Évaluer les performances OLTP sur AlloyDB pour PostgreSQL

Ce document explique comment configurer AlloyDB pour PostgreSQL et une machine cliente afin d'évaluer les performances d'AlloyDB à l'aide de TPC-C, une spécification de benchmark OLTP. Ce document explique également comment exécuter des scénarios OLTP personnalisés axés sur les lectures et les écritures, tels que Index Insert Only (Insérer uniquement dans l'index) et Select Only (Sélectionner uniquement).

Les instructions de ce document sont basées sur une configuration spécifique d'AlloyDB et de la machine cliente. Utilisez les valeurs fournies pour chaque étape des instructions de benchmarking.

Fonctionnalités de charge de travail AlloyDB

AlloyDB offre une fiabilité, une évolutivité et des performances de niveau professionnel adaptées à toutes les entreprises et à toutes les charges de travail critiques. AlloyDB fournit les composants et fonctionnalités suivants qui permettent d'obtenir des performances élevées pour vos charges de travail transactionnelles (OLTP), analytiques (OLAP) et hybrides (HTAP) :

  • Gestion des journaux et des transactions
  • Gestion dynamique de la mémoire
  • Intégration de l'intelligence artificielle et du machine learning
  • Moteur de données en colonnes intégré
  • Un cache à plusieurs niveaux
  • Stockage distribué et évolutif

Les systèmes de base de données relationnelles nécessitent généralement un administrateur de base de données pour optimiser la base de données à des fins de benchmarking, ce qui inclut la configuration des paramètres du journal des transactions, l'établissement des tailles de pool de tampons appropriées et la modification d'autres paramètres de base de données, d'indicateurs et de caractéristiques. Ces paramètres varient en fonction de la taille et du type d'instance.

AlloyDB est préconfiguré avec des paramètres optimisés pour chaque type de machine. AlloyDB ne nécessite pas d'ajuster les indicateurs au niveau de la base de données pour obtenir des performances OLTP élevées. Au lieu de cela, AlloyDB intègre des performances OLTP élevées.

Types de benchmarks acceptés

Ce document vous explique comment exécuter des benchmarks OLTP à l'aide des outils suivants:

Pilotes de benchmark OLTP Cas d'utilisation
HammerDB HammerDB mesure les performances du système en termes de transactions par minute (TPM) et génère des rapports qui incluent des statistiques détaillées et des métriques de performances.

HammerDB est compatible avec la personnalisation des paramètres de référence, ce qui vous permet d'ajuster la taille de la base de données, le nombre d'entrepôts et d'autres caractéristiques de la charge de travail pour simuler différents scénarios.

HammerDB inclut une implémentation de benchmark TPC-C pour évaluer les performances des systèmes OLTP. L'implémentation TPC-C de HammerDB vous permet de simuler une charge de travail semblable au benchmark TPC-C, y compris un mélange de transactions qui imitent le comportement d'un environnement de fournisseur en gros.
pgbench pgbench est un outil d'analyse comparative fourni avec PostgreSQL. pgbench vous permet de simuler des charges de travail transactionnelles telles que l'insertion, la mise à jour, la sélection de données et la mesure des performances du système de base de données en transactions par seconde (TPS).

Lorsque vous utilisez pgbench, vous pouvez personnaliser la taille de la base de données, le nombre de clients et le mélange de transactions pour émuler votre charge de travail de production et obtenir des insights sur le comportement du système dans différents scénarios.
pgbench inclut une implémentation TPC-B. L'implémentation TPC-B de pgbench est semblable à un benchmark TPC-B.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. Activez les API Cloud nécessaires pour créer et vous connecter à AlloyDB pour PostgreSQL.

    Activer les API

    1. À l'étape Confirmer le projet, cliquez sur Suivant pour confirmer le nom du projet que vous allez modifier.

    2. À l'étape Activer les API, cliquez sur Activer pour activer les éléments suivants:

      • API AlloyDB
      • API Compute Engine
      • API Cloud Resource Manager
      • API Service Networking

      L'API Service Networking est requise si vous prévoyez de configurer la connectivité réseau vers AlloyDB à l'aide d'un réseau VPC situé dans le même projet Google Cloud qu'AlloyDB.

      L'API Compute Engine et l'API Cloud Resource Manager sont requises si vous prévoyez de configurer la connectivité réseau à AlloyDB à l'aide d'un réseau VPC situé dans un autre projet Google Cloud.

Configurer et provisionner la base de données et la machine cliente

Démarrez l'analyse comparative en créant un cluster et une instance AlloyDB. Sauf indication contraire, les informations de ce document sont basées sur une instance AlloyDB principale avec 16 vCPU et 128 Go de RAM.

Créer un cluster et une instance AlloyDB

  1. Accédez à la page Clusters.

    accéder aux clusters

  2. Cliquez sur Créer un cluster.

  3. Dans le champ ID du cluster, saisissez un nom pour votre cluster.

  4. Dans Disponibilité zonale, sélectionnez Plusieurs zones (haute disponibilité) pour le type de cluster.

  5. Sélectionnez le réseau par défaut.

  6. Dans le champ Version de la base de données, sélectionnez PostgreSQL 15.

  7. Notez l'emplacement de la zone principale et l'adresse IP privée. Ne créez pas de pool de lecture.

  8. Cliquez sur Créer un cluster.

Provisionner la machine cliente

Pour exécuter des benchmarks OLTP, vous avez besoin d'une machine cliente disposant d'une puissance de traitement adéquate. Les outils d'analyse comparative tels que HammerDB et pgbench s'exécutent de manière très parallèle et consomment beaucoup de CPU. Une machine cliente ne doit pas constituer un goulot d'étranglement lorsque vous exécutez un benchmark OLTP.

Sauf indication contraire, les instructions de ce document utilisent une machine E2-standard-32 avec un disque de 128 Go en tant que client pour les benchmarks OLTP afin de piloter une instance AlloyDB sur une machine avec 16 CPU virtuels et 128 Go de RAM. Vous devez créer la machine cliente dans la même zone que l'instance principale AlloyDB.

Pour exécuter le benchmark TPC-C sur une instance principale AlloyDB avec 16 CPU virtuels, procédez comme suit pour créer une VM Compute Engine et provisionner une machine cliente:

  1. Dans Google Cloud Console, accédez à la page Instances de VM.

    Accéder à la page Instances de VM

  2. Sélectionnez le projet contenant l'instance AlloyDB à laquelle vous souhaitez vous connecter.
  3. Cliquez sur Créer une instance.
  4. Cliquez sur la section Configuration de la machine.
  5. Entrez un nom pour l'instance.
  6. Configurez la zone dans laquelle vous souhaitez créer l'instance. La zone doit être la même que celle de l'instance principale AlloyDB.
  7. Sélectionnez le type de machine e2-standard-32.
  8. Conservez les valeurs par défaut dans la section OS et stockage.
  9. Cliquez sur la section Networking (Mise en réseau), puis définissez Network interfaces (Interfaces réseau) sur le réseau VPC configuré pour l'accès aux services privés à AlloyDB.
    Si Interfaces réseau n'est pas défini sur le réseau VPC configuré pour l'accès aux services privés, développez-le, puis définissez Réseau sur le réseau VPC.
  10. Conservez les valeurs par défaut dans la section Observabilité.
  11. Cliquez sur la section Sécurité.
  12. Dans Identité et accès aux API, définissez Champs d'application sur Autoriser l'accès complet à l'ensemble des API Cloud.
  13. Conservez les valeurs par défaut dans la section Avancé.
  14. Cliquez sur Créer.
  15. Une fois la VM créée, connectez-vous à la VM Compute Engine que vous avez créée à l'aide de SSH.

Configurer la machine du pilote de référence

Après avoir installé et configuré la base de données et la machine cliente, vous configurez la machine cliente exécutée sur Google Cloud, où vous installez des outils de benchmarking tels que HammerDB et pgbench.

Pour configurer la machine du pilote de référence, procédez comme suit:

  1. Connectez-vous à la machine cliente à l'aide de la commande gcloud compute ssh suivante:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME"  --project "GOOGLE_PROJECT"

  2. Installez le client PostgreSQL.

    1. Utilisez la commande suivante pour installer un client PostgreSQL qui inclut une application psql, puis assurez-vous de pouvoir vous connecter.

      sudo apt-get update
sudo apt install postgresql-client

    2. Utilisez la commande suivante pour vous assurer que le client fonctionne et que vous pouvez vous connecter à AlloyDB. Utilisez l'adresse IP privée de votre instance AlloyDB principale.

      psql -h PRIVATE_IP -U postgres

  3. Installez le pilote HammerDB-4.6 pour le benchmark TPC-C en exécutant les commandes suivantes:

    mkdir hammerdb
pushd hammerdb
curl -OL https://github.com/TPC-Council/HammerDB/releases/download/v4.6/HammerDB-4.6-Linux.tar.gz
tar zxvf HammerDB-4.6-Linux.tar.gz

  4. Installez le pilote pgbench pour TPC-B et divers benchmarks OLTP en exécutant les commandes suivantes:

    sudo apt-get update
sudo apt-get install postgresql-contrib
pgbench --version

    Si pgbench --version s'exécute sans erreur, cela signifie que pgbench est installé.

Effectuer un nettoyage de benchmark

Si vous prévoyez d'exécuter plusieurs benchmarks à la suite, vous devez effectuer un nettoyage entre chaque benchmark pour vous assurer que les résultats des benchmarks sont précis et fiables.

Un nettoyage de benchmark garantit que les effets résiduels des benchmarks précédents n'affectent pas les mesures de performances du nouveau benchmark. Le nettoyage des benchmarks permet également de garantir la cohérence et la répétabilité des résultats des benchmarks, ce qui est essentiel pour effectuer des comparaisons pertinentes entre différents systèmes ou identifier les domaines d'optimisation du matériel, des logiciels ou de la configuration.

Pour effectuer un nettoyage avant d'exécuter un autre benchmark, procédez comme suit:

  1. Supprimez les données de référence ou la base de données de référence précédentes. Pour supprimer la base de données de référence précédente, utilisez la commande psql suivante sur la machine cliente:

    psql -h PRIVATE_IP -U postgres -c "DROP DATABASE IF EXISTS <database_name>;"

    Pour en savoir plus sur l'utilisation de psql, consultez la section Se connecter à une base de données.

  2. Redémarrez l'instance AlloyDB. Cette étape vide les caches au niveau de la base de données et du système d'exploitation.

Exécuter un benchmark TPC-C

HammerDB est un outil de benchmarking qui inclut une implémentation de benchmark TPC-C pour évaluer les performances des systèmes OLTP. L'implémentation TPC-C de HammerDB vous permet de simuler une charge de travail semblable au benchmark TPC-C, y compris un mélange de transactions qui imitent le comportement d'un environnement de fournisseur en gros.

HammerDB mesure les performances du système en termes de transactions par minute (TPM) et génère des rapports qui incluent des statistiques détaillées et des métriques de performances. De plus, HammerDB permet de personnaliser les paramètres de référence, ce qui permet aux utilisateurs d'ajuster la taille de la base de données, le nombre d'entrepôts et d'autres caractéristiques de la charge de travail pour simuler différents scénarios.

Scénarios d'évaluation des performances

Les performances du benchmark TPC-C sont évaluées à l'aide des méthodes suivantes:

  • Mode partiellement (environ 30%) mis en cache:dans ce mode, une grande base de données TPC-C est générée, qui ne peut tenir que partiellement dans le cache tampon. Les transactions dans ce mode ne sont pas toujours servies à partir de la mémoire et entraînent des E/S sur les sous-systèmes de stockage sous-jacents. Ce scénario s'applique aux besoins OLTP de nombreux utilisateurs.

  • Mode entièrement (100%) mis en cache:dans ce mode, la base de données TPC-C s'intègre entièrement dans le cache tampon. L'instance AlloyDB utilise environ 90% des 128 Go de RAM disponibles, y compris le cache tampon.

    Étant donné que les transactions TPC-C effectuent des E/S minimales (car les lectures sont principalement gérées à partir du cache de mémoire tampon), dans ce mode, un TPM plus élevé est attendu par rapport aux exécutions partiellement mises en cache. Ce scénario s'applique aux besoins OLTP des utilisateurs ayant des besoins d'E/S très faibles.

Configurer la machine cliente

  1. Configurez l'ordinateur sur lequel vous allez effectuer les benchmarks.

  2. Si vous exécutez plusieurs benchmarks à la suite, effectuez un nettoyage des benchmarks.

  3. Ouvrez hammerdb/HammerDB-4.6 directory en exécutant la commande suivante:

    cd hammerdb/HammerDB-4.6

    Vous exécutez des commandes à partir de ce répertoire pour configurer la machine cliente.

  4. Créez le fichier setup.env à l'aide des commandes suivantes:

    cat << EOF > setup.env
# Private IP of the AlloyDB primary instance
export PGHOST=PRIVATE_IP
# Postgres default port address. You do not need to change it unless you use non-default port address.
export PGPORT=5432   # default port to connect with postgres
# Number of TPC-C warehouses to load. This determines the overall database size.
export NUM_WAREHOUSE=576
# Number of users for running the benchmark.
export NUM_USERS=256
EOF

  5. Modifiez le fichier setup.env généré en remplaçant toutes les valeurs de paramètre en surbrillance par celles qui correspondent le mieux à la configuration de votre environnement.

  6. Facultatif: Testez le mode mis en cache partiellement (~30%) en remplaçant NUM_WAREHOUSE par 3200 dans le fichier setup.env. Pour en savoir plus, consultez la section Scénarios d'évaluation des performances.

  7. Facultatif: Testez le mode entièrement mis en cache (100%) en remplaçant NUM_WAREHOUSE par 576 dans setup.env file. Pour en savoir plus, consultez la section Scénarios d'évaluation des performances.

Charger des données TPC-C dans la base de données

Une étape de chargement fait référence au processus qui consiste à renseigner la base de données de référence avec des données initiales avant d'exécuter le test de performances.

Lors de l'étape de chargement, la base de données est renseignée avec un nombre spécifié d'entrepôts, de clients et d'autres entités, conformément aux spécifications TPC-C. L'étape de charge a pour but de créer une charge de travail réaliste pour le test de performances et de s'assurer que les résultats des tests sont comparables entre les différents systèmes.

Une fois l'étape de chargement terminée, la base de données est dans un état cohérent avec un ensemble défini de données initiales, prêt à être utilisé pour le test de référence TPC-C.

Pour charger la base de données TPC-C, procédez comme suit:

  1. Accédez au répertoire d'accueil de l'analyse comparative à l'aide de la commande suivante:

    cd hammerdb/HammerDB-4.6

  2. Copiez le contenu suivant, puis collez-le dans build-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

# create role tpcc with superuser login as 'postgres' and password as 'AlloyDB#123';
# -----------------------------------------------------

./hammerdbcli << EOF

# CONFIGURE PARAMETERS FOR TPCC BENCHMARK
# --------------------------------------
dbset db pg
dbset bm tpc-c

# CONFIGURE POSTGRES HOST AND PORT
# --------------------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC
# --------------------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user tpcc
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# SET NUMBER OF WAREHOUSES AND USERS TO MANAGE EACH WAREHOUSE
# THIS IMPORTANT METRIC ESTABLISHES THE DATABASE SCALE/SIZE
# --------------------------------------
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 10

# LOG OUTPUT AND CONFIGURATION DETAILS
# --------------------------------------
vuset logtotemp 1
print dict

# CREATE AND POPULATE DATABASE SCHEMA
# --------------------------------------
buildschema

waittocomplete
vudestroy
quit

EOF

  3. Exécutez la commande de chargement suivante et attendez qu'elle se termine.

    chmod +x ./build-tpcc.sh
mkdir results
sudo nohup ./build-tpcc.sh > results/build-tpcc.out 2>&1

  4. Validez la charge. Une fois le script précédent terminé, nous vous recommandons de vérifier que la charge de la base de données a réussi. Pour vérifier la taille de la base de données, exécutez la commande suivante:

    psql -h $PGHOST -p 5432 -U postgres
postgres=> \l+ tpcc
                                                                          List of databases
     Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size   | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+---------+------------+--------------------------------------------
 tpcc         | tpcc             | UTF8     | C.UTF-8 | C.UTF-8 |                                       | --- GB  | pg_default |
           |                  |          |         |         |                                       | 160.000 |            |
 (1 row)

Dans une configuration TPC-C mise en cache à 30 % (avec 3 200 entrepôts), la taille de la base de données tpcc devrait être d'environ 300 Go.

Dans une configuration TPC-C entièrement mise en cache (avec 576 entrepôts), la taille de la base de données tpcc devrait être d'environ 55 Go.

Exécuter le benchmark TPC-C

Vous êtes maintenant prêt à exécuter le test de performances TPC-C. Le benchmark TPC-C est exécuté à l'aide de la base de données renseignée à l'étape de chargement. Le benchmark génère une série de transactions qui simulent un environnement commercial typique, y compris la saisie de commandes, le traitement des paiements et la gestion des stocks. La charge de travail est mesurée en transactions par minute (TPM), ce qui représente le nombre de transactions commerciales complètes que le système peut gérer en une minute.

L'étape d'exécution est conçue pour solliciter le système de base de données dans des conditions réalistes et pour fournir une méthode standard de mesure des performances que vous pouvez comparer entre différents systèmes de base de données. Les fournisseurs et les utilisateurs utilisent souvent les résultats du benchmark TPC-C pour évaluer les performances de différents systèmes de base de données et configurations matérielles.

Pour exécuter le benchmark TPC-C, procédez comme suit:

  1. Accédez au répertoire d'accueil du benchmark:

    cd hammerdb/HammerDB-4.6

  2. Copiez le contenu suivant, puis collez-le dans run-tpcc.sh:

    #!/bin/bash -x

source ./setup.env

./hammerdbcli << EOF
dbset db pg
dbset bm tpc-c

# CONFIGURE PG HOST and PORT
# -------------------------
diset connection pg_host $PGHOST
diset connection pg_port $PGPORT

# CONFIGURE TPCC DB
# -------------------------
diset tpcc pg_superuser postgres
diset tpcc pg_superuserpass AlloyDB#123
diset tpcc pg_user postgres
diset tpcc pg_pass AlloyDB#123
diset tpcc pg_dbase tpcc

# BENCHMARKING PARAMETERS
# -------------------------
diset tpcc pg_driver timed
diset tpcc pg_rampup 10
diset tpcc pg_duration 60
diset tpcc pg_vacuum false
diset tpcc pg_partition false
diset tpcc pg_allwarehouse true
diset tpcc pg_timeprofile true
diset tpcc pg_connect_pool false
diset tpcc pg_dritasnap false
diset tpcc pg_count_ware $NUM_WAREHOUSE
diset tpcc pg_num_vu 1

loadscript
print dict
vuset logtotemp 1
vuset vu $NUM_USERS
vucreate
vurun
waittocomplete
quit
EOF

  3. Exécutez le script à l'aide des commandes suivantes:

    chmod +x run-tpcc.sh
mkdir results
sudo nohup ./run-tpcc.sh > results/run-tpcc.out 2>&1

  4. Attendez que le script run-tpcc.sh se termine. L'exécution du script prend environ une heure et 10 minutes. Une fois le script terminé, vous pouvez analyser les résultats.

Analyser les résultats des benchmarks

Dans le benchmark TPC-C, les métriques de performances "Nouveaux ordres par minute" (NOPM) et "Transactions par minute" (TPM) sont utilisées pour mesurer les performances d'un système de base de données.

  • NOPM:mesure le nombre de transactions de nouvelles commandes que le système peut traiter en une minute. La transaction de nouvelle commande est l'une des transactions les plus importantes du benchmark TPC-C. Elle implique la création d'une nouvelle commande pour un client.

  • TPM:mesure le nombre total de transactions commerciales terminées que le système peut gérer en une minute. Les transactions incluent les transactions de nouvelles commandes, ainsi que d'autres types de transactions définis dans le benchmark TPC-C, tels que le paiement, la livraison et l'état de la commande.

    Le TPM est la principale métrique de performances du benchmark TPC-C, car il fournit une mesure globale de la capacité du système à gérer une charge de travail réaliste. Le NOPM peut être une métrique utile pour les systèmes axés sur le traitement des nouvelles commandes, comme les systèmes d'e-commerce ou de vente au détail.

Afficher les résultats avec une base de données TPC-C mise en cache à 30% sur une machine à 16 vCPU

Pour extraire les chiffres de performances de ce scénario, utilisez la commande suivante:

grep NOPM results/run-tpcc.out

Voici le résultat attendu:

Vuser 1:TEST RESULT : System achieved 252970 NOPM from 582385 PostgreSQL TPM

Avec une base de données TPC-C mise en cache à 30% sur une machine à 16 processeurs virtuels (avec NUM_WAREHOUSE=3200 et NUM_USERS=256), vous observez 252 970 tpm-C (nouvelle commande par minute) à partir d'un TPM AlloyDB cumulé de 582 385.

Afficher les résultats avec une base de données TPC-C entièrement mise en cache sur une machine à 16 processeurs virtuels

Sur une base de données TPC-C entièrement mise en cache sur une machine à 16 processeurs virtuels (avec NUM_WAREHOUSE=576 et NUM_USERS=256), vous observez 428 316 tpm-C (nouvelle commande par minute) à partir d'un TPM AlloyDB cumulé de 974 264.

Pour extraire les chiffres de performances de ce scénario, utilisez la commande suivante:

grep NOPM results/tpcc-run.out

Voici le résultat attendu:

Vuser 1:TEST RESULT : System achieved 428316 NOPM from 974264 PostgreSQL TPM

Résumé des résultats de performances sur une machine à 16 processeurs virtuels

Le tableau suivant récapitule les résultats des benchmarks de performances pour une machine à 16 vCPU:

Scénario TPC-C NUM_WAREHOUSE NUM_USERS NOPM TPM cumulé
30% en cache 3200 256 252 970 582 385
100% en cache 576 256 428 316 974 264

Observer les métriques de performances de la base de données

Pour mieux comprendre le comportement de votre système de base de données, utilisez les outils de surveillance AlloyDB pour observer des métriques système importantes telles que l'utilisation du processeur, l'utilisation de la mémoire et les transactions par seconde. Pour en savoir plus, consultez la section Surveiller les performances des instances.

Par exemple, après avoir exécuté ce benchmark, vous pouvez observer sur la page Présentation d'AlloyDB dans la console Google Cloud que l'utilisation moyenne du processeur pour l'exécution TPC-C 100% mise en cache est d'environ 90%.

Exécuter un benchmark TPC-C sur une instance AlloyDB 64 vCPU

Pour exécuter un benchmark TPC-C sur une instance AlloyDB à 64 CPU virtuels, suivez les mêmes étapes de configuration que dans Exécuter un benchmark TPC-C, mais utilisez différents types de machines.

Configurer AlloyDB et la machine cliente

  1. Créez un cluster et une instance AlloyDB, en remplaçant 64 vCPU, 512GB par le type de machine.

  2. Provisionnez la machine cliente, en remplaçant n2-standard-64 par le type de machine.

  3. Configurez l'ordinateur sur lequel vous allez effectuer les benchmarks.

Exécuter le benchmark

  1. Si vous exécutez plusieurs benchmarks à la suite, effectuez un nettoyage des benchmarks.

  2. Configurez la machine cliente en remplaçant les valeurs suivantes:

    • Définissez PGHOST sur l'adresse IP privée de votre nouvelle instance AlloyDB 64 vCPU.
    • Pour le scénario TPC-C avec 30% de cache, définissez NUM_WAREHOUSE=12800 et NUM_USERS=1024.
    • Pour le scénario TPC-C 100% mis en cache, définissez NUM_WAREHOUSE=2304 et NUM_USERS=1024.

  3. Configurez et chargez une base de données TPC-C. Pour accélérer le chargement, remplacez la valeur de pg_num_vu par 64 dans build-tpcc.sh en tant que diset tpcc pg_num_vu 64.

  4. Exécutez le benchmark TPC-C.

Analyser les résultats des benchmarks

Le tableau suivant récapitule les résultats des benchmarks sur une machine à 64 vCPU:

Mode benchmark NUM_WAREHOUSE NUM_USERS NOPM TPM cumulé
30% en cache 12800 1 024 589 598 1 371 160
100% en cache 2304 1 024 716 138 1 665 438

Exécuter un benchmark TPC-B pgbench

TPC-B (Transaction Processing Performance Council Benchmark B) est l'un des modes de benchmark disponibles dans pgbench, un outil de benchmark pour PostgreSQL. TPC-B simule un scénario bancaire dans lequel plusieurs guichets effectuent des transactions sur les comptes client. La charge de travail se compose des types de transactions suivants:

  • Dépôts
  • Retraits
  • Demandes de solde

Le benchmark mesure les performances du système de base de données en simulant un mélange de ces transactions et en mesurant le nombre de transactions par seconde que le système peut gérer.

Le mode TPC-B de pgbench génère une base de données synthétique et simule un mélange de transactions qui ressemble à la charge de travail TPC-B, mais il n'est pas officiellement certifié par l'organisation TPC. Par conséquent, bien que le mode TPC-B de pgbench fournisse une approximation utile des performances TPC-B, n'utilisez pas cet outil pour prétendre être conforme aux normes TPC-B.

Scénarios pour mesurer les performances

Cette section explique comment mesurer les performances TPC-B dans les modes critiques suivants. Le seul paramètre qui diffère dans ces modes est la valeur du paramètre SCALE_FACTOR.

Scénario de base de données partiellement mise en cache

Dans ce scénario, vous allez configurer et initialiser une grande base de données (d'environ 650 Go) à l'aide de --scale= 50000. Une base de données volumineuse qui ne tient pas en mémoire et qui génère des E/S de disque importantes fournit une représentation réaliste de nombreuses charges de travail de production.

Une base de données volumineuse qui génère des E/S de disque importantes peut souligner l'importance de la conception de la base de données et de l'optimisation des requêtes. Une base de données volumineuse peut également révéler des problèmes de performances liés aux E/S de disque, tels qu'un accès au disque lent ou des requêtes inefficaces, qui peuvent ne pas être apparents dans une base de données petite ou entièrement en mémoire.

Scénario de base de données entièrement mise en cache

Dans ce scénario, vous configurez et initialisez une base de données d'environ 60 Go à l'aide de --scale=4000 afin qu'elle réside dans le pool de tampons. L'analyse comparative d'une base de données en mémoire est importante, car elle vous permet d'évaluer les performances maximales du système de base de données dans un environnement contrôlé.

Une base de données résidente en mémoire stocke toutes les données dans le pool de mémoire tampon PostgreSQL, ce qui élimine le goulot d'étranglement d'E/S pouvant se produire lors de l'accès aux données à partir du disque. Ce mode peut vous aider à identifier les goulots d'étranglement de performances qui ne sont pas liés aux E/S, tels que l'utilisation du processeur ou les problèmes de verrouillage, qui peuvent ne pas être apparents lorsque vous effectuez un benchmark d'une base de données qui repose sur les E/S de disque.

Configurer le serveur de base de données et la machine cliente

Pour configurer l'infrastructure afin d'exécuter un benchmark TPC-B pgbench, procédez comme suit:

  1. Créez un cluster et une instance AlloyDB, en remplaçant 16 vCPU, 128GB par le type de machine.

  2. Provisionnez la machine cliente, en remplaçant E2-standard-16 (minimum) par le type de machine.

  3. Configurez l'ordinateur sur lequel vous allez effectuer les benchmarks.

  4. Effectuez un nettoyage des analyses comparatives.

Exécuter le benchmark TPC-B pgbench

  1. Connectez-vous à la machine cliente à l'aide de la commande Google Cloud CLI suivante:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. Créez le fichier pgbench-setup.env :

    $ cat << EOF > pgbench-setup.env

# Private IP of the AlloyDB primary instance
export PGHOST=<private_ip>

# Set PGUSER to postgres as a default user.
export PGUSER=postgres

# Password set for PGUSER
export PGPASSWORD=<your pg password>

# In pgbench, the scale factor represents the size of the test database.
# and is defined as the number of 1 MB-sized data pages to be generated per client.
export SCALE_FACTOR=<scale_factor>

# Number of clients to drive the benchmark in throughput mode
export NUM_CLIENTS=<num_clients>

EOF

  3. Modifiez le fichier setup.env généré et remplacez la valeur de paramètre suivante par des valeurs adaptées à la configuration de votre environnement.

    • PRIVATE_IP: adresse IP privée de votre instance AlloyDB.

    Utilisez le tableau suivant pour choisir les valeurs <scale_factor> et <num_clients>. Ces valeurs doivent évoluer en fonction du type de machine et de la taille de la base de données (entièrement mise en cache ou partiellement mise en cache). Les exemples de ce guide utilisent les valeurs SCALE_FACTOR et NUM_CLIENT correspondant au type de machine n2-highmem-16.

    En cache complet En cache partiellement
    Type de machine SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25 000 128
    n2-highmem-16 4000 384 50 000 256
    n2-highmem-32 8000 768 100000 512
    n2-highmem-64 16000 1536 200000 1 024

  4. Créez une base de données pgbench.

    source ./pgbench-setup.env
psql -h $PGHOST -p 5432
postgres=> create database pgbench;
CREATE DATABASE

  5. Initialisez et chargez la base de données pgbench en exécutant les commandes suivantes. Cette étape permet de s'assurer que l'ensemble de données de référence est créé et rempli de données réalistes, ce qui vous permet de simuler avec précision une charge de travail TPC-B sur la base de données pgbench.

    source ./pgbench-setup.env
sudo nohup pgbench -i --host=$PGHOST --scale=$SCALE_FACTOR pgbench > /tmp/pgbench-tpcb-partially-cached-db-init.out 2>&1

    Temps de chargement estimés:

    • Le chargement de la base de données partiellement mise en cache prend environ six heures.
    • Le chargement de la base de données entièrement mise en cache prend environ 45 minutes.

  6. Facultatif: effectuez une vérification de la précision de la charge en vous assurant que le contenu du fichier /tmp/pgbench-tpcb-partially-cached-db-init.out est semblable à celui-ci:

    generating data (client-side)...
100000 of 400000000 tuples (0%) done (elapsed 0.02 s, remaining 99.82 s)
.. .. ..
.. .. ..
399800000 of 400000000 tuples (99%) done (elapsed 534.60 s, remaining 0.27 s)
399900000 of 400000000 tuples (99%) done (elapsed 534.72 s, remaining 0.13 s)
400000000 of 400000000 tuples (100%) done (elapsed 534.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 1481.92 s (drop tables 0.01 s, create tables 0.04 s, client-side generate 540.93 s, vacuum 615.11 s, primary keys 325.84 s).

  7. Facultatif: Pour valider davantage la précision de votre charge, exécutez la commande PostgreSQL suivante, qui mesure la taille de toutes les tables pgbench:

    1. Connectez-vous à la base de données pgbench:

      source ./pgbench-setup.env
psql -h $PGHOST -p 5432 -U postgres -d pgbench

    2. Exécutez la commande SQL suivante:

      pgbench=> SELECT nspname AS schema_name, relname AS table_name, pg_size_pretty(pg_total_relation_size(C.oid)) AS size FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema'
ORDER BY pg_total_relation_size(C.oid) DESC;

    3. Comparez la sortie de la commande précédente à celle que vous avez obtenue pour l'exécution de la base de données partiellement mise en cache (SCALE_FACTOR=50000).

       schema_name |                table_name                 |  size
 -------------+-------------------------------------------+---------
 public      | pgbench_accounts                          | 731 GB
 public      | pgbench_accounts_pkey                     | 105 GB
 public      | pgbench_tellers                           | 32 MB
 public      | pgbench_tellers_pkey                      | 11 MB
 public      | pgbench_branches                          | 2952 kB
 public      | pgbench_branches_pkey                     | 1112 kB
 .. .. ..
 public      | pgbench_history                           | 0 bytes
 .. .. ..
 (29 rows)

  8. Exécutez les commandes suivantes pour simuler la charge de travail d'un système de comptabilité financière en exécutant une série de transactions impliquant des dépôts, des transferts et des paiements, ce qui vous permet de mesurer les performances de la base de données sous une charge de travail importante.

    source ./pgbench-setup.env
mkdir -p ~/results/alloydb/pgbench
sudo nohup pgbench --host=$PGHOST --builtin=tpcb-like --time=3900 --jobs=$NUM_CLIENTS --client=$NUM_CLIENTS --scale=$SCALE_FACTOR --protocol=prepared --progress=1 pgbench > ~/results/alloydb/pgbench/pgbench.run.out 2>&1

Analyser les résultats des benchmarks

Vérifiez la sortie de la commande précédente dans le fichier ~/results/alloydb/pgbench/pgbench.run.out. Le nombre de TPS doit être proche des nombres affichés dans les scénarios de base de données entièrement mise en cache et de base de données partiellement mise en cache.

Résultats avec une base de données entièrement mise en cache

Le résultat de la dernière commande dans Exécuter le benchmark TPC-B pgbench doit ressembler à ce qui suit, où --scale=4000:

transaction type: <builtin: TPC-B (sort of)>
scaling factor: 4000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 84819501
latency average = 17.654 ms
latency stddev = 6.963 ms
tps = 21747.831164 (including connections establishing)
tps = 21750.579718 (excluding connections establishing)

Pour mieux comprendre le comportement du système de base de données, vous pouvez surveiller les métriques système telles que l'utilisation du processeur, de la mémoire et des transactions par seconde à l'aide de la console Google Cloud. Pour en savoir plus, consultez la section Surveiller les instances.

Résultats avec une base de données partiellement mise en cache

Le résultat de la dernière commande dans Exécuter le benchmark TPC-B pgbench doit ressembler à ce qui suit, où --scale=50000:

pgbench: warning: scale option ignored, using count from pgbench_branches table (50000)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>

scaling factor: 50000
query mode: prepared
number of clients: 384
number of threads: 384
duration: 3900 s
number of transactions actually processed: 68073405
latency average = 21.992 ms
latency stddev = 29.272 ms
tps = 17453.913041 (including connections establishing)
tps = 17460.373303 (excluding connections establishing)

Résumé des résultats de performances pour un benchmark pgbench TPC-B

Le tableau suivant récapitule les résultats de performances d'un benchmark TPC-B pgbench:

Scénario TPC-B SCALE_FACTOR TPS Utilisation du processeur (%)
Partiellement mis en cache 50 000 17 460 96 %
Entièrement mis en cache 4000 21 750 94 %

Exécuter un benchmark d'insertion d'index uniquement

Le benchmark d'insertion d'index uniquement est un scénario très concurrent et intensif en écriture qui est personnalisé dans cette section pour montrer les avantages de performances d'AlloyDB pour la majorité des applications OLTP. Pour exécuter ce benchmark, vous devez créer plusieurs index sur la table pgbench_history, puis effectuer des opérations INSERT à plusieurs reprises sur la table pgbench_history à partir de plusieurs connexions client.

Les benchmarks d'insertion uniquement dans l'index mesurent les performances de l'insertion de données dans une table de base de données, en se concentrant spécifiquement sur l'impact des index sur l'opération d'écriture. Ce benchmark vous permet de comprendre la rapidité avec laquelle de nouvelles lignes peuvent être ajoutées à une table avec et sans index, en mettant en évidence le ralentissement potentiel causé par la maintenance des index lors des insertions.

AlloyDB améliore les performances d'écriture de PostgreSQL, ce qui améliore également les charges de travail OLTP. Pour améliorer les performances des scénarios OLTP intensifs en écriture, AlloyDB propose des innovations architecturales, y compris une couche de cache à plusieurs niveaux pour faciliter les lectures et une technologie de moteur de stockage distribuée et hautement évolutive pour les écritures.

Configurer AlloyDB et la machine cliente

Pour configurer l'infrastructure afin d'exécuter un benchmark d'insertion en mode index uniquement, procédez comme suit:

  1. Créez un cluster et une instance AlloyDB, en remplaçant 16 vCPU and 128 GB RAM par le type de machine.

  2. Provisionnez la machine cliente, en remplaçant E2-standard-16 (minimum) par le type de machine.

  3. Configurez l'ordinateur sur lequel vous allez effectuer les benchmarks.

  4. Effectuez un nettoyage des analyses comparatives.

Exécuter le benchmark d'insertion d'index uniquement

  1. Connectez-vous à la machine cliente à l'aide de l'exemple de commande suivant:

    gcloud compute ssh --zone "<primary zone>" "<client machine name>" --project "<google-project>"

  2. Configurez l'environnement en exécutant la commande suivante:

    export PGHOST=<private_ip>

  3. Créez une base de données pgbench à l'aide de l'exemple suivant. Si la base de données existe déjà, supprimez-la, puis recréez-la.

    psql -h $PGHOST -p 5432 -U postgres -c "DROP DATABASE IF EXISTS pgbench"
psql -h $PGHOST -p 5432 -U postgres -c "CREATE DATABASE pgbench"

  4. Initialisez et chargez la base de données pgbench pour vous assurer que l'ensemble de données de référence est créé et rempli de données réalistes. Modifiez les paramètres mis en surbrillance, puis exécutez la commande suivante:

    sudo nohup pgbench -i  --host=$PGHOST --user=postgres --scale=25000 pgbench > /tmp/pgbench-index-insert-only-init.out 2>&1
...

postgres=> create database pgbench;
CREATE DATABASE pgbench

  5. Vérifiez que la sortie de la commande précédente ressemble à ceci:

    dropping old tables...
creating tables...
generating data (client-side)...
100000 of 2500000000 tuples (0%) done (elapsed 0.03 s, remaining 636.43 s)
200000 of 2500000000 tuples (0%) done (elapsed 0.05 s, remaining 649.12 s)
.. .. ..
.. .. ..
2499900000 of 2500000000 tuples (99%) done (elapsed 3425.42 s, remaining 0.14 s)
2500000000 of 2500000000 tuples (100%) done (elapsed 3425.57 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 12851.19 s (drop tables 998.62 s, create tables 0.02 s, client-side generate 3460.33 s, vacuum 5299.93 s, primary keys 3092.29 s).

  6. Créez le script index-init.sql à l'aide des commandes suivantes:

    cat > index-init.sql << EOF
CREATE INDEX tid ON pgbench_history(tid);
CREATE INDEX bid ON pgbench_history(bid);
CREATE INDEX aid ON pgbench_history(aid);
CREATE INDEX delta ON pgbench_history(delta);
CREATE INDEX mtime ON pgbench_history(mtime);
EOF

  7. Exécutez le script index-init.sql:

    psql -h $PGHOST -U postgres -d pgbench -f ./index-init.sql
Password for user postgres:
CREATE INDEX

  8. (Facultatif) Validez le schéma de la base de données et le chargement initial :

    psql -h $PGHOST -U postgres -d pgbench

pgbench=> \dt
           List of relations
Schema |       Name       | Type  |  Owner
--------+------------------+-------+----------
 public | pgbench_accounts | table | postgres
 public | pgbench_branches | table | postgres
 public | pgbench_history  | table | postgres
 public | pgbench_tellers  | table | postgres
(4 rows)

pgbench=> \di
                       List of relations
 Schema |         Name          | Type  |  Owner   |      Table
--------+-----------------------+-------+----------+------------------
 public | aid                   | index | postgres | pgbench_history
 public | bid                   | index | postgres | pgbench_history
 public | delta                 | index | postgres | pgbench_history
 public | mtime                 | index | postgres | pgbench_history
 public | pgbench_accounts_pkey | index | postgres | pgbench_accounts
 public | pgbench_branches_pkey | index | postgres | pgbench_branches
 public | pgbench_tellers_pkey  | index | postgres | pgbench_tellers
 public | tid                   | index | postgres | pgbench_history
(8 rows)

    Après le chargement, la taille de la base de données devrait être d'environ 365 Go:

    pgbench=> \l+ pgbench
                         List of databases
Name     |      Owner       | Encoding | Collate |  Ctype  |           Access privileges           |  Size  | Tablespace |                Description
 --------------+------------------+----------+---------+---------+---------------------------------------+--------+------------+--------------------------------------------
...
 pgbench      | postgres         | UTF8     | C.UTF-8 | C.UTF-8 |                                       | 365 GB | pg_default |
...

  9. Créez le script index-inserts-only.sql à l'aide des commandes suivantes:

    cat > index-inserts-only.sql << EOF
\set aid random(1, 1000000000)
\set bid random(1, 1000000000)
\set tid random(1, 1000000000)
\set delta random(-500000000, 500000000)
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;
EOF

  10. Exécutez le benchmark pgbench à l'aide de la commande suivante:

    sudo nohup pgbench --host=$PGHOST --user=postgres --time=3900 --client=256 --jobs=256 --scale=25000 --progress=1 --file=./index-inserts-only.sql pgbench > /tmp/pgbench-index-insert-only-run.out 2>&1

Analyser les résultats des benchmarks

Vérifiez la sortie de la commande précédente dans le fichier /tmp/pgbench-index-insert-only-run.out. Vous devriez voir environ 52 000 transactions par seconde et un taux d'utilisation du processeur d'environ 88% lors de ce test de référence, comme illustré dans l'exemple de sortie suivant.

scaling factor: 25000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 201785196
latency average = 4.947 ms
latency stddev = 3.488 ms
tps = 51738.604613 (including connections establishing)
tps = 51742.459757 (excluding connections establishing)

Exécuter un benchmark "Sélectionner uniquement" sur une instance 64 vCPU

pgbench prend en charge un scénario intégré, réservé aux requêtes SELECT, qui exécute à plusieurs reprises des requêtes SELECT à partir de plusieurs connexions client sur une base de données spécifiée. Ce benchmark permet de mesurer les performances de lecture de la base de données, sans entraîner les coûts liés aux opérations de modification des données telles que INSERT, UPDATE ou DELETE. Ces requêtes SELECT sont des requêtes de recherche de point qui constituent le type de requêtes SELECT le plus rapide et le plus efficace, car elles n'impliquent que l'accès à une seule ligne de données directement à partir des structures d'index.

Exécuter une analyse comparative "Sélectionner uniquement" vous permet d'effectuer les opérations suivantes:

  • Atteindre le débit maximal: comme les recherches ponctuelles sur un indice sont la forme de requêtes la plus efficace dans un système de base de données, vous pouvez mesurer le débit maximal possible qu'AlloyDB peut atteindre.

  • Évolutivité: seuls certains benchmarks vous aident à tester l'évolutivité d'AlloyDB de 2 vCPU à la configuration maximale de vCPU proposée par AlloyDB.

Configurer AlloyDB et la machine cliente

Configurez AlloyDB et la machine cliente sur un type de machine avec 64 processeurs virtuels.

Exécuter le benchmark "Sélectionner uniquement"

  1. Connectez-vous à la machine cliente à l'aide de l'exemple de commande suivant:

    gcloud compute ssh --zone "PRIMARY_ZONE" "CLIENT_MACHINE_NAME" --project "GOOGLE_PROJECT"

  2. Configurez l'environnement à l'aide de la commande suivante:

    export PGHOST=<private_ip>

  3. Créez la base de données pgbench à l'aide de l'exemple suivant:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Initialisez la base de données pgbench. La commande suivante initialise la base de données pgbench avec environ 220 Go de données réalistes. Vous utilisez --scale=15000 pour le benchmark "Sélectionner uniquement" entièrement mis en cache.

    Exécutez la commande suivante :

    sudo nohup pgbench -i --host=$PGHOST --user=postgres --scale=15000 pgbench > /tmp/pgbench-select-only-init.out 2>&1

  5. Vérifiez que la sortie de la commande précédente ressemble à ceci:

    cat /tmp/pgbench-select-only-init.out
nohup: ignoring input
dropping old tables...
creating tables...
generating data (client-side)...
100000 of 1500000000 tuples (0%) done (elapsed 0.01 s, remaining 161.60 s)
200000 of 1500000000 tuples (0%) done (elapsed 0.03 s, remaining 224.35 s)
300000 of 1500000000 tuples (0%) done (elapsed 0.09 s, remaining 448.97 s)
.. .. ..
.. .. ..
1499900000 of 1500000000 tuples (99%) done (elapsed 1251.03 s, remaining 0.08 s)
1500000000 of 1500000000 tuples (100%) done (elapsed 1251.10 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 2204.62 s (drop tables 2.29 s, create tables 0.01 s, client-side generate 1271.82 s, vacuum 427.83 s, primary keys 502.66 s).

  6. Exécutez pgbench. Cette dernière étape de benchmarking prend plus d'une heure.

    sudo nohup pgbench --host=$PGHOST --user=postgres  --builtin=select-only --time=3900 --jobs=256 --client=256 --scale=15000 --protocol=simple --progress=1 pgbench > /tmp/pgbench-select-only-run.out  2>&1

  7. Une fois le benchmark terminé, consultez le fichier /tmp/pgbench-select-only-run.out pour obtenir les résultats finaux.

Analyser les résultats des benchmarks

Vous devriez observer environ 467 000 transactions par seconde et un taux d'utilisation du processeur d'environ 95% lors de ce test de référence, comme illustré dans l'exemple de sortie suivant.

cat /tmp/pgbench-select-only-run.out
transaction type: <builtin: select only>
scaling factor: 15000
query mode: simple
number of clients: 256
number of threads: 256
duration: 3900 s
number of transactions actually processed: 1823506174
latency average = 0.547 ms
latency stddev = 0.267 ms
tps = 467563.144333 (including connections establishing)
tps = 467583.398400 (excluding connections establishing)

Récapitulatif des résultats des benchmarks AlloyDB

Les tableaux suivants récapitulent les résultats des benchmarks AlloyDB en fonction des tests effectués dans ce document.

Résumé des performances TPC-C de HammerDB

Type de machine AlloyDB Scénario de charge de travail TPC-C NUM_WAREHOUSE NUM_USERS Nouvelles commandes par minute (NOPM) TPM cumulé Converti en TPS
16 vCPU 30% en cache 3200 256 252 970 582 385 9 706
16 vCPU 100% en cache 576 256 428 316 974 264 16 238
64 vCPU 30% en cache 12800 1 024 589 598 1 371 160 22 853
64 vCPU 100% en cache 2304 1 024 716 138 1 665 438 27 757

Synthèse des performances de pgbench

Type de machine AlloyDB Scénario de charge de travail pgbench Facteur d'échelle TPS %de CPU
16 vCPU TPC-B Like, Fully Cached 4000 20 359 96 %
16 vCPU TPC-B Like, Partially Cached 50 000 14 060 94 %
16 vCPU Insérer uniquement des index 25 000 51 742 88 %
64 vCPU Débit maximal (sélection uniquement) 15000 467 583 95 %

Effectuer des benchmarks OLTP sur Cloud SQL pour PostgreSQL

Vous pouvez tester des performances OLTP équivalentes sur PostgreSQL dans Cloud SQL pour PostgreSQL sur un type de machine à 16 vCPU pour une analyse comparative. Cette section explique comment configurer un Cloud SQL pour PostgreSQL (ou tout serveur PostgreSQL déployé sur l'infrastructure de votre choix) comparable à la configuration AlloyDB utilisée dans ce guide pour comparer les performances OLTP. Dans ce scénario, cela inclut le choix du SKU 16 vCPU, l'activation de la haute disponibilité (HA) et la préconfiguration avec le stockage.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Install the Google Cloud CLI.

  5. To initialize the gcloud CLI, run the following command: 

    gcloud init

  6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  7. Make sure that billing is enabled for your Google Cloud project.

  8. Install the Google Cloud CLI.

  9. To initialize the gcloud CLI, run the following command: 

    gcloud init
  10. Assurez-vous de disposer des rôles d'administrateur Cloud SQL et de lecteur de Compute sur votre compte utilisateur.

    Accéder à la page IAM

    En savoir plus sur les rôles et les autorisations

Provisionner une instance Cloud SQL pour PostgreSQL

  1. Créez une instance PostgreSQL en remplaçant les valeurs suivantes:

    • Version de la base de données: PostgreSQL 14
    • Choisissez une configuration de départ: production
    • Choisir la disponibilité régionale et zonale: sélectionnez us-central1 comme région.
    • Disponibilité zonale: zones multiples (haute disponibilité)
      • Zone principale: us-central1-c
      • Zone secondaire: us-central-1-f
    • Type de machine: machine à haute capacité de mémoire avec 16 processeurs virtuels et 104 Go Il s'agit de la machine la plus proche que Cloud SQL pour PostgreSQL propose de l'instance AlloyDB correspondante que vous avez créée dans la section "Benchmarking AlloyDB" de ce document.
    • Capacité de stockage: personnalisée, 1 500 Go
      • Activer l'augmentation automatique de l'espace de stockage
    • Chiffrement: Google-owned and Google-managed encryption key
    • Connexions: adresse IP privée
      • Réseau : default
      • Adresse IP publique: activée

  2. Cliquez sur Créer une instance.

  3. Une fois l'instance PostgreSQL créée, notez l'adresse IP privée. Vous utilisez l'adresse IP en tant que PGHOST pour établir des connexions avec le benchmark.

Provisionner la machine cliente

  1. Provisionnez une instance Cloud SQL pour PostgreSQL. Pour exécuter le benchmark OLTP de votre choix, vous avez besoin d'une machine cliente avec une puissance de processeur importante dans la même zone que l'instance Cloud SQL pour PostgreSQL principale dans Cloud SQL.

  2. Facultatif: Au lieu de l'étape précédente, vous pouvez utiliser la même machine cliente que celle que vous avez configurée pour le benchmarking AlloyDB, à condition que les conditions suivantes soient remplies:

    • La machine cliente se trouve dans la même zone que la nouvelle instance principale PostgreSQL (Cloud SQL pour PostgreSQL).
    • La machine cliente répond aux exigences minimales en termes de processeur, de RAM et de taille de disque.

    Dans ce guide de benchmarking, vous avez réutilisé les machines clientes lorsqu'elles étaient colocalisées dans la même zone que l'instance principale et lorsqu'elles étaient suffisamment grandes pour exploiter toute la capacité du serveur.

  3. Si vous avez créé une machine cliente, configurez la machine du pilote de référence. Sinon, suivez les instructions de ce guide pour le benchmark qui vous intéresse.

Étape suivante