ORM-решения (JPA, Hibernate) и JDBC

Question

Мне нужно иметь возможность вставлять/обновлять объекты с постоянной скоростью не менее 8000 объектов каждые 5 секунд в базе данных HSQL в памяти.

Я проверил сравнительное тестирование производительности между Spring/Hibernate/JPA и чистым JDBC. Я нашел существенную разницу в производительности с использованием HSQL. С Spring/Hib/JPA я могу вставить 3000-4000 моих 1.5 КБ объектов (с отношениями «Один-много» и «Много-много») через 5 секунд, тогда как с прямым JDBC звонки Я могу вставить 10 000-12 000 из тех же самых объектов.

Я не могу понять, почему существует такое огромное несоответствие. Я настроил настройки Spring/Hib/JPA, пытаясь приблизиться к производительности без везения. Я хочу использовать Spring/Hib/JPA для будущих целей, расширяемости и потому, что отношения с внешним ключом (один-много и многие-многие) трудно поддерживать вручную; но требования к производительности, похоже, указывают на использование чистого JDBC.

Любые идеи, почему возникло бы такое огромное несоответствие?

Answer 1

У нас есть аналогичный опыт сравнения Hibernate с JDBC в пакетном режиме (Statement # executeBatch()). В принципе, похоже, что Hibernate просто не справляется с массовыми операциями. В нашем случае реализация Hibernate была достаточно быстрой на нашем производственном оборудовании.

Что вы можете сделать, это обернуть вызовы базы данных в DAO, предоставляя вашему приложению последовательный способ доступа к вашим данным. Внедрите свои DAO с Hibernate, где это удобно, и с JDBC, где требования к производительности требуют этого.

Answer 2

Hibernate поддерживает кеш-память первого уровня для использования в грязной проверке, а также для работы в качестве единицы работы и карты идентичности. Это добавляет дополнительные накладные расходы, особенно в операциях массового типа. Для массовых операций вы можете изучить StatelessSessions, которые не поддерживают это состояние.

Answer 3

Все это отображение ... оно может стать немного дорогим, со всей тайной логикой и всеми отражениями и согласованностью, которые она должна выполнить.

Точка сопоставления, конечно, не должна повышать производительность. Как правило, вы получаете удар производительности. Но то, что вы теряете в производительности, вы (может) многократно выигрывают в производительности разработчиков, согласованности, тестируемости, надежности и многих других желанных атрибутах. Как правило, когда вам нужна дополнительная производительность, и вы не хотите отказываться от сопоставления, вы можете добавить еще несколько аппаратных средств.

Answer 4

Как минимум, вам нужно делать пакетные вставки в спящем режиме: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Экономит много времени в оба конца.

И, как отметил судья, основной целью Hib является не производительность компьютера, а производительность разработчика. Сказав это, обычно можно достичь сопоставимых (не равных, но не намного хуже) результатов JDBC.

Answer 5

Никогда не используйте одну технологию для всех проблем. В зависимости от проблемы решайте, какую технологию использовать. Конечно, jpa или спящий режим медленнее, чем jdbc. jdbc находится на более низком уровне, чем jpa. Также специалист по db с jdbc может написать более оптимизированный sql, чем jpa. Если вы дали критическую точку, где требуется скорость, jpa не является вашим выбором.