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.
Un cluster a cinq types de tables. Chaque type stocke les données différemment sur les nœuds et sert des objectifs différents.
Tables distribuées
Le premier type (le plus courant) est celui des tables distribuées. Elles ressemblent à des tables normales pour les requêtes SQL, mais sont partitionnées horizontalement entre les nœuds de travail. Ce partitionnement signifie que les lignes des tables sont stockées sur différents nœuds dans des tables de fragments appelées partitions.
Les clusters élastiques exécutent non seulement des instructions SQL, mais également DDL (Data Definition Language) dans un cluster. Lorsque vous modifiez le schéma d’une table distribuée, la modification est répercutée afin de mettre à jour tous les fragments (shards) de la table sur les nœuds de calcul. Vous devez effectuer ces opérations via une connexion sur 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 stockée dans un seul fragment (shard). Le cluster réplique la partition 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 les partitions distinctes par ligne.
Les tables de référence sont généralement petites et stockent des données pertinentes pour les requêtes s’exécutant 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 administratives qui ne participent pas à des requêtes de jointure constituent de bonnes candidates pour les 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, vous pouvez créer manuellement des tables gérées localement en exécutant la citus_add_local_table_to_metadata fonction sur des tables locales régulières. 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 en tant que locales dans l’affichage citus_tables .
Tables de schéma
Lorsque vous utilisez le partitionnement basé sur des schémas, le système associe automatiquement des schémas distribués à des groupes de colocalisation individuels. Lorsque vous créez des tables dans ces schémas, le système les convertit automatiquement en tables distribuées colocalisées sans clé de partition. Ces tables sont des tables de schéma et apparaissent en tant que schéma dans la citus_tables vue.