Eseguire il benchmarking delle prestazioni OLTP su AlloyDB per PostgreSQL

Per valutare il throughput e la latenza dei workload transazionali in AlloyDB per PostgreSQL, puoi configurare AlloyDB e una macchina client per eseguire il benchmark delle prestazioni dell'elaborazione delle transazioni online (OLTP) utilizzando TPC-C, una specifica di benchmark OLTP standard di settore. Puoi anche eseguire scenari OLTP personalizzati con un'elevata intensità di lettura e scrittura, come Index Insert Only e Select Only.

Le istruzioni riportate in questo documento si basano su una configurazione specifica di AlloyDB e della macchina client. Utilizza i valori forniti per ogni passaggio delle istruzioni di benchmarking.

Funzionalità dei workload di AlloyDB

AlloyDB offre affidabilità, scalabilità e prestazioni di livello enterprise adatte a tutte le aziende e ai workload critici. AlloyDB fornisce i seguenti componenti e funzionalità che consentono prestazioni elevate per i workload transazionali (OLTP), analitici (OLAP) e ibridi (HTAP):

  • Gestione dei log e delle transazioni
  • Gestione dinamica della memoria
  • Integrazione di intelligenza artificiale e machine learning
  • Motore colonnare integrato
  • Una cache multilivello
  • Archiviazione distribuita e scalabile

I sistemi di database relazionali in genere richiedono a un amministratore di database di ottimizzare il database per il benchmarking, il che include la configurazione delle impostazioni del log delle transazioni, la definizione delle dimensioni corrette del pool di buffer e la modifica di altri parametri o flag e caratteristiche del database. Queste impostazioni variano in base alle dimensioni e al tipo di istanza.

AlloyDB è preconfigurato con impostazioni ottimizzate per ogni tipo di macchina. AlloyDB non richiede di ottimizzare i flag a livello di database per ottenere prestazioni OLTP elevate, poiché queste sono integrate in AlloyDB.

Tipi di benchmark supportati

Questo documento mostra come eseguire benchmark OLTP utilizzando i seguenti strumenti:

Driver di benchmark OLTP Casi d'uso
HammerDB HammerDB misura le prestazioni del sistema in termini di transazioni al minuto (TPM) e genera report che includono statistiche dettagliate e metriche sul rendimento.

HammerDB supporta la personalizzazione dei parametri di benchmark, che consente di regolare le dimensioni del database, il numero di warehouse e altre caratteristiche del workload per simulare scenari diversi.

HammerDB include un'implementazione del benchmark TPC-C per valutare le prestazioni dei sistemi OLTP. L'implementazione TPC-C di HammerDB ti consente di simulare un workload simile al benchmark TPC-C, incluso un mix di transazioni che simulano il comportamento di un ambiente di fornitori all'ingrosso.
pgbench pgbench è uno strumento di benchmarking incluso in PostgreSQL. pgbench ti consente di simulare workload di transazioni come l'inserimento, l'aggiornamento, la selezione dei dati e la misurazione delle prestazioni del sistema di database in transazioni al secondo (TPS).

Quando utilizzi pgbench, puoi personalizzare le dimensioni del database, il numero di client e la combinazione di transazioni per emulare il workload di produzione e ottenere insight sul comportamento del sistema in diversi scenari.
pgbench include un'implementazione TPC-B. L'implementazione di pgbench TPC-B è simile a un benchmark TPC-B.

Prima di iniziare

  1. 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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  3. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  4. Abilitare le API Cloud necessarie per creare e connettersi ad AlloyDB per PostgreSQL.

    Abilita le API

    1. Nel passaggio Conferma progetto, fai clic su Avanti per confermare il nome del progetto a cui apporterai le modifiche.

    2. Nel passaggio Abilita API, fai clic su Abilita per abilitare quanto segue:

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

      L'API Service Networking è obbligatoria se prevedi di configurare la connettività di rete ad AlloyDB utilizzando una rete VPC che si trova nello stesso progetto Google Cloud di AlloyDB.

      L'API Compute Engine e l'API Cloud Resource Manager sono necessarie se prevedi di configurare la connettività di rete ad AlloyDB utilizzando una rete VPC che si trova in un progetto Google Cloud diverso.

Configura ed esegui il provisioning del database e della macchina client

Avvia il benchmark creando un cluster e un'istanza AlloyDB. Se non diversamente specificato, le informazioni contenute in questo documento si basano su un'istanza AlloyDB principale con 16 vCPU e 128 GB di RAM.

Crea un cluster e un'istanza AlloyDB

  1. Vai alla pagina Cluster.

    Vai a Cluster

  2. Fai clic su Crea cluster.

  3. Nel campo ID cluster, inserisci un nome per il cluster.

  4. In Disponibilità a livello di zona, seleziona Più zone (alta affidabilità) per il tipo di cluster.

  5. Seleziona la rete predefinita.

  6. Nel campo Versione database, seleziona una delle seguenti opzioni:

    • PostgreSQL 17

    • PostgreSQL 18

  7. Prendi nota della località della zona principale e dell'indirizzo IP privato. Non creare un pool di lettura.

  8. Fai clic su Crea cluster.

Esegui il provisioning della macchina client

Per eseguire i benchmark OLTP, è necessaria una macchina client con una potenza di elaborazione adeguata. Gli strumenti di benchmark come HammerDB e pgbench vengono eseguiti in modo altamente parallelo e consumano molta CPU. Una macchina client non deve essere un collo di bottiglia quando esegui un benchmark OLTP.

Salvo diversa indicazione, le istruzioni in questo documento utilizzano una macchina E2-standard-32 con disco da 128 GB come client per i benchmark OLTP per gestire un'istanza AlloyDB su una macchina con 16 vCPU e 128 GB di RAM. Devi creare la macchina client nella stessa zona dell'istanza principale di AlloyDB.

Per eseguire il benchmark TPC-C su un'istanza principale AlloyDB con 16 CPU virtuali, segui questi passaggi per creare una VM Compute Engine ed eseguire il provisioning di una macchina client:

  1. Nella console Google Cloud , vai alla pagina Istanze VM.

    Vai a Istanze VM

  2. Seleziona il progetto contenente l'istanza AlloyDB a cui vuoi connetterti.
  3. Fai clic su Crea istanza.
  4. Fai clic sulla sezione Configurazione macchina.
  5. Inserisci un Nome per l'istanza.
  6. Configura la zona in cui vuoi creare l'istanza. La zona deve essere la stessa dell'istanza AlloyDB principale.
  7. Seleziona un tipo di macchina e2-standard-32.
  8. Mantieni i valori predefiniti nella sezione Sistema operativo e spazio di archiviazione.
  9. Fai clic sulla sezione Networking e imposta Interfacce di rete sulla rete VPC configurata per l'accesso privato ai servizi per AlloyDB.
    Se l'opzione Interfacce di rete non è impostata sulla rete VPC configurata per l'accesso privato ai servizi, espandila e imposta Rete sulla rete VPC.
  10. Mantieni i valori predefiniti nella sezione Osservabilità.
  11. Fai clic sulla sezione Sicurezza.
  12. In Identità e accesso API, imposta Ambiti di accesso su Consenti l'accesso completo a tutte le API Cloud.
  13. Mantieni i valori predefiniti nella sezione Avanzate.
  14. Fai clic su Crea.
  15. Dopo aver creato la VM, connettiti alla VM di Compute Engine che hai creato utilizzando SSH.

Configura la macchina driver del benchmark

Dopo aver installato e configurato il database e la macchina client, configura la macchina client in esecuzione su Google Cloud, dove installi gli strumenti di benchmarking come HammerDB e pgbench.

Per configurare la macchina del driver di benchmark, segui questi passaggi:

  1. Connettiti alla macchina client utilizzando il seguente comando gcloud compute ssh:

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

  2. Installa il client PostgreSQL.

    1. Utilizza il seguente comando per installare un client PostgreSQL che include un'applicazione psql, quindi assicurati di riuscire a connetterti.

      sudo apt-get update
sudo apt install postgresql-client

    2. Utilizza il comando seguente per assicurarti che il client funzioni e che tu possa connetterti ad AlloyDB. Utilizza l'indirizzo IP privato dell'istanza AlloyDB principale.

      psql -h PRIVATE_IP -U postgres

  3. Installa il driver HammerDB-4.6 per il benchmark TPC-C eseguendo i seguenti comandi:

    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. Installa il driver pgbench per il benchmarking TPC-B e vari OLTP eseguendo i seguenti comandi:

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

    Se pgbench --version viene eseguito senza errori, significa che pgbench è installato.

Esegui una pulizia del benchmark

Se prevedi di eseguire più benchmark in successione, devi eseguire una pulizia tra un benchmark e l'altro per garantire risultati di benchmarking accurati e affidabili.

La pulizia del benchmark garantisce che gli effetti residui dei benchmark precedenti non influiscano sulle misurazioni delle prestazioni del nuovo benchmark. Le pulizie dei benchmark contribuiscono anche a garantire la coerenza e la ripetibilità dei risultati dei benchmark, il che è essenziale per effettuare confronti significativi tra sistemi diversi o identificare aree di ottimizzazione nell'hardware, nel software o nella configurazione.

Segui questi passaggi per eseguire una pulizia del benchmark prima di eseguirne un altro:

  1. Elimina i dati di benchmark o il database di benchmark precedenti. Per eliminare il database di benchmark precedente, utilizza il seguente comando psql dalla macchina client:

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

    Per saperne di più sull'utilizzo di psql, consulta Connettiti a un database.

  2. Riavvia l'istanza AlloyDB. Questo passaggio svuota le cache a livello di database e di sistema operativo.

Esegui un benchmark TPC-C

HammerDB è uno strumento di benchmarking che include un'implementazione del benchmark TPC-C per valutare le prestazioni dei sistemi OLTP. L'implementazione TPC-C di HammerDB ti consente di simulare un workload simile al benchmark TPC-C, incluso un mix di transazioni che simulano il comportamento di un ambiente di fornitori all'ingrosso.

HammerDB misura le prestazioni del sistema in termini di transazioni al minuto (TPM) e genera report che includono statistiche dettagliate e metriche sul rendimento. Inoltre, HammerDB supporta la personalizzazione dei parametri di benchmark, consentendo agli utenti di modificare le dimensioni del database, il numero di magazzini e altre caratteristiche del workload per simulare scenari diversi.

Scenari di valutazione del rendimento

Le prestazioni del benchmark TPC-C vengono valutate utilizzando i seguenti metodi:

  • Modalità parzialmente memorizzata nella cache (~30%):in questa modalità viene generato un database TPC-C di grandi dimensioni, che può essere inserito solo parzialmente nella cache del buffer. Le transazioni in questa modalità non vengono sempre gestite dalla memoria e comportano operazioni di I/O nei sottosistemi di archiviazione sottostanti. Questo scenario è applicabile alle esigenze OLTP di molti utenti.

  • Modalità completamente (100%) memorizzata nella cache: in questa modalità, il database TPC-C si adatta completamente alla cache del buffer. L'istanza AlloyDB utilizza circa il 90% dei 128 GB di RAM disponibili, inclusa la cache del buffer.

    Poiché le transazioni TPC-C eseguono un numero minimo di I/O, in quanto le letture vengono gestite principalmente dalla cache del buffer, in questa modalità è previsto un TPM più elevato rispetto alle esecuzioni parzialmente memorizzate nella cache. Questo scenario è applicabile alle esigenze OLTP degli utenti con esigenze di I/O molto basse.

Configura la macchina client

  1. Configura la macchina driver del benchmark.

  2. Se esegui più benchmark in successione, esegui una pulizia del benchmark.

  3. Apri hammerdb/HammerDB-4.6 directory eseguendo questo comando:

    cd hammerdb/HammerDB-4.6

    Esegui i comandi da questa directory per configurare la macchina client.

  4. Crea il file setup.env utilizzando i seguenti comandi:

    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. Modifica il file setup.env generato sostituendo tutti i valori parametro evidenziati con i valori parametro più adatti alla configurazione del tuo ambiente.

  6. (Facoltativo) Testa la modalità parzialmente memorizzata nella cache (~30%) modificando NUM_WAREHOUSE in 3200 nel file setup.env. Per saperne di più, consulta Scenari di valutazione delle prestazioni.

  7. (Facoltativo) Testa la modalità di memorizzazione nella cache completa (100%) modificando NUM_WAREHOUSE in 576 in setup.env file. Per saperne di più, consulta Scenari di valutazione delle prestazioni.

Carica i dati TPC-C nel database

Un passaggio di caricamento si riferisce al processo di compilazione del database di benchmark con i dati iniziali prima di eseguire il test delle prestazioni.

Durante la fase di caricamento, il database viene compilato con un numero specificato di magazzini, clienti e altre entità in base alle specifiche TPC-C. Lo scopo della fase di caricamento è creare un workload realistico per il test delle prestazioni e garantire che i risultati del test siano confrontabili tra sistemi diversi.

Una volta completato il passaggio di caricamento, il database si trova in uno stato coerente con un insieme definito di dati iniziali, pronto per essere utilizzato per il test di benchmark TPC-C.

Per caricare il database TPC-C, segui questi passaggi:

  1. Passa alla home directory del benchmark utilizzando il seguente comando:

    cd hammerdb/HammerDB-4.6

  2. Copia i seguenti contenuti e incollali in 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. Esegui il seguente comando di caricamento e attendi che venga completato.

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

  4. Convalida il carico. Al termine dello script precedente, ti consigliamo di verificare che il caricamento del database sia andato a buon fine. Per verificare le dimensioni del database, esegui questo comando:

    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)

In una configurazione TPC-C memorizzata nella cache al 30% (con 3200 magazzini), le dimensioni del database tpcc dovrebbero essere di circa 300 GB.

Nella configurazione TPC-C memorizzata nella cache al 100% (con 576 magazzini), le dimensioni del database tpcc dovrebbero essere di circa 55 GB.

Esegui il benchmark TPC-C

Ora puoi eseguire il test delle prestazioni TPC-C. Il benchmark TPC-C viene eseguito utilizzando il database compilato dal passaggio di caricamento. Il benchmark genera una serie di transazioni che simulano un tipico ambiente aziendale, tra cui l'inserimento degli ordini, l'elaborazione dei pagamenti e la gestione dell'inventario. Il workload viene misurato in transazioni al minuto (TPM), che rappresenta il numero di transazioni aziendali complete che il sistema può gestire in un minuto.

La fase di esecuzione è progettata per sottoporre a stress il sistema di database in condizioni realistiche e per fornire un modo standard di misurare le prestazioni che puoi confrontare tra diversi sistemi di database. I fornitori e gli utenti utilizzano spesso i risultati del benchmark TPC-C per valutare le prestazioni di diversi sistemi di database e configurazioni hardware.

Per eseguire il benchmark TPC-C, segui questi passaggi:

  1. Passa alla home directory del benchmark:

    cd hammerdb/HammerDB-4.6

  2. Copia i seguenti contenuti e incollali in 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. Esegui lo script utilizzando i seguenti comandi:

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

  4. Attendi il completamento dello script run-tpcc.sh. Il completamento dello script richiede circa 1 ora e 10 minuti. Al termine dello script, puoi analizzare i risultati.

Analizza i risultati del benchmark

Nel benchmarking TPC-C, i nuovi ordini al minuto (NOPM) e le transazioni al minuto (TPM) sono metriche sul rendimento utilizzate per misurare le prestazioni di un sistema di database.

  • NOPM: misura il numero di transazioni di nuovi ordini che il sistema può gestire in un minuto. La transazione di un nuovo ordine è una delle transazioni più importanti nel benchmark TPC-C e prevede la creazione di un nuovo ordine per un cliente.

  • TPM: misura il numero totale di transazioni aziendali completate che il sistema può gestire in un minuto. Le transazioni includono le transazioni di nuovi ordini e altri tipi di transazioni definite nel benchmark TPC-C, come pagamento, consegna e stato dell'ordine.

    Il TPM è la metrica sul rendimento principale per il benchmark TPC-C perché fornisce una misura complessiva della capacità del sistema di gestire un workload realistico. Il NOPM può essere una metrica utile per i sistemi incentrati sull'elaborazione di nuovi ordini, come i sistemi di e-commerce o di vendita al dettaglio.

Visualizza i risultati con un database TPC-C memorizzato nella cache al 30% su una macchina con 16 vCPU

Per estrarre i dati sulle prestazioni per questo scenario, utilizza il seguente comando:

grep NOPM results/run-tpcc.out

Di seguito è riportato l'output previsto:

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

Con un database TPC-C memorizzato nella cache al 30% su una macchina con 16 vCPU (con NUM_WAREHOUSE=3200 e NUM_USERS=256), osservi 252.970 tpm-C (New Order Per Minute) da un totale cumulativo di 582.385 TPM AlloyDB.

Visualizza i risultati con il database TPC-C memorizzato nella cache al 100% su una macchina con 16 vCPU

In un database TPC-C memorizzato nella cache al 100% su una macchina con 16 vCPU (con NUM_WAREHOUSE=576 e NUM_USERS=256), osservi 428.316 tpm-C (New Order Per Minute) da un TPM AlloyDB cumulativo di 974.264.

Per estrarre i dati sulle prestazioni per questo scenario, utilizza il seguente comando:

grep NOPM results/tpcc-run.out

Di seguito è riportato l'output previsto:

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

Riepilogo dei risultati delle prestazioni su una macchina con 16 vCPU

La tabella seguente riassume i risultati delle prestazioni del benchmark per una macchina con 16 vCPU:

Scenario TPC-C NUM_WAREHOUSE NUM_USERS NOPM TPM cumulativo
30% memorizzato nella cache 3200 256 252.970 582.385
100% memorizzato nella cache 576 256 428.316 974.264

Osserva le metriche sul rendimento del database

Per comprendere meglio il comportamento del tuo sistema di database, utilizza gli strumenti di monitoraggio di AlloyDB per osservare metriche di sistema importanti come l'utilizzo della CPU, la memoria utilizzata e le transazioni al secondo. Per saperne di più, consulta Monitora le prestazioni delle istanze.

Ad esempio, dopo aver eseguito questo benchmark, puoi osservare nella pagina Panoramica di AlloyDB nella console Google Cloud che l'utilizzo medio della CPU per l'esecuzione TPC-C memorizzata nella cache al 100% è quasi del 90%.

Esegui un benchmark TPC-C su un'istanza AlloyDB con 64 vCPU

Per eseguire un benchmark TPC-C su un'istanza AlloyDB con 64 vCPU, segui gli stessi passaggi di configurazione descritti in Esegui un benchmark TPC-C, ma utilizzi tipi di macchine diversi.

Configura AlloyDB e la macchina client

  1. Crea un cluster e un'istanza AlloyDB, sostituendo 64 vCPU, 512GB come tipo di macchina.

  2. Esegui il provisioning della macchina client, sostituendo n2-standard-64 come tipo di macchina.

  3. Configura la macchina driver del benchmark.

Esegui il benchmark

  1. Se esegui più benchmark in successione, esegui una pulizia del benchmark.

  2. Configura la macchina client, sostituendo i seguenti valori:

    • Imposta PGHOST sull'IP privato della nuova istanza AlloyDB con 64 vCPU.
    • Per lo scenario TPC-C memorizzato nella cache al 30%, imposta NUM_WAREHOUSE=12800 e NUM_USERS=1024.
    • Per lo scenario TPC-C memorizzato nella cache al 100%, imposta NUM_WAREHOUSE=2304 e NUM_USERS=1024.

  3. Configura e carica un database TPC-C. Per velocizzare il caricamento, modifica il valore di pg_num_vu in 64 in build-tpcc.sh come diset tpcc pg_num_vu 64.

  4. Esegui il benchmark TPC-C.

Analizza i risultati del benchmark

La tabella seguente riassume i risultati delle prestazioni di benchmark su una macchina con 64 vCPU:

Modalità benchmark NUM_WAREHOUSE NUM_USERS NOPM TPM cumulativo
30% memorizzato nella cache 12800 1024 589.598 1.371.160
100% memorizzato nella cache 2304 1024 716.138 1.665.438

Esegui un benchmark TPC-B pgbench

TPC-B (Transaction Processing Performance Council Benchmark B) è una delle modalità di benchmark disponibili in pgbench, uno strumento di benchmarking per PostgreSQL. TPC-B simula uno scenario bancario in cui più cassieri eseguono transazioni sugli account dei clienti. Il workload è costituito dai seguenti tipi di transazioni:

  • Depositi
  • Prelievi
  • Richieste di saldo

Il benchmark misura le prestazioni del sistema di database simulando una combinazione di queste transazioni e misurando il numero di transazioni al secondo che il sistema può gestire.

La modalità TPC-B in pgbench genera un database sintetico e simula un mix di transazioni simile al workload TPC-B, ma non è certificata ufficialmente dall'organizzazione TPC. Pertanto, sebbene la modalità TPC-B in pgbench fornisca un'approssimazione utile delle prestazioni TPC-B, non utilizzarla per rivendicare la conformità agli standard TPC-B.

Scenari per misurare le prestazioni

Questa sezione descrive come misurare le prestazioni TPC-B nelle seguenti modalità critiche. L'unico parametro che è diverso in queste modalità è il valore del parametro SCALE_FACTOR.

Scenario di database parzialmente memorizzato nella cache

In questo scenario, configuri e inizializzi un database di grandi dimensioni (circa 650 GB) utilizzando --scale= 50000. Un database di grandi dimensioni che non entra in memoria e causa un I/O del disco significativo fornisce una rappresentazione realistica di molti workload di produzione.

Un database di grandi dimensioni che causa un I/O su disco significativo può sottolineare l'importanza della progettazione del database e dell'ottimizzazione delle query. Un database di grandi dimensioni può anche esporre problemi di prestazioni relativi all'I/O del disco, come un accesso lento al disco o query inefficienti, che potrebbero non essere evidenti in un database di piccole dimensioni o interamente residente in memoria.

Scenario di database completamente memorizzato nella cache

In questo scenario, configuri e inizializzi un database di circa 60 GB utilizzando --scale=4000 in modo che risieda nel pool di buffer. Il benchmarking di un database residente in memoria è importante perché consente di valutare le prestazioni massime del sistema di database in un ambiente controllato.

Un database residente in memoria archivia tutti i dati nel pool di buffer PostgreSQL, eliminando il collo di bottiglia di I/O che può verificarsi quando si accede ai dati dal disco. Questa modalità può aiutare a identificare i colli di bottiglia delle prestazioni non correlati all'I/O, come l'utilizzo della CPU o i problemi di blocco, che potrebbero non essere evidenti quando esegui il benchmark di un database che si basa sull'I/O del disco.

Configura il server di database e la macchina client

Per configurare l'infrastruttura per eseguire un benchmark pgbench TPC-B, segui questi passaggi:

  1. Crea un cluster e un'istanza AlloyDB, sostituendo 16 vCPU, 128GB come tipo di macchina.

  2. Esegui il provisioning della macchina client, sostituendo E2-standard-16 (minimum) come tipo di macchina.

  3. Configura la macchina driver del benchmark.

  4. Esegui una pulizia del benchmark.

Esegui il benchmark TPC-B di pgbench

  1. Connettiti alla macchina client utilizzando il seguente comando Google Cloud CLI:

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

  2. Crea il file 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. Modifica il file setup.env generato e sostituisci il seguente valore parametro con valori adatti alla configurazione del tuo ambiente.

    • PRIVATE_IP: l'IP privato della tua istanza AlloyDB.

    Utilizza la tabella seguente per scegliere i valori <scale_factor> e <num_clients>. Questi valori devono essere scalati in base al tipo di macchina e alle dimensioni del database (completamente o parzialmente memorizzato nella cache). Gli esempi in questa guida utilizzano i valori SCALE_FACTOR e NUM_CLIENT corrispondenti al tipo di macchina n2-highmem-16.

    Completamente memorizzato nella cache Memorizzato parzialmente nella cache
    Tipo di macchina 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 25000 128
    n2-highmem-16 4000 384 50000 256
    n2-highmem-32 8000 768 100000 512
    n2-highmem-64 16.000 1536 200000 1024

  4. Crea un database pgbench.

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

  5. Inizializza e carica il database pgbench eseguendo i seguenti comandi. Questo passaggio garantisce che il set di dati di benchmarking venga creato e compilato con dati realistici, il che ti consente di simulare con precisione un workload TPC-B sul database 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

    Tempi di caricamento previsti:

    • Il caricamento del database parzialmente memorizzato nella cache richiede circa 6 ore.
    • Il caricamento del database completamente memorizzato nella cache richiede circa 45 minuti.

  6. (Facoltativo) Esegui un controllo dell'accuratezza del caricamento assicurandoti che i contenuti del file /tmp/pgbench-tpcb-partially-cached-db-init.out siano simili ai seguenti:

    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. (Facoltativo) Per convalidare ulteriormente l'accuratezza del carico, esegui il seguente comando PostgreSQL che misura le dimensioni di tutte le tabelle pgbench:

    1. Connettiti al database pgbench:

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

    2. Esegui questo comando SQL:

      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. Confronta l'output del comando precedente con l'output ottenuto per l'esecuzione del database parzialmente memorizzato nella 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. Esegui i seguenti comandi per simulare il workload di un sistema di contabilità finanziaria eseguendo una serie di transazioni che coinvolgono depositi, trasferimenti e pagamenti, in modo da misurare le prestazioni del database in condizioni di workload elevato.

    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

Analizza i risultati del benchmark

Controlla l'output del comando precedente nel file ~/results/alloydb/pgbench/pgbench.run.out. Il numero di TPS dovrebbe essere vicino ai numeri mostrati negli scenari di database completamente memorizzato nella cache e di database parzialmente memorizzato nella cache.

Risultati con un database completamente memorizzato nella cache

L'output dell'ultimo comando in Esegui il benchmark TPC-B di pgbench dovrebbe essere simile al seguente, dove --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)

Per comprendere meglio il comportamento del sistema di database, puoi monitorare metriche di sistema come l'utilizzo della CPU, la memoria utilizzata e le transazioni al secondo utilizzando la console Google Cloud . Per saperne di più, consulta Monitora le istanze.

Risultati con un database parzialmente memorizzato nella cache

L'output dell'ultimo comando in Esegui il benchmark TPC-B di pgbench dovrebbe essere simile al seguente, dove --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)

Riepilogo dei risultati delle prestazioni per un benchmark TPC-B pgbench

La tabella seguente riassume i risultati delle prestazioni per un benchmark TPC-B pgbench:

Scenario TPC-B SCALE_FACTOR TPS Utilizzo CPU (%)
Memorizzato parzialmente nella cache 50000 17.460 96%
Completamente memorizzato nella cache 4000 21.750 94%

Esegui un benchmark di inserimento solo indice

Il benchmark Index Insert Only è uno scenario ad alta contemporaneità e ad alta intensità di scrittura, personalizzato in questa sezione per mostrare i vantaggi in termini di prestazioni di AlloyDB per la maggior parte delle applicazioni OLTP. Per eseguire questo benchmark, crei più indici nella tabella pgbench_history, quindi esegui ripetutamente operazioni INSERT nella tabella pgbench_history da più connessioni client.

I benchmark Index Only Insert misurano le prestazioni dell'inserimento di dati in una tabella di database, concentrandosi in particolare sull'impatto degli indici sull'operazione di scrittura. Questo benchmark ti consente di capire quanto velocemente è possibile aggiungere nuove righe a una tabella con e senza indici, evidenziando il potenziale rallentamento causato dalla manutenzione degli indici durante gli inserimenti.

AlloyDB migliora le prestazioni di scrittura di PostgreSQL, il che migliora anche i workload OLTP. Per migliorare le prestazioni degli scenari OLTP ad alta intensità di scrittura, AlloyDB offre innovazioni architettoniche, tra cui un livello di cache a più livelli per facilitare le letture e una tecnologia di motore di archiviazione distribuita e altamente scalabile per le scritture.

Configura AlloyDB e la macchina client

Per configurare l'infrastruttura per eseguire un benchmark di inserimento solo indice, segui questi passaggi:

  1. Crea un cluster e un'istanza AlloyDB, sostituendo 16 vCPU and 128 GB RAM come tipo di macchina.

  2. Esegui il provisioning della macchina client, sostituendo E2-standard-16 (minimum) come tipo di macchina.

  3. Configura la macchina driver di benchmark.

  4. Esegui una pulizia del benchmark.

Esegui il benchmark Index Insert Only

  1. Connettiti alla macchina client utilizzando il seguente comando di esempio:

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

  2. Configura l'ambiente eseguendo questo comando:

    export PGHOST=<private_ip>

  3. Crea un database pgbench utilizzando l'esempio seguente. Se il database esiste già, eliminalo e ricrealo.

    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. Inizializza e carica il database pgbench per assicurarti che il set di dati di benchmarking venga creato e compilato con dati realistici. Modifica i parametri evidenziati, quindi esegui questo comando:

    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. Verifica che l'output del comando precedente sia simile al seguente:

    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. Crea lo script index-init.sql utilizzando i seguenti comandi:

    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. Esegui lo script index-init.sql:

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

  8. (Facoltativo) Convalida lo schema del database e il caricamento iniziale:

    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)

    Dopo il caricamento, le dimensioni del database dovrebbero essere di circa 365 GB:

    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. Crea lo script index-inserts-only.sql utilizzando i seguenti comandi:

    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. Esegui il benchmark pgbench utilizzando il seguente comando:

    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

Analizza i risultati del benchmark

Verifica l'output del comando precedente nel file /tmp/pgbench-index-insert-only-run.out. Durante questo test di benchmark, dovresti vedere circa 52.000 transazioni al secondo e un tasso di utilizzo della CPU di circa l'88%, come mostrato nell'output di esempio seguente.

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)

Esegui un benchmark di sola selezione su un'istanza con 64 vCPU

pgbench supporta uno scenario integrato di sola selezione che esegue ripetutamente query SELECT da più connessioni client su un database specificato. Questo benchmark viene utilizzato per misurare le prestazioni di lettura del database, senza introdurre l'overhead delle operazioni di modifica dei dati come INSERT, UPDATE o DELETE. Queste query SELECT sono query di ricerca puntuale, il tipo di query di selezione più rapido ed efficiente perché comportano l'accesso a una singola riga di dati direttamente dalle strutture dell'indice.

L'esecuzione di un benchmark Solo selezione ti aiuta a raggiungere i seguenti obiettivi:

  • Raggiungimento della velocità effettiva massima: poiché le ricerche di punti su un indice sono la forma più efficiente di query in un sistema di database, puoi misurare la velocità effettiva massima possibile che AlloyDB può raggiungere.

  • Scalabilità: seleziona solo i benchmark che ti aiutano a testare la scalabilità di AlloyDB da 2 vCPU alla configurazione vCPU massima offerta da AlloyDB.

Configura AlloyDB e la macchina client

Configura AlloyDB e la macchina client su un tipo di macchina con 64 vCPU.

Esegui il benchmark Select Only

  1. Connettiti alla macchina client utilizzando il seguente comando di esempio:

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

  2. Configura l'ambiente utilizzando il seguente comando:

    export PGHOST=<private_ip>

  3. Crea il database pgbench utilizzando il seguente esempio:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Inizializza il database pgbench. Il comando seguente inizializza il database pgbench con circa 220 GB di dati realistici. Utilizza --scale=15000 per il benchmark Select Only completamente memorizzato nella cache.

    Esegui questo comando:

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

  5. Verifica che l'output del comando precedente sia simile al seguente:

    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. Esegui pgbench. Il completamento di questo passaggio finale di benchmarking richiede più di un'ora.

    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. Al termine del benchmark, controlla il file /tmp/pgbench-select-only-run.out per i risultati finali.

Analizza i risultati del benchmark

Durante questo test di benchmark, dovresti osservare circa 467.000 transazioni al secondo e un tasso di utilizzo della CPU di circa il 95%, come mostrato nell'output di esempio seguente.

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)

Riepilogo dei risultati del benchmark di AlloyDB

Le tabelle seguenti riassumono i risultati del benchmark di AlloyDB in base ai test eseguiti in questo documento.

Riepilogo delle prestazioni di HammerDB TPC-C

Tipo di macchina AlloyDB Scenario di workload TPC-C NUM_WAREHOUSE NUM_USERS New Orders Per Minute (NOPM) TPM cumulativo Conversione in TPS
16vCPU 30% memorizzato nella cache 3200 256 252.970 582.385 9706
16vCPU 100% memorizzato nella cache 576 256 428.316 974.264 16.238
64vCPU 30% memorizzato nella cache 12800 1024 589.598 1.371.160 22.853
64vCPU 100% memorizzato nella cache 2304 1024 716.138 1.665.438 27.757

Riepilogo delle prestazioni di pgbench

Tipo di macchina AlloyDB Scenario di workload pgbench Fattore di scalabilità TPS %CPU
16vCPU TPC-B Like, Fully Cached 4000 20.359 96%
16vCPU TPC-B Like, Partially Cached 50000 14.060 94%
16vCPU Solo inserimenti di indici 25000 51.742 88%
64vCPU Throughput massimo (solo selezione) 15000 467.583 95%

Esegui il benchmarking OLTP su Cloud SQL per PostgreSQL

Puoi testare le prestazioni OLTP equivalenti su PostgreSQL in Cloud SQL per PostgreSQL su un tipo di macchina con 16 vCPU per un'analisi comparativa. Questa sezione descrive come configurare un Cloud SQL per PostgreSQL (o qualsiasi server PostgreSQL di cui è stato eseguito il deployment nell'infrastruttura che preferisci) paragonabile alla configurazione di AlloyDB utilizzata in questa guida per eseguire il benchmark delle prestazioni OLTP. In questo scenario, è inclusa la scelta dello SKU con 16 vCPU, l'attivazione dell'alta affidabilità (HA) e la preconfigurazione con lo spazio di archiviazione.

Prima di iniziare

  1. 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 role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  3. Enable the AlloyDB, Compute Engine, and Resource Manager APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  4. Install the Google Cloud CLI.

  5. Configure the gcloud CLI to use your federated identity.

    For more information, see Sign in to the gcloud CLI with your federated identity.

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

    gcloud init
  7. Assicurati di disporre dei ruoli Amministratore Cloud SQL e Visualizzatore Compute nel tuo account utente.

    Vai alla pagina IAM

    Scopri di più su ruoli e autorizzazioni.

Esegui il provisioning di un'istanza Cloud SQL per PostgreSQL

  1. Crea un'istanza PostgreSQL, sostituendo i seguenti valori:

    • Versione del database: PostgreSQL 14
    • Scegli una configurazione con cui iniziare: Produzione
    • Scegli la disponibilità per regione e zona: seleziona us-central1 come regione.
    • Disponibilità a livello di zona: Più zone (alta affidabilità)
      • Zona principale: us-central1-c
      • Zona secondaria: us-central-1-f
    • Tipo di macchina: macchina con memoria elevata, 16 vCPU, 104 GB. Questa è la macchina più vicina che Cloud SQL per PostgreSQL offre all'istanza AlloyDB corrispondente che hai creato nella sezione di benchmarking di AlloyDB di questo documento.
    • Capacità di archiviazione: Personalizzata, 1500 GB
      • Abilita aumenti automatici dello spazio di archiviazione
    • Crittografia: Google-owned and Google-managed encryption key
    • Connessioni: IP privato
      • Rete: default
      • IP pubblico: abilitato

  2. Fai clic su Crea istanza.

  3. Dopo aver creato l'istanza PostgreSQL, prendi nota dell'indirizzo IP privato. Utilizza l'IP come PGHOST per stabilire connessioni con il benchmark.

Esegui il provisioning della macchina client

  1. Esegui il provisioning di un'istanza Cloud SQL per PostgreSQL. Per eseguire il benchmark OLTP che preferisci, devi disporre di una macchina client con una potenza della CPU significativa nella stessa zona dell'istanza Cloud SQL per PostgreSQL principale in Cloud SQL.

  2. (Facoltativo) In alternativa al passaggio precedente, puoi utilizzare la stessa macchina client configurata per il benchmarking di AlloyDB, a condizione che:

    • La macchina client si trova nella stessa zona della nuova istanza principale PostgreSQL (Cloud SQL per PostgreSQL).
    • La macchina client soddisfa i requisiti minimi di CPU, RAM e dimensioni del disco.

    In questa guida al benchmarking, hai riutilizzato le macchine client quando erano collocate nella stessa zona dell'istanza principale e quando erano abbastanza grandi da portare il server alla sua piena capacità.

  3. Se hai creato una nuova macchina client, configura la macchina driver di benchmark. In caso contrario, segui le istruzioni riportate in questa guida per il benchmark che ti interessa eseguire.

Passaggi successivi