Dans Hologres, le nombre de shards défini lors de la création d'un groupe de tables est permanent : vous ne pouvez pas le modifier par la suite. Une erreur de configuration entraîne une répartition inégale des ressources, une latence à longue traîne ou une consommation excessive de mémoire difficile à diagnostiquer. Cette rubrique explique les groupes de tables, les shards et le nombre de shards afin que vous configuriez correctement votre instance dès le départ.
Concepts clés
Shard
Un shard est une partition de données. Dans Hologres, les données sont stockées sur l'Apsara Distributed File System. Chaque shard possède un ID unique au niveau de l'instance. Lors de l'écriture, le moteur de stockage répartit les données entre les shards selon une clé de distribution. En l'absence de clé de distribution, les données sont distribuées aléatoirement.
Groupe de tables
Le groupe de tables est un concept de stockage logique propre à Hologres ; il n'existe pas dans PostgreSQL. Un groupe de tables gère un ensemble fixe de shards. Lorsque vous créez une table, elle est assignée à un groupe de tables et ses données sont stockées sur les shards de ce groupe.
Les groupes de tables se distinguent des concepts connexes suivants :
| Concept | Description |
|---|---|
| Groupe de tables | Regroupement spécifique à Hologres de shards logiques sous-jacents |
| Schéma | Concept de base de données standard pour organiser des objets (non lié aux shards) |
| Table space (PostgreSQL) | Identifie l'emplacement de stockage d'un objet de base de données, semblable à un répertoire |
Des tables appartenant à des schémas différents peuvent faire partie du même groupe de tables. Une table ne peut appartenir qu'à un seul groupe de tables. Pour déplacer une table vers un autre groupe de tables, recréez-la dans le nouveau groupe ou utilisez une fonction de migration.
Nombre de shards
Le nombre de shards correspond au nombre de shards présents dans un groupe de tables. Définissez ce nombre lors de la création du groupe de tables ; il est ensuite immuable. Pour utiliser un nombre de shards différent, créez un nouveau groupe de tables avec la valeur souhaitée.
Base de données et groupes de tables
Une base de données (DB) peut contenir un ou plusieurs groupes de tables, mais un seul est défini par défaut. Si vous ne configurez pas explicitement un groupe de tables et un nombre de shards, Hologres crée automatiquement un groupe de tables par défaut avec un nombre de shards par défaut lors de la création de la base de données. Vous pouvez ajouter d'autres groupes de tables ou modifier le groupe par défaut selon vos besoins. Les shards de différents groupes de tables ne se chevauchent jamais.
Si un groupe de tables ne contient aucune table, le système le supprime automatiquement.
La figure suivante illustre la structure d'un groupe de tables.
Fonctionnement
Hologres s'appuie sur deux composants principaux pour gérer les données :
Moteur de stockage (SE) : Gère et traite les données sur les shards. Pour les opérations DML (Data Manipulation Language), chaque SE fournit des interfaces permettant des accès CRUD (création, lecture, mise à jour et suppression) individuels ou par lots. Chaque SE gère exactement un shard.
Moteur de requête (QE) : Utilise les interfaces du SE pour lire et écrire des données avec des performances élevées.
Voici ce qui se produit lors de l'écriture de données ou de l'exécution d'une requête :
Lorsque vous créez un groupe de tables avec un nombre de shards donné, chaque nœud de travail crée plusieurs SE internes, un par shard attribué.
Hologres répartit les SE uniformément sur tous les nœuds de travail afin d'équilibrer les ressources de calcul.
Lors de l'écriture des données, le SE les achemine vers le shard approprié en fonction de la clé de distribution.
Lorsqu'une requête s'exécute, le QE appelle les SE pertinents, qui lisent les données de leurs shards en parallèle et renvoient les résultats.
La figure suivante présente la disposition des nœuds de travail, des SE et des shards.
Éléments gérés automatiquement par Hologres :
Répartition uniforme des SE sur les nœuds de travail
Distribution des shards d'un groupe de tables sur plusieurs nœuds de travail (aucun nœud unique ne détient tous les shards d'un groupe de tables)
Réattribution des shards à des nœuds de travail sains en cas de panne d'un nœud (par exemple, due à une erreur d'épuisement de la mémoire (OOM))
Décisions qui vous incombent :
Définir le nombre de shards lors de la création d'un groupe de tables (impossible à modifier ultérieurement)
Exemple de basculement : Dans une instance comportant 4 nœuds de travail et 8 shards (2 groupes de tables, chaque nœud détenant 2 SE), si le nœud de travail 4 tombe en panne et était responsable du Shard 7 et du Shard 8, ces deux shards sont automatiquement réattribués aux trois nœuds restants pour rétablir l'équilibre.
Définir le nombre de shards
Le nombre de shards affecte directement le parallélisme des requêtes, l'utilisation de la mémoire et la charge d'E/S. Le nombre minimal de shards est 1. Utilisez le tableau suivant pour choisir la valeur appropriée.
| Scénario | Nombre de shards recommandé |
|---|---|
| Données très peu volumineuses (centaines à milliers de lignes) | 1 |
| Charges de travail générales | Un multiple du nombre de nœuds de travail |
| Maximum recommandé | Nombre total de cœurs de calcul dans l'instance |
Pourquoi le nombre de shards doit être un multiple du nombre de nœuds de travail : Si le nombre de shards n'est pas un multiple du nombre de nœuds de travail, certains nœuds hébergent plus de SE que d'autres. Cela provoque une répartition inégale des ressources et une latence à longue traîne. Par exemple, si un groupe de tables comporte 3 shards mais que l'instance dispose de 2 nœuds de travail, un nœud gérera toujours une charge plus importante. Définir le nombre de shards comme un multiple du nombre de nœuds de travail garantit une distribution uniforme.
Pourquoi ne pas dépasser le nombre de cœurs de calcul : Chaque shard nécessite au moins un cœur CPU pendant l'exécution d'une requête. Si le nombre de shards dépasse le nombre de cœurs de calcul, certains shards ne se voient pas allouer de ressources CPU de manière constante, ce qui entraîne une latence à longue traîne et une surcharge liée aux changements de contexte.
Pour connaître les valeurs par défaut du nombre de shards selon la taille de l'instance, consultez la section Gestion des instances.
Compromis en matière de performances
Gardez à l'esprit les compromis suivants lors de la configuration des groupes de tables et du nombre de shards.
Plus de shards
Un parallélisme accru pour les écritures, les requêtes et les analyses, mais aussi une communication inter-nœuds, une utilisation de la mémoire et une charge de calcul plus importantes. Si les ressources sont limitées ou si les requêtes sont de petite taille, un nombre élevé de shards peut nuire aux performances plutôt que de les améliorer.
Plus de groupes de tables
Chaque shard, qu'il soit activement utilisé ou non, occupe de la mémoire pour stocker les métadonnées, les informations de schéma et d'autres données. Un shard consomme encore plus de mémoire lorsque des données sont écrites dans les tables qu'il contient. Davantage de groupes de tables signifie davantage de shards au total, ce qui augmente la consommation globale de mémoire.
De plus, les tables nécessitant une jointure locale doivent se trouver dans le même groupe de tables. Répartir des tables associées sur plusieurs groupes de tables empêche le moteur de requête d'effectuer efficacement des jointures locales.
Plus de shards par table
Un plus grand nombre de shards disperse les données d'une table dans davantage de fichiers. Avec de nombreuses tables et de nombreux shards, le nombre total de fichiers devient important, ce qui augmente les E/S lors des requêtes et prolonge les temps de récupération en cas de basculement.