ElasticSearch经验小结 (Based on 5.x)

1. ElasticSearch (ES)
   1.1 存储

• 分片 shard
  官方：搜索场景下一个分片大小建议不要超过30G
  索引不能动态调整shard，ES很是鼓励reindex，所以索引不建议太大，通常手动按时间划分。对于更新型数据可能不太友好。

• 内存
  官方：堆内建议不要超过32G，不然没法利用内存指针压缩优化，64-bit的地址表示会长一倍，被认为会比较影响性能
  官方&七牛：1G内存约可服务20~30G左右的索引数据。

• 磁盘
  对性能比较重视的索引请尽可能存在SSD，Lucene很是耗磁盘

• 分词器
  字分词器会性能较低(尤为是match类查询)，可是支持查询灵活
  词分词器会有可能难以适应业务查询需求变化和新词查询，可是性能和空间占用都较有优点
  通常来讲分词器仍是会妥协于业务需求，除非reindex代价不高。

1.2 写入

• transport优于http

• 控制bulk大小和频率
  官方：建议bulk的大小为单节点4m/s左右一批，但其实要考虑实际负载和对读的影响
  注意观察bulk thread_pool指标，若是bulk请求过多（好比异步写过快），则会引发EsRejectedException拒绝写入。在java client中须要本身去遍历response去确认是否成功，而不是依靠onFailure回调。

• 控制refresh_interval去避免过于频繁的merge触发和提升写性能
  如实时索引要求不是过高能够适当把refresh_interval从默认的1s调整成10s或30s。

• reindex或迁移等在5.x后尽可能用官方的内部命令工具会比较快
• 刷数时replica=0，刷完再恢复
• mapping侧的写入优化主要侧重于减小索引分析（analyz优化等）、减小索引写入（_source exclude等）
• Other: 还有一些比较极端的方法去提升写性能，好比禁止index warmup、提升index并行度等。须要根据实际业务场景去肯定这些优化的风险。
  1.3 读取
• 善用filter作缓存且防止数据打分排序 bool-filter
• 能用term代替match/match_phrase的尽可能用term

• 时间戳不须要毫秒级的尽可能使用秒级

• 尽可能不要从ES scroll太多数据，若有需求尽可能只scroll id。
• range查询不要用字符串，尽可能用数值
• script真的很慢

• cardinality太多的维度慎作agg，hyperloglog算法不精确

• 一致性
  ES支持读写时主从一致性配置，通常状况下都是异步写replica的弱一致性（最终一致性）以提升吞吐率和写性能。此时需注意不一样副本间的一致性问题，能够利用 _preference 参数作哈希来解决。

1.4 GC优化

• JDK 1.7+ && CMS优化:
  -Xmx30g –Xms30g -Xmn512m -Xss256k
  -XX:MaxPermSize=256m -XX:SurvivorRatio=2
  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
  -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
  -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
  -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

GC状况最后依然还需根据实际本身的状况进行调整。
JDK 1.8.100+ 的版本G1GC才能用，以前版本的G1GC都会致使Lucene数据丢失。

1.5 监控
方案：ELK、Grafana + 时序数据库(Opentsdb)/监控系统(OpenFalcon)等
指标：JVM (GC、Heap、OffHeap等)、query数目与耗时、fetch数目与耗时、flush、refresh、merge、slow query、集群基础监控。

另：记得对ElasticSearch作自动拉起的守护进程，默认5min内拉起的话不会触发分片reroute。

1.6 Linux

• 关闭大页 Tuning transparent huge pages (THP) off
• 禁止swap Set vm.swappiness = 0
• 关闭NUMA vm.zone_reclaim_mode = 0

以上操做系统配置基本适用于持续服务的高读性能数据存储集群，包括但不只限于HBase、ES等。
1.7 部署

• master节点：尽可能与data node 分开，至少三台
• client 节点：对于大集群建议划分，将一些须要聚合的请求利用client node去作导流，即便挂了也方便恢复。
• tribe节点：跨集群链接性节点，不与data node合部。

1.8 备份与容灾

• Quorum的Master选举机制
• 索引备份机制基于replica，线上索引至少设为1，也有利于作读负载均衡
• 集群备份能够利用 ES snapshot/restore机制去作，用户视角可作到增量备份，能够选择备份到HDFS（默认3副本，注意磁盘空间）
• ES很是鼓励reindex，所以有些操做（好比分片强制assign）的后果会比较不care数据（有可能会清空）。所以请注意作ES运维操做时对其可能的后果有充分了解。