Elasticsearch 開發運維實戰核心 Tips

本篇內容來自於死磕 Elasticsearch 知識星球的一個做業題目：

Elasticsearch基礎但很是重要的功能還有哪些？

0,有安全比裸奔重要！

1,模板template比mapping重要。

2,顯式映射 strict mapping比隱式mapping重要！

3,別名重要！

4,結合業務選擇甚至自定義分詞器比使用默認重要！

請留言寫下您的思考。

https://t.zsxq.com/MrjQrfM
有20多人蔘與，你們把本身架構、開發、運維實戰中遇到的核心問題和建議都一股腦寫出來了。

我作了擴展梳理，相信對架構、開發、運維都有必定的幫助！

一、集羣規劃層面
注意評估節點的硬盤空間。
結合esrally等第三方工具評估集羣資源的寫入、檢索的吞吐率等指標。
合理配置每一個索引的分片數。
二、數據預處理層面
數據進 Elasticsearch 前要作清洗。
Elasticsearch 擅長的是檢索和不復雜的聚合，其餘活給關係型數據庫或者第三方大數據開源庫如：clickhouse 等。
三、數據建模層面
比起嚴格模式，我更喜歡動態mapping，經過字段名字的前綴映射類型，自從用了這套規則，字段衝突致使的kibana沒法做報表的問題一掃而光啊，真的是不要太香了 。
是否須要打分，是否須要排序、聚合、過濾,若是不須要則(doc_values(dvm、dvd) norm(nvd、nvm))屬性須要關閉等等。
模板 template 比 mapping 更靈活，推薦結合別名多使用動態模板，尤爲數據量每日增量巨大的業務場景。
字段很是明確固定、且將來不會新增字段，考慮mapping建立時設置："dynamic": "strict", 以嚴格控制Mapping氾濫。
結合業務選擇分詞器甚至自定義分詞器。
四、檢索層面
若是須要考慮查詢速度的優化，且排序字段基本固定，則能夠考慮把 indexSort 配上，查詢時會提早中斷。
indexSort能經過預排序有效避免全局掃描，提早中斷查詢，提高查詢性能，對於查詢時按照某列排序（注意不適合相關性排序）的場景很是適合。

查詢根據業務實際考慮，建議最好把 Wildcard 模糊查詢、.等會致使數據量大的查詢作限制。
限制limit +offset，限制query_string等文本查詢的長度，限制term長度，隨時關注慢查詢日誌。es是很強大，可是取決你怎麼使用，你永遠不知道會怎麼調你的接口…
五、硬件資源層面
5.1 磁盤層面
磁盤大小是否充足，壓縮格式使用默認speed Compression? 仍是 Best Compression?
5.2 內存層面
採用默認NIOFS 仍是MMAP，採用MMAP哪些須要預緩存到堆外。
六、集羣管理層面
記得配置延時分片 index.unassigned.node_left.delayed_timeout。
refresh、flush時間根據的實際業務需求調整。
對集羣的性能監控越全面越好, 及時發現慢查詢，儘量全面的根據業務評估使用量, 並能在瓶頸期發現和升級配置。
多節點集羣，合理劃分節點角色，尤爲要分離：主節點、數據節點、協調節點。
七、安全及災備層面
禁用批量刪除索引比默認的隨意刪除重要。
按期或者增量備份比無備份重要(條件容許的狀況下)。
安全問題是必須的，咱們是在日誌清晰的時候作的核心字段加密，elk 整個技術棧都只容許內網訪問，對外的服務接口也是要軟 token 的。
將 ES 提供給業務研發去使用，更多的是須要考慮控制權限，下降門檻，最好是封裝一層網管提供給業務研發使用，而後再去多分享培訓，提升業務側研發對ES的認知。
八、性能優化層面
關閉系統swap。
若是數據量大，儘量使用bulk 批量操做。
（1）寫入層面bulk操做，包含但不限於：bulk API 執行批量寫入、更新、刪除多文檔操做。

（2）檢索層面bulk操做，包含但不限於：Multi Get（mget）， Scorll， MultiSearch。

建議根據業務需求較早的設置開啓慢查詢日誌。
堆內存大小不要超過32GB。
使用script 腳本時，要考慮可能帶來的慢、安全風險（早期版本）等負面影響。
在必定條件下，執行強制合併segment，查詢速度會提高不少。
九、小結
從各個層面列舉了你們實戰中關心且常忽視的Tips，不求全，但求有用。

由於 Tips 涉及內容多，沒有各個點展開。更多細節歡迎留言交流。

你們有實戰中更好的Tips，也歡迎留言交流一下。