Eseguire il benchmarking delle prestazioni OLTP su AlloyDB per PostgreSQL

Questo documento descrive come configurare AlloyDB per PostgreSQL e una macchina client per valutare le prestazioni di AlloyDB utilizzando TPC-C, una specifica di benchmark OLTP. Questo documento descrive anche come eseguire scenari OLTP personalizzati con un utilizzo intensivo 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 per il benchmarking.

Funzionalità dei carichi di lavoro di AlloyDB

AlloyDB offre affidabilità, scalabilità e prestazioni di livello aziendale 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
  • Spazio di archiviazione distribuito 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 buffer pool e la modifica di altri parametri, flag e caratteristiche del database. Queste impostazioni variano a seconda delle dimensioni e del 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; al contrario, AlloyDB ha prestazioni OLTP elevate 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 dettagliate e metriche delle prestazioni.

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 diversi scenari.

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 carico di lavoro simile al benchmark TPC-C, inclusa una combinazione di transazioni che imitano il comportamento di un ambiente di fornitore all'ingrosso.
pgbench pgbench è uno strumento di benchmarking fornito in bundle con PostgreSQL. pgbench consente di simulare carichi di lavoro transazionali 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 il mix di transazioni per emulare il carico di lavoro di produzione e ottenere informazioni sul comportamento del sistema in diversi scenari.
pgbench include un'implementazione TPC-B. L'implementazione TPC-B di pgbench è simile a un benchmark TPC-B.

Prima di iniziare

  1. Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei workload.

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

    Roles required to select or create a project

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

    Go to project selector

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

  4. Enable the AlloyDB, Compute Engine, and Resource Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. 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

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

  7. Enable the AlloyDB, Compute Engine, and Resource Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

    8.

  8. 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 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 è 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 progetto Google Cloud diverso.

Configura e esegui il provisioning del database e della macchina client

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

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à per zona, seleziona Più zone (disponibilità elevata) per il tipo di cluster.

  5. Seleziona la rete predefinita.

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

    • PostgreSQL 17

    • PostgreSQL 18

  7. Prendi nota della posizione della zona primaria 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. Gli strumenti di benchmarking 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.

Se non diversamente specificato, le istruzioni riportate in questo documento utilizzano una macchina E2-standard-32 con un 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 primaria AlloyDB.

Per eseguire il benchmark TPC-C su un'istanza primaria 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 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 primaria 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, 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 Compute Engine che hai creato utilizzando SSH.

Configura la macchina del driver di benchmark

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

Per configurare la macchina del driver di riferimento:

  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 includa un'applicazione psql e poi 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 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 OLTP vario 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 una pulizia del benchmark

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

Una pulizia del benchmark garantisce che gli effetti residui dei benchmark precedenti non influiscano sulle misurazioni del rendimento 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 per identificare le aree di ottimizzazione di hardware, software o configurazione.

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

  1. Elimina i dati di benchmark precedenti o il database di benchmark. 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 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 ti consente di simulare un carico di lavoro simile al benchmark TPC-C, inclusa una combinazione di transazioni che imitano il comportamento di un ambiente di 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 delle prestazioni. 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

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

  • Modalità con memorizzazione parziale 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 sui 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 I/O minimi, perché le letture vengono servite 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.

Configurare il computer client

  1. Configura la macchina 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 create 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 (~30%) memorizzata nella cache modificando NUM_WAREHOUSE in 3200 nel file setup.env. Per saperne di più, consulta Scenari di valutazione del rendimento.

  7. (Facoltativo) Prova la modalità completamente (100%) memorizzata nella cache modificando NUM_WAREHOUSE in 576 in setup.env file. Per saperne di più, consulta Scenari di valutazione del rendimento.

Caricare i dati TPC-C nel database

Un passaggio di caricamento si riferisce al processo di popolamento del database di benchmark con i dati iniziali prima di eseguire il test delle 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 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:

  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.

    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 riuscito. 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 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 mettere sotto 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. Fornitori e utenti spesso utilizzano i risultati del benchmark TPC-C per valutare le prestazioni 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.

Analizzare i risultati del benchmark

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

  • NOPM: misura il numero di nuove transazioni di ordini che il sistema può gestire in un minuto. La nuova transazione di ordine è una delle 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 definiti nel benchmark TPC-C, ad esempio pagamento, consegna e stato dell'ordine.

    TPM è la metrica di rendimento principale per il benchmark TPC-C perché fornisce una misura complessiva della capacità del sistema di gestire un carico di lavoro realistico. 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 il 30% del database TPC-C memorizzato nella cache su una macchina con 16 vCPU

Per estrarre i numeri di 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), si osservano 252.970 tpm-C (New Order Per Minute) da un TPM AlloyDB cumulativo di 582.385.

Visualizza i risultati con un 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 numeri di 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 del rendimento sulla 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 sulle prestazioni del database

Per comprendere meglio 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 saperne di più, consulta Monitorare 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 di TPC-C memorizzato 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 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 la macchina 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 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 impostandolo su 64 in build-tpcc.sh come diset tpcc pg_num_vu 64.

  4. Esegui il benchmark TPC-C.

Analizzare i risultati del benchmark

La tabella seguente riassume i risultati del benchmark delle prestazioni 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 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 dei clienti. Il workload è costituito dai seguenti tipi di transazioni:

  • Depositi
  • Prelievi
  • Richieste di saldo

Il benchmark misura il rendimento 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 mix di transazioni simile al carico di lavoro TPC-B, ma non è certificata ufficialmente 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 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 rientra nella memoria e causa un I/O del disco significativo fornisce una rappresentazione realistica di molti carichi di lavoro 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 rivelare problemi di prestazioni correlati all'I/O del disco, come accesso lento al disco o query inefficienti, che potrebbero non essere evidenti in un database piccolo 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 buffer pool. 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 buffer pool 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 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 di benchmark.

  4. Esegui una pulizia dei 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 dell'istanza AlloyDB.

    Utilizza la tabella seguente per scegliere i valori di <scale_factor> e <num_clients>. Questi valori devono essere scalati in base al tipo di macchina e alle dimensioni del database (completamente memorizzato nella cache 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 Parzialmente memorizzato 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 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 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 caricamento, esegui questo 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 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 questi comandi per simulare un carico di lavoro del sistema di contabilità finanziaria eseguendo una serie di transazioni che coinvolgono depositi, trasferimenti e pagamenti, il che ti consente di misurare le prestazioni del database in condizioni di carico di lavoro 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

Analizzare i risultati del benchmark

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

Risultati con un database completamente memorizzato nella cache

L'output dell'ultimo comando in Esegui il benchmark pgbench TPC-B 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, l'utilizzo della memoria e le transazioni al secondo utilizzando la console Google Cloud . Per saperne di più, consulta Monitorare le istanze.

Risultati con un database memorizzato parzialmente nella cache

L'output dell'ultimo comando in Esegui il benchmark pgbench TPC-B 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 del rendimento per un benchmark pgbench TPC-B

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

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

Esegui un benchmark di inserimento solo indice

Il benchmark Index Insert Only è uno scenario a concorrenza elevata e con molte scritture 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 ed esegui ripetutamente operazioni INSERT nella tabella pgbench_history da più connessioni client.

I benchmark di inserimento solo indice 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 con quale rapidità è 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 architetturali, 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 Inserimento solo 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 la macchina driver di benchmark.

  4. Esegui una pulizia dei benchmark.

Esegui il benchmark Inserimento solo 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 il seguente esempio. 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 ed 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

Analizzare 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 Select Only 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 che sono il tipo di query SELECT più veloce ed efficiente perché comportano l'accesso a una sola riga di dati direttamente dalle strutture di indice.

L'esecuzione di un benchmark Seleziona solo ti aiuta a ottenere quanto segue:

  • Raggiungere la velocità effettiva massima: poiché le ricerche puntuali 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 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 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. Utilizzi --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.

Analizzare i risultati del benchmark

Dovresti osservare circa 467.000 transazioni al secondo e un tasso di utilizzo della CPU di circa il 95% durante questo test di benchmark, 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 riepilogano i risultati del benchmark AlloyDB in base ai test eseguiti in questo documento.

Riepilogo del rendimento di HammerDB TPC-C

Tipo di macchina AlloyDB Scenario di workload TPC-C NUM_WAREHOUSE NUM_USERS Nuovi ordini al minuto (NOPM) TPM cumulativo Convertito 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 del rendimento di pgbench

Tipo di macchina AlloyDB Scenario del carico di lavoro pgbench Fattore di scala TPS %CPU
16vCPU TPC-B Like, Fully Cached 4000 20.359 96%
16vCPU TPC-B Like, Partially Cached 50000 14.060 94%
16vCPU Solo inserti dell'indice 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 l'analisi comparativa. Questa sezione descrive come configurare un'istanza Cloud SQL per PostgreSQL (o qualsiasi server PostgreSQL di cui è stato eseguito il deployment sull'infrastruttura di tua scelta) paragonabile alla configurazione di AlloyDB utilizzata in questa guida per valutare le prestazioni OLTP. Questo scenario include la scelta dello SKU 16 vCPU, l'attivazione dell'alta disponibilità (HA) e la preconfigurazione con lo spazio di archiviazione.

Prima di iniziare

  1. Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei workload.

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

    Roles required to select or create a project

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

    Go to project selector

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

  4. Enable the AlloyDB, Compute Engine, and Resource Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  5. Installa Google Cloud CLI.

  6. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  7. Per inizializzare gcloud CLI, esegui questo comando: 

    gcloud init

  8. 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

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

  10. Enable the AlloyDB, Compute Engine, and Resource Manager APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  11. Installa Google Cloud CLI.

  12. Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.

  13. Per inizializzare gcloud CLI, esegui questo comando: 

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

    Vai alla pagina IAM

    Scopri di più su ruoli e autorizzazioni.

Provisiona 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: High Memory 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. Utilizzi 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'istanzaCloud SQL per PostgreSQLQL 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 si verifichi quanto segue:

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

    In questa guida al benchmarking, hai riutilizzato le macchine client quando si trovavano 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