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运维操作时对其可能的后果有充分了解。