因此，我正在浏览有关优化elasticsearch查询的幻灯片，这似乎非常有用：
https://speakerdeck.com/elasticsearch/query-optimization-go-more-faster-better
它提到通过使用类似于以下内容的方法来避免缓存混乱：
curl -XGET 'localhost:9200/_all/_search?search_type=count' -d '
{
"query" : {
"filtered" : {
"filter" : {
"bool" : {
"must" : [
{"range" : {
"@timestamp" : {
"gte" : "now/d"
}
}},
{"range" : {
"@timestamp" : {
"gte" : "now-1h"
},
"_cache" : false
}}
]
}
}
}
}
}'
因此，问题是：日期舍入如何工作？
具体来说，现在/ d实际上指的是什么？这是否仅等同于“今天”？但是，这是否表示“今天根据运行查询的本地计算机”或“今天根据运行Elasticsearch群集的计算机的时区”？我猜很难区分，因为大多数人都在localhost上运行，或者他们的运行Elasticsearch集群的计算机很可能设置为相同的时区...但是我想这是一个小问题。
我猜想，该过滤后的查询的意思是：“搜索所有索引-必须从今天开始，并且必须从过去一小时之内开始。” 我可以看到-“必须从今天开始”是一个应该缓存的过滤器，因为它可以重复使用。elasticsearch github问题在https://github.com/elasticsearch/elasticsearch/issues/4947中提到了这一点
并且我看到了它如何有助于避免缓存混乱，但是我实际上认为，如果它小于或等于而不是大于或等于例如，它将更有用：
"lte" : "now/d"
也就是说“搜索所有索引-必须从今天或更早开始，并且必须从过去一小时之内开始。” 在我看来，这是有道理的，因为它使“今天或更早”成为一个恒定的终点，并允许您从当前固定的时间点向后搜索。这意味着您可以使用这种类型的过滤器组合来避免过去的缓存混乱和搜索，而不仅限于从“今天”开始搜索。但是，我不确定lte版本是否仍然有助于避免缓存混乱。谁能澄清这个问题？
据我了解，因为日期以毫秒为单位，所以我们必须对它们进行四舍五入以使其更通用，并使过滤器结果更有可能在其他查询中重用。我不知道几点会到。但这没关系。舍入到同一件事是很重要的，这样它才可以被缓存重用。
由于应用过滤器的顺序很重要，因此越快缩小记录范围就越好。理想情况下，我们的第一个过滤器是一个缓存的过滤器，并尽可能过滤掉。这就是为什么如果我们要从最近的一个小时中获取数据，则将今天以外的所有内容都过滤掉是有意义的。
让我们考虑您提到的第一个条件：
record_datetime >= now/d && record_datetime >= now-1h
似乎第一个条件是多余的，可以删除而没有任何副作用。但是弹性搜索会从中受益，因为它可以重用已存储的缓存过滤器数据并在更小的集合上执行第二个过滤器。请记住，颠倒过滤器的顺序，我们将失去这种冗余的所有好处。
正如您所提到的，当更深入地回顾过去时，也可以使用此方法。您可以使用过滤器，在某天后将所有内容丢弃。例如，如果我们需要今年第一周的数据，则可以采取以下措施：
record_datetime >= 01.01.2014 && record_datetime <= 05.01.2014 && other_filters
其他过滤器不必与时间相关。如果此操作将被执行多次，则只能other_filters完全执行，其余的将使用缓存的bitset。
而且，这种方法可以用于任何数值数据。例如，在通过精确的纬度和经度进行过滤之前，首先要通过一些粗略的网格或城市进行过滤。我们希望使查询之间的过滤器尽可能相似。
不知道我是否足够清楚:)有一篇不错的文章介绍了使用过滤器提高ES的性能，并在此处说明了您所要求的确切技术。还有关于滤波器的阶数和缓存一ES官方文档在这里。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句