保障集合正常运行的前提下，Algolia全量重建索引的最优方案

当前每日全量重建流程 #

我们每日执行一项全量重建所有30个索引的任务，每个索引的处理流程如下：

• 将参考索引x的配置复制到x_tmp
• 并行调用5次pushByIndexName服务（Ingestion API，由Mulesoft编排，无直接调用客户端），每次添加40个对象（确保payload不超过5MB）——总计约1200个对象需调用约60次
• 轮询每个响应的任务ID以检查状态

所有任务完成后，再处理下一个索引。此流程可使集合连接器在推送数据后自动工作，确保Merchandise Studio的所有内容保持一致。但这些索引规模较大（每条记录包含所有同类产品属性的一个小子集），因此每个索引处理耗时约30分钟（经Algolia日志确认，最后一次集合更新在原始索引复制到tmp后约30分钟触发）。

可行优化方案 #

方案1：分块推送（chunkedPush） #

• 借助官方提供的分块推送能力，无需手动关注payload大小限制，也可通过chunkedPush实现完全控制
• 注意：使用连接器后无法直接通过indexName操作，需维护推送任务ID映射，此问题可解决

方案2：改用saveObjects方式 #

• 尽管push是预索引转换的推荐方式，但saveObjects支持更大的payload

疑问与后续计划 #

• 疑问：假设已为集合映射所有推送任务ID，在推送数据完成后能否触发任务？
• 后续计划：将采用支持对应SDK的技术（优先TypeScript，也考虑Quarkus或Laravel容器）重新实现该任务，以充分利用相关自动化与优化能力

内容的提问来源于stack exchange，提问作者Sampgun