ElasticSearch 中理想的散装尺寸公式是什么？答案

【问题标题】：What is the ideal bulk size formula in ElasticSearch?ElasticSearch 中理想的散装尺寸公式是什么？
【发布时间】：2021-07-30 00:38:53
【问题描述】：

我相信应该有一个公式来计算 ElasticSearch 中的批量索引大小。大概下面就是这样一个公式的变量。

节点数
分片/索引数
文档大小
内存
磁盘写入速度
局域网速度

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

【问题讨论】：

标签： elasticsearch elasticsearch-bulk-api

【解决方案1】：

阅读 ES bulk API doc：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 url
尽可能删除数据中多余的空格
禁用搜索索引更新，稍后再激活
跨所有数据节点的循环法

【讨论】：

【解决方案2】：

这没有黄金法则。摘自文档：

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

【讨论】：

最终，确实需要调整。但是有什么数量级的想法吗？我们是在说 10s / 100s / 1000s 吗？有什么入门建议可以参考吗？

【解决方案3】：

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

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

【讨论】：

这听起来有点保守，我已经通过 http api 运行索引作业，批量大小为 10k 文档（文件在 ~25M 和 ~80MB 之间），在一个适度的 vServer 上
非常保守。但是，您无法通过实际集群上的实际数据进行测试来确定理想的设置。如今（5 年后），我们拥有一个更大、更强大的集群，使用 MB 为单位的更大批量，没有文档限制。

【解决方案4】：

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

关注批量请求的物理大小通常很有用。一千个 1KB 的文档与一千个 1MB 的文档有很大的不同。一个好的大容量大小是 5-15MB 左右

【讨论】：

这听起来有点保守（可能是我的意图），我在一个适度的 vServer 上运行批量大小为 10k 文档（文件介于 ~25M 和 ~80MB 之间）的索引作业（更多信息见下文）。

【解决方案5】：

就我而言，一次插入的记录不能超过 100,000 条。从1300万开始，降到50万，没有成功后，从另一边开始，1000，然后10,000，然后100,000，我的最大值。

【讨论】：

【解决方案6】：

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

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

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

我可以通过 http bulk api (curl) 使用 10k 个文档（20k 行，文件大小在 25MB 到 79MB 之间）的批处理大小成功索引大小差异很大的文档，每个批处理需要大约 90 秒。 index.refresh_interval 在索引期间设置为 -1，但这是我所做的唯一“调整”，所有其他配置都是默认配置。我想这主要是因为索引本身并不太复杂。

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

【讨论】：

【解决方案7】：

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

摘自link

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

【讨论】：