【FusionInsight Elasticsearch二次開發最佳實踐】寫入優化

1.1 基本優化手段

Elasticsearch默認的設置和參數配置下，是綜合考慮了數據的可靠性、搜索實時性、寫入速度等因素。如果業務場景中，業務對數據的寫入速度要求高，可以通過調整一些策略，優化寫入速度。

綜合來說，提升寫入速度可以從以下幾個方面入手：

1.???????? 加大index refresh間隔，除了降低IO，更重要的是降低了segment merge的頻率；

2.???????? 加大translog refresh間隔，目的是降低iops、writeblock；

3.???????? 調整bulk請求，控制每次bulk請求提交的量；

4.???????? 優化磁盤間的任務均勻情況，將shard盡量均勻分布到機器的各個磁盤；

5.???????? 優化節點間的任務分布，將任務盡量均勻地發布到各節點，避免單點阻塞問題；

6.???????? 優化Lucene層建立索引的過程，目的是降低CPU占用率及IO，例如，禁用_all字段。

1.2 索引刷新間隔

默認情況下索引的refresh_interval為1秒，這意味著數據寫1秒后就可以被搜索到，每次索引的refresh會產生一個新的lucene段，這會導致頻繁的segment merge行為，如果你不需要這么高的搜索實時性，應該降低索引refresh周期，如：

index.refresh_interval: 120s

1.3 Translog刷新間隔

默認設置下，translog的持久化策略為：每個請求都flush。對應配置項為：

index.translog.durability: request

這是影響Elasticsearch寫入速度的最大因素。但是只有這樣，寫操作才有可能是可靠的，如果系統可以接受一定幾率的數據丟失，調整translog持久化策略為周期性和一定大小的時候flush：

index.translog.durability: async

index.translog.sync_interval: 120s

index.translog.flush_threshold_size: 3gb

index.translog.flush_threshold_period: 120m

1.4 段合并優化

segment merge操作對系統CPU和IO占用都比較高，從es 2.0開始，merge行為不再由es控制，而是轉由lucene控制。有以下調整開關：

index.merge.scheduler.max_thread_count：最大線程數

index.merge.policy.*

最大線程數的默認值為：

Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))

是一個比較理想的值，如果你只有一塊硬盤并且非SSD，應該把他設置為1，因為在旋轉存儲介質上并發寫，由于尋址的原因，不會提升，只會降低寫入速度。

index.merge.policy.floor_segment

該屬性用于阻止segment的頻繁flush，小于此值將考慮優先合并，默認為2M，可考慮適當降低此值，如1M。

index.merge.policy.segments_per_tier

該屬性指定了每層分段的數量，取值越小最終segment越少，因此需要merge的操作更多，可以考慮適當增加此值。默認為10，他應該大于等于10。

index.merge.policy.max_merge_at_once

"merge":{

"scheduler":{

"max_thread_count" : "1"

},

"policy":{

"segments_per_tier" : "20",

"max_merge_at_once": "20",

"floor_segment" : "1m",

"max_merged_segment" : "5g"

}

}

1.5 Indexing Buffer

indexing buffer在為doc建立索引時使用，當緩沖滿時會刷入磁盤，生成一個新的 segment，這是除refresh_interval外另外一個刷新索引，生成新segment的機會。每個 shard有自己的indexing buffer，下面的關于這個buffer大小的配置需要除以這個節點上所有的shard數量。

indices.memory.index_buffer_size

默認為整個堆的10%，如30GB堆內存，約占300M，在大量的索引操作時，可以考慮適當增大，但不要超過20%。

1.6 Bulk請求

1.???????? 使用批量請求，設置合理的數據條數：使用bulk命令進行批量索引數據時，每批次提交的數據大小為5~15MB；比如每條數據大小為1k，那么建議批量提交的數據條數為5000條；當前集群的最佳批量請求大小，可以從5MB開始測試，緩慢增加這個大小，直到寫入性能不能提升為止。

2.???????? 每個批量請求中只處理一個索引的數據：一個bulk請求只寫入一個索引的數據，不建議一個bulk請求同時寫入多個索引的數據，不同索引的數據分多個bulk請求提交。

3.???????? 建立索引的過程偏計算密集型任務，應該使用固定大小的線程池配置，來不及處理的放入隊列，線程數量配置為CPU核心數+1，避免過多的上下文切換。隊列大小可以適當增加，但一定要嚴格控制大小，過大的隊列導致較高的GC壓力，并可能導致FGC頻繁發生。

1.7 磁盤間的任務均衡

如果你的部署方案是為path.data配置多個路徑來使用多塊磁盤， es在分配shard 時，落到各磁盤上的shard可能并不均勻，這種不均勻可能會導致某些磁盤繁忙，利用率達到100%，這種不均勻達到一定程度可能會對寫入性能產生負面影響。

所以建議每個數據實例掛載單塊磁盤。

1.8 節點間的任務均衡

為了在節點間任務盡量均衡，數據寫入客戶端應該把bulk請求輪詢發送到各個節點。

當使用java api ，或者rest api的bulk接口發送數據時，客戶端將會輪詢的發送的集群節點，節點列表取決于：

當client.transport.sniff為true，(默認為 false)，列表為所有數據節點。

否則，列表為初始化客戶端對象時添加進去的節點。

java api的TransportClient和rest api的RestClient都是線程安全的，當寫入程序自己創建線程池控制并發，應該使用同一個Client對象。在此建議使用rest api，兼容性好，只有吞吐量非常大才值得考慮序列化的開銷，顯然搜索并不是高吞吐量的業務。

觀察bulk請求在不同節點上的處理情況，通過cat接口觀察bulk線程池和隊列情況，是否存在不均：

_cat/thread_pool/bulk?v

另外，也可以搭建NGINX服務來達到負載均衡。

1.9 分片均勻分布

配置total_shards_per_node參數，讓分片更加均勻的分布在各個實例上。表示限制每個實例上分布該該索引的分片最大個數，如2，即表示每個實例上最多分布2個該索引的分片。

說明：total_shards_per_node參數值=(索引總分片數/數據實例數) + 1（向上取整）。

1.10 索引過程調整和優化

1.10.1 自動生成doc ID

分析es寫入流程可以看到，寫入doc時如果是外部指定了id，es會先嘗試讀取原來doc的版本號，判斷是否需要更新，使用自動生成doc id可以避免這個環節，從而避免出現在磁盤IOPS能力不足的情況下，磁盤IO被讀IO大量占用，導致寫入速度受限于磁盤IO。

1.10.2 調整字段 Mappings

1.???????? 字段的index屬性設置為： not_analyzed，或者no。對字段不分詞，或者不索引，可以節省很多運算，降低CPU占用。尤其是binary類型，默認情況下占用CPU非常高，而這種類型根本不需要進行分詞做索引。

2.???????? 調整_source字段：_source字段用于存儲doc原始數據，對于部分不需要存儲的字段，可以通過includes excludes來過濾，或者將_source 禁用，一般用于索引和數據分離。

3.???????? 禁用_all字段：_all字段默認是開啟的，其中包含所有字段分詞后的關鍵詞，作用是可以在搜索的時候不指定特定字段，從所有字段中檢索。如果你不需要這個特性，可以禁用_all，可以小幅的降低CPU 壓力，對速度影響并不明顯。

FusionInsight Elasticsearch EI企業智能

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。