【ES实战】如何规划索引

如何去规划一个索引

规划索引包含如何调整索引的主分片数，副本分片数和分片存储大小，以及如何根据数据量的变化进行相关的调整。

索引规划的影响因素包含不仅限于

• 索引存储占用大小
• 索引的TPS
• 索引的QPS
• 索引的总数据量
• 每条记录的平均大小
• 是否是实时查询
• 日增数据量
• 数据生命周期
• 索引的字段数

新建索引

有资料表明集群索引应该满足以下条件

• 单个分片的大小不要超过50GB

• 单个数据节点实例的数据量不要超过5TB，1TB索引数据的FST需要占2GB的内存，5TB就需要占10GB的内存（理解为JVM的配置为30GB），剩余20GB供其他使用，用来控制JVM的GC时间。

为什么JVM的启动和最大内存是30GB，关键字 jvm的指针压缩

FST是什么？关键字 Lucene的字典

在实际使用中发现

• 单个分片大小超过10GB 查询的延迟会出现明显的增大，甚至极可能到达秒级，对延迟时间要求低的，尽量保证单分片在10GB以下。
• 单个分片超过20GB之后，查询会出现明显的延迟效果。并且在索引恢复和迁移的时候，耗时增加了。
• 在20GB-50GB之间的分片数超过一定比例的时候，JVM的GC次数明显增多和耗时变长，会影响整个集群的写入和查询效果。
• 分片超过50GB，会明显加剧GC

一般情况下，单个索引的主分片大小一般以20GB为限。对业务调整频繁的，预估出一年的数据增量。业务调整不频繁的，评估出2年内的数据增量。那么主分片的个数 $n=\frac{(初始化数据大小+一年（或者2年内）的数据增量大小)(GB)\ast 数据膨胀比}{20}$​。分片副本数在没有特殊情况下，可以直接为1。对于一些查询要求高的场景，可以实现增加副本分片数，来提高查询速度。

数据膨胀比指的是源数据在存入ES时，会被以下因素影响，导致存储放大

• 是否开启_all
• 是否_source
• 不同的分词器，效果不一样
• 字段数
• …

数据膨比不是固定的值，可以通过部分数据的抽样插入临时的ES索引计算出来。一般不需要进行全文检索，可以不开_all，只对少部分的字段进行分词和建索引，加上压缩的特性，膨胀比接近1。

当数据量过大导致单个索引的主分片数过多的话，可以考虑使用以下方式进行处理。

• 通过Index templates按天，月，年的维度创建索引结合别名来使用。索引模板的使用
• 通过 rollover IndexAPI实现索引的滚动创建，结合别名使用。索引翻滚

如何判断一个索引的分片数过多？

理想情况下，单个索引的主分片数可以按照数据节点个数的1.5~3倍配置。当然，作者也试过在3个数据节点的情况下，单个索引的主分片是50的场景。当一个数据节点上相同索引的分片数过多的时候，在大量写入和查询的时候，会导致I/O过高。目前，单个数据节点的默认最大分片数是1000。

调整索引

每个分片本质上就是一个Lucene索引, 因此会消耗相应的文件句柄, 内存和CPU资源，每个索引的分片个数应该在一个相对合理的值。

整个索引的调整

• reindex

  可以通过reindex api实现重建索引，在重建索引的时候，可以修改分片的配置。如何使用reindex

• snapshot+restore

  可以对源索引进行创建快照，在使用快照恢复的时候，进行索引分片配置的修改。如何使用snapshot+restore

主分片的调整

• split Index

  在6.X版本上新增了主分片分裂的api，但是需要在创建索引的时候配置number_of_routing_shards，通过这个参数进行主分片个数的分裂，分配的个数是number_of_routing_shards的因子。在7.0版之后，会去掉这个参数，使用上有变化。如何使用split Index

• shrink Index

  在数据过期删除，新增数据量降低的场景下，导致索引的存储不是很大，分片数过多的时候，可以通过这个api，减少主分片的个数。如何使用shrink Index

副本分片数的调整

正常1就可以了。如果副本数为0，就代表数据可以丢失，且在集群宕机时可以立刻删除重建该索引来快速恢复集群。副本最大个数=数据节点数-1。

PUT /indexName/_settings
{
 "index" : {
     "number_of_replicas" : 2
 }
}

删除索引和过期数据

在创建索引的时候，就需要考虑，这个索引以及数据的生命周期。定期的清理过期索引和数据，是集群长久健康运行的必要条件。