Dane testowe

Do naszych testów wykorzystamy dane dostarczane wraz z domyślną dystrybucją Solr. Do uruchomienia Solr wykorzystujemy komendę:

bin/solr start -e techproducts

Spowoduje to uruchomienie Solr oraz zaindeksowanie przykładowych danych – wszystko to w kolekcji techproducts.

Przykład pierwszy

Zacznijmy od bardzo prostego przykładu z wykorzystaniem nowego facetingu – spróbujmy pobrać od Solr faceting dotyczący producentów oraz kategorii naszych produktów. Zapytanie, do którego jesteśmy przezwyczajeni wyglądało by następująco:

curl 'localhost:8983/solr/techproducts/select?q=*:*&rows=0&indent=true&facet=true&facet.field=manu_id_s&facet.field=cat'

Zapytanie wykorzystujące nowe API wygląda następująco:

curl http://localhost:8983/solr/techproducts/query -d 'q=*:*&rows=0&
 json.facet={
  categories : {
   terms : {
    field: cat
   }
  },
  producers : {
   terms : {
    field: manu_id_s
   }
  }
 }'

Odpowiedź na powyższe zapytanie wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2,
    "params":{
      "q":"*:*",
      "json.facet":"{\n  categories : {\n   terms : {\n    field: cat\n   } \n  },\n  manu : {\n   terms : {\n    field: manu_id_s\n   }\n  }\n}",
      "rows":"0"}},
  "response":{"numFound":32,"start":0,"docs":[]
  },
  "facets":{
    "count":32,
    "categories":{
      "buckets":[{
          "val":"electronics",
          "count":12},
        {
          "val":"currency",
          "count":4},
        {
          "val":"memory",
          "count":3},
        {
          "val":"connector",
          "count":2},
        {
          "val":"graphics card",
          "count":2},
        {
          "val":"hard drive",
          "count":2},
        {
          "val":"search",
          "count":2},
        {
          "val":"software",
          "count":2},
        {
          "val":"camera",
          "count":1},
        {
          "val":"copier",
          "count":1}]},
    "manu":{
      "buckets":[{
          "val":"corsair",
          "count":3},
        {
          "val":"belkin",
          "count":2},
        {
          "val":"canon",
          "count":2},
        {
          "val":"apple",
          "count":1},
        {
          "val":"asus",
          "count":1},
        {
          "val":"ati",
          "count":1},
        {
          "val":"boa",
          "count":1},
        {
          "val":"dell",
          "count":1},
        {
          "val":"eu",
          "count":1},
        {
          "val":"maxtor",
          "count":1}]}}}

Jak widać samo zapytanie, jak i odpowiedź jest czymś do czego nie jesteśmy przezwyczajeni w pracy z Solr. Zacznijmy więc od zapytania.

Zapytanie

Tym razem zapytanie wysłaliśmy do handlera query, ale nie to jest ważne. Najważniejsze jest to, jak wygląda samo zapytanie. Wszystkie parametry zapytania nie zostały przekazane jako parametry rządania HTTP. Tym razem wszystkie parametry zostały przekazane w ciele rządania w formie podobnej do tego do czego jesteśmy przezwyczajeni. Oprócz tego dodaliśmy nowy parametr – facet.json, gdzie zdefiniowaliśmy nasz faceting.

W Solr 5.1, każdy faceting, jaki chcemy wykonać definiujemy następująco:

NAZWA: {
 TYP: {
  PARAMETR: WARTOSC
  ...
  PARAMETR: WARTOSC
 }
}

W Solr 5.2, ten format zmieni się delikatnie, ale wrócimy do tego, jak tylko pojawi się Solr 5.2. W naszym przykładzie wykorzystaliśmy typ terms, który funkcjonuje tak samo, jak zachowanie znane nam, gdy korzystaliśmy z facet.field. Inne typy to np. query, czy range. Po możliwe do wykorzystania parametry odsyłamy do oficjalnej dokumentacji Solr.

Wyniki

Jeżeli natomiast spojrzymy na wyniki zwrócone przez Solr widzimy coś co nazywa się buckets. Są to grupy klucz – wartość opisujące nasz faceting – niby coś nowego, ale jednak znajome. Korzystając z nowego API facetingu możemy spotkać się z dwoma rodzajami zwracanych wyników – pojedyńczą wartością oraz właśnie bucketami. Opiszemy to dokładniej w chwili premiery Solr 5.2.

Facting i funkcje

Sprawdźmy jeszcze jeden przypadek – znalezienie średniej ceny produktów oraz 99 percentyla ceny. Solr umożliwia skorzytanie z szeregu funkcji w ramach nowego modułu facetingu, a zapytanie które umożliwi nam realizację naszego celu wygląda następująco:

curl http://localhost:8983/solr/techproducts/query -d 'q=*:*&rows=0&
 json.facet={
  average:"avg(price)",
  percentile:"percentile(price,99)"
 }'

Wynik zapytania wygląda następująco:

{
  "responseHeader":{
    "status":0,
    "QTime":2,
    "params":{
      "q":"*:*",
      "json.facet":"{\n  average:\"avg(price)\",\n  percentile:\"percentile(price,99)\"\n }",
      "rows":"0"}},
  "response":{"numFound":32,"start":0,"docs":[]
  },
  "facets":{
    "count":32,
    "average":164.10218846797943,
    "percentile":1966.6484985351556}}

Solr zwrócił to co chcieliśmy, a Solr zwrócił pojedyncze wartości dla każdej z funkcji.

Co dalej?

Oczywiście to nie wszystko co Solr oferuje nam w tym momencie oraz co planowane jest w przyszłości. Po pierwsze ilość funkcji zostanie rozszerzona – np. o możliwość pobierania unikalnych wartości. Dodatkowo, w Solr 5.2, dostaniemy możliwość zagnieżdżania facetingu i genrowania wyników zapytań zwracających np. minimalne wartości, dla każdej z grup kategorii zwróconej przez terms faceting.

Kilka słów na początek

Ze względu na to, że jest to niejako kontynuacja poprzedniego wpisu, sugerujemy, aby przeczytać wpis „Autocomplete na polach wielowartościowych (highlighting)„, aby wszystkie elementy wpisu były jasne. Warto także wspomnieć, iż metoda ta była już pokazywana we wpisie „Solr i autocomplete (cz. 1)„, aczkolwiek chcieliśmy przypomnieć ten temat ze względu na częstotliwość pojawiających się pytań.

Konfiguracja

Podobnie, jak w poprzednim wpisie zacznijmy od konfiguracji.

Struktura indeksu

Struktura naszego indeksu nie różni się od tego co zaprezentowane było w poprzednim wpisie. Jednak, przypomnijmy te informacje – zakładamy, że chcemy podpowiadać frazy z indeksu z pola wielowartościowego. Pole to nazywa się features, a cała konfiguracja pól w indeksie będzie następująca:

<fields>
 <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" />
 <field name="features" type="string" indexed="true" stored="true" multiValued="true"/>
 <field name="features_autocomplete" type="text_autocomplete" indexed="true" stored="true" multiValued="true"/>

 <field name="_version_" type="long" indexed="true" stored="true"/>
</fields>

Do autocomplete będziemy wykorzystywać pole features_autocomplete.

Kopiowanie

Dodatkowo, aby automatycznie zasilać danymi pole features_autocomplete skorzystamy z funkcjonalności copy field, a zatem do pliku schema.xml dodajemy następujący wpis:

<copyField source="features" dest="features_autocomplete"/>

Typ text_autocomplete

Typ text_autocomplete różni się od tego, co widzieliśmy w poprzednim wpisie. Tym razem wygląda on następująco:

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

Ze względu na to, że będziemy korzystać z facetingu korzystamy z solr.KeywordTokenizerFactory oraz sprawiamy, aby wszystkie znaki były małe za pomocą solr.LowerCaseFilterFactory.

Przykładowe dane

Nasze dane są identyczne do tych, które wykorzystaliśmy w poprzednim wpisie i wyglądają następująco:

<add>
 <doc>
  <field name="id">1</field>
  <field name="features">Multiple windows</field>
  <field name="features">Single door</field>
 </doc>
 <doc>
  <field name="id">2</field>
  <field name="features">Single window</field>
  <field name="features">Single door</field>
 </doc>
 <doc>
  <field name="id">3</field>
  <field name="features">Multiple windows</field>
  <field name="features">Multiple doors</field>
 </doc>
</add>

Zapytanie z facetingiem

Zobaczmy zatem, jak wyglądać będzie nasze zapytanie, kiedy wykorzystamy faceting.

Pełne zapytanie

W przypadku facetingu nasze zapytanie powinno wyglądać następująco:

q=*:*&rows=0&facet=true&facet.field=features_autocomplete&facet.prefix=sing

Kilka słów o dodanych parametrach:

• rows=0 – informujemy Solr, że nie jesteśmy zainteresowani wynikami wyszukiwania,
• facet=true – informujemy Solr, iż chcemy korzystać z facetingu,
• facet.field=features_autocomplete – określamy jakie pole ma zostać wykorzystane do facetingu,
• facet.prefix=sing – za pomocą tego parametru przekazujemy interesującą nas frazę.

Wyniki

Wyniki, które Solr zwraca na powyższe zapytanie, wyglądają następująco:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="facet">true</str>
    <str name="q">*:*</str>
    <str name="facet.prefix">sing</str>
    <str name="facet.field">features_autocomplete</str>
    <str name="rows">0</str>
  </lst>
</lst>
<result name="response" numFound="3" start="0">
</result>
<lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields">
    <lst name="features_autocomplete">
      <int name="single door">2</int>
      <int name="single window">1</int>
    </lst>
  </lst>
  <lst name="facet_dates"/>
  <lst name="facet_ranges"/>
</lst>
</response>

Jak widać, w sekcji odpowiedzialnej za faceting, otrzymaliśmy te frazy, które nas interesowały wraz z ilością dokumentów w jakich się znajdują.

O czym pamiętać

Ważną rzeczą jest to, że wartości parametru facet.prefix nie są analizowane, zatem jeżeli zamiast frazy sing przekazalibyśmy frazę Sing Solr nie zwróciłby interesujących nas wyników. Należy o tym pamiętać.

Podsumowanie

Powyższy wpis pokazał drugi sposób podejścia do realizacji funkcjonalności autocomplete na polach wielowartościowych. Oczywiście nie wyczerpaliśmy tematu i kiedyś do niego wrócimy, ale na dzisiaj to wszystko. Mamy nadzieję, że komuś się przyda to co znalazł w tych artykułach

Indeks

Załóżmy, że chcemy podpowiadać użytkownikowi nazwy produktów w sklepie internetowym. Załóżmy, że nasz indeks składa się z następujących pól:

<field name="id" type="string" indexed="true" stored="true" multiValued="false" required="true"/>
<field name="name" type="text" indexed="true" stored="true" multiValued="false" />
<field name="description" type="text" indexed="true" stored="true" multiValued="false" />

A typ text zdefiniowany jest w następujący sposób:

<fieldType name="text" class="solr.TextField" positionIncrementGap="100"> 
 <analyzer>
  <tokenizer class="solr.WhitespaceTokenizerFactory"/>
  <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1"/> 
  <filter class="solr.LowerCaseFilterFactory"/>
 </analyzer>
</fieldType>

Konfiguracja

Na początku należy zastanowić się co chcemy uzyskać. Czy chcemy aby podpowiadane były tylko poszczególne wyrazy składające się na frazy, czy może jednak pełne nazwy rozpoczynające się na podane przez użytkownika litery. W zależności od naszych wyborów musimy przygotować odpowiednie pole, na podstawie którego będziemy budować podpowiedzi.

Podpowiadanie pojedynczych wyrazów składających się na nazwę

W przypadku podpowiadania pojedynczych wyrazów powinniśmy podpowiadanie oprzeć o pole, które będzie odpowiednio tokenizowane. W naszym przypadku pole name będzie wystarczające. Należy jednak pamiętać, iż jeżeli chcemy korzystać np. ze stemmingu należałoby zdefiniować kolejny typ, który były go pozbawiony, ze względu na to jak taka analiza działa na zawartość pola.

Podpowiadanie pełnych nazw

W przypadku podpowiadania pełnych nazw produktów potrzebujemy innej konfiguracji pola na którym oprzemy podpowiadanie – najlepsze do tego będzie pole nietokenizowane. Nie możemy jednak wykorzystać do tego celu typu string – ze względu na to. W tym celu definiujemy pole następująco:

<field name="name_auto" type="text_auto" indexed="true" stored="true" multiValued="false" />

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

<fieldType name="text_auto" class="solr.TextField">
 <analyzer>
  <tokenizer class="solr.KeywordTokenizerFactory"/>
  <filter class="solr.LowerCaseFilterFactory"/>
 </analyzer>
</fieldType>

Aby nie było konieczności modyfikacji formatu danych dodajemy dodatkowo odpowiednią definicję kopiowania informacji:

<copyField source="name" dest="name_auto" />

Jak to wykorzystać ?

Mając już odpowiednio zaindeksowane dane możemy zacząć korzystanie z Solr. Aby skorzystać z tak przygotowanych danych skorzystać wystarczy dość proste zapytanie:

q=*:*&facet=true&facet.field=POLE&facet.mincount=1&facet.prefix=ZAPYTANIE_UŻYTKOWNIKA

Gdzie:

• POLE – pole na jakiego podstawie mamy zamiar realizować podpowiadanie. W naszym przypadku name_auto.
• ZAPYTANIE_UŻYTKOWNIKA – litery, które wpisał użytkownik.

Warto zauważyć parametr rows=0 dodany po to, aby widoczny był tylko wynik facetingu. Oczywiście nie jest to konieczność.

Na przykład:

fl=id,name&rows=0&q=*:*&facet=true&facet.field=name_auto&facet.mincount=1&facet.prefix=dys

Wynik powyższego zapytania mógłby wyglądać następująco:

<response>
 <lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
 </lst>
 <result name="response" numFound="4" start="0"/>
 <lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields">
   <lst name="name_auto">
    <int name="dysk twardy">1</int>
    <int name="dysk twardy samsung">1</int>
    <int name="dysk twardy seagate">1</int>
    <int name="dysk twardy toshiba">1</int>
   </lst>
  </lst>
  <lst name="facet_dates"/></lst>
</response>

Dodatkowe możliwości

Warto wspomnieć o dodatkowych możliwościach jakie niesie za sobą ta metoda.

Pierwsza z możliwości to pokazanie użytkownikowi dodatkowych informacji takich jak ilość wyników jaką dostanie użytkownik po wybraniu odpowiedniej podpowiedzi. Jeżeli chcemy pokazywać takie informacje będzie to na pewno ciekawa opcja.

Możliwość wyboru sortowania wyników facetingu, czyli standardowe wykorzystanie parametru facet.sort. W zależności od potrzeb możemy posortować wyniki po ilości dokumentów (domyślne zachowanie, wartość parametru ustawiamy na true) lub alfabetycznie (wartość parametru ustawiamy na false).

Możemy ograniczyć podpowiedzi, aby nie były generowane te, które mają mniejszą, niż określona ilość wyników. Aby skorzystać z tej możliwości należy przekazać w parametrze facet.mincount ilość dokumentów od jakiej mają być pokazywane wyniki.

I jak dla mnie największy plus tej metody – możliwość prostego pobierania podpowiedzi tylko tych, które pasują do zapytania użytkownika oraz dodatkowych parametrów, takich jak np. kategoria w której się znajduje. Na przykład chcemy pokazać podpowiedzi dla użytkownika, który znajduje się w dziale AGD naszego sklepu. Podejrzewamy, że w tej chwili nie będą go interesować produkty typu odtwarzacze DVD i dlatego dodajemy parametr fq=dział:agd (zakładając, że mamy taki dział). Po tak zmodyfikowanym zapytaniu, użytkownik nie dostanie podpowiedzi wygenerowanych z całego indeksu, a zawężone, do tego jaki dział przegląda.

Kilka słów na zakończenie

Jak wiele metod i ta ma swoje plusy i minusy. Plusem tego rozwiązania jest łatwość jego wykorzystania, brak dodatkowych komponentów oraz to, że wyniki podpowiedzi można w bardzo prosty sposób zawężać, aby były generowane tylko z tych dokumentów, które pasują do zapytania wpisanego przez użytkownika. Jako duży plus można zaliczyć pokazywanie ilości dokumentów, jakie dostanie użytkownik wybierając daną podpowiedź (oczywiście przy zachowaniu takich samych parametrów wyszukiwania). Do minusów należy na pewno konieczność posiadania dodatkowych typów i pól obsługujących podpowiedzi, wbrew pozorom dość ograniczone możliwości oraz obciążenie Solr powodowane przez mechanizm facetingu.

W następnym wpisie dotyczącym funkcjonalności autocomplete postaram się rozszerzyć temat i pokazać kolejne metody generowania podpowiedzi za pomocą Solr.

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.

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

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

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

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

1. Wyszukiwanie

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

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

2. Redefinicja zapytania

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

3. Filtracja

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

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

4. Sortowanie

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

5. Przeglądanie Wyników

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