索引文档的最佳批量大小取决于三个关键因素：系统资源、文档复杂性和性能要求。没有通用的值，因为每个应用程序都有不同的约束。一个好的起点是测试 100 到 1,000 个文档之间的批次，然后根据系统的行为进行调整。较小的批次减少内存使用并使错误处理更容易，但可能会增加来自频繁网络或磁盘操作的开销。较大的批次提高了吞吐量，但有耗尽内存或导致超时的风险。例如，索引 500 篇纯文本文章可能会在一个批次中顺利进行，但 50 个高分辨率图像 PDF 可能会压垮同一个系统。
要确定合适的批量大小，请在索引期间监视系统的资源使用情况和延迟。内存分析器或数据库查询分析器等工具可以帮助识别瓶颈。如果 CPU 使用率飙升且延迟增加，请减小批量大小。如果系统未得到充分利用（例如，CPU 或网络活动较低），请尝试更大的批次。例如，使用 Elasticsearch 的 Bulk API 的开发人员可能从 1,000 个文档的批次开始，但由于 Java 堆压力而注意到响应缓慢。将每个批次减少到 500 个文档可以解决此问题。同样，具有自动缩放功能的基于云的服务可能在非高峰时段处理更大的批次，但在流量高峰时段需要更小的批次，以避免限制。
实际示例也取决于索引管道的设计。需要低延迟的实时应用程序（例如，聊天消息搜索）可能会使用 10-50 个文档的批次来最大限度地减少延迟。相比之下，大型 CMS 的夜间备份作业可以处理 10,000 个文档的批次而没有问题。工具通常提供指导：Elasticsearch 建议每个批量请求 1,000-5,000 个文档，而 PostgreSQL 的 COPY 命令可以处理数百万行，但最好使用 10,000 个以下的批次以避免事务锁定。始终使用类似生产的数据和负载进行测试，并为失败的批次构建重试逻辑——较小的批次使重试成本更低。