Elasticsearch：过滤器顺序以获得最佳性能

Question

Elasticsearch指南说

“每个过滤器都是独立计算和缓存的，而不管它在哪里使用。如果两个不同的查询使用相同的过滤器，则相同的过滤器位集将被重用。同样，如果单个查询在多个位置使用相同的过滤器，则只有一个位集计算后再使用。”
（https://www.elastic.co/guide/zh-CN/elasticsearch/guide/current/filter-
caching.html
）

在另一页上还显示：

“
bool子句中过滤器的顺序对于性能很重要。应在较不特定的过滤器之前放置特定的过滤器，以便尽早排除尽可能多的文档。如果A子句可以匹配1000万个文档，并且B条只能匹配100个文档，则B条应放在A条之前。”
（https://www.elastic.co/guide/zh-
CN/elasticsearch/guide/current/_filter_order.html）

我不太了解在单独缓存每个过滤器时bool子句中的过滤器顺序很重要。

我可以想象，子句B是从缓存中执行或检索的，子句A是从缓存中执行或检索的，然后过滤器位集被“合并”。为什么顺序很重要？

Answer 1

该指南有点误导。这更加复杂，并且很难尝试编写适合所有情况的一组规则。随着数据的更改，规则也会更改。随着查询和过滤器类型的更改，规则也会更改。规则更改后，特定的过滤器执行起来可能会比广泛的过滤器慢。在每个细分受众群的基础上，过滤器的结果大小可能与在另一个细分受众群中的大小相反，但并非总是可以预测的。
因此，首先您必须了解更多内部信息 ，然后在进入现代Elasticsearch 2.x时需要放开对它的控制。

注意： 您的第二个报价（过滤器顺序）和相关链接是针对Elasticsearch 2.x的“已过时”页面，它将在以后进行更新。
因此，该建议可能不适用于现代。

回顾一下Elasticsearch 1.x以及订购建议的原因：

让我们先谈谈过滤器如何在内存中表示。它们要么是匹配文档的迭代列表，要么是随机访问“它在这里”模型。根据过滤器的类型，取决于哪种效率更高。现在，如果所有内容都已缓存，您将与它们相交，并且成本将因大小和类型而异。

如果过滤器未缓存但可缓存，则过滤器将独立执行，并且先前的过滤器将仅受相交的总成本影响。

如果过滤器不可缓存，那么它可能会受到先前结果的指导。想象一个Query加号Filter。如果执行查询，并在应用过滤器后，如果过滤器限制为一小组非常小的记录，那么您将做很多额外的工作。您在查询中浪费了时间来收集，评分和总体构建大量结果。但是，如果您转换为a
FilteredQuery并同时执行两个操作，则Query忽略将忽略所有已被删除的记录Filter。它只需要考虑已经在使用中的相同文件。这称为“跳过”。并非所有过滤器类型都可以使用跳过功能，但有些可以。这就是为什么较小的“引导”过滤器会使其他人更快地使用它的原因。

除非您了解每种过滤器类型，数据的启发式方法以及每种特定的过滤器将如何影响这些过滤器，否则您将没有足够的信息，只能说
“首先将限制最大的过滤器放到第二位，然后将较大的过滤器放到第二位”
，希望能解决。对于bool默认为，所以你必须要注意其持续进行（和/或它缓存）不要缓存它的整体效果。当过滤器交点的一侧较小时，效率更高。因此，从一个较小的交叉点开始，会使所有其他交叉点更快，因为它们只会变得更小。如果这是bool
查询 而不是 过滤器 进行评分，则避免为不必要的文档评分更为重要。

另一个重要的注意事项是， “最具体的过滤器优先” 有时可能很慢（脚本过滤器或其他过滤器），因此它的确应显示为： “成本最低，最具体的过滤器优先” 。

有了 Elasticsearch 2.0，一切都会改变：

现在该忘记有关查询和过滤器的所有知识了：Elasticsearch 2.0本身将做出更好的决策，而不是依靠用户来制定优化的查询。

在2.x版本中，您应该减少游戏系统的尝试，并让引擎做出最佳选择。实际上，引擎可能在引擎盖下产生了完全不同的变化，重新编写了过滤器，内部结构和数据发生了完全变化。而且，您甚至可能不再控制缓存。因此，您需要阅读更多有关此的内容。

以前的筛选器API可以通过两种方式使用：要么在匹配的文档上使用迭代器，要么使用允许检查特定文档是否与筛选器匹配的可选随机访问API。到目前为止，一切都很好，只是使用过滤器的最佳方法取决于您使用的是哪种过滤器：例如，script使用随机访问API时bool过滤器效率更高，而使用迭代器API
时过滤器效率更高。优化是一场噩梦，并且是bool一方面过滤器and和另一方面与or过滤器性能不同的根本原因。

现在，引擎将决定最好的方法，同时考虑更多因素，包括评分，结果大小估计，与相关过滤器相交的最佳方法，甚至可能以每个细分为基础等等。

此外，本文还明确指出，即使缓存也可能会产生误导，但并不总是会使事情变得更快。有时，内部数据结构最初使用时要比始终缓存的位集结构更好。因此，在2.x中，这种情况也发生了变化，从而避免了在不进行缓存的情况下缓存从本机数据结构执行得更好的事物。

在博客文章“ 咆哮的位图”中有更多详细信息：

显然，最重要的要求是快速执行某些操作：如果缓存的筛选器比重新执行筛选器慢，那么它不仅会消耗内存，还会使查询变慢。编码越复杂，由于CPU使用率增加，编码和解码的速度就越可能降低

在这里，您可以获得有关内部数据结构，缓存，交集以及有关2.x的内部更改的更多信息的大量信息，这将有助于您更深入地了解过滤器性能。

如果您不熟悉搜索引擎内部知识可能会让您感到惊讶，但搜索引擎最重要的组成部分之一是能够有效压缩和快速解码已排序的整数列表。

从这最后的2.x博客链接中，您对问题有很多了解，他们谈论了您正在尝试使用过滤器排序的所有问题。那里的信息和详细信息都在这里，您可以更好地了解1.x与2.x，以及如何解决查询+过滤器。因此请记住：

没有一种特定的实现总是比其他所有实现更好。

另请参阅以下1.x资源以获取历史参考：

• 优化Elasticsearch搜索涵盖了有关过滤器排序的更多内容。它总结说：

就是说，您仍然需要考虑要过滤的顺序。希望先运行更具选择性的过滤器。假设您针对以下类型进行过滤：图书和标签：elasticsearch。如果您有3000万份文档，一千万本打字本，并且只有10个带标签的Elasticsearch，则需要首先应用标签过滤器。与书籍过滤器相比，它减少的文档数量更多。

• 关于Elasticsearch过滤器位集的所有信息在现代都被视为过时的文章，但它为您引用的过滤器订购文档提供了更多背景知识。

• Martijn v Groningen在论坛上的回答似乎说的是bool与and查询有关使用迭代还是随机访问的情况相反，但是两者的想法是相同的：通过限制过滤器列表中较早的文档来确保安全-不管使用哪种模型是针对一种类型与另一种类型的。