如何優(yōu)化Elasticsearch寫入速度

這篇文章給大家分享的是有關(guān)如何優(yōu)化Elasticsearch寫入速度的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

本次優(yōu)化的示例版本是7.9.2。ES的版本升的是真快，已經(jīng)完全脫離了5的時代了。

1、哪些操作占用資源

要進行優(yōu)化，需要首先知道ES的寫入過程，了解哪些步驟最耗時。

首先，就是副本(replica)問題，為了保證起碼的高可用，這里的副本數(shù)量設(shè)置為1，是節(jié)省不了的。所以，將副本數(shù)量設(shè)置為0，只適合數(shù)據(jù)首次導(dǎo)入的時候。

如上圖，一條數(shù)據(jù)想要最終落地，是需要經(jīng)過多個步驟的。這個過程，甚至?xí)衪ranlog這樣的備份機制。

ES的底層存儲是Lucene，包含一系列的反向索引。這樣的索引就成為段(segment)。但記錄不會直接寫入段，而是先寫入一個緩沖區(qū)。

當(dāng)緩沖區(qū)滿了，或者在緩沖區(qū)呆的夠久，達到了刷新時間(劃重點)，會一次性將緩沖區(qū)的內(nèi)容寫進段中。

這也是為什么refresh_interval屬性的配置會嚴重的影響性能。如果你不要很高的實時性，不妨將其配置的大一點。

緩沖區(qū)默認使用堆空間的10%，最小值為48mb(針對于分片的)。如果你的索引多且寫入重，這部分內(nèi)存的占用是可觀的，可以適當(dāng)加大。

2、開始優(yōu)化

數(shù)據(jù)寫入，主要有三個動作：flush、refresh和merge。通過調(diào)整它們的行為，即可在性能和數(shù)據(jù)可靠性之間進行權(quán)衡。

flush

從上面的介紹可以看出來，translog寫入了一份全量的數(shù)據(jù)，它有點像MysSQL中的binlog，或者redis的aof，用來保證異常情況下的數(shù)據(jù)安全。

這是因為，我們把數(shù)據(jù)寫到磁盤后，還要調(diào)用fsync才能把數(shù)據(jù)刷到磁盤中，如果不這樣做在系統(tǒng)掉電的時候就會導(dǎo)致數(shù)據(jù)丟失。

ES默認每次請求都進行一次flush，但對于日志來說，這沒有必要，可以將這個過程改為異步的，參數(shù)如下：

curl -H "Content-Type: application/json"  -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{   "index.translog.durability" : "async", "index.translog.flush_threshold_size" : "512mb",   "index.translog.sync_interval" : "60s" }'

這可以說是最重要的一步優(yōu)化了，對性能的影響最大，但在極端情況下會有丟失部分數(shù)據(jù)的可能。對于日志系統(tǒng)來說，是可以忍受的。

refresh

除了寫translog，ES還會將數(shù)據(jù)寫入到一個緩沖區(qū)中。但是注意了!此時，緩沖區(qū)的內(nèi)容是無法被搜索到的，它還需要寫入到segment里面才可以。

這就是refresh動作，默認1秒。也就是你寫入的數(shù)據(jù)，大概率1秒之后才會被搜索到。

所以ES并不是一個實時性的搜索系統(tǒng)，它是一個類實時系統(tǒng)(near-realtime)。

通過index.refresh_interval可以修改這個刷新間隔。

對于日志系統(tǒng)來說，當(dāng)然要把它調(diào)大一點啦。xjjdog這里調(diào)整到了120s，減少了這些落到segment的頻率，速度自然會快。

curl -H "Content-Type: application/json"  -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{   "index.refresh_interval" : "120s" }'

merge

merge其實是lucene的機制，它主要是合并小的segment塊，生成更大的segment，來提高檢索的速度。

原因就是refresh過程會生成一大堆小segment文件，數(shù)據(jù)刪除也會產(chǎn)生空間碎片。所以merge，通俗來講就像是碎片整理進程。像postgresql等，也有vaccum進程在干同樣的事。

顯而易見，這種整理操作，既讓費I/O，又浪費CPU。

要命的是，merge有三種策略。

• tiered 默認選項，它能合并大小相似的索引段，并考慮每層允許的索引段的最大個數(shù)。

• log_byte_size 以字節(jié)數(shù)的對數(shù)為計算單位，選擇多個索引來合并創(chuàng)建新索引。

• log_doc 以索引段的文檔數(shù)量為計算單位，選擇多個索引來合并創(chuàng)建新索引。

每一種策略都有非常詳細的針對性配置，在此不啰嗦。

由于日志系統(tǒng)并沒有隨機性的刪除操作，所以我們保持默認就可以。

3、微調(diào)

新版本對線程池的配置進行了優(yōu)化，不需要配置復(fù)雜的search、bulk、index線程池。有需要配置下面幾個就行了：thread_pool.get.size,  thread_pool.write.size, thread_pool.listener.size,  thread_pool.analyze.size。具體可觀測_cat/thread_pool接口暴露的數(shù)據(jù)進行調(diào)整。

其實，可以通過配置多塊磁盤的方式，來分散I/O的壓力，但容易會造成數(shù)據(jù)熱點集中在單塊磁盤上。

Lucene的索引建立過程，非常耗費CPU，可以減少倒排索引的數(shù)量來減少CPU的損耗。第一個優(yōu)化就是減少字段的數(shù)量;第二個優(yōu)化就是減少索引字段的數(shù)量。具體的操作，是將不需要搜索的字段，index屬性設(shè)置為not_analyzed或者no。至于_source和_all，在實際調(diào)試中效果不大，不再贅述。

另外，如果日志是通過filebeat或者logstash這樣的組件傳導(dǎo)過來的，一般都是開啟了批量模式。通過批量能夠增加性能，但也不宜過大，可根據(jù)實際觀測進行設(shè)置，一般1k-1w之間都是可以的。

感謝各位的閱讀！關(guān)于“如何優(yōu)化Elasticsearch寫入速度”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！