sql - framework - Costo de rendimiento de ORM

sql framework java

Question

¿Alguien tiene alguna experiencia que indique qué tipo de rendimiento puede esperar un desarrollador al elegir usar un ORM (en Django, RoR, SQLAlechemy, etc.) en SQL y bases de datos diseñadas a mano? Imagino que hay problemas complicados, incluso si la especificación de una base de datos dentro de las restricciones de un ORM aumenta o disminuye las posibilidades de crear una estructura de base de datos eficiente (según el nivel de experiencia del desarrollador) y la cuestión de qué tan bien el desarrollador construye el Consultas basadas en SQL o ORM (nuevamente basadas en su experiencia). Cualquier información con respecto a estos o problemas de rendimiento intrínseco sería realmente interesante para mí.

Answer 1

Esto dependerá mucho de con qué lo compare. El codificador que escribe el código de la mano es un truco total, podría ser una bendición en lugar de un golpe. Claramente, puede ir a la inversa también.

Answer 2

Mi consejo es que no te preocupes por esto hasta que lo necesites, no optimices prematuramente. Un ORM puede proporcionar muchos beneficios a la velocidad de desarrollo, la legibilidad del código y puede eliminar una gran cantidad de repetición de código. Recomendaría usar uno si hace que su aplicación sea más fácil de desarrollar.

A medida que avanza en el desarrollo, utilice puntos de referencia y perfiles para determinar los cuellos de botella en el código y, si es necesario, puede eludir el ORM y utilizar las consultas manuales cuando sean necesarios. Normalmente podrá mejorar la velocidad del ORM utilizando el almacenamiento en caché y los índices de base de datos (entre otras cosas) y luego podrá decidir dónde se requieren las consultas manuales. En su mayor parte, el rendimiento del ORM probablemente sea aceptable y los beneficios de usarlo superarán con creces el costo de rendimiento.

Answer 3

También depende de lo que está usando como ORM. En mi experiencia, Hibernate es un cerdo, en términos de velocidad, uso de recursos y tiempo de inicio. LINQ to SQL, por otro lado, es un contenedor SQL extremadamente liviano, cuyo impacto probablemente apenas notará (si es que lo hace).

Answer 4

El rendimiento siempre ha sido una reflexión en la mayoría de los desarrollos / arquitecturas DAL Layer. Creo que es hora de que comencemos a cuestionar el rendimiento de estas herramientas ORM, por la llamada facilidad de desarrollo que prometen:

Las dos áreas más importantes de problemas de rendimiento en ORM son:

1. Incapacidad para escribir Optimum SQL. Debe utilizar un lenguaje de consulta de objetos interpretado en SQL por el marco. Mayormente es un buen SQL, pero a menudo no es el SQL más eficiente.

2. Reflexión. La mayoría de los marcos ORM usan Reflection para rellenar objetos con Data de la base de datos. Las operaciones de reflexión son costosas y, con el aumento de la carga y los datos, la degradación del rendimiento se vuelve obvia.

Otros problemas de rendimiento que surgen se deben a un diseño ineficiente de la base de datos o al diseño del modelo de entidad debido al estrecho acoplamiento de los objetos de la entidad a las tablas.

Answer 5

Rendimiento : siempre es pro y contra. Si profundizas en la arquitectura ORM (mira mi artículo: evita los malos hábitos de ORM ), entonces encontrarás intuitivamente las formas de hacerlo más rápido. Aquí está mi otro artículo sobre cómo hacer EF6x 5 veces más rápido (al menos para situaciones de lectura): EF6.x 5 veces más rápido

De todos modos, para un buen rendimiento, incluso con ORM, necesitará crear vistas de bases de datos, índices también para verificar las consultas generadas y ejecutadas por ORM y afinarlas también. La carga ansiosa es imprescindible con ORM.