題記
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基礎、進階、實戰第一公衆號