【ES实战】索引大分片治理

大分片治理思路

大分片的危害

• 过度占用服务器资源，降低集群服务能力
• 加剧JVM的GC，导致查询，写入变慢
• 在进行索引恢复，数据均衡时，更耗时
• 集群故障恢复变慢
• 集群稳定性变差
• ···

如何处理大分片

寻找大分片

执行以下命令，将单个索引大小超过30G的，全部copy出来，从大到小，从易到难进行处理。

 GET _cat/shards?v&s=store:desc

分析大分片的索引

针对不同的场景采用不同的处理方式

1、直接删除索引

• 使用索引的系统已经下线 没有对索引进行写入和查询了。
• 是采用索引模板创建定期创建的索引，且该索引的数据已经过期了。

2、删除索引重建索引

• 索引的数据不重要，但是不确定是否有系统还在使用，可以按原来的配置重建索引。
• 索引的数据不重要或者可以补数据，但是数据量实在太大，无法通过条件删除（delete_by_query）快速处理，可以估算一下单个索引增加主分片数可以解决，修改主分片数据重建索引，进行补数据。并创建数据定期删除计划。

3、删除索引数据

• 索引中只需要一定范围内的数据，其他数据可以进行删除的，进行条件删除，并创建数据定期删除计划。

4、拆分索引

• 不再向索引写入数据，只存在读取的情况，直接将索引拆分成多个索引，利用别名进行查询。
• 索引的数据每天都在增加，按数据量的大小，修改成通过索引模板，按年 月 日的维度进行创建索引使用。并创建索引定期删除计划。

处理方式的具体实现

1、删除索引

DELETE indexName1,indexName

2、删除索引数据

POST twitter/_delete_by_query
{
  "query": { 
    ···
  }
}

在删除索引的数据量达到一定程度，比如超过10%，就可以使用强制合并segment将这些已删除的文档从物理上进行删除了。
强制合并_forcemerge API 使用说明

3、拆分索引

在ES服务化平台进行索引创建和索引模板创建的申请

• 如何查询所有的配置

  GET /indexName
  

• reindex方式

  使用说明

• 索引模板

  使用说明

索引主分片数的计算

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

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

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

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

分片存储大小建议

详细见索引规划