Хорошо ли Hibernate для пакетной обработки? Как насчет использования памяти?

Question

У меня есть ежедневный пакетный процесс, который включает в себя выбор большого количества записей и форматирование файла для отправки во внешнюю систему. Мне также нужно пометить эти записи как отправленные, чтобы они не были переданы завтра.

По моему наивному способу JDBC я подготовил и выполнил оператор, а затем начал бы перебирать набор записей. Поскольку я только перебираю набор записей, моему серверу приложений не нужно одновременно хранить весь набор результатов в памяти. Группы записей можно передавать с сервера базы данных.

Теперь, допустим, я использую спящий режим. Неужели я не получу кучу объектов, представляющих весь набор результатов в памяти сразу?

Answer 1

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

Причины использования Hibernate:

• «Кто-то» был «креативным» с именами столбцов (PRXFC0315.XXFZZCC12)
• Дизайн БД все еще находится в движении, и / или вам нужно одно место, где имена столбцов сопоставляются с Java.
• В любом случае вы используете Hibernate
• У вас сложные запросы, и вы не владеете SQL

Причины не для использования Hibernate:

• Остальная часть вашего приложения - чистый JDBC
• Вам не нужна вся сила Hibernate
• У вас сложные запросы, и вы свободно владеете SQL
• Вам нужна особая функция вашей БД, чтобы заставить SQL работать

Answer 2

Hibernate предлагает некоторые возможности, чтобы сохранить сессию небольшой.

Вы можете использовать Query.scroll (), Criteria.scroll () для JDBC-подобной прокрутки. Вы можете использовать Session.evict (Object entity) для удаления сущностей из сессии. Вы можете использовать StatelessSession для подавления грязной проверки. И есть еще некоторые оптимизации производительности, см. Документацию Hibernate.

Answer 3

Hibernate, как и любая среда ORM, предназначена для разработки и поддержки систем на основе принципа объектно-ориентированного программирования. Но большинство баз данных являются реляционными и не объектно-ориентированными, поэтому в любом случае ORM - это всегда компромисс между удобным ООП-программированием и оптимизированным / наиболее эффективным доступом к БД.

Я бы не использовал ORM для конкретных изолированных задач, а скорее как общий архитектурный выбор для уровня сохраняемости приложений.

Answer 4

По моему мнению, я бы НЕ использовал бы Hibernate, поскольку он делает ваше приложение намного больше и менее удобным для обслуживания, и у вас нет возможности быстро оптимизировать сгенерированные sql-скрипты. Кроме того, вы можете использовать все функции SQL, которые поддерживает JDBC-мост, и не ограничены функциональностью гибернации. Другое дело, что у вас есть ограничения, которые входят в каждый слой устаревшего кода.

Но, в конце концов, это философский вопрос, и вы должны делать это так, как вам нужно, чтобы вы лучше думали.

Answer 5

Если возможны проблемы с производительностью, придерживайтесь кода JDBC.

Существует ряд хорошо известных оптимизаций чистого SQL, которые что было бы очень трудно сделать в Hibernate.

Выберите только те столбцы, которые вы используете! (Без "select *" материал).

Сохраняйте SQl как можно более простым. например Не включайте в объединение небольшие справочные таблицы, такие как коды валют. Вместо этого загрузите таблицу валют в память и разрешите описания валют с помощью поиска программы.

В зависимости от незначительного переупорядочения SQL в СУБД, где предикаты могут оказать существенное влияние на производительность.

Если вы обновляете / вставляете коммит только каждые 100-1000 обновлений. т.е. не совершайте каждую единицу работы, но держите некоторый счетчик, чтобы вы совершали реже.

Воспользуйтесь преимуществами агрегатных функций вашей базы данных. Если вы хотите получить итоги по коду DEPT, сделайте это в SQL с помощью «SUM (сумма) ... GROUP BY DEPT».