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所示
图 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架构实际》
内部构建segment的性能也在咱们的布局中。
2 分级存储
ES实现降本增效的另外一个方向：分级存储，该解决方案次要是针对数据量大查问少且对查问耗时不太敏感的业务。分级存储，比拟成熟的解决方案有es冷热架构和可搜寻快照。
2-1 冷热架构
冷热架构实用场景：时序型数据或者同一集群中同时存在这两个索引（一个热数据，另外一个冷数据）
es冷热架构架构，该性能曾经在京东云上线有一段时间了，欢送大家依据本人的业务状态进行试用，冷数据节点开启如图2-1所示
图 2-1 冷数据节点开启
倡议如果索引表是按天/小时，这种周期存储的数据，且数据查问具备冷热性，倡议开启冷节点；开启冷节点后你可能会取得如下的收益：
- 开启冷节点后能够升高你的存储老本，因为寄存冷节点的索引咱们能够抉择缩小正本数、冷节点的存储介质更便宜
- 集群能够寄存更多的数据
- 冷数据forcemerge,晋升冷数据的查问性能
- 冷数据从热节点迁徙走之后，缩小热节点的资源占用，从而使热查问更快
冷热架构的核心技术为
shard-allocation-filtering;
冷热架构实现原理：
es的hot节点减少如下配置
node.attr.box_type: hot es的warm节点减少如下配置
node.attr.box_type: warm 热数据索引setting减少如下配置，即可限度shard调配在hot节点
"index.routing.allocation.require.box_type": "hot"当数据查问削弱，咱们通过如下配置，即可使数据由hot节点迁徙到warm节点
"index.routing.allocation.require.box_type": "warm"2-2 可搜寻快照
可搜寻快照是在冷热架构的根底上更进一步的分级存储，在之前咱们将数据快照之后是无奈对快照的数据进行搜寻，如果要对快照的数据进行搜寻，则需将快照数据先restore（restore的过程可能会比拟长）之后能力被搜寻。
在引入可搜寻快照之后，咱们能够间接搜寻快照中的数据，大大降低了没必要的资源应用.
3 其余
3-1 数据压缩
除了从资源的角度进行升高存储老本之外，基于数据本身的个性，应用优良的压缩算法也是一种必不可少的搜寻；针对时序数据facebook开源了一个十分优良的压缩算法zstd，
目前曾经在业界被大量应用，国内的两大云友商曾经在es进行了实现，腾讯云针对zstd的测试后果如表3-1所示;阿里云在TimeStream性能中应用了zstd。
表 3-1 三种压缩算法的比照测试后果
目前在lucene的代码库中也有开源爱好者提交了custom codec providing Zstandard compression/decompression （zstd pr）
3-2 off heap
es单个节点存储数据量受到jvm堆内存的限度，为了使单个节点可能存储更多的数据，因而咱们须要缩小堆内存中的数据。
ES 堆中常驻内存中占据比重最大是 FST，即 tip(terms index) 文件占据的空间，1TB 索引大概占用2GB 或者更多的内存，因而为了节点稳固运行，业界通常认为一个节点 open 的索引不超过5TB。当初，从 ES 7.3版本开始，将 tip 文件批改为通过mmap的形式加载，这使 FST占据的内存从堆内转移到了堆外(即off Heap技术 )由操作系统的 pagecache 治理[6]。
应用esrally官网数据集geonames写入索引1TB,应用 _cat/segments API 查看 segments.memory内存占用量，比照 offheap 后的内存占用成果,如表3-2所示;JVM 内存占用量升高了78%左右
表 3-2 segments.memory内存占用量
4 参考
[1] Indexing Service
[2] ES-Fastloader
[3] 大规模测试新的 Elasticsearch 冷层可搜寻快照
[4] Introducing Elasticsearch searchable snapshots
[5] 7.7 版本中的新改良：显著升高 Elasticsearch 堆内存使用量
[6] Elasticsearch 7.3 的 offheap 原理
作者：杨松柏