Autoscaling Azure搜索索引器的编程扩展

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

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

对于静态缩放，我可以创建N对datasource+indexer，它将处理查询中定义的单独分区或项目子集，例如，其中indexingGroup=和_ts>=@HighWaterMark

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

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

是否有机会从datasource/indexer获取当前的HighWaterMark值，然后将其设置为其他值

UPD.1。情景

我们有数亿条不同类型的记录。每种类型都有自己的索引器组。有时我们会得到大量的新数据，因此我们需要扩大规模。因为在Azure Search中，并行索引器的限制非常低，在我们的测试中，我们发现一些索引器从未启动，因为较旧的索引器在24小时内不会停止。因此，我们的想法是能够以编程方式平衡索引器计数

我们不久前就面临这个问题，现在我们正在试验不同数量的索引器。在我们当前的方法中，我们使用ID作为分区键，所以每个分区没有专用的索引器

每月+不常见的场景之一是在有限的时间内索引2亿+个项目。为此，我们需要添加最大数量的索引器，完成索引，并缩小比例。之后，我们每天一次有10-20M的记录，每1个索引器大约有3M/h的项目。对于其他类型，我们需要处理的实时数据流Cosmos DB upsert吞吐量为10-100K。因此，主要的平衡是在这一大块数据和流媒体之间。但我们也有非常小的索引器，就Cosmos/搜索SLA功能而言，这些索引器应该在接近实时的最短时间内完成

---

您可以从 在索引器执行结果上。此值只能通过索引器重置清除值，不能设置为特定值。但是，通过创建或重置索引器，然后将数据源查询更改为也包含高水位线值，可以实现从特定高水位线运行的相同效果，例如：

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

如果要执行此操作，则需要记住在重置索引器时从查询中删除此值（如果希望从头开始）。此外，缩小比例时，请确保使用每个索引器的最小finalTrackingState，以确保不会遗漏任何文档

我是Azure认知搜索团队的成员，希望进一步了解您的场景。有几个问题

为什么需要动态缩放索引器？而不是总是使用分区索引器 您如何确定indexingGroup的价值？对数据进行分区 您的场景需要什么样的索引吞吐量？分区索引器数目的上界

---

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