Évaluer les performances OLTP sur AlloyDB pour PostgreSQL

Ce document explique comment configurer AlloyDB pour PostgreSQL et une machine cliente pour é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 avec lecture et écriture intensives, comme Index Insert Only et Select Only.

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 entreprise 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 relationnelle nécessitent généralement qu'un administrateur de base de données optimise la base de données pour les tests comparatifs. Cela inclut la configuration des paramètres du journal des transactions, l'établissement de la taille appropriée du pool de mémoire tampon et la modification d'autres paramètres, indicateurs ou caractéristiques de la base de données. 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 vous oblige pas à ajuster les indicateurs au niveau de la base de données pour obtenir des performances OLTP élevées. En effet, AlloyDB offre des performances OLTP élevées par défaut.

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 incluant des statistiques et des métriques de performances détaillées.

HammerDB permet de personnaliser les paramètres de benchmark. Vous pouvez ainsi 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 HammerDB TPC-C 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 de benchmarking fourni avec PostgreSQL. Il vous permet de simuler des charges de travail transactionnelles telles que l'insertion, la mise à jour et la sélection de données, et de mesurer les 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 mix de transactions pour émuler votre charge de travail de production et obtenir des informations sur le comportement du système dans différents scénarios.
pgbench inclut une implémentation TPC-B. L'implémentation pgbench TPC-B 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.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify 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.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

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

    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 à AlloyDB à l'aide d'un réseau VPC qui réside dans le même projet Google Cloud qu'AlloyDB.

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

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

    Commencez 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 de 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 le nom du 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 17.

    7. Notez l'emplacement de la zone principale et de 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 dotée d'une puissance de traitement adéquate. Les outils de benchmarking tels que HammerDB et pgbench s'exécutent de manière très parallèle et consomment beaucoup de ressources de processeur. Une machine cliente ne doit pas être 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 comme client pour les benchmarks OLTP afin de piloter une instance AlloyDB sur une machine à 16 processeurs 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, suivez ces étapes pour créer une VM Compute Engine et provisionner une machine cliente :

    1. Dans la console Google Cloud , 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 Mise en réseau, puis définissez 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 à l'API, définissez Niveaux d'accès 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 pilote de référence

    Après avoir installé et configuré la base de données et la machine cliente, 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 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 les tests TPC-B et OLTP divers 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é.

    Nettoyer les benchmarks

    Si vous prévoyez d'exécuter plusieurs benchmarks de suite, vous devez effectuer un nettoyage de benchmark entre chaque benchmark pour garantir des résultats précis et fiables.

    Le nettoyage du benchmark permet de s'assurer 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 d'assurer 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.

    Suivez ces étapes pour nettoyer les benchmarks avant d'en exécuter un autre :

    1. Supprimez les données de référence ou la base de données de référence précédentes. Pour supprimer l'ancienne base de données de benchmark, utilisez la commande psql suivante à partir de 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 Se connecter à une base de données.

    2. Redémarrez l'instance AlloyDB. Cette étape efface 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 du 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 incluant des statistiques détaillées et des métriques de performances. De plus, HammerDB permet de personnaliser les paramètres de benchmark. Les utilisateurs peuvent ainsi 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 mis en cache (~30 %) : dans ce mode, une grande base de données TPC-C est générée, qui ne peut être que partiellement insérée dans le cache du tampon. Les transactions dans ce mode ne sont pas toujours traitées à partir de la mémoire et entraînent des E/S vers les sous-systèmes de stockage sous-jacents. Ce scénario s'applique aux besoins OLTP de nombreux utilisateurs.

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

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

    Configurer la machine cliente

    1. Configurez la machine pilote de benchmark.

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

    3. Ouvrez le fichier 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 mises en surbrillance par celles qui conviennent le mieux à la configuration de votre environnement.

    6. Facultatif : Testez le mode partiellement mis en cache (~30 %) en remplaçant NUM_WAREHOUSE par 3200 dans le fichier setup.env. Pour en savoir plus, consultez 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 Scénarios d'évaluation des performances.

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

    Une étape de chargement fait référence au processus de remplissage de la base de données de benchmark 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 remplie avec un nombre spécifié d'entrepôts, de clients et d'autres entités, conformément aux spécifications TPC-C. L'objectif de l'étape de charge est de créer une charge de travail réaliste pour le test de performances et de s'assurer que les résultats du test sont comparables sur 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. Passez au répertoire d'accueil du benchmark à l'aide de la commande suivante :

      cd hammerdb/HammerDB-4.6

    2. Copiez le contenu suivant et 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 le chargement. Une fois le script précédent terminé, nous vous recommandons de vérifier que le chargement 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 100 % 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 remplie lors de l'étape de chargement. Le benchmark génère une série de transactions qui simulent un environnement professionnel typique, y compris la saisie des 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 traiter 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 se servent souvent des 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 et 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 du benchmark

    Dans les benchmarks TPC-C, les nouvelles commandes par minute (NOPM) et les transactions par minute (TPM) sont des métriques de performances 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 plus importantes du benchmark TPC-C. Elle consiste à créer une commande pour un client.

    • TPM : mesure le nombre total de transactions commerciales effectuées que le système peut traiter 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 de nouvelles commandes, tels que 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 (nouvelles commandes par minute) à partir d'un TPM AlloyDB cumulé de 582 385.

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

    Sur une base de données TPC-C mise en cache à 100 % sur une machine à 16 processeurs virtuels (avec NUM_WAREHOUSE=576 et NUM_USERS=256), vous observez 428 316 tpm-C (nouvelles commandes 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 performances de référence pour une machine à 16 processeurs virtuels :

    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 afin d'observer les métriques système importantes, comme l'utilisation du processeur et de la mémoire, et les transactions par seconde. Pour en savoir plus, consultez 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 entièrement mise en cache est de près de 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 processeurs virtuels, vous devez suivre les mêmes étapes de configuration que dans Exécuter un benchmark TPC-C, mais en utilisant 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 la machine pilote de benchmark.

    Exécuter le benchmark

    1. Si vous exécutez plusieurs benchmarks de 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 processeurs virtuels.
      • Pour le scénario TPC-C mis en cache à 30 %, 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 comme suit : diset tpcc pg_num_vu 64.

    4. Exécutez le benchmark TPC-C.

    Analyser les résultats du benchmark

    Le tableau suivant récapitule les résultats des tests de performances sur une machine à 64 processeurs virtuels :

    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 pgbench TPC-B

    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 guichetiers exécutent des transactions sur des comptes client. La charge de travail se compose des types de transactions suivants :

    • Acomptes
    • Retraits
    • Demandes concernant le 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, ne l'utilisez pas pour revendiquer la conformité aux normes TPC-B.

    Scénarios pour mesurer les performances

    Cette section décrit 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 (environ 650 Go) à l'aide de --scale= 50000. Une grande base de données qui ne tient pas en mémoire et qui provoque des E/S disque importantes constitue une représentation réaliste de nombreuses charges de travail de production.

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

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

    Dans ce scénario, vous allez configurer et initialiser une base de données d'environ 60 Go à l'aide de --scale=4000 afin qu'elle réside dans le pool de mémoire tampon. Il est important de comparer une base de données résidente en mémoire, car cela 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 des E/S qui peut se produire lors de l'accès aux données à partir du disque. Ce mode peut vous aider à identifier les goulots d'étranglement des 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 évaluez 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 pgbench TPC-B, 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 la machine pilote de benchmark.

    4. Effectuez un nettoyage de référence.

    Exécuter le benchmark pgbench TPC-B

    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 du paramètre suivant 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 être adaptées au type de machine et à la taille de la base de données (entièrement 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.

      Mise en cache complète Partiellement mis en cache
      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 benchmarking est créé et rempli avec des données réalistes, ce qui vous permet de simuler précisément 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 attendus :

      • 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 : Vérifiez l'exactitude du chargement en vous assurant que le contenu du fichier /tmp/pgbench-tpcb-partially-cached-db-init.out est semblable à ce qui suit :

      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 plus précisément l'exactitude de votre chargement, 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 une charge de travail de système de comptabilité financière en exécutant une série de transactions impliquant des dépôts, des transferts et des paiements. Cela 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 du benchmark

    Vérifiez le résultat de la commande précédente dans le fichier ~/results/alloydb/pgbench/pgbench.run.out. Le nombre de TPS doit être proche de ceux affichés dans les scénarios de base de données entièrement mise en cache et 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 de la section Exécuter le benchmark pgbench TPC-B 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, l'utilisation de la mémoire et les transactions par seconde à l'aide de la console Google Cloud . Pour en savoir plus, consultez Surveiller les instances.

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

    Le résultat de la dernière commande de la section Exécuter le benchmark pgbench TPC-B 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 pour un benchmark pgbench TPC-B :

    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 "Index Insert Only"

    Le benchmark "Index Insert Only" est un scénario à forte concurrence et à forte intensité d'écriture. Il est personnalisé dans cette section pour montrer les avantages en termes 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 à plusieurs reprises des opérations d'insertion sur la table pgbench_history à partir de plusieurs connexions clientes.

    Les benchmarks "Index Only Insert" mesurent les performances d'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 à forte intensité d'écriture, AlloyDB propose des innovations architecturales, y compris une couche de cache hiérarchisée 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 permettant d'exécuter un benchmark "Index Only Insert" (Insertion avec 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 la machine pilote de benchmark.

    4. Effectuez un nettoyage de référence.

    Exécuter le benchmark "Index Insert Only"

    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 en utilisant l'exemple suivant. Si la base de données existe déjà, supprimez-la et 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 benchmarking est créé et rempli avec des 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 le résultat de la commande précédente ressemble à ce qui suit :

      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 du benchmark

    Vérifiez le résultat de la commande précédente dans le fichier /tmp/pgbench-index-insert-only-run.out. Vous devriez observer 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 résultat 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 "Select Only" sur une instance à 64 vCPU

    pgbench est compatible avec un scénario intégré en lecture seule qui exécute de manière répétée 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 introduire la surcharge des opérations de modification de données telles que INSERT, UPDATE ou DELETE. Ces requêtes SELECT sont des requêtes de recherche ponctuelle qui sont le type de requêtes SELECT le plus rapide et le plus efficace, car elles n'impliquent d'accéder qu'à une seule ligne de données directement à partir des structures d'index.

    L'exécution d'une analyse comparative "Sélectionner uniquement" vous permet d'obtenir les résultats suivants :

    • Atteindre le débit maximal : les recherches ponctuelles dans un index étant la forme de requête la plus efficace dans un système de base de données, vous pouvez mesurer le débit maximal 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 à 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 le résultat de la commande précédente ressemble à ce qui suit :

      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 du benchmark

    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 indiqué dans l'exemple de résultat 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 du benchmark AlloyDB

    Les tableaux suivants récapitulent les résultats des tests de référence AlloyDB basés sur les tests effectués dans ce document.

    Synthèse des performances HammerDB TPC-C

    Type de machine AlloyDB Scénario de charge de travail TPC-C NUM_WAREHOUSE NUM_USERS Nouvelles commandes par minute (NCPM) 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

    Récapitulatif des performances de pgbench

    Type de machine AlloyDB Scénario de charge de travail pgbench Facteur d'échelle TPS % de processeur
    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 Inserts d'index uniquement 25 000 51 742 88 %
    64 vCPU Débit maximal (sélection uniquement) 15000 467 583 95 %

    Exécuter 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 processeurs virtuels pour une analyse comparative. Cette section explique comment configurer une instance 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 évaluer les performances OLTP. Dans ce scénario, vous devez choisir le SKU 16 vCPU, activer la haute disponibilité (HA) et préconfigurer 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.

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    3. Verify that billing is enabled for your Google Cloud project.

    4. Install the Google Cloud CLI.

    5. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

    6. Pour initialiser la gcloud CLI, exécutez la commande suivante : 

      gcloud init

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

      Roles required to select or create a project

      • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
      • Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

      Go to project selector

    8. Verify that billing is enabled for your Google Cloud project.

    9. Install the Google Cloud CLI.

    10. Si vous utilisez un fournisseur d'identité (IdP) externe, vous devez d'abord vous connecter à la gcloud CLI avec votre identité fédérée.

    11. Pour initialiser la gcloud CLI, exécutez la commande suivante : 

      gcloud init
    12. 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

      13. 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
        • Choisir une configuration avec laquelle commencer : production
        • Choisissez la disponibilité régionale et zonale : sélectionnez us-central1 comme région.
        • Disponibilité zonale : plusieurs zones (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 de mémoire. Il s'agit de la machine la plus proche que Cloud SQL pour PostgreSQL propose à l'instance AlloyDB correspondante que vous avez créée dans la section sur les benchmarks 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 son adresse IP privée. Vous utilisez l'adresse IP comme 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 dotée d'une puissance de calcul 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 du 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 amener le serveur à sa pleine capacité.

      3. Si vous avez créé une machine cliente, configurez la machine pilote du benchmark. Sinon, suivez les instructions de ce guide pour le benchmark que vous souhaitez exécuter.

      Étapes suivantes