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ę

Tie, czyli co ?

Parametr tie pozwala kontrolować, jak mocny wpływ na score mają pola, które otrzymały score mniejszy od najwyższego. W przypadku ustawienia parametru tie na wartość 0.0, podczas liczenia score będą brane pod uwagę tylko i wyłącznie te pola, które otrzymały najwyższy score. W przypadku ustawienia tego parametru na wartość 0.99, pola, które mają score mniejszy od najwyższego będą traktowane prawie identycznie, jak pole o najwyższym wyliczonym score. Sprawdźmy zatem, czy jest to prawda.

Struktura danych i ich przykład

Do testów wybrałem sobie bardzo prostą strukturę indeksu, która teoretycznie mogłaby przedstawiać produkty w sklepie internetowym, oczywiście w ogromnym uproszczeniu:

<field name="id" type="string" indexed="true" stored="true" required="true" />
<field name="title" type="text_ws" indexed="true" stored="true" />
<field name="description" type="text_ws" indexed="true" stored="true" />
<field name="author" type="text_ws" indexed="true" stored="true" multiValued="true" />

Typ text_ws został zdefiniowany w następujący sposób:

<fieldType name="text_ws" class="solr.TextField" positionIncrementGap="100">
 <analyzer>
  <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  <filter class="solr.LowerCaseFilterFactory"/>
 </analyzer>
</fieldType>

Natomiast przykładowe dane wyglądają w następujący sposób:

<add>
 <doc>
  <field name="id">1</field>
  <field name="title">First test book</field>
  <field name="description">This is a description of the first test book by Joe and Jane Blow</field>
  <field name="author">Joe Blow</field>
  <field name="author">Jane Blow</field>
 </doc>
 <doc>
  <field name="id">2</field>
  <field name="title">Second test book</field>
  <field name="description">This is a description of the second test book by Joe Blow</field>
  <field name="author">Joe Blow</field>
 </doc>
</add>

Rezultat z tie == 0.01

Zacznijmy więc testy. Na pierwszy ogień idzie następujące zapytanie:

defType=dismax&qf=title^1000 description author^10&tie=0.01&fl=id,score&debugQuery=on&indent=true&q=joe blow book

Powyższe skutkuje następującymi wynikami zwróconymi przez Solr (wizualizacja – http://explain.solr.pl/explains/cf0wnkpj):

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">8</int>
  <lst name="params">
    <str name="fl">id,score</str>
    <str name="debugQuery">on</str>
    <str name="indent">true</str>
    <str name="tie">0.01</str>
    <str name="q">joe blow book</str>
    <str name="qf">title^1000 description author^10</str>
    <str name="defType">dismax</str>
  </lst>
</lst>
<result name="response" numFound="2" start="0" maxScore="0.07342677">
  <doc>
    <float name="score">0.07342677</float>
    <str name="id">2</str>
  </doc>
  <doc>
    <float name="score">0.073365316</float>
    <str name="id">1</str>
  </doc>
</result>
<lst name="debug">
  <str name="rawquerystring">joe blow book</str>
  <str name="querystring">joe blow book</str>
  <str name="parsedquery">+((DisjunctionMaxQuery((author:joe^10.0 | title:joe^1000.0 | description:joe)~0.01) DisjunctionMaxQuery((author:blow^10.0 | title:blow^1000.0 | description:blow)~0.01) DisjunctionMaxQuery((author:book^10.0 | title:book^1000.0 | description:book)~0.01))~3) ()</str>
  <str name="parsedquery_toString">+(((author:joe^10.0 | title:joe^1000.0 | description:joe)~0.01 (author:blow^10.0 | title:blow^1000.0 | description:blow)~0.01 (author:book^10.0 | title:book^1000.0 | description:book)~0.01)~3) ()</str>
  <lst name="explain">
    <str name="2">
0.07342677 = (MATCH) sum of:
  0.07342677 = (MATCH) sum of:
    8.957935E-4 = (MATCH) max plus 0.01 times others of:
      8.9543534E-4 = (MATCH) weight(author:joe^10.0 in 1), product of:
        0.0024097771 = queryWeight(author:joe^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.3715843 = (MATCH) fieldWeight(author:joe in 1), product of:
          1.0 = tf(termFreq(author:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.625 = fieldNorm(field=author, doc=1)
      3.5817415E-5 = (MATCH) weight(description:joe in 1), product of:
        2.4097772E-4 = queryWeight(description:joe), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:joe in 1), product of:
          1.0 = tf(termFreq(description:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
    8.957935E-4 = (MATCH) max plus 0.01 times others of:
      8.9543534E-4 = (MATCH) weight(author:blow^10.0 in 1), product of:
        0.0024097771 = queryWeight(author:blow^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.3715843 = (MATCH) fieldWeight(author:blow in 1), product of:
          1.0 = tf(termFreq(author:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.625 = fieldNorm(field=author, doc=1)
      3.5817415E-5 = (MATCH) weight(description:blow in 1), product of:
        2.4097772E-4 = queryWeight(description:blow), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:blow in 1), product of:
          1.0 = tf(termFreq(description:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
    0.07163518 = (MATCH) max plus 0.01 times others of:
      0.07163482 = (MATCH) weight(title:book^1000.0 in 1), product of:
        0.2409777 = queryWeight(title:book^1000.0), product of:
          1000.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(title:book in 1), product of:
          1.0 = tf(termFreq(title:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=title, doc=1)
      3.5817415E-5 = (MATCH) weight(description:book in 1), product of:
        2.4097772E-4 = queryWeight(description:book), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:book in 1), product of:
          1.0 = tf(termFreq(description:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
</str>
    <str name="1">
0.073365316 = (MATCH) sum of:
  0.073365316 = (MATCH) sum of:
    7.1670645E-4 = (MATCH) max plus 0.01 times others of:
      7.163483E-4 = (MATCH) weight(author:joe^10.0 in 0), product of:
        0.0024097771 = queryWeight(author:joe^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(author:joe in 0), product of:
          1.0 = tf(termFreq(author:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=author, doc=0)
      3.5817415E-5 = (MATCH) weight(description:joe in 0), product of:
        2.4097772E-4 = queryWeight(description:joe), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:joe in 0), product of:
          1.0 = tf(termFreq(description:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    0.0010134276 = (MATCH) max plus 0.01 times others of:
      0.0010130694 = (MATCH) weight(author:blow^10.0 in 0), product of:
        0.0024097771 = queryWeight(author:blow^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.42039964 = (MATCH) fieldWeight(author:blow in 0), product of:
          1.4142135 = tf(termFreq(author:blow)=2)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=author, doc=0)
      3.5817415E-5 = (MATCH) weight(description:blow in 0), product of:
        2.4097772E-4 = queryWeight(description:blow), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:blow in 0), product of:
          1.0 = tf(termFreq(description:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    0.07163518 = (MATCH) max plus 0.01 times others of:
      0.07163482 = (MATCH) weight(title:book^1000.0 in 0), product of:
        0.2409777 = queryWeight(title:book^1000.0), product of:
          1000.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(title:book in 0), product of:
          1.0 = tf(termFreq(title:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=title, doc=0)
      3.5817415E-5 = (MATCH) weight(description:book in 0), product of:
        2.4097772E-4 = queryWeight(description:book), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0532142E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:book in 0), product of:
          1.0 = tf(termFreq(description:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    </str>
  </lst>
</lst>
</response>

Pierwszy dokument

Drugi dokument

Czyli jak to wygląda ?

Jak widać w przypadku przekazania wartości 0.01 do parametru tie pola, które mają najwyższy score, mają największe znaczenie, z niedużym znaczeniem innych pól. Widać to dobrze na przykładzie słowa book w pierwszym dokumencie na liście wyników. Score dla tego słowa, to 0.07163518, na który został wyliczony jako suma pola, które ma najwyższy score dla tego słowa, czyli pola title oraz wartości score reszty pól pomnożonych przez wartość tie, czyli 0.01.

Rezultat z tie == 0.99

Drugie zapytanie wygląda w następujący sposób:

defType=dismax&qf=title^1000 description author^10&tie=0.99&fl=id,score&debugQuery=on&indent=true&q=joe blow book

Wyniki zwrócone przez Solr (wizualizacja – http://explain.solr.pl/explains/1w7b06lv):

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">15</int>
  <lst name="params">
    <str name="fl">id,score</str>
    <str name="debugQuery">on</str>
    <str name="indent">true</str>
    <str name="tie">0.99</str>
    <str name="q">joe blow book</str>
    <str name="qf">title^1000 description author^10</str>
    <str name="defType">dismax</str>
  </lst>
</lst>
<result name="response" numFound="2" start="0" maxScore="0.07352995">
  <doc>
    <float name="score">0.07352995</float>
    <str name="id">2</str>
  </doc>
  <doc>
    <float name="score">0.0734685</float>
    <str name="id">1</str>
  </doc>
</result>
<lst name="debug">
  <str name="rawquerystring">joe blow book</str>
  <str name="querystring">joe blow book</str>
  <str name="parsedquery">+((DisjunctionMaxQuery((author:joe^10.0 | title:joe^1000.0 | description:joe)~0.99) DisjunctionMaxQuery((author:blow^10.0 | title:blow^1000.0 | description:blow)~0.99) DisjunctionMaxQuery((author:book^10.0 | title:book^1000.0 | description:book)~0.99))~3) ()</str>
  <str name="parsedquery_toString">+(((author:joe^10.0 | title:joe^1000.0 | description:joe)~0.99 (author:blow^10.0 | title:blow^1000.0 | description:blow)~0.99 (author:book^10.0 | title:book^1000.0 | description:book)~0.99)~3) ()</str>
  <lst name="explain">
    <str name="2">
0.07352995 = (MATCH) sum of:
  0.07352995 = (MATCH) sum of:
    9.308678E-4 = (MATCH) max plus 0.99 times others of:
      8.9540955E-4 = (MATCH) weight(author:joe^10.0 in 1), product of:
        0.0024097078 = queryWeight(author:joe^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.3715843 = (MATCH) fieldWeight(author:joe in 1), product of:
          1.0 = tf(termFreq(author:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.625 = fieldNorm(field=author, doc=1)
      3.581638E-5 = (MATCH) weight(description:joe in 1), product of:
        2.4097077E-4 = queryWeight(description:joe), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:joe in 1), product of:
          1.0 = tf(termFreq(description:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
    9.308678E-4 = (MATCH) max plus 0.99 times others of:
      8.9540955E-4 = (MATCH) weight(author:blow^10.0 in 1), product of:
        0.0024097078 = queryWeight(author:blow^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.3715843 = (MATCH) fieldWeight(author:blow in 1), product of:
          1.0 = tf(termFreq(author:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.625 = fieldNorm(field=author, doc=1)
      3.581638E-5 = (MATCH) weight(description:blow in 1), product of:
        2.4097077E-4 = queryWeight(description:blow), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:blow in 1), product of:
          1.0 = tf(termFreq(description:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
    0.071668215 = (MATCH) max plus 0.99 times others of:
      0.07163276 = (MATCH) weight(title:book^1000.0 in 1), product of:
        0.24097076 = queryWeight(title:book^1000.0), product of:
          1000.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(title:book in 1), product of:
          1.0 = tf(termFreq(title:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=title, doc=1)
      3.581638E-5 = (MATCH) weight(description:book in 1), product of:
        2.4097077E-4 = queryWeight(description:book), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:book in 1), product of:
          1.0 = tf(termFreq(description:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=1)
</str>
    <str name="1">
0.0734685 = (MATCH) sum of:
  0.0734685 = (MATCH) sum of:
    7.517859E-4 = (MATCH) max plus 0.99 times others of:
      7.1632763E-4 = (MATCH) weight(author:joe^10.0 in 0), product of:
        0.0024097078 = queryWeight(author:joe^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(author:joe in 0), product of:
          1.0 = tf(termFreq(author:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=author, doc=0)
      3.581638E-5 = (MATCH) weight(description:joe in 0), product of:
        2.4097077E-4 = queryWeight(description:joe), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:joe in 0), product of:
          1.0 = tf(termFreq(description:joe)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    0.0010484984 = (MATCH) max plus 0.99 times others of:
      0.0010130403 = (MATCH) weight(author:blow^10.0 in 0), product of:
        0.0024097078 = queryWeight(author:blow^10.0), product of:
          10.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.42039964 = (MATCH) fieldWeight(author:blow in 0), product of:
          1.4142135 = tf(termFreq(author:blow)=2)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=author, doc=0)
      3.581638E-5 = (MATCH) weight(description:blow in 0), product of:
        2.4097077E-4 = queryWeight(description:blow), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:blow in 0), product of:
          1.0 = tf(termFreq(description:blow)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    0.071668215 = (MATCH) max plus 0.99 times others of:
      0.07163276 = (MATCH) weight(title:book^1000.0 in 0), product of:
        0.24097076 = queryWeight(title:book^1000.0), product of:
          1000.0 = boost
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.29726744 = (MATCH) fieldWeight(title:book in 0), product of:
          1.0 = tf(termFreq(title:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.5 = fieldNorm(field=title, doc=0)
      3.581638E-5 = (MATCH) weight(description:book in 0), product of:
        2.4097077E-4 = queryWeight(description:book), product of:
          0.5945349 = idf(docFreq=2, maxDocs=2)
          4.0530972E-4 = queryNorm
        0.14863372 = (MATCH) fieldWeight(description:book in 0), product of:
          1.0 = tf(termFreq(description:book)=1)
          0.5945349 = idf(docFreq=2, maxDocs=2)
          0.25 = fieldNorm(field=description, doc=0)
    </str>
  </lst>
</lst>
</response>

Pierwszy dokument

Drugi dokument

Czyli jak to wygląda ?

Jak widać, score poszczególnych dokumentów uległ zmianie. Spójrzmy na ten sam dokument i te same słowo book. W przypadku, kiedy przekazaliśmy wartość 0.99 jako wartość parametru tie, wartość score zwiększyła się w stosunku do tej, którą obserwowaliśmy w przypadku tie równego 0.01. Oczywiście na zmianę wartości score ma także wpływ współczynnik normalizacji, ale pomińmy go w celu uproszczenia Zatem w drugim przypadku obserwujemy score wynoszący 0.071668215, składa się na to wartość score dla pola title oraz suma wartości score dla każdego z pozostałych pól, ale tym razem pomnożonych przez wartość 0.99.

Podsumowując

Jak widać, parametr tie pozwala nam na dość dużą kontrolę tego, jak wyliczany jest score w przypadku DisjunctionMaxQuery. W ekstremalnym przypadku, kiedy chcielibyśmy, aby tylko pola, które mają najwyższy score miały znaczenie, możemy ustawić parametr tie na wartość 0.0. Tie pozwala nam na kontrolę tego, czy chcemy, aby mało znaczące pola, po których wyszukujemy, wpływały na wartość score dokumentów, a tym samym na ich pozycję na liście wyników wyszukiwania kiedy korzystamy z Dismax’a.

Na koniec

Jeżeli zastanawiasz się z pomocą czego wygenerowaliśmy wykresy, które widoczne są w treści, zapraszamy na http://explain.solr.pl/help, może http://explain.solr.pl/ będzie przydatne w Twoim przypadku.

Załóżmy, że standardowo zadawaliśmy następujące zapytanie do Solr:

q=category:1 AND category:2 AND category:3 ... AND category:2000

Zadanie takiego zapytania z domyślną konfiguracją Solr będzie skutkowało wyjątkiem i komunikatem „too many boolean clauses„. Oczywiście, moglibyśmy zmodyfikować opcję maxBooleanClauses i pozbyć się wyjątku, jednak spróbujmy zrobić to w inny sposób:

Zmieńmy zapytanie na filtry

Zmieńmy zatem powyższe zapytanie tak, aby wykorzystywało filtry, czyli parametr fq:

q=*:*&fq=category:(1 2 3 ... 2000)

Wysyłamy powyższe zapytanie i … i znów to samo – wyjątek i komunikat „too many boolean clauses„. Dzieje się tak dlatego, iż Solr musi „wyliczyć” zawartość filtra, a co za tym idzie skonstruować odpowiednie zapytanie. Dokonajmy zatem jeszcze jednej modyfikacji:

Kolejna modyfikacja zapytania

Niech nasze zapytanie wygląda w takim wypadku w następujący sposób:

q=*:*&fq=category:1&fq=category:2&fq=category:3&....&fq=category:2000

Po wysłaniu zmodyfikowanego zapytania naszym oczom ukażą się wyniki wyszukiwania (oczywiście, jeżeli w indeksie znajdują się dokumenty odpowiadające warunkom w zapytaniu). Tym razem Solr nie musiał składać jednego dużego zapytania, dlatego też nie przekroczyliśmy limitu związanego z maxBooleanClauses.

Podsumowanie

Jak widać odpowiedź na pytanie zależy od tego, jakie zapytanie chcemy, bądź musimy zadać. W przypadku, kiedy nasze warunki łączy operator logiczny AND możemy pozwolić sobie na zmianę zapytania na wiele parametrów fq ponieważ Solr łączy je automatycznie właśnie tym spójnikiem. Jeżeli natomiast zmuszeni jesteśmy stosować spójnik logiczny OR czekałaby nas zmiana limitu wyznaczonego przez maxBooleanClauses. Należy przy tym pamiętać, iż zwiększanie tego limitu może pociągnąć za sobą spadek wydajności i zwiększone wykorzystanie pamięci.

Zadawanie zapytań

Aby skorzystać z zapytań frange należy zmodyfikować składnię zapytania. Do tej pory, zapytanie o zakres danych mogło wyglądać w następujący sposób:

fq=test_si:[0+TO+10000]

w tym momencie, należy zadać to zapytanie w poniższy sposób:

fq={!frange l=0 u=10000}test_si

Oczywiście, możliwe jest również składanie zapytań o zakresy inne, niż liczbowe, na przykład:

fq={!frange l=adam u=mariusz}imie

Wydajność

Sama logika testu jest dość prosta. Struktura indeksu zawiera dwa pola: id, czyli unikalny identyfikator oraz pole namestr (typu String) w którym generuje wartości o które będę się pytał. Zaindeksowałem w ten sposób 100.000 dokumentów. Dodatkowo w każdym z dokumentów termy w polach są unikalne, tak, aby w łatwy sposób móc określić procent termów pokrytych przez dane zapytanie. Następnie zacząłem zadawać zapytania pokrywające pewien procent termów w indeksie. Każde zapytanie zadawałem kilkukrotnie uśredniając wyniki. Poniższa tabela ilustruje wynik testu:

Jak widać standardowe zapytanie o przedział danych jest szybsze tylko w przypadku zapytania, które pokrywa małą ilość termów w polu. Już od 5% termów nowy typ zapytań o przedział jest dużo szybszy, co widać w przypadku większego pokrycia, np. 50%. Co ciekawe uzyskujemy wzrost wydajności kilkukrotny, co napawa optymizmem na jeszcze szybsze wyszukiwanie.

Na koniec

Wyniki mojego testu różnią się pod względem wydajności z tym co napisał Yonik Seeley na swoim blogu (wiąże się to m.in. z tym, że dane były przygotowane szybko), jednak co by nie mówić, testy pokazują wzrost wydajności w przypadku zapytań wykorzystujących frange.

Co przechowuje

Zacznijmy od środka. FilterCache przechowuje nieuporządkowany zbiór identyfikatorów dokumentów. Oczywiście nie są to identyfikatory zdefiniowanie w pliku schema.xml jako unikalny klucz, a wewnętrzne identyfikatory dokumentów używane przez Lucene i Solr – warto o tym pamiętać.

Do czego służy

Głównym zadaniem filterCache jest przechowywanie wyników związanych z wykorzystaniem filtrów. Aczkolwiek nie jest to jego jedyne zastosowanie. Oprócz tego cache ten może służyć jako pomoc przy facetingu (w przypadku korzystania z metody TermEnum) oraz do sortowania w przypadku określenia opcji <useFilterForSortedQuery/> na true w pliku solrconfig.xml.

Definicja

Standardowa definicja filterCache wygląda następująco:

<filterCache
      class="solr.FastLRUCache"
      size="16384"
      initialSize="4096"
      autowarmCount="4096" />

Dostępne są następujące opcje konfiguracyjne:

• class – klasa odpowiadająca za implementację. Do filterCache polecam korzystanie z solr.FastLRUCache, który charakteryzuje się większą wydajnością w przypadku większej ilości operacji GET, niż PUT.
• size – maksymalna ilość wpisów jaka może znaleźć się w cache’u.
• initialSize – początkowa wielkość cache’u.
• autowarmCount – ilość wpisów jaka będzie przepisywana podczas rozgrzewania ze starego cache’u do nowego.
• minSize – wartość określająca do jakiej ilości wpisów Solr będzie próbował redukować cache w przypadku pełnego uzupełnienia.
• acceptableSize – jeżeli Solr nie będzie w stanie sprowadzić ilości wpisów do tej określonej za pomocą parametru minSize, to wartość acceptableSize będzie tą, do której będzie dążył jako kolejnej.
• cleanupThread – wartość domyślna to false. W przypadku ustawienia na true do czyszczenia cache’u będzie wykorzystywany oddzielny wątek.

W większości przypadków wykorzystanie parametrów size, initialSize oraz autowarmCount jest w zupełności wystarczające.

Jak skonfigurować

Wielkość cache’u powinna być określana na podstawie zapytań, które wysyłane są do Solr. Maksymalna wielkość filterCache powinna być przynajmniej tak duża jak ilość filtrów (wraz z wartościami) jaką wykorzystujemy. Oznacza to, że jeżeli nasza aplikacja charakteryzuje się, w zadanym okresie czasu, wykorzystaniem np. 2000 różnych filtrów (parametrów fq wraz z wartościami), to parametr size powinien być ustawiony na wartości minimum 2000.

Efektywne wykorzystanie

Jednak samo skonfigurowanie cache’u to nie koniec – ważne, aby zapytania potrafiły to wykorzystać. Weźmy na przykład zapytanie:

q=nazwa:solr+AND+kategoria:ksiazka+AND+dzial:ksiazki

Na pierwszy rzut oka zapytanie jest jak najbardziej poprawne. Jest z nim jednak jeden problem – nie korzysta z filterCache. Całe zapytanie zostanie obsłużone przez queryResultCache i stworzy w nim pojedynczy wpis. Zmodyfikujemy je trochę i zadajmy je w następujący sposób.

q=nazwa:solr&fq=kategoria:ksiazka&fq=dzial:ksiazki

Co się stanie teraz ? Tak jak w poprzednim wypadku, stworzony zostanie jeden wpis w queryResultCache oraz dwa wpisy w filterCache. Dlaczego jest to ważne ? Weźmy kolejne zapytanie:

q=nazwa:lucene&fq=kategoria:ksiazka&fq=dzial:ksiazki

To zapytanie stworzyłoby kolejny wpis w queryResultCache oraz wykorzystałoby dwa już istniejące w filterCache wpisy, a tym samym Solr skróciłbym czas wykonania zapytaniai oszczędziłby operacji I/O na indeksie.

Jeżeli natomiast wykonalibyśmy zapytanie w postaci:

q=nazwa:lucene+AND+kategoria:ksiazka+AND+dzial:ksiazki

Solr nie byłby w stanie wykorzystać żadnych informacji z cache’u i musiałby w celu zalezienia wyników pobierać wszystkie informacje z indeksu Lucene.

Kilka słów na koniec

Jak widać, samo skonfigurowanie cache’u w poprawny sposób nie gwarantuje tego, że Solr będzie w stanie go wykorzystać. To od tego jak zadajemy zapytania zależy, jak wydajny w docelowym wdrożeniu będzie Solr. Warto o tym pamiętać podczas planowania wdrożenia.

Na początek

Aby zacząć mówić o konfiguracji parametru należy najpierw powiedzieć w jaki sposób Solr pobiera wyniki za pomocą biblioteki Lucene. Przekazując, wraz z zapytaniem do Solr, parametr rows z wartością np. 20 określamy, iż chcemy aby Solr zwrócił listę wyników składającą się maksymalnie z 20 dokumentów i tyle właśnie widzimy na wynikowej liście. Jednak ilość wyników, jaka została pobrana z indeksu jest różna i określona jest właśnie parametrem queryResultWindowSize. To ten parametr, zapisany w pliku solrconfig.xml, określa jak dużo wyników zostanie pobranych z indeksu i przechowanych w queryResultCache.

Ale do czego służy queryResultWindowSize ?

Parametr queryResultWindowSize określa wielkość, tzw. okna wyników, czyli po prostu ilość dokumentów jaka zostanie pobrana przy pobieraniu wyników wyszukiwania.  Na przykład ustawiając queryResultWinwdowSize na wartość 100 i zadając zapytanie:

q=car&rows=30&start=10

na liście wyników wyszukiwania otrzymamy maksymalnie 20 dokumentów wynikowych, natomiast sam Solr pobierze tak naprawdę wyniki zaczynające się od indeksu 0, a kończące się na indeksie 100, a następnie spróbuje je umieścić w queryResultCache. Wyniki wyszukiwania kolejnych zapytań, różniących się jedynie parametrami rows i start będą mogły być pobierane z queryResultCache.

Konfiguracja

Aby ustawić queryResultWindowSize na pokazaną w powyższym przykładzie wartość 100, należy do pliku solrconfig.xml dodać następujący wpis:

<queryResultWindowSize>100</queryResultWindowSize>

O czym należy pamiętać ?

Oczywiście samo ustawienie queryResultsWindowSize to nie jest wszystko. Należy jeszcze zapewnić odpowiednią ilość miejsca w queryResultCache, aby Solr miał możliwość przechowania koniecznych informacji. Natomiast sama konfiguracja queryResultCache to już temat na inny artykuł.

Ale po co korzystać ?

Odpowiedź na tak postawione pytanie jest całkiem proste – jeżeli Twoja aplikacja i Twoi użytkownicy często korzystają ze stronicowania rozsądnym będzie rozważenie zmiany domyślnej wartości queryResultWindowSize. W większości wypadków, gdzie wdrożenia opierały się na stronicowaniu, zmiana wartości omawianego parametru powodowała zwiększenie wydajności ciężkich zapytań przy przechodzeniu pomiędzy stronami wyników.

Jednym z niewielu źródeł dotyczących facetingu jest wiki Solr, a dokładniej strona pod adresem: http://wiki.apache.org/solr/SimpleFacetParameters. Poniższy artykuł jest rozszerzeniem informacji dostępnych na wymienionej stronie.

Faceting w Solr można podzielić na cztery podstawowe rodzaje:

• faceting po polu,
• faceting za pomocą zapytania,
• faceting po datach,
• faceting po przedziałach.

Aby uruchomić mechanizm facetingu, należy do zapytania, które zadajemy do Solr dołączyć parametr facet z wartością true.

Faceting po polu

Pierwszy rodzaj facetingu, polegający na kategoryzacji znalezionych dokumentów ze względu na zawartość podanego pola. Dzięki temu rodzajowi facetingu jesteśmy w stanie pobrać ilości dokumentów znalezionych na przykład w poszczególnych kategoriach, czy w podziale na lokalizację geograficzną. Faceting ten charakteryzuje się sporą liczbą opcji i możliwości konfigurowania jego zachowań. Poniżej parametry możliwe do wykorzystania:

• facet.field – pole po którym będzie wykonywany faceting. W jednym zapytaniu może być wiele pól po którym wykonywany będzie faceting. Należy jednak liczyć się ze spadkiem wydajności w przypadku dużej ilości pól, po których wykonujemy faceting.
• facet.prefix – ogranicza wyniki facetingu do tych, które zaczynają się od podanego przedrostka. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field poprzez dodanie nazwy pola w następujący sposób: facet.NAZWA_POLA.prefix.  Z pomocą tego parametru w dość prosty sposób można wdrożyć mechanizm autocomplete.
• facet.sort – określa w jaki sposób mają być sortowane wyniki facetingu. Jeżeli korzystamy z Solr w wersji niższej, niż 1.4 parametr ten przyjmuje wartości true lub false oznaczające kolejno: sortowanie po ilości wyników oraz sortowanie według porządku w indeksie (w przypadku znaków ASCII oznacza sortowania alfabetyczne). Jeżeli natomiast korzystamy z Solr w wersji 1.4 lub wyższej powinniśmy korzystać z wartości count (oznaczającej to samo co wartość true) oraz index (oznaczającej to samo co false). Warto wiedzieć, iż wartością domyślną parametru jest wartość true/count w przypadku ustawienia parametru facet.limit na wartość 0 lub false/index w przypadku ustawienia większego limitu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field.
• facet.limit – parametr określający jak dużo unikalnych wartości ma zwrócić mechanizm facetingu dla danego pola. Wartość ujemna tego parametru oznacza brak ustawionego limitu. Należy pamiętać, iż im większy limit, tym większą ilość pamięci potrzebujemy oraz tym dłuższy czas wykonywania zapytania. Wartość domyślna parametru to 100. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field.
• facet.offset – parametr określający od którego wyniku facetingu prezentować wyniki. Wartość domyślna parametru to 0. Parametr może być wykorzystany do stronicowania wyników facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field.
• facet.mincount – parametr określający, jaką minimalną liczność musi mieć dany wynik, aby pokazany został w wynikach facetingu. Domyślna wartość tego parametru to 0. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field.
• facet.missing – parametr określający, czy oprócz standardowych wyników facetingu ma być dodany wpis o ilości dokumentów nie posiadających wpisu w danym polu. Parametr przyjmuje wartości true oraz false (wartość domyślna). Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field.
• facet.method – parametr wprowadzony w Solr 1.4, przyjmuje wartości enum oraz fc. Określa metodę wyliczania wartości facetingu. Ustawienie metody kryjącej się pod parametrem enum skutkuje wyliczeniem wszystkich termów w danym polu i wyliczeniem na tej podstawie wyników facetingu. Ta metoda wyliczenia okazuje się wydajna przy polach, które mają małą ilość unikalnych termów. Druga metoda oznaczona jako fc jest standardową metodą wyliczania facetingu dla pól jednowartościowych i polega na iterowaniu po wszystkich znalezionych dokumentach w celu wyliczenia wyników facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.field. Domyślną wartością parametru jest fc dla wszystkich pól nie opartych o typ Boolean.
  
• facet.enum.cache.minDf – parametr o dziwnie brzmiącej nazwie określający minimalną liczbę dokumentów pasujących do pojedynczego termu, aby dla tego termu użyć metody fc do wyliczania wyników facetingu. Wiem, że to brzmi pokrętnie, ale nie wiem czy da się prościej to wytłumaczyć

Tak wyglądają parametry facetingu, z jakich możemy skorzystać w przypadku pierwszego rodzaju facetingu. W większości parametrów napisałem, iż możliwe jest definiowanie parametru dla poszczególnych pól. Jak to wygląda ? Załóżmy, że zadajemy następujące zapytanie do Solr:

q=solr&facet=true&facet.field=category&facet.field=location

Proste zapytanie o term 'solr’ z włączonym mechanizmem facetingu po dwóch polach – polu category oraz polu location. Chcielibyśmy, dla pola category pokazać 200 wyników facetingu posortowanych według liczności, a dla pola location pokazać 50 wyników facetingu posortowanych alfabetycznie. Aby to osiągnąć dodajemy do naszego zapytania następujący fragment:

facet.category.limit=200&facet.category.sort=count&facet.location.limit=50&facet.location.sort=index

W pokazany sposób możemy bez problemu modyfikować zachowanie mechanizmu facetingu dla poszczególnych pól dla których jest on wyliczany w ramach zapytania.

Faceting za pomocą zapytania

Metoda facetingu oparta tak naprawdę o jeden parametr – facet.query do którego podajemy zapytanie. Zapytanie musi być zapisane tak, aby standardowy parser Lucene był w stanie je zrozumieć. Przykładem wykorzystania tego parametru jest np. zapytanie o grupę cenową, które mogłoby wyglądać na przykład tak:

facet.query=price:[0+TO+100]

Należy jednak pamiętać, iż każdy dodany do zapytania parametr facet.query to kolejne zapytanie do Lucene, co oznacza spadek wydajności całego zapytania zadawanego do Solr.

W przypadku tej metody facetingu warto wspomnieć, iż istnieje możliwość zdefiniowania własnego parsera, który ma być użyty do przetworzenia zapytania przekazanego za pomocą parametru facet.query. Aby skorzystać na przykład z parsera o nazwie myParser przekazany parametr powinien wyglądać następująco:

facet.query={!myParser}aaa.

Faceting po datach

W wersji 1.3 Solr pojawiła się nowa funkcjonalność – faceting po datach. Pozwala na wyliczanie wyników facetingu z uwzględnieniem wszystkich zawiłości związanych z przetwarzaniem dat. Należy pamiętać, iż faceting po datach może być tylko wykorzystywany z polami opartymi o typ solr.DateField. Przejdźmy więc do opisania parametrów związanych z facetingiem po datach:

• facet.date – podobnie jak parametr facet.field parametr ten służy do określenia pól, w których ma być przeprowadzany faceting po datach. Podobnie jak w przypadku parametru facet.field możliwe jest podanie tego parametru wielokrotnie, aby umożliwić faceting po datach na wielu polach w ramach jednego zapytania.
• facet.date.start – parametr określający dolną granicę daty, czyli od której daty ma być rozpoczęte wyliczanie facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.date. Parametr ten jest wymagany w przypadku korzystania z parametru facet.date.
• facet.date.end – parametr określający górną granicę daty, czyli do której daty ma być zakończone wyliczanie facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.date. Parametr ten jest wymagany w przypadku korzystania z parametru facet.date.
• facet.date.gap – parametr określający przedziały dat, jakie mają być generowane dla zdefiniowanych granic. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.date. Parametr ten jest wymagany w przypadku korzystania z parametru facet.date.
• facet.date.hardend – parametr przyjmujący wartości true oraz false, określający co Solr ma zrobić w przypadku kiedy parametr facet.date.gap nie podzieli równo przedziałów pomiędzy zdefiniowanym początkiem, a końcem. Jeżeli ustawimy ten parametr na wartość true ostatni przedział może być większy od podanego w parametrze facet.date.end końca. W przypadku ustawienia na wartość false (która jest wartością domyślną) ostatni przedział dat może być mniejszy od pozostałych. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.date.
• facet.date.other – parametr określający jakie wartości oprócz tych wyliczonych dla określonych przedziałów mają być zawarte w wynikach facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.date. Parametr może przyjmować następujące wartości:
  • before – oprócz przedziałów wyniki facetingu będą zawierać wyliczenia ilości dla dat mieszczących się przed granicą zdefiniowaną w parametrze facet.date.start,
  • after – oprócz przedziałów wyniki facetingu będą zawierać wyliczenia ilości dla dat mieszczących się za granicą zdefiniowaną w parametrze facet.date.end,
  • between – do wyników facetingu po datach zostanie dołączona informacja o licznościach w przedziale zdefiniowanym przez parametry facet.date.start oraz facet.date.end,
  • all – skrót określający, że dla danego pola mają zostać dodane trzy powyższe opcje,
  • none – wartość określająca, iż żadna dodatkowa informacja ma nie być dołączona do wyników facetingu.
• facet.date.include – parametr, który zostanie wprowadzony w Solr 4.0. Parametr pozwala na domykanie, bądź otwieranie przedziałów zdefiniowanych przy pomocy parametrów facet.date.start oraz facet.date.end. Parametr będzie przyjmował następujące wartości:
  • lower – każdy z powstałych przedziałów będzie zawierał swoją dolną granicę,
  • upper – każdy z powstałych przedziałów będzie zawierał swoją górną granicę,
  • egde – pierwszy i ostatni przedział będą zawierały swoje zewnętrzne granice – czyli dolną dla pierwszego przedziału i górną dla ostatniego przedziału,
  • outer – parametr określający, iż przedziały zdefiniowane przez wartości before i after parametru facet.date.other będą zawierały swoje granice, nawet jeżeli inne przedziały zawierają już te granice,
  • all – parametr powodujący włączenie czterech powyższych opcji.

Tak przedstawiają się opcje facetingu po datach. Poniżej przykład wykorzystania tego rodzaju facetingu:

q=solr&facet=true&facet.date=addDate&facet.date.start=NOW/DAY-30DAYS&facet.date.end=NOW/DAY%2B30DAYS&facet.date.gap=%2B1DAY

Zajmijmy się facetingiem w tym zapytaniu – faceting po datach po polu o nazwie addDate. Jako dolną granicę ustawiamy datę o 30 dni wcześniejszą niż obecna, górna granica to data o 30 dni później, niż w chwili zadawania zapytania. Przedziały mają być wielkości jednego dnia.

Faceting po przedziałach

Funkcjonalność która dostępna będzie w Solr 3.1. Jeżeli ktoś chce już teraz ją testować, to zarówno trunk, jak i branch 3.x mają tą funkcjonalność zaimplementowaną. Ta metoda facetingu powstała jako rozszerzenie pomysłu facetingu po datach. Funkcjonalność działa analogicznie do facetingu po datach, czyli w wyniku działania dostajemy listę przedziałów skonstruowanych automatycznie na podstawie parametrów. Lista parametrów, jakie charakteryzują działanie mechanizmu:

• facet.range – parametr określający po jakich polach ma być przeprowadzony faceting po przedziałach. Parametr może być przekazywany wielokrotnie.
• facet.range.start – parametr określający dolną granicę przedziałów, czyli wartość od której ma być rozpoczęte wyliczanie facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.range. Parametr ten jest wymagany w przypadku korzystania z parametru facet.range.
• facet.range.end – parametr określający dolną granicę przedziałów, czyli wartość na której ma być skończone wyliczanie facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.range. Parametr ten jest wymagany w przypadku korzystania z parametru facet.range.
• facet.range.gap – parametr określający wielkość przedziałów, jakie mają być generowane dla zdefiniowanych granic. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.range. Parametr ten jest wymagany w przypadku korzystania z parametru facet.range.
• facet.range.hardend – parametr przyjmujący wartości true oraz false, określający co Solr ma zrobić w przypadku kiedy parametr facet.range.gap nie podzieli równo przedziałów pomiędzy zdefiniowanym początkiem, a końcem. Jeżeli ustawimy ten parametr na wartość true ostatni przedział może być większy od podanego w parametrze facet.range.end końca. W przypadku ustawienia na wartość false (która jest wartością domyślną) ostatni przedział może być mniejszy od pozostałych. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.range.
• facet.range.other – parametr określający jakie wartości oprócz tych wyliczonych dla określonych przedziałów mają być zawarte w wynikach facetingu. Parametr może być definiowany dla poszczególnych pól przekazanych w parametrze facet.range. Parametr może przyjmować następujące wartości:
  • before – oprócz przedziałów wyniki facetingu będą zawierać wyliczenia ilości dla przedziału mieszczących się przed granicą zdefiniowaną w parametrze facet.range.start,
  • after – oprócz przedziałów wyniki facetingu będą zawierać wyliczenia ilości dla przedziału mieszczących się za granicą zdefiniowaną w parametrze facet.range.end,
  • between – do wyników facetingu po rozdziałach zostanie dołączona informacja o licznościach w przedziale zdefiniowanym przez parametry facet.range.start oraz facet.range.end,
  • all – skrót określający, że dla danego pola mają zostać dodane trzy powyższe opcje,
  • none – wartość określająca, iż żadna dodatkowa informacja ma nie być dołączona do wyników facetingu po przedziałach.
• facet.range.include – parametr pozwala na domykanie, bądź otwieranie przedziałów zdefiniowanych przy pomocy parametrów facet.range.start oraz facet.range.end. Parametr przyjmuje następujące wartości:
  • lower – każdy z powstałych przedziałów będzie zawierał swoją dolną granicę,
  • upper – każdy z powstałych przedziałów będzie zawierał swoją górną granicę,
  • egde – pierwszy i ostatni przedział będą zawierały swoje zewnętrzne granice – czyli dolną dla pierwszego przedziału i górną dla ostatniego przedziału,
  • outer – parametr określający, iż przedziały zdefiniowane przez wartości before i after parametru facet.date.other będą zawierały swoje granice, nawet jeżeli inne przedziały zawierają już te granice,
  • all – parametr powodujący włączenie czterech powyższych opcji.

Jak widać parametry facetingu po przedziałach są prawie identyczne, jak w przypadku facetingu po datach. Działanie jest także analogiczne. Przykładem zapytania z wykorzystaniem facetingu po datach może być następujące zapytanie:

q=solr&facet=true&facet.range=price&facet.range.start=0&facet.range.end=1000&facet.range.gap=100

Tak przeszliśmy przez wszystkie rodzaje facetingu. Jednak to jeszcze nie wszystko. Użytkownicy Solr w wersji 1.4 i wyższych mają możliwość korzystania z tzw. LocalParams wraz z facetingiem.

LocalParams i faceting

Załóżmy takie wymaganie. Mamy zapytanie, które zwraca wyniki wyszukiwania dla słowa solr oraz, które ma zdefiniowane dwa filtry jeden dla kategorii, a drugi dla kraju z którego pochodzi dokument. Oprócz wyników wyszukiwania chcemy umożliwić, w ramach wyników wyszukiwania, nawigację po regionach oraz po kategoriach, ale chcielibyśmy, aby liczności nie były od siebie zależne. To znaczy chcielibyśmy dać możliwość nawigacji po regionach dla słowa solr, ale nie zawężonych do wybranej kategorii, oraz po kategorii, ale nie zawężonej do wybranego regionu. Żeby zrobić to w Solr w wersji 1.3 lub wcześniejszej, należałoby napisać następujące zapytania:

q=solr&fq=category:search&fq=region:poland
q=solr&facet=true&facet.field=category&facet.field=region

Dwa zapytania dlatego, że po pierwsze musimy pobrać zawężone wyniki wyszukiwania, a z drugiej strony potrzebujemy niezawężonych wyników wyszukiwania po to, aby pobrać wymagane liczności za pomocą facetingu.

W przypadku Solr w wersji 1.4 lub wyższej mamy możliwość skrócenia tego do jednego zapytania. Do tego celu wykorzystamy możliwość tagowania i wykluczania tagowanych parametrów. Pierwsze zapytanie zmieniamy w następujący sposób:

q=solr&fq={!tag=categoryFQ}fq=category:search&fq={!tag=regionFQ}region:poland

Na razie wyniki wyszukiwania się nie zmienią. Do powyższego zapytania zostały dodane tagi nadające nazwę każdemu z wykorzystywanych filtrów po to, abyśmy mogli wykluczyć je w facetingu.

Drugie zapytanie modyfikujemy w następujący sposób:

q=solr&facet=true&facet.field={!ex=categoryFQ,regionFQ}category&facet.field={!ex=categoryFQ,regionFQ}region

Tutaj także na razie wyniki facetingu nie uległy zmianie. Dodaliśmy do facetingu wykluczenia, które mówią o tym, że filtry o nazwach categoryFQ oraz regionFQ mają nie być brane pod uwagę przy wyliczaniu wyników facetingu.

Tak zmodyfikowane zapytanie łączymy w jedno, które powinno wyglądać następująco:

q=solr&fq={!tag=categoryFQ}fq=category:search&fq={!tag=regionFQ}region:poland&facet=true&facet.field={!ex=categoryFQ,regionFQ}category&facet.field={!ex=categoryFQ,regionFQ}region

Więcej o LocalParams napiszę w jednym z kolejnych wpisów.

Kilka słów na koniec

Mam nadzieję, że tym artykułem przybliżyłem możliwości wykorzystania facetingu w Solr, zarówno w starszych wersjach, w tej obecnej, jak i tych, które pojawią się w przyszłości.