Azure 搜索索引器的编程缩放答案

【问题标题】：Programmatic scaling of Azure Search indexersAzure 搜索索引器的编程缩放
【发布时间】：2020-01-18 06:52:46
【问题描述】：

我有由标准 Azure 搜索索引器 + 数据源对索引的 Cosmos DB 集合。并按照文档中的建议使用WHERE _ts > @HighWaterMark inQuery。

有时我需要将索引器从 1 放大/缩小到 N 以加快索引过程。

对于静态扩展，我可以创建 N 对数据源 + 索引器，它们将通过在查询中定义来处理单独的分区或项目子集，例如WHERE indexingGroup = <1..N> AND _ts >= @HighWaterMark

但现在我需要动态扩展这些对。例如，我有 1 个索引器，我想再创建 1 个。我需要更新查询并为第一对添加WHERE indexingGroup = 1，并创建一个新的索引器+数据源，它将使用WHERE indexingGroup = 2处理第二个子集。

因此，我假设第一对将使用之前执行的HighWaterMark 继续处理。而第二个新对将从头开始，因为HighWaterMark 是 0。

是否有机会从数据源/索引器中获取当前的HighWaterMark 值，然后将其设置为另一个？

UPD.1。场景

我们拥有数亿条不同类型的记录。每种类型都有自己的索引器（组）。有时我们会获得大量新数据，因此我们需要扩大规模。因为在 Azure 搜索中存在并行索引器的限制（而且它非常低），所以在我们的测试中我们发现一些索引器永远不会启动，因为旧的索引器不会 24 小时停止。所以这个想法是能够以编程方式平衡索引器计数。
正如我们不久前遇到的那样，现在我们正在试验不同数量的索引器。在我们当前的方法中，我们使用 ID 作为分区键，因此每个分区没有专用的索引器。
一种不常见的（每月+）方案是在有限的时间内索引 200M+ 个项目。为此，我们需要添加最大的索引器，完成索引，然后按比例缩小。之后，我们每天有 10-20M 条记录，每个索引器大约 3M/h 的项目。对于其他类型，我们有要处理的实时数据流（Cosmos DB upsert 吞吐量为 10-100K）。所以主要的平衡是在这个大数据块和流媒体之间。但我们也有非常小的索引器，它们应该在最短的时间内完成（就 Cosmos/Search SLA 功能而言接近实时）

【问题讨论】：

【解决方案1】：

您可以从索引器的最后一次完成运行中获取高水位线值 finalTrackingState 在索引器执行结果上。该值只能通过 Indexer Reset 清除，不能设置为特定值。但是，您可以通过创建或重置索引器然后将数据源查询更改为也包括高水位线值来实现从特定高水位线运行的相同效果，例如：

WHERE indexingGroup = <1..N> AND _ts >= @HighWaterMark AND _ts >= _LiteralAsCInt64(1579295473)

如果您这样做，您需要记住在重置索引器时从查询中删除此值，如果您希望它从头开始。此外，在缩小时，请务必使用每个索引器的最小 finalTrackingState，以确保您不会错过任何文档。

我是 Azure 认知搜索团队的一员，想详细了解您的方案。几个问题。

【讨论】：

感谢您的回复。用答案更新了原始帖子。我说得对吗？我们可以从最近的任何索引器执行中获取finalTrackingState 并将其用作@HighWaterMark >= finalTrackingState-result-string？
字符串的语法将根据您的数据源和索引器配置而有所不同，并且将来可能会发生变化，但是是的。