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運維操做時對其可能的後果有充分了解。