ElasticSearch优化方式

1. ES每一个分片是一个Lucence实例，因此分片数量不该过多。可是分片数一旦设置好就不能修改，若是设置过少等数据量上去后不能扩容，这时能够考虑增长索引库的方式来增长分片数。好比一个索引库设置20个分片，增长一个索引库就等于增长了20个分片。应用程序如何知道增长了索引库呢？这时须要用到ES的别名功能，将一个别名映射到多个实际的索引库，而应用程序使用别名便可，别名映射的实际索引库能够动态修改而对应用程序透明。
2. 能够从这几个方面来观测ES的性能指标：
   • cpu消耗
   • 内存消耗
   • 磁盘io和网络io
   • jvm的gc状况
   • es的各个线程池和队列的负荷
3. Elasticsearch 须要使用大量的堆内存, 而 Lucene 则须要消耗大量非堆内存 (off-heap)。推荐给 ES 设置本机内存的一半, 如32G 内存的机器上, 设置 -Xmx16g -Xms16g ，剩下的内存给 Lucene 。
4. 若是不须要对分词字符串作聚合计算（例如，不须要 fielddata ）能够考虑下降堆内存。堆内存越小，Elasticsearch（更快的 GC）和 Lucene（更多的内存用于缓存）的性能越好。
5. 针对io高的优化方式：
   • 尽可能保证一个分片只落在一个硬盘上面，这样不用跨磁盘读写
   • 检查mapping，es默认会将全部字段写入_all字段，若是实际业务不须要能够关闭，减小存储空间
   • 一样的，若是不须要存储原始数据，能够关闭_source，或者只设置某些必要字段的store属性 store:true
   • 查询时只返回必要的数据
   • 采用_doc排序能够依赖lucence内部id排序，提升排序速度
6. 注意防止脑裂：

   • discovery.zen.minimum_master_nodes > = ( master 候选节点个数 / 2) + 1

7. 若是有节点挂掉，不要急于恢复集群致使分片数据的大量复制和传输，应尽可能等节点本身恢复：

   • gateway.recover_after_nodes: 8 # 等待集群至少存在 8 个节点 后才能进行数据恢复
     gateway.expected_nodes: 10
     gateway.recover_after_time: 5m # 等待 5 分钟，或者 10 个节点上线后，才进行数据恢复，这取决于哪一个条件先达到

8. 升级的过程由于须要关闭节点再重启，这时也要防止es自动恢复的操做：
   • 可能的话，中止索引新的数据
   • 禁止分片分配，这样es不会自动平衡缺失的分片：

     • PUT /_cluster/settings
           {
               "transient" : {
                   "cluster.routing.allocation.enable" : "none"
               }
           }

   • 这时关闭节点，升级好后再加入集群，而后重启分片分配便可：
     • "cluster.routing.allocation.enable" : "all"
9. 能够考虑在ES前面加一个kafka之类的消息缓存，防止数据量的瞬间暴增对es形成压力。