PolarDB:Glossaire PolarDB-X

Concept

Description

Région

Zone géographique d'un centre de données où un cluster PolarDB est déployé.

Zone

Zone géographique au sein d'une région. Une zone dispose d'une alimentation électrique et d'un réseau indépendants. La latence réseau entre les instances situées dans la même zone est inférieure à celle entre les instances résidant dans des zones différentes.

Cluster (instance)

PolarDB-X utilise une architecture de cluster multinœud. Un cluster contient plusieurs nœuds de calcul et nœuds de données. Un cluster est également appelé instance.

Nœud de calcul

Les instances PolarDB-X utilisent une architecture de séparation du stockage et du calcul. La couche de calcul se compose de plusieurs nœuds de calcul. Tous les nœuds de calcul sont égaux et possèdent les mêmes spécifications.

Un nœud de calcul comprend des modules tels que l'analyseur SQL, l'optimiseur et l'exécuteur.

Nœud de données

Les instances PolarDB-X utilisent une architecture de séparation du stockage et du calcul. La couche de stockage se compose de plusieurs nœuds de données. Tous les nœuds de données sont égaux et possèdent les mêmes spécifications.

Les nœuds de données assurent la persistance des données et offrent une haute fiabilité ainsi qu'une forte cohérence grâce au protocole Paxos basé sur la majorité.

Nœud de métadonnées

Nœud de gestion des métadonnées d'une instance PolarDB-X. Il enregistre principalement les informations d'état telles que la topologie des tables et fournit des services d'horodatage global.

Capture des modifications de données (CDC)

Le protocole de réplication primaire/secondaire est compatible avec les protocoles et formats de données pris en charge par la journalisation binaire MySQL. La capture des modifications de données (CDC) fournit un protocole de réplication primaire/secondaire compatible avec MySQL et des capacités d'abonnement incrémentiel.

Type d'instance

Configuration des ressources de chaque nœud d'une instance PolarDB-X, par exemple 8 cœurs et 64 Go de mémoire.

Endpoint de cluster

Endpoint unifié en lecture/écriture qui intègre plusieurs nœuds d'une instance. Un endpoint de cluster possède les fonctionnalités suivantes : mise à l'échelle automatique, routage intelligent, répartition lecture/écriture, équilibrage de charge et niveau de cohérence.

Endpoint en lecture seule

Endpoint qui intègre plusieurs nœuds en lecture seule d'une instance pour fournir des services en lecture seule. Un cluster PolarDB-X propose des services en lecture seule avec deux niveaux de cohérence des requêtes : forte cohérence et faible cohérence.

Instance principale

Cluster principal qui fournit les services de base de données. Vous pouvez accéder à l'instance principale via l'endpoint de cluster.

Instance en lecture seule

Les instances en lecture seule fournissent des ressources physiques supplémentaires isolées de l'instance principale afin de réduire la charge de travail de cette dernière. Elles prennent en charge la syntaxe SQL utilisée sur l'instance principale et peuvent partager les mêmes données que les données principales. Les instances en lecture seule simplifient le flux de données dans votre architecture métier et vous dispensent d'une synchronisation supplémentaire des données. Ainsi, vos coûts d'exploitation et de maintenance ainsi que votre budget sont réduits.

Charge de travail

Les charges de travail sont classées en traitement transactionnel (TP) et traitement analytique (AP). Les opérations intra-transactionnelles, les opérations d'écriture et les requêtes simples relèvent des charges de travail TP. Les requêtes complexes relèvent des charges de travail AP.

Routage intelligent

Si vous activez le routage intelligent pour l'endpoint de cluster, les types de charge de travail des requêtes SQL sont identifiés sur la base de statistiques pour acheminer ces requêtes. Par exemple, les requêtes SQL identifiées comme des charges AP sont routées vers les instances en lecture seule.

Répartition lecture/écriture

Si vous activez la répartition lecture/écriture pour l'endpoint de cluster, les opérations sont directement routées vers différentes instances selon le type d'instructions SQL. Par exemple, les opérations intra-transactionnelles et les écritures sont routées vers l'instance principale, tandis que toutes les requêtes sont routées vers les instances en lecture seule.

Niveau de cohérence des requêtes

L'endpoint en lecture seule propose deux niveaux de cohérence des requêtes : forte cohérence et faible cohérence.

• Forte cohérence : vous pouvez interroger les dernières données validées par l'instance principale. Cela garantit la cohérence des requêtes de données globales. En cas de retard de réplication important, la requête soumise reste en attente.

• Faible cohérence : vous pouvez interroger les dernières données disponibles sur l'instance en lecture seule actuelle. En cas de délai de synchronisation des données entre l'instance principale et l'instance en lecture seule, la requête ne reste pas en attente et renvoie immédiatement les données.

Mode trois rôles

PolarDB-X prend en charge le mode trois rôles pour la gestion des bases de données. Dans ce mode, trois rôles sont créés pour gérer les bases de données : administrateur de base de données (DBA), administrateur de sécurité des bases de données (DSA) et administrateur d'audit des données (DAA). Cette approche renforce la sécurité de votre base de données car les permissions de gestion ne sont pas attribuées à un seul compte. Le mode trois rôles est principalement utilisé dans les activités financières.

Liste d'autorisation

Fournit une protection de sécurité d'accès pour les instances PolarDB-X. La configuration d'une liste d'autorisation n'affecte pas le fonctionnement normal des instances PolarDB-X.

Journal d'audit

Enregistre les opérations des utilisateurs. Les journaux d'audit SQL sont conservés pendant 45 jours par défaut.

Concept

Description

Table distribuée

Le sharding est un processus qui divise les données d'une table en plusieurs bases de données et tables à l'aide d'une clé de shard selon des règles spécifiques.

Table de diffusion

Une table de diffusion n'est pas divisée et tous les nœuds de données de la base de données possèdent un réplica de la table.

Table unique

Les tables uniques sont des tables qui ne sont pas divisées.

Mode de base de données

Spécifié par le paramètre Mode lors de la création d'une base de données. Il comprend deux modes : DRDS et AUTO.

Base de données en mode DRDS

Base de données créée avec Mode=DRDS. Ce type de base de données utilise la syntaxe DDL de sharding de PolarDB-X 1.0 (DRDS).

Base de données en mode AUTO

Base de données créée avec Mode=AUTO. Dans ce type de base de données, lorsque vous spécifiez manuellement la clé de partition et l'algorithme de partition, la syntaxe des tables partitionnées MySQL est utilisée pour les opérations DDL.

Table AUTO

Dans une base de données en mode AUTO, les tables créées sans utiliser la syntaxe PARTITION sont appelées tables AUTO. Les tables AUTO sont distribuées.

Table partitionnée

Dans une base de données en mode AUTO, les tables créées à l'aide de la syntaxe PARTITION sont appelées tables partitionnées.

Groupe de tables

Dans une base de données en mode AUTO, afin d'éviter autant que possible les requêtes intermachines et d'améliorer les performances, certains index globaux peuvent être regroupés dans un groupe de tables. Tous les index d'un groupe de tables doivent avoir le même nombre de partitions, le même algorithme de partition et la même clé de partition. Les groupes de tables se situent au niveau de l'index global. La table principale possède son propre groupe de tables et chaque index secondaire global possède également son propre groupe de tables.

Groupe de partitions

Dans une base de données en mode AUTO, lorsque les tables d'un groupe de tables sont des tables partitionnées, une partition de chaque table du groupe forme un groupe de partitions. Un groupe de partitions constitue l'unité de base de la planification des partitions. Toutes les partitions de table appartenant à un groupe de partitions se trouvent toujours sur le même nœud de données.

Groupe de jointure

Dans une base de données en mode AUTO, un groupe de jointure se compose de plusieurs tables. Les index globaux (tables principales et index secondaires globaux) appartenant au même groupe de jointure seront planifiés dans le même groupe de tables.

Plan d'exécution

Plan exécutable après l'analyse et l'optimisation d'une instruction de requête SQL.

Réécriture de requêtes

Optimisation des plans logiques basée sur des règles prédéfinies afin de produire de meilleurs plans logiques.

Cache de plans

Met en cache les plans d'exécution afin que, lors de la prochaine exécution de l'instruction SQL, le plan d'exécution puisse être obtenu directement à partir de la chaîne SQL paramétrée.

Gestion des plans

La gestion des plans est un processus qui enregistre un ou plusieurs plans d'exécution pour chaque instruction SQL. Lors de l'exécution d'une instruction SQL, PolarDB-X sélectionne un plan d'exécution enregistré pour cette instruction.

Modèle de coût

Utilisé pour estimer le coût des plans d'exécution de requêtes physiques. PolarDB-X décrit les coûts d'exécution à l'aide d'un quadruplet (CPU, Memory, IO, Net).

Modèle d'exécution

Contrairement aux bases de données traditionnelles qui utilisent le modèle d'exécution Volcano, PolarDB-X utilise un modèle d'exécution hybride combinant Pull et Push.

CBO (Cost Based Optimizer)

Optimiseur basé sur les coûts.

RBO (Rule Based Optimizer)

Optimiseur basé sur les règles.

Opérateur

Les opérateurs constituent les unités de base des plans d'exécution. Un plan d'exécution se compose de plusieurs opérateurs.

Planification

La planification est un processus qui déplace une tâche ou une partie d'une tâche vers une autre machine pour exécution.

DDL en ligne

Le DDL en ligne désigne les opérations DDL qui ne bloquent pas les opérations DML concurrentes. Par exemple, les opérations de création d'index ne bloquent pas les opérations DML concurrentes en cours d'exécution.

Requête logique

Requêtes SQL envoyées depuis le client vers PolarDB-X.

Requête physique

Requêtes SQL exécutées sur les nœuds de données.

Connexion logique

Connexion du client vers un nœud de calcul PolarDB-X.

Connexion physique

Connexion d'un nœud de calcul PolarDB-X vers un nœud de données PolarDB-X.

Transaction distribuée

Les opérations au sein d'une même transaction impliquent plusieurs nœuds de données.

Horodatage global

Les horodatages globaux sont incrémentiels et uniques à l'échelle d'un cluster PolarDB-X.

Index local

Les index locaux sont gérés par MySQL dans les nœuds de données. Également appelés index secondaires.

Index secondaire global (GSI)

Les données d'un index secondaire global (GSI) sont distribuées sur plusieurs nœuds de données selon des règles spécifiques.

Index clusterisé

Les index clusterisés sont des index secondaires globaux spéciaux qui couvrent par défaut toutes les colonnes de la table de base. Lorsqu'ils sont utilisés, les données demandées peuvent être interrogées directement depuis la table d'index sans nécessiter de balayage de la table de base. Cela réduit la consommation de ressources.

Sharding automatique

Partitionne automatiquement les tables en fonction du type de clé primaire.

Mise à l'échelle horizontale (scale-out/scale-in)

La mise à l'échelle horizontale (scale-out ou scale-in) correspond à l'augmentation ou à la diminution du nombre de nœuds. Par exemple, vous pouvez effectuer une mise à l'échelle horizontale d'un cluster de quatre à huit nœuds.

Mise à l'échelle verticale (scale-up/scale-down)

Augmente ou diminue la configuration d'un nœud unique. Par exemple, les spécifications du nœud peuvent passer de 4 cœurs et 8 Go à 16 cœurs et 32 Go.

XPaxos

X-Paxos est un protocole développé par Alibaba Group. X-Paxos est utilisé pour garantir la cohérence des données dans les bases de données distribuées.

Leader/Follower/Learner

X-Paxos définit les trois types de nœuds suivants : le nœud leader initie les propositions. Le nœud follower peut élire un nouveau leader. Le nœud learner reçoit uniquement les modifications de données de l'instance principale et ne participe pas à l'élection du leader.

Retour à la table principale

Opération consistant à interroger la table principale pour récupérer les colonnes nécessaires à une requête après le balayage d'un index.