本篇內容來自於死磕 Elasticsearch 知識星球的一個作業題目：
Elasticsearch基礎但非常重要的功能還有哪些？
0,有安全比裸奔重要！
1,模板template比mapping重要。
2,顯式映射 strict mapping比隱式mapping重要！
3,別名重要！
4,結合業務選擇甚至自定義分詞器比使用默認重要！
請留言寫下您的思考。
https://t.zsxq.com/MrjQrfM
有20多人蔘與，大家把自己架構、開發、運維實戰中遇到的核心問題和建議都一股腦寫出來了。
我做了擴展梳理，相信對架構、開發、運維都有一定的幫助！
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，查詢速度會提升很多。
9、小結
從各個層面列舉了大家實戰中關心且常忽視的Tips，不求全，但求有用。
因爲 Tips 涉及內容多，沒有各個點展開。更多細節歡迎留言交流。
大家有實戰中更好的Tips，也歡迎留言交流一下。
感謝：球友們實戰 Tips 討論。
中國通過 Elastic 認證工程師人數最多的圈子！
更短時間更快習得更多幹貨！