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
