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.