hibernate кэш второго уровня с Redis-это улучшит производительность?

в настоящее время я разрабатываю приложение, используя Весна MVC4 с и спящий режим 4. Я реализовал hibernate кэш второго уровня для улучшения производительности. Если я использую Рэдис что такое хранилище структуры данных в памяти, используемое в качестве базы данных, кэша и т. д., производительность увеличится, но будет ли это резкое изменение?

11
caching hibernate java redis spring

4 ответов

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

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

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

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

Sub оптимальная производительность
В зависимости от того, сколько производительности вам нужно и какой тип приложения вы используете Hibernate кэш второго уровня может быть хорошим или плохим выбором. Хорошо с точки зрения того, что это plug and play...." вроде..."плохо, потому что вы никогда не будете сжимать представление ты бы выиграл. Кроме того, разработка богатых моделей означает больше предварительной работы и больше ООП.

ограниченные возможности запроса на самом кэше
Это зависит от поставщика кэша, но некоторые из поставщиков действительно не очень хорошо делают соединения с предложением Where, отличным от ID. Если вы пытаетесь построить и в индексе памяти для запроса на Hazelcast, например, вы увидите, что я имею в виду.

7

да, если вы используете Redis, Это улучшит вашу производительность.

нет, это не будет кардинальных изменений. :)

https://memorynotfound.com/spring-redis-application-configuration-example/

http://www.baeldung.com/spring-data-redis-tutorial

приведенные выше ссылки помогут вам узнать способ интеграции redis с вашим проектом.

2

Это зависит от движения.

Если у вас есть 1000 или более запросов в секунду, и у вас мало ОЗУ, то да, используйте узлы redis на другой машине, чтобы использовать их. Это значительно улучшит вашу оперативную память и скорость запроса.

но если это не так, то не используйте его.

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

1

Ваш вопрос уже обсуждался здесь. Проверьте эту ссылку: кэш приложений V. s. hibernate кэш второго уровня, который использовать?

Это был наиболее приемлемый ответ, с которым я согласен:

Это действительно зависит от вашей модели запросов приложений и трафика спросы.

  1. использование Redis/Hazelcast может дать лучшую производительность, так как не будет быть любой, туда-обратно больше дБ, но вы нормированный данные в БД и денормализованная копия в вашем кэше, которая будет оказывать давление в политиках обновления кэша. Так вы получаете самое лучшее представление на стоимость реализации обновления кэша при сохранении данных изменения.
  2. использование кэша 2-го уровня проще настроить, но он хранит только сущности по ID. Существует также кэш запросов, хранящий идентификаторы, возвращаемые a данный запрос. Таким образом, кэш 2-го уровня-это двухэтапный процесс, который вы нужно настроиться, чтобы получить лучшее спектакль. При выполнении проекционные запросы кэш объектов 2-го уровня не помогут вам, так как он работает только при загрузке объекта. Основным преимуществом кэша 2-го уровня является что легче синхронизировать его при изменении данных, особенно если все ваши данные сохраняются в Hibernate.

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

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

надеюсь, что это помогает!

1