Как контролировать использование карт Hibernate по мере роста требований

Question

Я работал над несколькими веб-приложениями Java, в которых постоянство происходит через Hibernate, и мы начинаем с некоторого центрального класса (например, приложения страхования), не тратя времени на размышления о том, как разбить вещи на управляемые куски. Со временем, по мере добавления функций, мы добавляем новые сопоставления (тарифы, клиенты, адреса и т. Д.), А затем увеличивается количество времени, затрачиваемого на сохранение и загрузку объекта страхования, и всего, к чему он подключается. В частности, вы приближаетесь к дате ввода в действие, и тестирование производительности с большими объемами данных в каждой таблице начинает демонстрировать, что все слишком медленно.

Очевидно, что есть несколько способов, которыми мы могли бы попытаться разделить вещи, например отображать только клиентские классы для клиентских экранов CRUD и т. д., которые было бы лучше установить на месте раньше, чем пытаться работать с ними в конце цикла разработки.

Мне просто интересно, есть ли рекомендации о способах решения / смягчения этого.

Answer 1

Пара трюков:

• Не используйте нетерпеливое извлечение. Если вы используете аннотацию, вы должны убедиться, что все аннотации * ToMany сделаны ленивыми (fetch = ... LAZY). Стремление забрать это зло. Если по какой-то причине вы действительно хотите загружать данные, вы всегда можете указать это в запросе.

• Не загружать слишком много объектов в одной транзакции. Допустим, у вас есть транзакция, которая обработает большое количество объектов (> 1000). Вы должны использовать некоторую нумерацию страниц и обрабатывать каждую страницу в своей собственной транзакции. Загрузка большого количества объектов в одной транзакции загрузит сеанс, и производительность снизится. Кроме того, вы можете удалить объекты, которые больше не используются, но это может быть сложно, если загружен граф объектов.

Последнее замечание: я использовал hibernate в системах с более чем 300 таблицами и с таблицами, имеющими> 30 миллионов записей. Таблицы имеют много связей, и мы не видим проблем с производительностью базы данных.

Answer 2

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

Answer 3

Проблемы такого типа могут быстро перерасти в уродливые религиозные дебаты. Многие аспекты недостатков ORM были обсуждены здесь . Тем не менее, трудно вести дискуссию в этой области, не отвлекаясь на религиозную войну. ORM великолепны, но для некоторых ситуаций, может быть, не совсем подходят. Возможно, вы столкнулись с ситуацией, когда ORM препятствует достижению вашей системы. Возможно, нет, и некоторые эксперты Hibernate могут провести вас через косяки.

Answer 4

Есть ли у Java такой порт? http://fluentnhibernate.org/ Это должно облегчить вашу жизнь, ускорить процесс, плюс оно предлагает много других преимуществ.

Edit: Кроме того, зачастую гораздо проще просто бросить аппаратное обеспечение на проблему. Если дела идут слишком медленно, стоит потратить пару 100 или 1000 долларов на аппаратное обеспечение, а не предпринимать длительные (читай: дорогостоящие) усилия по реинжинирингу.