這篇文章主要為大家展示了“怎么提高ElasticSearch 索引速度”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學習一下“怎么提高ElasticSearch 索引速度”這篇文章吧。

成都創(chuàng)新互聯(lián)公司成立于2013年，先為嵐山等服務(wù)建站，嵐山等地企業(yè)，進行企業(yè)商務(wù)咨詢服務(wù)。為嵐山企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

我Google了下，大致給出的答案如下：

1. 使用bulk API

2. 初次索引的時候，把 replica 設(shè)置為 0

3. 增大 threadpool.index.queue_size

4. 增大 indices.memory.index_buffer_size

5. 增大 index.translog.flush_threshold_ops

6. 增大 index.translog.sync_interval

7. 增大 index.engine.robin.refresh_interval

這篇文章會講述上面幾個參數(shù)的原理，以及一些其他的思路。這些參數(shù)大體上是朝著兩個方向優(yōu)化的：

• 減少磁盤寫入

• 增大構(gòu)建索引處理資源

一般而言，通過第二種方式的需要慎用，會對集群查詢功能造成比較大的影響。

這里還有兩種形態(tài)的解決方案：

• 關(guān)閉一些特定場景并不需要的功能，比如Translog或者Version等

• 將部分計算挪到其他并行計算框架上，比如數(shù)據(jù)的分片計算等，都可以放到Spark上事先算好

上面的參數(shù)都和什么有關(guān)

• 其中 5,6 屬于 TransLog 相關(guān)。

• 4 則和Lucene相關(guān)

• 3 則因為ES里大量采用線程池，構(gòu)建索引的時候，是有單獨的線程池做處理的

• 7 的話個人認為影響不大

• 2  的話，能夠使用上的場景有限。個人認為Replica這塊可以使用Kafka的ISR機制。所有數(shù)據(jù)還是都從Primary寫和讀。Replica盡量只作為備份數(shù)據(jù)。

Translog

為什么要有Translog?  因為Translog順序?qū)懭罩颈葮?gòu)建索引更高效。我們不可能每加一條記錄就Commit一次，這樣會有大量的文件和磁盤IO產(chǎn)生。但是我們又想避免程序掛掉或者硬件故障而出現(xiàn)數(shù)據(jù)丟失，所以有了Translog，通常這種日志我們叫做Write  Ahead Log。

為了保證數(shù)據(jù)的完整性，ES默認是每次request結(jié)束后都會進行一次sync操作。具體可以查看如下方法：

該方法會調(diào)用IndexShard.sync 方法進行文件落地。

你也可以通過設(shè)置index.translog.durability=async  來完成異步落地。這里的異步其實可能會有一點點誤導。前面是每次request結(jié)束后都會進行sync,這里的sync僅僅是將Translog落地。而無論你是否設(shè)置了async,都會執(zhí)行如下操作：根據(jù)條件，主要是每隔sync_interval(5s)  ，如果flush_threshold_ops(Integer.MAX_VALUE)，flush_threshold_size(512m),flush_threshold_period(30m)  滿足對應(yīng)的條件，則進行flush操作，這里除了對Translog進行Commit以外，也對索引進行了Commit。

所以如果你是海量的日志，可以容忍發(fā)生故障時丟失一定的數(shù)據(jù)，那么完全可以設(shè)置，index.translog.durability=async，并且將前面提到的flush*相關(guān)的參數(shù)調(diào)大。

而極端情況，你還可以有兩個選擇：

• 設(shè)置index.translog.durability=async，接著設(shè)置index.translog.disable_flush=true進行禁用定時flush。然后你可以通過應(yīng)用程序自己手動來控制flush。

• 通過改寫ES 去掉Translog日志相關(guān)的功能。

當然，如果去掉Translog日志有兩個風險點：

• Get***數(shù)據(jù)會有點問題。因為根據(jù)ID Get***數(shù)據(jù)是從Translog里拿的。

• 我們知道ES通過Shard Replication 保證Node節(jié)點出現(xiàn)故障時出現(xiàn)數(shù)據(jù)的完整性。在Relocating的時候，Replica  從Primary 進行Recover時，Primary會先Snapshot Lucene，然后拷貝數(shù)據(jù)到Replica,***通過回放Translog  保證數(shù)據(jù)的一致性。

Version

Version可以讓ES實現(xiàn)并發(fā)修改，但是帶來的性能影響也是極大的,這里主要有兩塊：

• 需要訪問索引里的版本號，觸發(fā)磁盤讀寫

• 鎖機制

目前而言，似乎沒有辦法直接關(guān)閉Version機制。你可以使用自增長ID并且在構(gòu)建索引時，index 類型設(shè)置為create。這樣可以跳過版本檢查。

這個場景主要應(yīng)用于不可變?nèi)罩緦耄S著ES被越來越多的用來做日志分析，日志沒有主鍵ID,所以使用自增ID是合適的，并且不會進行更新，使用一個固定的版本號也是合適的。而不可變?nèi)罩就亲非笸掏铝俊?/p>

當然，如果有必要，我們也可以通過改寫ES相關(guān)代碼，禁用版本管理。

分發(fā)代理

ES是對索引進行了分片(Shard)，然后數(shù)據(jù)被分發(fā)到不同的Shard。這樣 查詢和構(gòu)建索引其實都存在一個問題：

如果是構(gòu)建索引，則需要對數(shù)據(jù)分揀，然后根據(jù)Shard分布分發(fā)到不同的Node節(jié)點上。

如果是查詢，則對外提供的Node需要收集各個Shard的數(shù)據(jù)做Merge

這都會對對外提供的節(jié)點造成較大的壓力，從而影響整個bulk/query 的速度。

一個可行的方案是，直接面向客戶提供構(gòu)建索引和查詢API的Node節(jié)點都采用client模式，不存儲數(shù)據(jù)，可以達到一定的優(yōu)化效果。

另外一個較為麻煩但似乎會更優(yōu)的解決方案是，如果你使用類似Spark  Streaming這種流式處理程序，在***往ES輸出的時候，可以做如下幾件事情：

• 獲取所有primary shard的信息，并且給所有shard帶上一個順序的數(shù)字序號，得到partition(順序序號) ->  shardId的映射關(guān)系

• 對數(shù)據(jù)進行repartition,分區(qū)后每個partition對應(yīng)一個shard的數(shù)據(jù)

• 遍歷這些partions,寫入ES。方法為直接通過RPC 方式，類似transportService.sendRequest  將數(shù)據(jù)批量發(fā)送到對應(yīng)包含有對應(yīng)ShardId的Node節(jié)點上。

這樣有三點好處：

1. 所有的數(shù)據(jù)都被直接分到各個Node上直接處理。避免所有的數(shù)據(jù)先集中到一臺服務(wù)器

2. 避免二次分發(fā)，減少一次網(wǎng)絡(luò)IO

3. 防止***處理數(shù)據(jù)的Node壓力太大而導致木桶短板效應(yīng)

場景

因為我正好要做日志分析類的應(yīng)用，追求高吞吐量，這樣上面的三個優(yōu)化其實都可以做了。一個典型只增不更新的日志入庫操作，可以采用如下方案：

1. 對接Spark Streaming,在Spark里對數(shù)據(jù)做好分片，直接推送到ES的各個節(jié)點

2. 禁止自動flush操作，每個batch 結(jié)束后手動flush。

3. 避免使用Version

我們可以預期ES會產(chǎn)生多少個新的Segment文件，通過控制batch的周期和大小，預判出ES  Segment索引文件的生成大小和Merge情況。***可能減少ES的一些額外消耗

以上是“怎么提高ElasticSearch 索引速度”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

分享名稱：怎么提高ElasticSearch索引速度
分享URL：http://chinadenli.net/article38/ppdcsp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供電子商務(wù)、、自適應(yīng)網(wǎng)站、Google、網(wǎng)站營銷、軟件開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)