Программирование c масштабирование Azure Поиск по индексаторам

Question

У меня есть коллекции Cosmos DB, которые проиндексированы стандартными парами Azure Search indexer + datasource. И используя WHERE _ts > @HighWaterMark inQuery, как рекомендуется в документах.

Время от времени мне нужно увеличивать / уменьшать индексаторы с 1 до N, чтобы ускорить процесс индексирования.

Для сведения c масштабирование Я могу создать N пар источника данных + индексатор, который будет обрабатывать отдельный раздел или подмножество элементов, определенных в Query, например WHERE indexingGroup = <1..N> AND _ts >= @HighWaterMark

Но теперь мне нужно динамически масштабировать такие пары. Например, у меня есть 1 индексатор, и я хочу создать еще 1. Мне нужно обновить запрос и добавить WHERE indexingGroup = 1 для 1-й пары и создать новый индексатор + источник данных, который будет обрабатывать второе подмножество с WHERE indexingGroup = 2.

В результате 1-я пара, я полагаю, будет продолжить обработку, используя HighWaterMark из предыдущего выполнения. В то время как 2-я новая пара будет начинаться с нуля, потому что HighWaterMark равен 0.

Есть ли шанс получить текущее значение HighWaterMark из источника данных / индексатора, а затем установить его на другое значение?

UPD.1. Сценарий

1. У нас есть сотни миллионов записей разных типов. У каждого типа есть свой индексатор (группа). Иногда мы получаем огромное количество новых данных, поэтому нам нужно расширяться. Поскольку в Azure Search есть ограничение параллельных индексаторов (и оно довольно низкое), в наших тестах мы обнаружили, что некоторые из индексаторов не запускаются, потому что старые не останавливаются в течение 24 часов. Таким образом, идея состоит в том, чтобы иметь возможность сбалансировать счетчики индексов программным путем.

2. Поскольку мы столкнулись с этим не так давно, go, сейчас мы экспериментируем с различным количеством индексаторов. В нашем текущем подходе мы используем ID в качестве ключа раздела, поэтому для каждого раздела нет выделенных индексаторов.

3. Один из редких (ежемесячных +) сценариев ios - индексировать 200M + предметы в ограниченное количество времени. Для этого нам нужно добавить максимум индексаторов, завершить индексацию и уменьшить ее. После этого у нас ежедневно 10-20 миллионов записей за раз с примерно 3M / ч элементов на 1 индексатор. Для других типов у нас есть поток данных для обработки в реальном времени (пропускная способность Cosmos DB составляет 10-100 КБ). Таким образом, основной баланс между большим блоком данных и потоковой передачей. Но также у нас есть очень незначительные индексаторы, которые должны завершаться за минимальное время (почти в режиме реального времени с точки зрения возможностей Cosmos / Search SLA)

Answer 1

Значение максимальной отметки можно получить из последнего завершенного запуска индексатора из finalTrackingState в результате выполнения индексатора. Это значение может быть очищено только от значения через сброс индексатора и не может быть установлено в значение c. Однако вы можете выполнить sh тот же эффект, что и при запуске с заданной c верхней отметки, создав или сбросив индексатор, а затем изменив запрос источника данных, включив в него также значение отметки максимальной отметки, например:

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

Если вы сделаете это, вам нужно помнить об удалении этого значения из запроса при сбросе индексатора, если вы хотите, чтобы он начинался с самого начала. Также при уменьшении обязательно используйте минимальный finalTrackingState каждого из индексаторов, чтобы не пропустить ни одного документа.

Я работаю в команде Azure Cognitive Search и хотел бы узнать больше о ваш сценарий Несколько вопросов.

1. Зачем вам нужно динамически масштабировать индексаторы? (а не всегда с использованием секционированных индексаторов)
2. Как вы определяете значение indexingGroup? (разделите данные)
3. Какая пропускная способность индексирования вам нужна для вашего сценария? (верхняя граница числа секционированных индексаторов)