Elasticsearch filter context 的使用原理

ES querycache 加速匹配的方法

前言

ES 进行信息检索的时候,boolean 查询组合条件有 must/must_not/should/filter 四个操作。其中 must 和 filter 的用途都是用于过滤必要符合的条件,但是 filter 在查询过程中不算分并且可以进行缓存,这样逻辑简单又可以加速的查询方式经常得到 Elastic 的提倡。

可是,只有 filter 的条件可以被缓存么?这里的缓存是属于哪一部分?缓存有什么样的进入和淘汰机制?怎么去监控缓存的使用情况?

这些问题也会伴随着对 ES 的深入使用自然而然的产生。本文中,我们结合 Elastic 的一些资料进行探索。

什么是 Filter Context

仔细去看 Elastic 的文档可以发现,在 filter 的使用介绍里是这么写的Filter clauses are executed in filter context, meaning that scoring is ignored and clauses are considered for caching.这里不仅措辞严谨的说 filter 条件以 filter context 的方式执行,并做了超链解释。

简而言之,filter context 主要用于查询的过滤 条件,并且不用算分 ,与 bool 的 filter 条件没有严格关联,除了 bool 的 filter 外,bool 中的 must_not, constant_score 查询中的 filter,聚合中的 filter 也都属于。

如何进入 Query Cache

现在我们来看看是查询是怎么进入 Query Cache 的:

  1. 找到匹配文档

    在倒排索引中找到 filter 条件符合的词项,并在所有的文档中检索这个词项。

  2. 建立一个位图 bitset

    建立一个只包含 1 和 0 的位图 bitset,这个 bitset 用于描述所有文档的匹配情况,匹配的文档被设置为 1。ES 实际执行时,使用的是 RoaringBitMap

  3. 迭代 bitset

    一旦为某个查询生成了 bitset, Elasticsearch 就会遍历 bitset 以查找满足所有过滤条件的匹配文档集。执行顺序通常是首先迭代最稀疏的 bitset(因为它排除了最多数量的文档)。

  4. 增加使用计数

    把查询条件和其结果的 bitset 组合作为 key-value 进行缓存,这里利用对查询条件的使用记录来判断是否进缓存。简单来说,如果一个查询在最近的 256 个查询中被多次使用,它将被缓存在内存中。更为详细的保留机制见下一节。

Query Cache 的缓存机制

总体来说,Query Cache 是 Lucene 层面实现的,ES 层面会进行一些策略控制和信息统计。

Query Cache 会维护在相对较大的 segment 上,对于**存储小于 1w 文档数 或者 size 大小小于整体索引 size 3%**的 segment 不会维护 Query Cache(小 segment 本身的查询就比较快,不需要 cache 加速)。
docs_count(segment) < 10000 || segment.size < 3%*index.size

其管理策略类是 lucene 的 UsageTrackingQueryCachingPolicy,符合 LRU 的规则 ,也就是说 Query Cache 中的查询结果长时间不被访问会被优先淘汰。这里判断是否被缓存的方法是shouldCache(Query query)有兴趣的同学可以去研究下

判断是否可以缓存的主要规则如下:

  1. 判断是否为 filter 查询assert query instanceof BoostQuery == false;
  2. 命中永不缓存 shouldNeverCache 条件的淘汰,其中包括:TermQuery、MatchAllDocsQuery、MatchNoDocsQuery、以及子查询为空的 BooleanQuery、DisjunctionMaxQuery
  3. 某些大于特定阈值的查询可以被缓存:
    3.1 大于 2 次:MultiTermQuery、MultiTermQueryConstantScoreWrapper、TermInSetQuery、PointQuery(在 isCostly 方法中定义)
    3.2 大于 5 次:除了上面列出条件的所有 filter 查询

使用和观测 Query Cache

最后,我们来看下怎么去使用和观测 Query Cache。

默认情况下节点的 Query cache 最多缓存 10000 个子查询的结果,或者最多使用堆内存的 10%,都可以通过配置来调整:

复制代码
indices.queries.cache.count  #默认 10000
indices.queries.cache.size   #默认 10%

对 Query Cache 也可以进行人工清理:POST /<index>/_cache/clear?query=true

而 Nodes stats API 和 Index stats API 都提供了 Query Cache 的监控

json 复制代码
"query_cache": {
  "memory_size_in_bytes": 1110305640,//使用的size
  "total_count": 45109997,//历史查询总条数 total=hit+miss
  "hit_count": 1192144,//命中的
  "miss_count": 43917853,//未命中的
  "cache_size": 1309,//当前缓存的条数
  "cache_count": 51509,//历史缓存总条数
  "evictions": 50200//被驱逐的条数
}

使用小建议:

  1. 当 evictions 大量发生时,缓存被大量置换,对高敏感的业务可能会有一定的查询抖动。
  2. 在监控项上添加一个 hit/total 的百分比监控,更加直观。

小结

本文短暂总结了 Filter context 如何形成 Query Cache 并进行维护观测的整体流程。

其中对 Query Cache 和其他缓存有兴趣的同学可以研读张超老师的扒一扒缓存的裤子

Filter context 本身可以省去复杂的算分过程,再加上 Query Cache 的加速优势,建议大家在编写只需要匹配过滤查询语句中优先选择。

作者:金多安,极限科技搜索运维专家,Elastic 认证专家,搜索客社区日报责任编辑。一直从事与搜索运维相关的工作,日常会去挖掘 ES / Lucene 方向的搜索技术原理,保持搜索相关技术发展的关注。

原文:https://infinilabs.cn/blog/2024/elasticsearch-filter-context/

相关推荐
TDengine (老段)3 小时前
TDengine 转化类函数 TO_CHAR 用户手册
大数据·数据库·物联网·时序数据库·tdengine·涛思数据
黄雪超3 小时前
Kafka——多线程开发消费者实例
大数据·分布式·kafka
ManageEngineITSM4 小时前
从混乱到秩序:IT服务管理如何重塑企业运营效率
大数据·人工智能·程序人生·职场和发展·itsm
青云交5 小时前
Java 大视界 -- 基于 Java 的大数据分布式存储在工业互联网数据管理与边缘计算协同中的创新实践(364)
java·大数据·边缘计算·工业互联网·分布式存储·paxos·数据协同
数据爬坡ing6 小时前
软件工程之可行性研究:从理论到实践的全面解析
大数据·流程图·软件工程·可用性测试
晴天彩虹雨7 小时前
统一调度与编排:构建自动化数据驱动平台
大数据·运维·数据仓库·自动化·big data·etl
SelectDB10 小时前
浩瀚深度:从 ClickHouse 到 Doris,支撑单表 13PB、534 万亿行的超大规模数据分析场景
大数据·数据库·apache
SelectDB10 小时前
公开免费!Apache Doris & SelectDB 培训与认证课程正式上线
大数据·数据库·apache
mykyle10 小时前
Elasticsearch-8.17.0 centos7安装
大数据·elasticsearch·jenkins
大视码垛机10 小时前
协作机器人掀起工厂革命:码垛场景如何用数据重塑制造业命脉?
大数据·数据库·人工智能