Solr 中 IndexBasedSpellChecker 和 DirectSolrSpellChecker 的区别?
Difference between IndexBasedSpellChecker and DirectSolrSpellChecker in Solr?
在查看 Solr 中的拼写检查功能时,我发现了以下类型的 solr SpellChecker
- IndexbasedSpellChecker
- DirectSolrSpellChecker
- FileBasedSpellChecker
我从 solr 文档定义中了解到的内容“DirectSolrSpellChecker 使用 Solr 索引中的术语,而没有像 IndexBasedSpellChecker 那样构建并行索引”是,IndexbasedSpellChecker 创建了一个并行索引,每当使用构建并行索引的基础索引发生变化时,我们都需要重建这个并行索引
但在 DirectSolrSpellChecker 中不会创建并行索引,因此无需一次又一次地重建
我的问题是如果创建并行索引是这两种拼写检查类型之间的唯一区别,为什么 solr 在 Solr4.0 版本中创建新类型 DirectSolrSpellChecker 而不是更新 IndexbasedSpellChecker。
由于他们没有更新 IndexbasedSpellChecker,而是创建了名为 DirectSolrSpellChecker 的新类型,我的问题是:
构建并行索引(如IndexbasedSpellChecker)的优势和不构建并行索引的拼写检查的优势(如DirectSolrSpellChecker)
IndexbasedSpellChecker 和 DirectSolrSpellChecker 之间的实际区别是什么
什么时候应该使用 IndexbasedSpellChecker 和 DirectSolrSpellChecker
部分答案在您的问题中(唯一的区别是一个需要自己的索引,另一个不需要),但我要补充:
DirectSolrSpellChecker
使用 Solr 索引中的术语,这意味着它具有不必定期构建的好处,因为术语始终与来自主要指标。
缺点是每次 更改 solr 索引都会花费更多的时间来维护拼写检查器使用的这些术语。
相反,IndexbasedSpellChecker
使用自己的索引,从主索引构建。此处的优点是您可以决定何时提交更改并重建字典。
假设您需要一个实时索引让您的用户能够快速搜索和检索他们更新的文档,这在性能方面可能非常昂贵。在这种情况下,有一个单独的拼写检查索引可以防止每次主索引更改时更新拼写检查字典(通过设置 buildOnCommit=false
),即。您可以按计划或手动触发重建。您仍然可以设置 buildOnCommit=true
在每次提交时重建拼写检查索引。
缺点是需要更多space。
在https://issues.apache.org/jira/browse/LUCENE-2507中,DirectSolrSpellChecker
的作者给出了一些证据,与IndexbasedSpellChecker
相比,不仅更方便(没有重建单独的索引)并且节省了大量磁盘space(没有存储单独的索引)而且还提供了更合理的建议。唯一的缺点是相当微不足道的 query-time 性能损失。
看起来 DirectSolrSpellChecker
应该是一个强烈推荐的默认选项,甚至可以完全取代旧的拼写检查器,但由于项目惰性,它根本没有发生。不幸的是,新用户现在很困惑。
在查看 Solr 中的拼写检查功能时,我发现了以下类型的 solr SpellChecker
- IndexbasedSpellChecker
- DirectSolrSpellChecker
- FileBasedSpellChecker
我从 solr 文档定义中了解到的内容“DirectSolrSpellChecker 使用 Solr 索引中的术语,而没有像 IndexBasedSpellChecker 那样构建并行索引”是,IndexbasedSpellChecker 创建了一个并行索引,每当使用构建并行索引的基础索引发生变化时,我们都需要重建这个并行索引
但在 DirectSolrSpellChecker 中不会创建并行索引,因此无需一次又一次地重建
我的问题是如果创建并行索引是这两种拼写检查类型之间的唯一区别,为什么 solr 在 Solr4.0 版本中创建新类型 DirectSolrSpellChecker 而不是更新 IndexbasedSpellChecker。
由于他们没有更新 IndexbasedSpellChecker,而是创建了名为 DirectSolrSpellChecker 的新类型,我的问题是:
构建并行索引(如IndexbasedSpellChecker)的优势和不构建并行索引的拼写检查的优势(如DirectSolrSpellChecker)
IndexbasedSpellChecker 和 DirectSolrSpellChecker 之间的实际区别是什么
什么时候应该使用 IndexbasedSpellChecker 和 DirectSolrSpellChecker
部分答案在您的问题中(唯一的区别是一个需要自己的索引,另一个不需要),但我要补充:
DirectSolrSpellChecker
使用 Solr 索引中的术语,这意味着它具有不必定期构建的好处,因为术语始终与来自主要指标。缺点是每次 更改 solr 索引都会花费更多的时间来维护拼写检查器使用的这些术语。
相反,
IndexbasedSpellChecker
使用自己的索引,从主索引构建。此处的优点是您可以决定何时提交更改并重建字典。假设您需要一个实时索引让您的用户能够快速搜索和检索他们更新的文档,这在性能方面可能非常昂贵。在这种情况下,有一个单独的拼写检查索引可以防止每次主索引更改时更新拼写检查字典(通过设置
buildOnCommit=false
),即。您可以按计划或手动触发重建。您仍然可以设置buildOnCommit=true
在每次提交时重建拼写检查索引。缺点是需要更多space。
在https://issues.apache.org/jira/browse/LUCENE-2507中,DirectSolrSpellChecker
的作者给出了一些证据,与IndexbasedSpellChecker
相比,不仅更方便(没有重建单独的索引)并且节省了大量磁盘space(没有存储单独的索引)而且还提供了更合理的建议。唯一的缺点是相当微不足道的 query-time 性能损失。
看起来 DirectSolrSpellChecker
应该是一个强烈推荐的默认选项,甚至可以完全取代旧的拼写检查器,但由于项目惰性,它根本没有发生。不幸的是,新用户现在很困惑。