4.0 – Solr.pl

Solr 4.0: DirectSolrSpellChecker

Rafał Kuć — Mon, 30 Apr 2012 21:29:41 +0000

Jedną z nowości, która zostanie zaprezentowana w Solr 4.0, jest nowy rodzaj SpellChecker’a, który nie potrzebuje własnego indeksu. Postanowiłem przyjrzeć się jego konfiguracji i działaniu.

Stan obecny

W chwili obecnej (Solr 3.6) mamy do dyspozycji następujące implementacje SpellChecker’a:

org.apache.solr.spelling.IndexBasedSpellChecker
org.apache.solr.spelling.FileBasedSpellChecker

Wraz z nadejściem Solr 4.0, dostaniemy dodatkowo nową implementację:

org.apache.solr.spelling.DirectSolrSpellChecker

Obecne problemy

W moim przypadku, jednym z głównych problemów IndexBasedSpellChecker’a była konieczność przebudowywania jego indeksu. Ze względu na to, że operacja mogła trwać długo, nie było możliwości przebudowywania tego indeksu po każdej operacji commit, co w niektórych wypadkach było znaczącym problemem. Oczywiście problem ten nie dotyczył FileBasedSpellChecker’a, jednak w moim wypadku pełnił rolę pomocniczego mechanizmu poprawiania błędów użytkowników.

Konfiguracja

Konfiguracja, jest analogiczna do tej do której przyzwyczaił nas Solr 3. Poniżej przykład:


  textTitle
  
    default
    title
    solr.DirectSolrSpellChecker
    internal
    0.7
    2
    1
    5
    4
    0.01
    .01

Co oznaczają poszczególne parametry konfiguracyjne:

queryAnalyzerFieldType – nazwa typu na podstawie którego dokonywana będzie analiza zapytania zadanego do SpellChecker’a.
field – pole, które będzie wykorzystywane do budowania podpowiedzi.
classname – implementacja SpellChecker’a.
distanceMeasure – algorytm określający odległość pomiędzy słowami, w tym wypadku domyślny, czyli wykorzystujący algorytm Levenshtein’a.
accuracy – dokładność, jaka musi być osiągnięta, aby podpowiedź była uznana za poprawną.
maxEdits – maksymalna ilość zmian podczas procesu wyliczania termów, możliwe wartości to 1 i 2.
minPrefix – minimalny wspólny przedrostek w podczas wyliczania termów.
maxInspections – maksymalna liczba sprawdzeń dla każdej podpowiedzi.
minQueryLength – minimalna wielkość słowa, aby te było brane pod uwagę jako podpowiedź.
maxQueryFrequency – maksymalny procent dokumentów w jakich może wystąpić słowo, aby było uznane za kandydata do poprawienia (wartość 0.01 oznacza 1%).
thresholdTokenFrequency – minimalny procent dokumentów w jakich musi wystąpić podpowiedź, aby była uznana za poprawną (wartość .01 oznacza 1%).

Powyższe atrybuty konfiguracji pokazują, iż DirectSolrSpellChecker daje nam dość duże pole jeżeli chodzi o konfigurację jego zachowania.

Korzystanie

DirectSolrSpellChecker nie różni się w kwestii wykorzystania od swoich poprzedników. Tak samo jak w poprzednim wypadku możemy skonfigurować Solr, aby dodawał wyniki działania SpellCheckera do wyników wyszukiwania w każdym zapytaniu lub jako oddzielny handler wywoływany wtedy, kiedy nasza aplikacja uzna to za stosowne. O korzystaniu ze SpellChecker’a pisaliśmy już kiedyś w przykładowej aplikacji „Sprzedaż samochodów„.

Czego możemy oczekiwać ?

Zgodnie z informacjami, jakie można znaleźć w zgłoszeniu LUCENE-2507 DirectSolrSpellChecker uwalnia nas nie tylko od konieczności budowania indeksu SpellCheck’a, ale także niesie ze sobą szansę na poprawę działania tego mechanizmu. Z tego co widać, DirectSolrSpellChecker działa lepiej od dotychczas dostępnych implementacji kosztem spadku wydajności, którym moim zdaniem jest do zaakceptowania, przynajmniej jeżeli nie potrzebujemy podpowiedzi od SpellCheckera przy każdym zapytaniu.

Solr 4.0 i możliwości analizy języka polskiego

Rafał Kuć — Mon, 02 Apr 2012 21:27:23 +0000

Ze względu na to, iż wsparcie dla języka polskiego w Lucene (i Solr) jest już od jakiegoś czasu, postanowiłem przyjrzeć się jak zmieni się to wraz z premierą Lucene i Solr w wersji 4.0.

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:

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:

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:

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:

[table “20” not found /]

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.

Solr 4.0: Realtime GET

Rafał Kuć — Mon, 09 Jan 2012 20:35:54 +0000

Kolejną funkcjonalnością, jakiej postanowiłem się przyjrzeć, w związku ze zbliżającym się Solr 4.0, jest tzw. „Realtime Get”. Jest to funkcjonalność umożliwiająca wyszukiwanie danych, które nie zostały jeszcze dodane do indexu, czyli po ich indeksowaniu nie zostało wysłane polecenie commit. Spójrzmy zatem, jak to działa.

Trochę teorii

Aktualizacja danych w Lucene i Solr ma jeden zasadniczy minus – w przypadku standardowego korzystania nie jesteśmy w stanie zobaczyć zmian w indeksie, do chwili, kiedy nie zostanie wywołane polecenie commit. Problem polega na tym, iż operacja commit jest stosunkowo droga pod względem wydajnościowym i zbyt częste jej używanie może powodować problemy. Z związku z tym, jeżeli podczas implementacji aplikacji wykorzystującej Lucene lub Solr możesz być postawiony przed wyborem: albo wysoka wydajność, albo szybko widoczne zmiany. W związku z tym twórcy Lucene i Solr podjęli prace w kierunku umożliwiającym wyszukiwanie Near Real Time (NRT). W Lucene mamy już tą możliwość, w wersji 4.0 Solr także się jej doczekamy, ale nie tylko jej.

Konfiguracja

Aby funkcjonalność Realtime Get miała możliwość działania, potrzebujemy skonfigurować następujące rzeczy:

Log transakcyjny

Pierwsza z rzeczy koniecznych do uruchomienia funkcjonalności Realtime Get to zapisywanie loga transakcyjnego. W tym celu do konfiguracji updateHandler’a dodajemy następujący wpis:

Powyższy wpis oznacza, iż katalog z logiem transakcyjnym zostanie zapisany w katalogu, gdzie zapisywane są dane.
Realtime Get handler
Druga rzecz, którą musimy zrobić, aby zobaczyć Realtime Get w działaniu, to zdefiniowanie odpowiedniego handlera (bądź komponentu). W tym celu do pliku solrconfig.xml dodajemy następujący wpis:

true

Powyższy wpis, to nic innego jak zdefiniowanie nowego handlera, opartego o klasę solr.RealTimeGetHandler, który umożliwia wyszukiwanie w oparciu o log transakcyjny.
Działanie
Aby sprawdzić działanie Realtime Get postanowiłem zrobić dość prosty test. Najpierw zaindeksowałem jeden plik (z tych które dostępne są w katalogu exampledocs) za pomocą następującego polecenia:

curl 'http://localhost:8983/solr/update' -d @hd.xml -H 'Content-type:application/xml'
Oczywiście, po indeksowaniu nie wysyłamy polecenia commit. Zgodnie z oczekiwaniami, zadanie zapytania w postaci:

http://localhost:8983/solr/select?q=*:*
nie zwraca wyników wyszukiwania. Sprawdźmy więc, czy handler zarejestrowany jako /get jest w stanie dostarczyć nam wyniki. Wywołuję zatem następujące zapytanie:

http://localhost:8983/solr/get?id=SP2514N
W odpowiedzi, na powyższe zapytanie otrzymujemy następujący dokument:

SP2514N
Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133
Samsung Electronics Co. Ltd.
samsung

electronics
hard drive

7200RPM, 8MB cache, IDE Ultra ATA-133
NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor

92.0
6
true
2006-02-13T15:26:37Z
35.0752,-97.032

Zatem otrzymaliśmy dokument, który nie został jeszcze dodany do indeksu.
Możliwe zastosowanie
Zauważyliście pewnie, że aby pobrać dokument musiałem podać jego identyfikator (możliwe jest także podanie listy identyfikatorów). To prawda, Realtime Get przynajmniej w tym momencie, nie wspiera pełnego wyszukiwania, ponieważ nie do tego został stworzony. Funkcjonalność ta jest w stanie pokazać aktualizację dokumentów, których znamy identyfikatory - np. poprzez dodanie komponentu wykorzystywanego w solr.RealTimeGetHandler do dowolnego innego handlera. Dodatkowo nie musimy się bać o wydajność - komponent jest bardzo szybki. Zatem, jeżeli jednym z problemów twojej aplikacji opartej na Solr, jest problem z długim oczekiwaniem na aktualizację możesz z uśmiechem patrzeć w przyszłość
Podsumowując
Funkcjonalność ta niesie za sobą bardzo dużo możliwości jeżeli chodzi o Solr, a także jego rozwój w kierunku SolrCloud. Na podstawie loga transakcyjnego będzie możliwe zaimplementowanie, np. automatycznego odtwarzania instancji Solr w klastrze, czy aktualizacji instancji w bardzo szybkim czasie. Jak widać wersja 4.0 to nie tylko usprawnienia w kierunku wyszukiwania, ale także rozwój Solr w kierunku baz NOSQL.
{solr.data.dir:}

Oczywiście, po indeksowaniu nie wysyłamy polecenia commit. Zgodnie z oczekiwaniami, zadanie zapytania w postaci:

nie zwraca wyników wyszukiwania. Sprawdźmy więc, czy handler zarejestrowany jako /get jest w stanie dostarczyć nam wyniki. Wywołuję zatem następujące zapytanie:

W odpowiedzi, na powyższe zapytanie otrzymujemy następujący dokument:

Zatem otrzymaliśmy dokument, który nie został jeszcze dodany do indeksu.
Możliwe zastosowanie
Zauważyliście pewnie, że aby pobrać dokument musiałem podać jego identyfikator (możliwe jest także podanie listy identyfikatorów). To prawda, Realtime Get przynajmniej w tym momencie, nie wspiera pełnego wyszukiwania, ponieważ nie do tego został stworzony. Funkcjonalność ta jest w stanie pokazać aktualizację dokumentów, których znamy identyfikatory – np. poprzez dodanie komponentu wykorzystywanego w solr.RealTimeGetHandler do dowolnego innego handlera. Dodatkowo nie musimy się bać o wydajność – komponent jest bardzo szybki. Zatem, jeżeli jednym z problemów twojej aplikacji opartej na Solr, jest problem z długim oczekiwaniem na aktualizację możesz z uśmiechem patrzeć w przyszłość
Podsumowując
Funkcjonalność ta niesie za sobą bardzo dużo możliwości jeżeli chodzi o Solr, a także jego rozwój w kierunku SolrCloud. Na podstawie loga transakcyjnego będzie możliwe zaimplementowanie, np. automatycznego odtwarzania instancji Solr w klastrze, czy aktualizacji instancji w bardzo szybkim czasie. Jak widać wersja 4.0 to nie tylko usprawnienia w kierunku wyszukiwania, ale także rozwój Solr w kierunku baz NOSQL.

Solr 4.0: DocTransformers – pierwsze spojrzenie

Rafał Kuć — Mon, 05 Dec 2011 20:33:18 +0000

Dzisiejszy wpis jest kolejnym z serii, w której staramy się przybliżyć funkcjonalności jakie pojawią się w wersji 4.0 Apache Solr. Dzisiaj przyjrzymy się funkcjonalności pozwalającej na zmianę sposobu w jaki zwracane są pola w dokumentach.

Po co mi taka funkcjonalność ?

Do tej pory, praktycznie, nie mieliśmy możliwości wpływania na to, jak budowane były odpowiedzi zwracane przez Solr. Wraz z pojawieniem się wersji 4.0 Solr dostaniemy do ręki nowe narzędzie, tzw. DocTransformers. Funkcjonalność ta pozwala na modyfikację pól w wynikach wyszukiwania zwróconych przez Solr. Patrząc na to, co w tym momencie jest dostępne, mamy na przykład możliwość zamiany nazw zwracanych pól, czy oznaczenia elementów dodawanych przez QueryElevationComponent. W tym momencie nie jest tego dużo, natomiast implementacja własnego DocTransformer’a nie jest trudna, o czym za chwilę.

Co jest już dostępne

W tym momencie, w wersji 4.0 Apache Solr dostępne są następujące funkcjonalności związane z DocTransformer’ami:

Możliwość oznaczenia, które dokumenty zostały dodane przez QueryElevationComponent.
Możliwość dodania informacji explain do dokumentu.
Możliwość dodania stałej wartości jako pola do dokumentu.
Możliwość dodania informacji o shardzie z jakiego pochodzi danych dokument.
Możliwość dodania informacji docid jako pola dokumentu (identyfikator wykorzystywany przez Lucene).

Jak z tego skorzystać ?

Sprawdźmy, jak wygląda wykorzystanie tej funkcjonalności. Do tego celu pobrałem najnowszą wersję Apache Solr z repozytorium i uruchomiłem przykładowe wdrożenie. Następnie zaindeksowałem przykładowe dane i zadałem następujące zapytanie:

http://localhost:8983/solr/select?q=encoded&fl=name,score,[docid],[explain]

W powyższym zapytaniu warto przyjrzeć się parametrowi fl. Oprócz informacji takich, jak pole name oraz wartość score powiedzieliśmy Solr, że chcemy, aby do wygenerowania wyników wyszukiwania zostały wykorzystane dwa DocTransformery: [docid] oraz [explain]. W odpowiedzi Solr wygenerował następującego XML’a:



 
  0
  2
  
    encoded
    name,score,[docid],[explain]
  
 
 
 
  Test with some GB18030 encoded characters
  0.50524884
  0
  
  0.50524884 = (MATCH) weight(text:encoded in 0) [DefaultSimilarity], result of:
    0.50524884 = score(doc=0,freq=1.0 = termFreq=1), product of:
      1.0000001 = queryWeight, product of:
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.3092536 = queryNorm
      0.5052488 = fieldWeight in 0, product of:
        1.0 = tf(freq=1.0), with freq of:
          1.0 = termFreq=1
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.15625 = fieldNorm(doc=0)
  
 
 
  Test with some UTF-8 encoded characters
  0.4041991
  25
  
  0.4041991 = (MATCH) weight(text:encoded in 25) [DefaultSimilarity], result of:
    0.4041991 = score(doc=25,freq=1.0 = termFreq=1), product of:
      1.0000001 = queryWeight, product of:
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.3092536 = queryNorm
      0.40419903 = fieldWeight in 25, product of:
        1.0 = tf(freq=1.0), with freq of:
          1.0 = termFreq=1
        3.2335923 = idf(docFreq=2, maxDocs=28)
        0.125 = fieldNorm(doc=25)

Jak widać, Solr dołączył do wyników wyszukiwania to o co go prosiliśmy.

Własna implementacja

Omówmy, jak wygląda implementacja własnego DocTransfomer’a. Poniżej, przykład klasy RenameFieldsTransformer z pakietu org.apache.solr.response.transform. Ogólnie polega to na implementacji następujących metod z klasy DocTransformer z pakietu org.apache.solr.response.transform:

String getName() – metoda zwracająca nazwę transformera,
void transform(SolrDocument doc, int docid) – metoda dokonująca transformacji.

Sama implementacja wygląda następująco:

public class RenameFieldsTransformer extends DocTransformer {
 final NamedList rename;

 public RenameFieldsTransformer( NamedList rename ) {
  this.rename = rename;
 }

 @Override
 public String getName() {
  StringBuilder str = new StringBuilder();
  str.append( "Rename[" );
  for( int i=0; i< rename.size(); i++ ) {
   if( i > 0 ) {
    str.append( "," );
   }
   str.append( rename.getName(i) ).append( ">>" ).append( rename.getVal( i ) );
  }
  str.append( "]" );
  return str.toString();
 }

 @Override
 public void transform(SolrDocument doc, int docid) {
  for( int i=0; i
Powyższy kod umożliwia zwrócenie pola o innej nazwie, niż ta, która została zaindeksowana. Metoda transform iteruje po wszystkich wartościach zmiennej rename, która zawiera nazwę pól, które mają zostać zmienione wraz z nazwami na jakie powinny zostać zamienione. Należy pamiętać, iż, aby nasz własny transformer zaczął działać, należy dodać go do pliku solrconfig.xml. Oto przykład w wiki Solr:


Podsumowując
Należy pamiętać, iż opisywana funkcjonalność jest oznaczona jako eksperymentalna i jej działanie może się zmienić w stosunku do opisywanego w chwili publikacji wersji 4.0 Solr i Lucene. Na pewno wrócimy do tematu po ukazaniu się Solr 4.0.

Solr 4.0: możliwości parametru fl – pierwsze spojrzenie

Rafał Kuć — Tue, 22 Nov 2011 20:32:04 +0000

W związku ze zbliżającym się powoli wydaniem Apache Solr w wersji 4.0 uznałem, iż nadszedł czas, aby przybliżyć niektóre z funkcjonalności, jakie dostaniemy w swoje ręce wraz z premierą tej wersji silnika wyszukiwania. Na pierwszy ogień przyjrzymy się prostej, aczkolwiek przydatnej funkcjonalności nazwanej pseudo fields wraz z dodatkowymi możliwościami związanymi z parametrem fl.

Na początek

W Apache Solr 4.0 zmienił się nieznacznie sposób obsługi parametru fl – parametr może być podawany wielokrotnie. Wartości z wszystkich podanych do zapytania parametrów fl zostaną przez Solr połączone. Czasami będzie to przydatne, przynajmniej w moim przypadku.

Własne nazwy pól

Wraz z Solr 4.0 będziemy mieli możliwość nazywania pól, jakie zwracane są w Solr. Wyobraźmy sobie, że w zależności od kontekstu chcielibyśmy aby pola, które w indeksie nazywane są price_en, price_pl, czy price_fr były zwracane jako pole price. W Solr 4.0 możemy to zrobić w umieszczając następujący fragment w zapytaniu:

fl=price:price_pl

Spowoduje to, że pole price_pl, zostanie zwrócone jako pole o nazwie price.

Wszystkie pola o wspólnym początku nazwy

Jeżeli będziemy chcieli zwrócić, wraz z dokumentem, wszystkie pola, których nazwa zaczyna się np. od price (użyteczne w przypadku pól dynamicznych) wystarczy, że dodamy następującą wartość parametru fl w zapytaniu:

fl=price*

Zwracanie wartości funkcji

Ostatnia z funkcjonalności, którym przyjrzymy się dzisiaj, czyli możliwość dołączenia wyniku działania funkcji, jako pola dokumentu. Zatem w Solr 4.0 będziemy mieli możliwość dodania np. sumy cen, bądź wyliczonej odległości geograficznej pomiędzy dwoma punktami. Całkiem przydatne. Aby skorzystać z tej funkcjonalności wystarczy do parametru fl dodać odpowiednie wywołanie funkcji dostępnej w Solr, na przykład:

fl=*,stock:sum(stockMain,stockShop)

Co spowoduje zwrócenie wszystkich pól (wartość *) oraz pola o nazwie stock, które będzie sumą pól stockMain oraz stockShop.

Kilka słów na koniec

Oprócz opisanych powyżej, nowych funkcjonalności, parametru fl, jest jeszcze możliwość skorzystania DocTransformer. Opisanie tego zostawiłem sobie jednak na kolejny wpis o Apache Solr 4.0.

Hierarchiczny faceting – czyli Pivot Facet w trunk’u

Rafał Kuć — Mon, 25 Oct 2010 05:25:50 +0000

W dużej ilości wdrożeń z jakimi miałem do czynienia zawsze pojawiało się pytanie – co możemy zrobić, aby uzyskać od Solr drzewiastą strukturę facetingu. Oczywiście są na to metody, jednak ich wykorzystanie polegało na modyfikacji danych i odpowiednim przetwarzaniu po stronie aplikacji. Nie było to szczególnie funkcjonalne, jak i szczególnie wygodne. Jednak kilka dni temu Solr w wersji 4.0 został wzbogacony o kod oznaczony jako SOLR-792 w systemie JIRA. Zobaczmy w takim wypadku, jak pobrać wyniki facetingu w postaci drzewa.

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.



.
.
.


  
  
  
  
  
    
      
        cat
        electronics
        17
        
          
            inStock
            true
            13
          
          
            inStock
            false
            4
          
        
      
      
        cat
        memory
        6
        
          
            inStock
            true
            6
          
        
      
      
        cat
        connector
        2
        
          
            inStock
            false
            2
          
        
      
      
        cat
        graphics card
        2
        
          
            inStock
            false
            2
          
        
      
      
        cat
        hard drive
        2
        
          
            inStock
            true
            2
          
        
      
      
        cat
        monitor
        2
        
          
            inStock
            true
            2
          
        
      
      
        cat
        search
        2
        
          
            inStock
            true
            2
          
        
      
      
        cat
        software
        2
        
          
            inStock
            true
            2

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ę:



.
.
.


  
  
  
  
  
    
      
        cat
        electronics
        17
        
          
            inStock
            true
            13
            
              
                features
                2
                7
              
              
                features
                3
                7
              
              
                features
                lcd
                5
              
              
                features
                x
                5
              
              
                features
                ca
                4
              
              
                features
                latenc
                4
              
              
                features
                tft
                4
              
              
                features
                v
                4
              
              
                features
                0
                3
              
              
                features
                1
                3
              
              
                features
                25
                3
              
              
                features
                30
                3
              
              
                features
                5
                3
              
              
                features
                7
                3
              
              
                features
                8
                3
              
              
                features
                time
                3
              
              
                features
                up
                3
              
              
                features
                000
                2
              
              
                features
                19
                2
              
              
                features
                20
                2
              
              
                features
                2336
                2
              
              
                features
                27
                2
              
              
                features
                275
                2
              
              
                features
                6
                2
              
              
                features
                75
                2
              
              
                features
                activ
                2
              
              
                features
                built
                2
              
              
                features
                cach
                2
              
              
                features
                color
                2
              
              
                features
                flash
                2
              
              
                features
                heat
                2
              
              
                features
                heatspread
                2
              
              
                features
                matrix
                2
              
              
                features
                mb
                2
              
              
                features
                ms
                2
              
              
                features
                photo
                2
              
              
                features
                resolut
                2
              
              
                features
                seek
                2
              
              
                features
                speed
                2
              
              
                features
                spreader
                2
              
              
                features
                unbuff
                2
              
              
                features
                usb
                2
              
            
          
          
            inStock
            false
            4
            
              
                features
                0
                2
              
              
                features
                1
                2
              
              
                features
                16
                2
              
              
                features
                2
                2
              
              
                features
                20
                2
              
              
                features
                3
                2
              
              
                features
                9
                2
              
              
                features
                90
                2
              
              
                features
                adapt
                2
              
              
                features
                car
                2
              
              
                features
                clock
                2
              
              
                features
                direct
                2
              
              
                features
                directx
                2
              
              
                features
                dual
                2
              
              
                features
                dvi
                2
              
              
                features
                express
                2
              
              
                features
                gddr
                2
              
              
                features
                ghz
                2
              
              
                features
                gl
                2
              
              
                features
                gpu
                2
              
              
                features
                gpuvpu
                2
              
              
                features
                hdtv
                2
              
              
                features
                mb
                2
              
              
                features
                mhz
                2
              
              
                features
                open
                2
              
              
                features
                opengl
                2
              
              
                features
                out
                2
              
              
                features
                pci
                2
              
              
                features
                power
                2
              
              
                features
                vpu
                2
              
              
                features
                white
                2
              
              
                features
                x
                2

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ć.

Szybkie spojrzenie – FieldCollapsing

Rafał Kuć — Mon, 20 Sep 2010 04:27:07 +0000

FieldCollapsing, czyli inaczej grupowanie wyników wyszukiwania – funkcjonalność nad którą developerzy Lucene/Solr pracowali już od dłuższego czasu trafiła właśnie do repozytorium projektu Solr. Postanowiłem się przyjrzeć, w jaki sposób działa ta funkcjonalność.

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:




  0
  0
  
    inStock
    true
    true
    *:*
  


  
    19
    
     
        T
        
          
            electronicshard drive
            7200RPM, 8MB cache, IDE Ultra ATA-133NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor
            SP2514N
            true
            Samsung Electronics Co. Ltd.
            2006-02-13T15:26:37Z
            Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133
            6
            92.0
            45.17614,-93.87341
            45.17614
            -93.87341
            45.17614,-93.87341
          
        
      
      
        F
        
          
            electronicsconnector
            car power adapter, white
            F8V7067-APL-KIT
            false
            Belkin
            2005-08-01T16:30:25Z
            Belkin Mobile Power Cord for iPod w/ Dock
            1
            19.95
            45.17614,-93.87341
            45.17614
            -93.87341
            45.17614,-93.87341
            4.0

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