1、集群規劃層面

• 注意評估節點的硬盤空間。
• 結合esrally等第三方工具評估集群資源的寫入、檢索的吞吐率等指標。
• 合理配置每個索引的分片數。

2、數據預處理層面

• 數據進 Elasticsearch 前要做清洗。
• Elasticsearch 擅長的是檢索和不復雜的聚合，其他活給關系型數據庫或者第三方大數據開源庫如：clickhouse 等。

3、數據建模層面

• 比起嚴格模式，我更喜歡動態mapping，通過字段名字的前綴映射類型，自從用了這套規則，字段沖突導致的kibana無法作報表的問題一掃而光啊，真的是不要太香了 。
• 是否需要打分，是否需要排序、聚合、過濾,如果不需要則(doc_values(dvm、dvd) norm(nvd、nvm))屬性需要關閉等等。
• 模板 template 比 mapping 更靈活，推薦結合別名多使用動態模板，尤其數據量每日增量巨大的業務場景。
• 字段非常明確固定、且未來不會新增字段，考慮mapping創建時設置："dynamic": "strict", 以嚴格控制Mapping泛濫。
• 結合業務選擇分詞器甚至自定義分詞器。

4、檢索層面

• 如果需要考慮查詢速度的優化，且排序字段基本固定，則可以考慮把 indexSort 配上，查詢時會提前中斷。

indexSort能通過預排序有效避免全局掃描，提前中斷查詢，提升查詢性能，對于查詢時按照某列排序（注意不適合相關性排序）的場景非常適合。

• 查詢根據業務實際考慮，建議最好把 Wildcard 模糊查詢、*.*等會導致數據量大的查詢做限制。
• 限制limit +offset，限制query_string等文本查詢的長度，限制term長度，隨時關注慢查詢日志。es是很強大，但是取決你怎么使用，你永遠不知道會怎么調你的接口…

5、硬件資源層面

5.1 磁盤層面

• 磁盤大小是否充足，壓縮格式使用默認speed Compression? 還是 Best Compression?

5.2 內存層面

• 采用默認NIOFS 還是MMAP，采用MMAP哪些需要預緩存到堆外。

6、集群管理層面

• 記得配置延時分片 index.unassigned.node_left.delayed_timeout。
• refresh、flush時間根據的實際業務需求調整。
• 對集群的性能監控越全面越好, 及時發現慢查詢，盡可能全面的根據業務評估使用量, 并能在瓶頸期發現和升級配置。
• 多節點集群，合理劃分節點角色，尤其要分離：主節點、數據節點、協調節點。

7、安全及災備層面

• 禁用批量刪除索引比默認的隨意刪除重要。
• 定期或者增量備份比無備份重要(條件允許的情況下)。
• 安全問題是必須的，我們是在日志清晰的時候做的核心字段加密，elk 整個技術棧都只允許內網訪問，對外的服務接口也是要軟 token 的。
• 將 ES 提供給業務研發去使用，更多的是需要考慮控制權限，降低門檻，最好是封裝一層網管提供給業務研發使用，然后再去多分享培訓，提高業務側研發對ES的認知。

8、性能優化層面

• 關閉系統swap。
• 如果數據量大，盡可能使用bulk 批量操作。

（1）寫入層面bulk操作，包含但不限于：bulk API 執行批量寫入、更新、刪除多文檔操作。

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

• 建議根據業務需求較早的設置開啟慢查詢日志。
• 堆內存大小不要超過32GB。
• 使用script 腳本時，要考慮可能帶來的慢、安全風險（早期版本）等負面影響。
• 在一定條件下，執行強制合并segment，查詢速度會提升很多。