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

我们当前的限流方案，能够大幅提升在异常查询、压力过载、单节点故障、网络分区等场景下， ES 服务的稳定性问题。但还有少量场景没有覆盖完全，所以我们目前也在引入混沌测试，依赖混沌测试来覆盖更多异常场景。

文章插图
前面我们介绍了高可用解决方案，下面我们来介绍成本方面的优化实践。成本方面的挑战，主要体现在以日志、监控为代表的时序场景对机器资源的消耗，我们对线上典型的日志、时序业务进行分析，总体来看，硬盘、内存、计算资源的成本比例接近 8:4:1 ，硬盘、内存是主要矛盾，其次是计算成本。
而对时序类场景进行分析，可以发现时序数据有很明显的访问特性。一是冷热特性，时序数据访问具有近多远少的特点，最近 7 天数据的访问量占比可达到 95%以上;历史数据访问较少，且通常都是访问统计类信息。

文章插图
基于这些瓶颈分析和数据访问特性，我们来介绍成本优化的解决方案。
硬盘成本方面，由于数据具有明显的冷热特性，首先我们采用冷热分离架构，使用混合存储的方案来平衡成本、性能;其次，既然对历史数据通常都是访问统计信息，那么以通过预计算来换取存储和性能，后面会展开介绍;如果历史数据完全不使用，也可以备份到更廉价的存储系统;其他一些优化方式包含存储裁剪、生命周期管理等。
内存成本方面，很多用户在使用大存储机型时会发现，存储资源才用了百分之二十，内存已经不足。其实基于时序数据的访问特性，我们可以利用 Cache 进行优化，后面会展开介绍。

文章插图
我们展开介绍下 Rollup 部分。官方从 ES 6.x 开始推出 Rollup ，实际上腾讯在 5.x 已经开始这部分的实践。Rollup 类似于大数据场景下的 Cube、物化视图，它的核心思想是通过预计算提前生成统计信息，释放掉原始粒度数据，从而降低存储成本、提高查询性能，通常会有数据级的收益。这里举个简单的例子，比如在机器监控场景下，原始粒度的监控数据是 10 秒级的，而一个月之前的监控数据，一般只需要查看小时粒度，这即是一个 Rollup 应用场景。
在大数据领域，传统的方案是依赖外部离线计算系统，周期性的读取全量数据进行计算，这种方式计算开销、维护成本高。谷歌的广告指标系统 Mesa 采用持续生成方案，数据写入时系统给每个 Rollup 产生一份输入数据，并对数据进行排序，底层在 Compact/Merge 过程中通过多路归并完成 Rollup ，这种方式的计算、维护成本相对较低。ES 从 6.x 开始支持数据排序，我们通过流式查询进行多路归并生成 Rollup ，最终计算开销小于全量数据写入时 CPU 开销的 10% ，内存使用小于 10MB 。我们已反馈内核优化至开源社区，解决开源 Rollup 的计算、内存瓶颈，具体可参考 PR ES-48399 。

文章插图
接下来，我们展开介绍内存优化部分。前面提到很多用户在使用大存储机型时，内存优先成为瓶颈、硬盘不能充分利用的问题，主要瓶颈在于索引占用大量内存。但是我们知道时序类场景对历史数据访问很少，部分场景下某些字段基本不使用，所我们可以通过引入 Cache 来提高内存利用效率。
在内存优化方面，业界的方案是什么样的呢?ES 社区从 7.x 后支持索引放于堆外，和 DocValue 一样按需加载。但这种方式不好的地方在于索引和数据的重要性完全不同，一个大查询很容易导致索引被淘汰，后续查询性能倍数级的衰减。Hbase 通过缓存 Cache 缓存索引、数据块，提升热数据访问性能，并且从 HBase 2.0 开始，重点介绍其 Off Heap 技术，重点在于堆外内存的访问性能可接近堆内。我们基于社区经验进行迭代，在 ES 中引入 LFU Cache 以提高内存的利用效率，把 Cache 放置在堆外以降低堆内存压力，同时通过 Weak Reference、减少堆内外拷贝等技术降低损耗。最终效果是内存利用率提升 80% ，可以充分利用大存储机型，查询性能损耗不超过 2% ， GC 开销降低 30% 。