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.
Il existe cinq types de tables dans un cluster, chacune stockée différemment sur des nœuds et utilisée à différentes fins.
Tables distribuées
Le premier type (le plus courant) est celui des tables distribuées. Elles ressemblent à des tables normales pour les instructions SQL, mais sont partitionnées horizontalement dans les nœuds worker. Cela signifie que les lignes des tables sont stockées sur différents nœuds, dans des tables fragmentées appelées Partitions.
Les clusters élastiques exécutent non seulement des instructions SQL mais DDL (Data Definition Language) dans un cluster. La modification du schéma d’une table distribuée a pour effet en cascade de mettre à jour toutes les partitions de table des Workers. Ces opérations doivent être effectuées avec une connexion via le port 5432.
Colonne distribuée
Les clusters élastiques utilisent le partitionnement algorithmique pour affecter des lignes à des partitions. L’affectation est effectuée de façon déterministe en fonction de la valeur d’une colonne de table appelée colonne de distribution. L’administrateur de cluster doit désigner cette colonne lors de la distribution d’une table. Il est important pour les performances et les fonctionnalités de faire le bon choix.
Tables de référence
Une table de référence est un type de table distribuée dont l’intégralité du contenu est concentré dans une seule partition. La partition est répliquée sur chaque Worker. Les requêtes sur un Worker peuvent accéder localement aux informations de référence, sans surcharger le réseau en demandant des lignes d’un autre nœud. Les tables de référence n’ont pas de colonne de distribution, car il n’est pas nécessaire de distinguer des partitions différentes par ligne.
Les tables de référence sont généralement petites et servent à stocker des données qui s’appliquent aux requêtes en cours d’exécution sur n’importe quel nœud Worker. C’est, par exemple, le cas des valeurs énumérées telles que les états de commande ou les catégories de produits.
Tables locales
Lorsque vous utilisez un cluster élastique, chaque nœud est une base de données PostgreSQL standard. Vous pouvez créer des tables ordinaires sur elles et choisir de ne pas les partitionner.
Les petites tables d’administration qui ne font pas partie de requêtes de jointure font d’excellentes tables locales. C’est, par exemple, le cas d’une table users pour l’authentification et la connexion à l’application. Ce type de table est utile uniquement lorsque vous ne prévoyez pas d’équilibrer la charge de votre connexion entre un cluster élastique à l’aide du port 7432 ou 8432.
Tables managées locales
Les clusters élastiques peuvent automatiquement ajouter des tables locales aux métadonnées si une référence de clé étrangère existe entre une table locale et une table de référence. En outre, les tables managées localement peuvent être créées manuellement en exécutant citus_add_local_table_to_metadata fonction sur des tables locales normales. Les tables présentes dans les métadonnées sont considérées comme des tables managées et peuvent être interrogées à partir de n’importe quel nœud. Citus sait acheminer vers le nœud pour obtenir des données à partir de la table managée locale. Ces tables sont affichées comme locales en mode citus_tables.
Tables de schéma
Avec le partitionnement basé sur le schéma, les schémas distribués sont automatiquement associés à des groupes de colocation individuels. Les tables créées dans ces schémas sont automatiquement converties en tables distribuées colocalisées sans clé de partition. Ces tables sont considérées comme des tables de schémas et sont affichées en tant que schéma dans la vue citus_tables.