Elasticsearch常見的5個錯誤及解決策略

網羅Elasticsearch最佳實踐，實際應用場景中常見錯誤要預知和避免，以最大化提高集羣性能。

一、採用動態Mapping
若是不定義Mapping，Elasticsearch會根據輸入的數據，建立對應的Mapping，這看起來很是完美，可是Elasticsearch的動態Mapping並不老是精確的。
動態Mapping對於入門頗有用，但在某些時候您須要結合業務數據指定Mapping。

舉例1：5.x版本以後，須要分詞的字段須要設定text類型和對應的analyzer ；僅須要精確匹配的可直接設置爲keyword類型。
舉例2：長文本高亮須要在text類型的基礎上，設置fast-vector-highlighter高亮方式，高亮效率能提高20倍以上。

二、聚合設置不當致使OOM
在某些聚合中，沒有足夠的內存來支持複雜的嵌套聚合，致使聚合結果超時甚至OOM。

舉例說明：

現有9億條數據，45個索引，每條數據大小爲2k左右 在查詢時候，
首先要按照時間進行排序，而後作三次分組操做？
https://elasticsearch.cn/question/6323

羣友討論實際問題

聚合爆炸是計算問題，可能致使某些聚合的桶生成呈指數增加，並可能致使不受控制的內存使用。

Elasticsearch「terms」字段根據您的數據構建存儲桶，但沒法預測將提早建立多少存儲桶。 對於由多個子聚合組成的父聚合，這可能會有問題。 組合每一個子聚合中的惟一值可能會致使建立的桶數量大幅增長。

咱們來看一個例子。

假設您有一個表明運動隊的數據集。 若是你想特別關注那支球隊的前10名球員和以及他們的支持球員，那麼聚合將以下所示

1{
2"aggs" : {
3"play_aggs" : {
4"terms" : {
5"field" : "players",
6"size" : 10
7},
8"aggs" : {
9"other_aggs" : {
10"terms" : {
11"field" : "players",
12"size" : 5
13}
14}
15}
16}
17}
18}

聚合將返回前10名球員的列表以及每位頂級球員的前五名支持球員的列表 - 這樣總共將返回50個值。這個看上去簡單的查詢能夠垂手可得地消耗大量內存。

terms聚合能夠顯示爲使用每一個級別的桶的樹。所以，以上聚合中每一個頂級球員的桶將構成第一級，而另外一個聚合中的每一個支持球員的桶將構成第二級。所以，一個團隊將生產n²桶。想象一下，若是您擁有5億個文檔的數據集會發生什麼。

Collection Mode用於幫助控制子聚合的執行方式。聚合的默認Collection Mode稱爲深度優先，首先須要構建整個樹，而後修剪邊緣。雖然深度優先是大多數聚合的適當收集模式，但它不適用於上面的運動員聚合示例。所以，Elasticsearch容許您將特定聚合中的收集模式更改成更合適的方式。

諸如上面的示例之類的規範應該使用廣度優先收集模式，該模式一次構建和修剪樹一級以控制聚合爆炸。 此收集模式極大地幫助減小消耗的內存量並保持節點穩定。

1{
2"aggs" : {
3"play_aggs" : {
4"terms" : {
5"field" : "players",
6"size" : 10,
7"collect_mode" : "breadth_first"
8},
9"aggs" : {
10"other_aggs" : {
11"terms" : {
12"field" : "players",
13"size" : 5
14}
15}
16}
17}
18}
19}

推薦閱讀：http://t.cn/RHndSgY

3. ES索引設置不當
   3.1 集羣名稱配置
   ES啓動的默認羣集名稱稱爲elasticsearch。 若是羣集中有許多節點，最好保持命名標誌儘量一致，例如：

1cluster.name:app_es_production
2node.name:app_es_node_001

3.2 集羣恢復設置
節點的恢復設置也很重要。 假設羣集中的某些節點因爲故障而從新啓動，而且某些節點在其餘節點以後重啓。 爲了使全部這些節點之間的數據保持一致，咱們必須運行一致性程序，以使全部集羣保持一致狀態。

舉例1：只要10個數據或主節點已加入羣集，便可恢復。

1gateway.recover_after_nodes：10

舉例2：集羣中期待啓動節點達到20個以及時間超過7分鐘後，集羣重啓或恢復。

1gateway.expected_nodes：20
2gateway.recover_after_time：7m

使用正確的配置，可能須要數小時的恢復縮減到只須要分鐘級，極大提升工做效率。

3.3 防腦裂配置
minimum_master_nodes對於羣集穩定性很是重要。 它們有助於防止腦裂。
此設置的建議值爲（N / 2）+ 1 ， 其中N是候選主節點的節點數。
有了這個，若是你有10個能夠保存數據併成爲主數據的 候選主節點，那麼該值將是6。
若是您有三個專用主節點和1,000個數據節點，則該值爲兩個（僅計算候選主節點）：
discovery.zen.minimum_master_nodes：2

四、集羣不作規劃，遇到問題再說
1「我須要多少存儲空間、多大的內存？」是用戶常常問本身的問題。

遺憾的是，沒有固定的公式，但能夠採起某些步驟來協助規劃資源。
推薦方法：模擬實際用例。
步驟1：建立ES集羣。
步驟2：使用與生產設置所需的數據速率幾乎相同的數據。
步驟3：啓動節點，用真實文檔填充它們，而後推送填充數據到索引分片。

在模擬實際用例過程當中瞭解資源利用率很是重要，由於它容許您爲節點保留適當的RAM量，配置JVM堆空間並優化整個測試過程。

根據模擬結果，決定實際集羣的內存、CPU、磁盤容量。

五、線程池設置不合理
ES節點具備許多線程池，以便改進節點內線程的管理方式。 可是每一個線程能夠處理多少數據存在限制。 要跟蹤此值，咱們可使用ES屬性：

1threadpool.bulk.queue_size：2000

這會向ES通知分片中的請求數，當沒有可用於處理請求的線程時，新請求能夠在節點中排隊等待執行。 若是任務數高於此值，您將得到RemoteTransportException。 該值越高，節點機器上所需的堆空間量就越大，而且JVM堆也將被消耗。
此外，你應該在代碼的開發階段作好異常處理。

注意：ES官網不建議修改此值。

小結
Elasticsearch的使用過程當中總會遇到這樣、那樣的問題，多總結、多思考，造成針對業務場景的有效的解決方案。
同時，也要多吸收國內外社區、論壇、博客中的精華，取長補短。

注意：網絡文獻通常沒有涉及版本，老版本ES一些配置不必定適用於6.X最新版本，但，底層的技術永遠不過期。