另外關(guān)于第三點 “增大 threadpool.index.queue_size” 應(yīng)該也是沒有用的
索引時的并發(fā)量是跟shard的數(shù)量對應(yīng)的杏慰,但是不會超過本機(jī)的cpu 核的個數(shù)测柠。
因為es里面不管是BULK, 還是INDEX的threadPool炼鞠,線程數(shù)都是fix的,即availableProcessors(貌似可以通過配置手動修改轰胁,沒設(shè)默認(rèn)就是機(jī)器的cpu核數(shù)谒主,且不超過32)
而這個threadpool.index.queue_size,只不過是線程池等待任務(wù)隊列的大小赃阀。默認(rèn)50霎肯,若索引時es消化不過來,這個等待任務(wù)超過了隊列大小榛斯,es會直接拒絕請求观游,拋出EsRejectException。
如何提高ElasticSearch 索引速度我Google了下驮俗,大致給出的答案如下: 使用bulk API 初次索引的時候备典,把 replica 設(shè)置為 0 增大 threadpool.index.queue_size ...
關(guān)于version這塊提佣,一般是不會影響索引速度的吧。
一般情況下索引數(shù)據(jù)時你是不會自己提供id的荤崇,這時es會為每條數(shù)據(jù)自動生成一個base64 UUID拌屏,而且好像還是字典序上的自增,這個時候記錄索引默認(rèn)是create术荤,這根本就不存在版本沖突和加鎖的問題吧倚喂。
如果你是指索引的meta state的版本號。這個版本號一般只會在發(fā)生了field mapping的更新瓣戚,setting的更新時版本號才會更新端圈。當(dāng)你海量數(shù)據(jù)導(dǎo)入的時候,數(shù)據(jù)的列總不會每條數(shù)據(jù)都不一樣吧子库?所以這個版本號也是不會頻繁更新的舱权。
不知道我有沒有理解正確你的意思?
如何提高ElasticSearch 索引速度我Google了下仑嗅,大致給出的答案如下: 使用bulk API 初次索引的時候宴倍,把 replica 設(shè)置為 0 增大 threadpool.index.queue_size ...