Решения 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.
Есть идеи, почему может быть такое огромное несоответствие?
Ответы 5
Hibernate поддерживает кэш объектов первого уровня для использования при грязной проверке, а также в качестве единицы работы и карты идентификации. Это увеличивает накладные расходы, особенно при операциях массового типа. Для массовых операций вы можете исследовать Сеансы без сохранения состояния, которые не поддерживают это состояние.
Документы могли быть перемещены. docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.ht ml
У нас есть аналогичный опыт сравнения Hibernate с JDBC в пакетном режиме (оператор # executeBatch ()). По сути, кажется, что Hibernate не очень хорошо справляется с массовыми операциями. В нашем случае реализация Hibernate была достаточно быстрой на нашем производственном оборудовании.
Возможно, вы захотите обернуть вызовы базы данных в DAO, предоставив вашему приложению последовательный способ доступа к вашим данным. Реализуйте свои DAO с помощью Hibernate, где это удобно, и с помощью JDBC, где этого требуют требования к производительности.
Вы тоже принимали Hib-терапию? В моих тестах партии Hib и JDBC были почти идентичны.
Все это отображение ... оно может стать немного дороже, со всей загадочной логикой и всеми необходимыми отражениями и проверками согласованности.
Смысл сопоставления, конечно, не в повышении производительности. Обычно производительность снижается. Но что бы вы ни теряли в производительности, вы (может) многократно выигрываете в продуктивности разработчика, согласованности, тестируемости, надежности и многих других желанных качествах. Обычно, когда вам нужна дополнительная производительность и вы не хотите отказываться от сопоставления, вы добавляете еще какое-то оборудование.
Как минимум, вам нужно выполнять пакетную вставку в Hibernate: http://www.hibernate.org/hib_docs/reference/en/html/batch.html Экономит много времени на обход.
И, как сказал Джастис, основная цель Hib - не производительность компьютера, а производительность разработчика. Сказав это, обычно можно достичь сопоставимых (не равных, но не намного хуже) результатов JDBC.
Возможно, документы переместились. Попробуйте здесь docs.jboss.org/hibernate/core/3.3/reference/en/html/batch.ht ml
Кроме того, это упоминается в документации, но его легко пропустить. Пакетный режим будет отключен и проигнорирован, если вы выполняете вставки и работаете с объектами, у которых есть автоматически сгенерированный первичный ключ.
Никогда не используйте одну технологию для всех проблем. В зависимости от проблемы решите, какую технологию использовать. Конечно, jpa или hibernate медленнее, чем jdbc. jdbc находится на более низком уровне, чем jpa. Также профессионал по базам данных с jdbc может написать более оптимизированный sql, чем jpa. Если вы указали критическую точку, где требуется скорость, jpa не ваш выбор.
Возможно, вы захотите переименовать этот вопрос, так как заголовок не очень описывает фактический вопрос.