Решения ORM (JPA; Hibernate) против JDBC

Question

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

Я провел несколько сравнительных тестов производительности между Spring / Hibernate / JPA и чистым JDBC. Я обнаружил существенную разницу в производительности с использованием HSQL. С помощью Spring / Hib / JPA я могу вставить 3000-4000 своих объектов размером 1,5 КБ (с отношением One-Many и Many-Many) за 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: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Экономит много времени туда и обратно.

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

Answer 3

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

Answer 4

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

Answer 5

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

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