網羅Elasticsearch最佳實踐,實際應用場景中常見錯誤要預知和避免,以最大化提升集羣性能。
1、採用動態Mapping
如果不定義Mapping,Elasticsearch會根據輸入的數據,創建對應的Mapping,這看起來非常完美,但是Elasticsearch的動態Mapping並不總是精確的。
動態Mapping對於入門很有用
,但在某些時候您需要結合業務數據指定Mapping。
舉例1:5.x版本之後,需要分詞的字段需要設定text類型和對應的analyzer
;僅需要精確匹配的可直接設置爲keyword類型。
舉例2:長文本高亮需要在text類型的基礎上,設置fast-vector-highlighter
高亮方式,高亮效率能提升20倍以上。
2、聚合設置不當導致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
4、集羣不做規劃,遇到問題再說
1“我需要多少存儲空間、多大的內存?”是用戶經常問自己的問題。
遺憾的是,沒有固定的公式,但可以採取某些步驟來協助規劃資源。 推薦方法:模擬實際用例。 步驟1:創建ES集羣。 步驟2:使用與生產設置所需的數據速率幾乎相同的數據。 步驟3:啓動節點,用真實文檔填充它們,然後推送填充數據到索引分片。
在模擬實際用例過程中瞭解資源利用率非常重要,因爲它允許您爲節點保留適當的RAM量,配置JVM堆空間並優化整個測試過程。
根據模擬結果,決定實際集羣的內存、CPU、磁盤容量。
5、線程池設置不合理
ES節點具有許多線程池,以便改進節點內線程的管理方式。 但是每個線程可以處理多少數據存在限制。 要跟蹤此值,我們可以使用ES屬性:
1threadpool.bulk.queue_size:2000
這會向ES通知分片中的請求數,當沒有可用於處理請求的線程時,新請求可以在節點中排隊等待執行。 如果任務數高於此值,您將獲得RemoteTransportException。 該值越高,節點機器上所需的堆空間量就越大,並且JVM堆也將被消耗。 此外,你應該在代碼的開發階段做好異常處理。
注意:ES官網不建議修改此值。
小結
Elasticsearch的使用過程中總會遇到這樣、那樣的問題,多總結、多思考,形成針對業務場景的有效的解決方案。 同時,也要多吸取國內外社區、論壇、博客中的精華,取長補短。
注意:網絡文獻一般沒有涉及版本,老版本ES一些配置不一定適用於6.X最新版本,但,底層的技術永遠不過時。
參考:
[1] http://t.cn/RRv9dw9
[2]http://t.cn/E2iBb3X
推薦閱讀:
重磅 | 死磕Elasticsearch方法論認知清單(國慶更新版)