Performance Elasticsearch：最佳性能的过滤器顺序

Elasticsearch指南说

每个筛选器都是独立计算和缓存的，无论在何处使用。如果两个不同的查询使用相同的筛选器，则将重用相同的筛选器位集。同样，如果单个查询在多个位置使用相同的筛选器，则只计算并重用一个位集 （）

在另一页上，它还说：

“bool子句中过滤器的顺序对性能很重要。为了尽可能早地排除尽可能多的文档，应该在不太具体的筛选器之前放置更具体的筛选器。如果A条可以匹配1000万份文件，而B条只能匹配100份文件，那么B条应该放在A条之前。” （）

我不太明白当每个过滤器都独立缓存时，bool子句中过滤器的顺序是如何重要的

---

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

我认为将较小的匹配文档集合并到较大的文档集更有效，或者按此顺序操作会提供更高的机会零匹配，因此可以走捷径。需要检查源代码（和）才能确定

---

如果我错了，请纠正我…

并非所有筛选器都是可缓存的。例如，使用

now

变量的日期范围筛选器不会缓存，因为它一直在更改。如果您在给出的第一个链接中再往下看一点，您将看到一个名为的部分，其中说明了以下事实：

但是，某些叶过滤器在默认情况下不会缓存，因为这样做没有意义：脚本过滤器、地理位置过滤器、日期范围过滤器

为了说明这一点，假设我们有以下日期

range

filter（我们称之为filter A），它过滤过去一个月的所有文档

"range" : {
    "timestamp" : {
         "gt" : "now-1m"
    }
}

还有另一个

术语

过滤器（我们称之为过滤器B），用于过滤类型为

XYZ

"term" : {
    "type" : "XYZ"
}

如果您将

过滤器A在过滤器B之前，或

过滤器A之前的过滤器B

在案例1中，执行速度会变慢，因为上个月的所有文档都需要先通过过滤器A，而过滤器A不会被缓存

在案例2中，您首先过滤掉所有没有

类型的文档，这很快，因为过滤器B是缓存的。然后通过过滤器B的文档可以通过过滤器A。因此，即使过滤器A没有缓存，执行速度也会更快，因为过滤器pip中剩下的文档会更少艾琳

这是一个非常简单的示例，但它应该说明为什么过滤器顺序很重要，即主要是因为某些过滤器未被缓存。您可以通过强制缓存来更改默认行为，但有时这不是一个好主意。最佳做法是首先应用最激进的过滤器，以便让尽可能少的文档被缓存让我们通过下一个过滤器

我个人称之为“推土机方法”，即首先确保在过滤管道中尽早处理尽可能多的材料，最终得到的数据块更容易咀嚼，处理速度更快。
此指南有点误导。它更为复杂，而且很难尝试编写一套适合所有情况的规则。随着数据的变化，规则也随之变化。随着查询和筛选器类型的更改，规则也会更改。如果规则发生变化，则特定筛选器的执行速度可能比广泛筛选器慢。在每段的基础上，过滤器的结果大小可能与另一段的结果大小相反，这并不总是可预测的。因此，首先您必须了解更多的内部内容，然后在进入现代Elasticsearch 2.x时，您需要放弃尝试控制它

注意：您的第二个报价（过滤顺序）和相关链接指向的页面对于Elasticsearch 2.x而言被视为“过时”，稍后将进行更新。因此，该建议可能适用于现代，也可能不适用于现代

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

让我们首先讨论如何在内存中表示过滤器。它们要么是匹配文档的迭代列表，要么是随机访问“IsIthere”模型。取决于过滤器的类型，取决于哪个更有效。现在，如果所有的东西都被缓存了，那么您只需将它们相交，成本将因大小和类型而异

如果过滤器未缓存，但可缓存，则过滤器将独立执行，而之前的过滤器只会通过交叉点的总成本对其产生影响

如果筛选器不可缓存，则可以根据以前的结果进行引导。想象一个
查询
加上一个
过滤器
。如果您执行查询，并且在应用过滤器之后，如果过滤器限制为一个非常小的记录集，那么您将做大量额外的工作。在查询过程中，您浪费了大量的时间来收集、评分和整体构建一大组结果。但是如果您转换为
FilteredQuery
并同时执行这两项操作，则
Query
将忽略已被
过滤器删除的所有记录。它只需要考虑已经播放的相同文档。这被称为“跳过”。并非所有的过滤器类型都能利用跳过，但有些可以。这就是为什么更小的“引导”过滤器会让其他人更快地使用它

除非您知道每种过滤器类型、数据的启发式方法以及每个特定过滤器将如何受到这些过滤器的影响，否则您就没有足够的信息，只能说“将限制最大的过滤器放在第一位，将较大的过滤器放在第二位”，并希望它能起作用。对于
bool
而言，默认情况下不缓存其总体