para - orm personaje
¿Es lento el ORM? ¿Importa? (15)
Los ORM son más lentos y agregan sobrecarga a las aplicaciones (a menos que sepa específicamente cómo solucionar estos problemas, lo cual no es muy común). La base de datos es el elemento más crítico y las aplicaciones web deben diseñarse a su alrededor.
Muchos marcos de OOP que usan Active Record o ORMs, desarrolladores en general, tratan la base de datos como una ocurrencia secundaria sin importancia y tienden a verla como algo que realmente no necesitan aprender. ¡Pero el rendimiento y la escalabilidad suelen sufrir, ya que el DB está fuertemente gravado!
Muchas aplicaciones web a gran escala se han desplomado, perdiendo millones y meses o años debido a que no reconocieron la importancia de la base de datos. Cientos de usuarios concurrentes y tablas con millones de registros requieren optimización y optimización de la base de datos. Pero creo que el problema es notable con unos pocos usuarios y menos datos.
¿Por qué los desarrolladores tienen tanto miedo de aprender SQL y medidas de ajuste cuando es la clave del rendimiento?
Realmente me gusta ORM en comparación con el procedimiento de almacenamiento, pero una cosa que temo es que ORM podría ser lento, debido a capas y capas de abstracción. ¿El uso de ORM ralentizará mi aplicación? ¿O es importante?
¿Es lento el ORM?
No inherentemente. Algunos ORM pesados pueden agregar un arrastre general a las cosas, pero no estamos hablando de una desaceleración de órdenes de magnitud.
Lo que hace que ORM sea lento es el uso ingenuo. Si está utilizando un ORM porque parece fácil y no sabe cómo funciona el modelo de datos relacionales subyacente, puede escribir fácilmente código que parezca razonable para un programador de OO, pero asesinará el rendimiento.
ORM es una herramienta útil, pero necesita la comprensión de nivel inferior (que generalmente proviene de escribir consultas SQL) para ir con ella.
¿Importa?
Si termina realizando una consulta en bucle para cada una de las miles de entidades a la vez, en lugar de una sola combinación rápida, entonces puede hacerlo.
¿Es lento el ORM?
Sí (en comparación con los procedimientos almacenados)
¿Importa?
No (excepto que su preocupación es la velocidad)
Creo que el problema es que muchas personas piensan en ORM como un "truco" de objetos para las bases de datos, para codificar menos o simplificar el uso de SQL, mientras que en realidad es ... un Objeto - Para Mapeo Relacional (DB).
ORM se utiliza para persistir sus objetos a un sistema de administrador de bases de datos relacionales, y no (simplemente) para sustituir o hacer SQL más fácil (aunque también hace un buen trabajo)
Si no tiene un buen modelo de objeto, o lo está usando para generar informes, o incluso si solo está tratando de obtener cierta información, ORM no lo vale.
Si, por otro lado, tienes un sistema complejo modelado a través de objetos, cada uno tiene reglas diferentes e interactúan dinámicamente y tu preocupación es que esa información persista en la base de datos en lugar de sustituir algunas secuencias de comandos SQL existentes por ORM.
Descubrí que la diferencia entre "demasiado lento" y "no demasiado lento" depende de si tiene activada la caché de segundo nivel de ORM (SessionFactory). Sin él, se maneja bien bajo carga de desarrollo, pero aplastará su sistema con una carga de producción moderada. Después de encender el caché de segundo nivel, el servidor manejó la carga esperada y escalado muy bien.
El uso de un ORM generalmente es más lento. Pero el aumento en productividad que obtienes hará que tu aplicación funcione mucho más rápido. Y el tiempo que ahorre puede gastar más tiempo buscando las partes de su aplicación que están causando la desaceleración más grande: puede dedicar tiempo a optimizar las áreas en las que obtiene el mejor rendimiento de su esfuerzo de desarrollo. Solo porque haya decidido usar un ORM no significa que no pueda usar otras técnicas en las secciones de código que realmente puedan beneficiarse de él.
En un proyecto de Windows Mobile 5 contra el uso de SqlCe, pasé de usar objetos codificados a mano a objetos generados por código (CodeSmith) usando una plantilla ORM. En el proceso, todos mis datos de acceso usaron CSLA como capa base.
La conversión directa mejoró mi desempeño en un 32% en pruebas locales, casi todo como resultado de mejores métodos de acceso.
Después de ese cambio, ajustamos las plantillas (después de ver algunas características de rendimiento de SqlCe en PDC de Steve Lasker) y en menos de 20 minutos, nuestra capa de datos completa mejoró mucho, nuestras llamadas "lentas" promedio pasaron de 460 ms a ~ 20 ms. Lo bueno de las cosas de ORM es que solo tuvimos que implementar (y probar la unidad) estos cambios una vez y todos los códigos de acceso a los datos se cambiaron. Fue un increíble ahorro de tiempo, tal vez ahorramos 40 horas o más.
Dicho lo anterior, perdimos algo de tiempo sacando un grupo de diálogos de ''espera'' y ''progreso'' que ya no eran necesarios.
He utilizado algunas de las herramientas ORM, y puedo recomendar dos de ellas:
Ambos han funcionado bastante bien y cualquier pérdida de rendimiento no se ha notado.
Realmente nunca entendí por qué la gente piensa que esto es más lento o que es más lento ... obtengo una máquina real, digo. He tenido resultados mixtos ... He visto que el tiempo de ejecución para un procedimiento almacenado es mucho más lento que ORM y viceversa. Pero en ambos casos, el rendimiento se debió a la diferencia en el hardware.
Respuesta obvia: depende
ORM hace un buen trabajo aislando a un programador de SQL. Esto en efecto sustituye las consultas mediocres generadas por computadora por las consultas catastróficamente malas que un programador podría dar.
Incluso en el mejor de los casos, un ORM va a hacer un trabajo extra, cargando campos que no necesita, verificando restricciones explícitamente, y así sucesivamente.
Cuando estos se convierten en un cuello de botella, la mayoría de los ORM te permiten pasar de un lado a otro e inyectar SQL sin procesar.
Si su aplicación se ajusta bien a los objetos, pero no tan fácilmente con las relaciones, entonces esto aún puede ser una ganancia. Si, en cambio, su aplicación se adapta muy bien a un modelo relacional, entonces el ORM representa un cuello de botella de codificación además de un posible cuello de botella de rendimiento.
Una cosa que he encontrado particularmente ofensiva sobre la mayoría de los ORM es su manejo de claves primarias. La mayoría de los ORM requieren pk para todo lo que tocan, incluso si no hay un uso concebible para ellos. Ejemplo: los autores deben tener pk''s, las publicaciones de blog DEBERÍAN tener pk''s, pero los enlaces (join table) entre los autores y las publicaciones no.
Sí, ORM reducirá la velocidad de su aplicación. Por cuánto depende de qué tan lejos vaya la abstracción, qué tan bien se mapea su modelo de objetos en la base de datos y otros factores. La pregunta debería ser: ¿está dispuesto a gastar más tiempo de desarrollador y usar acceso de datos directo o cambiar menos tiempo de desarrollo para un rendimiento de ejecución más lento?
En general, los buenos ORM tienen poca sobrecarga y, en general, se considera que valen la pena compensarlos.
Si, importa Utiliza más ciclos de CPU y, en consecuencia, ralentiza la aplicación. Escúchame aunque ...
Pero, considere esto: ¿qué es más caro? ¿Hardware del servidor u otro programador? El hardware del servidor, en general, es más barato que contratar a otro equipo de programadores. Entonces, aunque ORM puede estar costando ciclos de CPU, necesita un programador menos para administrar sus consultas SQL, lo que a menudo resulta en un costo neto más bajo.
Para determinar si vale la pena, calcule o determine cuántas horas guardó utilizando un ORM. Luego, averigüe cuánto dinero gastó en el servidor para soportar ORM. Multiplique las horas que guardó por su tarifa por hora y compare con el costo del servidor.
Por supuesto, si un ORM realmente le ahorra tiempo es un debate completamente diferente ...
Siempre he encontrado que no importa. Debería usar lo que sea más productivo, receptivo a los cambios y lo que sea más fácil de depurar y mantener.
La mayoría de las aplicaciones nunca necesitan suficiente carga para que la diferencia entre ORM y SP sea notable. Y hay optimizaciones para hacer que ORM sea más rápido.
Finalmente, una aplicación bien escrita tendrá su acceso a datos separado de todo lo demás para que en el futuro pueda cambiar de ORM a lo que sea posible.
Un ORM puede ser más lento, pero esto se ve compensado por su capacidad para almacenar datos en caché, por lo tanto, por más rápida que sea la alternativa, no puede obtener mucho más rápido que leer desde la memoria.
Un ORM siempre agregará algo de sobrecarga debido a las capas de abstracción, pero a menos que sea un ORM mal diseñado que debería ser mínimo. El tiempo para consultar realmente la base de datos será mucho más que la sobrecarga adicional de la infraestructura ORM si lo hace correctamente, por ejemplo, no cargando el gráfico completo del objeto cuando no es necesario. Un buen ORM (nHibernate) también le dará muchas opciones para las consultas que se ejecutan en la base de datos, por lo que también puede optimizarlas según sea necesario.
Sí, los ORM afectan el rendimiento, si eso finalmente depende de las características específicas de su proyecto.
A los programadores a menudo les encanta ORM porque les gustan los agradables entornos de cd de front-end como Visual Studio y no les gusta codificar SQL en bruto sin intellisense, etc.
Los ORM tienen otras limitaciones además de un impacto en el rendimiento: a menudo tampoco hacen lo que se necesita el 100% del tiempo, agregan la complejidad de una capa de abstracción adicional que se debe mantener y restablecer cada vez que se crean los elementos, también hay problemas de almacenamiento en caché a tratar.
Solo un pensamiento: si los proveedores de bases de datos hicieran que el entorno de programación SQL fuera tan agradable como Visual Studio y proporcionara un vínculo más natural entre el código db y el código front-end, no necesitaríamos los ORM ... supongo puede ir en esa dirección eventualmente.
ORM puede obtener un orden de magnitud más lento, no solo al azar de desperdiciar una gran cantidad de ciclos de CPU por sí mismo, sino que también usa mucho más memoria que luego tiene que ser GC-d.
Mucho peor, sin embargo, es que no es un estándar para ORM (a diferencia de SQL) y que mi y el gran uso de ORM-SQL varían de manera ineficiente, por lo que al final del día todavía tiene que profundizar en SQL para solucionar problemas y cada vez un ORM hace un lío y tienes que depurarlo. Lo que significa que no has ganado nada en absoluto.
Es una tecnología terriblemente inmadura para aplicaciones reales de nivel de producción. Cosas muy problemáticas son manejar índices, claves externas, ajustar tablas para ajustar jerarquías de objetos y transacciones terriblemente largas, lo que significa mucho más interbloqueos y repeticiones, si un ORM sabe cómo manejar eso en absoluto.
En realidad, hace que los servidores sean menos escalables, lo que multiplica los costos, pero estos costos no se mencionan al principio: una pequeña verdad incómoda :-) Cuando algo usa transacciones de 10 a 100 veces más grandes que lo óptimo, se vuelve imposible escalar SQL en absoluto. Hablando de sistemas serios otra vez, no cosas de casa / juguetes / académicos.