在Elasticsearch中增加Scroll API的大小時應考慮哪些因素？

Question

我目前正在使用Elasticsearch的Scroll API ，並希望使用它來獲取大量數據並對其進行一些手動處理。 該處理由外部庫執行，並且不屬於可以輕易包含為腳本的類型 。

盡管目前看來這很好，但是我想知道在微調滾動尺寸以執行這種形式的處理時應考慮哪些注意事項。 快速觀察似乎表明增加滾動大小將減少操作的等待時間。 盡管我懷疑較大的滾動條通常會降低吞吐量，但我不知道這種假設是否正確。 另外，我不知道是否有其他后果我現在沒有想到。

因此，總而言之，我的問題是：在為獲得的每個批次處理結果的情況下，更改Elasticsearch的滾動大小會產生什么影響，特別是對性能有何影響？

提前致謝！

Answer 1

一個（也是我唯一知道的）考慮因素是能夠足夠快地處理批處理，而不會釋放滾動上下文（由?scroll=X參數控制）。

假設您將使用查詢中的所有數據，則應根據網絡和第三方應用程序的性能來調整滾動。 即

• 如果您的應用程序可以以類似流的方式處理數據，則越大的塊越好
• 如果您的應用程序分批處理數據（首先等待完整的ES響應），則批處理大小的上限應保證處理時間<滾動釋放時間
• 如果您在較差的網絡環境中工作，則較小的批處理大小會更好地處理丟失的連接/重試的開銷
• 通常，較大的批次顯然更好，因為它消除了一些網絡/ ES cpu開銷