Drastycznych różnic możesz się spodziewać, jeśli buforujesz to, co jest dobre do buforowania i unikasz buforowania danych, które w ogóle nie powinny być buforowane. Jak piękno jest w oku patrzącego, tak samo jest z przedstawieniem. Oto kilka aspektów, o których należy pamiętać podczas korzystania z dostawcy pamięci podręcznej drugiego poziomu hibernacji AS:
Brak niestandardowej serializacji – intensywnie wykorzystujące pamięć
Jeśli używasz buforowania drugiego poziomu, nie będziesz w stanie korzystać z szybkich frameworków serializacji, takich jak Kryo i będziesz musiał trzymać się serializacji java, która jest do niczego.
Oprócz tego dla każdego typu jednostki będziesz mieć osobny region, aw każdym regionie będziesz mieć wpis dla każdego klucza każdej jednostki. Pod względem wydajności pamięci jest to nieefektywne.
Brak możliwości przechowywania i dystrybucji bogatych obiektów
Większość nowoczesnych pamięci podręcznych oferuje również funkcjonalność siatki obliczeniowej, w której obiekty są podzielone na wiele małych części, co zmniejsza Twoją zdolność do wykonywania rozproszonych zadań z gwarantowaną kolokacją danych. To zależy trochę od dostawcy sieci, ale dla wielu byłoby to ograniczenie.
Suboptymalna wydajność
W zależności od wymaganej wydajności i typu aplikacji, korzystanie z hibernacji pamięci podręcznej drugiego poziomu może być dobrym lub złym wyborem. Dobre pod względem tego, że jest typu plug and play..." trochę..." złe, ponieważ nigdy nie wyciśniesz wydajności, którą byś zyskał. Również projektowanie bogatych modeli oznacza więcej pracy z góry i więcej OOP.
Ograniczone możliwości zapytań w samej pamięci podręcznej
To zależy od dostawcy pamięci podręcznej, ale niektórzy dostawcy naprawdę nie są dobrzy w wykonywaniu JOIN z klauzulą Where inną niż ID. Jeśli spróbujesz zbudować indeks w pamięci dla zapytania na przykład Hazelcast, zobaczysz, o co mi chodzi.
