Kilka słów o optymalizacji – filter cache

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:

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:

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.

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:

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:

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.

One thought on “Kilka słów o optymalizacji – filter cache

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.