Hibernate Second-Level Query Cache nie działa Eager Fetching

Question

W NHibernate Profiler zauważyłem, że kiedy używam chętnego pobierania na skojarzenie, używając "left join fetch" w kwerendzie HQL lub .SetFetchMode() w Kryteriach Zapytanie zapytanie nr dłużej zostaje zbuforowane w pamięci podręcznej zapytań.

W rzeczywistości z tego, co widzę, tylko bardzo podstawowe zapytania są buforowane. Jeśli ktokolwiek może mi dać wgląd w to, jakie zapytania są buforowane, a które nie, zaznaczę odpowiedź.

Jeśli to robi jakąś różnicę, używam Memcached .... Czy jest lepszy wybór dla L2 Cache dla gęstego systemu zapytań?

Zauważyłem, że jest to dość trudne - jeśli nie używam sporego obciążenia, mam problem N + 1 (ale używa pamięci podręcznej), jeśli robię spore obciążenie, otrzymuję wszystkie jednostki z bazy danych, ale z bez buforowania.

Wygląda na to, że istnieje dość gruba linia podziału, obie strategie mają poprawę wydajności, ale obie strategie obrabiają wydajność z drugiej strategii.

Jeśli ktokolwiek może dać wgląd w to, gdzie na tej "grubej linii" powinienem mieć optymalną wydajność, lub jak "sprawić, że linia będzie cieńsza" ... Byłbym bardzo trudny i oznaczyć odpowiedź.

Answer 1

Aktualizacja: Proszę zobaczyć moje powiązane pytanie here. w dolnej linii jest, spróbuj użyć fetch = "select", aby uniknąć łączenia z obiektami, które są już w pamięci podręcznej drugiego poziomu.

---

Moje poprzednie odpowiedź (nadal mogą być przydatne)

cache zapytań buforuje identyfikatory wrócił z zapytaniem, a nie rzeczywistych obiektów

Aby używać go właściwie powinieneś

1. Użyj uchwytów miejsca (?lub: varName)
2. Set zapytanie cache true (zrobiłaś)
3. Kwerenda powinna powrócić obiektów, a nie właściwości (from Foo nie select foo.bar from Foo foo)
4. Zwracany obiekty powinny być w pamięci podręcznej poziomu 2 lub późniejsza połączenia są w tej samej sesji hibernacji (ta sama transakcja):

Aby wyjaśnić # 4, jeśli dwie różne transakcje uruchamiają dokładne (buforowane) zapytanie z dokładnymi parametrami i zwracają dokładnie ten sam obiekt, ale nie znajduje się on w Pamięć podręczna drugiego poziomu, trafienie bazy danych nadal będzie występować, aby uzyskać rzeczywiste obiekty (prawdopodobnie wybrane .. w)

cache zapytań jest przydatna dla 2 rzeczy - uniknąć ponownego trafienia bazy danych w tej samej transakcji zapytań HQL dla osób buforowanych elementów i umożliwiają wykorzystanie poziomu pamięci podręcznej obiektów 2nd zapytań HQL (automatycznie stosowanych w obciążeniu lub uzyskać poleceń)

Mam nadzieję, że oczyściłem las ...

Answer 2

Nie wiem o NHibernate, ale w trybie hibernacji należy jawnie włączyć buforowanie zapytań dla wskazówek dotyczących korzystania z zapytań. Pamięć podręczna L2 może automatycznie buforować poszczególne obiekty, ale w przypadku zapytań wymaga wyraźnych wskazówek.

Answer 3

Niezupełnie odpowiedź - raczej podpowiedź ... Zarówno pamięć podręczna kolekcji, jak i kwerenda nie zapisują wyników. Po prostu przechowują identyfikatory wynikowych jednostek. Jest to pamięć podręczna jednostki/klasy, która przechowuje dane jednostki.

Myśląc o tym - jeśli zapytanie zwraca wiele typów encji (tj. Niecierpliwe obciążenie), nie może rozsądnie przechowywać tablicy identyfikatorów, ponieważ istnieje relacja między tymi elementami. Uważam, że sama pamięć podręczna jest bardzo prostą strukturą.

Nie jestem pewien co do zapytań o wartości - tj. Takich, które używają rzutowań zamiast klas. Powiedziałbym, że nie możesz ich przechowywać w pamięci podręcznej. Ale mogę się mylić.

Teraz może to nie pomóc w Twoim problemie - istnieją inne techniki, które mogą. Mianowicie ładowanie wsadowe i właściwa pamięć podręczna jednostki. Byłbym ostrożny w przypadku buforowania kolekcji. Kilkakrotnie ugryzłem ich.

Nadzieję, że pomaga (przynajmniej trochę).