Выбор количества сегментов в Azure Cosmos DB для PostgreSQL

Это важно

Azure Cosmos DB для PostgreSQL больше не поддерживается для новых проектов. Не используйте эту службу для новых проектов. Вместо этого используйте одну из этих двух служб:

• Используйте Azure Cosmos DB для NoSQL как распределенное решение базы данных, предназначенное для крупномасштабных сценариев с соглашением об уровне доступности (SLA) 99.999%, мгновенным автомасштабированием и автоматическим переключением в случае отказа в нескольких регионах.

• Используйте функцию эластичных кластеров Базы данных Azure для PostgreSQL для сегментированного PostgreSQL с помощью расширения Citus с открытым кодом.

Выбор количества сегментов для каждой распределенной таблицы — это баланс между гибкостью наличия большего количества сегментов и затратами на планирование запросов и их выполнение. Если вы решите изменить количество сегментов таблицы после распространения, можно использовать функцию alter_distributed_table .

Вариант использования SaaS с несколькими клиентами

Оптимальный выбор зависит от шаблонов доступа для данных. Например, в варианте использования базы данных SaaS с несколькими клиентами рекомендуется выбрать от 32 до 128 сегментов. Для небольших рабочих нагрузок 100 ГБ можно начать с 32 сегментов <и для больших рабочих нагрузок можно выбрать 64 или 128. Этот выбор дает вам возможность масштабирования от 32 до 128 рабочих машин.

Вариант использования аналитики в режиме реального времени

В аналитике в реальном времени количество шардов должно быть связано с общим числом ядер на рабочих узлах. Чтобы обеспечить максимальное параллелизм, необходимо создать достаточно сегментов на каждом узле, чтобы на каждом узле было по крайней мере один сегмент на ядро ЦП. Обычно рекомендуется создавать большое количество начальных сегментов, например 2x или 4x количество текущих ядер ЦП. При добавлении дополнительных рабочих ролей и ядер ЦП позволяет в будущем масштабироваться.

Помните, что для каждого запроса Azure Cosmos DB для PostgreSQL открывает одно подключение к базе данных на сегмент и что эти подключения ограничены. Будьте осторожны, чтобы количество сегментов было достаточно небольшим, чтобы распределенные запросы не часто должны ждать подключения. Поместите другой способ, необходимые подключения, (max concurrent queries * shard count)не должны превышать общее количество подключений, возможных в системе. (number of workers * max_connections per worker)

Следующие шаги

• Дополнительные сведения о параметрах производительности кластера.
• Увеличение размера кластера или его расширение
• Перебалансирование сегментов