Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les clusters élastiques sur le service Azure Database pour PostgreSQL sont une offre managée de l’extension Citus open source à PostgreSQL qui permet le partitionnement horizontal de PostgreSQL.
Bien que Citus ne soit qu’une extension, elle permet de connecter plusieurs instances PostgreSQL. Lorsque vous déployez un serveur flexible Azure Database pour PostgreSQL avec Citus, il gère la gestion et la configuration de plusieurs instances PostgreSQL en tant que ressource unique. Il configure également automatiquement les nœuds et en informe l’extension Citus.
Les clusters élastiques sur le service offrent deux modèles de partitionnement : le partitionnement basé sur les lignes et le partitionnement basé sur le schéma. Pour en savoir plus, consultez la documentation open source sur les modèles de partitionnement.
Architecture
Un cluster élastique se compose d’un ou plusieurs nœuds de serveurs flexibles Azure Database pour PostgreSQL. Ces instances se découvrent automatiquement et s’interconnectent pour former un cluster Citus. Les nœuds doivent être du même niveau de calcul et de stockage, et vous pouvez les faire évoluer uniformément vers des niveaux supérieurs ou inférieurs.
Les clusters élastiques utilisent des instances de serveurs flexibles (appelés nœuds) pour se coordonner entre eux dans une architecture « partagé rien ». L’architecture permet également de mettre à l’échelle la base de données en ajoutant des nœuds supplémentaires au cluster.
Les clusters élastiques utilisent des serveurs flexibles (appelés nœuds) pour coordonner les uns avec les autres dans une architecture partagée sans rien . L’architecture permet également à la base de données de mettre à l’échelle en ajoutant des nœuds supplémentaires au cluster.
Contrairement à Cosmos DB pour PostgreSQL, les adresses des nœuds ne sont pas exposées en externe. Si vous consultez les tableaux de métadonnées Citus tels que pg_dist_node, vous remarquerez peut-être que tous les nœuds ont la même adresse IP, comme dans l’exemple 10.7.0.254, mais des ports différents.
select nodeid, nodename, nodeport from pg_dist_node;
nodeid | nodename | nodeport
--------+------------+----------
1 | 10.7.0.254 | 7000
2 | 10.7.0.254 | 7001
(2 rows)
Dans l’infrastructure Azure, ces nœuds se trouvent sur des machines virtuelles différentes, même s’ils semblent se trouver sur des ports différents de la même machine.
Pour en savoir plus sur Citus, consultez la documentation officielle du projet open source.
Par défaut, les tables et les schémas créés avec Citus ne sont pas automatiquement distribués dans le cluster. Vous devez choisir un modèle de partitionnement et décider si vous souhaitez distribuer des schémas ou si vous souhaitez distribuer les données de vos tables avec un partitionnement basé sur les lignes.
Pour chaque requête sur des tables distribuées, le nœud interrogé l’achemine vers un nœud unique ou le parallélise sur plusieurs nœuds. La décision varie selon que les données requises se trouvent sur un nœud unique ou sur plusieurs. Avec le partitionnement basé sur les schémas, le coordinateur achemine les requêtes directement vers le nœud qui héberge le schéma. En cas de partitionnement basé sur un schéma ou de partitionnement basé sur les lignes, le nœud décide de l’action à effectuer en consultant les tables de métadonnées. Ces tables effectuent le suivi de l’emplacement et de l’intégrité des nœuds, ainsi que la distribution des données entre les nœuds.
Une fois les données distribuées à l’aide de l’un des modèles de partitionnement, vous pouvez vous connecter au nœud de votre choix pour effectuer des opérations DML (Data Modification Language) telles que SELECT, UPDATE, INSERT, DELETE. Tous les nœuds contiennent les métadonnées nécessaires pour localiser les données requises par la requête et peuvent les obtenir pour y répondre.
Les opérations DDL (Data Definition Language) et les opérations à l’échelle du cluster sont actuellement limitées au nœud qui joue le rôle de coordinateur. Effectuez des opérations DDL et à l’échelle du cluster en vous connectant au port 5432 plutôt que d’utiliser le port 7432.
Vous pouvez effectuer un scale-out d’un cluster élastique en ajoutant de nouveaux nœuds et en rééquilibrant les données. Le rééquilibrage est une opération en ligne qui ne bloque pas l’exécution des charges de travail.
Partitions
La section précédente décrivait la façon dont les tables distribuées sont stockées en tant que partitions sur les nœuds worker. Cette section décrit plus de détails techniques sur ces partitions.
La table de métadonnées pg_dist_shard contient une ligne pour chaque partition de chaque table distribuée dans le système. La ligne correspond à un identificateur de partition (shardid) avec une plage d’entiers dans un espace de hachage (shardminvalue, shardmaxvalue).
SELECT * from pg_dist_shard;
logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
github_events | 102026 | t | 268435456 | 402653183
github_events | 102027 | t | 402653184 | 536870911
github_events | 102028 | t | 536870912 | 671088639
github_events | 102029 | t | 671088640 | 805306367
(4 rows)
Si le nœud coordinateur souhaite déterminer quelle partition héberge une ligne de github_events, il hachera la valeur de la colonne de distribution dans la ligne. Ensuite, le nœud vérifie quelle plage de la partition contient la valeur hachée. Les plages sont définies de sorte que l’image de la fonction de hachage soit leur union disjointe.
Placements de partition
Supposons que la partition 102027 est associée à la ligne en question. La ligne est lue ou écrite dans une table appelée github_events_102027 dans un des Workers. En utilisant les informations stockées dans les tables de métadonnées, l’extension détermine quel worker spécifique utiliser. Le mappage de partition au Worker est appelé positionnement de partition.
Le nœud coordinateur réécrit les requêtes en fragments qui font référence à des tables spécifiques, telles que github_events_102027, et exécute ces fragments sur les Workers appropriés. Voici un exemple d’une requête exécutée en arrière-plan pour rechercher la partition contenant le nœud avec l’identifiant 102027.
SELECT
shardid,
node.nodename,
node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
ON placement.groupid = node.groupid
AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;
┌─────────┬───────────┬──────────┐
│ shardid │ nodename │ nodeport │
├─────────┼───────────┼──────────┤
│ 102027 │ localhost │ 5433 │
└─────────┴───────────┴──────────┘