Одна из новых функций, которая будет представлена в Solr 4.0, — это новая реализация SpellChecker, которая не требует своего собственного индекса. Я решил быстро взглянуть на это и поделиться своими мыслями.
Что мы имеем сегодня
На сегодняшний день ( Solr 3.6 ) мы можем использовать следующие реализации SpellChecker:
- org.apache.solr.spelling.IndexBasedSpellChecker
- org.apache.solr.spelling.FileBasedSpellChecker
С выходом Solr 4.0 мы получим новую реализацию:
- org.apache.solr.spelling.DirectSolrSpellChecker
Текущие проблемы
В большинстве случаев я работал с основной проблемой IndexBasedSpellChecker, заключавшейся в необходимости перестроения его индекса. В некоторых случаях перестройка была долгой, и невозможно было перестроить этот индекс после каждой фиксации, что для некоторых было проблемой. Конечно, это не было проблемой с FileBasedSpellChecker , но опять же, в моем случае, он использовался в качестве механизма поддержки IndexBasedSpellChecker .
конфигурация
Конфигурация DirectSolrSpellChecker аналогична той, которую вы используете сегодня в Solr 3. Конечно, есть некоторые дополнительные параметры. Ниже вы можете найти образец конфигурации:
<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>
И значение для каждого из параметров:
- queryAnalyzerFieldType — имя типа, на основе которого будет анализироваться запрос SpellChecker.
- field — поле, содержимое которого будет использоваться для построения результатов SpellChecker.
- classname — класс реализации SpellChecker.
- distanceMeasure — алгоритм, который будет использоваться для вычисления терминов дистанции, в нашем случае мы будем использовать стандартные (Levensthein’s).
- точность — точность, которая должна быть достигнута, чтобы предложение считалось правильным.
- maxEdits — максимальное количество изменений во время перечисления терминов. Это свойство может быть установлено в 1 или 2 .
- minPrefix — минимальный, общий префикс при перечислении терминов.
- maxInspections — максимальное количество проверок для каждого предложения.
- minQueryLength — минимальная длина предложения для работы, которая будет принята за правильное предложение.
- maxQueryFrequency — максимальный процент документов, в которых слово может отображаться для слова, которое следует рассматривать как исправляемое ( значение 0,01 означает 1% ).
- thresholdTokenFrequency — минимальный процент документов, в которых предложение должно появляться, чтобы оно считалось правильным ( .01 значение означает 1% ).
Приведенные выше атрибуты конфигурации показывают, что DirectSolrSpellChecker дает нам большую степень конфигурации поведения.
использование
DirectSolrSpellChecker ничем не отличается от других реализаций SpellChecker, когда дело доходит до его использования. Как и в предыдущих реализациях, вы можете настроить Solr для добавления результатов SpellChecker к каждому результату запроса или просто настроить новый обработчик и решить, когда запрашивать его для результатов. Мы писали о том, как использовать SpellChecker в прошлом — в примере « Приложение для продажи автомобиля ».
Что мы можем ожидать?
Согласно информации, которую мы видим в выпуске JIRA, LUCENE-2507 DirectSolrSpellChecker не только устранит необходимость в отдельном индексе, но также улучшит качество предложений. Из того, что вы видите в упомянутой проблеме JIRA, DirectSolrSpellChecker работает лучше по сравнению с предыдущими реализациями, хотя он немного медленнее, но я думаю, что это не будет проблемой, если вы не используете SpellChecker с каждым запросом.