Solr如何在太多原子更新后提高查询速度

Question

我正在使用具有3个实例（每个实例16GB RAM）的solrCloud 7.4，并具有1个具有10m数据的集合。首先，它真的非常快，几乎没有查询超过2秒的时间。

然后，我已使用其他oracle数据库中的交易（即受欢迎程度）数据进行了更新，以使我的收藏更加相关。我只是简单地循环事务，然后使用诸如set和inc之类的Solr原子更新大约1〜10个字段（几乎所有字段类型float n long）。但是交易有超过300m的数据。因此，进程i每{10k个交易数据} set和inc到solr中收集。

300m数据的更新部分仅处理一次，此后可能需要50k /天并在凌晨0点进行处理。

最后。该集合仍然有10m的数据，但是看起来我的查询速度降低了近10秒。

我查看分片概述，每个分片都有20多个细分，其中一半已删除文档：

• 我在这里有什么想念的地方，为什么查询时间减少了吗？
• 我如何像以前一样再次加速？
• 我应该在原子更新（从300m transc）到我的新馆藏之后将我的10m馆藏复制并创建新馆藏吗？

Answer 1

此问题是由于创建了许多段而导致的，这些段主要由已删除的文档组成。当您执行原子更新时，将获取前一个文档，更改值，并为新文档（具有新值）建立索引。这样会将旧文档保留为删除状态，而将新文档写入新文件中。

命中mergeFactor值时这些段将合并；也就是说，当细分的数量足够多时，它们会合并到一个新的细分文件中，而不是周围有多个文件。发生这种合并时，删除的文档将被删除（无需将不再存在的文档写入新文件）。

您可以通过发出优化来强制执行此过程，尽管通常可以依靠mergeFactor来完成工作（取决于mergeFactor的值和索引策略），但数据集是一口气进行更新（例如晚上一次），然后发布优化程序就可以了。

不利的一面是，它将需要额外的处理（但是，如果您只是依靠mergeFactor，无论如何都将发生这种情况，但并非同时所有内容都会发生），并且最多将当前索引大小的2倍作为临时空间。

您可以通过调用集合的更新终结点来执行优化：http://localhost:8983/solr/collection/update?optimize=true&maxSegments=1&waitFlush=false

maxSegments值告诉Solr可接受多少段。默认值为1。对于大多数使用情况来说，就可以了。

尽管调用优化的代表不好（因为mergeFactor通常应该为您完成工作，而且人们往往过于频繁地调用优化），但这是优化的一个很好的用例。还有optimization enhancements for the optimize command in 7.5，这将有助于避免以前最坏的情况。