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.

Trochę teorii

W przypadku kiedy nasz indeks składa się z dużej ilości pól oznaczonych jako stored mogą one stanowić nawet większą część miejsca zajmowanego przez indeks. Skąd wiedzieć ile zajmują pola typu stored ? Wystarczy spojrzeć do katalogu z indeksem i policzyć ile zajmują pliki z rozszerzeniem .fdt. Pomimo tego, że duża ilość pól tego typu nie wpływa bezpośrednio na wydajność Solr, to jednak wielkość indeksu wpływa na to jak zachowuje się cache I/O, a tym samym, im większy indeks, tym bardziej prawdopodobne, że będziemy mieli dość dużo operacji odczytu, a tym samym nasze zapytania będą wykonywane wolniej. Do tego, ze względu na to, że musimy zapisać więcej danych – indeksowanie także będzie wolniejsze.

Wraz z Lucene 4.1 pola oznaczone jako stored będą kompresowane algorytmem LZ4 (http://code.google.com/p/lz4/), który powinien znacznie zmniejszyć wielkość indeksu, gdy korzystamy z dużej ilości tego typu pól, a jednocześnie nie powinien mocno obciążać maszyny podczas wykonywania kompresji.

Dane testowe

Do testów wykorzystaliśmy dane polskiej wikipedii z dnia 2012.11.10 zawierające artykuły (http://dumps.wikimedia.org/plwiki/20121110/plwiki-20121110-pages-articles.xml.bz2). Rozpakowany plik XML z danymi zajmował około 4.7GB.

Struktura indeksu

Następująca struktura indeksu została przygotowana, aby zaindeksować powyższe dane:

<field name="id" type="string"  indexed="true" stored="true" required="true"/>
<field name="title" type="text" indexed="true" stored="true"/>
<field name="revision" type="int" indexed="true" stored="true"/>
<field name="user" type="string" indexed="true" stored="true"/>
<field name="userId" type="int" indexed="true" stored="true"/>
<field name="text" type="text" indexed="true" stored="true"/>
<field name="timestamp" type="date" indexed="true" stored="true"/>
<field name="_version_" type="long" indexed="true" stored="true"/>

Konfiguracja DIH

Konfiguracja DIH użyta do importu danych Wikipedii wyglądała następująco:

<dataConfig>
 <dataSource type="FileDataSource" encoding="UTF-8" />
 <document>
  <entity name="page" processor="XPathEntityProcessor" stream="true" forEach="/mediawiki/page/" url="/home/data/wikipedia/plwiki-20121110-pages-articles.xml" transformer="RegexTransformer,DateFormatTransformer">
   <field column="id" xpath="/mediawiki/page/id" />
   <field column="title" xpath="/mediawiki/page/title" />
   <field column="revision" xpath="/mediawiki/page/revision/id" />
   <field column="user" xpath="/mediawiki/page/revision/contributor/username" />
   <field column="userId" xpath="/mediawiki/page/revision/contributor/id" />
   <field column="text" xpath="/mediawiki/page/revision/text" />
   <field column="timestamp" xpath="/mediawiki/page/revision/timestamp" dateTimeFormat="yyyy-MM-dd'T'hh:mm:ss'Z'" />
   <field column="$skipDoc" regex="^#REDIRECT .*" replaceWith="true" sourceColName="text"/>
  </entity>
 </document>
</dataConfig>

Czas indeksowania

Czas indeksowania był bardzo podobny w obu przypadkach dla tej samej liczby dokumentów, dokładnie było ich 1.301.394. W przypadku Solr 4.0 czas indeksowania wyniósł 14 minut i 33 sekundy, w przypadku Solr 4.1 wyniósł 14 minut i 43 sekundy. Zatem Solr 4.1 był minimalnie wolniejszy, a ze względu na to, że test był wykonywany na moim laptopie, można przyjąć iż wydajność indeksowania będzie podobna.

Wielkość wynikowego indeksu

Wielkość indeksu, czyli to co nas najbardziej interesuje. W przypadku Solr 4.0 indeks, który powstał w wyniku zaindeksowania danych miał około 5.1GB, czyli dokładnie 5.464.809.863 bajtów. W przypadku Solr 4.1 rozmiar indeksu wyniósł około 3.24GB, czyli dokładnie 3.480.457.399 bajtów. Zatem porównyjąc indeks stworzony przez Solr 4.0 do indeksu stworzonego przez Solr 4.1 zyskaliśmy około 35% miejsca na dysku.

Podsumowanie

Widać jak na dłoni, iż zysk z kompresowania pól oznaczonych jako stored jest duży. Pomimo tego, iż potrzebna jest dodatkowa moc procesora na kompresję i dekompresję danych, zysk polegający na zmniejszeniu obciążenia I/O będzie większy, niż strata cykli procesora. Nie dziwię się zatem, iż kompresja pól oznaczonych jako stored jest włączona domyślnie w Lucene 4.1, a zatem i w Solr 4.1. Jeżeli jednak chcielibyśmy wyłączyć to zachowanie, na chwilę obecną konieczna jest własna implementacja odpowiedniego codec’a, który nie korzysta z kompresji. Jednak aby skorzystać z własnego formatu indeksu nie musimy utrzymywać własnej wersji Lucene, co znów pokazuje potęgę codec’ów wprowadzonych wraz z Lucene 4.0.

Konfiguracja

Zacznijmy od konfiguracji komponentu, która jest standardowa jeżeli chodzi o Solr. Do pliku schema.xml dodajemy po prostu kolejny wpis, np. w takiej postaci:

<fieldType class="solr.CurrencyField" name="currencyField" defaultCurrency="USD" currencyConfig="currencyExchange.xml" />

W powyższej konfiguracji typu pojawiają się dwa dodatkowe atrybutu, które określają zachowanie pól typu currencyField. Po pierwsze to parametr defaultCurrency, który określa domyślną walutę dla pola. Raz zdefiniowany określa w jakiej formie dane będą zapisywane w indeksie (zmiana wartości wymaga reindeksacji danych). Drugi atrybut, currencyConfig określa plik z kursami wymiany pomiędzy walutami. Warto pamiętać, iż parametr ten ma sens tylko dla domyślnego providera wymiany (FileExchangeRateProvider) dostarczanego z Solr. Przyjrzyjmy się zatem plikowi currencyExchange.xml:

Plik definicji wymiany walut dla FileExchangeRateProvider

Poniżej przedstawiam zawartość pliku currencyExchange.xml zawierającego przykładowe przeliczniki kursów walut dla domyślnego providera wymiany dostarczanego razem z Solr.

<currencyConfig version="1.0">
 <rates>
  <rate from="USD" to="PLN" rate="3.1"/>
  <rate from="EUR" to="PLN" rate="2.5"/>
  <rate from="USD" to="EUR" rate="2.5"/>
 </rates>
</currencyConfig>

Jak widać plik ma dość prostą strukturę, podajemy walutę wejściową (from), walutę wyjściową (to) oraz przelicznik (rate). Nic prostszego

Indeksowanie danych

Aby poprawnie zaindeksować dane zawierając nasz zdefiniowany typ currencyField należy podać wartość, a następnie symbol waluty oddzielony przecinkiem. Na przykład:

<field name="price">21.99,EUR</field>

Zadawanie zapytań

Zadawanie zapytań wygląda analogicznie do indeksowania. Oprócz samej informacji o wartościach musimy także przekazać informację o walucie na jakiej Solr ma dokonywać operacji. Poniżej przykłady wykorzystujące filtrowanie po wartości oraz przedziale wartości:

fq=price:29.99,PLN

fq=price:[10.00 TO 29.99,EUR]

Jak widać, po podaniu interesujących nas wartości dodajemy przecinek, a następnie podajemy oznaczenie waluty. Co więcej, możemy skorzystać z walut zdefiniowanych wcześniej w pliku wymiany. Oznacza to, że Solr może za nas dokonać automatycznej zamiany Pomimo możliwości automatycznej zmiany wyszukiwanej waluty wyniki zwracane są zawsze w tej zdefiniowanej jako domyślna i na razie nie ma możliwości zmiany tego zachowania.

Własny provider wymiany walut

Solr, oprócz domyślnego provider’a wymiany walut, umożliwia napisanie własnego. Aby to zrobić musimy stworzyć klasę implementującą interfejs org.apache.solr.schema.ExchangeRateProvider oraz podać naszą klasę w jako wartość atrybutu providerClass dla zdefiniowanego typu. Zakładając, iż mamy klasę pl.solr.schema.DynamicRateExchangeProvider implementującą w/w interfejs i chcemy z niej skorzystać, definicja typu mogłaby wyglądać następująco:

<fieldType class="solr.CurrencyField" name="currencyField" defaultCurrency="USD" providerClass="pl.solr.schema.DynamicRateExchangeProvider" />

Osobiście bardzo podoba mi się ta możliwość, ponieważ zyskujemy możliwość dynamicznego pobierania kursów wymiany np. poprzez webservice.

Co zostało do implementacji

W chwili pisania i publikacji tego wpisu, pola typu CurrencyField nie są obsługiwane w przypadku facetingu po zakresach.

Podsumowanie

Moim zdaniem CurrencyField jest całkiem ciekawą funkcjonalnością uwalniającą nas od przeliczania waluty po stronie aplikacji. Zamiast tego, w Solr 3.6, otrzymamy narzędzie, które umożliwi nam wyszukiwanie z automatycznym przeliczaniem waluty po stronie Solr. Dodatkowo, jeżeli pokusimy się o implementację własnego mechanizmu dostarczania przeliczników wymiany możemy otrzymać całkiem fajny w użyciu mechanizm, który sam pobierze waluty z odpowiadającego nam źródła, sam będzie je dynamiczne przeliczał, a nam zostanie tylko zadawanie zapytań

Na początek mała informacja, FieldCollapsing dostępny jest tylko w wersji 4.0, czyli w wersji rozwojowej kodu projektu Solr i raczej mało prawdopodobnym jest przeniesienie tej funkcjonalności do wersji 3.X.

FieldCollapsing, czyli co ?

Wyobraźmy sobie, iż nasz indeks zawiera informacje o firmach z różnych miast. Chcemy pokazać użytkownikowi po jednej (lub np. dwie, czy trzy) firmie z każdego miasta, oczywiście firmie spełniającej kryteria wyszukiwania. W jaki sposób tego dokonać – wykorzystać właśnie mechanizm FieldCollapsing. Pozwala on na grupowanie zwróconych w wyników wyszukiwania na podstawie zawartości pól. Wyniki wyszukiwania mogą być zgrupowane do pojedynczego dokumentu, bądź stałej ich ilości.

Parametry

Podobnie, jak w przypadku większości funkcjonalności dostępnych w Solr, tak samo zachowanie mechanizmu FieldCollapsing można konfigurować szeregiem parametrów, oto one:

• group – analogicznie do np. facetingu ustawienie tego parametru na wartość true włącza mechanizm FieldCollapsing. Wartość domyślna parametru to false.
• group.field – określenie na podstawie jakiego pola ma się odbywać grupowanie.
• group.func – określenie funkcji, na podstawie wyniku której będzie odbywać się grupowanie.
• group.limit – ilość wyników jaka ma być zwrócona w poszczególnych grupach. Domyślna wartość parametru to 1.
• group.sort – parametr określający w jaki sposób sortować dokumenty w ramach grup. Wartość domyślna, to wartość score desc.

Warto podkreślić, iż parametr rows przekazywany do zapytania będzie określał ilość grup jaka ma zostać zwrócona w wynikach wyszukiwania, a nie ilość pojedynczych dokumentów. Zmienia się także zachowanie parametru sort. Parametr ten będzie sortował grupy wyników, a nie poszczególne dokumenty. Grupy będą sortowane na podstawie zawartości pól pierwszych dokumentów tworzących grupy.

Wyniki wyszukiwania

Wyniki wyszukiwania różnią się od tych do których jesteśmy przyzwyczajeni. Są one pogrupowane według parametrów, które przekazaliśmy. Głównym elementem wyników wyszukiwania nie są już poszczególne dokumenty, a grupy dokumentów. Dopiero w ramach grup pokazywane są dokumenty (ich ilość definiuje parametr group.limit). Na przykład, zadając zapytanie:

http://localhost:8983/solr/select/?q=*:*&group=true&group.field=inStock&indent=true

do indeksu, który powstał poprzez zaindeksowanie wszystkich dokumentów w formacie XML z katalogu exampledocs przykładowego wdrożenia dostarczanego z Solr, otrzymujemy następujący wynik:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="group.field">inStock</str>
    <str name="group">true</str>
    <str name="indent">true</str>
    <str name="q">*:*</str>
  </lst>
</lst>
<lst name="grouped">
  <lst name="inStock">
    <int name="matches">19</int>
    <arr name="groups">
     <lst>
        <str name="groupValue">T</str>
        <result name="doclist" numFound="15" start="0">
          <doc>
            <arr name="cat"><str>electronics</str><str>hard drive</str></arr>
            <arr name="features"><str>7200RPM, 8MB cache, IDE Ultra ATA-133</str><str>NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</str></arr>
            <str name="id">SP2514N</str>
            <bool name="inStock">true</bool>
            <str name="manu">Samsung Electronics Co. Ltd.</str>
            <date name="manufacturedate_dt">2006-02-13T15:26:37Z</date>
            <str name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</str>
            <int name="popularity">6</int>
            <float name="price">92.0</float>
            <str name="store">45.17614,-93.87341</str>
            <double name="store_0_d">45.17614</double>
            <double name="store_1_d">-93.87341</double>
            <str name="store_lat_lon">45.17614,-93.87341</str>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">F</str>
        <result name="doclist" numFound="4" start="0">
          <doc>
            <arr name="cat"><str>electronics</str><str>connector</str></arr>
            <arr name="features"><str>car power adapter, white</str></arr>
            <str name="id">F8V7067-APL-KIT</str>
            <bool name="inStock">false</bool>
            <str name="manu">Belkin</str>
            <date name="manufacturedate_dt">2005-08-01T16:30:25Z</date>
            <str name="name">Belkin Mobile Power Cord for iPod w/ Dock</str>
            <int name="popularity">1</int>
            <float name="price">19.95</float>
            <str name="store">45.17614,-93.87341</str>
            <double name="store_0_d">45.17614</double>
            <double name="store_1_d">-93.87341</double>
            <str name="store_lat_lon">45.17614,-93.87341</str>
            <float name="weight">4.0</float>
          </doc>
        </result>
      </lst>
    </arr>
  </lst>
</lst>
</response>

Na koniec

Ciekawa funkcjonalność, która na pewno znajdzie zastosowania w niektórych wdrożeniach. Należy jednak pamiętać, iż funkcjonalność ta będzie jeszcze rozwijana. Jak na razie nie ma wsparcia m.in. dla wyszukiwania rozproszonego, czy grupowania po polach wielowartościowych. W tym momencie nie ma sensu przeprowadzanie też testów wydajnościowych, po pierwsze ze względu na zmiany jakie zajdą w samym mechanizmie, a po drugie ze względu na to, iż jest to mocno rozwojowa wersja Lucene i Solr. Niemniej jednak, na pewno będę miał opisywaną funkcjonalność na oku