京东云开发者｜ElasticSearch降本增效常见的方法 _生活百科

Elasticsearch在db_ranking 的排名又（双叒叕）上升了一位,如图1-1所示;由此可见es在存储领域已经蔚然成风且占有非常重要的地位。
随着Elasticsearch越来越受欢迎，企业花费在ES建设上的成本自然也不少。那如何减少ES的成本呢？今天我们就特地来聊聊ES降本增效的常见方法：

弹性伸缩
分级存储
其他：（1）数据压缩（2）off heap

图 1-1 Elasticsearch db_ranking
1 弹性伸缩所谓弹性伸缩翻译成大白话就是随时快速瘦身与增肥，并且是头痛医头，按需动态调整资源。当计算能力不足的时候我们可以快速扩充出计算资源，业届比较有代表性的两个ES相关产品阿里云Indexing Service 和滴滴的ES-Fastloader；
当存储资源不足时，能够快速扩容磁盘，业届比较代表性es产品:阿里云的ES日志增强版。
1-1 计算存储分离ES使用计算存储分离架构之后，解决了资源预留而造成资源浪费的问题。在早期大家认为的计算存储分离的实现方式为：使用云盘代替本地盘，这种实现方式可以提高数据的可靠性、可以快速弹扩磁盘资源和计算资源，但是es自身弹性需求是无法解决，即秒级shard搬迁和replica扩容。
那么如何解决es自身的弹性呢？本文该部分将给出答案。
共享存储版ES本文该部分将介绍我们京东云-中间件搜索团队，研发的共享存储版本ES；计算存储分离架构如图1-2所示
【京东云开发者｜ElasticSearch降本增效常见的方法】

图 1-2 计算存储分离架构(共享)
如图1-2所示，我们只存储一份数据，primary shard负责读写，replica只负责读；当我们需要扩容replica的时候无需进行数据搬迁,直接跳过原生es的peer recover两阶段，秒级完成replica的弹扩。
当主分片发生relocating时,可以直接跳过原生es的peer recover第一阶段(该阶段最为耗时)，同时也不需要原生es的第二阶段发送translog 。
共享版本的计算存储分离ES，相对于原生的ES和普通版本的计算存储分离，具有如下突出的优势：

数据只保存一份，存储成本倍数级降低
存储容量按需自动拓展，几乎无空间浪费
按实际用量计费，无需容量规划

性能测试

数据集为esrally提供的http_logs
共享版ES7.10.2: 3个data节点(16C64GB)
原生ES7.10.2: 3个data节点(16C64GB)

表 1-1 副本性能测试对比
我们的初步性能测试结果如表1-1所示；副本数越多，共享版本的es越具有优势;
从表1-1所示我们可以看出性能似乎提升的不是特别理想，目前我们正从两个方面进行优化提升：

底层依赖的云海存储，目前正在有计划地进行着性能提升
源码侧，我们也在正在优化ing

在研发es计算存储分离的过程中，我们攻克了很多的问题,后续将输出更加详细的文章进行介绍，比如：主写副只读的具体实现，replica的访问近实时问题，ES的主分片切换脏写问题等等。目前共享版本的ES正在内部进行公测，欢迎在云搜平台进行试用。
1-2 外部构建Segment对于有大量写入的场景，通常不会持续的高流量写入，而只有1-2个小时写入流量洪峰；在写入过程中最耗费时间的过程并不是写磁盘而是构建segment,既然构建segment如此耗时，那么我们是否可以将该部分功能单独出来，形成一个可快速扩展的资源（避免去直接改动es源码而引入其他问题）。
目前业界已经有比较好的案例如阿里云的Indexing Service 和滴滴开源的 ES-Fastloader 外部构建Segment，相对于共享存储版的es实现起来更简单；它的核心解决方案使用了spark或者map reduce这种批处理引擎进行批量计算处理，然后将构建好的segment搬运到对应的索引shard即可。它的详细实现,我这里就不做搬运工了，大家感兴趣可以参考滴滴发布的文章《滴滴离线索引快速构建FastIndex架构实践》