腾讯万亿级Elasticsearch技术解密( 四 ) _Elasticsearch

文章插图
前面我们介绍了可用性、成本优化的解决方案，最后我们来介绍性能方面的优化实践。以日志、监控为代表的时序场景，对写入性能要求非常高，写入并发可达 1000w/s 。然而我们发现在带主键写入时， ES 性能衰减 1+倍，部分压测场景下， CPU 无法充分利用。以搜索服务为代表的场景，对查询性的要求非常高，要求 20w QPS, 平响 20ms ，而且尽量避免 GC、执行计划不优等造成的查询毛刺。

文章插图
针对上述问题，我们介绍下腾讯在性能方面的优化实践：
写入方面，针对主键去重场景，通过利用索引进行裁剪，加速主键去重的过程，写入性能提升 45% ，具体可参考 PR Lucene-8980 。对于部分压测场景下 CPU 不能充分利用的问题，通过优化 ES 刷新 Translog 时的资源抢占，提升性能提升 20% ，具体可参考 PR ES-45765 /47790 。我们正在尝试通过向量化执行优化写入性能，通过减少分支跳转、指令 Miss ，预期写入性能可提升 1 倍。
查询方面，我们通过优化 Merge 策略，提升查询性能，这部分稍后展开介绍。基于每个 Segment 记录的 min/max 索引，进行查询剪枝，提升查询性能 30% 。通过 CBO 策略，避免查询 Cache 操作导致查询耗时 10+倍的毛刺，具体可参考Lucene-9002 。此外，我们也在尝试通过一些新硬件来优化性能，比如说英特尔的 AEP、Optane、QAT 等。

文章插图
接下来我们展开介绍下 Merge 策略优化部分。ES 原生的 Merge 策略主要关注大小相似性和最大上限，大小相似性是指 Merge 时尽量选择大小相似的 Segments 进行 Merge ，最大上限则考虑尽量把 Segment 拼凑到 5GB 。那么有可能出现某个 Segment 中包含了 1 月整月、3 月 1 号的数据，当用户查询 3 月 1 号某小时的数据时，就必须扫描大量无用数据，性能损耗严重。
我们在 ES 中引入了时序 Merge ，在选择 Segments 进行 Merge 时，重点考虑时间因素，这样时间相近的 Segments 被 Merge 到一起。当我们查询 3 月 1 号的数据时，只需要扫描个别较小的 Segments 就好，其他的 Segments 可以快速裁剪掉。
另外， ES 官方推荐搜索类用户在写入完成之后，进行一次 Force Merge ，用意是把所有 Segments 合并为一个，以提高搜索性能。但这增加了用户的使用成本，且在时序场景下，不利于裁剪，需要扫描全部数据。我们在 ES 中引入了冷数据自动 Merge ，对于非活跃的索引，底层 Segments 会自动 Merge 到接近 5GB ，降低文件数量的同时，方便时序场景裁剪。对于搜索场景，用户可以调大目标 Segment 的大小，使得所有 Segments 最终 Merge 为一个。我们对 Merge 策略的优化，可以使得搜索场景性能提升 1 倍。
前面介绍完毕我们再 ES 内核方面的优化实践，最后我们来简单分享下我们在开源贡献及未来规划方面的思考。
四、未来规划及开源贡献

文章插图
近半年我们向开源社区提交了 10+PR ，涉及到写入、查询、集群管理等各个模块，部分优化是和官方开发同学一起来完成的，前面介绍过程中，已经给出相应的 PR 链接，方便大家参考。我们在公司内部也组建了开源协同的小组，来共建 Elastic 生态。
总体来说，开源的收益利大于弊，我们把相应收益反馈出来，希望更多同学参与到 Elastic 生态的开源贡献中：首先，开源可以降低分支维护成本，随着自研的功能越来越多，维护独立分支的成本越来越高，主要体现在与开源版本同步、快速引入开源新特性方面;其次，开源可以帮助研发同学更深入的把控内核，了解最新技术动态，因为在开源反馈的过程中，会涉及与官方开发人员持续的交互。此外，开源有利于建立大家在社区的技术影响力，获得开源社区的认可。最后 Elastic 生态的快速发展，有利于业务服务、个人技术的发展，希望大家一起参与进来，助力 Elastic 生态持续、快速的发展。