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