Soluciones ORM (JPA; Hibernate) vs. JDBC

Question

Necesito poder insertar/actualizar objetos a una velocidad constante de al menos 8000 objetos cada 5 segundos en una base de datos HSQL en memoria.

He hecho algunas pruebas de rendimiento de comparación entre Spring/Hibernate/JPA y JDBC puro. He encontrado una diferencia significativa en el rendimiento usando HSQL. Con Spring/Hib/JPA, puedo insertar 3000-4000 de mis objetos de 1,5 KB (con una relación Uno-Muchos y Muchos-Muchos) en 5 segundos, mientras que con Direct Llamadas JDBC Puedo insertar 10,000-12,000 de esos mismos objetos.

No puedo entender por qué existe una gran discrepancia. He modificado mucho las configuraciones de Spring/Hib/JPA tratando de acercarme en el rendimiento sin suerte. Deseo usar Spring/Hib/JPA para propósitos futuros, capacidad de expansión y porque las relaciones de clave externa (uno-muchos y muchos-muchos) son difíciles de mantener a mano; pero los requisitos de rendimiento parecen apuntar hacia el uso de JDBC puro.

¿Alguna idea de por qué habría una gran discrepancia?

Answer 1

Tenemos experiencia similar comparando Hibernate con JDBC en modo batch (Statement # executeBatch()). Básicamente, parece que Hibernate simplemente no funciona bien con operaciones masivas. En nuestro caso, la implementación de Hibernate fue lo suficientemente rápida en nuestro hardware de producción.

Lo que puede querer hacer es encerrar sus llamadas a la base de datos en un DAO, dando a su aplicación una forma consistente de acceder a sus datos. Implemente sus DAO con Hibernate donde sea conveniente, y con JDBC donde los requisitos de rendimiento lo requieran.

Answer 2

Hibernate mantiene un caché de primer nivel de objetos para usar en la verificación sucia, así como para actuar como una Unidad de Trabajo y Mapa de Identidad. Esto se suma a la sobrecarga, especialmente en operaciones de tipo bulk. Para operaciones masivas, es posible que desee investigar StatelessSessions que no mantienen este estado.

Answer 3

Todo ese mapeo ... puede ser un poco caro, con toda la lógica arcana y toda la reflexión y la comprobación de coherencia que tiene que hacer.

El objetivo del mapeo no es aumentar el rendimiento, por supuesto. Por lo general, tomas un golpe de rendimiento. Pero lo que pierde en rendimiento, usted (puede) gana muchas veces más en productividad del desarrollador, consistencia, capacidad de prueba, confiabilidad y tantos atributos más codiciados. Normalmente, cuando necesita un rendimiento adicional y no desea renunciar a la asignación, puede agregar más hardware.

Answer 4

Como mínimo, necesita insertar lotes en Hibernate: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Ahorra mucho tiempo de ida y vuelta.

Y, como mencionó Justice, el objetivo principal de Hib no es el rendimiento de la computadora, sino el rendimiento del desarrollador. Una vez dicho esto, generalmente es posible obtener resultados comparables (no iguales, pero no mucho peores) a JDBC.

Answer 5

Nunca utilice una tecnología para todos los problemas. Según el problema, decida qué tecnología usar. Por supuesto, jpa o hibernate es más lento que jdbc. jdbc está en un nivel más bajo que jpa. También un profesional de db con jdbc puede escribir sql más optimizado que jpa. Si le dio un punto crítico donde se requiere velocidad, jpa no es su elección.