针对超出范围索引的弹性时间范围查询的性能

Question

使用日期弹性索引是很常见的，特别是来自诸如 logstash 之类的东西。

因此，例如，你有一个像指数foo-2016.05.01，foo-2016.05.02等...

对数据进行时间范围查询时。查询我已经知道在该时间范围内没有数据的索引的成本是多少？

因此，例如，如果时间范围查询仅询问 2016.05.02 的数据，但我还在foo-2016.05.01查询中包含索引。

这基本上是每个索引的快速单操作，其中索引知道它在该日期范围内没有数据，还是这样做会影响性能？我不仅希望知道是/否的答案，还希望了解它为什么会这样。

Answer 1

简而言之：它可能会很贵。成本将是n其中n是日期数据的不同字段值的数量。如果索引中的所有条目都具有相同的日期字段值，那么这将是一个廉价的检查查询1（并且毫无意义，因为此时它是一个二进制“全有或全无”响应）。当然，现实情况通常是每个文档都有一个唯一的日期字段值（它是递增的，例如在日志中），具体取决于日期的粒度（假设此处时间包括秒或毫秒）。Elasticsearch 将检查所包含索引的每个聚合的唯一日期字段值，以尝试通过满足范围查询的谓词来查找与该字段匹配的文档。这就是倒排索引（按字段索引文档）的本质。

提高性能的一个简单方法是将范围查询更改为范围过滤器，它可以缓存结果并提高第一个请求之外的请求的性能。当然，只有当您随着时间的推移重复相同的范围过滤器（缓存读取的次数多于写入的次数），并且范围不是对文档进行评分的一部分（也就是说范围内的文档是返回一组两者时，并不比那些不在范围内的值更有价值 - 也称为“提升”）。

另一种提高性能的方法是遵循惯例。如果按天查询，则将每一天存储在自己的滚动索引中，然后执行预搜索逻辑以选择要查询的索引。这完全消除了对过滤器或查询的需要。