IDF i Solr

Wraz z premierą Lucene i Solr 6.0 domyślny algortym odpowiadający za score TF/IDF został zastąpiony algorytmem BM25, który powinien spisywać się lepiej ze względu na ograniczenia związane z maksymalnym wpływem częstotliwości termu.

W algorytmie BM25 współczynnik IDF obliczany jest w następujący sposób:

log(1 + (docCount - docFreq + 0.5)/(docFreq + 0.5))

Oznacza to, iż wartość IDF jest dużo szybciej i mocniej ograniczana w przypadku często występujących termów porównując to algorytmu TF/IDF obecnego przez we wcześniejszych wersjach Lucene i Solr.

Problemem jest to, iż informacja ja, domyślnie nie jest rozproszona. Oznacza to, że każdy shard przechowuje te informacje powodując, iż im bardziej kolekcja jest rozproszona, tym mniejsza dokładność. W większości przypadków nie jest to problem, jednak są takie gdzie jest to jednak coś, czym zaczynamy się przejmować. Dodatkowo, zmiany w architekturze kolekcji powodują zmiany w wyliczanym współczynniku score, nawet przy tych samych dokumentach. Jest to czasem niedopuszczalne.

Rozproszone IDF

Wraz z Solr 5.0 wprowadzona została możliwość skonfigurowania Solr do korzystania z rozproszonego obliczania IDF. Wystarczy do pliku solrconfig.xml dodać definicję statsCache i to wszystko. Na przykład:

<statsCache class="org.apache.solr.search.stats.ExactStatsCache" />

Proste prawda? Spójrzmy zatem jakie mamy opcje jeżeli chodzi o implementację:

LocalStatsCache – domyślna implementacja, kiedy nie mamy zdefiniowanego elementu statsCache w pliku solrconfig.xml. W tym wypadku sytuacja jest bardzo prosta – brak rozproszonego obliczania współczynnika IDF.

ExactStatsCache – implementacja cacheująca statystyki dotyczące termów wymagająca dodatkowego kroku podczas przetwarzania zapytania, tak aby zapytanie było analizowane na każdym shardzie wchodzącym w skład kolekcji. Może skutkować spadkiem wydajności zapytań ze względu na dodatkowe operacje.

ExactSharedStatsCache – implementacja podobna do opisywanej powyżej z tą różnicą, iż statystki są współdzielone pomiędzy żądaniami. Może skutkować większą wydajnością, niż ExactStatsCache, ale cechować go będzie większe wykorzystanie pamięci.

LRUStatsCache – w odróżnieniu do ExactStatsCache implementacja przechowująca statystyki dotyczące termów w LRU cache. Bazując na informacjach w cache’u Solr jest w stanie określić, czy dodatkowe zapytania są potrzebne tym samym zmniejszając ich częstotliwość, a tym samym zwiększając wydajność zapytań. Termy przechowywane są w mapach – liczba map determinowana jest liczbą shardów z których składa się kolekcja – map będzie tyle, ile jest shardów, a każdy shard trzyma jedną mapę ze statystykami termów.

Czy to działa?

Na tak postawione pytanie możemy odpowiedzieć tylko – trzeba to po prostu sprawdzić. W tym celu stworzymy dwie kolekcje distrib_idf oraz non_distrib_idf oraz zaindeksujemy przykładowe dane (konfigurację i dane można znaleźć na naszym Githubie – https://github.com/solrpl/blog). Każda z kolekcji będzie miała dwa shardy, jedną replikę, a sam klaster SolrCloud będzie składał się z dwóch instancji Solr.

Po zaindeksowaniu kilku przykładowych dokumentów możemy sprawdzić różnicę w wyliczaniu score zadając następujące zapytanie do każdej z kolekcji:

.../select?q=title:solr&fl=*,score

W przypadku kolekcji, która została skonfigurowana bez statsCache wyniki wyglądają następująco:

{
   "responseHeader":{
     "zkConnected":true,
     "status":0,
     "QTime":7,
     "params":{
       "q":"title:solr",
       "fl":"*,score"}},
   "response":{"numFound":4,"start":0,"maxScore":0.082873434,"docs":[
       {
         "id":"2",
         "title":["Solr document two"],
         "version":1633875263859195904,
         "score":0.082873434},
       {
         "id":"3",
         "title":["Solr document three"],
         "version":1633875263924207616,
         "score":0.082873434},
       {
         "id":"1",
         "title":["Solr document one"],
         "version":1633875263562448896,
         "score":0.082873434},
       {
         "id":"4",
         "title":["Solr document four"],
         "version":1633875263679889408,
         "score":0.082873434}]
   }}

W przypadku kolekcji w której statsCache jest skonfigurowany wyniki wyglądają następująco:

{
   "responseHeader":{
     "zkConnected":true,
     "status":0,
     "QTime":12,
     "params":{
       "q":"title:solr",
       "fl":"*,score"}},
   "response":{"numFound":4,"start":0,"maxScore":0.04789114,"docs":[
       {
         "id":"2",
         "title":["Solr document two"],
         "version":1633875264251363328,
         "score":0.04789114},
       {
         "id":"3",
         "title":["Solr document three"],
         "version":1633875264254509056,
         "score":0.04789114},
       {
         "id":"1",
         "title":["Solr document one"],
         "version":1633875264186351616,
         "score":0.04789114},
       {
         "id":"4",
         "title":["Solr document four"],
         "version":1633875264189497344,
         "score":0.04789114}]
   }}

Jest to oczywiście bardzo prosty przykład, jednak jak widać w przypadku kolekcji w której nie mamy skonfigurowanego statsCache score dokumentów jest prawie dwa razy wyższy. Ma to sens biorąc pod uwagę, iż term solr występuje w polu title cztery razy, po dwa razy w każdym shardzie. Oznacza to, iż kolekcja bez skonfigurowanego rozproszonego wyliczania IDF nie widzi pełnych danych.

Podsumowanie

Brak rozproszonego obliczania współczynnika IDF może powodować problemy – wtedy, kiedy jakość wyników wyszukiwania jest dla nas szczególnie ważna. Na szczęście, od wersji 5 silnika wyszukiwania Solr jesteśmy w stanie w bardzo prosty sposób włączyć rozproszony cache statystyk termów, a tym samym całkowicie rozprawić się z problemem. Oczywiście należy pamiętać, iż włączenie mechanizmu statsCache niesie za sobą obniżenie wydajności zapytań ze względu na konieczność dodatkowych operacji. Powodzenia