#azure-cosmosdb #azure-data-factory
Вопрос:
Мы используем набор данных Cosmos в качестве приемника потока данных в нашем конвейере. База данных Cosmos настроена на использование 400 RUs во время обычных операций, но мы увеличиваем ее масштаб во время выполнения конвейера. Масштабирование работает безупречно.
Как и ожидалось, трубопровод потребляет 100% выделенной пропускной способности. Мы хотели бы ограничить это примерно 80%, чтобы наши клиенты не сталкивались с задержками и исключениями из времени ожидания. Согласно документации, параметр «Бюджет пропускной способности записи» в приемнике Cosmos должен быть «Целым числом, представляющим объем, который вы хотите выделить для этой операции записи потока данных, из общей пропускной способности, выделенной для коллекции«. Если я не ошибаюсь, это означает, что вы можете установить ограничение на количество RUs, которое может потреблять конвейер.
Однако независимо от того, какое значение мы используем для «Бюджета пропускной способности записи», конвейер всегда будет потреблять ~10% от общей выделенной пропускной способности. Мы тестировали с широким диапазоном значений, и результат всегда один и тот же. Если мы не задаем значение, потребляется 100% RUs, но ~10% всегда используется, независимо от того, задаем ли мы значение 1, 500, 1000 или даже 1200 (из общей суммы 1000).
Кто-нибудь знает, является ли это ошибкой с приемником ADF Cosmos, или я неправильно понял, какой должна быть эта настройка? Есть ли какой — либо другой способ ограничить количество Cosmos RUs, которое разрешено использовать конвейеру ADF?
ПРАВКА: Это определенно связано с размером данных. Установка выделенной пропускной способности на 10000 RUs и бюджета пропускной способности записи на 7500 использует ~85% от общей пропускной способности при тестировании с 300 000 документами. Используя те же настройки, но 10 000 000 документов, мы видим постоянное использование ~ 10% RU для запуска конвейера.
Ответ №1:
Это будет зависеть от количества разделов. Проверьте, сколько перегородок у вас в раковине.
Комментарии:
1. У нас есть только 1 (физический) раздел. Это не массивная база данных (~5,5 гигабайт), но если это имеет значение, есть 7-10 миллионов документов, в которых мы используем уникальный идентификатор в качестве ключа раздела.
2. Это количество разделов против приемника потока данных. Вы можете увидеть это в подробном мониторинге выполнения потока данных.
3. При выполнении тестового прогона с 20 000 и 300 000 строк в раковине использовались 3 и 4 раздела. Есть ли способ проверить, что он будет использовать с полными 10 000 000 строками? Выполнение полного цикла для этого было бы не оптимальным.
Ответ №2:
Решение нашей проблемы состояло в том, чтобы установить «бюджет пропускной способности записи» на гораздо более высокое значение, чем выделенная пропускная способность. Размер данных и количество разделов, используемых в конвейере, определенно влияют на то, какие настройки вы должны использовать. Для справки у нас было ~10 000 000 документов по 455 байт каждый. Установив пропускную способность на 10 000 и бюджет пропускной способности записи на 60 000, ADF использовал в среднем ~90% выделенной пропускной способности.
Я рекомендую метод проб и ошибок для вашего конкретного случая и не бояться устанавливать бюджет записи на гораздо большее значение, чем вы считаете необходимым.