Eseguire il benchmarking delle prestazioni OLTP su AlloyDB per PostgreSQL

Questo documento descrive come configurare AlloyDB per PostgreSQL e una macchina client per eseguire il benchmark delle prestazioni di AlloyDB utilizzando TPC-C, una specifica di benchmark OLTP. Questo documento descrive anche come eseguire scenari OLTP personalizzati con lettura e scrittura intensive, come Solo inserimento nell'indice e Solo selezione.

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

Funzionalità dei carichi di lavoro AlloyDB

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

  • Gestione di log e transazioni
  • Gestione dinamica della memoria
  • Integrazione di intelligenza artificiale e machine learning
  • Motore colonnare integrato
  • Una cache a più livelli
  • Archiviazione distribuita e scalabile

I sistemi di database relazionali in genere richiedono un amministratore del database per ottimizzare il database per il benchmarking, che include la configurazione delle impostazioni del log delle transazioni, l'impostazione 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, ma le ha già integrate.

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 e metriche sul rendimento dettagliate.

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

HammerDB include un'implementazione del benchmark TPC-C per valutare le prestazioni dei sistemi OLTP. L'implementazione di HammerDB TPC-C consente di simulare un carico di lavoro 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 fornito in bundle con PostgreSQL. pgbench consente di simulare carichi di lavoro delle transazioni come inserimento, aggiornamento, selezione dei dati e 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 carico di lavoro di produzione e ottenere approfondimenti sul comportamento del sistema in diversi scenari.
pgbench include un'implementazione di TPC-B. L'implementazione di pgbench TPC-B è simile a un benchmark TPC-B.

Prima di iniziare

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

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

    Go to project selector

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

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

    Go to project selector

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

  6. Abilita le API Cloud necessarie per creare e connetterti 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 modifiche.

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

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

      L'API Service Networking è necessaria 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 altro progetto Google Cloud.

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 riportate 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 (disponibilità elevata) per il tipo di cluster.

  5. Seleziona la rete predefinita.

  6. Nel campo Versione database, seleziona PostgreSQL 15.

  7. Prendi nota della posizione 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 benchmark OLTP, è necessaria una macchina client con potenza di elaborazione adeguata. Strumenti di benchmark come HammerDB e pgbench vengono eseguiti in modo molto parallelo e consumano molta CPU. Un computer client non deve costituire un collo di bottiglia quando esegui un benchmark OLTP.

Se non diversamente specificato, 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 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 e 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 collegarti.
  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 della zona dell'istanza principale AlloyDB.
  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 ad AlloyDB.
    Se Interfacce di rete non è impostato sulla rete VPC configurata per l'accesso privato ai servizi, espandi l'opzione 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 Compute Engine che hai creato tramite SSH.

Configura la macchina del driver del benchmark

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

Per configurare il computer del driver di benchmark:

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

    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 includa un'applicazione psql e assicurati di poterti connettere.

      sudo apt-get update
sudo apt install postgresql-client

    2. Utilizza il seguente comando per assicurarti che il client funzioni e che puoi connetterti ad AlloyDB. Utilizza l'indirizzo IP privato della tua 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 TPC-B e vari benchmark 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.

Eseguire la pulizia di un benchmark

Se prevedi di eseguire più benchmark in successione, devi eseguire la pulizia del benchmark tra ogni benchmark per garantire risultati accurati e affidabili.

La pulizia del benchmark garantisce che gli effetti residui dei benchmark precedenti non influiscano sulle misurazioni del rendimento del nuovo benchmark. La pulizia dei benchmark contribuisce inoltre a garantire la coerenza e la ripetibilità dei risultati dei benchmark, il che è essenziale per fare confronti significativi tra sistemi diversi o identificare aree di ottimizzazione in hardware, software o configurazione.

Per eseguire la pulizia di un benchmark prima di eseguirne un altro:

  1. Elimina i dati 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 ulteriori informazioni sull'utilizzo di psql, consulta Connettersi a un database.

  2. Riavvia l'istanza AlloyDB. Questo passaggio svuota le cache a livello di database e 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 consente di simulare un carico di lavoro simile al benchmark TPC-C, incluso un mix di transazioni che simulano il comportamento di un ambiente fornitore 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 regolare le dimensioni del database, il numero di magazzini e altre caratteristiche del carico di lavoro per simulare scenari diversi.

Scenari di valutazione del rendimento

Il rendimento del benchmarking TPC-C viene valutato utilizzando i seguenti metodi:

  • Modalità cache parziale (~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 eseguite dalla memoria e comportano I/O con i sottosistemi di archiviazione sottostanti. Questo scenario è applicabile alle esigenze OLTP di molti utenti.

  • Modalità completamente (100%) 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 I/O minime, in quanto le letture vengono principalmente eseguite dalla cache del buffer, in questa modalità si prevede un TPM più elevato rispetto alle esecuzioni con cache parziale. Questo scenario è applicabile alle esigenze OLTP degli utenti con esigenze I/O molto ridotte.

Configurare il computer client

  1. Configura il computer del driver di benchmark.

  2. Se esegui più benchmark in successione, esegui una pulizia dei 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 quelli più adatti alla configurazione del tuo ambiente.

  6. (Facoltativo) Prova la modalità in cache parziale (~30%) modificando NUM_WAREHOUSE in 3200 nel file setup.env. Per ulteriori informazioni, consulta Scenari di valutazione del rendimento.

  7. (Facoltativo) Testa la modalità completamente (100%) in cache cambiando NUM_WAREHOUSE in 576 in setup.env file. Per ulteriori informazioni, consulta Scenari di valutazione del rendimento.

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 di prestazioni.

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

Al termine del passaggio di caricamento, il database è 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:

  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 il completamento del comando.

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

  4. Convalida il caricamento. 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 quanto segue:

    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 con il 30% in cache (con 3200 magazzini), le dimensioni del database tpcc dovrebbero essere di circa 300 GB.

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

Esegui il benchmark TPC-C

Ora è tutto pronto per eseguire il test di 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 dell'attività, tra cui inserimento degli ordini, elaborazione dei pagamenti e gestione dell'inventario. Il carico di lavoro viene misurato in transazioni al minuto (TPM), che rappresenta il numero di transazioni aziendali complete che il sistema può gestire in un minuto.

Il passaggio di esecuzione è progettato per sottoporre a stress il sistema di database in condizioni realistiche e per fornire un modo standard per 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 il rendimento di diversi sistemi di database e configurazioni hardware.

Per eseguire il benchmark TPC-C:

  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 il rendimento 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 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 relative ai nuovi ordini nonché altri tipi di transazioni definiti nel benchmark TPC-C, come pagamento, consegna e stato dell'ordine.

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

Visualizza i risultati con il 30% del database TPC-C in cache su una macchina con 16 vCPU

Per estrarre i dati sul rendimento 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 il 30% del database TPC-C memorizzato nella cache su una macchina con 16 vCPU (con NUM_WAREHOUSE=3200 e NUM_USERS=256), vengono osservati 252.970 tpm-C (nuovi ordini al minuto) da un TPM AlloyDB cumulativo di 582.385.

Visualizza i risultati con il database TPC-C completamente in cache su una macchina con 16 vCPU

Su un database TPC-C completamente in cache su una macchina con 16 vCPU (con NUM_WAREHOUSE=576 e NUM_USERS=256), vengono osservati 428.316 tpm-C (nuovi ordini al minuto) da un valore cumulativo di 974.264 TPM AlloyDB.

Per estrarre i numeri sul rendimento 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 relativi alle prestazioni su una macchina con 16 vCPU

La seguente tabella riassume i risultati del benchmark sul rendimento per una macchina con 16 vCPU:

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

Osservare le metriche sul rendimento del database

Per comprendere ulteriormente il comportamento del sistema di database, utilizza gli strumenti di monitoraggio di AlloyDB per osservare metriche di sistema importanti come l'utilizzo della CPU, l'utilizzo della memoria e le transazioni al secondo. Per ulteriori informazioni, consulta Monitorare il rendimento 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 con il 100% in cache è quasi del 90%.

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

Per eseguire un benchmark TPC-C su un'istanza AlloyDB con 64 vCPU, segui gli stessi passaggi di configurazione descritti in Eseguire un benchmark TPC-C, ma utilizza 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 il computer del driver di benchmark.

Esegui il benchmark

  1. Se esegui più benchmark in successione, esegui una pulizia dei 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 con cache del 30%, imposta NUM_WAREHOUSE=12800 e NUM_USERS=1024.
    • Per lo scenario TPC-C con 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 dei benchmark sul rendimento su una macchina con 64 vCPU:

Modalità Benchmark NUM_WAREHOUSE NUM_USERS NOPM TPM cumulativo
30% nella cache 12800 1024 589.598 1.371.160
Nella cache al 100% 2304 1024 716.138 1.665.438

Esegui un benchmark pgbench TPC-B

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 del cliente. Il carico di lavoro è costituito dai seguenti tipi di transazioni:

  • Depositi
  • Prelievi
  • Richieste di informazioni sul saldo

Il benchmark misura le prestazioni del sistema di database simulando un mix 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 insieme di transazioni simile al carico di lavoro TPC-B, ma non è ufficialmente certificata dall'organizzazione TPC. Pertanto, anche se la modalità TPC-B in pgbench fornisce un'approssimazione utile delle prestazioni TPC-B, non utilizzarla per dichiarare la conformità agli standard TPC-B.

Scenari per misurare il rendimento

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

Scenario del database con cache parziale

In questo scenario, configuri e inizializzi un database di grandi dimensioni (circa 650 GB) utilizzando --scale= 50000. Avere un database di grandi dimensioni che non si adatta alla memoria e causa un'I/O disco significativa fornisce una rappresentazione realistica di molti carichi di lavoro di produzione.

Un database di grandi dimensioni che causa un'I/O del disco significativa 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 accesso al disco lento o query inefficienti, che potrebbero non essere evidenti in un database piccolo o sediato interamente 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 si trovi nel pool del buffer. Il benchmarking di un database 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 I/O che può verificarsi quando si accede ai dati dal disco. Questa modalità può aiutarti a identificare i colli di bottiglia delle prestazioni non correlati all'I/O, come problemi di utilizzo della CPU o 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 TPC-B di pgbench, 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 il computer del driver di benchmark.

  4. Esegui una pulizia del benchmark.

Esegui il benchmark pgbench TPC-B

  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 scalabili in base al tipo di macchina e alle dimensioni del database (cache completa o parziale). Gli esempi in questa guida utilizzano valori SCALE_FACTOR e NUM_CLIENT corrispondenti al tipo di macchina n2-highmem-16.

    Completamente nella cache Parzialmente memorizzata 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 16000 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 consente di simulare con precisione un carico di lavoro 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 a quanto segue:

    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 il seguente 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 quello ottenuto per l'esecuzione del database con cache parziale (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 carico di lavoro di un sistema di contabilità finanziaria eseguendo una serie di transazioni che coinvolgono depositi, trasferimenti e pagamenti, in modo da misurare il rendimento del database sotto un carico 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 ~/results/alloydb/pgbench/pgbench.run.out file. Il numero di TPS deve essere simile a quello visualizzato nel database completamente memorizzato nella cache e negli scenari del database parzialmente memorizzato nella cache.

Risultati con un database completamente memorizzato nella cache

L'output dell'ultimo comando in Eseguire 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 ulteriormente il comportamento del sistema di database, puoi monitorare le metriche di sistema come l'utilizzo della CPU, l'utilizzo della memoria e le transazioni al secondo utilizzando la console Google Cloud. Per ulteriori informazioni, consulta Monitorare le istanze.

Risultati con un database parzialmente memorizzato nella cache

L'output dell'ultimo comando in Eseguire 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 pgbench TPC-B

La seguente tabella riassume i risultati relativi al rendimento di un benchmark pgbench TPC-B:

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

Esegui un benchmark solo per l'inserimento di indici

Il benchmark Solo inserimenti di indici è uno scenario altamente concorrente con un'intensità di scrittura elevata 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, crea più indici nella tabella pgbench_history, quindi esegui ripetutamente operazioni INSERT nella tabella pgbench_history da più connessioni client.

I benchmark di inserimento solo dell'indice misurano le prestazioni dell'inserimento di dati in una tabella di database, concentrandosi in modo specifico 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 consente anche di migliorare i carichi di lavoro OLTP. Per migliorare le prestazioni degli scenari OLTP con un'intensità di scrittura elevata, AlloyDB offre innovazioni architettoniche, tra cui un livello della 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 inserimenti solo di indice:

  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 il computer del driver di benchmark.

  4. Esegui una pulizia del benchmark.

Esegui il benchmark Solo inserimento dell'indice

  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 il seguente comando:

    export PGHOST=<private_ip>

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

    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 sia creato e compilato con dati realistici. Modifica i parametri evidenziati ed esegui il seguente 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 riportato di seguito.

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 tipo Solo selezione su un'istanza con 64 vCPU

pgbench supporta uno scenario integrato solo per la selezione che esegue ripetutamente query SELECT da più connessioni client a un database specificato. Questo benchmark viene utilizzato per misurare le prestazioni di lettura del database, senza introdurre il sovraccarico delle operazioni di modifica dei dati come INSERT, UPDATE o DELETE. Queste query SELECT sono query di ricerca puntuale, ovvero il tipo di query SELECT più veloce ed efficiente perché richiedono di accedere solo a una singola riga di dati direttamente dalle strutture di indice.

L'esecuzione di un benchmark Solo selezione ti consente di:

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

  • Scalabilità: seleziona solo i benchmark per testare la scalabilità di AlloyDB da 2 vCPU alla configurazione massima di vCPU 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 Solo selezione

  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 l'esempio seguente:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Inizializza il database pgbench. Il seguente comando inizializza il database pgbench con circa 220 GB di dati realistici. Utilizza --scale=15000 per il benchmark Seleziona solo 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 ultimo passaggio 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 i risultati finali nel file /tmp/pgbench-select-only-run.out.

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'esempio di output 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 seguenti tabelle riepilogano i risultati del benchmark di AlloyDB basati sui test eseguiti in questo documento.

Riepilogo del rendimento di HammerDB TPC-C

Tipo di macchina AlloyDB Scenario di carico di lavoro TPC-C NUM_WAREHOUSE NUM_USERS Nuovi ordini al minuto (NOPM) TPM cumulativo Convertito in TPS
16vCPU 30% nella cache 3200 256 252.970 582.385 9.706
16vCPU Nella cache al 100% 576 256 428.316 974.264 16.238
64vCPU 30% nella cache 12800 1024 589.598 1.371.160 22.853
64vCPU Nella cache al 100% 2304 1024 716.138 1.665.438 27.757

Riepilogo del rendimento di pgbench

Tipo di macchina AlloyDB Scenario di carico di lavoro pgbench Fattore di scala TPS %CPU
16vCPU Come TPC-B, completamente memorizzato nella cache 4000 20.359 96%
16vCPU TPC-B Like, parzialmente memorizzato nella cache 50000 14.060 94%
16vCPU Solo inserimenti di indici 25000 51.742 88%
64vCPU Velocità effettiva massima (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 servizio 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 disponibilità (HA) e la preconfigurazione con lo spazio di archiviazione.

Prima di iniziare

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

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

    Go to project selector

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

  4. Install the Google Cloud CLI.

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

    gcloud init

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

    Go to project selector

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

  8. Install the Google Cloud CLI.

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

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

    Vai alla pagina IAM

    Scopri di più su ruoli e autorizzazioni.

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 disponibilità)
      • Zona principale: us-central1-c
      • Zona secondaria: us-central-1-f
    • Tipo di macchina: macchina con 16 vCPU e 104 GB di memoria elevata. Si tratta della macchina più simile offerta da Cloud SQL per PostgreSQL all'istanza AlloyDB corrispondente che hai creato nella sezione relativa al 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, hai bisogno di un computer 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 sia vero quanto segue:

    • La macchina client si trova nella stessa zona della nuova istanza principale PostgreSQL (Cloud SQL per PostgreSQL).
    • Il computer 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 del driver di benchmark. In caso contrario, segui le istruzioni riportate in questa guida per il benchmark che vuoi eseguire.

Passaggi successivi