Dzisiejszy wpis poświęcony został jednemu z typów cache w Solr – filter cache. Postaram się przedstawić do czego służy, jak go skonfigurować i jak go optymalnie wykorzystywać. Zapraszam do lektury.
Co przechowuje
Zacznijmy od środka. FilterCache przechowuje nieuporządkowany zbiór identyfikatorów dokumentów. Oczywiście nie są to identyfikatory zdefiniowanie w pliku schema.xml jako unikalny klucz, a wewnętrzne identyfikatory dokumentów używane przez Lucene i Solr – warto o tym pamiętać.
Do czego służy
Głównym zadaniem filterCache jest przechowywanie wyników związanych z wykorzystaniem filtrów. Aczkolwiek nie jest to jego jedyne zastosowanie. Oprócz tego cache ten może służyć jako pomoc przy facetingu (w przypadku korzystania z metody TermEnum) oraz do sortowania w przypadku określenia opcji <useFilterForSortedQuery/> na true w pliku solrconfig.xml.
Definicja
Standardowa definicja filterCache wygląda następująco:
<filterCache
class="solr.FastLRUCache"
size="16384"
initialSize="4096"
autowarmCount="4096" />
Dostępne są następujące opcje konfiguracyjne:
- class – klasa odpowiadająca za implementację. Do filterCache polecam korzystanie z solr.FastLRUCache, który charakteryzuje się większą wydajnością w przypadku większej ilości operacji GET, niż PUT.
- size – maksymalna ilość wpisów jaka może znaleźć się w cache’u.
- initialSize – początkowa wielkość cache’u.
- autowarmCount – ilość wpisów jaka będzie przepisywana podczas rozgrzewania ze starego cache’u do nowego.
- minSize – wartość określająca do jakiej ilości wpisów Solr będzie próbował redukować cache w przypadku pełnego uzupełnienia.
- acceptableSize – jeżeli Solr nie będzie w stanie sprowadzić ilości wpisów do tej określonej za pomocą parametru minSize, to wartość acceptableSize będzie tą, do której będzie dążył jako kolejnej.
- cleanupThread – wartość domyślna to false. W przypadku ustawienia na true do czyszczenia cache’u będzie wykorzystywany oddzielny wątek.
W większości przypadków wykorzystanie parametrów size, initialSize oraz autowarmCount jest w zupełności wystarczające.
Jak skonfigurować
Wielkość cache’u powinna być określana na podstawie zapytań, które wysyłane są do Solr. Maksymalna wielkość filterCache powinna być przynajmniej tak duża jak ilość filtrów (wraz z wartościami) jaką wykorzystujemy. Oznacza to, że jeżeli nasza aplikacja charakteryzuje się, w zadanym okresie czasu, wykorzystaniem np. 2000 różnych filtrów (parametrów fq wraz z wartościami), to parametr size powinien być ustawiony na wartości minimum 2000.
Efektywne wykorzystanie
Jednak samo skonfigurowanie cache’u to nie koniec – ważne, aby zapytania potrafiły to wykorzystać. Weźmy na przykład zapytanie:
q=nazwa:solr+AND+kategoria:ksiazka+AND+dzial:ksiazki
Na pierwszy rzut oka zapytanie jest jak najbardziej poprawne. Jest z nim jednak jeden problem – nie korzysta z filterCache. Całe zapytanie zostanie obsłużone przez queryResultCache i stworzy w nim pojedynczy wpis. Zmodyfikujemy je trochę i zadajmy je w następujący sposób.
q=nazwa:solr&fq=kategoria:ksiazka&fq=dzial:ksiazki
Co się stanie teraz ? Tak jak w poprzednim wypadku, stworzony zostanie jeden wpis w queryResultCache oraz dwa wpisy w filterCache. Dlaczego jest to ważne ? Weźmy kolejne zapytanie:
q=nazwa:lucene&fq=kategoria:ksiazka&fq=dzial:ksiazki
To zapytanie stworzyłoby kolejny wpis w queryResultCache oraz wykorzystałoby dwa już istniejące w filterCache wpisy, a tym samym Solr skróciłbym czas wykonania zapytaniai oszczędziłby operacji I/O na indeksie.
Jeżeli natomiast wykonalibyśmy zapytanie w postaci:
q=nazwa:lucene+AND+kategoria:ksiazka+AND+dzial:ksiazki
Solr nie byłby w stanie wykorzystać żadnych informacji z cache’u i musiałby w celu zalezienia wyników pobierać wszystkie informacje z indeksu Lucene.
Kilka słów na koniec
Jak widać, samo skonfigurowanie cache’u w poprawny sposób nie gwarantuje tego, że Solr będzie w stanie go wykorzystać. To od tego jak zadajemy zapytania zależy, jak wydajny w docelowym wdrożeniu będzie Solr. Warto o tym pamiętać podczas planowania wdrożenia.