Partager via

Choisir le nombre de partitions dans Azure Cosmos DB for PostgreSQL

  • Article

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

Le choix du nombre de partitions pour chaque table distribuée est un compromis entre la flexibilité d’avoir plus de partitions et la surcharge liée à la planification et à l’exécution des requêtes sur ces partitions. Si vous décidez de modifier le nombre de partitions d’une table après la distribution, vous pouvez utiliser la fonction alter_distributed_table.

Cas d’usage SaaS multilocataire

Le choix optimal varie en fonction de vos modèles d’accès aux données. Par exemple, dans le cas d’usage d’une base de données SaaS multilocataire, nous vous recommandons de choisir entre 32 et 128 partitions. Pour les charges de travail plus petites, par exemple de <100 Go, vous pouvez commencer avec 32 partitions et pour les charges de travail plus volumineuses, vous pouvez choisir 64 ou 128 partitions. Ce choix vous donne la marge de manœuvre nécessaire pour passer de 32 à 128 machines Worker.

Cas d’usage de l’analytique en temps réel

Dans le cas d’usage de l’analytique en temps réel, le nombre de partitions doit être lié au nombre total de cœurs sur les Workers. Pour garantir un parallélisme maximal, vous devez créer suffisamment de partitions sur chaque nœud de sorte qu’il y ait au moins une partition par cœur de processeur. Nous vous recommandons généralement de créer un nombre élevé de partitions initiales, par exemple 2 ou 4 fois le nombre de cœurs de processeur actuels. Le fait d’avoir plus de partitions permet une mise à l’échelle ultérieure si vous ajoutez d’autres Workers et cœurs de processeur.

N’oubliez pas que, pour chaque requête, Azure Cosmos DB for PostgreSQL ouvre une seule connexion de base de données par partition, et que ces connexions sont limitées. Veillez à garder le nombre de partitions suffisamment petit pour que les requêtes distribuées n’aient pas souvent à attendre une connexion. Autrement dit, les connexions nécessaires, (max concurrent queries * shard count), ne doivent pas dépasser le nombre total de connexions possibles dans le système, (number of workers * max_connections per worker).

Étapes suivantes