Elasticsearch 方案選型必須瞭解的 10 件事

摘要： 題記 Elasticsearch 目前被廣泛使用，也越來越受到歡迎。一些傳統的行業甚至婚慶公司都已經在使用Elasticsearch。人們喜歡Elasticsearch，不單單因為它的典型特徵： 1）易於部署； 2）無需額外的軟體即可擴充套件到數百個節點...

題記

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等。

“裸奔的風險非常大”，進階閱讀： 你的Elasticsearch在裸奔嗎？

4、資料建模

4.1 使用別名

業務層面使用 別名 進行檢索、聚合操作。

別名的好處：
1）將應用和索引名稱隔離；
2）可以方便的實現跨索引檢索。

4.2 資料型別選型

進階閱讀： 乾貨 | 論Elasticsearch資料建模的重要性

5、檢索選型

• 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選型

API選型推薦使用： 官方API 。

原因：
1）版本更新及時、
2）新特性支援適配更新及時。

http://t.cn/EMUzubT

http://t.cn/EMUzubH

DSL開發推薦使用的Kibana的 Dev-tool ，非常高效、方便。

10、資料接入

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

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

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

kafka-connector ， flume ， canal 等。

選型中， 不一棵樹上吊死 ，綜合對比效能和穩定性，找適合自己業務場景的最為重要。

小結

安裝和執行開箱即用的Elasticsearch叢集非常簡單。 使其適用於你的實際業務場景並滿足你的效能指標非常不容易。

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

期待反饋交流心得！

參考： http://t.cn/EMUZw6N

新部落格域名： http://elastic.blog.csdn.net

加入星球，更短時間更快習得更多幹貨！