java - SOLR 7+/Lucene 7+ 以及 DelegatingCollector 和 PostFilter 的性能问题

Question

这是我面临的情况。

我正在从 SOLR 4 迁移到 SOLR 7。SOLR 4 在 Tomcat 8 上运行，SOLR 7 在内置 Jetty 9 上运行。最大的核心包含大约 1,800,000 个文档(约 3 GB)。

迁移顺利进行。但是有些事情困扰着我。

我有一个 PostFilter 可以根据预先选择的列表只收集一些文档。这是 org.apache.solr.search.DelegatingCollector 的代码:

@Override
protected void doSetNextReader(LeafReaderContext context) throws IOException {
    this.reader = context.reader();
    super.doSetNextReader(context);
}

@Override
public void collect(int docNumber) throws IOException {
    if (null != this.reader && isValid(this.reader.document(docNumber).get("customid")))
    {
        super.collect(docNumber);
    }
}

private boolean isValid(String customId) {
    boolean valid = false;
    if (null != customMap) // HashMap<String, String>, contains the custom IDs to keep. Contains an average of 2k items
    {
        valid = customMap.get(customId) != null;
    }

    return valid;
}

下面是发送到 SOLR 的查询示例:

/select?fq=%7B!MyPostFilter%20sessionid%3DWST0DEV-QS-5BEEB1CC28B45580F92CCCEA32727083&q=system%20upgrade

所以，问题是:

它在 SOLR 4 上运行得非常快，平均 QTime 等于 30。

但现在在 SOLR 7 上，它非常慢，平均 QTime 约为 25000!

我想知道这种糟糕表现的根源是什么......

使用非常简化的(或者我应该说透明的)收集功能(见下文)，没有退化。这个测试只是为了从等式中排除服务器/平台。

@Override
public void collect(int docNumber) throws IOException {
    super.collect(docNumber);
}

我的猜测是，自 LUCENE 7 以来，API 访问文档的方式发生了巨大变化，但我不确定是否已理解所有内容。我从这篇文章中得到它:How to get DocValue by document ID in Lucene 7+?

我想这与我面临的问题有关。但我不知道如何升级/更改我的 PostFilter 和/或 DelegatingCollector 以恢复良好的性能。

如果任何 LUCENE/SOLR 专家可以提供一些提示或线索，将不胜感激。提前致谢。

附言:在核心架构中:

<field name="customid" type="string" indexed="true" stored="true" required="true" multiValued="false" />

这个字段是字符串类型的，因为它可以是像“100034_001”这样的东西。

在 solrconfig.xml 中:

<queryParser name="MyPostFilter" class="solrpostfilter.MyQueryPaser"/>

如果需要，我可以共享完整的架构和 solrconfig.xml 文件，但到目前为止，那里没有其他特定的配置。

编辑

在深入研究 API 之后，我用以下内容更改了 collect 函数:

@Override
public void collect(int docNumber) throws IOException {
    if (null != reader)
    {
        SortedDocValues sortedDocValues = reader.getSortedDocValues("customid");
        if (sortedDocValues.advanceExact(docNumber) && isValid(sortedDocValues.binaryValue().utf8ToString()))
        {
            super.collect(docNumber);
        }
    }
}

现在 QTime 的平均值下降到 1100，这已经好很多了，但与我使用 SOLR 4 时的 30 还是相去甚远。

不确定是否有可能对此进行更多改进，但仍然非常欢迎任何其他建议/评论。/干杯

Answer 1

使用过滤器查询而不是后置过滤器。

这个答案并没有试图提高后置过滤器的性能，而是使用了不同的方法。尽管如此，与对后置过滤器所做的任何改进相比，我得到了更好的结果(10 倍)。

在这里检查我的代码:https://github.com/cheffe/solr-postfilter-sample

增加maxBooleanClauses

访问您的solrconfig.xml。添加或调整<query> ... </query>包含子元素的元素 maxBooleanClauses值为 10024。

<query>
  <!-- other content left out --->
  <maxBooleanClauses>10024</maxBooleanClauses>
</query>

这将允许您添加大型过滤器查询而不是后置过滤器。

添加所有customids作为过滤查询

这个查询变得很大，但性能却好得多。

fq=customid:(0_001 1_001 2_001 3_001 4_001 5_001 ... 4999_001 5000_001)

执行时间与后置过滤器的比较

后置过滤器处理 5.000 个 ID 需要 320 毫秒，相比之下，过滤器查询处理相同数量的 ID 需要 22 毫秒。