在Elasticsearch中增加Scroll API的大小时应考虑哪些因素？

Question

我目前正在使用Elasticsearch的Scroll API ，并希望使用它来获取大量数据并对其进行一些手动处理。 该处理由外部库执行，并且不属于可以轻易包含为脚本的类型 。

尽管目前看来这很好，但是我想知道在微调滚动尺寸以执行这种形式的处理时应考虑哪些注意事项。 快速观察似乎表明增加滚动大小将减少操作的等待时间。 尽管我怀疑较大的滚动条通常会降低吞吐量，但我不知道这种假设是否正确。 另外，我不知道是否有其他后果我现在没有想到。

因此，总而言之，我的问题是：在为获得的每个批次处理结果的情况下，更改Elasticsearch的滚动大小会产生什么影响，特别是对性能有何影响？

提前致谢！

Answer 1

一个（也是我唯一知道的）考虑因素是能够足够快地处理批处理，而不会释放滚动上下文（由?scroll=X参数控制）。

假设您将使用查询中的所有数据，则应根据网络和第三方应用程序的性能来调整滚动。 即

• 如果您的应用程序可以以类似流的方式处理数据，则越大的块越好
• 如果您的应用程序分批处理数据（首先等待完整的ES响应），则批处理大小的上限应保证处理时间<滚动释放时间
• 如果您在较差的网络环境中工作，则较小的批处理大小会更好地处理丢失的连接/重试的开销
• 通常，较大的批次显然更好，因为它消除了一些网络/ ES cpu开销