Elasticsearch存储空间体系结构及空间异常增长问题分析

1. 基本概念和原理

1.1.document(文档)

数据记录，与关系数据库中的表记录类似。
document由字段构成，每个字段有其特点的type，如integer, long, boolean, ip,  keyword, text等等。

1.2.index(索引)

index是document的集合，与关系数据库中的table类似。
index有静态特性和动态特性；
静态特性在创建时指定，创建后不可修改，如index.number_of_shards（索引主分片的数量）；
动态特性在创建后可以修改，如index.number_of_replicas（副本数）。

1.3.node(节点)

一个node即一个ES实例，一般情况下一台服务器（虚拟机或物理机）部署一个node；如果服务器配置较高（内存128G以上），建议部署2个以上node。

ES实例的内存结构

ES实例消耗的内存分为两块：1、java堆内存，2、lucene使用的OS cache
java堆内存大小不要超过31G

原因：32位操作系统下最多可用4G内存，64位操作系统下无此限制，但64位指针会导致内存极大的浪费，也增加CPU缓存与内存之间的带宽消耗，因此 java通过内存指针压缩技术(compressed oops)实现32位的指针在64位操作系统平台下引用内存；但这种技术有限制，最多只能管理32G内存；如果JVM堆大小超过32G，将自动不使用该技术，直接使用64位的指针来引用内存，从而带来大量的额外消耗。
lucene管理了大量的segement，每个segment对应一个操作系统文件，对segment处理时需要消耗大量OS cache，因此除了JVM堆，还要预留足够的操作系统内存。
总之：

1. 如果服务器内存低于64G，只部署一个node，JVM不超过31G，剩下的给预留给lucene；
2. 如果服务器内存高于128G，可以考虑每64G部署一个node，每个node的JVM不超过31G；
3. 如果一台服务器部署2个以上的node，确保设置cluster.routing.allocation.same_shard.host：true，这将阻止同一个分片的副本分布在同一个服务器上的多个节点上，从而确保多副本的高可用。

1.4.shard(分片)

一个index分为多个shard，以便将数据分布到不同的node，提高index容量和并行读写能力；
shard分为primary（主分片）和replica（副本分片），数据写入主分片，自动向副本分片同步；
副本作用：数据容灾、提升读性能（类似mysql读写分离）；
下图中一个index分布在3个node，包含10个shard（5个主分片，5个副本分片），同一个shard的主分片与副本分片分布在不同的node。

document分发到shard的规则
shard = hash(routing) % number_of_primary_shards
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

1.5.segment(段)

segment生成过程
一个document写入到ES后，先写入buffer，默认每秒将buffer中的记录刷新到segment；
数据刷新到segment后，数据才可以被读取到，因此ES是准实时的，默认最大延迟1秒；
事务日志（translog）确保数据尽可能不丢失，默认5秒刷新一次translog，因此ES宕机最多可能丢5秒数据；

segment合并
每个segment是一个倒排索引，每个请求需要遍历所有segment；
一个shard内每秒生成一个segment，segment数量太多，搜索性能会很差，因此需要将segment合并。
merge进程会在后台选择一些小体积的segments，然后将其合并成一个更大的segment。

2.阿里云ES空间使用率异常增长分析

2.1.现象

三台ES组成集群：172.16.92.222/223/224，磁盘空间初始各100G，5月11日20:00磁盘各扩容至200G。
222磁盘空间使用率从5月10日9:30开始增长，直到磁盘扩容才下降；
224磁盘空间使用率从5月10日9:30开始增长，期间大幅增长并恢复初始值，扩容后大幅下降；
223磁盘空间使用率无波动，扩容后大幅下降

数据使用大小，从183G增长到196G，最终回落到178G

2.2.分析

5月11日18:15，segment数量出现明显波动，最终大幅下降，说明后台在进行深度segment merge；
期间磁盘空间大幅增加，224完成segment merge后空间正常回收，223磁盘空间卡在80%。

数量增长幅度正常，说明空间增长不是因为数据量增加导致

 诊断报告显示出现了磁盘空间使用85%的情况，但上述磁盘空间趋势图中并未体现，可能是监控未捕捉到申请磁盘空间的时间点。

 2.3.总结

深度segment merge过程中，临时需要大量额外的磁盘空间；
222节点merge过程中，磁盘空间增长到85%，无法继续申请空间，导致merge过程挂起，直到扩容后才申请到新的空间，最终顺利merge，并释放空间；
这种场景的解决方案：

• 适当增加磁盘空间，使得资源满足segment merge的需求；
• 如无法增加磁盘空间，可适当增加low disk watermark [85%]，也可达到目的。