1、線上常見問題

在我線下對接企業(yè)或線上交流的時候，經(jīng)常會遇到各種業(yè)務(wù)場景不同的問題。

比如，常見問題歸類如下：

• 常見問題1：ES 適合場景及架構(gòu)選型問題。

公司的核心業(yè)務(wù)是做企業(yè)員工健康管理，數(shù)據(jù)來自電子化后的員工體檢報告以及各種健康數(shù)據(jù)采集設(shè)備，均存儲在關(guān)系型數(shù)據(jù)庫中。

先計劃搞健康大數(shù)據(jù)分析，比如某企業(yè)內(nèi)按部門，年齡段等對現(xiàn)有數(shù)據(jù)對比分析等。請問ES適合這個場景使用嗎？如果適合，大致的架構(gòu)是怎樣的？

• 常見問題2：節(jié)點偶然下線問題。

運輸數(shù)據(jù)場景，批量寫入導(dǎo)致 ES 宕機，集群偶然下線后導(dǎo)致無法上線，怎么解決？

• 常見問題3：數(shù)據(jù)不一致問題。

在原有的集群規(guī)模的數(shù)據(jù)非常大的基礎(chǔ)上，要刪除接近2/3的數(shù)據(jù)。這時候，兩個集群出現(xiàn)了數(shù)據(jù)不一致的情況，如何排查？

• 常見問題4：集群重啟時間超過20小時以上。

超過8小時的時候，沒有引起重視，后面起不起來了，才發(fā)現(xiàn)是大問題。

實地環(huán)境排查及大量溝通發(fā)現(xiàn)，這些后期出現(xiàn)的問題或者“坑”，前期規(guī)避的話，成本會更低。

2、發(fā)現(xiàn)的潛在的“坑”

如下的坑，都是中小型企業(yè)現(xiàn)場環(huán)境排查、騰訊會議交流等發(fā)現(xiàn)的。

提前聲明：對于一些大型企業(yè)、大廠不見得適用，畢竟場景不同，得具體問題具體分析。

（1）沒有選擇相對新的8.X版本，而是選擇了 6.X版本。

原因：對接 API 方便。

（2）一臺高配物理機（如：256GB內(nèi)存，64核CPU）部署一個節(jié)點，資源利用率非常低。

（3）不熟悉 Linux，集群部署依然基于 Windows 服務(wù)器。

（4）數(shù)據(jù)同步工具自己開發(fā)“另起爐灶”，關(guān)鍵功能和性能尚不如 Logstash等成熟工具。

（5）主分片設(shè)定未考慮集群未來的可橫向擴展性。

（6）批量寫入不考慮集群性能上限，直至節(jié)點宕機脫離集群。

（7）不借助可視化工具：Kibana monitoring 監(jiān)控集群，甚至 head 插件也沒有用起來，出現(xiàn)問題不知道如何排查。

（8）命令行 DSL 仍然借助 Postman 等工具實現(xiàn)。

（9）Wildcard 模糊匹配召回結(jié)果符合預(yù)期，就大量不計后果的使用。

（10）查詢細節(jié)參數(shù)不了解，能用起來就不關(guān)心其他。

3、Elasticsearch 常見認知“誤區(qū)”

• 認知誤區(qū)1：Elasticsearch 是關(guān)系型數(shù)據(jù)庫。

實際上，Elasticsearch是非關(guān)系型數(shù)據(jù)庫，不支持嚴格的關(guān)系數(shù)據(jù)模型，而是采用文檔型存儲。

探究 | Elasticsearch 與傳統(tǒng)數(shù)據(jù)庫界限

• 認知誤區(qū)2：Elasticsearch 只適用于搜索。

Elasticsearch不僅適用于搜索，還支持聚合、分析等功能。

• 認知誤區(qū)3：Elasticsearch 無需預(yù)處理數(shù)據(jù)。

Elasticsearch需要預(yù)處理數(shù)據(jù)，并對數(shù)據(jù)結(jié)構(gòu)有嚴格的要求，否則可能導(dǎo)致檢索效果不佳。

• 認知誤區(qū)4：Elasticsearch 可以無限擴展。

（1）縱向擴展得看機器是否支持動態(tài)擴內(nèi)存、CPU等資源，取決于硬件。

（2）橫向擴展得看多節(jié)點集群規(guī)模能否適配性能指標(biāo)，不見得是機器越多越好。

• 認知誤區(qū)5：Elasticsearch 安全性很高。

Elasticsearch 本身 7.1 之前不提供嚴格的安全性，需要通過相關(guān)的插件或配置來實現(xiàn)安全性。7.1（含）之后 xpack 基礎(chǔ)功能免費，8.X 之后安全成為必選項！

• 認知誤區(qū)6：Elasticsearch 無需維護。

不止要維護，Elasticsearch 需要定期維護，包括數(shù)據(jù)備份（借助快照和恢復(fù)功能）、性能優(yōu)化、安全更新等。

4、避坑方案探討

4.1 Elasticsearch 版本及架構(gòu)選型避坑

關(guān)于版本選型，Elastic 官方工程師如是說：“我完全理解穩(wěn)定性是最重要的問題。在那種情況下，我們不應(yīng)該選擇最新版本的 Elasticsearch。作為參考，所有當(dāng)前和過去的版本都可以在此頁面上找到......作為一種模式，我建議比最新版本早發(fā)布 4 到 6 個月的版本”。——來自阮一鳴老師和ES官方的討論帖。

關(guān)于版本選型，張超老師說“對穩(wěn)定性要求比較高的生產(chǎn)，不要用最新的版本，誰不也知道有沒有嚴重 bug，往前推一些，看看社區(qū)反饋沒有大問題的版本，修正版本號用最高的”。

如下幾點要謹慎考慮：

• 考慮功能要求：選擇支持我們需要的功能的版本，比如：xpack 功能7.1之后才免費，ilm功能 6.7 版本才推出。

• 考慮兼容性：確保您選擇的版本與正在使用的其他軟件和工具兼容，比如：java、python客戶端的選擇。

• 考慮數(shù)據(jù)量: Elasticsearch是否能夠滿足數(shù)據(jù)存儲和處理的要求？

• 考慮硬件資源：使用Elasticsearch需要充足的硬件資源，包括內(nèi)存，硬盤，帶寬等。

• 考慮集群架構(gòu)：要根據(jù)業(yè)務(wù)需求選擇合適的集群架構(gòu)，并考慮到集群的可用性和擴展性。

歷史版本下載地址：

https://www.elastic.co/cn/downloads/past-releases#ela...?

1. Elasticsearch架構(gòu)選型指南——不止是搜索引擎，還有......

2. 干貨 | Elasticsearch方案選型必須了解的10件事！

3. 干貨 | Elasticsearch Java 客戶端演進歷史和選型指南

4. https://blog.csdn.net/u013613428/article/details/103317806

4.2 ?Elasticsearch 常用工具避坑

“工欲善其事必先利其器”，沒有工具，效率無從談起。

推薦優(yōu)先級：Kibana > Head / cerebro > Postman。

學(xué)會使用：Kibana Dev Tool，并用好 ctrl + i 快捷鍵。

學(xué)會使用：Kibana monitor 監(jiān)控可視化工具。

更多推薦：

1. 嚴選 | Elasticsearch史上最全最常用工具清單

2. MetricBeat + Elasticsearch + Kibana 實現(xiàn)監(jiān)控指標(biāo)可視化

4.3 Elasticsearch 集群避坑

結(jié)合集群能承載的總數(shù)據(jù)量、每日的增量，在有預(yù)留的前提下，給出集群規(guī)模的評估。避免“拍腦袋”，要理性計算給出實際參考依據(jù)。

布局好節(jié)點角色，早期版本叫節(jié)點類型。要知道節(jié)點角色更為便捷。

確定是否需要冷熱集群架構(gòu)，區(qū)分：熱節(jié)點、溫節(jié)點、冷節(jié)點。冷熱集群架構(gòu)是 ILM 的前提，沒有它，ILM無從談起。

更多推薦：

探究 | Elasticsearch集群規(guī)模和容量規(guī)劃的底層邏輯

干貨 | Elasticsearch 8.X 節(jié)點角色劃分深入詳解

4.4 Elasticsearch 索引避坑

確定是否需要 ILM 索引生命周期管理，而不是僅適用 rollover + 腳本自己維護方式或借助 curator 實現(xiàn)。用好 Kibana 可視化管理好 ILM。

考慮索引承載數(shù)據(jù)上限和大索引可能帶來的風(fēng)險，提前做好業(yè)務(wù)層面的布局，不同業(yè)務(wù)使用不同索引，不要混用。

能用模板 template 的就不要單獨使用 index。

能支持 datastream 數(shù)據(jù)流（智能別名）就大膽使用。

模板和別名搭配、索引和別名搭配，干活不累。

定期備份集群索引數(shù)據(jù)，尤其業(yè)務(wù)索引，并準(zhǔn)備恢復(fù)方案，以防數(shù)據(jù)丟失。

數(shù)據(jù)遷移需要認真計劃，以防遷移不當(dāng)可能導(dǎo)致數(shù)據(jù)丟失或損壞問題。

更多推薦：

1. Elasticsearch ILM 索引生命周期管理常見坑及避坑指南?

2. 干貨 | Elasticsearch 索引生命周期管理 ILM 實戰(zhàn)指南

3. Elasticsearch 7.X data stream 深入詳解

4. Elasticsearch 快照生命周期管理 (SLM) 實戰(zhàn)指南

5. 干貨 | Elasitcsearch7.X集群/索引備份與恢復(fù)實戰(zhàn)?
   

4.5 Elasticsearch 分片避坑

由于路由機制原因，不同于副本分片支持 update 動態(tài)更新，Elasticsearch 主分片數(shù)一旦設(shè)定就不能動態(tài)更新，除非 reindex。

分片設(shè)置要不僅滿足當(dāng)下集群的需求，也要考慮集群的未來可擴展性。

單分片大小參見官方的 30GB-50GB的優(yōu)化建議（因場景而異，可能微調(diào)）。

更多推薦：

Elasticsearch究竟要設(shè)置多少分片數(shù)？

4.6 Elasticsearch 同步工具避坑

能借助 Ingest 預(yù)處理功能解決的，就不要使用 logstash。

能使用 logstash 解決基于時間遞增和基于id遞增同步的，就不要自己開發(fā)。

衡量好 Kafka_connector 和 logstash 的性能和適用場景。

阿里的 canal 工具在同步刪除和更新操作時，要優(yōu)先選擇，因為 logstash 不支持同步更新和刪除操作。

更多推薦：

1. Elasticsearch的ETL利器——Ingest節(jié)點?

2. Elasticsearch 預(yù)處理沒有奇技淫巧，請先用好這一招！

3. 從一個線上問題看 Elasticsearch 數(shù)據(jù)清洗方式?

4. 實戰(zhàn) | canal 實現(xiàn)Mysql到Elasticsearch實時增量同步?

5. 干貨 | Logstash Grok數(shù)據(jù)結(jié)構(gòu)化ETL實戰(zhàn)

4.7 Elasticsearch 檢索選型避坑

如果查詢語句不正確，可能導(dǎo)致查詢性能下降，例如查詢條件過于復(fù)雜、數(shù)據(jù)量過大等。

首先，建立起 ES 支持的檢索類型的全局認知。

其次：

• 區(qū)分好：什么是召回率？什么是精準(zhǔn)率？

• 區(qū)分好：什么是精準(zhǔn)匹配，什么是全文檢索？

• 區(qū)分好：哪些需要評分？哪些不需要評分？

• 區(qū)分好：什么叫 query？什么叫 filter？

最后：選型成功后，做充分的驗證，再部署到線上環(huán)境。

涉及性能相關(guān)的，要做足檢索并發(fā)性能測試。

PS：如果所有的已經(jīng)存在的檢索都無法達到業(yè)務(wù)指標(biāo)，得考慮分詞處下功夫，得考慮空間換時間。

推薦閱讀：

1. Elasticsearch 8.X 如何實現(xiàn)更精準(zhǔn)的檢索？

2. 實戰(zhàn) | Elasticsearch自定義評分的N種方法

3. 干貨 | Elasticsearch 檢索類型選型指南

4. JMeter 如何實現(xiàn) Elasticsearch 8.X 性能測試？
   

5. esrally 如何進行簡單的自定義性能測試？
   

4.8 Elasticsearch 數(shù)據(jù)建模避坑

Elasticsearch要求數(shù)據(jù)結(jié)構(gòu)符合其特定 Mapping 格式，如果數(shù)據(jù)結(jié)構(gòu)不合適，可能導(dǎo)致數(shù)據(jù)存儲不完整，后續(xù)檢索可能會非常復(fù)雜。

建模問題的核心在于，前期不會發(fā)現(xiàn)，往往項目的中后期才會發(fā)現(xiàn)。但，一旦發(fā)現(xiàn)，返工的概率就會極大，帶來了整體工期的延長和效率的降低。

所以，建議設(shè)計初期做足準(zhǔn)備。

做什么準(zhǔn)備呢？

（1）業(yè)務(wù)層面：不同索引可能跨索引檢索，字段的一致性必要性尤為凸顯。

（2）能“寬表”就不要或少用 Nested 嵌套字段、Join 多表關(guān)聯(lián)數(shù)據(jù)類型。

（3）避免字段爆炸，設(shè)置 strict 最為嚴謹，設(shè)置dynamic：false相對謹慎，設(shè)置默認的 dynamic：true 要慎之又慎，評估好風(fēng)險。

更多推薦：

1. 干貨 | Elasticsearch 數(shù)據(jù)建模指南

2. 干貨 | Elasticsearch多表關(guān)聯(lián)設(shè)計指南

3. Elasticsearch 8.X 防止 Mapping “爆炸”的三種方案
   

4.9 Elasticsearch 運維避坑

不要等出了問題采取看監(jiān)控，而是動態(tài)更新監(jiān)控指標(biāo)數(shù)據(jù)，考慮將集群各節(jié)點的健康狀態(tài)，以定時任務(wù)的形式發(fā)送到郵箱等。

定期監(jiān)控集群健康狀態(tài)，并及時解決任何問題，以保證集群穩(wěn)定運行。

用好運維監(jiān)控工具。Kibana monitor、grafana 均可。

日志建議再歸集到一個獨立的小ES集群，通過 kibana 可視化展示，并對于 Warn 及以上級別日志及時預(yù)警。

推薦如下：

（1）使用Elasticsearch的內(nèi)置監(jiān)控工具：如Node Stats API和Cluster Stats API，可用于監(jiān)控節(jié)點和集群的性能。

（2）使用 Kibana Monitoring：提供了全面的監(jiān)控功能，包括集群監(jiān)控、節(jié)點監(jiān)控、索引監(jiān)控等。

（3）定期評估集群健康：使用Elasticsearch的Cluster Health API評估集群的健康狀況，以檢測性能問題。

（4）記錄并分析日志：記錄并分析Elasticsearch的日志，以診斷性能問題。

（5）設(shè)置告警：設(shè)置告警，以提醒您有關(guān)性能問題的變化。建議和監(jiān)控工具（如：Zabbix）結(jié)合。

更多推薦：

1. MetricBeat + Elasticsearch + Kibana 實現(xiàn)監(jiān)控指標(biāo)可視化

2. 干貨 | Elasticsearch Top10 監(jiān)控指標(biāo)

3. 干貨 | Elasticsearch 運維實戰(zhàn)常用命令清單

4. 干貨 | Elasticsearch 集群健康值紅色終極解決方案
   

4.10 Elasticsearch 安全避坑

安全無小事，早期版本（1.X、2.X、5.X、6.X、7.X）“l(fā)uo奔”導(dǎo)致的安全事故依然屢見不鮮。8.X 的版本已經(jīng)全線支持默認安全機制，用起來是王道。

如果非要早期版本（5.X、6.X、7.X），建議一定至少加上 xpack 安全機制，至少設(shè)置好密碼。如果更早版本（1.X、2.X），建議不要開放外網(wǎng)權(quán)限，切記！

更多推薦：

1. 你的Elasticsearch在裸奔嗎？
   

2. 重要！！Elasticsearch 安全加固指南
   

3. Elasticsearch 腳本安全使用指南
   

5、小結(jié)

“坑”是成長過程中的財富，提前關(guān)注“坑”能提高開發(fā)效率。

歡迎大家就使用 Elasticsearch 過程中遇到的坑留言交流。

5、參考

https://articles.zsxq.com/id_oo0h8a5b6b8a.html

https://wx.zsxq.com/dweb2/index/search/%E4%BC%81%E4%B8%9A/alltopics?groupId=225224548581

https://t.zsxq.com/0bUYswMJn

推薦閱讀

1. 全網(wǎng)首發(fā)！從 0 到 1 Elasticsearch 8.X 通關(guān)視頻
   

2. 重磅 | 死磕 Elasticsearch 8.X 方法論認知清單（2022年國慶更新版）
   

3. 如何系統(tǒng)的學(xué)習(xí) Elasticsearch ？

4. 2023，做點事

更短時間更快習(xí)得更多干貨！

和全球?1800+?Elastic 愛好者一起精進！

比同事?lián)屜纫徊綄W(xué)習(xí)進階干貨！