ElasticSearch中理想的批量大小公式是什么？

Question

我认为应该有一个公式来计算ElasticSearch中的批量索引大小。可能以下是这种公式的变量。

• 节点数
• 分片数/索引
• 文件大小
• RAM
• 磁盘写入速度
• LAN速度

我想知道是否有人知道或使用数学公式。如果没有，人们如何决定他们的体积？通过反复试验？

Answer 1

这没有黄金法则。摘自doc：

  

单个批量调用中没有“正确”的操作数。您应该尝试不同的设置，以找到特定工作负载的最佳大小。

Answer 2

我从Java API的BulkProcessor类派生了这些信息。它默认为1000个动作或5MB，它还允许您设置刷新间隔，但默认情况下不设置。我只是使用默认设置。

如果您使用的是Java API，我建议使用BulkProcessor。

Answer 3

仔细阅读 ES 批量API文档：https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html#_using_and_sizing_bulk_requests

• 尝试1 KiB，尝试20 KiB，然后10 KiB，...二分法
• 使用KiB（或同等数量）的批量大小，而不是文档计数！
• 批量发送数据（无流媒体），如果可以
，则传递冗余信息API网址
• 尽可能删除数据中多余的空格
• 禁用搜索索引更新，稍后再将其激活
• 遍历所有数据节点的循环法

Answer 4

我正在搜索它，我找到了你的问题:) 我发现这有弹性documentation ..所以我会调查我的文件的大小。

  

密切关注批量请求的实际大小通常很有用。一千个1KB文件与一千个1MB文件非常不同。开始玩的好体积大小约为5-15MB

Answer 5

就我而言，一次插入的记录数不能超过100,000。从一千三百万开始，下降到五十万，但没有成功，在另一边开始，我先是一千，然后是一万然后是十万。

Answer 6

我没有找到比反复试验（即传统的工程流程）更好的方法，因为除了硬件以外，还有许多因素会影响索引速度：索引的结构/复杂度（复杂映射，过滤器或分析器），数据类型，无论您的工作负载是受I / O还是CPU约束，and so on。

无论如何，为了展示它的可变性，我可以分享我的经验，因为它似乎与大多数发布在这里的有所不同：

Elastic 5.6的10GB堆运行在具有16GB RAM，4个vCPU和搜索时平均为150 MB / s的SSD的单个vServer上。

我可以使用批量大小为1万的文档（2万行，文件大小在25MB到79MB之间）通过http bulk api（curl）成功索引大小各异的文档，每批大约需要90秒。 index.refresh_interval在建立索引期间设置为-1，但这仅是我所做的唯一“调整”，所有其他配置均为默认设置。我猜这主要是由于索引本身不太复杂。

vServer的CPU大约为50％，SSD平均为40 MB / s，没有可用的4GB RAM，因此我可以通过并行发送两个文件来使其更快（我尝试将批处理大小简单地增加50％但开始出现错误），但是在那之后，考虑使用其他API或简单地将负载分散到整个群集可能更有意义。

Answer 7

实际上，没有明确的方法可以找出批量更新的确切上限。批量更新中要考虑的一个重要因素是请求数据量，而不仅仅是数量。文件

摘自link

<块引用>

多大才算太大？
整个批量请求需要由接收我们请求的节点加载到内存中，因此请求越大，其他请求可用的内存就越少。批量请求有一个最佳大小。超过该大小，性能不再提高，甚至可能下降。然而，最佳尺寸并不是一个固定的数字。这完全取决于您的硬件、您的文档大小和复杂性，以及您的索引和搜索负载。
幸运的是，很容易找到这个最佳点：尝试分批增加大小的典型文档。当性能开始下降时，您的批量过大。一个好的起点是批量处理 1,000 到 5,000 个文档，或者，如果您的文档非常大，则使用更小的批次。
密切关注批量请求的物理大小通常很有用。一千个 1KB 的文档与一千个 1MB 的文档大不相同。适合开始使用的批量大小约为 5-15MB。