Avant de créer un cluster ApsaraDB for HBase, sélectionnez les spécifications des nœuds maîtres et des nœuds principaux, leur nombre ainsi que le type de stockage. Adaptez ces choix aux requêtes par seconde (QPS), aux transactions par seconde (TPS), au volume de données, aux exigences de latence de réponse et aux besoins de stabilité de votre charge de travail.
Vous devez également décider de :
L'édition d'ApsaraDB for HBase. Consultez la rubrique Éditions d'ApsaraDB for HBase.
Le type d'instance Elastic Compute Service (ECS) : utilisez une instance ECS dédiée pour allouer des ressources exclusives et éviter toute contention. Pour les charges de travail à faible latence, associez une instance dédiée à des disques SSD.
Choisir les spécifications des nœuds maîtres
Les nœuds maîtres exécutent les masters ApsaraDB for HBase, les NameNodes du système de fichiers distribués Hadoop (HDFS) et ZooKeeper. Ils ne stockent pas de données. Par défaut, deux nœuds maîtres sont déployés en mode primaire-secondaire pour assurer la reprise après sinistre.
Une insuffisance de CPU ou de mémoire sur les nœuds maîtres dégrade les performances de l'ensemble du cluster. Sélectionnez les spécifications en fonction du nombre de nœuds principaux, de tables et de régions HBase gérés par le cluster. Les clusters comportant un grand nombre de tables ou de régions nécessitent des nœuds maîtres plus puissants.
| Nombre de nœuds principaux | Spécification du nœud maître |
|---|---|
| Moins de 4 | CPU 4 cœurs, 8 Go de mémoire |
| 4 à 7 | CPU 8 cœurs, 16 Go de mémoire (recommandé pour les petits clusters) |
| 8 à 15 | CPU 8 cœurs, 32 Go de mémoire |
| Plus de 16 | CPU 16 cœurs, 64 Go de mémoire ou plus |
Choisir les spécifications des nœuds principaux
Les nœuds principaux sont les RegionServers dans ApsaraDB for HBase. Ils traitent toutes les requêtes de lecture et d'écriture ; leurs spécifications influencent donc directement le débit, la latence et la stabilité du cluster.
Plage de spécifications : de CPU 4 cœurs avec 8 Go de mémoire (minimum) à CPU 32 cœurs avec 128 Go de mémoire (maximum).
Principe clé : mettez en cache l'intégralité des métadonnées pour obtenir des performances optimales. Choisissez la mémoire des nœuds principaux en fonction du volume de données devant rester en cache.
Voici quelques exemples de sélection des spécifications des nœuds principaux pour différents clusters ApsaraDB for HBase :
Petits clusters : CPU 4 cœurs et 16 Go de mémoire, ou CPU 8 cœurs et 32 Go de mémoire (recommandé).
-
Clusters moyens ou grands : sélectionnez les nœuds principaux en fonction du volume de données à stocker en mémoire.
Volume important de données à stocker : CPU 16 cœurs et 64 Go de mémoire, ou CPU 32 cœurs et 128 Go de mémoire.
Faible volume de données à stocker : CPU 16 cœurs et 32 Go de mémoire, ou CPU 32 cœurs et 64 Go de mémoire.
Si vous avez besoin d'aide pour calculer l'espace de stockage requis, rejoignez le groupe DingTalk ApsaraDB for HBase Q&A s0s3eg3 ou soumettez un ticket.
Spécifications selon le volume de la charge de travail
| TPS + QPS | Nœuds recommandés | Notes |
|---|---|---|
| Moins de 1 000 | Deux nœuds : CPU 4 cœurs, 16 Go de mémoire | Minimum pour les charges légères. Maintenez le nombre de régions par nœud en dessous de 600. L'option CPU 4 cœurs/8 Go est disponible, mais il est préférable de l'éviter : 8 Go de mémoire risquent de provoquer des erreurs de mémoire insuffisante (out-of-memory) en cas de pic de charge ou de volume du magasin clé-valeur. |
| 1 000 à 20 000 | Deux ou trois nœuds : CPU 8 cœurs, 32 Go de mémoire | Plus rentable que l'option CPU 8 cœurs/16 Go. Les 16 Go de mémoire supplémentaires offrent une marge de stabilité pour les charges légères à moyennes. |
| Plus de 20 000 | CPU 8 cœurs/32 Go ; CPU 16 cœurs/32 Go ; CPU 16 cœurs/64 Go ; CPU 32 cœurs/64 Go ; CPU 32 cœurs/128 Go ; ou supérieur | Pour les charges de travail en ligne, privilégiez les nœuds à grande mémoire afin de maximiser le taux de succès du cache. Pour les tâches hors ligne MapReduce ou Apache Spark à forte utilisation CPU, donnez la priorité aux nombres de cœurs plus élevés. |
Lorsque le volume des requêtes ne suffit pas
Les TPS et les QPS ne sont pas les seuls facteurs à prendre en compte. Même avec quelques centaines de requêtes par seconde, augmentez les spécifications des nœuds principaux si votre charge de travail présente l'une des caractéristiques suivantes :
Des lignes stockant des kilo-octets ou des méga-octets de données
Des requêtes d'analyse (scan) avec des filtres complexes
De faibles taux de succès du cache, où chaque requête accède au disque
Un grand nombre de tables et de régions
Dans ces conditions, les nœuds CPU 4 cœurs/8 Go peuvent entraîner des problèmes de stabilité et une augmentation de la latence, malgré un faible volume de requêtes.
Mise à l'échelle verticale ou horizontale
En cas de pics de charge, d'augmentation de la latence ou d'instabilité du cluster, vous pouvez effectuer une mise à l'échelle horizontale en ajoutant des nœuds principaux. Toutefois, l'ajout de nœuds aux spécifications limitées risque de créer des points chauds si votre charge de travail est inégalement répartie. Les spécifications d'un nœud principal déterminent sa capacité à absorber les pics de trafic et à prévenir les points chauds.
Par exemple, si une augmentation soudaine du trafic touche une seule région ou si une requête volumineuse atteint un nœud unique, un nœud aux spécifications limitées peut devenir surchargé ou manquer de mémoire, ce qui affecte la stabilité du cluster.
Choisissez d'abord les spécifications en fonction des exigences de la charge de travail, puis ajustez le nombre de nœuds selon les besoins.
Pour mettre à niveau les nœuds maîtres ou principaux, rejoignez le groupe DingTalk ApsaraDB for HBase Q&A (s0s3eg3) ou soumettez un ticket.
Choisir un type de stockage
Le type de stockage ne peut pas être modifié après la création d'un cluster. Faites votre choix avec soin avant de créer le cluster.
ApsaraDB for HBase prend en charge trois types de stockage :
| Fonctionnalité | Type de stockage | Idéal pour |
|---|---|---|
| Hautes performances | Disques SSD, SSD locaux ou ESSD | Charges de travail en ligne nécessitant une faible latence : publicité, recommandation, flux d'actualités et profilage des utilisateurs. Offre une latence de 1 à 2 ms et minimise les variations de performance. Les disques SSD constituent le meilleur choix pour une faible latence P99 (99e centile). |
| Haute efficacité | Disques ultra ou HDD locaux | Charges de travail en ligne sensibles à la latence, où une latence d'environ 10 ms est acceptable. Les disques HDD génèrent davantage de variations de performance que les disques SSD. |
| Stockage des données froides | OSS (stockage froid) | Stockage quasi en ligne et archivage des données. Le débit en écriture correspond à celui du stockage actif, mais les QPS en lecture sont limités et la latence en lecture est de l'ordre de quelques dizaines de millisecondes. |
Disques cloud
Les disques cloud sont évolutifs et répliqués pour assurer la redondance. Ils sont indépendants du matériel physique, ce qui protège contre la perte de données en cas de défaillance matérielle. Les disques cloud incluent les disques SSD et les disques ultra.
Pour augmenter la capacité de stockage après la création du cluster, étendez les disques cloud existants ou ajoutez davantage de nœuds principaux.
Disques locaux
Les disques locaux sont des disques physiques attachés aux instances ECS. Ils coûtent moins cher que les disques cloud, mais ne sont pas évolutifs de manière indépendante : la spécification du nœud principal détermine la taille du disque.
Pour augmenter la capacité de stockage, ajoutez davantage de nœuds principaux. Vous ne pouvez pas étendre la capacité en mettant à niveau l'instance ECS.
Si un seul disque tombe en panne, les données ne sont pas perdues. Si deux disques physiques ou plus sont endommagés, les charges de travail sont affectées. L'équipe d'assistance ApsaraDB for HBase remplace rapidement les disques endommagés.
Les disques locaux impliquent des coûts de démarrage élevés et conviennent aux charges de travail avec de grands volumes de données.
Stockage froid
Le stockage froid est un niveau basé sur Object Storage Service (OSS), dédié à ApsaraDB for HBase. Utilisez-le conjointement avec les disques cloud pour stocker les données rarement consultées, ou activez la séparation des données actives et froides pour archiver automatiquement les données froides et réduire les coûts.
Contrairement aux disques cloud et aux disques locaux, le stockage froid n'a pas besoin d'être sélectionné lors de la création du cluster. Activez et étendez le stockage froid à tout moment après la création du cluster.