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:

<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
  <str name="queryAnalyzerFieldType">textTitle</str>
  <lst name="spellchecker">
    <str name="name">default</str>
    <str name="field">title</str>
    <str name="classname">solr.DirectSolrSpellChecker</str>
    <str name="distanceMeasure">internal</str>
    <float name="accuracy">0.7</float>
    <int name="maxEdits">2</int>
    <int name="minPrefix">1</int>
    <int name="maxInspections">5</int>
    <int name="minQueryLength">4</int>
    <float name="maxQueryFrequency">0.01</float>
    <float name="thresholdTokenFrequency">.01</float>
  </lst>
</searchComponent>

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.