Recommandations de dimensionnement et de déploiement

Ce document fournit des recommandations concernant les charges de travail et le déploiement pour dimensionner les instances AlloyDB pour PostgreSQL pour les charges de travail de traitement transactionnel en ligne (OLTP) et de traitement analytique en ligne (OLAP).

Présentation

Pour vous aider à améliorer les performances de votre base de données, AlloyDB pour PostgreSQL fournit 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 avant réplication
  • Maintenance sans interruption avec un temps d'arrêt inférieur à la seconde pour le nœud principal et nul pour les nœuds du pool de lecture lors des opérations de scaling

Pour optimiser les performances de votre instance AlloyDB pour PostgreSQL, vous devez gérer les éléments suivants :

  • Dimensionner correctement vos instances principales et de pool de lecture
  • Mettre à jour les indicateurs 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 dissociés. Les écritures sont confirmées dès que les fichiers journaux WAL (Write-Ahead Logging) sont conservés dans le stockage régional, tandis que la matérialisation des blocs est déchargée sur le 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 multicouche utilisée dans AlloyDB pour PostgreSQL, les opérations d'entrée/sortie par seconde (IOPS) ne sont pas pertinentes dans le contexte d'AlloyDB pour PostgreSQL pour la comparaison avec d'autres systèmes de base de données.

Toutefois, l'utilisation des transactions par seconde (TPS) ou des transactions par minute (TPM) peut fournir une comparaison significative pour comprendre la quantité de données pouvant être traitées par AlloyDB pour PostgreSQL.

La métrique de dimensionnement principale est le TPS. Pour estimer la taille requise d'AlloyDB pour PostgreSQL, procédez comme suit :

  1. Identifiez votre charge de travail existante. Si vous migrez depuis votre instance 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.
  2. Analysez vos requêtes. Identifiez les requêtes les plus critiques de votre charge de travail et déterminez leurs exigences de performances.
  3. Utilisez un outil tel que HammerDB ou pgbench. Ces outils permettent de comparer AlloyDB pour PostgreSQL et de déterminer si la taille de la machine répond à vos exigences en termes de TPS.
  4. Utilisez le guide d'analyse comparative des transactions (OLTP) AlloyDB pour PostgreSQL. Ce guide fournit des données sur les performances de différentes configurations AlloyDB pour PostgreSQL, afin de vous aider à trouver celle qui répond à vos exigences en termes de TPS.
  5. Choisissez une taille appropriée pour AlloyDB pour PostgreSQL. Tenez compte de la taille actuelle de vos données et de vos attentes en termes de croissance future.

Consignes concernant la taille des machines

Le tableau suivant présente des exemples de recommandations pour des données avec benchmarking 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 la surcharge de planification du système d'exploitation. Cela laisse une certaine marge pour les pics d'utilisation des ressources par les applications clientes.

vCPU/Mémoire Plage recommandée de transactions/s
(30 % en cache)		 Taille de données de travail recommandée
(jusqu'à 128 To au total)		 max_connections recommandé
2 / 16 Go Jusqu'à 1 000 Jusqu'à 100 Go 1000
4 / 32 Go Jusqu'à 2 500 Jusqu'à 250 Go 2000
8/ 64 Go Jusqu'à 4 000 Jusqu'à 500 Go 4000
16 / 128 Go Jusqu'à 8 000 Jusqu'à 1 To 5000
32 / 256 Go Jusqu'à 14 000 Jusqu'à 3 To 5000
64 / 512 Go Jusqu'à 20 000 Jusqu'à 8 To 5000
96 / 768 Go Jusqu'à 25 000 Jusqu'à 16 To 5000
128 / 864 Go Supérieur à 20 000 Jusqu'à 32 To 5000

Types de déploiement

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 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 axées sur la lecture avec des opérations d'écriture légères
  • Lecture/écriture OLTP typique (60 à 70 % de lectures, 30 à 40 % d'écritures).

Pour en savoir plus sur les types de machines, consultez les Consignes générales concernant 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 sur 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 une mise en cache efficace et améliore les performances des requêtes.
  • Vous pouvez dimensionner différemment vos instances principales et de pool de lecture 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. Il n'est pas nécessaire d'activer le moteur columnar sur l'instance principale.

Envisagez d'utiliser des fonctionnalités intégrées telles que le conseiller d'index pour vous aider à ajouter des index susceptibles d'améliorer les performances des requêtes.

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 complètes de tables ou des agrégations. 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 par défaut du moteur en colonnes consomme 30 % de 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 de benchmarking OLAP pour AlloyDB pour PostgreSQL.

Types de déploiement

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 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 avec 16 vCPU ou plus, qui offre 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 effectuez de nombreuses opérations d'écriture et des lectures analytiques sensibles à la latence avec de faibles exigences de décalage, déployez l'instance principale avec la haute disponibilité activée et avec des instances de pool de lecture.
  • Activez le moteur 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 une mise en cache efficace et améliore les performances des requêtes.
  • Vous pouvez dimensionner différemment vos instances principales et de pool de lecture 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. Il n'est pas nécessaire d'activer le moteur columnar sur l'instance principale.

Étapes suivantes