本文整理自：袋鼠雲技術薈 | 某物流客戶Elasticsearch集羣性能優化案例前端
數棧是雲原生—站式數據中臺PaaS，咱們在github和gitee上有一個有趣的開源項目：FlinkX，FlinkX是一個基於Flink的批流統一的數據同步工具，既能夠採集靜態的數據，也能夠採集實時變化的數據，是全域、異構、批流一體的數據同步引擎。你們喜歡的話請給咱們點個star！star！star！git
github開源項目：https://github.com/DTStack/flinkxgithub
gitee開源項目：https://gitee.com/dtstack_dev_0/flinkx性能優化
1、客戶背景
客戶使用ES來進行數據存儲、快速查詢業務訂單記錄，可是常常會出現業務高峯期ES集羣的cpu負載、內存使用均較高，查詢延遲大，致使前端業務訪問出現大量超時的狀況，極大影響其客戶使用體驗。架構
部分監控以下圖：運維
一、 集羣架構以下：工具
集羣節點配置：8數據節點（16C64G）；3主節點（8C32G）性能
二、 集羣存在問題分析大數據
- 業務層面
與客戶業務人員溝通，業務處理中有幾個聚合查詢會佔用較多的內存，且這類查詢對準確性要求較高，需精確統計全部匹配結果。優化
- 架構層面
存在4-5T的單個較大索引，該索引字段多達2000+，分片大小廣泛60G+，最高達到130G+，是制約查詢性能的一個較大瓶頸，另外集羣在業務高峯期還會出現常常的fullgc，這是出現訪問超時的直接緣由。
如圖：
2、Elasticsearch集羣優化
與客戶開發人員溝通了解集羣在業務上存在的問題，結合咱們在ES這塊的服務經驗，從語句參數、索引、架構等多個角度給客戶提出調優建議。
一、語句、參數調優
客戶已提供4個慢查詢語句，語句中聚合查詢使用"execution_hint": "map"，該執行策略會把命中的記錄都撈回內存中，一旦查詢結果較大就會佔用大量內存。建議使用terminator_after，此方法能夠控制查詢結果數量，另外將不參與聚合、排序的字段設置爲doc_values:false, 節省磁盤空間提高索引速度。
二、 集羣架構優化：
在原有集羣基礎上添加協調節點或者擴容數據節點：
- 添加協調節點：優勢是能夠減輕數據節點壓力，變動較爲容易，緩解fullgc頻繁出現的問題；
- 擴容數據節點：優勢是能夠減輕當前數據節點壓力，也能夠減少分片大小；可是增長索引分片須要從新建立索引，從新導入數據，且當前節點存儲壓力不大，同時增長數據節點對存儲空間有必定的浪費。
結合客戶業務特性，咱們推薦客戶使用添加協調節點的方式對集羣架構進行優化。
三、 集羣索引優化：
能夠對集羣進行索引拆分和使用別名兩方面進行優化調整。
- 拆分索引：對索引字段進行拆分並確認大小，能夠解決當前索引分片過大的問題，提高查詢性能。
- 使用別名：根據日期按期建立新的索引（建議按月建立索引），根據業務對統一查詢的索引建立統一別名，該方法能夠完全解決當前索引分片過大問題，優化查詢性能。
3、集羣優化效果
集羣優化後總體性能有明顯提高：
a. ES集羣負載、內存較爲平穩，業務高峯期不會有較大波動；
b. ES集羣FullGC出現頻次極大下降，下降對業務的影響；
c. ES聚合查詢延遲減少，業務數據查詢性能提高，速度達到百毫秒級別
4、寫在最後
袋鼠雲經過數據集成優化、任務調度優化、代碼優化、全鏈路數據質量保障、故障緊急處理、大數據平臺運維，爲客戶提供大數據系統運維保障服務。