更新嵌套場數以百萬計的文檔

我爲了更新嵌套字段使用批量更新腳本，但這是非常緩慢：更新嵌套場數以百萬計的文檔

POST index/type/_bulk 

{"update":{"_id":"1"}} 
{"script"{"inline":"ctx._source.nestedfield.add(params.nestedfield)","params":{"nestedfield":{"field1":"1","field2":"2"}}}} 
{"update":{"_id":"2"}} 
{"script"{"inline":"ctx._source.nestedfield.add(params.nestedfield)","params":{"nestedfield":{"field1":"3","field2":"4"}}}} 

... [a lot more splitted in several batches]

你知道另一種方式，可能會更快？

似乎可以存儲腳本以便不對每次更新重複它，但我找不到保留「動態」參數的方法。

來源

2017-10-18 eli0tt

恐怕有一個解決這個問題的方法。 –

@ eli0tt請您澄清幾個問題。您是否每次插入新的任意數據（更新時）？目前進程有多快？什麼是（大致）您的索引大小：記錄數，磁盤大小？你多久做一次這樣的更新（數百萬嵌套文檔）？你可以使用['_reindex']（https://www.elastic.co/guide/en/elasticsearch/reference/5.5/docs-reindex.html）嗎？謝謝！ –

我的索引有~11M個文檔（3.6G）。我需要做一次大的更新，其中包括將記錄添加到現有文檔中相同的嵌套字段。數據是任意的。有些文檔不需要更新，有些需要在嵌套字段中更新〜1-3條新記錄。所需更新的總數是~12M。我從數據中以批量格式生成文件，就像您在我的文章中看到的一樣。更新的執行似乎需要數天...（即使存儲了我也嘗試過的腳本）。謝謝！ – eli0tt

與性能優化問題一樣，沒有單一的答案，因爲有很多可能的原因表現不佳。

在您的情況下，您正在製作批量update請求。當執行update，該文件是actually being re-indexed：

...更新文件是檢索它，改變它，然後重新索引整個文件。

因此有必要看看indexing performance tuning tips。在你的情況下，我會考慮的前幾件事是選擇正確的批量大小，使用多個線程批量請求和增加/禁用indexing refresh interval。

您也可以考慮使用支持並行批量請求的現成客戶端，如Python elasticsearch client。

這將是理想的監控ElasticSearch性能指標，以瞭解瓶頸在哪裏，以及您的性能調整是否給予實際收益。 Here是關於ElasticSearch性能指標的概述性博客文章。

來源

2017-10-21 08:07:41

更新嵌套場數以百萬計的文檔

回答

相關問題