Dzisiaj przyjrzymy się bardziej rozbudowanej funkcjonalonści autocomplete – takiej, która jest w stanie poradzić sobie ze znakami specjalnymi lub inaczej, znakami niewystępującymi w standardowym zbiorze ASCII.

Autocomplete ze znakami specjalnymi

Załóżmy, że nasze dokumenty, na podstawie których chcemy generować wyniki autocomplete, mają tylko dwa pola – identyfikator i pole name. W polu name możemy napotkać znaki specyficzne dla danego języka, np. takie jak ż, ć lub ę w języku polskim. Co byśmy chcieli to umożliwić generowanie autocomplete dla osób, które nie posiadają klawiatury umożliwiającej wpisanie takich znaków, badź locale, które to umożliwiają w systemie. Zakładamy, iż mamy zaindeksowane następujące dokumenty:

{"id":1, "name":"Pośrednictwo nieruchomości"}
{"id":2, "name":"Posadowienie budynków"}
{"id":3, "name":"Posocznica"}

Same nazwy nie są znaczące, ważne jest co chcemy osiągnąć. Chcielibyśmy dostać wszystkie trzy dokumenty wpisując pos lub poś. Czy jest to możliwe? Tak i za chwilę zobaczymy, jak to zrobić.

Przygotowanie konfiguracji kolekcji

Zacznijmy od pliku konfiguracyjnego schema.xml i definicji pól i ich typów. Kompletnie zignorujemy w tym wypadku wyszukiwanie pełno tekstowe i skoncentrujemy się tylko i wyłącznie na funkcjonalności autocomplete. Dodatkowo zakładamy, iż chcemy zwrócić zawsze całą wartość pola name, jeżeli tylko trafimy w jakikolwiek term w polu name. Definicja naszych pól w pliku schema.xml wygląda następująco:

<field name="id" type="int" indexed="true" stored="true" required="true" multiValued="false" />
<field name="name" type="string" indexed="false" stored="true" multiValued="false" />
<field name="name_ac" type="text_ac" indexed="true" stored="false" multiValued="false" />

Mamy więc pole id, które jest typu int oraz pole name, które używane jest tylko w celu wyświetlania danych. Pole name_ac to te, z za pomocą którego będziemy generować podpowiedzi autocomplete. Aby ręcznie nie wypełniać pola name_ac skorzystamy z tzw. copyField, który przez analizą skopiuje dane z jednego pola do drugiego (umieszczamy to także w pliku schema.xml):

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

Typ pola name_ac oparty zostanie o mechanizm ngram, czyli przyrostowe generowanie coraz dłuższego przedrostka wartości występującej w tym polu. Do usunięcia znaków pochodzących spoza standardowej tablicy ASCII skorzystamy z filtra solr.ASCIIFoldingFilterFactory. Oczywiście, filtra potrzebujemy zarówno podczas indeksowania, jak i podczas analizy zapytań. Zatem definicja typu text_ac wyglądać będzie następująco:

<fieldType name="text_ac" class="solr.TextField" positionIncrementGap="100">
  <analyzer type="index">
    <tokenizer class="solr.KeywordTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.ASCIIFoldingFilterFactory"/>
    <filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="100" />
  </analyzer>
  <analyzer type="query">
    <tokenizer class="solr.KeywordTokenizerFactory"/>
    <filter class="solr.LowerCaseFilterFactory"/>
    <filter class="solr.ASCIIFoldingFilterFactory"/>
  </analyzer>
</fieldType>

Jak widać jedyną różnicą pomiędzy analizą podczas indeksowania, a tą podczas zapytania jest wykorzystanie filtra solr.EdgeNGramFilterFactory w trakcie indeksowania. Powoduje on przyrostowe generowanie przedrostka i umieszczenie tych wartości w danym polu. Filtra tego nie potrzebujemy podczas zadawania zapytań.

Czas testowania

Aby przetestować to co zrobiliśmy uruchomimy Solr w wersji SolrCloud z wbudowanym ZooKeeperem za pomocą następującego polecenia:

$ bin/solr start -c

Następnie prześlemy konfigurację zawierającą wszystkie nasze zmiany do ZooKeepera używając następującego polecenia:

$ bin/solr zk upconfig -z localhost:9983 -n autocomplete -d /home/config/autocomplete/conf

Jedyne o czym należy pamiętać, aby powyższe polecenie zadziałało to stworzenie konfiguracji (lub jej pobranie z naszego konta Github – konfiguracja), a następnie umieszczenie jej w odpowiednim katalogu.

Następnie tworzymy kolekcję za pomocą bardzo prostego polecenia:

$ curl 'localhost:8983/solr/admin/collections?action=CREATE&name=autocomplete&numShards=1&replicationFactor=1&collection.configName=autocomplete'

Po poprawnym wykonaniu polecenia, możemy zaindeksować testowe dokumenty z początku wpisu w następujący sposób:

$ curl "http://localhost:8983/solr/autocomplete/update?commit=true" -H 'Content-type:application/json' -d '[
  {"id":1, "name":"Pośrednictwo nieruchomości"},
  {"id":2, "name":"Posadowienie budynków"},
  {"id":3, "name":"Posocznica"}
]'

Zadajmy więc dwa zapytania, jedno z literą ś, a drugie z literą s i porównajmy rezultaty. Pierwsze zapytanie wygląda następująco:

http://localhost:8983/solr/autocomplete/select?q.op=AND&defType=edismax&qf=name_ac&fl=id,name&q=pos

Drugie wygląda natomiast tak:

http://localhost:8983/solr/autocomplete/select?q.op=AND&defType=edismax&qf=name_ac&fl=id,name&q=pos

W obu przypadkach korzystamy z parsera Extended DisMax, spójnika logicznego AND (parametr q.op) i ustawiamy pole po którym chcemy szukać na name_ac za pomocą parameteru qf. Dodatkowo mówimy Solr, iż chcemy aby zwrócone zostały tylko pola id oraz name za pomocą parametru fl.

W przypadku obu zapytań wyniki są jednakowe i wyglądają następująco:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <bool name="zkConnected">true</bool>
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="q">poś</str>
    <str name="defType">edismax</str>
    <str name="qf">name_ac</str>
    <str name="fl">id,name</str>
    <str name="q.op">AND</str>
  </lst>
</lst>
<result name="response" numFound="3" start="0">
  <doc>
    <int name="id">1</int>
    <str name="name">Pośrednictwo nieruchomości</str></doc>
  <doc>
    <int name="id">2</int>
    <str name="name">Posadowienie budynków</str></doc>
  <doc>
    <int name="id">3</int>
    <str name="name">Posocznica</str></doc>
</result>
</response>

Jak widać opisana metoda działa

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

Wiele rdzeni kontra jeden rdzeń

Jedną z możliwości, jaką powinniśmy rozważyć na początku, to kwestia tego, czy jesteśmy w stanie stworzyć rdzeń lub kolekcję odpowiedzialną tylko i wyłączenie za autocomplete. Jeżeli tak, to powinniśmy iść tą drogą. Przyczyny tego są proste – taka kolekcja będzie z reguły mniejsza, niż ta w której indeksowane są nasze dane, ilość termów także ma szansę być mniejsza, a tym samym wykonywanie zapytań powinno być szybsze. Oczywiście, idzie za tym konieczność przygotowania konfiguracji, konieczność indeksacji drugiej kolekcji. Czasami jednak istnieją sytuacje kiedy takie rozwiązanie nie jest możliwe, na przykład ze względu na dodatkowe filtrowanie i takim przypadkiem zajmę się w tym wpisie.

Załóżmy dodatkowo że chcemy podpowiadać pełne frazy.

Konfiguracja

Zacznijmy zatem od konfiguracji.

Struktura indeksu

Załóżmy, że chcemy podpowiadać frazy z indeksu, oczywiście z pola wielowartościowego. Niech 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>

Jak widać do autocomplete będziemy wykorzystywać pole features_autocomplete. Pole _version_ wymagane jest przez niektóre funkcjonalności Solr 4.0 i nowszych i dlatego jest obecne w naszym indeksie.

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

Przyjrzyjmy się teraz jak wygląda nasz typ text_autocomplete:

<fieldType name="text_autocomplete" class="solr.TextField" positionIncrementGap="100">
 <analyzer type="index">
  <tokenizer class="solr.KeywordTokenizerFactory"/>
  <filter class="solr.LowerCaseFilterFactory"/>
  <filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="50" />
 </analyzer>
 <analyzer type="query">
  <tokenizer class="solr.KeywordTokenizerFactory" />
  <filter class="solr.LowerCaseFilterFactory"/>
 </analyzer>
</fieldType>

Jak widać w trakcie indeksowania będziemy tworzyć kolejne rozwinięcia naszej frazy zawartej w polu features_autocomplete za pomocą filtra solr.EdgeNGramFilterFactory. Minimalna długość powstałego tokoena może mieć długość 2, a najdłuższy może mieć długość 50 znaków.

Na etapie zapytania sprowadzamy frazę tylko do wspólnego mianownika za pomocą solr.LowerCaseFilterFactory i filtrów tworzonych przez tą fabrykę.

Przykładowe dane

Nasze dane 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>

Podstawowe zapytania

Spójrzmy zatem na zapytania.

Na początek

Zacznijmy od prostego zapytania, które w przypadku kiedy mielibyśmy pole przechowujące pojedyncze wartości zwróciłoby nam dane, które nas interesują. Zapytanie takie mogłoby wyglądać następująco:

q=features_autocomplete:sing&fl=features_autocomplete

Wyniki

Wyniki, jakie otrzymujemy z takiego zapytania to:

<?xml version="1.0" encoding="UTF-8"?>
<response>
 <lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">3</int>
  <lst name="params">
   <str name="fl">features_autocomplete</str>
   <str name="q">features_autocomplete:sing</str>
  </lst>
 </lst>
 <result name="response" numFound="2" start="0">
 <doc>
  <arr name="features_autocomplete">
   <str>Single window</str>
   <str>Single door</str>
  </arr>
 </doc>
 <doc>
  <arr name="features_autocomplete">
   <str>Multiple windows</str>
   <str>Single door</str>
  </arr>
 </doc>
 </result>
</response>

Krótki komentarz

Jak widać wyniki, jakie otrzymaliśmy nie satysfakcjonują nas, ze względu na to, że oprócz wartości, w której Solr znalazł trafienie, dostajemy także resztę danych w polu wielowartościowym. Zmodyfikujmy zatem nasze zapytanie.

Zapytanie z highlightingiem

Jak widać musimy zmienić nasze zapytanie, aby otrzymać to czego potrzebujemy. Wykorzystamy do tego highlighting.

Zmienione zapytanie

Zmieńmy zatem nasze zapytanie dodając następujący fragment:

hl=true&hl.fl=features_autocomplete&hl.simple.pre=&hl.simple.post=

Zatem całe zapytanie wygląda następująco:

q=features_autocomplete:sing&fl=features_autocomplete&hl=true&hl.fl=features_autocomplete&hl.simple.pre=&hl.simple.post=

Kilka słów o dodanych parametrach:

• hl=true – informujemy Solr, iż chcemy korzystać z highlightingu,
• hl.fl=features_autocomplete – określamy jakie pole ma zostać wykorzystane do highlightingu,
• hl.simple.pre= – stwierdzamy, iż nie chcemy widzieć gdzie zaczyna się podświetlony fragment,
• hl.simple.post= – stwierdzamy, iż nie chcemy widzieć gdzie kończy się podświetlony fragment.

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">4</int>
  <lst name="params">
   <str name="fl">features_autocomplete</str>
   <str name="q">features_autocomplete:sing</str>
   <str name="hl.simple.pre"/>
   <str name="hl.simple.post"/>
   <str name="hl.fl">features_autocomplete</str>
   <str name="hl">true</str>
  </lst>
 </lst>
 <result name="response" numFound="2" start="0">
 <doc>
  <arr name="features_autocomplete">
   <str>Single window</str>
   <str>Single door</str>
  </arr>
 </doc>
 <doc>
  <arr name="features_autocomplete">
   <str>Multiple windows</str>
   <str>Single door</str>
  </arr>
 </doc>
 </result>
 <lst name="highlighting">
  <lst name="2">
   <arr name="features_autocomplete">
    <str>Single window</str>
   </arr>
  </lst>
  <lst name="1">
   <arr name="features_autocomplete">
    <str>Single door</str>
   </arr>
  </lst>
 </lst>
</response>

Jak widać, w sekcji odpowiedzialnej za highlighting, otrzymaliśmy te frazy, które nas interesowały.

Podsumowanie

Należy pamiętać, iż przedstawiony sposób nie jest jedynym sposobem rozwiązania przedstawionego problemu. W kolejnym wpisie przedstawimy, jak ten sam problem można rozwiązać przy pomocy facetingu, jeżeli tylko jesteśmy w stanie zaakceptować pewne niedogodności, ale o tym w następnym wpisie dotyczącym funkcjonalności autocomplete.

Wymagania

Przy tworzeniu listy podpowiedzi przyjęliśmy następujące założenia:

1. Podpowiadana jest cała fraza a nie tylko pojedyncze słowo
2. Podpowiadana fraza może wystąpić w indeksie wielokrotnie
3. w wyniku chcemy znać liczbę wystąpień
4. Częściej występujące frazy są podpowiadane w pierwszej kolejności
5. Kolejność podawanych przez użytkownika słów nie musi odpowiadać kolejności występowania słów w podpowiadanej frazie

Rozwiązanie

Podany w pierwszej części sposób odpada ze względu na pierwsze założenie. Co prawda wyszukiwanie słów we frazie da się prosto osiągnąć zmieniając sposób analizy, jednak zwracane są pojedyncze słowa a nie cała fraza.

Rozwiązanie to zmodyfikowana wersja sposobu z facetingiem. Zamiast stosować wyszukiwanie wszystkich elementów i zawężanie wyników facetingu poprzez facet.prefix, możemy od razu wyszukać tylko te elementy, które mają fragment słowa wpisanego przez użytkownika. Ponieważ nie chcemy stosować zapytania prefiksowego ( „słowo*” ) ze względów wydajnościowych, na pomoc wezwiemy ngramy. Oznacza to zapisanie w indeksie wszystkich przedrostków słowa. Oczywistą wadą jest rozrost indeksu, ale w naszym przypadku jesteśmy w stanie z tym żyć

Schema.xml

Definiujemy więc dodatkowy typ:

  <fieldType name="text_autocomplete" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="25" />
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
  </fieldType>

Oraz pola: to, którego wartość będziemy wyświetlać oraz te, służące do wyszukiwania:

<field name="tag_autocomplete" type="text_autocomplete" indexed="true" stored="true" omitNorms="true" omitTermFreqAndPositions="true"/>
<field name="tag" type="string" indexed="true" stored="true" />

Zostaje jeszcze odpowiedni copyField:

<copyField source="tag" dest="tag_autocomplete"/>

 Zapytanie

Po przeindeksowaniu możemy przystąpić do tworzenia zapytania:

1. Zawężamy listę wyników do tych, które w polu tag_autocomplete mają poszukiwany fragment słowa: q=tag_autocomplete:(FRAZA)
2. W przypadku wielu podanych przez użytkownika fragmentów słów istotne jest, by były one wyszukiwane wszystkie: q.op=AND
3. Tak naprawdę wyniki nie są istotne, dane odczytamy z facetingu, więc informujemy solr, że nie potrzebujemy listy wyników: rows=0
4. Potrzebujemy natomiast faceting: facet=true
5. W dodatku to faceting po polu w którym przechowujemy oryginalną zawartość pola podpowiedzi: facet.field=tag
6. Nie interesują nas tagi, które nie zostały znalezione: facet.mincount=1
7. Interesuje nas 5 wyników: facet.limit=5

Ostateczne zapytanie:

?q=tag_autocomplete:(FRAZA)&q.op=AND&rows=0&facet=true&facet.field=tag&facet.mincount=1&facet.limit=5

Jeśli parametry, które są stałe umieścimy w handlerze, jako wartości domyślne, to zapytanie sprowadza się do:

?q=tag_autocomplete:(FRAZA)

Słowo na koniec

Podstawową zaletą tego rozwiązania w stosunku do rozwiązania opartego o faceting i facet.prefix jest możliwość używania innego pola do zwracania podpowiedzi. Dzięki temu przy podpowiadaniu pojedynczych słów możemy w wyniku wyświetlić całą zawartość pola „tag”.

Konfiguracja komponentu

Do konfiguracji komponentu przedstawionej w poprzedniej części dodajmy następujący parametr:

<str name="sourceLocation">dict.txt</str>

Zatem nasza konfiguracja powinna wyglądać następująco:

<searchComponent name="suggest" class="solr.SpellCheckComponent">
 <lst name="spellchecker">
  <str name="name">suggest</str>
  <str name="classname">org.apache.solr.spelling.suggest.Suggester</str>
  <str name="lookupImpl">org.apache.solr.spelling.suggest.tst.TSTLookup</str>
  <str name="field">name_autocomplete</str>
  <str name="sourceLocation">dict.txt</str>
 </lst>
</searchComponent>

Poinformowaliśmy komponent, że ma korzystać ze słownika o nazwie dict.txt, który znajduje się w katalogu z plikami konfiguracyjnymi Solr.

Konfiguracja handlera

Do konfiguracji handlera także dodamy jeden parametr, będzie on następujący:

<str name="spellcheck.onlyMorePopular">true</str>

Zatem konfiguracja powinna wyglądać następująco:

<requestHandler name="/suggest" class="org.apache.solr.handler.component.SearchComponent">
 <lst name="defaults">
  <str name="spellcheck">true</str>
  <str name="spellcheck.dictionary">suggest</str>
  <str name="spellcheck.count">10</str>
  <str name="spellcheck.onlyMorePopular">true</str>
 </lst>
 <arr name="components">
  <str>suggest</str>
 </arr>
</requestHandler>

Parametr ten mówi, aby komponent zwrócił tylko takie podpowiedzi, dla których ilość wyników wyszukiwania będzie większa od ilości wyników wyszukiwania dla aktualnego zapytania.

Słownik

Wcześniej powiedzieliśmy Solr, aby korzystał ze słownika, ale jak ma wyglądać przykładowy słownik. Do celów artykułu zdefiniowałem następujący słownik:

# przykladowy slownik
Dysk twardy hitachi
Dysk twardy wd    2.0
Dysk twardy jjdd    3.0

Jak wygląda konstrukcja słownika ? Każda z fraz (bądź pojedynczy wyrazów) znajduje się w oddzielnej linii. Każda linia zakończona jest wagą danej frazy (pomiędzy wagą a frazą występuje znak tabulacji) wykorzystywanej wraz z parametrem spellcheck.onlyMorePopular=true (im wyższa waga, tym wyżej znajdzie się podpowiedź). W przypadku pominięcia wagi Solr sam dodaje wartość domyślną wynoszącą 1. Słownik powinien być zapisany w kodowaniu UTF-8. Linie rozpoczynające się od znaku # są pomijane.

Dane

W tym wypadku nie potrzebujemy danych – komponent korzysta jedynie ze słownika.

Sprawdźmy jak to działa

W celu sprawdzenia jak działa nasz mechanizm zadajemy do Solr następujące zapytanie, oczywiście wcześniej przebudowując indeks mechanizmu:

/suggest?q=Dys

W odpowiedzi dostajemy następujące wyniki:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
</lst>
<lst name="spellcheck">
  <lst name="suggestions">
    <lst name="Dys">
      <int name="numFound">3</int>
      <int name="startOffset">0</int>
      <int name="endOffset">3</int>
      <arr name="suggestion">
        <str>Dysk twardy jjdd</str>
        <str>Dysk twardy hitachi</str>
        <str>Dysk twardy wd</str>
     </arr>
    </lst>
  </lst>
</lst>
</response>

Kilka słów na koniec

Jak widać podpowiedzi zostały posortowane według wysokości wag, czyli zgodnie z oczekiwaniami. Warto zauważyć także, że zapytanie zostało zadane dużą literą, co również ma dość duże znaczenie – zadanie zapytania małą literą spowoduje wygenerowanie zerowej listy podpowiedzi.

Co można powiedzieć o metodzie – jeżeli mamy bardzo dobre słowniki z wygenerowanymi wagami np. na podstawie zachowań klientów, jest to metoda generowania podpowiedzi, która zdobędzie sympatię klientów. Nie polecam jej jednak w przypadku pierwszych kroków z podpowiedziami i nieposiadania słowników – wtedy podpowiedzi mogą, choć oczywiście nie muszą, być słabej jakości.

Co dalej

Ilość zajęć nie pozwoliła mi niestety na przeprowadzenie testów wydajnościowych poszczególnych metod, dlatego też w następnej części postaram się przedstawić, jak zachowują się poszczególne metody w zależności od struktury i wielkości indeksu.