调用搜索大师：Lucene的数字范围搜索性能？

Question

我正在研究一个系统，该系统根据字符串和数字范围以及日期范围对大型记录集进行匹配。据我所知，字符串匹配大多是精确匹配，而不是我所理解的lucene通常设计的不太精确的全文搜索类型结果。由于数据涉及价格，因此数字精度很重要。

我注意到Lucene最近添加了一些对数值范围搜索的支持，但它不是最初设计的。

目前，系统使用过程SQL进行匹配，并且就系统的可扩展性达到了限制。我正在研究水平扩展系统的方法，并且使用搜索引擎技术似乎是一种可能性，因为有些技术可以扩展到非常大的数据集，同时执行非常快速的搜索结果。我想研究是否可以通过与lucene生成的元数据匹配来减少数据库的负担，而不会在数据库中查找完整记录，直到匹配规则确定应该检索的内容为止。我想最终的目标是近乎实时的结果，尽管我们距离目前还有很长的路要走。

我的问题如下：对于这种类型的索引和搜索，Lucene可能会比RDBMS更快地执行更多次并扩展到更大的数据集吗？

Answer 1

1. Lucene将其数字内容存储为trie; SQL实现可能会将其存储为b树或r树。 Lucene存储它的trie和SQL使用R树的方式非常相似，如果你看到了巨大的差异（除非你利用了Solr的一些可扩展性），我会感到惊讶。
2. 作为Lucene与SQL全文表现的一般性问题，我发现的一项很好的研究是：Jing，Y.，C。Zhang和X. Wang。 “Lucene与关系数据库性能比较的实证研究”，“通信软件与网络”，2009年.ICCSN'09。国际会议，336-340。 IEEE，2009。

  

首先，执行时   确切的查询，Lucene的表现要好得多   unindexed-RDB的那个，与几乎相同   索引-RDB。其次，当通配符查询是前缀时   查询，然后indexed-RDB和Lucene都表现得很好   还是通过利用指数......第三，对于组合查询，Lucene执行   顺利而且通常花费很少的时间，而查询时间   RDB与组合搜索条件有关   索引字段的数量。如果在某些领域   组合条件尚未编入索引，搜索会   花费更多的时间。第四，Lucene和。的查询时间   unindexed-RDB与记录复杂性有关系，   但索引的RDB几乎与它无关。

简而言之，如果您正在进行“select * where x = y”之类的搜索，那么您使用哪种搜索无关紧要。你添加的条款越多（x = y OR（x = z AND y = x）......）Lucene变得越好。

他们并没有真正提到这一点，但Lucene的一个巨大优势是所有内置功能：词干，查询解析等。

Answer 2

我建议你阅读Marc Krellenstein's "Full Text Search Engines vs DBMS".

开始使用Lucene的一种相对简单的方法是尝试Solr。您可以scale Lucene and Solr使用复制和分片。

Answer 3

Lucene的核心和最简单的形式是一个词密度搜索引擎。 Lucene可以扩展以处理极大的数据集，并且在正确索引时以极快的速度返回结果。对于基于文本的搜索，搜索结果很可能会在Lucene中更快地返回，而不是SQL Server / Oracle / My SQL。据说将Lucene与传统的RDBMS进行比较是不公平的，因为它们都有完全不同的用法。