php - composer - redbean tutorial

Rendimiento ORB RedBean

Question

Me gustaría saber, ¿se puede utilizar Redbean ORM para escenarios orientados al rendimiento, como las aplicaciones web de redes sociales, y es estable incluso si varios usuarios obtienen datos al mismo tiempo? ¿También me gustaría saber si Redbean consume más espacio de memoria?

¿Alguien puede ofrecer un estudio comparativo de Doctrine-Propel-Redbean?

Answer 1

@ tereško si es posible, ¿puede dar los pros y los contras de orm con respecto a sql puro de acuerdo con su experiencia y también buscaré el tema en Google al mismo tiempo? -

Bueno ... explicar esto en 600 caracteres sería difícil.

Debo aclarar una cosa: se trata de ORM en PHP , aunque estoy bastante seguro de que también se aplica a algunos ORM de Ruby y quizás a otros.

En resumen, debes evitarlos, pero si tienes que usar un ORM, entonces serás mejor con Doctrine 2.x, es el mal menor. (Implementa algo similar a DataMapper lugar de ActiveRecord).

Caso contra ORMs

La razón principal por la que a algunos desarrolladores les gusta usar ORM es también lo peor de ellos: es fácil hacer cosas simples en ORM , con costos de rendimiento muy pequeños. Esto está perfectamente bien.

1. Complejidad exponencial

El problema se origina en las personas a la misma herramienta para todo. Si todo lo que tienes es un martillo (..) tipo de problema. Esto se traduce en la creación de una deuda técnica .

Al principio es fácil escribir un nuevo código relacionado con DB. Y tal vez, debido a que tiene un gran proyecto, la administración en las primeras semanas (porque más tarde se trataría de problemas adicionales, lea El mes-hombre mítico , si está interesado en los detalles) decide contratar a más personas. Y terminas prefiriendo personas con habilidades de ORM sobre SQL general.

Pero, a medida que el proyecto avanza, comenzará a utilizar ORM para resolver problemas cada vez más complejos. Comenzará a sortear algunas limitaciones y, eventualmente, puede terminar con problemas que simplemente no se pueden resolver, incluso con todos los hacks ORM que conoce ... y ahora no tiene los expertos en SQL, porque no los contrató.

Además, la mayoría de los ORM populares están implementando ActiveRecord , lo que significa que la lógica de negocios de su aplicación está directamente acoplada a ORM. Y agregar nuevas funciones llevará más y más tiempo debido a ese acoplamiento. Y por la misma razón, es extremadamente difícil escribir buenas pruebas unitarias para ellos.

2. Rendimiento

Ya mencioné que incluso los usos simples de ORM (que trabajan con una sola tabla, sin JOIN ) tienen algunos costos de rendimiento. Se debe al hecho de que usan comodines * para seleccionar datos. Cuando solo necesita la lista de ID de artículos y títulos, no tiene sentido recuperar el contenido.

Los ORM son realmente malos para trabajar con varias tablas, cuando necesita datos basados ​​en múltiples condiciones. Considera el problema:

La base de datos contiene 4 tablas: Projects , Presentations , Slides y Bulletpoints .

• Los proyectos tienen muchas presentaciones
• Las presentaciones tienen muchas diapositivas.
• Las diapositivas tienen muchos Bulletpoitns

Y debe encontrar el contenido de todos los Bulletpoints en las Slides etiquetadas como "importantes" en 4 Presentations más recientes relacionadas con los Projects con los ID 2, 4 y 8.

Este es un JOIN simple para escribir en SQL puro, pero en cualquier implementación de ORM, como he visto, esto resultará en un bucle anidado de 3 niveles, con consultas en cada nivel.

PD: hay otras razones y efectos secundarios, pero son relativamente menores ... no puedo recordar ningún otro problema importante en este momento.

Answer 2

Aquí difiero de @ tereško: los ORM pueden hacer que las consultas de la base de datos sean más fáciles de escribir y de mantener. Hay un gran trabajo en Propel y Doctrina, en mi opinión, ¡aprovéchalos! Hay una serie de comparaciones de rendimiento en la web, y también NotORM ver NotORM (no lo he usado pero hacen algunas comparaciones con Doctrine, si recuerdo bien).

Si llega a un punto en el que su rendimiento requiere que realice un SQL sin formato, optimice en ese punto. Pero en términos de reducir su número de errores y aumentar su productividad, creo que sus ahorros financiarán un mejor servidor de todos modos. Por supuesto, su kilometraje puede variar.

No conozco RedBean, por cierto, pero creo que Propel es más rápido que Doctrine en la mayoría de los casos, ya que las clases son generadas previamente. Usé Propel cuando era la única opción y lo seguí, aunque ciertamente no sería reacio a usar Doctrine.

Actualización 2018

Propel 2 todavía está en alfa después de varios años, y necesita una serie de grandes proyectos de refactorización, que lamentablemente no se hicieron. Aunque los mantenedores dicen que este alfa es bueno para usar en producción, ya que tiene una buena cobertura de pruebas, ahora han comenzado con Propel 3. Desafortunadamente, esto no ha tenido ningún lanzamiento todavía, al momento de escribir esto, a pesar de que El repositorio tiene un año de antigüedad.

Si bien creo que Propel fue un gran proyecto, me pregunto si es mejor usar otra cosa por el momento. ¡Todavía podría levantarse de las cenizas!

Answer 3

Me gustaría ir con la situación de "Caballos para cursos" que utiliza una combinación de ambos mundos. He construido pocas aplicaciones a gran escala utilizando RedBean, por lo que mi comentario se centrará exclusivamente en RedBean y no en otros ORM.

¿Es RedBean ORM LENTO?

Bueno, depende de cómo lo uses. En ciertas situaciones, es más rápido que la consulta tradicional porque RedBean almacena en caché el resultado durante unos segundos. Reutilizar la consulta producirá resultados más rápido. Eche un vistazo al registro usando R::debug(true); Siempre muestra

"SELECT * FROM `table` -- keep-cache"

Escenario 1: Fetching All (*)

En RedBean si consultas

$result = R::findOne(''table'', '' id = ?'', array($id));

Esto se representa como

$result= mysql_query("Select * from TABLE where id =".$id);

Puede argumentar que si la tabla tiene varias columnas, ¿por qué debería consultar (*) ?

Escenario 2: Columna única

Obteniendo una sola columna

R::getCol( ''SELECT first_name FROM accounts'' );

Como mencioné "Horses for Courses", los desarrolladores no deberían simplemente confiar en FindOne, FindAll, FindFirst, FindLast sino también en redactar cuidadosamente lo que realmente necesitan.

Escenario 3: almacenamiento en caché

Cuando no necesita el almacenamiento en caché, puede deshabilitarlo en el nivel de la aplicación, lo que no es una situación ideal

R::$writer->setUseCache(true);

RedBean sugiere que si no desea deshabilitar el almacenamiento en caché en el nivel de la aplicación, debe usar la consulta tradicional con el parámetro no-cache como $result = R::exec("SELECT SQL_NO_CACHE * FROM TABLE");

Esto resuelve perfectamente el problema de obtener datos en tiempo real de la tabla descartando por completo el caché de consultas.

Escenario 4: Desarrollo rápido

El uso de ORM hace que el desarrollo de su aplicación sea realmente rápido, los desarrolladores pueden codificar usando ORM 2-3 veces más rápido que escribir SQL.

Escenario 5: consultas y relaciones complejas

RedBean presenta una manera realmente agradable de implementar consultas complejas y relaciones de one-to-many o de many-to-many

SQL simple para consultas complejas

$books = R::getAll( ''SELECT 
    book.title AS title, 
    author.name AS author, 
    GROUP_CONCAT(category.name) AS categories FROM book
    JOIN author ON author.id = book.author_id
    LEFT JOIN book_category ON book_category.book_id = book.id
    LEFT JOIN category ON book_category.category_id = category.id 
    GROUP BY book.id
    '' );
    foreach( $books as $book ) {
        echo $book[''title''];
        echo $book[''author''];
        echo $book[''categories''];
    }

O RedBean forma de manejar las relaciones de muchos a muchos

list($vase, $lamp) = R::dispense(''product'', 2);

$tag = R::dispense( ''tag'' );
$tag->name = ''Art Deco'';

//creates product_tag table!
$vase->sharedTagList[] = $tag;
$lamp->sharedTagList[] = $tag;
R::storeAll( [$vase, $lamp] );

Problemas de desempeño

Los argumentos como los ORM suelen ser lentos, consumen más memoria y tienden a hacer que una aplicación sea lenta. Creo que no están hablando de RedBean.

Lo hemos probado con MySQL y Postgres, confía en que el rendimiento nunca fue un cuello de botella.

No se puede negar que los ORM suponen una pequeña sobrecarga y tienden a hacer que su aplicación sea más lenta (solo un poco). El uso de ORM es principalmente un compromiso entre el tiempo del desarrollador y el rendimiento del tiempo de ejecución ligeramente más lento. Mi estrategia es construir primero la aplicación de extremo a extremo con el ORM, luego, en función de los casos de prueba, ajustar los módulos de velocidad crítica para usar el acceso directo a los datos.

Answer 4

Siento que la respuesta de Tereško no es del todo correcta.

En primer lugar no aborda la pregunta original. De hecho, es un caso contra los ORM, y estoy de acuerdo con los problemas descritos en su respuesta. Por eso escribí RedBeanPHP. El hecho de que la mayoría de los ORM no logren hacer su vida un poco más fácil no significa que el concepto de un sistema de mapeo relacional de objetos sea defectuoso. La mayoría de los ORM intentan ocultar SQL, por lo que los JOIN se vuelven tan complejos; necesitan reinventar algo similar en un entorno orientado a objetos. Aquí es donde RedBeanPHP difiere, ya que no oculta SQL. Crea tablas de SQL válidas y legibles que son fáciles de consultar. En lugar de un lenguaje de consulta fabricado, RedBeanPHP usa un SQL simple y antiguo para la recuperación de registros y beans. En breve; RedBeanPHP trabaja con SQL en lugar de contra él. Esto lo hace mucho menos complejo.

Y sí, el rendimiento de RedBeanPHP es bueno. ¿Cómo puedo estar tan seguro? Porque a diferencia de otros ORM, RedBeanPHP distingue entre modo de desarrollo y modo de producción. Durante el ciclo de desarrollo la base de datos es fluida; Puedes agregar entradas y se agregarán dinámicamente. RedBeanPHP crea las columnas, índices, adivina los tipos de datos, etc. Incluso alarga las columnas si necesita más bytes (tipo de datos más alto) después de un tiempo. Esto hace que RedBeanPHP sea extremadamente lento, pero solo durante el tiempo de desarrollo cuando la velocidad no debería ser un problema. Una vez que hayas terminado de desarrollar, debes congelar la base de datos con un especificador de modo único R :: freeze () y no se realizan más comprobaciones. Lo que queda es una capa de base de datos bastante sencilla en su servidor de producción. Y porque no se hace mucho, el rendimiento es bueno.

Sí, lo sé, soy el autor de RedBeanPHP, por lo que soy parcial. Sin embargo, sentí que mi ORM estaba siendo visto de la misma manera que los otros ORM, lo que me llevó a escribir esto. Si desea saber más, no dude en consultar el sitio web de RedBeanPHP , y aquí hay una discusión sobre el rendimiento .

En nuestra empresa utilizamos RedBeanPHP para sistemas integrados y sistemas de negocios financieros, por lo que parece escalar bastante bien.

Juntos, yo y la comunidad de RedBeanPHP intentamos sinceramente hacer del mundo ORM un lugar mejor; Puedes leer la declaración de la misión here .

Buena suerte con su proyecto y espero que encuentre la solución técnica que está buscando.