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:

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:

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.

W chwili obecnej, opisywane narzędzia dostępne są jedynie w branchu o nazwie branch_3x repozytorium SVN, jednak planowana jest migracja tych funkcjonalności także do wersji 4.x.

Ale o co chodzi ?

Korzystając z technik kończenia wyszukiwania po z góry ustalonym czasie, nie oglądając się na ilość wyników wyszukiwania, trafiamy w pewnym momencie na problem jakości wyników wyszukiwania. Zamiast otrzymywania najlepszych, w kontekście danego wyszukiwania, wyników otrzymujemy je w sposób losowy. Oznacza to, że nie jesteśmy w stanie zapewnić, iż użytkownik korzystający z systemu dostanie najlepiej dopasowane wyniki. Oczywiście dalej mówimy o sytuacji, kiedy kończymy wyszukiwanie po z góry ustalonym czasie i nie dajemy Solr możliwości zebrania wszystkich dokumentów pasujących do zapytania.

Po co mi to ?

Kiedy kończenie wyszukiwania po z góry ustalonym czasie może być przydatne ? Istnieje wiele zastosowań takiego wyszukiwania. Wyobraźmy sobie, że nasze wdrożenie składa się z wielu oddzielnych shardów, które operują na dużej ilości danych każdy. W przypadku zadania zapytania, każdy z shardów musi być odpytany o odpowiednie dokumenty, następnie wszystkie wyniki muszą być złożone razem i wyświetlone użytkownikowi końcowemu (oczywiście nie musi być to człowiek, może być to aplikacja). Co jednak, jeżeli każdy z shardów potrzebuje bardzo długiego czasu na przetworzenie wszystkich wyników wyszukiwania, a nas interesują np. tylko te dodane w ostatnim czasie (np. w ostatnim tygodniu). Tutaj właśnie mamy możliwość wcześniejszego zakończenia wyszukiwanie – zakładając, że bardziej interesują nas dokumenty dodane poprzedniego dnia, niż dwa tygodnie wcześniej.

Jak to zrealizować ?

Powyższy przykład pokazuje, przypadek kiedy możemy zastosować wyszukiwanie zakończone po określonym z góry czasie. Jednak zastanawiając się dalej trafiamy na pewien problem – aby posortować wyniki wyszukiwania Solr musi pobrać je wszystkie. Czyli stosując w zapytaniu parametr sort=added+desc, aby uzyskać poprawnie posortowane dokumenty i tak każdy z shardów musiałby zwrócić wszystkie wyniki wyszukiwania (oczywiście wszystkie w rozumieniu pojedynczego indeksu), czyli nici z wcześniejszego zakończenia wyszukiwania ? Nie do końca. Tutaj właśnie z pomocą przychodzi nam narzędzie IndexSorter, które do tej pory dostępne było tylko w projekcie Nutch, a od niedawna dostępne jest także w Lucene i Solr. Dzięki temu narzędziu możemy posortować wstępnie indeks według odpowiadającego nam parametru. Zatem sortując indeks malejąco po dacie dodania dokumentu, Solr pobierałby najpierw dokumenty, które zostały dodanie najpóźniej, a tym samym mielibyśmy możliwość zakończenia wyszukiwania po z góry ustalonym czasie.

Korzystanie z IndexSorter

Co zrobić, aby skorzystać z narzędzia IndexSorter ? Prawdę powiedziawszy, nie jest to nic skomplikowanego. Należy jednak pamiętać, że w momencie publikacji tego wpisu narzędzie to dostępne jest tylko w branchu o nazwie branch_3x. Aby posortować indeks na podstawie jakiegoś pola należy wywołać następującą komendę z linii poleceń (oczywiście pamiętając o odpowiednim umiejscowieniu biblioteki lucene-misc-3.1.jar z klasą IndexSorter – po wybudowaniu projektu znajdziemy ją w katalogu lucene/build/contrib/misc):

java IndexSorter KATALOG_ŹRÓDŁOWY KATALOG_DOCELOWY NAZWA_POLA

Poszczególne parametry oznaczają:

• KATALOG_ŹRÓDŁOWY – katalog z indeksem który chcemy posortować,
• KATALOG_DOCELOWY – katalog, gdzie zostanie zapisany posortowany indeks,
• NAZWA_POLA – pole, po jakim zostanie posortowany indeks.

Jeżeli wszystko przebiegło poprawnie to na ekranie powinniśmy dostać informację w stylu:

IndexSorter: done, 896 total milliseconds

Na koniec

Moim zdaniem Lucene i Solr dostały właśnie bardzo ciekawą funkcjonalność, która może być wykorzystana wszędzie tam, gdzie ilość danych jest bardzo duża, czas odpowiedzi nie może przekroczyć pewnej granicy, a wyniki poza pierwszymi (pierwszych 100, czy 1000) nie są znaczące. Wszystkich bardziej zainteresowanych tematem sortowania indeksu oraz technikami dzielenia indeksu zapraszam do obejrzenia slajdów z prezentacji pod tytułem „Munching and Crunching: Lucene Index Post-Processing” (slajdy) prowadzonej Andrzeja Białeckiego na konferencji Lucene Eurocon 2010, który omawiał te tematy.