Recommandations de dimensionnement et de déploiement

Ce document fournit des recommandations sur les charges de travail et le déploiement pour dimensionner les instances AlloyDB pour PostgreSQL à la fois 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
  • Délai de réplication faible
  • Maintenance non intrusive avec un temps d'arrêt inférieur à une seconde pour l'instance principale et nul pour les nœuds du pool de lecture lors des opérations d'ajustement de l'échelle

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
  • Modifier les indicateurs ayant un impact sur les performances

Considérations concernant le 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 en termes de latence et de débit
  • Taille de 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 (PRA).

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 journaux d'écriture anticipée (WAL) sont conservés dans le stockage régional, tandis que la matérialisation de blocs est transférée vers le stockage.

De même, avec une architecture de cache multicouche, les données sont automatiquement placées entre le cache tampon, le cache ultra-rapide 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 et de sortie par seconde (E/S) ne sont pas pertinentes dans le contexte d'AlloyDB pour PostgreSQL pour comparer avec d'autres systèmes de base de données.

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

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

  1. Identifiez votre charge de travail existante. Si vous effectuez une migration à partir de votre PostgreSQL autogéré ou 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 de TPS.
  4. Consultez le guide de benchmarking OLTP d'AlloyDB pour PostgreSQL. Ce guide fournit des données de performances pour différentes configurations AlloyDB pour PostgreSQL afin de trouver une configuration qui répond à vos exigences de TPS.
  5. Choisissez une taille AlloyDB pour PostgreSQL appropriée. Tenez compte de la taille actuelle de vos données et de vos attentes de croissance future.

Consignes concernant la taille des machines

L'exemple de tableau suivant présente des recommandations pour les données avec un benchmark TPC-C ayant un ratio lecture/écriture d'environ 65% de lectures et 35% d'écritures. Lorsque vous dimensionnez une instance AlloyDB pour PostgreSQL, vous devez viser une utilisation du processeur à l'état stable d'environ 60 à 70% pour éviter les frais généraux de planification du système d'exploitation. Cela permet de laisser une marge pour les pics d'utilisation des ressources par les applications clientes.

vCPU/Mem Transactions/s recommandées
Plage (30% en cache)		 Taille de données de travail
recommandée (jusqu'à 128 To au total)		 Valeur max_connections recommandée
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 Go / 512 Go Jusqu'à 20 000 Jusqu'à 8 To 5000
96 / 768 Go Jusqu'à 25 000 Jusqu'à 16 To 5000
128 / 864 Go Plus de 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 instance de pool de lecture.

Principale uniquement

Choisissez le déploiement principal uniquement pour les charges de travail suivantes:

  • Écritures intensives avec des lectures faibles à moyennes
  • Requêtes axées sur la lecture avec des écritures 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 sur la taille des machines.

Principale avec instance de 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 qui offrent un délai de réplication 25 fois inférieur à celui de PostgreSQL standard. Vous pouvez configurer jusqu'à 20 nœuds pour toutes les instances de pool de lecture.
  • Configurez plusieurs instances de pool de lecture si vous disposez de 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 pool 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 les 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. Pour ce faire, vous n'avez pas besoin d'activer le moteur de colonnes 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 métrique de dimensionnement principale est les performances des requêtes, en particulier les requêtes qui nécessitent des analyses de table complètes 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 du moteur de données en colonnes par défaut consomme 30% de la mémoire et utilise automatiquement des données de cache ultra-rapides.

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 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 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 avec 16 vCPU ou plus, qui offre plus de mémoire pour stocker des données en colonnes.

Principal 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 écritures et des lectures analytiques sensibles à la latence avec des exigences de latence faibles, 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 dans lesquelles vous exécutez vos requêtes analytiques.
  • Configurez plusieurs instances de pool de lecture si vous disposez de 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 pool 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 les 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. Pour ce faire, vous n'avez pas besoin d'activer le moteur de colonnes sur l'instance principale.

Étape suivante