lucene - Lucene/Solr如何在多字段/多面搜索中实现高性能？

Question

上下文

这主要是关于Lucene(或可能是Solr)内部的问题。主要主题是分面搜索，其中搜索可以沿着多个独立的对象维度(例如大小，速度，汽车价格)进行。

当使用关系数据库实现时，对于大量构面而言，多字段索引没有用处，因为可以按任意顺序搜索构面，因此使用特定顺序的多索引的可能性很小，因此创建索引的所有可能顺序是难以忍受。

宣传Solr是为了很好地应对多面搜索任务，如果我认为正确的话，必须将其与Lucene关联(据说)在多字段查询(文档的字段与对象的方面有关)上表现良好。

问题

Lucene的反向索引可以存储在关系数据库中，自然也可以通过使用单字段索引的RDBMS轻松获取匹配文档的交集。

因此，Lucene可能具有一些用于多字段查询的先进技术，而不仅仅是基于倒排索引获取匹配文档的交集。

所以问题是，这是什么技巧？更广泛地说:从理论上讲，Lucene/Solr为什么能获得比RDBMS更好的多面搜索性能(如果可以的话)？

注意:我的第一个猜测是Lucene将使用某种空间划分方法来划分从文档字段构建的向量空间作为维，但是据我所知Lucene并非纯粹基于向量空间。

Answer 1

构面

关于构面，有两个答案，因为存在两种类型的构面。我不确定这两个都比RDBMS快。

枚举构面。查询的结果是一个位向量，如果第i个文档匹配，则第i位为1。构面也是位向量，因此交集只是按位与。我认为这不是一种新颖的方法，大多数RDBMS可能都支持它。

字段缓存。这只是一个正常的(非反向)索引。在此处运行的SQL样式查询类似于:

从face_cache中选择facet，count(*)
其中docId在query_results中
按构面分组

同样，我不认为这是普通RDBMS无法做到的。索引是一个跳过列表，以docId作为键。

长期搜索

这是Lucene闪耀的地方。为什么Lucene的方法如此好，现在在这里发布太长了，但是我可以推荐this post on Lucene Performance或其中链接的论文。