Согласно документации, соединитель фабрики данных v2 для cosmos db использует библиотеку массового исполнителя .
Операция копирования фабрики данных имеет параметры "Единица интеграции данных", "Степень параллелизма копирования" и "Размер пакета записи".
Я экспериментирую с поиском оптимальных настроек, так как я 'Я уверен, что зависит от размера данных, строк и т. д., но я хочу понять, что они означают в этом контексте.
Когда установлено значение auto;«Единица интеграции данных» и «Степень параллелизма копирования», по-видимому, установлены на 4. Конечно, я уверен, что это зависит от предоставляемых RU / s и т. Д. И т. Д. Я также читал, что реляционные подобные сервисы в любом случае игнорируют параллелизм, ноЯ не уверен, подходит ли CosmosDB к этой скобке.
Степень параллелизма копирования
При чтении рекомендаций по производительности предполагается, что для каждого приложения создается единственный BulkExecutor, что противоречит моему пониманию «Степенипараллелизм копирования ".
Я думал, что" Степень параллелизма копирования "- это количество потоков, то есть количество порожденных BulkExecutor.Принимая во внимание, что рекомендации звучат так, как будто BulkExecutor будет управлять своими собственными потоками.Если это на самом деле не параметр maxConcurrencyPerPartitionKeyRange?
Размер пакета записи, по-видимому, используется, при мониторинге пакетов я вижу весь набор данных, считанный из источника, и пакеты, записываемые в место назначения.Однако, похоже, что BulkExecutor оптимально обрабатывает пакетирование внутри, должен ли размер пакета быть 0 или, может быть, очень большим?Или это может привести к проблемам с памятью на единицах интеграции (Azure или Self-Hosted)?
Кроме того, я предполагаю, что массовый исполнитель, когда фабрика данных установлена пустой для тайм-аута записи, будет повторяться бесконечно во время перегрузки или будетумереть в какой-то момент?