在海量数据的背景下，数据的写入、存储、分析、搜索都会遇到不小的挑战(存储成本大，写入查询慢等)，Elasticsearch 技术栈一直是日志、安全、搜索的首选。随着数据规模的海量增长，降本增效的诉求也越来越高。本次分享将解析腾讯云全新技术栈下的系统架构，基于腾讯云 ES 自研存算分离、读写分离、查询/IO 并行化等一套完整的降本增效解决方案。主要内容包括：

1.  存算分离：自研低频存储架构优化，存储成本节约 50%-80%

2.  读写分离：无共享、自闭环，读写资源隔离的同时提升 1-3 倍写入吞吐

3.  查询/IO 并行化：自研多线程并行查询框架，查询性能提升 3~5 倍

痛点与挑战

1、  存储的痛点：

1.1：副本冗余存储：主分片和副本的数据量是完全一样的，主分片已经存储了一份数据之后，副本再存储一份同样的数据便是冗余。对于云上的产品来讲，云盘会有 3 份备份、ES 通过副本再备份一次，所以相当于有六份存储。

1.2：计算与存储耦合：CPU 和 IO 相互影响。比如如果 IO 打满 CPU 使用率确很低，CPU 资源没有充分利用。CPU 打满 IO 使用率却很低，IO 没有充分利用。

2、  写入的痛点：

2.1：副本冗余写入：当一个写入请求发送到 ES 集群时，主分片会进行分词、解析、写入到 Lucene，主分片写入完成后会转发给副本，这时副本会重复做同样的事情，那如果把主分片 refresh 成的 segment 直接拷贝给副本就可以减少一半的计算量。

2.2：分片长尾效应：ES 的写入会把一批数据分发到所有分片上，当一个分片所在节点出现了问题(GC、网络抖动、负载太高等)，那么会影响整体的写入响应。

3、  查询的痛点：

3.1：Segment 串行处理：默认情况下 ES 在查询的时候是串行执行的，比如有 10 个 Segment，ES 是 1 个 1 个 Segment 的去查询 Lucene，然后打分、合并倒排表，收集文档等，直至最后一个 segment，最后返回给协调节点。

3.2：大数据量查询性能慢：在使用 ES 的过程中应该都会发现，在数据量小的时候一切都还好，当数据量一旦变大，会出现各种问题。

全新技术栈

存算分离+读写分离+查询/IO 并行化是腾讯云 ES 全新一代技术架构，是腾讯云 ES 最近非常重磅的功能，存算分离主要是解决存储成本的痛点，读写分离主要是解决读写资源隔离和写入的痛点，查询/IO 并行化主要是解决查询的痛点。

接下来是解决方案的具体实现,请参考下面的视频

https://www.bilibili.com/video/BV1ic411Z7GS/?spm_id_from=333.337.search-card.all.click&vd_source=28b16f1299ed73f1c2d5e7c6504ccc38

未来规划

1.存算分离

分布式缓存：当数据存储在 COS 上时，我们在本地会缓存一部分经常查询的数据来提高查询的性能。主分片和副本的缓存都在各自的机器上，存在一定的冗余。为了进一步降低存储成本，我们会实现分布式缓存，让主副分片共享一份缓存。

2.读写分离

读写分离还有进一步优化的空间，一方面 Segment 发送太快，merge 可能跟不上会导致写入限流，另一方面写入速度大幅提升导致 IO 打的很满时数据可能会有延迟。未来我们会进一步优化提升 merge、parse document、分词、flush 等层面性能，理论上写入性能可以提升 5-10 倍。

3.聚合下推

ES 的聚合分析性能相对于专门做分析场景的 olap 框架还是有一定的差距的，ES 聚合的实现是通过 docId 查找列存，当匹配的文档非常多，性能就会非常慢。所以我们后面将大力提升聚合分析的性能，将聚合算子下推到 Lucene，优化 Lucene 的文件格式和数据结构，预计聚合性能提升 5~10 倍。

4.查询并行化

fetch 并行化：目前我们只在 query 阶段做了并行化，未来会在 fetch 阶段比较重的查询场景将 fetch 并行化，进一步提升查询的性能。

算法优化：现在 segment、docs 切分还是按照顺序切分，segment 有大有小，这样大的 segment 就会成为长尾，未来会进一步优化切分的算法，优化 Segment 的分配，比如我们切割 Segment 的时候，是不是可以将大的 Segment 配一些小的 Segment，这样组合起来，让每一个线程处理差不多的文档，这样就不会出现长尾的子请求。