如何優化Elasticsearch寫入速度

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

本次優化的示例版本是7.9.2。ES的版本升的是真快，已經完全脫離了5的時代了。

1、哪些操作占用資源

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

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

如上圖，一條數據想要最終落地，是需要經過多個步驟的。這個過程，甚至會有tranlog這樣的備份機制。

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

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

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

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

2、開始優化

數據寫入，主要有三個動作：flush、refresh和merge。通過調整它們的行為，即可在性能和數據可靠性之間進行權衡。

flush

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

這是因為，我們把數據寫到磁盤后，還要調用fsync才能把數據刷到磁盤中，如果不這樣做在系統掉電的時候就會導致數據丟失。

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

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" }'

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

refresh

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

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

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

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

對于日志系統來說，當然要把它調大一點啦。xjjdog這里調整到了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文件，數據刪除也會產生空間碎片。所以merge，通俗來講就像是碎片整理進程。像postgresql等，也有vaccum進程在干同樣的事。

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

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

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

• log_byte_size 以字節數的對數為計算單位，選擇多個索引來合并創建新索引。

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

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

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

3、微調

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

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

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

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

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