Вы всегда используете кэш второго уровня в Hibernate?

Question

Всегда ли вы используете кэш второго уровня в Hibernate или вы сначала пробуете его без него и используете его только при снижении производительности?

Answer 1

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

Answer 2

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

Answer 3

Я использовал Hibernate всегда в контексте другого фреймворка (например, Spring), где включение кэширования почти тривиально. Некоторые из этих проектов использовали кэширование через ehcache для некоторых критических классов домена.

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

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

Answer 4

Сначала мы пробуем его без использования, и используем его только при снижении производительности.

Answer 5

Если вы все делаете правильно (остерегайтесь выбора N + 1 и т. Д.), Производительность должна быть приемлемой без кэша второго уровня для подавляющего большинства случаев

Answer 6

Теперь существует особая проблема, связанная с этим. И это печально известное исключение LazyInitialization. По сути, вам нужно инициализировать все ленивые ассоциации, пока сущности привязаны к контексту постоянства. Два способа сделать это:

1. Доступ к отношениям вручную для принудительной загрузки.
2. Используйте запрос, определяющий выборку соединения.

Эти два подхода приводят к совершенно разным частям кода, поэтому переход с одного на другой может быть довольно сложной задачей. Проблема заключается в том, что подход 1. приводит к большому количеству запросов, когда не используется кэш 2-го уровня, поэтому люди могут решить использовать подход 2, что приводит к запросам на повышение температуры. Однако, когда вы включаете кэш 2-го уровня позже, запросы из подхода 2 не загружают данные из кеша, а помещают в него результирующие сущности, делая выполнение запроса медленнее, чем без кеша. Это приводит к сложным вещам, таким как необходимость использовать кеш запросов.

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

Answer 7

Цитируя знаменитого Дональда Кнута: «Программисты тратят огромное количество времени на размышления или беспокойство по поводу скорости некритических частей своих программ, и эти попытки повышения эффективности на самом деле оказывают сильное негативное влияние, когда рассматриваются вопросы отладки и обслуживания. Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла. Но мы не должны упускать наши возможности в эти критические 3%. "

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

Однако реализация этой оптимизации в NHibernate в большинстве случаев оказывает незначительное влияние на отладку и обслуживание и часто может быть реализована с минимальными добавлениями в код.

Если вы в значительной степени полагаетесь на отложенную загрузку, имеете таблицы только для чтения, вам не нужно беспокоиться о параллелизме с приложениями, не использующими NHibernate, производительность является проблемой, и вы знаете, как оптимизировать использование кэша 2-го уровня (то есть вы уже знать ответ на этот вопрос), тогда вам следует использовать кэш второго уровня.