0、題記
Elastic中文社區和各種Elastic愛好者交流羣中會遇到形形色色的問題。
來自運維球友討論的真實線上吐槽問題總結：
問題1：開發不規範。
我們這邊es 都是我們在推,很多開發不會用或者用的不規範！
問題2：不管性能，用起來再說！
場景1：我們這邊開發只要work，管他wildcard，能模糊就好，管他內存，windows size死命地設，不管多少頁都讓它翻。
問題3：不評估可行性和高可用性，先搞起來。
場景1, 我們還在2.x，這些開發的大爺可以把size給你堆幾萬！
場景2, 那你叫產品看百度嘛，你搜個東西，前幾頁就有你想要的，會不會翻到10頁以後？
場景3, 對嘛，好多公司都是後臺開發用ES，也許是爲了緩解MySQL其他庫的查詢壓力就不管ES這邊的性能效率了，幾萬條數據都往回吐。
如下圖，某公司26歲的程序員王某的Elasitcsearch一把梭用法，能很形象的說出了問題產生的根因。
這裏引發大家思考：Elasticsearch到底是不是一把梭，用起來再說？！還是有更好的方式？
快速部署、快速增刪改查、快速上線就完了嗎？遇到問題怎麼辦？
我把常見問題總結爲常見的坑，希望您實戰中能避免踩坑。
1、坑1：不重視安全。
2019年12月初安全事件《Elasticsearch27億數據泄露，10億明文，波及中國大廠》。看到類似自媒體標題就很容易讓人恐慌。社區小夥伴真實中招案例如下：
根因：用起來再說，沒有考慮安全，端口直接暴露公網，機器相當於裸奔。
社區創始人Medcl大神說：不要等到出事了纔想起做基本的安全配置!
社區主席劉徵老師比喻恰如其分：
1,es集羣像是一套房子，有門也有鎖，以前大家不捨得買這把鎖，結果小偷推門就進去了，用戶被盜極大的影響使用體驗，現在鎖也免費了隨房屋附送了，請大家謹記上班出門的時候一定鎖好門，es也一樣，沒升級的趕緊升級，沒加鎖，也沒用鎖門習慣的趕緊養成好習慣
2,送的鎖可能需要拆盒安裝一下，這個動作用戶需要知道，房子裏的財產的估值決定了你是否做這個動作！！很形象的比喻。
安全咱們多次強調了：
乾貨 | Elasticsearch7.X X-Pack基礎安全實操詳解
官方文檔：Elasticsearch安全功能使您可以輕鬆保護集羣。您可以用密碼保護數據，並實施更高級的安全措施，例如加密通信，基於角色的訪問控制，IP過濾和審覈。
https://www.elastic.co/guide/en/elasticsearch/reference/7.5/configuring-security.html
2、坑2：不規劃集羣，出了問題再說。
實戰問題：
.....當時建的時候沒考慮好，按默認的建了5個分片，版本是6.0.0. 之前是用mysql的，剛遷過來，沒想到數據量非常大，基本每天增長1.5G左右。原來計劃數據至少要保存一年。.....
知識星球討論
建議：不要等數據量大了、磁盤滿了、性能出問題、並行寫入被拒絕了等再考慮規劃集羣。
實戰部署之前建議思考問題：
0、站在巨人的肩上，不閉門造車，查各種資料，總結思考別人如何規劃集羣的？
1、一共要存儲多少全量數據？
2、存儲週期是多長？
3、每天增量數據是多少？
4、客戶期望的QPS/TPS指標是多少？
5、需要幾個節點，如何劃分節點角色？
6、是否有冷熱數據之分？
7、業務層面分幾個索引？
8、每個索引分幾個分片？
9、單分片最大支持的數據量？
10、要不要刪除歷史數據，如何刪除等？
注意：任何別人的建議都是基於特定的場景，特定的物理環境，特定的ES版本及特定的集羣規模等實施的，如果在規劃前自己拿不準，建議通過esrally等測試工具驗證一下。
集羣規劃推薦：
探究 | Elasticsearch集羣規模和容量規劃的底層邏輯
3、坑3：不設置副本、數據不備份，導致數據丟失。
業務場景不同，自行決定數據是否需要副本和備份。
但是相對高可用的場景，建議副本數至少設置爲1。
設置副本好處：
提升檢索的高可用性；
讀操作並行，分擔集羣壓力。
副本數量要可受控。
理想最小值：1；最大值：節點數-1。
平衡點：增量基準測試是一種很好的縮小範圍的方法。逐步添加副本，並測量每個新副本的性能改進。如果改進不明顯，副本數可能不適宜調太高。
參考：
https://bonsai.io/blog/ideal-elasticsearch-cluster/
如上截圖的極限情況會造成數據丟失的。
高可用的場景除了設置副本，建議定期做增量快照，確保數據丟失後可恢復，不影響線上業務。
4、坑4：不考慮建模，導致性能問題。
數據建模的重要性，無需贅述。
1、使用模板和別名規劃索引，必要時結合Ingest。
2、儘量自己顯示定義Mapping，不採用動態生成的Mapping。
3、根據業務場景，選擇適合自己業務場景的分詞器。
4、Mysql的多表關聯，在ES中對應選擇：寬表存儲、nested存儲（子文檔更新不頻繁）、join父子文檔（子文檔更新頻繁）。
5、根據實際業務需要選定合適的字段，以最大化優化存儲。如：是否分詞、是否聚合、是否存儲等。
上面截圖也展示了keyword較數值型的性能優勢，選型時也需要斟酌提前考慮。
這些問題先寫入數據，後考慮可以不？
可以，但，不專業。
如果是海量數據，reindex遷移數據都會花費您很長時間。
5、坑5：不重視官網基礎，自認爲一切在掌控之中。
坑 5.1：多集羣一臺機器部署，相同的path.data路徑，無異於自殺。
血淋淋的線上教訓：詳見如下：羣友真實案例。大家多注意！
以後多注意：
1,數據目錄：path.data不要多集羣共享。
2,最好一個機器一個集羣節點，如果機器配置高可以考慮分虛擬機或者docker虛擬化或者其他，但path.data切記不要一樣。
坑 5.2：參數配置不合理導致腦裂。
6.x 版本，2節點，minimum_master_nodes最小主機節點數設置1,運行很長一段時間未知原因導致腦裂。
剖析原因：沒有按照官方文檔配置。最小主力節點數=候選主機節點/2＋1,應該配置2纔可能不腦裂。
6.X官方明確說明：To avoid a split brain, this setting should be set to a quorum of master-eligible nodes:(master_eligible_nodes / 2) + 1
我現在用7.X了，還要考慮嗎？
注意：在 Elasticsearch 7.0 中，重新設計並重建了集羣協調子系統：移除了 minimum_master_nodes 設置，讓 Elasticsearch 自己選擇可以形成法定數量的節點。
好處1：用戶無需設置最小主節點個數了，集羣層面給解決了。
好處2：避免用戶配置錯誤導致出現腦裂問題。
好處3：選主更快了。
視頻demo 演示：
https://discuss.elastic.co/t/avoid-split-brain-with-new-elasticsearch-7-0-after-discovery-zen-minimum-master-nodes-removal/176877
https://www.elastic.co/cn/blog/a-new-era-for-cluster-coordination-in-elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/discovery-settings.html
坑 5.3：堆內存不合理設置
羣友反饋：線上環境：集羣節點內存大小爲64GB，堆內存設置4g。
出現問題：es啓動前後內存比例太大，堆被打滿。
覆盤：問題很明顯了 堆設置不合理。
建議：min（機器內存/2，32GB）
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
坑 5.4：磁盤使用NAS 導致拒絕請求
各位好，請教一個問題:掛載nas-SSD的es(docker）集羣，1個master，2個協調，18個data節點，每個16核32g。大量查詢時會出現拒絕請求的情況，nas的數據是每秒1.2g，延遲5ms。會出現rejected的情況。
微信羣討論
導致的原因估計是宿主機的io在異常時95+，不確定是主機瓶頸還是網絡或者nas的瓶頸。各位有什麼方案或建議嗎？
已經在業務和參數做了一些優化了。我現在想到的是:
1.換物理機掛本地磁盤
2.現在path.data都是掛一個nas，換成多個path.data，目前還不清楚負載是否均衡
回覆：nas官方不推薦，會有性能問題。
官方文檔提示：
避免使用網絡附加存儲（NAS）。人們常聲稱他們的 NAS 解決方案比本地驅動器更快更可靠。
除卻這些聲稱， 我們從沒看到 NAS 能配得上它的大肆宣傳。NAS 常常很慢，顯露出更大的延時和更寬的平均延時方差，而且它是單點故障的。
Always use local storage, remote filesystems such as NFS or SMB should be avoided. Also beware of virtualized storage such as Amazon’s Elastic Block Storage.
官網地址：
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/tune-for-indexing-speed.html
https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html
6、 我知道了這些坑又如何，怎麼破？
以上坑都值得我們開發、運維實際方案選型、可行性分析、方案評估、業務實戰中反思。避免類似問題發生。
瞭解和掌握中間隔了十萬八千里（包括我自己也存在認知問題）。
6.1、重視官方文檔同時多調研
一定要優先覈對官方文檔。比如：wildcard前綴匹配少用或者不用。
你習得別人分享的坑，就是你業務中需要避免的點。
類似的坑，性能分析的文章，都會有提示。
6.2、彆着急動手，先預研實踐一把
摸着石頭先過河，主要看水多深，能不能過去。
比如：深度翻頁，from size. 要不要翻頁100頁之後，甚至1000頁之後。
業務產品經理就這麼要求怎麼辦？
給出測試時間數據，讓架構層參與一起評估。
同時：給出scroll scroll after slice等解決方案。
6.3、在前期就要考慮性能
1, 準備多少臺服務器？
硬件配置 cpu 內存 磁盤,堆內存等都得考慮。
2，業務層面支持多少併發？寫入速率？查詢返回時間的要求指標？
都是需要關注的點。運維考慮我需要哪些硬件資源、優化配置以提供支撐？
開發考慮：我怎麼優化查詢、優化業務細節。多考慮、多考慮、多考慮。
3, 提前避免導致慢查詢、gc相關的操作。
包含不限於：優化配值、預熱緩存機制、冷熱架構集羣機制、合理控制分片、按時間規劃切分索引、模板、別名、靜態mapping、最優檢索等等。
6.4,切記Elasticsearch不是一把梭，快了就是慢了！
的確，數據量不大，部署、數據導入、增刪改查搞定的瞬間，感覺ES“不就那麼回事嗎？有什麼難的？”
這麼想的時候，就是可能危險的時候！
用就得好好用，參考第一手資料官方文檔。而不是各種網上搜到的片段。
6.5 考慮版本升級
羣友還有1.X，2.X，5.X的不少釘子戶存在，礙於各種原因（jie kou），不能升級。
不升級，體會不到性能優勢和新功能點（尤其）。
現在不升級，時間長了徒傷悲。
後面會相對更麻煩。推薦看下升級7.x的10個理由。
不盡興，歡迎留言討論您實戰中遇到的坑。也歡迎交流您的"一把梭"用法！
推薦：
重磅 | 死磕Elasticsearch方法論認知清單（2019國慶更新版）
elastic.blog.csdn.net
