我们有一个作业每天对所有索引（共30个）执行一次完整重建，针对每个索引的流程如下：

1. 将参考索引x 的设置复制到x_tmp
2. 对 pushByIndexName 服务进行5 次并行调用（Injestion API，直接调用，无客户端，因为它由Mulesoft编排）以添加40个对象（这让有效载荷保持在5MB的范围内）——总对象约1200个，我大致估算需要60次调用
3. 对每个响应任务ID进行轮询，以检查状态

当所有任务完成后，对后续的索引进行处理。

这个过程使集合连接器在你推送数据后就能自动工作，从而让Merchandise Studio（商品工作室）的一切保持一致。

然而，这些索引往往相当庞大（因为每条记录包含同族产品全部属性中的一个小子集）。 因此每个索引大约需要约30分钟来处理（通过查看Algolia日志确认，最后一次集合更新大约在原始索引复制到tmp后 30分钟左右触发）。

两种可能的方法：

1. 我找到了 这篇页面，它讲述了使用连接器来推送更大数据集而不必担心有效载荷大小（或者通过使用 chunkedPush，你可以实现对整个过程的完全控制）。

当然，如果你涉及连接器，你就不能直接操作indexName，并且需要一个push任务ID的映射表，但这并不成问题。 2.虽然push是允许预索引转换的推荐方法，saveObjects 的做法似乎能够处理更大的有效载荷。

假设要为Collections映射所有push任务ID，如果我已经推送了数据，我还能触发任务吗？

无论选择哪种最佳方案，我都会使用一种技术栈重新实现这个作业（很可能是TypeScript，尽管我也很想用Quarkus或 Laravel的容器），以便可以使用他们的SDK，充分利用该场景中的自动化与优化。

解决方案

直接使用API时，你正在遵循的方法是正确的。如果你想触发一个预索引任务，例如填充Collections所需的任务，通常应该直接调用Ingestion API的端点。

一些澄清：

• API客户端的 chunkedPush 方法本身并不会引入任何特殊的索引行为。它只是将你的记录分成批次，默认为 1,000 条记录，并将每个批次作为一次推送请求发送。
• 不幸的是，即使你跟踪了相关的 taskId，也不可能先使用 saveObjects，再在之后触发Collections任务。由于这是一个预索引转换，必须在记录被索引之前运行。否则，你就有数据被索引到实时索引中，但未正确应用Collections标签的风险。

如果将这个作业迁移到基于SDK的实现（如Algolia的推荐），推荐的做法是：

• 使用 saveObjectsWithTransformation 来新增记录或覆盖现有记录。
• 使用 partialUpdateObjectsWithTransformation 进行增量更新，当只需要更改现有记录的某些属性时。
• 使用 replaceAllObjectsWithTransformation 进行全量重建索引。这个方法会为你创建一个临时索引，索引完成后再与实时索引互换，这基本上与你今天手动实现的模式相同。

关于这些方法还值得注意的几点：

• 只要该索引上没有配置其他预索引连接器，它们会自动应用索引的Collections任务。
• 在底层，它们会使用 [chunkedPush] 将记录分批，当需要时。批量大小可以通过 [WithBatchSize] 选项进行配置。
• 可以通过 [WithWaitForTasks] 选项将它们设为同步。

TL;DR：若你仍然使用直接API调用，那么你当前的模型是正确的。如果你切换到SDK，[replaceAllObjectsWithTransformation] 是日常全量重建流程中最简洁的选项。