Solr 4.0: DirectSolrSpellChecker

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:

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.

3 thoughts on “Solr 4.0: DirectSolrSpellChecker

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.