ElasticSearch的坑

ElasticSearch使用时，一开始因为数据量比较小，使用都比较随意，也没有在意很多参数，只要实现高可用就可以了，但是随着数据量的不断增大，过程中遇到了一系列的问题

遇到的问题

• 创建索引太慢

Elasticsearch创建分片的速度会随着集群内分片数的增加而变慢。以ES 5.5.2版本、3节点集群为例，在默认配置下，当集群分片数超过1w时，创建index的耗时一般在几十秒甚至以上。

ElasticSearch默认是5个分片，1个副本，相当于每创建一个索引就会产生10个分片。一开始没有问题，后来索引数目达到了4000左右（其中大部分数据量都很小，几十M而已），也就是有超过1万的分片存在，所有节点都需要维护分片和节点的关系，而且为了保证一致性，都是单线程更新，所以效率很低。

• 重启ElasticSearch节点出现大量未分配分片

当一个节点不可达后，为了尽快恢复集群的高可用特性，ElasticSearch会尽快地重新调整分片，没有副本的，也会全量复制分片。当节点恢复后，集群又会再次重新调整分片，达到负载均衡的目的

修改延迟分配时间为5分钟

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

• 关闭一个节点后，集群状态变成red

当时有部分索引的主分片一直没有分配，导致集群处于red状态。当时没有仔细分析原因，只是快速地把那部分索引进行重建处理（从其他数据源导入）。当时还不知道怎么查看未分配的原因，其实可以查看分片详情命令，看到未分配的原因

#分片详情命令，查看未分配的原因
_cat/shards?h=index,shard,prirep,state,unassigned.reason&v

采用的措施有：手工分配，但是系统表示不支持命令allocate

最佳实践

• 索引很小，shard设置为1，replica也是1就可以了
• ElasticSearch推荐的最大JVM堆空间是30~32G
• 一般一个分片不要超过50GB
• 索引稳定后，可以使用forcemerge，提高检索效率
• shrink index API

参考

• How many shards should I have in my Elasticsearch cluster?
• [译]优化ElasticSearch之合理分配索引分片
• Elasticsearch最佳实践之分片使用优化
• Delaying allocation when a node leaves