共计 3306 个字符，预计需要花费 9 分钟才能阅读完成。
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 原理
作者：杨松柏
