Les instances Hologres sont dimensionnées par incréments d'unités de calcul (CU). Comme Hologres repose sur une architecture séparant le calcul du stockage, la capacité de stockage évolue indépendamment. Choisir les spécifications d'une instance revient donc essentiellement à sélectionner la puissance de calcul adaptée à votre charge de travail.
Cette rubrique explique comment le nombre d'unités CU détermine le nombre de connexions, le nombre de shards et les performances des requêtes, afin que vous puissiez choisir une configuration de départ et savoir quand l'ajuster.
Concepts clés
CU (Compute Unit) — L'unité de base des ressources pour les instances Hologres. Chaque lot de 16 CUs correspond à un nœud de calcul.
Shard — L'unité de partitionnement des données dans Hologres. Chaque shard gère les demandes de lecture et d'écriture pour une partie des données. Les shards au sein d'un même Table Group répartissent les données de chaque table de sorte que les jointures entre tables co-localisées évitent les transferts de données inter-shards (on parle alors de jointure locale). Lorsque les données s'étendent sur plusieurs shards, un opérateur de redistribution les réorganise via le réseau, ce qui engendre une surcharge de planification.
Table Group — Un regroupement logique qui définit l'organisation des shards. Toutes les tables appartenant au même Table Group partagent la même disposition des shards, ce qui permet d'effectuer des jointures locales entre ces tables.
Nœud frontal — La couche d'accès qui gère les connexions entrantes. Le nombre total de connexions pour une instance est égal au nombre maximal de connexions par nœud frontal multiplié par le nombre de nœuds frontaux.
Impact du nombre de shards sur les performances
Le comportement des shards varie selon le type de charge de travail :
| Charge de travail | Effet d'une augmentation du nombre de shards |
|---|---|
| Écritures et mises à jour de données | Débit plus élevé — les écritures sont parallélisées sur les shards |
| Requêtes ponctuelles (avec élagage des shards) | Concurrence plus élevée — chaque requête cible un seul shard |
| Requêtes OLAP (traitement analytique en ligne) | Rendements décroissants — la coordination entre plusieurs shards ajoute une surcharge de planification |
| Tables orientées ligne | Meilleures performances en lecture — distribution naturelle des données sur les shards |
Après avoir augmenté la capacité d'une instance, l'ajout de ressources de calcul améliore la concurrence des requêtes. Dans la plupart des cas, laissez le nombre de shards inchangé, sauf si vous avez spécifiquement besoin d'un débit d'écriture plus élevé. Si vous augmentez la capacité de moins de cinq fois sa taille d'origine, ne modifiez pas le nombre de shards.
Il est impossible de modifier manuellement le nombre maximal de connexions. Lorsqu'une instance est mise à l'échelle (augmentation ou diminution), les limites de connexion s'ajustent automatiquement. Toutefois, le nombre de shards par défaut des bases de données existantes ne change pas lors de la mise à l'échelle ; mettez-le à jour manuellement si nécessaire. Les nouvelles bases de données utilisent le nombre de shards par défaut associé aux nouvelles spécifications.
Quand ajuster vos spécifications
Avant de consulter le tableau de recommandations, vérifiez si vos spécifications actuelles constituent réellement un goulot d'étranglement. Les signaux suivants indiquent qu'il est probablement nécessaire de modifier vos spécifications :
| Signal | Action recommandée |
|---|---|
| Le nombre de connexions approche ou atteint la limite de l'instance | Augmentez la capacité (ajoute des nœuds frontaux et relève le plafond de connexions) |
| Le débit d'écriture ne suit pas le taux d'ingestion | Augmentez la capacité, puis augmentez le nombre de shards pour les bases de données existantes |
| La latence des requêtes OLAP est élevée mais la concurrence est faible | Augmentez la capacité pour ajouter des nœuds de calcul ; n'augmentez pas le nombre de shards |
| La concurrence des requêtes ponctuelles a atteint un plateau | Augmentez la capacité, puis augmentez le nombre de shards si l'élagage des shards est actif |
Exécutez l'instruction suivante pour vérifier votre utilisation actuelle des connexions par rapport à la limite :
-- Returns the maximum connections for a single frontend node.
-- Multiply by the number of frontend nodes to get the instance total.
show max_connections;Si aucun de ces signaux n'est présent, vos spécifications actuelles sont probablement suffisantes.
Spécifications recommandées selon le volume de données
Le choix des spécifications appropriées dépend de nombreux facteurs au-delà du simple nombre de lignes. La fréquence d'accès, le volume d'accès aux données, la charge de calcul (requêtes ponctuelles ou analytiques), le débit d'écriture et le nombre de tables au sein d'un Table Group entrent tous en ligne de compte. Utilisez le tableau suivant comme point de départ.
Ces recommandations sont des lignes directrices, non des limites strictes. Une table avec un petit volume de données peut fonctionner sur une instance disposant d'un nombre élevé de shards ; une grande table peut fonctionner sur une instance à shard unique. Adaptez le nombre de shards à votre objectif de concurrence tout en maintenant une concentration des données suffisante pour éviter une surcharge inutile due au brassage (shuffle).
| Taille totale des données | Spécifications recommandées | Nombre de shards recommandé | Adéquation avec la charge de travail |
|---|---|---|---|
| Moins de 40 millions de lignes | 32 cœurs ou plus | 10–20 | Développement et tests. Ne convient pas aux tests de charge. |
| 40 millions à 400 millions de lignes | 64 cœurs ou plus | 20–40 | Charges de travail simples : débit d'écriture modéré, sans mélange de concurrence OLAP et de requêtes ponctuelles. |
| 400 millions à 4 milliards de lignes | 128 cœurs ou plus | 40–80 | Équilibre entre écritures et requêtes. Point de départ par défaut pour la production. |
| 4 milliards à 40 milliards de lignes | 256 cœurs ou plus | 80–240 | Écriture à haut débit ou OLAP à grande échelle. Utilisez plusieurs Table Groups ; divisez selon la cohésion métier ou le volume de données ; spécifiez explicitement le Table Group lors de la création des tables. |
| 40 milliards à 400 milliards de lignes | 512 cœurs ou plus | 160–400 | OLAP très large ou charges de travail multi-locataires. Utilisez plusieurs Table Groups (mêmes directives que ci-dessus). Réservez les nombres élevés de shards uniquement aux très grandes tables — les tables standard n'en tirent pas profit. |
Ressources par défaut selon les spécifications de l'instance
Depuis le 25 avril 2022, les instances à usage général prennent en charge de 512 à 1 024 CUs. Pour des spécifications supérieures, soumettez un ticket. Avant de passer à des spécifications plus élevées, mettez à niveau l'instance vers la version V1.1.58 ou ultérieure.
Les instances de groupe de calcul prennent en charge n'importe quelle spécification de 32 à 8 192 CUs sans nécessiter de ticket.
Chaque lot de 16 CUs correspond à un nœud de calcul.
Pour les spécifications inférieures ou égales à 512 CUs : le nombre de nœuds de calcul est égal au nombre de nœuds frontaux.
Pour les spécifications supérieures ou égales à 1 600 CUs : le nombre de nœuds frontaux est plafonné à 100.
Nombre total maximal de connexions = nombre maximal de connexions par nœud frontal × nombre de nœuds frontaux. Les valeurs entre parenthèses indiquent le chiffre par nœud suivi du nombre de nœuds.
| Spécifications de l'instance | Nœuds de calcul | Nombre de shards par défaut | Connexions maximales (V2.1 et antérieures) | Connexions maximales (V2.2 et ultérieures) | Connexions réservées pour Superuser (V1.1 et ultérieures) |
|---|---|---|---|---|---|
| 32 CUs | 2 | 20 | 256 (128 × 2) | 512 (256 × 2) | 10 (5 × 2) |
| 48–80 CUs | 3–5 | 40 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 96–112 CUs | 6–7 | 60 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 128–192 CUs | 8–12 | 80 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 208–352 CUs | 13–22 | 120 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 368–992 CUs | 23–62 | 160 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 1 008–1 584 CUs | 63–99 | 200 | 128 × nombre de nœuds de calcul | 256 × nombre de nœuds de calcul | 5 × nombre de nœuds de calcul |
| 1 600–2 272 CUs | 100–142 | 200 | 12 800 (128 × 100) | 25 600 (256 × 100) | 500 (5 × 100) |
| 2 288–4 000 CUs | 143–250 | 240 | 12 800 (128 × 100) | 25 600 (256 × 100) | 500 (5 × 100) |
| 4 016–8 000 CUs | 251–500 | 320 | 12 800 (128 × 100) | 25 600 (256 × 100) | 500 (5 × 100) |
| 8 016–8 192 CUs | 501–512 | 400 | 12 800 (128 × 100) | 25 600 (256 × 100) | 500 (5 × 100) |
Modifications automatiques lors de la mise à l'échelle
Lorsque vous augmentez ou réduisez la capacité d'une instance, les modifications suivantes s'appliquent automatiquement :
| Configuration | Comportement lors de la mise à l'échelle |
|---|---|
| Connexions maximales | Ajustées automatiquement pour correspondre aux nouvelles spécifications |
| Nombre de shards par défaut (nouvelles bases de données) | Utilise la valeur par défaut des nouvelles spécifications |
| Nombre de shards par défaut (bases de données existantes) | Ne change pas — mettez à jour manuellement si nécessaire |
Cela signifie qu'après une augmentation de capacité, les bases de données existantes conservent leur nombre original de shards. Les nœuds de calcul supplémentaires améliorent tout de même la concurrence des requêtes, car davantage de cœurs traitent chaque requête. Ne mettez à jour le nombre de shards manuellement que si vous avez besoin d'un débit d'écriture plus élevé ou si vous prévoyez d'ajouter significativement plus de données.
Consulter et gérer les connexions
Vérifier la limite actuelle de connexions
Une fois connecté à un outil de développement, exécutez l'instruction suivante pour afficher le nombre maximal de connexions pour un seul nœud frontal :
-- View the maximum connections for a single frontend node.
-- Connections are balanced across all frontend nodes.
show max_connections;Multipliez la valeur renvoyée par le nombre de nœuds frontaux pour obtenir la limite totale de connexions de l'instance.
Gérer les connexions lorsque la limite est atteinte
Chaque instance réserve des connexions pour le rôle Superuser. Lorsque la limite de connexions est atteinte, un utilisateur Superuser peut se connecter et utiliser SQL pour afficher et libérer les connexions inactives, ou augmenter la capacité de l'instance. Pour plus de détails, consultez Connexions.
Afficher et modifier le nombre de shards
L'augmentation de la capacité d'une instance ne modifie pas le nombre de shards des bases de données existantes ; ajustez-le manuellement si votre charge de travail l'exige. Augmentez le nombre de shards lorsque vous avez besoin d'un débit d'écriture plus élevé. Pour les tables orientées ligne, un plus grand nombre de shards améliore également les performances en lecture grâce à la distribution naturelle des données.
Pour les instructions, consultez Guide de l'utilisateur Table Group et nombre de shards.
Étapes suivantes
Guide de l'utilisateur Table Group et nombre de shards — Créez des Table Groups et ajustez les nombres de shards
Connexions — Surveillez et libérez les connexions inactives