Dostępne opcje

W obecnej chwili dostępne są trzy opcje, jeżeli chodzi o analizę języka polskiego:

• Wykorzystanie możliwości  biblioteki Stempel (od wersji 3.1 Solr)
• Wykorzystanie możliwości biblioteki Hunspell i słownika języka polskiego (od wersji 3.5 Solr)
• Wykorzystanie możliwości biblioteki Morfologik (od wersji 4.0 Solr, SOLR-3272)

Konfiguracja

Przyjrzyjmy się konfiguracji każdej z wyżej wymienionych funkcjonalności (należy pamiętać, że poniższe konfiguracje zostały oparte o Solr 4.0).

Stempel

W celu dodania stemmingu języka polskiego przy pomocy biblioteki Stempel, to proste dodanie filtra do definicji typu:

<filter class="solr.StempelPolishStemFilterFactory" />

Oprócz tego, do SOLR_HOME/lib należy dodać bibliotekę lucene-analyzers-stempel-4.0.jar oraz apache-solr-analysis-extras-4.0.jar. Dobrym pomysłem jest także użycie solr.LowerCaseFilterFactory przed Stemplem.

Hunspell

Podobnie, jak w powyższym przypadku, skorzystanie z Hunspell’a to dodanie filtra do definicji typu. Na przykład w taki sposób:

<filter class="solr.HunspellStemFilterFactory" dictionary="pl_PL.dic" affix="pl_PL.aff" ignoreCase="true" />

Parametry dictionary oraz affix odpowiadają za definicję słownika z którego korzystamy. Natomiast parametr ignoreCase ustawiony na wartość true mówi filtrowi, aby nie zwracać uwagi na wielkość znaków. Słowniki można znaleźć m.in. pod adresem: http://wiki.services.openoffice.org/wiki/Dictionaries.

Morfologik

Tak jak w wyżej wymienionych przypadkach, tak samo i tutaj, skorzystanie z Morfologika to dodanie filtra do definicji typu. Tym razem w następujący sposób:

<filter class="solr.MorfologikFilterFactory" dictionary="MORFOLOGIK" />

Parametr dictionary to definicja z którego słownika chcemy skorzystać, do wyboru mamy:

• MORFOLOGIK
• MORFEUSZ
• COMBINED

Oprócz tego, do SOLR_HOME/lib należy dodać bibliotekę lucene-analyzers-morfologik-4.0.jar, apache-solr-analysis-extras-4.0.jar, morfologik-fsa-1.5.2.jar, morfologik-polish-1.5.2.jar oraz morfologik-stemming-1.5.2.jar.

Porównanie działania

Oczywiście nie byłem w stanie ocenić działania dla całego korpusu słów języka polskiego, dlatego wybrałem sobie cztery słowa, aby sprawdzić, jak zachowuje się każdy z wymienionych wyżej filtrów. Słowa te to: „urodzić urodzony urodzona urodzeni”. Wyniki przedstawiają się następująco:

Stempel

Wynikiem działania Stempla były następujące tokeny:

[urodzić] [urodzo] [urodzona] [urodzeni]

Należy jednak pamiętać, iż Stempel to stemmer, a więc wyniki jego działania mogą i będą odbiegać od form podstawowych, czy też tematów słów. Ważne jest to, aby interesujące nas słowa sprowadzane były do tej samej formy, co umożliwi znalezienie odpowiedniego słowa przez Lucene/Solr. Pamiętając jednak o tym, widać iż wyniki nie są zadowalające, przynajmniej dla mnie. Na przykład zadając zapytanie urodzić, nie znaleźlibyśmy dokumentów ze słowami urodzona, czy urodzony. Dodatkowo widać, iż Stempel wyprodukował po jednym tokenie dla każdego ze słów.

Hunspell

Wynikiem działania Hunspell’a były następujące tokeny:

[urodzić, urodzić] [urodzony, urodzić] [urodzić] [urodzić, urodzony, urodzenie]

Porównując wyniki uzyskane z pomocą Hunspell’a do tych uzyskanych z pomocą Stempla widać różnicę. Nasze przykładowe zapytanie o słowo urodzić, znalazłoby zarówno dokumenty ze słowem urodzony, jak również ze słowem urodzona, czy urodzeni. Całkiem miło. Dodatkowo widać, iż na trzy z czterech słów wejściowych Hunspell wygenerował więcej, niż jeden token (oczywiście umieszczając je na odpowiednich pozycjach w strumieniu tokenów). Wynik działania Hunspell’a mnie satysfakcjonuje, natomiast spójrzmy jeszcze na działanie najnowszego filtra dostępnego w Lucene i Solr pozwalającego na analizę języka polskiego, czyli na Morfologika.

Morfologik

Wynikiem działania Morfologika były następujące tokeny:

[urodzić] [urodzony, urodzić] [urodzić] [urodzić, urodzony]

Porównując wyniki uzyskane za pomocą Morfologika do tych uzyskanych za pomocą Hunspell’a ciężko zauważyć różnicę (oczywiście w tym wypadku). Jedyną różnicą pomiędzy Hunspell’em, a Morfologikiem jest ostatni term dla słowa urodzeni, czyli urodzenie, którego nie otrzymaliśmy w wyniku działania Morfologika. Moim zdaniem wynik działania Morfologika, podobnie jak w przypadku Hunspell’a można uznać za satysfakcjonujący.

Wydajność

Test wydajności został zrobiony bardzo prosto – każdorazowo zostało zaindeksowanych 5 milionów dokumentów, gdzie wszystkie pola tekstowe były oparte o analizę języka polskiego z odpowiednim filtrem (do tego kilka standardowych filtrów, jak usuwanie stopwordów, synonimy, itp). Za każdym razem indeksowanie rozpoczynane było od nowa na nowej instancji Solr 4.0. Ze względu na korzystanie z Data Import Handlera polecenie commit wysyłane było co 100.000 dokumentów. Indeks składał się z kilkunastu pól, jednak sama struktura nie jest ważna ze względu na to, że zamierzałem zobaczyć, jak wygląda porównanie poszczególnych filtrów. Poniżej wyniki testu:

Uwaga: W chwili pisania niniejszego tekstu, zgodnie ze zgłoszeniem SOLR-3245 istnieje problem z wydajnością Hunspella z polskimi słownikami w Solr 4.0. Najprawdopodobniej, sytuacja ta zostanie rozwiązana do czasu wypuszczenia wersji 4.0 Solr, jednak jeżeli zastanawiacie się nad korzystaniem z Solr 4.0 i Hunspell’a z polskimi słownikami wydajność takiego tandemu może być niezadowalająca.

Niestety ze względu na problemy wydajnościowe z Hunspell’em nie byliśmy w stanie porównać wydajności trzech dostępnych filtrów umożliwiających analizę języka polskiego. Natomiast z powyższej tabeli wnioskować można, iż w większości przypadków zarówno Stempel, jak i Morfologik będą charakteryzowały się podobną wydajnością.

Krótkie podsumowanie

Pomimo braku wyników wydajnościowych dotyczących Hunspell’a (bo te które są uważam za błędne i jestem pewien, że zostaną poprawione), widać iż Hunspell i Morfologik są dobrymi kandydatami do wykorzystania jeżeli chodzi o filtr umożliwiający analizę języka polskiego. W przypadku Morfologika, mamy wydajność podobną do Stempla, a w testach wychodzi na to, że Morfologik daje sobie radę z większą ilością polskich słów, co wpłynie pozytywnie na odczucia użytkowników.

Na początek mała informacja, FieldCollapsing dostępny jest tylko w wersji 4.0, czyli w wersji rozwojowej kodu projektu Solr i raczej mało prawdopodobnym jest przeniesienie tej funkcjonalności do wersji 3.X.

FieldCollapsing, czyli co ?

Wyobraźmy sobie, iż nasz indeks zawiera informacje o firmach z różnych miast. Chcemy pokazać użytkownikowi po jednej (lub np. dwie, czy trzy) firmie z każdego miasta, oczywiście firmie spełniającej kryteria wyszukiwania. W jaki sposób tego dokonać – wykorzystać właśnie mechanizm FieldCollapsing. Pozwala on na grupowanie zwróconych w wyników wyszukiwania na podstawie zawartości pól. Wyniki wyszukiwania mogą być zgrupowane do pojedynczego dokumentu, bądź stałej ich ilości.

Parametry

Podobnie, jak w przypadku większości funkcjonalności dostępnych w Solr, tak samo zachowanie mechanizmu FieldCollapsing można konfigurować szeregiem parametrów, oto one:

• group – analogicznie do np. facetingu ustawienie tego parametru na wartość true włącza mechanizm FieldCollapsing. Wartość domyślna parametru to false.
• group.field – określenie na podstawie jakiego pola ma się odbywać grupowanie.
• group.func – określenie funkcji, na podstawie wyniku której będzie odbywać się grupowanie.
• group.limit – ilość wyników jaka ma być zwrócona w poszczególnych grupach. Domyślna wartość parametru to 1.
• group.sort – parametr określający w jaki sposób sortować dokumenty w ramach grup. Wartość domyślna, to wartość score desc.

Warto podkreślić, iż parametr rows przekazywany do zapytania będzie określał ilość grup jaka ma zostać zwrócona w wynikach wyszukiwania, a nie ilość pojedynczych dokumentów. Zmienia się także zachowanie parametru sort. Parametr ten będzie sortował grupy wyników, a nie poszczególne dokumenty. Grupy będą sortowane na podstawie zawartości pól pierwszych dokumentów tworzących grupy.

Wyniki wyszukiwania

Wyniki wyszukiwania różnią się od tych do których jesteśmy przyzwyczajeni. Są one pogrupowane według parametrów, które przekazaliśmy. Głównym elementem wyników wyszukiwania nie są już poszczególne dokumenty, a grupy dokumentów. Dopiero w ramach grup pokazywane są dokumenty (ich ilość definiuje parametr group.limit). Na przykład, zadając zapytanie:

http://localhost:8983/solr/select/?q=*:*&group=true&group.field=inStock&indent=true

do indeksu, który powstał poprzez zaindeksowanie wszystkich dokumentów w formacie XML z katalogu exampledocs przykładowego wdrożenia dostarczanego z Solr, otrzymujemy następujący wynik:

<?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="group.field">inStock</str>
    <str name="group">true</str>
    <str name="indent">true</str>
    <str name="q">*:*</str>
  </lst>
</lst>
<lst name="grouped">
  <lst name="inStock">
    <int name="matches">19</int>
    <arr name="groups">
     <lst>
        <str name="groupValue">T</str>
        <result name="doclist" numFound="15" start="0">
          <doc>
            <arr name="cat"><str>electronics</str><str>hard drive</str></arr>
            <arr name="features"><str>7200RPM, 8MB cache, IDE Ultra ATA-133</str><str>NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</str></arr>
            <str name="id">SP2514N</str>
            <bool name="inStock">true</bool>
            <str name="manu">Samsung Electronics Co. Ltd.</str>
            <date name="manufacturedate_dt">2006-02-13T15:26:37Z</date>
            <str name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</str>
            <int name="popularity">6</int>
            <float name="price">92.0</float>
            <str name="store">45.17614,-93.87341</str>
            <double name="store_0_d">45.17614</double>
            <double name="store_1_d">-93.87341</double>
            <str name="store_lat_lon">45.17614,-93.87341</str>
          </doc>
        </result>
      </lst>
      <lst>
        <str name="groupValue">F</str>
        <result name="doclist" numFound="4" start="0">
          <doc>
            <arr name="cat"><str>electronics</str><str>connector</str></arr>
            <arr name="features"><str>car power adapter, white</str></arr>
            <str name="id">F8V7067-APL-KIT</str>
            <bool name="inStock">false</bool>
            <str name="manu">Belkin</str>
            <date name="manufacturedate_dt">2005-08-01T16:30:25Z</date>
            <str name="name">Belkin Mobile Power Cord for iPod w/ Dock</str>
            <int name="popularity">1</int>
            <float name="price">19.95</float>
            <str name="store">45.17614,-93.87341</str>
            <double name="store_0_d">45.17614</double>
            <double name="store_1_d">-93.87341</double>
            <str name="store_lat_lon">45.17614,-93.87341</str>
            <float name="weight">4.0</float>
          </doc>
        </result>
      </lst>
    </arr>
  </lst>
</lst>
</response>

Na koniec

Ciekawa funkcjonalność, która na pewno znajdzie zastosowania w niektórych wdrożeniach. Należy jednak pamiętać, iż funkcjonalność ta będzie jeszcze rozwijana. Jak na razie nie ma wsparcia m.in. dla wyszukiwania rozproszonego, czy grupowania po polach wielowartościowych. W tym momencie nie ma sensu przeprowadzanie też testów wydajnościowych, po pierwsze ze względu na zmiany jakie zajdą w samym mechanizmie, a po drugie ze względu na to, iż jest to mocno rozwojowa wersja Lucene i Solr. Niemniej jednak, na pewno będę miał opisywaną funkcjonalność na oku