Funkcjonalność Rank Query Parser

Funkcjonalność Rank Query Parser jest dość prosta. Pozwala on na modyfikowanie score dokumentu na podstawie jednej z dostępnych funkcji operującej na wartości zawartej w polu tego dokumentu. Można zatem powiedzieć, iż dostarcza wycinka funkcjonalności dostępnej za pomocą Function Query Parser. Nowością jest jednak możliwość wykorzystania algorytmu BlockMax-WAND, aby zwiększyć wydajność naszego zapytania.

Pola typu RankField

Korzystanie z nowego typu pół, czyli z RankField jest bardzo proste. Wszystko co potrzebujemy zrobić do zdefiniowanie odpowiedniego typu pola, pola i rozpoczęcie indeksowania danych. Załóżmy, iż nasze dokumentu posiadają następującą strukturę:

{
  "id" : 1,
  "name": "RankField and RankQueryParser",
  "type": "post",
  "views": 1000 
}

Mamy zatem identyfikator dokumentu, nazwę dokumentu, jego typ oraz liczbę wyświetleń. Interesują nas wartości z tego ostatniego. Załóżmy, iż chcielibyśmy, aby wartości z tego pola były brane pod uwagę podczas obliczania score dokumentu – im więcej wyświetleń, tym wyżej dokument powinien być w wynikach wyszukiwania. W przypadku naszych dokumentów struktura danych opisana w pliku schema.xml wygląda następująco:

<field name="id" type="string" />
<field name="name" type="text_ws" />
<field name="type" type="string" />
<field name="views" type="rank" />

Oczywiście, musimy także zdefiniować nasz nowy typ rank, którego definicja mogłaby wyglądać następująco:

<fieldType name="rank" class="solr.RankField" />

I to jest wszystko czego potrzebujemy, czas na zapytania.

Korzystanie z Rank Query Parser

Aby skorzystać z Rank Query Parser i wykorzystać informacje z pola views w celu wpływania na score możemy wykorzystać zapytanie podobne do następującego:

q=_query_:{!rank f='views' function='log'}

Przed zadaniem zapytania zaindeksowaliśmy następujące dokumenty:

[
  {
    "id" : 1,
    "name": "RankField and RankQueryParser",
    "type": "post",
    "views": 1000 
  },
  {
    "id" : 2,
    "name": "Lucene and Solr 8.6.1 were released",
    "type": "announcement",
    "views": 10
  }
]

A wyniki zapytania wygląda następująco:

{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":3,
    "params":{
      "q":"_query_:{!rank f='views' function='log'}",
      "fl":"score,*"}},
  "response":{"numFound":2,"start":0,"maxScore":6.908755,"numFoundExact":true,"docs":[
      {
        "id":"1",
        "name":"RankField and RankQueryParser",
        "type":"post",
        "_version_":1678886835690930176,
        "score":6.908755},
      {
        "id":"2",
        "name": "Lucene and Solr 8.6.1 were released",
        "type":"announcement",
        "_version_":1678886835758039040,
        "score":2.3978953}]
  }}

Można zauważyć, iż pomimo tego, że zadaliśmy zapytanie match all, które nadaje każdemu z dokumentów score o wartości 1.0 wszystkim pasującym dokumentom nasz score jest inny. Solr wziął pod uwagę wartość zwróconą przez funkcję log dla każdego z dokumentów.

Wydajność

Oczywiście, to samo co powyżej moglibyśmy osiągnąć stosując Function Query Parser. Kluczem jest natomiast to, iż Rank Query Parser wspiera algorytm BlockMax-WAND. W przypadku kiedy do naszego zapytania dodamy parametr minExactCount ustawiony na liczbę dokumentów, które muszą pasować do zapytania Solr jest w stanie pominąć te dokumenty, które nie trafią do top N. Oczywiście zrobi to tylko wtedy, kiedy warunek określony przez minExactCount zostanie osiągnięty.

Wynik zapytania z parametrem minExactCount wygląda następująco:

{
  "responseHeader":{
    "zkConnected":true,
    "status":0,
    "QTime":1,
    "params":{
      "q":"_query_:{!rank f='views' function='log'}",
      "fl":"score,*",
      "minExactCount":"1"}},
  "response":{"numFound":2,"start":0,"maxScore":6.908755,"numFoundExact":true,"docs":[
      {
        "id":"1",
        "name":"RankField and RankQueryParser",
        "type":"post",
        "_version_":1678886835690930176,
        "score":6.908755},
      {
        "id":"2",
        "name":"Lucene and Solr 8.6.1 were released",
        "type":"announcement",
        "_version_":1678886835758039040,
        "score":2.3978953}]
  }}

O samym algorytmie BlockMax-WAND i jego wykorzystaniu w Solr porozmawiamy sobie w następnych wpisach. Jest trochę plusów i minusów o których fajnie porozmawiać.

Dostępne funkcje

W momencie powstawania tego wpisu dostępne były następujące funkcje, z których mogliśmy skorzystać wykorzystując Rank Query Parser:

• log – funkcja logarytmiczna, wykorzystuje atrybuty  weight oraz scalingFactor
• satu – funkcja akceptujące atrybuty pivot oraz weight
• sigm – funkcja akceptująca atrybuty pivot, weight, oraz exponent 

W ramach naszego zapytania możemy skorzystać z jednej z wyżej wymienionych funkcji i wykorzystać ją do modyfikacji score naszych dokumentów.

Podsumowanie

Pomimo tego, iż wcześniej podobną funkcjonalność mogliśmy już w Solr uzyskać, to jednak wsparcie dla algorytmu BlockMax-WAND jest dosyć dużym plusem. W sytuacjach kiedy mamy możliwość zadawania zapytań i nie potrzebujemy dokładnej informacji na temat liczby zwróconych wyników wyszukiwania to Rank Query Parser wydaje się być funkcjonalnością, na którą warto spojrzeć.

Na początek

Pierwszy z przykładów, których przychodzi mi do głowy, być może ze względu na projekt nad którym pracowałem jakiś czas temu, to sortowanie po odległości pomiędzy dwoma punktami. Do tej pory, aby zaimplementować taką funkcjonalność konieczne była zmiany w Solr (np. wdrożenie LocalLucene i LocalSolr). Korzystając z Solr 3.1 i późniejszych, możemy sortować wyniki wyszukiwania za pomocą wartości zwracanych przez zdefiniowane funkcje. Na przykład,w Solr mamy dostępną funkcję dist wyliczającą odległość pomiędzy dwoma punktami. Jeden z wariantów funkcji to funkcja przyjmująca pięć parametrów: algorytm i dwie pary punktów. Jeżeli, przy pomocy tej funkcji, chcielibyśmy posortować wyniki wyszukiwania rosnąco od punktu o długości i szerokości geograficznej 0,0, to wysyłając parametr sort w następującej postaci otrzymalibyśmy właśnie tak posortowane wyniki:

...sort=dist(2, geo_x, geo_y, 0, 0) asc

Podejrzewam, że najczęściej wykorzystywanymi wartościami pierwszego parametru będą:

• 1 – kalkulacja odległości na podstawie metryki Manhattan
• 2 – kalkulacja odległości euklidesowej

Kilka słów o wydajności

Wszystko pięknie, tylko jak to wygląda pod kątem wydajności ? Przeprowadziłem dwa proste testy.

Podczas pierwszego testu zaindeksowałem 200 tysięcy dokumentów składających się z czterech pól: identyfikatora (pole liczbowe), opis (pole typu text) oraz x i y (dwa pola liczbowe). Żeby nie zaciemniać wyników testu do sortowania wykorzystałem jedną z prostszych funkcji dostępnych obecnie w Solr – sum – sumującą dwa argumenty. Tak zdefiniowane sortowanie porównałem z sortowaniem domyślnym, czyli po wartości score. Poniżej tabela z wynikami:

[table “11” not found /]

Kolejny test polegał na porównaniu sortowania po polu typu string do sortowania z wykorzystaniem funkcji. Przebieg testu był prawie identyczny, jak przebieg pierwszego testu – indeksacja 200.000 dokumentów (z dodatkowym polem: opis_sort typu string) oraz wykorzystanie funkcji sum. Poniżej tabela z wynikami:

[table “12” not found /]

Na podstawie powyższego testu widać, iż sortowanie z wykorzystaniem funkcji jest zdecydowanie wolniejsze od domyślnego sortowania (czego można było się spodziewać). Sortowanie to jest także wolniejsze od sortowania po polu typu string, jednak tutaj różnica nie jest już tak znaczna, jak w poprzednim przypadku.

Kilka słów na koniec

Oczywiście powyższy test tylko prześlizguje się po temacie wydajności sortowania z wykorzystaniem funkcji w Solr, jednak pokazuje prostą zależność. Biorąc pod uwagę to, iż nie jest to sortowanie domyśle, a dające nam naprawdę duże możliwości konfiguracyjne wydaje mi się, że jest to funkcjonalność warta zapamiętania. Na pewno będzie sprawdzać się wtedy, kiedy wymagania mówią, iż musimy sortować po wartościach zmieniających się zarówno w zależności od zapytania, jak i od stanu indeksu – tak jak w przypadku sortowania po dystansie od podanego przez użytkownika punktu.