幹貨 Elasticsearch方案選型必須了解的10件事！

題記

Elasticsearch 目前被廣泛使用，也越來越受到歡迎。一些

傳統的行業甚至婚慶公司都已經在使用Elasticsearch。

人們喜歡Elasticsearch，不單單因為它的典型特征：

1）易于部署；
2）無需額外的軟體即可擴充到數百個節點；
3）内置RESTful API，上手快；
4）開源+更新快+社群相當活躍。           

更重要的是Elastic已經形成了包含Elasticsearch、logstash、kibana、Beats等的Elastic Stack一體化解決方案。

在大家使用Elasticsearch作為備用選型方案期間，被問到最多的問題之一是：

“Elasticsearch作為解決方案需要注意什麼？”

本文以15年國外經典部落格的架構為線索，剔除過時的技術體系、技術棧内容，結合近千萬級業務場景和最新Elastic技術洞察重新梳理出：Elasticsearch方案選型必須了解的10件事。

1、叢集規模

Elasticsearch的優點在于它是非常容易擴充。但，索引和查詢時間可能因許多因素而異。在叢集規模層面一方面要考慮資料量，另一方面比較重要的衡量因素是項目/産品的名額要求。

要想達到吞吐量和CPU使用率的名額要求，建議進行一定量的測試，以确認叢集承擔的負載和性能瓶頸問題。

測試工具推薦：

Apache Jmeter

。

網上會有很多的一線網際網路公司等的“他山之石”，但，方案僅供參考，需要自己結合業務場景、硬體資源進行反複測試驗證。

2、節點職責

Elasticsearch節點可以是主節點（Master），資料節點（Data），用戶端/路由節點（Client）或某種組合。 大多數人大規模叢集選擇專用主節點（至少3個），然後選擇一些資料和用戶端節點。

建議：

職責分離

，并您針對特定工作負載優化每種類型的節點的配置設定。

例如，通過分離用戶端和資料節點提升性能。 用戶端節點處理傳入的HTTP請求，這使得資料節點為查詢提供服務。

這并不是絕對的，有大量網友在社群回報，分離用戶端節點并沒有提升性能，因實際場景而異，大規模資料增量的業務場景，職責分離必然是大勢所趨。

3、安全

近期，未加任何安全防護措施的Elastic安全事件頻發。建議在應用程式API和Elasticsearch層之間以及Elasticsearch層和内部網絡之間保護您的Elasticsearch叢集。

• 6.3+版本之後，xpack插件已經內建到Elastic産品線。（收費）
• 加一層Nginx代理，能防止未經授權的通路。
• 其他選型推薦：search-guard，readonlyRest等。

“裸奔的風險非常大”，進階閱讀：

https://blog.csdn.net/laoyang360/article/details/86347480

4、資料模組化

4.1 使用别名

業務層面使用

别名

進行檢索、聚合操作。

别名的好處：

1）将應用和索引名稱隔離；

2）可以友善的實作跨索引檢索。

4.2 資料類型選型

若不指定資料類型的動态映射機制，比如：字元串類型會預設存儲為text和keyword兩種類型，勢必會

增加存儲成本

建議：針對業務場景需求，靜态的手動指定好每個字段的資料類型。

考慮因素包含但不限于：

1）是否需要索引；

2）是否需要存儲；

3）是否需要分詞；

4）是否需要聚合；

5）是否需要多表關聯（nested類型、join或者是寬表存儲）；

6）是否需要快速響應（keyword和long類型選型）

…

此處的

設計時間不能省

進階閱讀：

https://blog.csdn.net/laoyang360/article/details/82287045

5、檢索選型

Elasticsearch

查詢DSL非常龐大。如果業務場景不需要計算評分，推薦使用過濾器filter。因為基于緩存，更高效。

查詢相關的API包含但不限于：

• match/multi_match
• match_phrase/match_phrase_prefix
• term/terms
• wildcard/regexp
• query_string

選型前，建議通過Demo驗證一下是否符合預期。

了解如何編寫高效查詢是一回事，但讓它們傳回最終使用者期望的結果是另一回事。

業務實戰中，建議

花一些時間

調整分析器、分詞和評分，以便ES傳回期望的正确的命中。

6、監控和警報

請務必考慮一個完全獨立的“監視”叢集機制，該機制僅用于捕獲有關群集運作狀況的統計資訊，并在出現問題時提醒您。

監控

作用：能通過可視化的方式，直覺的看到記憶體、JVM、CPU、負載、磁盤等的使用情況，以對可能的突發情況及早做出應對方案。

警報

作用：異常實時預警。

ES6.X xpack已經內建watcher工具。它會監視某些條件，并在滿足這些條件時提醒您。

舉例：當某些狀态（例如JVM堆）達到門檻值時，您可以采取一些操作（發送電子郵件，調用Web鈎子等）。

如果你的業務場景是：幾乎實時地将資料寫入Elasticsearch并希望在資料與某些模式比對時收到警報，則推薦使用

ElastAlert

https://github.com/Yelp/elastalert

7、節點配置和配置管理

一旦擁有多個節點，就每個節點在軟體版本、配置等方面保持同步變得具有挑戰性。

有許多開源工具可以幫助解決這個問題。推薦：

Chef

和

Ansible

幫助管理Elasticsearch叢集。

Ansible

可以自動執行更新和配置傳播，而無需在任何Elasticsearch節點上安裝任何其他軟體。

目前可能看不到對自動化的巨大需求，如果要從小規模開始發展，并且希望能夠快速發展的話，一個使用Ansible編寫的常見任務庫可以使你在幾分鐘内從裸伺服器轉到完全配置的Elasticsearch節點，

無需人工幹預

增量索引的管理推薦：rollover + curator + crontab，6.6版本的新特性：

Index Lifecycle Management(索引生命周期管理）

，推薦嘗鮮使用。

8、備份和恢複

經常被問到的問題1“ES中誤删除的資料（delete或者delete_by_query）能恢複嗎？”

——答案：如果做了備份，是可以的。如果沒有，不可以。

問題2：“遷移節點，直接data路徑原封不動拷貝可以嗎？”

——答案：不可以，不推薦。推薦使用reindex或其他工具實作。

對于高可用性的業務系統，資料的備份功能非常重要。 由于資料的存儲可能會涉及多個節點，依賴OS級檔案系統備份可能會很冒險。

推薦使用Elasticsearch内置的“快照”功能，可以備份您的索引。

9、API選型

Elastic

官方

支援API，包含：JAVA、Java Script、.net、PHP、python、Ruby。

Elastic民間API（社群貢獻）非常龐大：C++、Go等20多種。

API選型推薦使用：

官方API。

原因：

1）版本更新及時、

2）新特性支援适配更新及時。

https://www.elastic.co/guide/en/elasticsearch/client/community/current/index.html https://www.elastic.co/guide/en/elasticsearch/client/index.html

DSL開發推薦使用的Kibana的

Dev-tool

，非常高效、友善。

10、資料接入

将資料索引到Elasticsearch很容易。 根據資料源和其他因素，您可以自己編寫，也可以使用Elastic中的

Logstash

工具。

Logstash可以檢視日志檔案或其他輸入，然後有效地将資料索引到叢集中。

其他大資料元件或開源項目也有類似的功能，舉例：

kafka-connector

，

flume

canal

等。

選型中，

不一棵樹上吊死

，綜合對比性能和穩定性，找适合自己業務場景的最為重要。

小結

安裝和運作開箱即用的Elasticsearch叢集非常簡單。 使其适用于你的實際業務場景并滿足你的性能名額非常不容易。

希望這個清單能助力你的Elastic方案選型，為選型掃清障礙。

期待回報交流心得！

參考：

https://ecmarchitect.com/archives/2015/07/27/4031

銘毅天下——Elasticsearch基礎、進階、實戰第一公衆号