Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
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. Lorsqu’une instance de serveur flexible Azure Database pour PostgreSQL est déployée avec Citus, elle 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. Consultez la documentation open source sur les modèles de partitionnement, si vous souhaitez en savoir plus.
Architecture
Un cluster élastique se compose d’un ou plusieurs nœuds d’instances de serveur flexible Azure Database pour PostgreSQL. Ces instances sont automatiquement reconnues entre elles et connectées pour former un cluster Citus. Les nœuds doivent être du même niveau de calcul et de stockage et peuvent être uniformément mis à l’échelle à 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.
En vous connectant à votre cluster via le port 5432, vous êtes dirigé vers le nœud coordinateur désigné. Les clusters élastiques vous permettent également d’équilibrer la charge des connexions sur le cluster à l’aide d’une méthode de hachage à cinq tuples, si vous vous connectez à l’aide du port 7432. Vous pouvez toujours atterrir au nœud désigné comme coordinateur à l’aide du port 7432. Pour certaines opérations à l’échelle du cluster, telles que la distribution de tables, vous devrez peut-être vous connecter via le port 5432. Nous vous recommandons vivement de vous connecter toujours sur le port 5432 lorsque vous envisagez d’effectuer des mises à niveau de schéma d’application et des modifications similaires. Si vous activez PgBouncer sur des clusters élastiques, vous pouvez utiliser le port 8432 pour équilibrer la charge des connexions entre les instances PgBouncer sur chaque nœud (ou utiliser le port 6432 pour le coordinateur désigné).
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, vous pouvez consulter 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 quel intervalle de fragment 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. Avec les informations stockées dans les tables de métadonnées, l’extension détermine ce Worker spécifique. 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 │
└─────────┴───────────┴──────────┘