Problem

Kiedy documentCache włączony jest w konfiguracji, po pobraniu dokumentu z Lucene jest on umieszczany w pamięci i trzymany tam do chwili usunięcia z documentCache (czy to przez wielkość cache lub commit). Taka operacja może być dosyć kosztowna – szczególnie dla dużych dokumentów. Możemy wyobrazić sobie dokumenty, które reprezentują treść strony uzyskanej przez skanowanie tekstu z książki. Problem polega na tym, że każdy wpis w documentCache, jeżeli nie jest ponownie użyty kwalifikuje się jako śmieć. Im więcej śmieci tym więcej pracy musi wykonać garbage collector, a tym samym Solr traci cykle procesora na ten proces zamiast na obsługę zapytań i indeksowanie danych. Może się to oczywiście wiązać z gorszą wydajnością. Na szczęście, zaczynając od Solr 6.5 jesteśmy sobie w stanie z tym poradzić, przynajmniej dla dużych pól typu stored.

Oznaczenie pola jako large

Zaczynając od Solr 6.5 dostaliśmy możliwość dodania dodatkowego atrybutu do definicji pola. W przypadku, kiedy nasze pole tekstowe ustawione jest jako stored=”true” oraz multiValued=”false” możemy dodać do niego atrybut large przyjmujący wartości true lub false (domyślnie false). Tak zdefiniowane pole nie będzie automatycznie umieszczane w documentCache, a umieszczana będzie jedynie referencja do niego z możliwością późniejszego załadowania.

Sprawdźmy różnicę

Ze względu na to, że jest to wpis typu szybkie spojrzenie nie będziemy wgłębiać się w kod i szczegóły, a jedynie sprawdzimy dwie kolekcje z tymi samymi danymi i polami. Struktura kolekcji składać się będzie z następujących pól:

• id – identtyfikator dokumentu,
• name – nazwa dokumentu,
• body – treść dokumentu, która w założeniach może być bardzo duża.

Jedna z kolekcji będzie miała ustawiony atrybut large=”true” dla pola body. Dodatkowo zaindeksujemy kilka dokumentów w celu sprawdzenia zachowania się Solr w przypadku obu konfiguracji.

Jeżeli mielibyście ochotę przeprowadzić ten sam test, poniżej przedstawiamy komendy użyte do jego przeprowadzenia (wszystkie pliki pochodzą z naszego konta na Github (https://github.com/solrpl/). Test polegał będzie na stworzeniu kolekcji, zaindeksowaniu danych, zadaniu zapytania, zebraniu statystyk. Powtórzymy go dla każdej z kolekcji za każdym razem uruchamiają nową, pustą instancję Solr. Wykorzystane komendy wyglądają następująco:

$ mkdir /tmp/solr
$ mkdir /tmp/solr/collection_with_large
$ mkdir /tmp/solr/collection_without_large
$ wget https://github.com/solrpl/blog/tree/master/posts/large_field/data.xml /tmp/solr/data.xml
$ wget https://github.com/solrpl/blog/tree/master/posts/large_field/collection_with_large/managed-schema /tmp/solr/collection_with_large/managed-schema
$ wget https://github.com/solrpl/blog/tree/master/posts/large_field/collection_with_large/solrconfig.xml /tmp/solr/collection_with_large/solrconfig.xml
$ wget https://github.com/solrpl/blog/tree/master/posts/large_field/collection_without_large/managed-schema /tmp/solr/collection_without_large/managed-schema
$ wget https://github.com/solrpl/blog/tree/master/posts/large_field/collection_without_large/solrconfig.xml /tmp/solr/collection_without_large/solrconfig.xml
$ bin/solr zk upconfig -z localhost:9983 -n config_with_large -d /tmp/collection_with_large
$ bin/solr create_collection -c collection_with_large -n config_with_large -shards 1 -replicationFactor 1
$ curl -XPOST 'localhost:8983/solr/collection_with_large/update?commit=true' -H 'Content-Type:application/xml' --data-binary @/tmp/solr/data.xml
$ curl 'localhost:8983/solr/collection_with_large/select?q=*:*'

A teraz stwórzmy drugą kolekcję używają pobranych danych:

$ bin/solr zk upconfig -z localhost:9983 -n config_without_large -d /tmp/collection_without_large
$ bin/solr create_collection -c collection_without_large -n config_without_large -shards 1 -replicationFactor 1
$ curl -XPOST 'localhost:8983/solr/collection_without_large/update?commit=true' -H 'Content-Type:application/xml' --data-binary @/tmp/solr/data.xml
$ curl 'localhost:8983/solr/collection_without_large/select?q=*:*'

Sprawdźmy teraz, jak wygląda wykorzystanie documentCache oraz co można znaleźć w jego środku. Tak wygląda documentCache w przypadku kolekcji z polem body oznaczonym jako large=”true”:

A tak wygląda wykorzystanie documentCache z polem body bez oznaczenia jako large=”true”:

Jak łatwo zauważyć pole oznaczone jako large=”true” nie zostało dodane do documentCache bezpośrednio, a została dodana „leniwa” referencja, która może być wykorzystana w razie potrzeby. Pozwala to na zmniejszenie rozmiaru dokumentów umieszczonych w documentCache, a tym samym mniejsze obciążenie pamięci i mniej pracy dla garbage collectora, co powinno przełożyć się na trochę lepszą wydajność Solr.

Parametr cache=false

Ustawiając parametr cache na wartość false mówimy Solr, aby wyniki danego zapytania nie były zapisywanie w cache’u. Parametr ten może być także użyty w ramach filtra (fq) powodując to samo zachowanie – wynik działania filtra nie trafi do cache’u. Co na to daje ? Wyobraźmy sobie następujący filtr, jako część zapytania:

fq={!frange l=10 u=100}log(sum(sqrt(popularity),100))

Jeżeli wiemy, iż zapytania z tym filtrem zdarzają się sporadycznie, możemy zdecydować, iż nie chcemy tych informacji w cache’u, aby np. nie powodować zmiany jego stanu poprzez dodawanie zbędnych wpisów. Aby to zrobić dodajemy atrybut cache=false w następujący sposób:

fq={!frange l=10 u=100 cache=false}log(sum(sqrt(popularity),100))

Dodanie dodatkowego atrybutu spowoduje, że wynik zapytania nie będzie dodany do cache’u.

Parametr cost

Dodatkowa możliwość oferowana przez Solr 3.4 to określenie ciężaru, jaki niesie filtr w przypadku filtrów, których nie chcemy cache’ować. Filtry z określonym ciężarem wykonywane są na samym końcu, po wszystkich wcześniejszych filtrach. Sam koszt określamy podając liczbę całkowitą jako wartość atrybutu cost. Weźmy na przykład następujący fragment zapytania:

fq=cat:video&fq={!cache=false cost=50}productGroup:12&fq={!frange l=10 u=100 cache=false cost=150}log(sum(sqrt(popularity),100))

Na początku zostanie wykonany filtr fq=cat:video ze względu na to, że jego zawartość trafi do cache’u. Następnie zostanie wykonany filtr z mniejszą wartością parametru cost, czyli filtr fq={!cache=false cost=50}. Na sam koniec Solr zostawi sobie najbardziej kosztowny filtr. Dodatkowo ostatni filtr zostanie nałożony tylko na dokumenty, które pasują do zapytania i wszystkich pozostałych filtrów (ze względu na to, że atrybut cost wynosi więcej, niż 100).

Należy pamiętać, że atrybut cost działa tylko wtedy, kiedy filtr nie jest cache’owany.

Podsumowanie

Parametry cache oraz cost pozwalają na kontrolę tego co umieszczane jest w cache’u Solr, co jest przydatne wtedy kiedy wiemy jakie zapytania zadawane są do naszych instancji Solr. Co więcej, w przypadku korzystania z obu z nich jesteśmy w stanie poprawić wydajność niektórych zapytań, szczególnie tych z atrybutem cost większym, niż 100. Warto więc przyjrzeć się swoim zapytaniom i zastanowić się, czy na pewno chcemy cacheować wszystkie wykorzystywane filtry

Co przechowuje

Utrzymując strukturę poprzedniego wpisu, zacznijmy od środka. Tak więc, documentCache, przechowuje dokumenty Lucene, które zostały pobrane z dysku. Tylko tyle i aż tyle.

Do czego służy

Każdy obiekt (dokument Lucene) przechowywany w documentCache zawiera listę referencji do pól, jakie posiada dany dokument. Dzięki temu, raz pobrany dokument z indeksu, jeżeli jest obecny w documentCache nie musi być po raz kolejny pobierany przy kolejnym zapytaniu. W związku z tym, podczas budowania listy wyników wyszukiwania, liczba operacji I/O jest zmniejszana.

O czym należy pamiętać ?

Korzystając z documentCache należy pamiętać o dwóch dość ważnych rzeczach:

1. documentCache nie może być automatycznie odświeżany ze względu na to, iż operuje na identyfikatorach, które zmieniają się po każdej operacji commit.
2. W przypadku, kiedy używamy lazyFieldLoading, (czyli ustawienie enableLazyFieldLoading na true) funkcjonalność documentCache jest ograniczona. Oznacza to, że dokument zapisany w cache będzie posiadał tylko te pola, które zostały podane w parametrze fl. Jeżeli w późniejszym czasie Solr trafi na ten dokument w cache, pola, które wcześniej nie były wczytane, zostaną dynamicznie odczytane z indeksu.

Definicja

Standardowa definicja documentCache  wygląda następująco:

<documentCache
      class="solr.FastLRUCache"
      size="16384"
      initialSize="16384"/>

Przypomnijmy sobie poszczególne parametry:

• class – klasa odpowiedzialna za implementację,
• size – maksymalna wielkość,
• initialSize – początkowa wielkość.

Jak skonfigurować

Odwieczna odpowiedź w przypadku wielkości cache’u. Jak duży powinien być. Zgodnie z tym co jest napisane na wiki Solr (http://wiki.apache.org/solr/SolrCaching#documentCache), maksymalna wielkość nie powinna być mniejsza niż iloczyn liczby równoległych zapytań i maksymalnej liczby dokumentów pobieranych przez zapytania. Dość prosta zależność, która zagwarantuje, że Solr nie będzie musiał ponownie pobierać dokumentów podczas przetwarzania zapytania.

Kilka słów na koniec

W odróżnieniu od filterCache, w przypadku documentCache nie musimy martwić się o to, jak konstruujemy zapytania, aby dobrze wykorzystać ten cache. Należy jednak pamiętać, iż documentCache wymaga tym więcej pamięci, im więcej pól przechowywanych jest w indeksie.

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.

Na początek

Aby zacząć mówić o konfiguracji parametru należy najpierw powiedzieć w jaki sposób Solr pobiera wyniki za pomocą biblioteki Lucene. Przekazując, wraz z zapytaniem do Solr, parametr rows z wartością np. 20 określamy, iż chcemy aby Solr zwrócił listę wyników składającą się maksymalnie z 20 dokumentów i tyle właśnie widzimy na wynikowej liście. Jednak ilość wyników, jaka została pobrana z indeksu jest różna i określona jest właśnie parametrem queryResultWindowSize. To ten parametr, zapisany w pliku solrconfig.xml, określa jak dużo wyników zostanie pobranych z indeksu i przechowanych w queryResultCache.

Ale do czego służy queryResultWindowSize ?

Parametr queryResultWindowSize określa wielkość, tzw. okna wyników, czyli po prostu ilość dokumentów jaka zostanie pobrana przy pobieraniu wyników wyszukiwania.  Na przykład ustawiając queryResultWinwdowSize na wartość 100 i zadając zapytanie:

q=car&rows=30&start=10

na liście wyników wyszukiwania otrzymamy maksymalnie 20 dokumentów wynikowych, natomiast sam Solr pobierze tak naprawdę wyniki zaczynające się od indeksu 0, a kończące się na indeksie 100, a następnie spróbuje je umieścić w queryResultCache. Wyniki wyszukiwania kolejnych zapytań, różniących się jedynie parametrami rows i start będą mogły być pobierane z queryResultCache.

Konfiguracja

Aby ustawić queryResultWindowSize na pokazaną w powyższym przykładzie wartość 100, należy do pliku solrconfig.xml dodać następujący wpis:

<queryResultWindowSize>100</queryResultWindowSize>

O czym należy pamiętać ?

Oczywiście samo ustawienie queryResultsWindowSize to nie jest wszystko. Należy jeszcze zapewnić odpowiednią ilość miejsca w queryResultCache, aby Solr miał możliwość przechowania koniecznych informacji. Natomiast sama konfiguracja queryResultCache to już temat na inny artykuł.

Ale po co korzystać ?

Odpowiedź na tak postawione pytanie jest całkiem proste – jeżeli Twoja aplikacja i Twoi użytkownicy często korzystają ze stronicowania rozsądnym będzie rozważenie zmiany domyślnej wartości queryResultWindowSize. W większości wypadków, gdzie wdrożenia opierały się na stronicowaniu, zmiana wartości omawianego parametru powodowała zwiększenie wydajności ciężkich zapytań przy przechodzeniu pomiędzy stronami wyników.