Zacznijmy od listy

Korzystając z parameteru defType w trakcie zapytania jesteśmy w stanie określić, który query parser zostanie wykorzystany w trakcie przetwarzania naszego zapytania. Lista dostępnych query parserów w Solr 4.4 przedstawia się następująco:

• lucene
• lucenePlusSort
• func
• prefix
• boost
• dismax
• edismax
• field
• raw
• term
• query
• frange
• geofilt
• bbox
• join
• surround
• switch
• maxscore

Przejdźmy zatem do ich opisu.

Lucene Query Parser – lucene

Domyślny parser wykorzystywany przez Solr umożliwiający zadawanie zapytań z wykorzystaniem języka zapytań Lucene (z pewnymi, małymi zmianami o których można przeczytać tutaj: http://wiki.apache.org/solr/SolrQuerySyntax). Przykładowe zapytanie z wykorzystaniem tego parsera wygląda następująco: q=+title:harry +category:books

Old Lucene Query Parser – lucenePlusSort

Stary parser Lucene, który wydaje się być bardzo rzadko wykorzystywany. Wyróżniał się tym, iż pozwalał na określenie sortowania w samym zapytaniu (metoda ta oznaczona jest jako deprecated). Zapytanie takie wyglądało następująco: q={!lucenePlusSort}title:harry;price asc

Function Query Parser – func

Parser umożliwiający wykorzystanie funkcji (http://wiki.apache.org/solr/FunctionQuery) w zapytaniu. Na przykład, można go wykorzystać do wykonywania obliczeń na etapie zapytań: q={!func}add($value1,$value2)&value1=max(price,100)&value2=1.0.

Prefix Query Parser – prefix

Jeden z parserów, którego nie interesuje typ pola – wartości do niego podane nie będą poddane analizie. Sam parser służy do wykonywania zapytań z wykorzystaniem przedrostków, na przykład zapytanie, takie jak q={!prefix}har jest prawie tym samym co zapytanie q=har* wykorzystujący domyślny Lucene query parser.

Boost Query Parser – boost

Parser umożliwiający tworzenie zapytań modyfikujących wartości score dokumentów. Na przykład, jeżeli chcemy, aby score dokumentów zwracanych w odpowiedzi na zapytanie harry były zmodyfikowane zapytaniem recip(ms(NOW,published),3.16e-11,1,1), możemy zadać następujące zapytanie: {!boost b=recip(ms(NOW,published),3.16e-11,1,1)}harry.

Dismax Query Parser – dismax

Parser obsługujący uproszczoną wersję języka zapytań Lucene (np. nie ma możliwości przekazania nazwy pola w zapytaniu), który na wyjściu tworzy tzw. zapytania disjunction max (wiem, wiem, dziwnie to brzmi) stworzone z przekazanego zapytania oraz pól zdefiniowanych w parametrze qf. Pozwala na definiowanie liczby słów, jakie muszą być znalezione w dokumencie (za pomocą parametru mm) oraz definicji, jak powinny być traktowane poszczególne elementy wpływające na finalny score dokumentu (parametr tie). Wszystkie parametery udostępnianie przez ten parser oraz jego opis można znaleźć na wiki Solr, pod adresem: http://wiki.apache.org/solr/DisMaxQParserPlugin.

Extended Dismax Query Parser – edismax

Rozszerzona wersja parsera dismax, umożliwiająca między innymi podawanie nazw pól w głównym zapytaniu. Parser ten, został zaprojektowany z myślą o możliwości podawania bardziej skomplikowanych zapytań, niż te, które można było przekazać za pomocą parametru q w przypadku parsera dismax. Wszystkie parametry i dokładniejszy opis parsera można znaleźć na wiki Solr pod adresem: http://wiki.apache.org/solr/ExtendedDisMax.

Field Query Parser – field

Field query parser umożliwia nam wykonywanie zapytań przeciwko danemu polu. Przekazana do parsera wartość zostanie poddana analizie oraz zostanie stworzone zapytanie o frazę, jeżeli jest taka możliwość. Na przykład, zapytanie postaci {!field f=title}harry potter jest mniej, więcej odpowiednikiem zapytania title:”harry potter” w przypadku korzystania z domyślnego Lucene query parsera.

Raw Query Parser – raw

Parser umożliwiający przekazanie terma, który nie zostanie poddany analizie przez Solr. Na przykład zapytanie {!raw f=title}harry zaowocuje stworzeniem TermQuery do pola title  z wartością harry.

Term Query Parser – term

Parser przydatny do zadawania zapytań, które powinny zostać potraktowane jako filtry, np. w przypadku zawężania facetingu – {!term f=category}book. Należy pamiętać, iż wartość przekazana do tego parsera nie zostanie poddana analizie.

Nested Query Parser – query

Parser umożliwiający przekazanie podzapytania, z możliwością zmiany typu podzapytania. Na przykład weźmy następujące zapytanie {!query defType=func v=$query}&$query=max(price,100) będzie ono skutkować wywołaniem zapytania z wykorzystaniem funkcji zdefiniowanego w parametrze query. Jeżeli natomiast zmienimy parametr query na następujący: $query={!term f=category}book, wtedy zostanie wykonane zapytanie z wykorzystaniem term query parsera, a zatem parametr defType zostanie nadpisany. Nested query parser jest użyteczny na przykład w sytuacji, kiedy chcemy umożliwić użytkownikom wykorzystanie wartości zapisanych w parametrach konfiguracyjnych.

Function Range Query Parser – frange

Parser umożliwiający zadanie zapytanie o zakres wartości wyniku działania funkcji (pisaliśmy o tym – http://solr.pl/2011/05/30/krotkie-spojrzenie-frange/). Parser umożliwia wykorzystanie czterech parametrów: l, u, incl, incu które pozwalają na konfigurowanie jego zachowania. Przykładowe zapytanie z wykorzystaniem tego parsera może wyglądać następująco: {!frange l=10 u=12 incl=true incu=true}sum(price,rate).

Spatial Filter Query Parser – geofilt

Jeden z dwóch parserów umożliwiających zawężanie dokumentów na podstawie ich lokalizacji oraz odległości od podanego punktu geograficznego. Na przykład zapytanie q=*:*&fq={!geofilt pt=52.14,21.10 sfield=location d=50} zwróci nam dokumenty, które zawierają się w odległości 50km od podanego punktu. Więcej o tym parserze można przeczytać na wiki Solr pod adresem: http://wiki.apache.org/solr/SpatialSearch#geofilt_-_The_distance_filter.

Spatial Box Query Parser – bbox

Kolejny query parser umożliwiający zawężanie dokumentów na podstawie ich lokalizacji. W odróżnieniu od parsera geofilt parser bbox jest mniej wymagający pod względem mocy obliczeniowej, aczkolwiek może zwrócić dokument, który będzie znajdował się poza dokładnie zdefiniowanym okręgiem (ze względu na przybliżenia obliczeń). Przykładowe zapytanie wykorzystujące ten parser może wyglądać następująco: q=*:*&fq={!bbox pt=52.14,21.10 sfield=location d=50}. Więcej o tym parserze można przeczytać na wiki Solr pod adresem http://wiki.apache.org/solr/SpatialSearch#bbox_-_Bounding-box_filter.

Join Query Parser – join

Parser umożliwiający tworzenie zapytań o dokumenty, które są zależne od innych dokumentów, czyli z wykorzystaniem joinów. Możliwe są połączenia zarówno w ramach pojedynczego rdzenia, jak i różnych rdzeni. Przykładowe zapytanie może wyglądać następująco: q={!join from=parent to=id}color:Yellow. Więcej przykładów oraz trochę dokładniejszy opis można znaleźć wśród wcześniejszych artykułów, np. tutaj: http://solr.pl/2011/02/21/czekajac-na-4-0-solr-2272-czyli-solr-i-funkcjonlanosc-join/.

Surround Query Parser – surround

Parser, który jest dostępny w ramach dodatkowych bibliotek do Solr (można o nim przeczytać więcej na: http://wiki.apache.org/solr/SurroundQueryParser). Postaramy się w nabliższych tygodniach napisać o nim więcej – generalne pozwala na wyszukiwanie informacji z uwzględnieniem pozycji.

Switch Query Parser – switch

Idea działania tego parsera jest dość prosta – umożliwić przetwarzanie prostego warunku po stronie Solr i przekazanie go jako podzapytania. Przykład wykorzystania oraz więcej o tym parserze można znaleźć tutaj: http://solr.pl/2013/06/03/switch-query-parser-szybkie-spojrzenie/.

Max Score Query Parser – maxscore

Bardzo podobny (jeżeli chodzi o parametry) parser do domyślnego Lucene query parsera. Różnica w działaniu polega na wyliczaniu score dokumentów. W przypadku max score query parsera, dokumenty otrzymują score równy najbardziej znaczącemu elementowi w zapytaniu. Dodatkowo, mamy możliwość zmiany tego zachowania poprzez przekazanie parametru tie (domyślnie 0.0). W przypadku przekazania tie=0.0, dokument otrzyma score, taki jak najbardziej znaczący element zapytania, jeżeli przekażemy tie=1.0, to score dokumentu będzie sumą wszystkich elementów wpływających na score. Przykładowe zapytanie może wyglądać następująco: q=potter {!maxscore v=’harry’}. Więcej o parametrze tie można przeczytać tutaj: http://solr.pl/2012/02/06/do-czego-moze-przydac-sie-tie-w-dismaxie/.

Krótkie podsumowanie

Jak widać, Solr dostarcza nam naprawdę różnorodne i ciekawe parsery zapytań do wykorzystania. Za ich pomocą możemy stworzyć skomplikowane zapytania, które wykorzystają dużą część funkcjonalności Lucene. Należy jednak pamiętać, że im bardziej skomplikowane zapytanie, tym więcej mocy obliczeniowej będzie potrzebować Solr, aby je wykonać – warto o tym pamiętać przy konstrukcji tych bardziej skomplikowanych.

Idea działania

Idea działania jest dość prosta – umożliwić przetwarzanie prostego warunku po stronie Solr i przekazanie do jako podzapytanie. Na przykład, wyobraźmy sobie, że mamy aplikację, która rozumie cztery wartości pola priceRange:

• cheap – w przypadku kiedy cena produktu, zapisana w polu price, jest niższa, niż 10$,
• average – w przypadku kiedy cena produktu jest pomiędzy 10, a 30$,
• expensive – w przypadku kiedy cena produktu jest wyższa niż 30$,
• all – w przypadku kiedy chcemy pokazać wszystkie produkty, bez względu na cenę

Chcielibyśmy tę logikę zaszyć w Solr, aby nie było konieczności zmian po stronie aplikacji za każdym razem kiedy chcemy zmienić powyższe warunki. W tym właśnie celu wykorzystamy SwitchQueryParser.

Nasze zapytanie

Załóżmy, że nasza aplikacja jest w stanie zadać następujące zapytanie:

http://localhost:8983/solr/collection1/price?q=*:*&priceRange=cheap

A zatem chcielibyśmy, aby na powyższe zapytanie Solr zwrócił wszystkie dokumenty (q=*:*), ale zawężone do tych posiadających cenę niższą niż 10$ (parameter priceRange=cheap).

Konfiguracja Solr

Oczywiście nie chcemy konfiguracji naszych zakresów pola price wysyłać w zapytaniu, bo nie miałoby to większego sensu. My zdecydowaliśmy się stworzyć nowy SearchHandler o nazwie /price z następującą konfiguracją (dodajemy go do pliku solrconfig.xml):

<requestHandler name="/price">
 <lst name="defaults">
  <str name="priceRange">all</str>
 </lst>
 <lst name="appends">
  <str name="fq">{!switch case.all='price:[* TO *]' case.cheap='price:[0 TO 10]' case.average='price:[10 TO 30]' case.expensive='price:[30 TO *]' v=$priceRange}</str>
 </lst>
</requestHandler>

Jak widać konfiguracja naszego SearchHandlera składa się z dwóch elementów. Po pierwsze w sekcji defaults zdefiniowaliśmy, iż parametr priceRange będzie domyślnie przyjmować wartość all. Dodatkowo zdefiniowaliśmy filtr (fq) działający w oparciu o SwitchQueryParser (!switch). Dla każdej z możliwych wartości parametru priceRange (v=$priceRange) zdefiniowaliśmy odpowiedni filtr wykorzystując wyrażenie case.wartośćPolaPriceRange=filtr. Zatem, kiedy wartość parametru priceRange w zapytaniu będzie wynosić cheap to filtr zdefiniowany przez case.cheap będzie wykorzystany, jeżeli ta wartość będzie wynosić expensive to filtr zdefiniowany przez case.expensive będzie wykorzystany, itd.

O czym należy pamiętać

Jest jedna, ważna rzecz o której należy pamiętać w przypadku korzystania z opisywanego parsera. W naszym przypadku podanie do parametru priceRange wartości innej, niż 4 powyżej wymienione będzie skutkowało błędem Solr.

Kilka słów podsumowania

Moim skromnym zdaniem SwitchQueryParser pomimo tego, że nie będzie stosowany przez większość użytkowników Solr wydaje się być fajnym pomysłem. Biorąc pod uwagę to, że pozwala ukryć przed aplikacją bardzo prostą logikę oraz to, że jest dość prosty, a co za tym nie wymagający jeżeli chodzi o zasoby, na pewno znajdą się użytkownicy, którym ten parser ułatwi pracę

W obecnym trunk`u Solr, mamy dostępne trzy parsery zapytań:

• Standard Solr Query Parser, czyli domyślny parser dla Solr oparty na domyślnym parserze zapytań w Lucene
• DisMax Query Parser
• Extended DisMax Query Parser

Każdy z wyżej wymienionych parserów ma inne możliwości jeżeli chodzi premiowanie fraz na etapie zapytań. W tym wpisie nie zajmuję się kwestiami premiowania bliskości słów na etapie indeksowania, o tym napiszę innym razem. A więc wracając do parserów.

Standard Solr Query Parser

Parser oparty o standardowy parser zapytań Lucene oraz rozszerzający jego możliwości. Możliwości co do premiowania fraz nie są duże. Załóżmy, iż nasz system obsługuje dużą księgarnię internetową, gdzie użytkownicy są mogą oceniać książki, zostawiać komentarze, czy dyskutować na temat książek na forach, a my indeksujemy wszystkie te dane oraz później prezentujemy je w ramach wyników wyszukiwania. Możemy założyć także, iż użytkownik wpisując w pole wyszukiwania „Java wzorce projektowe” szuka książek dotyczących wzorców projektowych z przykładami w języku Java i takie książki chcemy mu pokazać. Żaden problem, zadajemy do Solr zapytanie:

q=java+wzorce+projektowe

I otrzymujemy listę książek. Można spocząć na laurach i stwierdzić, że nasza wyszukiwarka zachowuje się świetnie i chcemy nic więcej poprawiać. Ja jednak dodałbym do tego zapytania kolejną część – premiowanie fraz, tak aby książki, które w przeszukiwanych polach posiadają odpowiednią frazę (czyli tak naprawdę w których słowa podane przez użytkownika występują obok siebie) były pozycjonowane na początku listy wyników. Zmodyfikowane zapytanie wyglądałoby tak:

q=java+wzorce+projektowe+OR+"java+wzorce+projektowe"^30

Dodając dodatkowy fragment (+OR+”java+wzorce+projektowe”^30) na pierwszych miejscach listy wyników wyszukiwania dostaniemy dokumenty, które nie tylko mają w polach wyszukiwania termy (wyrazy) podane przez użytkownika, ale w tych polach mają te termy umiejscowione obok siebie. A tak wygląda zapytanie wygenerowane do Lucene:

<str name="parsedquery">name:java name:wzorce name:projektowe PhraseQuery(name:"java wzorce projektowe"^30.0)</str>
<str name="parsedquery_toString">name:java name:wzorce name:projektowe name:"java wzorce projektowe"^30.0</str>

Wyniki wyszukiwania dla tak skonstruowanego zapytania przedstawiają się następująco:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="q">java wzorce projektowe OR "java wzorce projektowe"^30</str>
      <str name="fl">score,id,name</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.2399161">
   <doc>
      <float name="score">1.2399161</float>
      <str name="id">1</str>
      <str name="name">Java wzorce projektowe</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">2</str>
      <str name="name">Wzorce projektowe java</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">3</str>
      <str name="name">Wzorce java projektowe</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">4</str>
      <str name="name">Projektowe wzorce java</str>
   </doc>
   <doc>
      <float name="score">0.010219089</float>
      <str name="id">5</str>
      <str name="name">Projektowe java wzorce</str>
   </doc>
</result>
</response>

DisMax Query Parser

Oprócz możliwości skonstruowania zapytania w taki sposób, jak opisany powyżej mamy możliwość wykorzystania parametru pf oraz modyfikacji jego zachowania za pomocą parametru ps. Parametr pf przekazuje informacje o tym, w jakich polach mają być identyfikowane frazy. Parametru tego używa się w sposób analogiczny do parametru qf określając listę pól w jakich mają być identyfikowane frazy. Dodatkowo, należy dla każdego z podanych pól określić odpowiednie wartości podbicia (boost), bo jak wiemy domyślnym podbiciem jest 1. Zapytanie z wykorzystaniem DisMax`a wyglądałoby następująco:
q=java+wzorce+projektowe&defType=dismax&qf=name&pf=name^30&ps=0

Natomiast zapytanie przekazane do Lucene wygląda w sposób następujący:

<str name="parsedquery">+((DisjunctionMaxQuery((name:java)) DisjunctionMaxQuery((name:wzorce)) DisjunctionMaxQuery((name:projektowe)))~3) DisjunctionMaxQuery((name:"java wzorce projektowe"^30.0))</str>
<str name="parsedquery_toString">+(((name:java) (name:wzorce) (name:projektowe))~3) (name:"java wzorce projektowe"^30.0)</str>

Wyniki dla tak skonstruowanego zapytania przedstawiają się następująco:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="pf">name^30</str>
      <str name="fl">id,name,score</str>
      <str name="q">java wzorce projektowe</str>
      <str name="qf">name</str>
      <str name="defType">dismax</str>
      <str name="ps">0</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.2399161">
   <doc>
      <float name="score">1.2399161</float>
      <str name="id">1</str>
      <str name="name">Java wzorce projektowe</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">2</str>
      <str name="name">Wzorce projektowe java</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">3</str>
      <str name="name">Wzorce java projektowe</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">4</str>
      <str name="name">Projektowe wzorce java</str>
   </doc>
   <doc>
      <float name="score">0.013625451</float>
      <str name="id">5</str>
      <str name="name">Projektowe java wzorce</str>
   </doc>
</result>
</response>

Warto zauważyć, iż kolejność wyników dla obu metod jest taka sama. Wynika to z tego, iż fraza została zidentyfikowana tylko w przypadku dokumentu z identyfikatorem 1. Wartość score dla tego dokumentu w obu przypadkach jest taka sama. Natomiast dokumenty znajdujące się na pozycjach od 2 do 4 mają w ramach danej metody dokładnie taką samą wartość score ze względu na zidentyfikowanie trzech termów i dokładnie taką samą długość pola name. Oczywiście istnieją różnice w wartości score tych dokumentów pomiędzy metodami, ale wynika to z różnic w składaniu zapytań.

Użyłem jednak współczynnika ps=0 nie wspominając zupełnie o tym co oznacza i do czego służy. W przypadku korzystania z parametru pf (oraz pf2, ale o tym później) parametr ps oznacza tzw. Phrase Slop, czyli maksymalną odległość słów od siebie, aby tworzyły frazę. Na przykład ps=2 będzie oznaczało, iż słowa mogą być maksymalnie dwie pozycje od siebie, aby tworzyły frazę. Należy jednak pamiętać, iż pomimo tego, że zarówno „Java przykładowe wzorce projektowe”, jak i „Java wzorce projektowe” stworzą frazę, jednak dokument o tytule „Java wzorce projektowe” będzie posiadał większy score pomimo ustawienia ps=2, ze względu na to, że termy położone są bliżej siebie.

Omówiliśmy już dwa przypadki premiowania fraz. Został nam ostatni opierający się na tzw. Enhanced Term Proximity Boosting, czyli metodzie premiowania nie tylko całych fraz, ale także ich poszczególnych części. Funkcjonalność tą oferuje jednak tylko i wyłączenie:

Extended DisMax Query Parser

Niestety bez skorzystania z trunk`a lub przeniesienia kawałka kodu nie ma możliwości skorzystania z eDisMax`a.

Zapytanie z eDisMax`em wyglądałoby następująco:

q=java+wzorce+projektowe&defType=edismax&qf=name&pf2=name^30&ps=0

Powyższe zapytanie, tworzy następujące zapytania do Lucene:

<str name="parsedquery">+(DisjunctionMaxQuery((name:java)) DisjunctionMaxQuery((name:wzorce)) DisjunctionMaxQuery((name:projektowe))) (DisjunctionMaxQuery((name:"java wzorce"^30.0)) DisjunctionMaxQuery((name:"wzorce projektowe"^30.0)))</str>
<str name="parsedquery_toString">+((name:java) (name:wzorce) (name:projektowe)) ((name:"java wzorce"^30.0) (name:"wzorce projektowe"^30.0))</str>

Jak widać oprócz standardowych DisjunctionMaxQuery charakterystycznych dla DisMax`a (a tym samym dla jego rozszerzonej wersji) które wyszukują poszczególne termy przekazane do parametru q stworzone zostały także dwa dodatkowe zapytania, które odpowiadają za funkcjonalność enhanced term proximity boosting. Polega ona na stworzeniu par ze słów występujących obok siebie. W opisywanym testowym przypadku stworzone zostały pary „java wzorce” oraz „wzorce projektowe”. Jak można się domyślić najbardziej znaczącymi dokumentami na liście wyników, będą dokumenty posiadające obie wygenerowane pary, kolejne dokument będą posiadały jedną z par, a kolejne nie będą posiadały żadnej. Na potwierdzenie przedstawiam wynik zadania powyższego zapytania do Solr:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
   <int name="status">0</int>
   <int name="QTime">0</int>
   <lst name="params">
      <str name="fl">id,name,score</str>
      <str name="q">java wzorce projektowe</str>
      <str name="qf">name</str>
      <str name="pf2">name^30</str>
      <str name="defType">edismax</str>
      <str name="ps">0</str>
   </lst>
</lst>
<result name="response" numFound="5" start="0" maxScore="1.1705827">
   <doc>
      <float name="score">1.1705827</float>
      <str name="id">1</str>
      <str name="name">Java wzorce projektowe</str>
   </doc>
   <doc>
      <float name="score">0.3034844</float>
      <str name="id">2</str>
      <str name="name">Wzorce projektowe java</str>
   </doc>
   <doc>
      <float name="score">0.3034844</float>
      <str name="id">5</str>
      <str name="name">Projektowe java wzorce</str>
   </doc>
   <doc>
      <float name="score">0.014451639</float>
      <str name="id">3</str>
      <str name="name">Wzorce java projektowe</str>
   </doc>
   <doc>
      <float name="score">0.014451639</float>
      <str name="id">4</str>
      <str name="name">Projektowe wzorce java</str>
   </doc>
</result>
</response>

Jak widać pierwszy dokument nie zmienił swojej pozycji i jest to dalej dokument o identyfikatorze 1. Natomiast na drugim i trzecim miejscu znajdują się dokumenty, które mają jedną z wygenerowanych przez parser par słów. Co za tym idzie dokumenty o identyfikatorach 2 i 5 mają tą samą wartość współczynnika score. Listę wyników zamykają dokumenty posiadające jedynie termy wpisane przez użytkownika. Na uwagę zasługuje również fakt, iż tak samo jak w przypadku pierwszych dwóch przykładów, tak i eDisMax wyliczył inną wartość maksymalną współczynnika score dla wynikowego zbioru dokumentów – spowodowane jest to dokładnie tym samym co w poprzednim przykładzie, a mianowicie zapytaniem wygenerowanym przez parser i złożonym do Lucene.

Wydajność

W każdym wypadku należy wziąć pod uwagę, jaki poszczególne funkcjonalności będą miały wpływ na wydajność aplikacji opartej o Solr. W tym celu postanowiłem zrobić prosty test wydajnościowy. Założenia testu są dość proste – indeksuję dane z wikipedii, i dla każdej z metod tworze zapytanie dla fraz składających się z dwóch do sześciu tokenów. Zapytania zadaje przy wyłączonych cache`ach, za każdym razem restartując Solr. Wynik to średnia arytmetyczna z 10 powtórzeń każdego z testów. Przed wynikami testu, kilka słów o samym indeksie:

• Ilość dokumentów w indeksie: 1.177.239
• Ilość segmentów: 1
• Ilość termów:  18.506.646
• Ilość par term/dokument: 230.297.212
• Ilość tokenów: 418.135.268
• Wielkość indeksu: 4.6GB (zoptymalizowany)
• Wersja Lucene wykorzystana do zbudowania: 4.0-dev 964000

Frazy jakie wybierane były dla każdej iteracji testu:

• Iteracja I: „wielki piotr”
• Iteracja II: „druga wojna światowa”
• Iteracja III: „druga wojna światowa niemcy”
• Iteracja IV: „czas zmian reformacja w polsce”
• Iteracja V: „zmiana czasu letniego na czas zimowy”

Same wyniki przedstawiają się następująco:

Należy pamiętać, iż przedstawione wyniki dotyczą tylko i wyłącznie kwestii wydajnościowej i nie są sugestią której metody premiowania fraz należy używać. Wybór metody to kwestia wymagań i danego wdrożenia. Co do samych wyników, widać, iż zgodnie z przypuszczeniami najszybsza jest metoda druga, czyli wykorzystanie term proximity boost i parsera DisMax, który okazuje się szybszy zarówno od Standard Query Parsera, jak i od eDisMax`a.