Solutions ORM (JPA, Hibernate) par rapport à JDBC

Question

Je dois être en mesure d'insérer/mettre à jour des objets à un débit cohérent d'au moins 8000 objets toutes les 5 secondes dans une base de données HSQL en mémoire.

J'ai effectué quelques tests de performance de comparaison entre Spring/Hibernate/JPA et JDBC pur. J'ai trouvé une différence significative dans les performances en utilisant HSQL .. Avec Spring/Hib/JPA, je peux insérer 3000-4000 de mes objets de 1,5 Ko (avec une relation un-plusieurs et un beaucoup-plusieurs) en 5 secondes, tandis qu'avec direct Les appels JDBC je peux insérer 10 000-12 000 de ces mêmes objets.

Je n'arrive pas à comprendre pourquoi il y a un tel écart. J'ai beaucoup modifié les réglages Spring/Hib/JPA en essayant de me rapprocher des performances sans avoir de chance. Je veux utiliser Spring/Hib/JPA à des fins futures, l'extensibilité, et parce que les relations de clés étrangères (un-plusieurs et plusieurs-plusieurs) sont difficiles à maintenir à la main; mais les exigences de performance semblent pointer vers l'utilisation de JDBC pur.

Des idées de pourquoi il y aurait un tel écart?

Answer 1

Nous avons une expérience similaire en comparant Hibernate avec JDBC en mode batch (instruction # executeBatch()). Fondamentalement, il semble que Hibernate ne fonctionne pas très bien avec les opérations en masse. Dans notre cas, l'implémentation d'Hibernate était assez rapide sur notre matériel de production.

Ce que vous pouvez faire, c'est d'envelopper vos appels de base de données dans un DAO, donnant à votre application un moyen cohérent d'accéder à vos données. Implémentez vos DAO avec Hibernate là où c'est pratique, et avec JDBC où les exigences de performance l'exigent.

Answer 2

Hibernate conserve un cache de premier niveau d'objets à utiliser lors de la vérification sale ainsi que pour agir comme unité de travail et carte d'identité. Cela ajoute à la surcharge, en particulier dans les opérations de type bulk. Pour les opérations en bloc, vous pouvez rechercher StatelessSessions qui ne conserve pas cet état.

Answer 3

Tout ce mapping ... ça peut être un peu cher, avec toute la logique des arcanes et toute la réflexion et la vérification de cohérence qu'il doit faire.

Le point de la cartographie n'est bien sûr pas d'augmenter les performances. En règle générale, vous prenez un coup de performance. Mais ce que vous perdez en performance, vous (peut) gagner de nombreuses fois dans la productivité des développeurs, la cohérence, la testabilité, la fiabilité, et tant d'autres attributs convoités. En règle générale, lorsque vous avez besoin de performances supplémentaires et que vous ne voulez pas abandonner le mappage, vous ajoutez du matériel supplémentaire.

Answer 4

Au minimum, vous devez effectuer des insertions par lots dans Hibernate: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Permet d'économiser beaucoup de temps. Et, comme le mentionne Justice, l'objectif principal de Hib n'est pas la performance de l'ordinateur, mais la performance du développeur. Cela dit, il est généralement possible d'obtenir des résultats comparables (pas égaux, mais pas si graves) aux résultats de JDBC.

Answer 5

N'utilisez jamais une seule technologie pour tous les problèmes. Selon le problème, décider quelle technologie utiliser. Bien sûr, jpa ou hibernate est plus lent que jdbc. jdbc est au niveau inférieur à jpa. De plus, un professionnel db avec jdbc peut écrire un sql plus optimisé que jpa. Si vous avez donné un point critique où la vitesse est requise, jpa n'est pas votre choix.