Hibernacja pamięci podręcznej drugiego poziomu w aplikacji Grails

Question

Hibernacja pamięci podręcznej drugiego poziomu w aplikacji Grails

Część I

W aplikacji Grails rozumiem, że włączasz 2. poziom pamięci podręcznej dla każdej klasy domeny, dodając

static mapping {
  cache true
}

Domyślnie bufor drugiego poziomu jest używany tylko wtedy, gdy wywołane jest get(), ale może być również używany do zapytań kryteriów i wyszukiwarek dynamicznych przez dodanie cache true do zapytania.

Jednak nadal nie jestem pewien, czy rozumiem, jak działa pamięć podręczna zapytań. Moim zdaniem:

istnieją oddzielne buforowania zapytań dla każdej klasy domeny, np. jedna dla Książki i inne dla autora
przed wykonaniem zapytania, takiego jak Author.findByName('bob', [cache: true]), klucz pamięci podręcznej jest obliczany na podstawie klasy domeny( Autor), zapytania (findByName) i parametrów zapytania ('bob'). Jeśli klucz ten znajduje się w buforze zapytań autora, zwracane są buforowane wyniki zamiast wykonywania zapytania

Wydaje się to rozsądne, dopóki nie uznamy, że zapytanie, które zwraca książkę instancje mogą dołączyć do tabeli autora. W takim przypadku konieczne byłoby opróżnienie pamięci podręcznej zapytań Książki i autora, gdy autor jest zapisywany, usuwany lub aktualizowany. To prowadzi mnie do podejrzeń, że być może istnieje tylko jedna pamięć podręczna zapytań i jest ona usuwana za każdym razem, gdy zapisywana jest jakaś buforowana klasa domeny?

Część II

W Grails docs wspomina, że

Jak również możliwość korzystania z pamięci podręcznej drugiego poziomu Hibernate do buforowania instancji można również buforować Kolekcje (skojarzenia) przedmiotów.

Na przykład:

class Author {    

  static hasMany = [books: Book]

  static mapping = { 
    cache true        // Author uses the 2nd level cache
    books cache: true // associated books use the 2nd level cache
  } 
}

class Book {
  static belongsTo = [author: Author]

  static mapping = {
    cache true // Book uses the 2nd level cache
  }
}

Czy powyższa konfiguracja ma sens, tzn. jeśli autor i książka używają pamięci podręcznej drugiego poziomu, czy jest jakaś korzyść, aby Stowarzyszenie Autor-książka również używało pamięci podręcznej drugiego poziomu?

Część III

W końcu przeczytałemtę radę o używaniu bufora zapytań drugiego poziomu, co sugeruje, że powinien być używany tylko do rzadkiej zmiany klas domeny. Są tam wszelkie okoliczności, w których nie należy włączać pamięci podręcznej drugiego poziomu dla operacji get(), tj. jakikolwiek powód, dla którego nie można dodać następujących do klasy domeny

static mapping = {
  cache true // Book uses the 2nd level cache
}

38

caching hibernate grails gorm

Author: Community, 2012-02-19

Source

1 answers

score 43 · Accepted Answer

Część 1:

Hibernate robi dobrze. Bufor zapytań nie jest przypadkowy na jednostkę. Istnieje jeden region pamięci podręcznej zapytań, współdzielony przez wszystkie zapytania, chyba że ustawiono konkretny region dla zapytania. Za każdym razem, gdy tabela jest aktualizowana, jej znacznik czasu w pamięci podręcznej znaczników czasu jest aktualizowany. Za każdym razem, gdy zapytanie jest wykonywane, znacznik czasu każdej z tabel, w których wyszukiwane jest zapytanie, jest porównywany ze znacznikiem czasu wyniku buforowanego. I oczywiście wynik buforowany jest zwracany tylko wtedy, gdy itstimestamp jest bardziej najnowsze niż wszystkie znaczniki czasu w tabeli.

Część 2:

Tak, to ma sens. Cache dla autora pamięta, że autor o ID 456 ma imię " foo " i datę urodzenia 1975/07/19. Zapamiętane są tylko dane zapisane w tabeli autor. Tak więc buforowanie asocjacji jest również przydatne: zamiast wykonywać dodatkowe zapytanie, aby uzyskać zestaw książek autora podczas wywoływania author.getBooks(), Hibernate pobierze identyfikatory książek autora ze swojej pamięci podręcznej, a następnie załaduje każdą książkę z pamięć podręczna drugiego poziomu. Upewnij się jednak, że przechowujesz książki.

Część 3:

Mogę sobie wyobrazić kilka powodów:

jest tak wiele jednostek i zmieniają się tak, że liczba trafień pamięci podręcznej byłaby bardzo niska, a obsługa pamięci podręcznej drugiego poziomu zajęłaby więcej czasu i pamięci niż rozwiązanie bez pamięci podręcznej
inne aplikacje nie hibernowane piszą do tej samej bazy danych, a pamięć podręczna wiąże się z dużym ryzykiem powrotu starych danych, co jest niedopuszczalne
wszystko idzie bardzo dobrze bez pamięci podręcznej drugiego poziomu i nie ma powodu, aby uczynić aplikację bardziej złożoną niż jest.