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

Мне нужно иметь возможность вставлять/обновлять объекты с постоянной скоростью не менее 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.

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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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