我相信应该有一个公式来计算 ElasticSearch 中的批量索引大小。可能以下是这样一个公式的变量。
- 节点数
- 分片数/索引
- 文档大小
- 内存
- 磁盘写入速度
- 局域网速度
我想知道是否有人知道或使用数学公式。如果没有，人们如何决定他们的体积大小？通过反复试验？
问问题
31801 次
7 回答
9
这没有黄金法则。从文档中提取：
在单个批量调用中没有要执行的“正确”数量的操作。您应该尝试不同的设置以找到适合您特定工作负载的最佳大小。
于 2013-08-28T13:57:54.177 回答
9
仔细阅读ES bulk 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 url
- 如果可能，删除数据中多余的空格
- 禁用搜索索引更新，稍后再激活
- 跨所有数据节点的循环
于 2016-11-08T10:34:50.413 回答
7
我从 Java API 的 BulkProcessor 类中获得了这些信息。它默认为 1000 个操作或 5MB，它还允许您设置刷新间隔，但默认情况下未设置。我只是使用默认设置。
如果您使用的是 Java API，我建议您使用 BulkProcessor。
于 2013-11-25T15:05:44.807 回答
5
我正在搜索它，我发现了你的问题 :) 我在弹性文档中找到了这个 .. 所以我会调查我的文档的大小。
密切关注批量请求的物理大小通常很有用。一千个 1KB 的文档与一千个 1MB 的文档有很大的不同。开始使用的一个好的大容量大小约为 5-15MB
于 2016-03-28T09:55:57.407 回答
3
就我而言，一次插入的记录不能超过 100,000 条。从 1300 万开始，下降到 500,000，没有成功后，从另一边开始，1,000，然后 10,000，然后 100,000，我的最大值。
于 2019-08-21T01:08:03.383 回答
1
我没有找到比试错法（即传统的工程过程）更好的方法，因为除了硬件之外还有许多因素会影响索引速度：索引的结构/复杂性（复杂的映射、过滤器或分析器）、数据类型、您的工作负载是 I/O 还是 CPU 密集型，等等 。
无论如何，为了展示它的可变性，我可以分享我的经验，因为它似乎与这里发布的大多数不同：
具有 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 和 4GB RAM，因此我可以通过并行发送两个文件来加快速度（我尝试简单地将批处理大小增加 50%，但开始获得错误），但在那之后，考虑不同的 API 或简单地将负载分散到集群上可能更有意义。
于 2018-11-12T22:15:36.257 回答
0
实际上，没有明确的方法可以找出批量更新的确切上限。在批量更新中要考虑的一个重要因素是请求数据量不仅仅是没有。文件
链接摘录
多大才算太大？
整个批量请求需要被接收到我们请求的节点加载到内存中，所以请求越大，其他请求可用的内存就越少。有一个批量请求的最佳大小。超过该大小，性能不再提高，甚至可能下降。然而，最佳尺寸并不是一个固定的数字。这完全取决于您的硬件、文档大小和复杂性，以及您的索引和搜索负载。
幸运的是，很容易找到这个最佳点：尝试以越来越大的批量索引典型文档。当性能开始下降时，你的批量太大了。一个好的起点是批量处理 1,000 到 5,000 个文档，或者，如果您的文档非常大，则批量更小。
密切关注批量请求的物理大小通常很有用。一千个 1KB 的文档与一千个 1MB 的文档有很大的不同。开始使用的大容量大小约为 5-15MB。
于 2021-07-29T16:33:39.320 回答