怎样开网站,公共服务平台,相关文章wordpress,家具营销策划方案大家都知道在对索引执行查询的时候#xff0c;需要在所有的分片上执行查询#xff0c;因为无法知道被查询的关键词位于哪个分片#xff0c;对于全文查询来说诚然如此#xff0c;然而对于时序型的索引#xff0c;当你从 my_index-* 中执行 now-3d 的范围查询时#xff0c;… 大家都知道在对索引执行查询的时候需要在所有的分片上执行查询因为无法知道被查询的关键词位于哪个分片对于全文查询来说诚然如此然而对于时序型的索引当你从 my_index-* 中执行 now-3d 的范围查询时可能很多分片上都不存在被查询的数据范围因此 es 从 v5.6 开始引入了 pre-filter 机制对于 Date 类型的 Range 查询在对分片执行搜索之前先检查一下分片是否包括被查询的数据范围如果查询的范围与分片持有的数据没有交集就跳过该分片。分布式搜索过程原先由两个阶段执行查询阶段和取回阶段在引入了 pre-filter 之后分布式搜索过程变成了三个阶段预过滤阶段(pre-filter)、查询阶段和取回阶段。pre-filter 在查询阶段之前执行。协调节点收到客户端的查询请求后向本次搜索涉及到的全部分片发送RPC 请求indices:data/read/search[can_match]这次 RPC 请求以 shard 为单位并行发送没有并发限制。待查询的 shard 有多少个就并发发送多少个 RPC。然后等待全部 RPC 返回响应。tips此时发送的 RPC 请求没有超时限制。事实上_search 请求的 timeout参数仅在整个分布式搜索的 query 阶段进行检查并且不包括 PRC 层面他只在数据节点收到协调节点发来的 RPC 后开始计时检查 query 过程是否超时。fetch 阶段的 RPC以及数据节点对 fetch 请求的处理均没有超时检查。节点收到请求后判断请求的范围和待查询的分片是否存在交集返回是或否然后协调节点跳过不存在交集的分片向其他分片发送下一阶段(查询阶段)的请求。本次查询跳过了多少分片可以通过查询结果中的 skipped 字段看到如_shards:{total: 130,successful: 130,skipped: 129,failed: 0}同时也来看一下手册对 skipped 字段的解释skipped(Integer) Number of shards that skipped the request because a lightweight check helped realize that no documents could possibly match on this shard. This typically happens when a search request includes a range filter and the shard only has values that fall outside of that range.什么情况下会执行 pre-filterpre-filter 并不会在所有查询过程中执行在 v7.4中需要同时满足以下条件才会执行 pre-filter 待查询的分片数大于 128(pre_filter_shard_size指定)聚合请求不要求访问所有 doc。即非 Global Aggregation 或 min_doc_count 不为0另外非 Date 类型的数值查询虽然也会走 pre-filter流程但内部不会去判断范围虽然协调节点也会发送 can_match 的 RPC但数据节点的响应会在 MappedFieldType#isFieldWithinQuery 中直接返回相交所以没有分片会被 skip未来这方面可能会有扩展。pre-filter 实现原理数据节点判断某个 Range 查询与分片是否存在交集依赖于 Lucene 的一个重要特性PointValues 。在早期的版本中数值类型在 Lucene 中被转换成字符串存入倒排索引但是由于范围查询效率比较低从 Lucene 6.0开始对于数值类型使用 BKD-Tree 来建立索引内部实现为 PointValues。PointValues原本用于地理位置场景但它在多维、一维数值查询上的表现也很出色因此原先的数值字段(IntFieldLongFieldFloatFieldDoubleField)被替换为(IntPointLongPointFloatPointDoublePoint)关于 BKD-Tree 的性质请参阅其他资料暂且只需要知道 Lucene为每个字段单独建立索引对于数值字段生成 BKD-Tree一个新的 segment 生成时会产生一个新的.dim和.dii文件。最重要的可以获取到这个 segment 中数值字段的最大值和最小值为 pre-filter 提供了基础。当 segment 被 reader 打开的时候Lucene 内部的 BKDReader 会将最大值和最小值读取出来保存到类成员变量因此每个 segment 中每个数值字段的最大最小值都是常驻 JVM 内存的。既然每个 segment 记录了数值字段的取值范围获取shard 级别的范围就轻而易举PointValues.getMaxPackedValue()PointValues.getMinPackedValue(),函数遍历全部的 segment 分别计算最大值和最小值然后根据查询条件判断是否存在交集在 DateFieldMapper.DateFieldType#isFieldWithinQuery 函数中既然数值类型都可以获取分片级别的范围为什么 pre-filter 只在 Date 类型的Range 查询里实现了而其他的数值类型的 Range 查询不会走 pre-filter 流程原因也非常简单只有 Date 类型的数值确定是递增的其他数值类型未必。对于非递增的数值字段其数据会散布到 my_index-* 的每个分片上因此 pre-filter 也就没有必要了。如果你有另外一个递增的数值字段目前也没有配置的方式来使用 pre-filter。题外话BKD-Tree 的每个节点都记录了节点自己的maxPackedValue、minPackedValueLucenene 内部查询的也会按照 segment file 级别跳过现在我们忘掉 es讨论数值类型查询在 Lucene 内部的实现。HBase 的写入模型和 Lucene 类似先写内存然后刷盘生成 HFileHFile 合并成大文件。由于 HBase 使用时间戳作为数据版本号因此每个 HFile 都记录了时间范围。因此查询的时候如果指定时间范围就可以过滤掉大量的 HFile 不用查询。这么优秀的操作在 Lucene 中也必不可少。在一个 Lucene 索引中可能有很多 segmentLucene遍历所有的 segment 进行处理在对每个 segment 的 weight.bulkScorer过程中BKDReader.intersect函数根据相交情况决定收集符合条件的 docid如果查询条件和 segment 没有交集就什么都不做。因此当对数值类型查询的时候不在范围的 segment 会直接跳过Lucene 内部称为CELL_OUTSIDE_QUERY但是段合并的时候目前还不会考虑按时间临近的方式进行合并因此借鉴 HBase 的思想按照时间临近的段进行合并有助于降低数值类型的范围查询耗时。思考既然 Lucene 对数值类型有 segment 级别的skipElasticsearch 实现的分片层面的 pre-filter 还有必要存在吗他可以让搜索延迟更低么我们实际测试来说话。过程如下生产集群有 filebeat-* 索引数据为 nginx 日志大约8T有180个shard11227个 segment分布在3个节点。step1我们对 date 字段执行一个不会命中的查询让他走 pre-filter 流程POST filebeat-7.4.2-*/_search{size:0,query: {range: {timestamp: {gte: 2021-01-01,lte:2022-01-01 } } }}返回结果摘要如下整个过程执行了31ms{ took : 31, timed_out : false, _shards : { total : 180, successful : 180, skipped : 179, failed : 0}, hits : { total : { value : 0, relation : eq}}step2现在加上 ?pre_filter_shard_size1000 参数重新查询其他条件不变让查询过程不走 pre-filter返回结果如下整个过程执行了31ms可见没什么区别{ took : 23, timed_out : false, _shards : { total : 180, successful : 180, skipped : 0, failed : 0}, hits : { total : { value : 0, relation : eq}}}step3最后我们对 long 字段执行 range 查询这样也不走 pre-filter 流程POST filebeat-7.4.2-*/_search?size0{query: {range: {nginx.bytes.body_sent: {gte: -2,lte:-1 } } }}这次查询执行了50ms还是在一个数据级。{ took : 50, timed_out : false, _shards : { total : 180, successful : 180, skipped : 0, failed : 0}, hits : { total : { value : 0, relation : eq}}}因此 pre-filter并不会降低查询延迟在和官方聊过之后他们的想法是 pre-filter 最主要的作用不是降低查询延迟而是 pre-filter 阶段可以不占用search theadpool减少了这个线程池的占用情况。个人感觉这个收益并不大。不过未来会在这个阶段做更多的查询优化 例如7.6中放出的 #49092,#48681特别感谢陆徐刚蚂蚁基于Elasticsearch 7.4 7.6参考https://github.com/elastic/elasticsearch/pull/25658https://www.amazingkoala.com.cn/Lucene/Search/2020/0427/135.htmlhttps://lucene.apache.org/core/6_2_1/core/org/apache/lucene/index/PointValues.htmlhttp://www.nosqlnotes.com/technotes/searchengine/lucene-invertedindex-3/https://www.jianshu.com/p/39eb0d66d082https://cloud.tencent.com/developer/article/1366835https://www.elastic.co/guide/en/elasticsearch/reference/current/release-notes-7.6.0.html#
