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.

Po co mi taka funkcjonalność ?

Do tej pory, praktycznie, nie mieliśmy możliwości wpływania na to, jak budowane były odpowiedzi zwracane przez Solr. Wraz z pojawieniem się wersji 4.0 Solr dostaniemy do ręki nowe narzędzie, tzw. DocTransformers. Funkcjonalność ta pozwala na modyfikację pól w wynikach wyszukiwania zwróconych przez Solr. Patrząc na to, co w tym momencie jest dostępne, mamy na przykład możliwość zamiany nazw zwracanych pól, czy oznaczenia elementów dodawanych przez QueryElevationComponent. W tym momencie nie jest tego dużo, natomiast implementacja własnego DocTransformer’a nie jest trudna, o czym za chwilę.

Co jest już dostępne

W tym momencie, w wersji 4.0 Apache Solr dostępne są następujące funkcjonalności związane z DocTransformer’ami:

• Możliwość oznaczenia, które dokumenty zostały dodane przez QueryElevationComponent.
• Możliwość dodania informacji explain do dokumentu.
• Możliwość dodania stałej wartości jako pola do dokumentu.
• Możliwość dodania informacji o shardzie z jakiego pochodzi danych dokument.
• Możliwość dodania informacji docid jako pola dokumentu (identyfikator wykorzystywany przez Lucene).

Jak z tego skorzystać ?

Sprawdźmy, jak wygląda wykorzystanie tej funkcjonalności. Do tego celu pobrałem najnowszą wersję Apache Solr z repozytorium i uruchomiłem przykładowe wdrożenie. Następnie zaindeksowałem przykładowe dane i zadałem następujące zapytanie:

http://localhost:8983/solr/select?q=encoded&fl=name,score,[docid],[explain]

W powyższym zapytaniu warto przyjrzeć się parametrowi fl. Oprócz informacji takich, jak pole name oraz wartość score powiedzieliśmy Solr, że chcemy, aby do wygenerowania wyników wyszukiwania zostały wykorzystane dwa DocTransformery: [docid] oraz [explain]. W odpowiedzi Solr wygenerował następującego XML’a:

<?xml version="1.0" encoding="UTF-8"?>
<response>
 <lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">2</int>
  <lst name="params">
    <str name="q">encoded</str>
    <str name="fl">name,score,[docid],[explain]</str>
  </lst>
 </lst>
 <result name="response" numFound="2" start="0" maxScore="0.50524884">
 <doc>
  <str name="name">Test with some GB18030 encoded characters</str>
  <float name="score">0.50524884</float>
  <int name="[docid]">0</int>
  <str name="[explain]">
  0.50524884 = (MATCH) weight(text:encoded in 0) [DefaultSimilarity], result of:
    0.50524884 = score(doc=0,freq=1.0 = termFreq=1), product of:
      1.0000001 = queryWeight, product of:
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.3092536 = queryNorm
      0.5052488 = fieldWeight in 0, product of:
        1.0 = tf(freq=1.0), with freq of:
          1.0 = termFreq=1
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.15625 = fieldNorm(doc=0)
  </str>
 </doc>
 <doc>
  <str name="name">Test with some UTF-8 encoded characters</str>
  <float name="score">0.4041991</float>
  <int name="[docid]">25</int>
  <str name="[explain]">
  0.4041991 = (MATCH) weight(text:encoded in 25) [DefaultSimilarity], result of:
    0.4041991 = score(doc=25,freq=1.0 = termFreq=1), product of:
      1.0000001 = queryWeight, product of:
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.3092536 = queryNorm
      0.40419903 = fieldWeight in 25, product of:
        1.0 = tf(freq=1.0), with freq of:
          1.0 = termFreq=1
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.125 = fieldNorm(doc=25)
  </str>
 </doc>
</result>
</response>

Jak widać, Solr dołączył do wyników wyszukiwania to o co go prosiliśmy.

Własna implementacja

Omówmy, jak wygląda implementacja własnego DocTransfomer’a. Poniżej, przykład klasy RenameFieldsTransformer z pakietu org.apache.solr.response.transform. Ogólnie polega to na implementacji następujących metod z klasy DocTransformer z pakietu org.apache.solr.response.transform:

• String getName() – metoda zwracająca nazwę transformera,
• void transform(SolrDocument doc, int docid) – metoda dokonująca transformacji.

Sama implementacja wygląda następująco:

public class RenameFieldsTransformer extends DocTransformer {
 final NamedList<String> rename;

 public RenameFieldsTransformer( NamedList<String> rename ) {
  this.rename = rename;
 }

 @Override
 public String getName() {
  StringBuilder str = new StringBuilder();
  str.append( "Rename[" );
  for( int i=0; i< rename.size(); i++ ) {
   if( i > 0 ) {
    str.append( "," );
   }
   str.append( rename.getName(i) ).append( ">>" ).append( rename.getVal( i ) );
  }
  str.append( "]" );
  return str.toString();
 }

 @Override
 public void transform(SolrDocument doc, int docid) {
  for( int i=0; i<rename.size(); i++ ) {
   Object v = doc.remove( rename.getName(i) );
   if( v != null ) {
    doc.setField(rename.getVal(i), v);
   }
  }
 }
}

Powyższy kod umożliwia zwrócenie pola o innej nazwie, niż ta, która została zaindeksowana. Metoda transform iteruje po wszystkich wartościach zmiennej rename, która zawiera nazwę pól, które mają zostać zmienione wraz z nazwami na jakie powinny zostać zamienione. Należy pamiętać, iż, aby nasz własny transformer zaczął działać, należy dodać go do pliku solrconfig.xml. Oto przykład w wiki Solr:

<transformer name="elevated" class="org.apache.solr.response.transform.EditorialMarkerFactory" />

Podsumowując

Należy pamiętać, iż opisywana funkcjonalność jest oznaczona jako eksperymentalna i jej działanie może się zmienić w stosunku do opisywanego w chwili publikacji wersji 4.0 Solr i Lucene. Na pewno wrócimy do tematu po ukazaniu się Solr 4.0.

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.