Pour optimiser le débit, la latence et la haute disponibilité de vos charges de travail AlloyDB pour PostgreSQL, vous pouvez dimensionner et déployer vos instances de pool principal et de lecture pour les charges de travail de traitement des transactions en ligne (OLTP), de traitement analytique en ligne (OLAP) et de traitement transactionnel et analytique hybride (HTAP).
Présentation
Pour vous aider à améliorer les performances de vos bases de données, AlloyDB pour PostgreSQL propose les fonctionnalités intégrées suivantes :
- Gestion automatique de la mémoire
- Autovacuum adaptatif
- Paramètres de performances intégrés optimisés
- Faible délai de réplication
- Maintenance sans interruption avec un temps d'arrêt inférieur à la seconde pour l'instance principale et aucun temps d'arrêt pour les nœuds du pool de lecture lors des opérations de scaling
Le réglage de votre instance AlloyDB pour PostgreSQL pour améliorer les performances implique de gérer les éléments suivants :
- Dimensionner correctement vos instances principales et de pool de lecture
- Mettre à jour les options ayant un impact sur les performances
Considérations liées au dimensionnement
Avant de dimensionner votre instance AlloyDB pour PostgreSQL, déterminez les éléments suivants :
- Type de charge de travail : OLTP, OLAP ou HTAP
- Exigences de performances : exigences de latence et de débit
- Taille des données attendue : taille des données que vous prévoyez de stocker dans AlloyDB pour PostgreSQL et taille de l'ensemble de données actif
- Échelle de votre charge de travail : augmentation ou croissance de la taille des données au fil du temps
Charges de travail OLTP
Vous pouvez déployer votre base de données AlloyDB pour PostgreSQL en tant qu'instance zonale (nœud unique) ou en tant qu'instance disponibilité élevée (deux nœuds dans chaque zone). Vous pouvez également ajouter des instances de pool de lecture et un cluster secondaire dans une autre région pour les charges de travail géographiquement distribuées ou pour la reprise après sinistre (DR).
AlloyDB pour PostgreSQL est déployé à l'aide d'une architecture distribuée à l'échelle du cloud, avec un calcul et un stockage désagrégés. Les écritures sont confirmées dès que les fichiers de journalisation WAL (Write-Ahead Logging) sont conservés dans l'espace de stockage régional, tandis que la matérialisation des blocs est déchargée vers l'espace de stockage.
De même, avec l'architecture de cache multicouche, les données sont automatiquement placées entre le cache tampon, le cache ultrarapide et le moteur de stockage intelligent. En raison de cette architecture de cache à plusieurs niveaux utilisée dans AlloyDB pour PostgreSQL, les opérations d'entrée et de sortie par seconde (IOPS) ne sont pas pertinentes dans le contexte d'AlloyDB pour PostgreSQL pour les comparer à d'autres systèmes de base de données.
Toutefois, l'utilisation de transactions par seconde (TPS)/transactions par minute (TPM) peut fournir une comparaison pertinente pour comprendre la quantité de données pouvant être gérée par AlloyDB pour PostgreSQL.
La principale métrique de dimensionnement est le nombre de transactions par seconde (TPS). Pour estimer la taille requise pour AlloyDB pour PostgreSQL, procédez comme suit :
- Identifiez votre charge de travail existante. Si vous effectuez une migration depuis votre base de données PostgreSQL autogérée ou depuis d'autres bases de données commerciales, vous disposez peut-être déjà de la valeur TPS pour votre charge de travail existante.
- Analysez vos requêtes. Identifiez les requêtes les plus critiques de votre charge de travail et déterminez leurs exigences de performances.
- Utilisez un outil tel que
HammerDBoupgbench. Ces outils permettent d'évaluer AlloyDB pour PostgreSQL et de déterminer si la taille de la machine répond à vos exigences de TPS. - Utilisez le guide d'analyse comparative OLTP d'AlloyDB pour PostgreSQL. Ce guide fournit des données sur les performances pour différentes configurations AlloyDB pour PostgreSQL afin de trouver une configuration qui répond à vos exigences de TPS.
- Choisissez une taille AlloyDB pour PostgreSQL appropriée. Tenez compte de la taille actuelle de vos données et de vos attentes en termes de croissance future.
Consignes concernant la taille de machine
L'exemple de tableau suivant présente des recommandations pour les données avec une analyse comparative TPC-C dont le ratio lecture/écriture est d'environ 65% de lectures et 35% d'écritures. Lorsque vous dimensionnez une instance AlloyDB pour PostgreSQL, vous devez viser une utilisation du processeur en état stable d'environ 60 à 70% pour éviter les frais de planification du système d'exploitation. Cela permet de prévoir une marge pour les pics d'utilisation des ressources par les applications clientes.
Utilisez les recommandations de dimensionnement du tableau suivant comme consignes générales.
Pour connaître la valeur max_connections maximale recommandée pour chaque taille de machine, consultez Nombre maximal de connexions simultanées.
| vCPU/Mémoire | Plage de transactions/s recommandée (30% en cache) |
Taille des données de travail recommandée (jusqu'à 128 To au total) |
|---|---|---|
| 2 / 16 Go | Jusqu'à 1 000 | Jusqu'à 100 Go |
| 4 / 32 Go | Jusqu'à 2 500 | Jusqu'à 250 Go |
| 8/ 64 Go | Jusqu'à 4 000 | Jusqu'à 500 Go |
| 16 / 128 Go | Jusqu'à 8 000 | Jusqu'à 1 To |
| 32 / 256 Go | Jusqu'à 14 000 | Jusqu'à 3 To |
| 64 / 512 Go | Jusqu'à 20 000 | Jusqu'à 8 To |
| 96 / 768 Go | Jusqu'à 25 000 | Jusqu'à 16 To |
| 128 / 864 Go | Plus de 20 000 | Jusqu'à 32 To |
Types de déploiements
En fonction de votre charge de travail, vous pouvez déployer AlloyDB pour PostgreSQL en tant qu'instance principale uniquement ou en tant qu'instance principale avec une instance de pool de lecture.
Principale uniquement
Choisissez un déploiement principal uniquement pour les charges de travail suivantes :
- Écriture intensive avec lectures faibles à moyennes
- Requêtes à forte intensité de lecture avec des écritures légères
- Lecture-écriture OLTP standard (60 à 70% de lectures, 30 à 40% d'écritures).
Pour en savoir plus sur les types de machines, consultez Consignes générales sur la taille des machines.
Instance principale avec pool de lecture
Si vous choisissez de déployer une instance principale avec un pool de lecture, tenez compte des points suivants :
- Si vous avez des lectures sensibles à la latence, envisagez de décharger vos requêtes de lecture vers des instances de pool de lecture. Vous pouvez configurer jusqu'à 20 nœuds sur toutes les instances de pool de lecture. Pour en savoir plus, consultez Créer une instance de pool de lecture.
- Configurez plusieurs instances de pool de lecture si vous avez plusieurs bases de données (par exemple, CRM ou Finance dans la même instance). Cette stratégie permet d'optimiser la mise en cache et les performances des requêtes.
- Vous pouvez dimensionner vos instances de pool principal et de lecture différemment en fonction de vos besoins. Pour en savoir plus sur les bonnes pratiques concernant les instances de pool de lecture, consultez Bonnes pratiques pour améliorer les performances et la disponibilité d'AlloyDB.
- Ajoutez plusieurs nœuds par instance de pool de lecture pour assurer une haute disponibilité.
- Activez le moteur de données en colonnes de manière sélective dans des instances de pool de lecture spécifiques pour améliorer les performances des requêtes de lecture. Cela ne nécessite pas d'activer le moteur de données en colonnes sur l'instance principale.
Charges de travail OLAP
Pour les charges de travail OLAP, la principale métrique de dimensionnement est la performance des requêtes, en particulier celles qui nécessitent des analyses ou des agrégations de tables complètes. AlloyDB pour PostgreSQL inclut un moteur de données en colonnes intégré qui permet d'accélérer les requêtes analytiques. L'activation du moteur de données en colonnes consomme par défaut 30% de la mémoire et utilise automatiquement des données de cache ultrarapides.
Pour en savoir plus sur la mesure des performances OLAP avec AlloyDB pour PostgreSQL à l'aide de la charge de travail TPC-H, consultez le guide d'analyse comparative OLAP d'AlloyDB pour PostgreSQL.
Types de déploiements
En fonction de votre charge de travail, vous pouvez déployer AlloyDB pour PostgreSQL en tant qu'instance principale uniquement ou en tant qu'instance principale avec une instance de pool de lecture.
Principale uniquement
Si vous déployez une instance principale uniquement, tenez compte des points suivants :
- Utilisez ce déploiement pour les transactions avec des requêtes analytiques (HTAP).
- Activez le moteur de données en colonnes pour faciliter les requêtes OLAP.
- Envisagez de déployer une machine de 16 vCPU ou plus, qui fournit plus de mémoire pour stocker les données en colonnes.
Instance principale avec pool de lecture
Si vous déployez une instance principale avec un pool de lecture, tenez compte des points suivants :
- Si vous avez des écritures lourdes et des lectures analytiques sensibles à la latence avec des exigences de faible décalage, déployez l'instance principale avec la haute disponibilité activée et avec des instances de pool de lecture.
- Activez le moteur de données en colonnes dans les instances de pool de lecture où vous exécutez vos requêtes analytiques.
- Configurez plusieurs instances de pool de lecture si vous avez plusieurs bases de données (par exemple, CRM ou Finance dans la même instance). Cette stratégie permet d'optimiser la mise en cache et les performances des requêtes.
- Vous pouvez dimensionner vos instances de pool principal et de lecture différemment en fonction de vos besoins. Pour en savoir plus sur les bonnes pratiques concernant les instances de pool de lecture, consultez Bonnes pratiques pour améliorer les performances et la disponibilité d'AlloyDB.
- Ajoutez plusieurs nœuds par instance de pool de lecture pour assurer une haute disponibilité.
- Activez le moteur de données en colonnes de manière sélective dans des instances de pool de lecture spécifiques pour améliorer les performances des requêtes de lecture. Cela ne nécessite pas d'activer le moteur de données en colonnes sur l'instance principale.
Étapes suivantes
- Découvrez les bonnes pratiques pour améliorer les performances et la disponibilité.
- Guide d'analyse comparative d'AlloyDB pour PostgreSQL pour PostgreSQL OLTP.
- Guide d'analyse comparative d'AlloyDB pour PostgreSQL pour PostgreSQL OLAP.