Будьте в спящем режиме Кэш Запроса Второго уровня, не работающий Нетерпеливая Выборка
В Профилировщике NHibernate я заметил, что, когда я использую нетерпеливую выборку на ассоциации, с помощью "оставленный, присоединяются к выборке" в Запросе HQL или.SetFetchMode () в Запросе Критериев, запрос больше не кэшируется в кэше запроса.
На самом деле от того, что я вижу только, очень простые запросы кэшируются. Если кто-либо может дать мне некоторое понимание, какие запросы кэшируются и которые не делают я отмечу ответ.
Если это имеет какое-либо значение, я использую Memcached.... Существует ли лучший выбор для Кэша L2 для плотной запросом системы?
Я нахожу это довольно сложным - если я не использую нетерпеливую загрузку, у меня есть проблема N+1 (но кэш использования), если я делаю нетерпеливую загрузку, я получаю все объекты от базы данных, но без кэширования.
Кажется, что существует вполне толстая разделительная линия, обе стратегии имеют повышения производительности, но обе стратегии грабят производительность из другой стратегии.
Если кто-либо может дать понимание, где abouts на этой 'толстой строке' я должен быть должен иметь оптимальную производительность, или как 'сделать разбавитель строки'... Я был бы очень gateful и отметил бы ответ.
3 ответа
Обновление: Пожалуйста, смотрите мой соответствующий вопрос здесь . Суть в том, что попробуйте использовать fetch="select", чтобы избежать объединения с объектами, которые уже находятся в кэше 2-го уровня.
Мой предыдущий ответ (все еще может быть полезным)
Кэш запросов кэширует идентификаторы, возвращенные из вашего запроса, а не фактические объекты
Чтобы использовать его правильно, вы должны
- Использовать place holders (? или :varName)
- Установить кэш запросов в true (вы сделали)
- Запрос должен возвращать объекты, а не свойства (
из Foo, а неselect foo. bar from Foo foo) - Возвращаемые объекты должны быть либо в кэше 2-го уровня, либо последующие вызовы находятся в той же самой спящей сессии (той же самой транзакции)
Для уточнения #4, если 2 разные транзакции выполнят точный (кэшированный) запрос с точными параметрами и вернут точно такой же объект, но его нет в кэше 2-го уровня, то все равно произойдет попадание в базу данных для получения реальных объектов (вероятно, select . . in )
Кэш запросов полезен для 2 вещей - избегайте повторного попадания в базу данных в той же самой транзакции для запросов HQL для некэшированных элементов и разрешайте использовать кэшированные объекты 2-го уровня для запросов HQL (автоматически используются при загрузке или получении команд)
Надеюсь, это очистило лес...
.I don't know about NHibernate, but in Hibernate, you have to explicitly enable query caching for a query use hints. L2 cache may cache individual objects automatically, but for queries it requires explicit directions.
На самом деле ответ - скорее подсказка.... Кэш коллекций и запросов на самом деле не хранит результаты. Они просто хранят идентификаторы результирующих сущностей. Именно в кэше сущностей/классов будут храниться данные сущности.
Так что подумайте об этом - если запрос возвращает несколько типов сущностей (т.е. нетерпеливую нагрузку), то он не может разумно хранить массив идентификаторов, так как между сущностями существует связь. Я считаю, что сам кэш - это очень простая структура.
Я не уверен насчет "стоимостных" запросов - т.е. таких, которые используют проекции вместо классов. Я бы сказал, что кэшировать их нельзя. Но, возможно, я ошибаюсь.
Сейчас, хотя это может и не помочь в вашем вопросе, но есть и другие техники, которые могут помочь. А именно, пакетная загрузка и правильное кэширование сущностей. Я был бы осторожен с кэшами коллекций. Меня несколько раз ими укусили.
Надеюсь, это поможет (хотя бы немного).
.