L'Édition Haute Performance d'AnalyticDB for PostgreSQL repose sur une architecture à réplica unique. Elle réduit les coûts de stockage et offre des performances d'E/S en écriture supérieures à celles de l'édition Haute Disponibilité. Cette édition convient aux charges de travail analytiques pour lesquelles l'efficacité des coûts et le débit d'écriture priment sur la disponibilité maximale.
L'Édition Haute Performance convient à la plupart des scénarios d'analyse métier. Pour les exigences métier critiques nécessitant une disponibilité maximale, privilégiez l'édition Haute Disponibilité.
Quand utiliser l'Édition Haute Performance
Critères | Édition Haute Performance | Édition Haute Disponibilité |
Architecture | Réplica unique | Double réplica (primaire + secondaire) |
Coût de stockage | Inférieur (réduction de 50 % par rapport aux mêmes spécifications) | Supérieur |
Performances d'E/S en écriture | Supérieures (aucune surcharge de réplication) | Inférieures |
Récupération après un crash SQL | ~10 secondes | 5–10 minutes |
Récupération après une panne du nœud de calcul | Redémarrage requis ; aucun basculement automatique | Basculement automatique ; aucune interruption de service |
Récupération après une panne de l'hôte | Redémarrage requis après migration de l'hôte ; ~15 minutes | Basculement automatique ; la migration s'exécute en arrière-plan |
Idéal pour | Analytique, traitement par lots, charges de travail sensibles aux coûts | OLAP de production, missions critiques |
Choisissez l'Édition Haute Performance si votre charge de travail tolère une fenêtre de récupération de quelques minutes à quelques heures en cas de défaillance matérielle. Pour les charges de travail nécessitant une disponibilité continue lors de pannes matérielles, utilisez l'édition Haute Disponibilité.
Architecture
L'Édition Haute Performance déploie les nœuds coordinateurs et les nœuds de calcul dans une architecture à réplica unique, comme illustré ci-dessous.
Figure 1. Architecture de l'Édition Haute Performance
L'édition Haute Disponibilité inclut un nœud coordinateur de secours et des nœuds de calcul secondaires.
Figure 2. Architecture de l'édition Haute Disponibilité
La suppression du nœud coordinateur de secours et des nœuds de calcul secondaires a trois effets directs :
Aucun stockage n'est alloué au nœud coordinateur de secours.
Le stockage des nœuds de calcul est réduit de 50 %.
La synchronisation des données entre les nœuds de calcul primaires et secondaires est supprimée, ce qui améliore les performances d'E/S en écriture.
Réduction des coûts
Une instance de l'Édition Haute Performance aux mêmes spécifications coûte moins cher qu'une instance de l'édition Haute Disponibilité, car elle ne maintient qu'un seul réplica.
Le tableau ci-dessous présente les prix mensuels des deux éditions pour deux niveaux de spécifications courants.
**Spécifications**
|
**Stockage HPE (USD/mois)**
|
**Stockage HAE (USD/mois)**
|
**Réduction du stockage**
|
**Calcul HPE (USD/mois)**
|
**Calcul HAE (USD/mois)**
|
**Réduction du calcul**
|
**Total HPE (USD/mois)**
|
**Total HAE (USD/mois)**
|
**Réduction totale**
| | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | |
Entrée de gamme
|
22,4
|
100
|
77,6 %
|
175,55
|
352,05
|
50,13 %
|
197,95
|
452,05
|
56,21 %
| |
Courante
|
89,6
|
200
|
55,2 %
|
668,65
|
700,28
|
4,52 %
|
758,25
|
900,28
|
15,78 %
|
Spécifications d'entrée de gamme : L'Édition Haute Performance (HPE) utilise 2 cœurs CPU, 50 Go de stockage et 2 nœuds de calcul. L'édition Haute Disponibilité (HAE) utilise 2 cœurs CPU, 50 Go de stockage et 4 nœuds de calcul. Avec ces spécifications, l'HPE est 56 % moins chère.
Spécifications courantes : Les deux éditions utilisent 4 cœurs CPU, 100 Go de stockage et 4 nœuds de calcul. Avec ces spécifications, l'HPE est 15 % moins chère.
Pour connaître les tarifs actuels, consultez la page Tarification d'AnalyticDB for PostgreSQL.
Performances
L'Édition Haute Performance offre de meilleures performances d'E/S, car elle élimine la synchronisation des données et la réplication en continu entre les nœuds de calcul primaires et secondaires. Sur une instance à 2 cœurs CPU, les performances d'E/S peuvent atteindre 250 % de celles d'une instance comparable de l'édition Haute Disponibilité. Les charges de travail intensives en écriture bénéficient d'une amélioration d'environ 100 %.
Les benchmarks suivants comparent les deux éditions configurées avec 2 cœurs CPU, 400 Go de stockage et 4 nœuds de calcul.
Réplication locale
Réplication d'une table orientée ligne contenant environ 90 Go de données :
CREATE TABLE lineitem2 AS (SELECT * FROM lineitem);Édition | Temps d'exécution |
Édition Haute Performance | 249 secondes |
Édition Haute Disponibilité | 1 307 secondes |
L'Édition Haute Performance a effectué l'opération environ 5 fois plus rapidement. La même amélioration s'applique aux opérations INSERT INTO SELECT.
Benchmark TPC-H
Ce test est basé sur la méthodologie du benchmark TPC-H, mais ne satisfait pas à toutes les exigences TPC-H. Les résultats ne peuvent pas être comparés aux résultats TPC-H publiés.
22 requêtes SQL ont été exécutées sur un jeu de données TPC-H de 100 Go. La figure suivante présente les résultats.
L'Édition Haute Performance a terminé l'ensemble complet des requêtes 40 % plus rapidement que l'édition Haute Disponibilité, ce qui reflète l'avantage en E/S lié à la suppression de la surcharge de réplication.
Disponibilité
Fiabilité des données
AnalyticDB for PostgreSQL stocke les données sur des disques SSD améliorés (ESSD), qui utilisent plusieurs réplicas internes au niveau du stockage. Cela garantit une fiabilité et une intégrité élevées des données, même en mode réplica unique : les données ne sont pas perdues en cas de panne d'un nœud de calcul.
Scénarios de panne et récupération
L'Édition Haute Performance offre une disponibilité inférieure à celle de l'édition Haute Disponibilité, car il n'y a pas de nœud de secours vers lequel basculer. Le tableau ci-dessous résume le comportement de récupération pour les scénarios de panne courants.
Scénario de panne | Édition Haute Performance | Édition Haute Disponibilité |
Crash SQL (core dump, manque de mémoire (OOM)) | ~10 secondes (point de contrôle optimisé) | 5–10 minutes |
Panne du nœud de calcul | Redémarrage requis ; service indisponible jusqu'à la fin du redémarrage | Basculement automatique ; le nœud secondaire prend le relais sans interruption de service |
Panne de l'hôte | Redémarrage requis après migration de l'hôte ; ~15 minutes | Basculement automatique ; la migration de l'hôte s'exécute en arrière-plan |
En cas de défaillance de machine physique, la récupération peut prendre jusqu'à 8 heures dans les scénarios extrêmes.
Fonctionnement du mode de récupération
La plupart des pannes dans AnalyticDB for PostgreSQL, y compris les crashes SQL causés par des vidages de mémoire ou des erreurs OOM, déclenchent le mode de récupération plutôt qu'une panne complète du nœud. Pendant le mode de récupération, l'instance :
Efface les verrous restants et la mémoire.
Rejoue les fichiers journaux de transactions anticipées (WAL) pour restaurer les transactions validées qui n'ont pas encore été écrites sur le disque.
Reprend le service.
L'Édition Haute Performance utilise un mécanisme de point de contrôle optimisé qui réduit la quantité de données WAL à rejouer. La récupération après ces scénarios de panne courants prend environ 10 secondes, contre 5 à 10 minutes pour l'édition Haute Disponibilité.
WAL et points de contrôle
Journal des transactions anticipées (WAL) : Enregistre toutes les modifications de données pour chaque transaction avant la validation de celle-ci. Le WAL permet à la base de données de rejouer les modifications qui ont été validées mais pas encore vidées sur le disque.
Point de contrôle : Point jusqu'auquel toutes les modifications de données sont confirmées sur le disque. La base de données récupère à partir du point de contrôle le plus récent. AnalyticDB for PostgreSQL effectue des points de contrôle selon un calendrier défini et les déclenche également lorsque la taille du fichier WAL atteint un seuil.
Pannes des nœudes de calcul
Lorsqu'un nœud de calcul tombe en panne dans l'édition Haute Disponibilité, le nœud de calcul secondaire prend automatiquement le relais. Le nœud défectueux redémarre en arrière-plan sans interruption de service.
Lorsqu'un nœud de calcul tombe en panne dans l'Édition Haute Performance, il n'y a pas de nœud secondaire pour prendre le relais. L'instance devient indisponible et doit être redémarrée pour la récupération.
Pannes de l'hôte
Les pannes de l'hôte déclenchent une migration automatique de l'hôte dans les deux éditions. Dans l'édition Haute Disponibilité, le nœud de secours assure la continuité du service pendant que la migration s'exécute en arrière-plan. Dans l'Édition Haute Performance, l'instance doit redémarrer une fois la migration de l'hôte terminée, un processus qui prend environ 15 minutes.
FAQ
Puis-je mettre à niveau l'Édition Haute Performance vers l'édition Haute Disponibilité ?
La mise à niveau directe sur place n'est pas prise en charge. Les deux éditions utilisent des nombres de réplicas et des configurations de stockage différents, il n'existe donc pas de chemin de migration automatisé. Pour changer d'édition, sauvegardez les données de l'instance de l'Édition Haute Performance, achetez une instance de l'édition Haute Disponibilité et restaurez-y les données. Pour obtenir des instructions de migration, consultez la page Migration de données entre instances AnalyticDB for PostgreSQL.