搜索软件/服务器的替代方案，用于检索所有匹配文档的ID

Question

我正在尝试弄清楚如何根据关键字匹配来过滤非常大的文档集。

我的20+million数据库中有带有ID和(几个)文本字段的SQL项，我希望获得文本与一组关键字匹配的所有ID。这包括更复杂的表达式，如：

 (term1 NEAR term2 NEAR term3) AND NOT "A phrase" AND @fieldXYZ "wildcards%aswell*"

结果不需要以任何方式进行评分、排序或排名。

据我所知，Lucene/Solr、Sphinx和ElasticSearch的强大之处在于能够超级快速地返回顶级文档，但它们并不是真的打算返回所有文档。

我知道可以使用Lucene中的自定义收集器(参见What's the most efficient way to retrieve all matching documents from a query in Lucene, unsorted?)和Solr/Elasticsearch中的游标/滚动来实现这一点，但我想知道是否有其他技术专门针对这个问题进行了优化？

Answer 1

据我所知，Lucene/

，Sphinx和ElasticSearch的强大功能是超快地返回顶级文档，但它们并不是真正打算返回所有文档。

实际上，这曾经是真的，但最近几年变得更好了。当涉及到其他软件选项时，我会听从其他人的意见，但是Lucene在4.x系列的早期确实得到了一些改进，可以使用游标进行高效的深度分页。

为此，Elasticsearch有一个特别好的应用程序接口：Scrolling Search。要使用它，需要提供带有scroll参数的搜索查询。然后，它返回一个scroll_id游标，您可以使用该游标对每个页面进行后续请求。

如果不关心排序，只想返回所有文档，那么还可以将搜索类型指定为scan。这将以最有效的顺序返回所有文档，而不会应用特定的排序。

我在这里略微介绍了一些细节，您需要查看Scrolling Search文档以获得更全面的描述。

从SOLR-5463中的Solr4.7开始，Solr还支持深度分页。它增加了对与搜索请求一起使用的cursorMark参数的支持。然后，Solr返回一个指向每个后续页面的nextCursorMark。

请参阅Solr的Pagination of Results文档中的“使用游标”一节。

听起来OP已经熟悉了这些选项，但我认为为了其他有类似问题的人，它是值得充实的。

同样有趣的是：my take on the mechanics and efficiency of an Elasticsearch scrolling search。

Answer 2

如果它对处理相同问题的任何人都有帮助，这里是我要使用的解决方案。

我正在使用Lucene和一个自定义的收集器，它存储所有匹配的ID，没有任何处理：

class IDCollector : Collector
{
    // Offset for multiple reader
    private int docBase;

    // Stores IDs for all hits
    public List<int> HitList { get; set; }

    public IDCollector() 
    { 
         this.HitList = new List<int>(INITIAL_CAPACITY); 
    }

    public override void Collect(int doc) 
    { 
        HitList.Add(doc + docBase); 
    }

    // Order of docs does not matter
    public override bool AcceptsDocsOutOfOrder { get { return true; } }

    // Default implementation, docBase is the offset from reader
    public override void SetNextReader(IndexReader reader, int docBase) 
    { 
        this.docBase = docBase; 
    }

    // Scoring is not necessary
    public override void SetScorer(Scorer scorer) { }
}

这样，对于像term1* OR term2* OR term3* OR term4*这样的查询，可以在大约5.5秒内收集每个匹配文档的所有~30mioID。

不幸的是，即使没有对命中进行任何评分、排序或类似的处理，搜索速度也非常依赖于命中的数量，但这可能是不可避免的。