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.

Czy zastanawialiście się co powoduje, że wyszukiwarka w serwisie jest uważana za dobrą? By odpowiedzieć na to pytanie, należy się zastanowić, jak wygląda typowy proces znajdowania przez klienta pożądanej przez niego informacji. I czy jest coś takiego, jak typowy proces.

W projektach, w których udało mi się uczestniczyć dobrze sprawdzał się model mówiący o podziale na następujące fazy:

• wyszukiwanie
• redefinicja zapytania
• filtracja
• sortowanie
• przeglądanie wyników

Nie wszystkie te fazy muszą wystąpić, ich kolejność czasem będzie inna, czasem też poszczególne fazy będą występować wielokrotnie. Również w zależności od produktu, posiadanych danych i ich ilości nie wszystkie z nich system musi udostępniać.

1. Wyszukiwanie

Tu użytkownik może wykazać się największą inwencją wpisując w pole (albo wiele pól) frazę wyszukiwania. I jest to jednocześnie krytyczny moment, w którym często nowy użytkownik podejmuje decyzję: zostać czy znaleźć inny, lepszy serwis. Na co zwykle zwracamy uwagę:

• czytelność wyników i sensowność doboru wyświetlanych informacji – celem użytkownika jest znalezienie konkretnego elementu lub grupy elementów spełniających kryteria (często mętne i niekonkretne) wyszukiwania. Dlatego musi mieć możliwość wstępnego odrzucenia tych elementów, które mu z jakiś powodów nie pasują. Błędem jest brak podstawowych dla użytkownika informacji (np. serwis z ogłoszeniami sprzedaży mieszkań, który nie pokazuje na liście wyników metrażu ani lokalizacji! )
• liczba znalezionych wyników – jeśli wyników jest mało, może to np. sugerować ograniczony asortyment w sklepie
• przystawanie wyników do frazy wyszukiwania – jeśli w sklepie komputerowym na hasło: „notebook” na pierwsza strona zawiera tylko pokrowce na notebooki, może to sugerować, że firma sprzedaje tylko akcesoria
• możliwości nawigacji i łatwość dokonania wyboru – jeśli wyników wyszukiwania jest dużo, zostawienie użytkownikowi możliwości tylko zmiany zapytania albo męczącego przebijania się przez strony wyników nie jest dobrym pomysłem.

2. Redefinicja zapytania

W zależności od uzyskanych wyników wyszukiwania, zwykle od pierwszego wrażenia jakości tych wyników, użytkownik może zdecydować się powtórzyć wyszukiwanie. Im więcej faz redefinicji, tym gorsze wrażenie klienta i większa szansa na opuszczenie sklepu. Zwłaszcza, jeśli użytkownik, w jego mniemaniu wpisał bardzo ogólną frazę, a nie dostał żadnych wyników.

3. Filtracja

Rodzaj zwróconych wyników jest w porządku, pytanie, jak teraz użytkownik może ograniczyć ich liczbę do tych, które są szczególnie interesujące (czyli odrzucić te mniej ciekawe). W tym celu umożliwia się dalsze nawigowanie po wynikach wyszukiwania w oparciu o filtry. Tutaj zwykle zwracamy uwagę na:

• łatwość dodawania i usuwania filtru – zakładając, że użytkownik ma jedynie ogólne pojęcie czego szuka, należy się spodziewać, że będzie on wielokrotnie zmieniał kryteria wyszukiwania – niedopuszczalne są ścieżki nawigacji, gdzie jedyną metodą powrotu do wcześniej odfiltrowanych elementów jest przycisk „powrót” w przeglądarce, lub rozpoczęcie kolejnego wyszukiwania.
• zależność filtrów od rodzaju wyszukiwania – szukając nowego komputera interesujący jest inny zestaw parametrów niż wybierając książkę. Chociaż brzmi to jak oczywistość, zbyt często można spotkać sytuacje, gdzie zmiana asortymentu sklepu nie pociąga za sobą zmian definicji filtrów, lub zestaw filtrów jest narzucony „z góry”. W efekcie pojawiają się opcje typu „kolor opon”.
• podanie liczb określających liczbę wyników po zastosowaniu filtra – niedoceniana funkcjonalność, jednak pozwala na wybieranie przez użytkownika optymalnego sposobu filtrowania: jeśli koniecznie w notebooku muszę mieć wbudowaną kamerę, to filtr „Z wbudowaną kamerą (3)” od razu sugeruje, że wybór koloru będzie mniej ważny i nie ma sobie co nim zawracać głowy.

4. Sortowanie

Pozwala się zająć klientowi przeglądaniem wyników w najwygodniejszej kolejności (np. od najtańszych produktów). W praktyce liczba opcji jest mocno ograniczona, np. Pomysł sortowania po cechach produktu może konfliktować z filtrowaniem.

5. Przeglądanie Wyników

Tutaj użytkownik już zapoznaje się z wybranymi produktami. Z punktu widzenia wyszukiwania to już dość nudny temat Warto jednak pamiętać o wygodnym powrocie do listy wyników: tu błędem jest np. automatyczny powrót na pierwszą stronę wyników, albo zmuszanie użytkownika do przewijania strony w poszukiwaniu ostatnio oglądanego elementu.