Ważna uwaga – funkcjonalność ta w tym momencie jest dostępna tylko i wyłącznie w wersji 4.0 Solr, czyli w wersji rozwojowej. Oznaczenie 4.0 jest oznaczeniem kodu, który znajduje się w trunk’u repozytorium SVN.

Kilka słów na początek

W wielu projektach w jakich miałem okazję zajmować się była konieczność wprowadzenia hierarchicznego facetingu. Jednym z prostszych przykładów jest wymaganie polegające na pokazaniu miejscowości w województwach i ilości dokumentów zarówno w województwach, jak i w poszczególnych miejscowościach. Do tej pory, bez zmiany struktury danych, nie było możliwości zrealizowania takiej funkcjonalności. Teraz już jest

Indeksowanie

Aby nie potrzebnie nie komplikować opisywanych funkcjonalności zdecydowałem się na skorzystanie z przykładowych dokumentów XML dostępnych w katalogu /exampledocs przykładowego wdrożenia. Nie modyfikowałem także pliku schema.xml, czy solrconfig.xml, tak więc konfiguracje zostały standardowe. I tyle jeżeli chodzi o konfigurację. Tak więc możemy uruchomić indeksację (komenda wywołana z katalogu $SOLR_HOME/exampledocs/):

./post.sh *.xml

Kilka ekranów informacji i mamy zaindeksowane dane.

Mechanizm

Samo skorzystanie z hierarchicznego facetingu nie jest trudne. Twórcy Solr dali nam do dyspozycji dwa dodatkowe parametry:

• facet.pivot – lista pól oddzielonych przecinkami, która pokazuje po jakich polach i w jakiej kolejności wyliczyć strukturę,
• facet.pivot.mincount – minimalna ilość dokumentów, aby wynik został uwzględniony w facetingu. Wartość domyślna parametru to 1.

Spróbujmy więc.

Zapytania

Na początek próba z dwoma polami. Pobieram wszystkie dokumenty z indeksu i dodaje parametr facet.pivot=cat,inStock, czyli mówię Solr, że chce dostać wyniki hierarchicznego facetingu, gdzie pierwszym poziomem hierarchii jest pole cat, a drugim poziomem jest pole inStock. Zapytanie wygląda w następujący sposób:

http://localhost:8983/solr/select/?q=*:*&facet=true&facet.pivot=cat,inStock

Aby skrócić listing pominąłem część odpowiedzialną za wyniki wyszukiwania wraz z nagłówkiem.

<?xml version="1.0" encoding="UTF-8"?>
<response>
.
.
.
<result name="response" numFound="19" start="0"/>
<lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields"/>
  <lst name="facet_dates"/>
  <lst name="facet_ranges"/>
  <lst name="facet_pivot">
    <arr name="cat,inStock">
      <lst>
        <str name="field">cat</str>
        <str name="value">electronics</str>
        <int name="count">17</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">13</int>
          </lst>
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">4</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">memory</str>
        <int name="count">6</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">6</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">connector</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">graphics card</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">hard drive</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">monitor</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">search</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">software</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
    </arr>
  </lst>
</lst>
</response>

Sama prezentacja wyników facetingu, w tym wypadku, uległa zmianie. Dla każdej wartości głównego poziomu mamy znaczniki określające pole (znacznik z atrybutem name=”field”), wartość (znacznik z atrybutem name=”value”) oraz ilość dokumentów (znacznik z atrybutem name=”count”). Następnie mamy tablicę wyników drugiego poziomu (znacznik z atrybutem name=”pivot”). Tablica ta zawiera elementy takie same jak poziom pierwszy, czyli nazwa pola, wartość w polu oraz ilość dokumentów z daną wartością.

Zobaczmy, jak mechanizm ten daje sobie radę z większą ilością zagłębienia. W tym celu zadałem następujące zapytanie do tej samej wersji Solr:

http://localhost:8983/solr/select/?q=*:*&facet=true&facet.pivot=cat,inStock,features

Jak w powyższym przypadku w pominąłem nagłówek odpowiedzi wraz z wynikami zostawiając same wyniki facetingu. Dodatkowo, ze względu na długość wyników facetingu przedstawiam wyniki tylko dla jednej kategorii głównej pomijając resztę:

<?xml version="1.0" encoding="UTF-8"?>
<response>
.
.
.
<result name="response" numFound="19" start="0"/>
<lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields"/>
  <lst name="facet_dates"/>
  <lst name="facet_ranges"/>
  <lst name="facet_pivot">
    <arr name="cat,inStock,features">
      <lst>
        <str name="field">cat</str>
        <str name="value">electronics</str>
        <int name="count">17</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">13</int>
            <arr name="pivot">
              <lst>
                <str name="field">features</str>
                <str name="value">2</str>
                <int name="count">7</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">3</str>
                <int name="count">7</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">lcd</str>
                <int name="count">5</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">x</str>
                <int name="count">5</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ca</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">latenc</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">tft</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">v</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">0</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">1</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">25</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">30</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">5</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">7</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">8</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">time</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">up</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">000</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">19</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">20</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">2336</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">27</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">275</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">6</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">75</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">activ</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">built</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">cach</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">color</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">flash</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">heat</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">heatspread</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">matrix</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mb</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ms</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">photo</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">resolut</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">seek</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">speed</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">spreader</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">unbuff</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">usb</str>
                <int name="count">2</int>
              </lst>
            </arr>
          </lst>
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">4</int>
            <arr name="pivot">
              <lst>
                <str name="field">features</str>
                <str name="value">0</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">1</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">16</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">2</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">20</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">3</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">9</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">90</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">adapt</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">car</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">clock</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">direct</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">directx</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">dual</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">dvi</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">express</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gddr</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ghz</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gl</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gpuvpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">hdtv</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mb</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mhz</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">open</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">opengl</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">out</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">pci</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">power</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">vpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">white</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">x</str>
                <int name="count">2</int>
              </lst>
            </arr>
          </lst>
        </arr>
      </lst>
    </arr>
  </lst>
</lst>
</response>

Jak widać na zaprezentowanym przykładzie, również w tym wypadku Solr nie miał problemów z poprawnym wyliczeniem hierarchii. Sama część prezentacyjna wzbogaciła się o jeden poziom zagłębienia, który podlega tym samym zasadom co reszta poziomów.

Kilka słów na koniec

Moim zdaniem jedna z bardziej przydatnych funkcjonalności dla „zwykłego” użytkownika. Niestety na razie dostępna tylko w wersji developerskiej Solr. Nie znalazłem także informacji o tym, czy planowane jest przeniesienie tej funkcjonalności do wersji 1.5 Solr, czyli gałęzi o nazwie branch_3x w SVN. Jednak, ważne jest to, że taka funkcjonalność powstała i wcześniej, czy później użytkownicy Solr będą mogli z niej korzystać.

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.

1. Brak wykorzystania filtrów

Jednym z podstawowych błędów jakie spotykam co jakiś czas jest brak wykorzystania filtrów, czyli prosto mówiąc brak wykorzystania parametru fq w zapytaniach. Pamiętajmy o tym, filtry to nasi przyjaciele Dzięki filtrom cache wykorzystywany jest bardziej optymalnie. Filtry nie wpływają na ważność dokumentu w kontekście zapytania (współczynnik score), a co za tym idzie, możemy wykonywać zawężania bez obawy o zmianę wartości score poszczególnych dokumentów (przydatne np. w sklepach e-commerce w przypadku zawężania grup produktów).

2. Warunki logiczne i parametr q

Kolejny z „grzechów” jakie spotykam dość często, dość mocno związany z poprzednim punktem. Nie jest to może błąd w dosłownym tego słowa znaczeniu, aczkolwiek, jest to obszar, gdzie prosta zmiana będzie miała spory wpływ na wydajność. Zakładając, że domyślnym operatorem logicznym jest OR, wyobraźmy sobie zapytanie w postaci q=(java+wzorce+projektowe)+AND+kategoria:ksiazki+AND+promocja:true+AND+wydawnictwo:ABC. Zapytanie to jest jak najbardziej poprawne z punktu widzenia logiki aplikacji, gdzie mamy dostać odpowiednią grupę wyników wyszukiwania. Co jednak, jeżeli chcemy, aby także optymalnie wykorzystywało cache Solr, a tym samym wykonywało się szybciej. Odpowiedź jest dość prosta – należy przenieść niektóre z warunków do filtrów. Zmieniając przedstawione zapytanie na q=java+wzrce+projektowe&fq=kategoria:ksiazki&fq=promocja:true&fq=wydawnictwo:ABC Solr skorzysta z dwóch rodzajów cache – queryDocumentCache w celu pobrania dokumentów dla zapytania z parametru q oraz z filterCache dla każdego z filtrów. Zmiana zapytania w pokazany sposób pozwoliła na wykorzystanie dodatkowego cache oraz na uporządkowanie wpisów w queryDocumentCache (ze względu na skrócenie zapytania w parametrze q).

3. Ogromne ilości facet query

Kolejny „grzech” związany z obsługą grup dokumentów. Dość często, szczególnie, w przypadku aplikacji które mają dużą ilość parametrów pozwalających kategoryzować produkty spotykałem zapytania z dużą ilością parametrów facet.query. Zapytania te używane były do wyświetlania grup dokumentów – według ceny, lokalizacji, grup i tak dalej. Dobrym przykładem jest grupowanie po cenie, gdzie klient biznesowy może określać przedziały cenowe dla poszczególnych kategorii i na tym podstawie grupować produkty. Pamiętajmy, że dołożenie do zapytania 100, czy 200 razy parametru facet.query odbija się na wydajności i to czasami dość znacznie. Jeżeli interesuje nas szybka reakcja Solr nie możemy stosować takich zapytań. W takich wypadkach zawsze proponuję modyfikację struktury indeksu, czyli stworzenie odpowiednich przedziałów w importerze aplikacji i przekazywanie do Solr identyfikatorów tych przedziałów, które tłumaczy aplikacja. Pozwala to na zlikwidowanie dziesiątek, czy setek facet.query na rzecz jednego parametru facet, po odpowiednim polu (oczywiście w przykładzie z grupami zależnymi od kategorii mogą to być pola dynamiczne). Wiąże się z jeszcze jedną niedogodnością – wytłumaczeniem klientowi, dlaczego musi nacisnąć przycisk reindeksacji danych po zmianach przedziałów. Z reguły jednak testy wydajnościowe przy dużym obciążeniu i dużej różnorodności zapytań mówią same za siebie.

4. Limity facetingu

Problem pojawiający się na styku zapytań zadawanych do Solr, a logiki biznesowej jaką realizować ma aplikacja korzystająca z Solr. Przykładem tego „grzechu” jest prosta lista kategorii, którą klient chce mieć wyświetlaną w zależności od strony na jakiej znajduje się użytkownik. Kiedy kategorii jest mało nie mamy problemu, gorzej kiedy tych kategorii jest bardzo dużo. Bardzo często spotykałem się z podejściem ze strony programistów, aby pobierać wszystkie kategorie z Solr (z mocno zwiększonym w stosunku do domyślnego parametrem facet.limit) i dopiero w aplikacji zawężać te wyniki. Według mnie jest to podejście, które może generować problemy – po pierwsze faceting wymaga pamięci, po drugie czasu na przetworzenie i agregację wyników. Co więcej, pobranie wszystkich 50.000 kategorii wraz z licznościami może być bolesne dla Solr. Jeżeli zależy nam na szybkich zapytaniach, starajmy się korzystać z parametru facet.limit rozsądnie i ewentualnie tak budować aplikację, aby możliwe było stronicowanie wyników facetingu i korzystanie tym samym z parametru facet.offset. Jeżeli nie jest to możliwe, to przynajmniej skonfigurujmy tak kontener w którym działa Solr, aby miał wystarczającą ilość pamięci, aby obsłużyć równoległe zapytania i przygotujmy się, że zapytania z dużą wartością facet.limit mogą wykonywać się dłużej, niż inne.

5. Pobieranie niepotrzebnych danych

Bardzo często spotykanym problemem jest pobieranie wszystkich informacji, a nie tylko tych, które są nam potrzebne. Oczywiście problem nie dotyczy wdrożeń, gdzie Solr serwuje informacje takie jak na przykład identyfikator produktu i tylko identyfikator. Jednak, duża ilość wdrożeń z którą miałem do czynienia opierała się prawie w całości na Solr, a co za tym idzie indeks składał się z wielu pól z atrybutem stored ustawionym na wartość true. Programiści korzystający z Solr bardzo rzadko korzystali z parametru fl oraz możliwości ograniczania pól, które są zwracane odpowiedzi. W ekstremalnych przypadkach prowadziło to do problemów z ilością danych, jakie trzeba było przesyłać przez sieć.

6. Wiele zapytań do uzyskania liczności grup dokumentów

W niektórych wdrożeniach ważniejsze od standardowego wyszukiwania, gdzie użytkownik wpisuje frazę jaką chce znaleźć, jest przechodzenie do dokumentów za pomocą nawigacji, na przykład przy pomocy działów, kategorii, podkategorii i tak dalej. Bardzo często oprócz na przykład nazwa kategorii podaje się także informacje takie jak ilość dokumentów w tej kategorii, czyli np. produktów. Spotkałem się z przypadkami, gdzie ilości dokumentów w poszczególnych kategoriach były pobierane za pomocą oddzielnych zapytań. Skutek – wyświetlenie 100 kategorii na formatce skutkowało taką samą ilością zapytań do Solr. Nie róbmy tego – jeżeli trzeba zmodyfikujmy indeks Solr tak, aby możliwe było wykorzystanie mechanizmów facetingu. Może w danym momencie będzie to więcej pracy, ale na pewno w dłuższej perspektywie czasu się to opłaci.

Kilka słów na koniec

Należy pamiętać, że są to tylko przykłady, które uważam za dość powszechne, a przynajmniej na które dość często natknąłem się podczas pracy. Nie są to na pewno wszystkie błędy popełniane przy korzystaniu z Solr, jednak mam nadzieję, że przynajmniej w pewnym stopniu uwypuklają stronę w którą należy spoglądać generując zapytania do Solr, czy optymalizując już istniejące.