Rozproszone obliczanie IDF

Korzystając z SolrCloud, kiedy nasza kolekcja rozproszona jest pomiędzy wiele instancji Solr dotyka nas problem związany z obliczaniem tzw. odwrotnej częstotliwości dokumentu, czyli zmiennej określającej w jak dużej liczbie dokumentów występuje dany term. Problem w tym, iż domyślnie każda instanacja Solr trzyma dane na temat tej częstotliwości tylko sobie i nie dzieli się z innymi 😉 A co za tym idzie, im bardziej rozproszona jest nasza kolekcja, tym mniejsza jest precyzja naszego wyszukiwania. Zobaczmy zatem co możemy na to poradzić.

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:

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:

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:

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

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

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 🙂

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.