Solr 6.5 i pola typu large – szybkie spojrzenie

Jak wiadomo Solr posiada różne możliwości jeżeli chodzi o cachowanie danych – filterCache dla filtrów, queryResultCache dla wyników zapytań oraz documentCache do cachowania zapytań do szybkiego ich pobierania. Skupimy się dzisiaj na tym ostatnim i co możemy zrobić, aby wykorzystać go bardziej optymalnie.

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:

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

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.

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.