OLTP-Leistung in AlloyDB for PostgreSQL benchmarken

Wenn Sie den Durchsatz und die Latenz Ihrer Transaktionsarbeitslasten in AlloyDB for PostgreSQL bewerten möchten, können Sie AlloyDB und einen Clientcomputer so konfigurieren, dass die Leistung der Online-Transaktionsverarbeitung (OLTP) mithilfe von TPC-C, einer branchenüblichen OLTP-Benchmark-Spezifikation, gemessen wird. Sie können auch benutzerdefinierte lese- und schreibintensive OLTP-Szenarien ausführen, z. B. Nur Index einfügen und Nur auswählen.

Die Anleitung in diesem Dokument basiert auf einer bestimmten Konfiguration von AlloyDB und dem Clientcomputer. Verwenden Sie die angegebenen Werte für jeden Schritt in der Benchmarking-Anleitung.

AlloyDB-Arbeitslastfunktionen

AlloyDB bietet Zuverlässigkeit, Skalierbarkeit und Leistung auf Unternehmensniveau, die für alle Unternehmen und kritischen Arbeitslasten geeignet sind. AlloyDB bietet die folgenden Komponenten und Funktionen, die eine hohe Leistung für Ihre transaktionalen (OLTP), analytischen (OLAP) und hybriden (HTAP) Arbeitslasten ermöglichen:

  • Log- und Transaktionsverwaltung
  • Dynamische Speicherverwaltung
  • Integration von künstlicher Intelligenz und maschinellem Lernen
  • Integrierte spaltenbasierte Engine
  • Ein mehrstufiger Cache
  • Verteilter und skalierbarer Speicher

Bei relationalen Datenbanksystemen muss ein Datenbankadministrator die Datenbank für das Benchmarking optimieren. Dazu gehört das Konfigurieren der Einstellungen für das Transaktionslog, das Festlegen der richtigen Pufferpoolgrößen und das Ändern anderer Datenbankparameter oder -flags und -merkmale. Diese Einstellungen variieren je nach Größe und Typ der Instanz.

AlloyDB ist für jeden Maschinentyp mit optimierten Einstellungen vorkonfiguriert. Bei AlloyDB müssen Sie keine Flags auf Datenbankebene anpassen, um eine hohe OLTP-Leistung zu erzielen. Stattdessen ist eine hohe OLTP-Leistung in AlloyDB integriert.

Unterstützte Benchmarktypen

In diesem Dokument wird beschrieben, wie Sie OLTP-Benchmarks mit den folgenden Tools ausführen:

OLTP-Benchmark-Treiber Anwendungsfälle
HammerDB HammerDB misst die Leistung des Systems in Transaktionen pro Minute (TPM) und generiert Berichte mit detaillierten Statistiken und Leistungsmesswerten.

HammerDB unterstützt die Anpassung von Benchmark-Parametern, sodass Sie die Datenbankgröße, die Anzahl der Warehouses und andere Arbeitslastmerkmale anpassen können, um verschiedene Szenarien zu simulieren.

HammerDB enthält eine TPC-C-Benchmark-Implementierung zur Bewertung der Leistung von OLTP-Systemen. Mit der HammerDB-TPC-C-Implementierung können Sie eine Arbeitslast simulieren, die dem TPC-C-Benchmark ähnelt, einschließlich einer Mischung aus Transaktionen, die das Verhalten einer Großhandelsumgebung nachahmen.
pgbench pgbench ist ein Benchmarking-Tool, das im Lieferumfang von PostgreSQL enthalten ist. Mit pgbench können Sie Transaktionsarbeitslasten wie das Einfügen, Aktualisieren und Auswählen von Daten simulieren und die Leistung des Datenbanksystems in Transaktionen pro Sekunde (TPS) messen.

Wenn Sie pgbench verwenden, können Sie die Datenbankgröße, die Anzahl der Clients und den Transaktionsmix anpassen, um Ihre Produktionsarbeitslast zu emulieren und Einblicke in das Verhalten des Systems in verschiedenen Szenarien zu erhalten.
pgbench enthält eine TPC-B-Implementierung. Die pgbench-TPC-B-Implementierung ähnelt einem TPC-B-Benchmark.

Hinweis

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

    Roles required to select or create a project

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

    Go to project selector

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

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

    Roles required to enable APIs

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

    Enable the APIs

  4. Aktivieren Sie die Cloud APIs, die zum Erstellen von AlloyDB for PostgreSQL und zum Herstellen einer Verbindung erforderlich sind.

    APIs aktivieren

    1. Klicken Sie im Schritt Projekt bestätigen auf Weiter, um den Namen des Projekts zu bestätigen, an dem Sie Änderungen vornehmen möchten.

    2. Klicken Sie im Schritt APIs aktivieren auf Aktivieren, um Folgendes zu aktivieren:

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

      Die Service Networking API ist erforderlich, wenn Sie die Netzwerkverbindung zu AlloyDB über ein VPC-Netzwerk konfigurieren möchten, das sich im selben Google Cloud -Projekt wie AlloyDB befindet.

      Die Compute Engine API und die Cloud Resource Manager API sind erforderlich, wenn Sie die Netzwerkverbindung zu AlloyDB über ein VPC-Netzwerk konfigurieren möchten, das sich in einem anderen Google Cloud -Projekt befindet.

Datenbank und Clientcomputer einrichten und bereitstellen

Starten Sie den Benchmark, indem Sie einen AlloyDB-Cluster und eine AlloyDB-Instanz erstellen. Sofern nicht anders angegeben, basieren die Informationen in diesem Dokument auf einer primären AlloyDB-Instanz mit 16 vCPUs und 128 GB RAM.

AlloyDB-Cluster und -Instanz erstellen

  1. Zur Clusterseite.

    Zu den Clustern

  2. Klicken Sie auf Cluster erstellen.

  3. Geben Sie im Feld Cluster-ID einen Namen für den Cluster ein.

  4. Wählen Sie unter Zonale Verfügbarkeit die Option Mehrere Zonen (Hochverfügbarkeit) für den Clustertyp aus.

  5. Wählen Sie das Standardnetzwerk aus.

  6. Wählen Sie im Feld Datenbankversion eine der folgenden Optionen aus:

    • PostgreSQL 17

    • PostgreSQL 18

  7. Notieren Sie sich den Standort der primären Zone und die private IP-Adresse. Erstellen Sie keinen Lesepool.

  8. Klicken Sie auf Cluster erstellen.

Clientcomputer bereitstellen

Zum Ausführen von OLTP-Benchmarks benötigen Sie einen Clientcomputer mit ausreichender Rechenleistung. Benchmark-Tools wie HammerDB und pgbench werden hochgradig parallel ausgeführt und verbrauchen viel CPU. Ein Clientcomputer darf beim Ausführen eines OLTP-Benchmarks kein Engpass sein.

Sofern nicht anders angegeben, wird in den Anleitungen in diesem Dokument eine E2-Standard-32-Maschine mit 128 GB Speicherplatz als Client für OLTP-Benchmarks verwendet, um eine AlloyDB-Instanz auf einer Maschine mit 16 vCPUs und 128 GB RAM auszuführen. Sie müssen den Clientcomputer in derselben Zone wie die primäre AlloyDB-Instanz erstellen.

Wenn Sie den TPC-C-Benchmark auf einer AlloyDB-Primärinstanz mit 16 virtuellen CPUs ausführen möchten, führen Sie die folgenden Schritte aus, um eine Compute Engine-VM zu erstellen und einen Clientcomputer bereitzustellen:

  1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf:

    Zur Seite „VM-Instanzen“

  2. Wählen Sie das Projekt aus, das die AlloyDB-Instanz enthält, zu der Sie eine Verbindung herstellen möchten.
  3. Klicken Sie auf Instanz erstellen.
  4. Klicken Sie auf den Bereich Maschinenkonfiguration.
  5. Geben Sie einen Namen für die Instanz ein.
  6. Konfigurieren Sie die Zone, in der Sie die Instanz erstellen möchten. Die Zone muss mit der Zone der primären AlloyDB-Instanz übereinstimmen.
  7. Wählen Sie den Maschinentyp e2-standard-32 aus.
  8. Behalten Sie die Standardwerte im Bereich Betriebssystem und Speicher bei.
  9. Klicken Sie auf den Abschnitt Netzwerk und legen Sie für Netzwerkschnittstellen das VPC-Netzwerk fest, das für den Zugriff auf private Dienste auf AlloyDB konfiguriert ist.
    Wenn Netzwerkschnittstellen nicht auf das VPC-Netzwerk festgelegt ist, das für den Zugriff auf private Dienste konfiguriert ist, maximieren Sie es und legen Sie dann Netzwerk auf das VPC-Netzwerk fest.
  10. Behalten Sie die Standardwerte im Abschnitt Beobachtbarkeit bei.
  11. Klicken Sie auf den Abschnitt Sicherheit.
  12. Legen Sie unter Identität und API-Zugriff die Zugriffsbereiche auf Uneingeschränkten Zugriff auf alle Cloud APIs zulassen fest.
  13. Behalten Sie die Standardwerte im Abschnitt Erweitert bei.
  14. Klicken Sie auf Erstellen.
  15. Nachdem die VM erstellt wurde, stellen Sie über SSH eine Verbindung zur Compute Engine-VM her, die Sie erstellt haben.

Benchmark-Treibermaschine einrichten

Nachdem Sie die Datenbank und den Clientcomputer installiert und eingerichtet haben, konfigurieren Sie den Clientcomputer, der auf Google Cloudausgeführt wird. Dort installieren Sie Benchmarking-Tools wie HammerDB und pgbench.

So richten Sie die Benchmark-Treibermaschine ein:

  1. Stellen Sie mit dem folgenden gcloud compute ssh-Befehl eine Verbindung zum Clientcomputer her:

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

  2. PostgreSQL-Client installieren

    1. Verwenden Sie den folgenden Befehl, um einen PostgreSQL-Client mit einer psql-Anwendung zu installieren, und prüfen Sie dann, ob Sie eine Verbindung herstellen können.

      sudo apt-get update
sudo apt install postgresql-client

    2. Verwenden Sie den folgenden Befehl, um zu prüfen, ob der Client funktioniert und Sie eine Verbindung zu AlloyDB herstellen können. Verwenden Sie die private IP-Adresse Ihrer primären AlloyDB-Instanz.

      psql -h PRIVATE_IP -U postgres

  3. Installieren Sie den HammerDB-4.6-Treiber für den TPC-C-Benchmark mit den folgenden Befehlen:

    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. Installieren Sie den pgbench-Treiber für TPC-B und verschiedene OLTP-Benchmarks mit den folgenden Befehlen:

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

    Wenn pgbench --version ohne Fehler ausgeführt wird, ist pgbench installiert.

Benchmark-Bereinigung durchführen

Wenn Sie mehrere Benchmarks nacheinander ausführen möchten, müssen Sie zwischen den einzelnen Benchmarks eine Benchmark-Bereinigung durchführen, um genaue und zuverlässige Benchmarking-Ergebnisse zu erhalten.

Durch eine Benchmark-Bereinigung wird sichergestellt, dass sich Resteffekte aus vorherigen Benchmarks nicht auf die Leistungsmessungen der neuen Benchmark auswirken. Benchmark-Bereinigungen tragen auch dazu bei, die Konsistenz und Wiederholbarkeit der Benchmark-Ergebnisse zu gewährleisten. Dies ist wichtig, um aussagekräftige Vergleiche zwischen verschiedenen Systemen anzustellen oder Bereiche für die Optimierung von Hardware, Software oder Konfiguration zu identifizieren.

So führen Sie eine Benchmark-Bereinigung durch, bevor Sie einen weiteren Benchmark ausführen:

  1. Löschen Sie die vorherigen Benchmarkdaten oder die Benchmarkdatenbank. Verwenden Sie den folgenden psql-Befehl auf dem Clientcomputer, um die vorherige Benchmark-Datenbank zu löschen:

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

    Weitere Informationen zur Verwendung von psql finden Sie unter Verbindung zu einer Datenbank herstellen.

  2. Starten Sie die AlloyDB-Instanz neu. In diesem Schritt werden Caches auf Datenbank- und Betriebssystemebene geleert.

TPC-C-Benchmark ausführen

HammerDB ist ein Benchmarking-Tool, das eine TPC-C-Benchmark-Implementierung zur Bewertung der Leistung von OLTP-Systemen enthält. Mit der TPC-C-Implementierung von HammerDB können Sie eine Arbeitslast simulieren, die dem TPC-C-Benchmark ähnelt, einschließlich einer Mischung aus Transaktionen, die das Verhalten einer Großhandelsumgebung nachahmen.

HammerDB misst die Leistung des Systems in Transaktionen pro Minute (TPM) und generiert Berichte mit detaillierten Statistiken und Leistungsmesswerten. Darüber hinaus unterstützt HammerDB die Anpassung der Benchmark-Parameter, sodass Nutzer die Datenbankgröße, die Anzahl der Warehouses und andere Arbeitslastmerkmale anpassen können, um verschiedene Szenarien zu simulieren.

Szenarien für die Leistungsbewertung

Die Leistung des TPC-C-Benchmarkings wird mit den folgenden Methoden bewertet:

  • Teilweise (~30%) im Cache gespeicherter Modus: In diesem Modus wird eine große TPC-C-Datenbank generiert, die nur teilweise in den Zwischenspeicher passt. Die Transaktionen in diesem Modus werden nicht immer aus dem Arbeitsspeicher bereitgestellt und verursachen E/A-Vorgänge in den zugrunde liegenden Speichersubsystemen. Dieses Szenario ist für die OLTP-Anforderungen vieler Nutzer geeignet.

  • Vollständig (100%) im Cache gespeicherter Modus: In diesem Modus passt die TPC-C-Datenbank vollständig in den Zwischenspeicher. Die AlloyDB-Instanz verwendet etwa 90% der verfügbaren 128 GB RAM, einschließlich des Zwischenspeichers.

    Da TPC-C-Transaktionen in diesem Modus nur minimale E/A-Vorgänge ausführen, weil Lesevorgänge hauptsächlich aus dem Zwischenspeicher bedient werden, ist im Vergleich zu teilweise im Cache gespeicherten Ausführungen ein höherer TPM-Wert zu erwarten. Dieses Szenario gilt für die OLTP-Anforderungen von Nutzern mit sehr geringen E/A-Anforderungen.

Clientcomputer einrichten

  1. Benchmark-Treibermaschine einrichten

  2. Wenn Sie mehrere Benchmarks nacheinander ausführen, führen Sie eine Benchmark-Bereinigung durch.

  3. Öffnen Sie die hammerdb/HammerDB-4.6 directory mit dem folgenden Befehl:

    cd hammerdb/HammerDB-4.6

    Sie führen Befehle aus diesem Verzeichnis aus, um den Clientcomputer einzurichten.

  4. Erstellen Sie die Datei setup.env mit den folgenden Befehlen:

    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. Bearbeiten Sie die generierte setup.env-Datei, indem Sie alle hervorgehobenen Parameterwerte durch Parameterwerte ersetzen, die am besten zu Ihrer Umgebungseinrichtung passen.

  6. Optional: Testen Sie den Modus mit teilweisem Cache (~30%), indem Sie in der Datei setup.env den Wert NUM_WAREHOUSE in 3200 ändern. Weitere Informationen finden Sie unter Szenarien für die Leistungsbewertung.

  7. Optional: Testen Sie den vollständig (100%) im Cache gespeicherten Modus, indem Sie in der setup.env file NUM_WAREHOUSE in 576 ändern. Weitere Informationen finden Sie unter Szenarien für die Leistungsbewertung.

TPC-C-Daten in die Datenbank laden

Ein Ladeschritt bezieht sich auf den Vorgang, bei dem die Benchmark-Datenbank mit ersten Daten gefüllt wird, bevor der Leistungstest ausgeführt wird.

Während des Ladeschritts wird die Datenbank gemäß den TPC-C-Spezifikationen mit einer bestimmten Anzahl von Lagern, Kunden und anderen Entitäten gefüllt. Der Zweck des Lastschritts besteht darin, eine realistische Arbeitslast für den Leistungstest zu erstellen und dafür zu sorgen, dass die Testergebnisse über verschiedene Systeme hinweg vergleichbar sind.

Nach Abschluss des Ladeschritts befindet sich die Datenbank in einem konsistenten Zustand mit einem definierten Satz von Anfangsdaten, die für den TPC-C-Benchmarktest verwendet werden können.

So laden Sie die TPC-C-Datenbank:

  1. Wechseln Sie mit dem folgenden Befehl in das Benchmark-Basisverzeichnis:

    cd hammerdb/HammerDB-4.6

  2. Kopieren Sie den folgenden Inhalt und fügen Sie ihn in build-tpcc.sh ein:

    #!/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. Führen Sie den folgenden Ladebefehl aus und warten Sie, bis der Befehl abgeschlossen ist.

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

  4. Validieren Sie den Ladevorgang. Nachdem das vorherige Skript abgeschlossen ist, sollten Sie prüfen, ob das Laden der Datenbank erfolgreich war. Führen Sie den folgenden Befehl aus, um die Datenbankgröße zu prüfen:

    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 einer TPC-C-Konfiguration mit 30% Cache (mit 3.200 Warehouses) beträgt die Größe der tpcc-Datenbank etwa 300 GB.

In einer zu 100% im Cache gespeicherten TPC-C-Konfiguration (mit 576 Warehouses) beträgt die Größe der tpcc-Datenbank etwa 55 GB.

TPC-C-Benchmark ausführen

Sie können jetzt den TPC-C-Leistungstest ausführen. Der TPC-C-Benchmark wird mit der gefüllten Datenbank aus dem Ladeschritt ausgeführt. Der Benchmark generiert eine Reihe von Transaktionen, die eine typische Geschäftsumgebung simulieren, einschließlich Auftragserfassung, Zahlungsabwicklung und Inventarverwaltung. Die Arbeitslast wird in Transaktionen pro Minute (TPM) gemessen. Dies entspricht der Anzahl der vollständigen Geschäftstransaktionen, die das System in einer Minute verarbeiten kann.

Der Ausführungsschritt ist so konzipiert, dass das Datenbanksystem unter realistischen Bedingungen belastet wird und eine standardisierte Methode zur Leistungsmessung bereitgestellt wird, die Sie über verschiedene Datenbanksysteme hinweg vergleichen können. Anbieter und Nutzer verwenden die Ergebnisse des TPC-C-Benchmarks häufig, um die Leistung verschiedener Datenbanksysteme und Hardwarekonfigurationen zu bewerten.

So führen Sie den TPC-C-Benchmark aus:

  1. Wechseln Sie zum Benchmark-Basisverzeichnis:

    cd hammerdb/HammerDB-4.6

  2. Kopieren Sie den folgenden Inhalt und fügen Sie ihn in run-tpcc.sh ein:

    #!/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. Führen Sie das Skript mit den folgenden Befehlen aus:

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

  4. Warten Sie, bis das Skript run-tpcc.sh abgeschlossen ist. Die Ausführung des Skripts dauert etwa 1 Stunde und 10 Minuten. Nachdem das Script abgeschlossen ist, können Sie die Ergebnisse analysieren.

Benchmark-Ergebnisse analysieren

Beim TPC-C-Benchmarking sind „Neue Bestellungen pro Minute“ (NOPM) und „Transaktionen pro Minute“ (TPM) Leistungsmesswerte, mit denen die Leistung eines Datenbanksystems gemessen wird.

  • NOPM: Misst die Anzahl der neuen Bestelltransaktionen, die das System in einer Minute verarbeiten kann. Die Transaktion „Neue Bestellung“ ist eine der wichtigsten Transaktionen im TPC-C-Benchmark und umfasst das Erstellen einer neuen Bestellung für einen Kunden.

  • TPM: Misst die Gesamtzahl der abgeschlossenen Geschäftstransaktionen, die das System in einer Minute verarbeiten kann. Zu den Transaktionen gehören neue Bestelltransaktionen sowie andere im TPC-C-Benchmark definierte Transaktionstypen, z. B. Zahlung, Lieferung und Bestellstatus.

    TPM ist der primäre Leistungsmesswert für den TPC-C-Benchmark, da er ein Gesamtmaß für die Fähigkeit des Systems bietet, eine realistische Arbeitslast zu bewältigen. NOPM kann ein nützlicher Messwert für Systeme sein, die sich auf die Verarbeitung neuer Bestellungen konzentrieren, z. B. E-Commerce- oder Einzelhandelssysteme.

Ergebnisse mit 30% im Cache gespeicherter TPC-C-Datenbank auf einer Maschine mit 16 vCPUs ansehen

Verwenden Sie den folgenden Befehl, um die Leistungswerte für dieses Szenario zu extrahieren:

grep NOPM results/run-tpcc.out

Die erwartete Ausgabe sieht so aus:

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

Mit einer zu 30% im Cache gespeicherten TPC-C-Datenbank auf einer Maschine mit 16 vCPUs (mit NUM_WAREHOUSE=3200 und NUM_USERS=256) werden 252.970 tpm-C (New Order Per Minute) von insgesamt 582.385 AlloyDB-TPM beobachtet.

Ergebnisse mit einer zu 100% im Cache gespeicherten TPC-C-Datenbank auf einer Maschine mit 16 vCPUs ansehen

In einer zu 100% im Cache gespeicherten TPC-C-Datenbank auf einer Maschine mit 16 vCPUs (mit NUM_WAREHOUSE=576 und NUM_USERS=256) werden 428.316 tpm-C (New Order Per Minute) von insgesamt 974.264 AlloyDB-TPM beobachtet.

Verwenden Sie den folgenden Befehl, um die Leistungswerte für dieses Szenario zu extrahieren:

grep NOPM results/tpcc-run.out

Die erwartete Ausgabe sieht so aus:

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

Zusammenfassung der Leistungsergebnisse auf einer Maschine mit 16 vCPUs

In der folgenden Tabelle sind die Benchmark-Leistungsergebnisse für eine Maschine mit 16 vCPUs zusammengefasst:

TPC-C-Szenario NUM_WAREHOUSE NUM_USERS NOPM Kumulativer TPM
30% im Cache gespeichert 3200 256 252.970 582.385
100% im Cache gespeichert 576 256 428.316 974.264

Leistungsmesswerte der Datenbank beobachten

Wenn Sie das Verhalten Ihres Datenbanksystems besser verstehen möchten, können Sie mit den AlloyDB-Monitoring-Tools wichtige Systemmesswerte wie CPU-Auslastung, Arbeitsspeichernutzung und Transaktionen pro Sekunde beobachten. Weitere Informationen finden Sie unter Instanzleistung überwachen.

Nachdem Sie diesen Benchmark ausgeführt haben, können Sie beispielsweise auf der AlloyDB-Seite Übersicht in der Google Cloud Console sehen, dass die durchschnittliche CPU-Auslastung für die zu 100% im Cache gespeicherte TPC-C-Ausführung fast 90 % beträgt.

TPC-C-Benchmark auf einer AlloyDB-Instanz mit 64 vCPUs ausführen

Wenn Sie einen TPC-C-Benchmark auf einer AlloyDB-Instanz mit 64 vCPUs ausführen möchten, folgen Sie denselben Einrichtungsschritten wie unter TPC-C-Benchmark ausführen, verwenden aber andere Maschinentypen.

AlloyDB und den Clientcomputer einrichten

  1. Erstellen Sie einen AlloyDB-Cluster und eine AlloyDB-Instanz und ersetzen Sie 64 vCPU, 512GB als Maschinentyp.

  2. Stellen Sie den Clientcomputer bereit und ersetzen Sie den Maschinentyp durch n2-standard-64.

  3. Benchmark-Treibermaschine einrichten

Benchmark ausführen

  1. Wenn Sie mehrere Benchmarks nacheinander ausführen, führen Sie eine Benchmark-Bereinigung durch.

  2. Richten Sie den Clientcomputer ein und ersetzen Sie dabei die folgenden Werte:

    • Legen Sie für PGHOST die private IP-Adresse Ihrer neuen AlloyDB-Instanz mit 64 vCPUs fest.
    • Legen Sie für das Szenario „30% im Cache gespeicherte TPC-C“ die Werte NUM_WAREHOUSE=12800 und NUM_USERS=1024 fest.
    • Legen Sie für das Szenario „100% im Cache gespeicherte TPC-C“ die Werte NUM_WAREHOUSE=2304 und NUM_USERS=1024 fest.

  3. TPC-C-Datenbank einrichten und laden Wenn Sie den Ladevorgang beschleunigen möchten, ändern Sie den Wert von pg_num_vu in build-tpcc.sh in 64 als diset tpcc pg_num_vu 64.

  4. Führen Sie den TPC-C-Benchmark aus.

Benchmark-Ergebnisse analysieren

In der folgenden Tabelle sind die Benchmark-Leistungsergebnisse auf einer Maschine mit 64 vCPUs zusammengefasst:

Benchmark-Modus NUM_WAREHOUSE NUM_USERS NOPM Kumulativer TPM
30% im Cache gespeichert 12800 1.024 589.598 1.371.160
100% im Cache gespeichert 2304 1.024 716.138 1.665.438

pgbench-TPC-B-Benchmark ausführen

TPC-B (Transaction Processing Performance Council Benchmark B) ist einer der Benchmark-Modi, die in pgbench, einem Benchmarking-Tool für PostgreSQL, verfügbar sind. TPC-B simuliert ein Bankenszenario, in dem mehrere Kassierer Transaktionen auf Kundenkonten ausführen. Die Arbeitslast besteht aus den folgenden Transaktionstypen:

  • Einzahlungen
  • Abbuchungen
  • Kontostandabfragen

Der Benchmark misst die Leistung des Datenbanksystems, indem er eine Mischung dieser Transaktionen simuliert und die Anzahl der Transaktionen pro Sekunde misst, die das System verarbeiten kann.

Der TPC-B-Modus in pgbench generiert eine synthetische Datenbank und simuliert eine Mischung aus Transaktionen, die der TPC-B-Arbeitslast ähnelt, aber nicht offiziell von der TPC-Organisation zertifiziert ist. Der TPC-B-Modus in pgbench bietet zwar eine nützliche Annäherung an die TPC-B-Leistung, sollte aber nicht verwendet werden, um die Einhaltung von TPC-B-Standards zu beanspruchen.

Szenarien zur Leistungsmessung

In diesem Abschnitt wird beschrieben, wie Sie die TPC-B-Leistung in den folgenden kritischen Modi messen. Der einzige Parameter, der sich in diesen Modi unterscheidet, ist der Wert des Parameters SCALE_FACTOR.

Szenario mit teilweise im Cache gespeicherter Datenbank

In diesem Szenario richten Sie eine große Datenbank (ca. 650 GB) mit --scale= 50000 ein und initialisieren sie. Eine große Datenbank, die nicht in den Arbeitsspeicher passt und erhebliche Laufwerk-E/A-Vorgänge verursacht, bietet eine realistische Darstellung vieler Produktionsarbeitslasten.

Eine große Datenbank, die erhebliche Laufwerk-E/A verursacht, kann die Bedeutung des Datenbankdesigns und der Abfrageoptimierung unterstreichen. Eine große Datenbank kann auch Leistungsprobleme im Zusammenhang mit Laufwerk-E/A aufdecken, z. B. langsamer Laufwerkzugriff oder ineffiziente Abfragen, die in einer kleinen oder vollständig speicherresidenten Datenbank möglicherweise nicht offensichtlich sind.

Szenario mit vollständig im Cache gespeicherter Datenbank

In diesem Szenario richten Sie eine Datenbank mit einer Größe von etwa 60 GB ein und initialisieren sie mit --scale=4000, sodass sie sich im Pufferpool befindet. Das Benchmarking einer speicherresidenten Datenbank ist wichtig, da Sie damit die maximale Leistung des Datenbanksystems in einer kontrollierten Umgebung bewerten können.

Eine speicherresidente Datenbank speichert alle Daten im PostgreSQL-Zwischenspeicherpool. Dadurch wird der E/A-Engpass vermieden, der beim Zugriff auf Daten von der Festplatte auftreten kann. In diesem Modus können Sie Leistungsengpässe identifizieren, die nicht mit E/A zusammenhängen, z. B. CPU-Auslastung oder Sperrprobleme, die beim Benchmarking einer Datenbank, die auf Laufwerk-E/A basiert, möglicherweise nicht offensichtlich sind.

Datenbankserver und Clientcomputer einrichten

So richten Sie die Infrastruktur für die Ausführung eines pgbench-TPC-B-Benchmarks ein:

  1. Erstellen Sie einen AlloyDB-Cluster und eine AlloyDB-Instanz und ersetzen Sie 16 vCPU, 128GB als Maschinentyp.

  2. Stellen Sie die Clientmaschine bereit und ersetzen Sie E2-standard-16 (minimum) als Maschinentyp.

  3. Benchmark-Treibermaschine einrichten

  4. Benchmark-Bereinigung durchführen

pgbench-TPC-B-Benchmark ausführen

  1. Stellen Sie mit dem folgenden Google Cloud CLI-Befehl eine Verbindung zum Clientcomputer her:

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

  2. Erstellen Sie die Datei 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. Bearbeiten Sie die generierte Datei setup.env und ersetzen Sie die folgenden Parameterwerte durch Werte, die für Ihre Umgebungseinrichtung geeignet sind.

    • PRIVATE_IP: die private IP-Adresse Ihrer AlloyDB-Instanz.

    Wählen Sie anhand der folgenden Tabelle die Werte für <scale_factor> und <num_clients> aus. Diese Werte müssen mit dem Maschinentyp und der Datenbankgröße (vollständig oder teilweise im Cache gespeichert) skaliert werden. In den Beispielen in diesem Leitfaden werden die Werte SCALE_FACTOR und NUM_CLIENT verwendet, die dem Maschinentyp n2-highmem-16 entsprechen.

    Vollständig im Cache gespeichert Teilweise im Cache
    Maschinentyp SCALE_FACTOR NUM_CLIENTS SCALE_FACTOR NUM_CLIENTS
    n2-highmem-2 500 48 6250 32
    n2-highmem-4 1000 96 12500 64
    n2-highmem-8 2000 192 25.000 128
    n2-highmem-16 4000 384 50.000 256
    n2-highmem-32 8000 768 100000 512
    n2-highmem-64 16.000 1.536 200000 1.024

  4. Erstellen Sie eine pgbench-Datenbank.

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

  5. Initialisieren und laden Sie die pgbench-Datenbank mit den folgenden Befehlen. In diesem Schritt wird das Benchmarking-Dataset erstellt und mit realistischen Daten gefüllt, sodass Sie eine TPC-B-Arbeitslast in der pgbench-Datenbank genau simulieren können.

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

    Erwartete Ladezeiten:

    • Das Laden der teilweise im Cache gespeicherten Datenbank dauert etwa 6 Stunden.
    • Das Laden der vollständig im Cache gespeicherten Datenbank dauert etwa 45 Minuten.

  6. Optional: Führen Sie eine Prüfung der Ladegenauigkeit durch. Der Inhalt der Datei /tmp/pgbench-tpcb-partially-cached-db-init.out sollte in etwa so aussehen:

    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. Optional: Wenn Sie die Genauigkeit der Last weiter prüfen möchten, führen Sie den folgenden PostgreSQL-Befehl aus, um die Größe aller pgbench-Tabellen zu messen:

    1. Stellen Sie eine Verbindung zur pgbench-Datenbank her:

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

    2. Führen Sie den folgenden SQL-Befehl aus:

      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. Vergleichen Sie die Ausgabe des vorherigen Befehls mit der Ausgabe, die Sie für die Ausführung der teilweise im Cache gespeicherten Datenbank (SCALE_FACTOR=50000) erhalten haben.

       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. Führen Sie die folgenden Befehle aus, um eine Arbeitslast für ein Finanzbuchhaltungssystem zu simulieren. Dazu wird eine Reihe von Transaktionen mit Einzahlungen, Überweisungen und Zahlungen ausgeführt, mit denen Sie die Datenbankleistung bei hoher Arbeitslast messen können.

    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

Benchmark-Ergebnisse analysieren

Prüfen Sie die Ausgabe des vorherigen Befehls in der Datei ~/results/alloydb/pgbench/pgbench.run.out. Die TPS-Anzahl sollte nahe an den Zahlen liegen, die in den Szenarien mit vollständig im Cache gespeicherter Datenbank und teilweise im Cache gespeicherter Datenbank angezeigt werden.

Ergebnisse mit einer vollständig im Cache gespeicherten Datenbank

Die Ausgabe des letzten Befehls in pgbench-TPC-B-Benchmark ausführen sollte in etwa so aussehen, wobei --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)

Wenn Sie das Verhalten des Datenbanksystems besser verstehen möchten, können Sie Systemmesswerte wie CPU-Auslastung, Arbeitsspeichernutzung und Transaktionen pro Sekunde in der Google Cloud Console überwachen. Weitere Informationen finden Sie unter Instanzen überwachen.

Ergebnisse mit einer teilweise im Cache gespeicherten Datenbank

Die Ausgabe des letzten Befehls in pgbench-TPC-B-Benchmark ausführen sollte in etwa so aussehen, wobei --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)

Zusammenfassung der Leistungsergebnisse für einen pgbench TPC-B-Benchmark

In der folgenden Tabelle sind die Leistungsergebnisse für einen pgbench TPC-B-Benchmark zusammengefasst:

TPC-B-Szenario SCALE_FACTOR TPS CPU-Auslastung (%)
Teilweise im Cache gespeichert 50.000 17.460 96 %
Vollständig im Cache gespeichert 4000 21.750 94 %

Benchmark „Nur Indexeinfügung“ ausführen

Der Benchmark „Index Insert Only“ ist ein Szenario mit hoher Gleichzeitigkeit und Schreibintensität, das in diesem Abschnitt angepasst wird, um die Leistungsvorteile von AlloyDB für die meisten OLTP-Anwendungen zu veranschaulichen. Zum Ausführen dieses Benchmarks erstellen Sie mehrere Indexe für die Tabelle pgbench_history und führen dann wiederholt INSERT-Vorgänge für die Tabelle pgbench_history über mehrere Clientverbindungen aus.

Benchmarks für „Nur Index einfügen“ messen die Leistung beim Einfügen von Daten in eine Datenbanktabelle, wobei der Schwerpunkt auf den Auswirkungen von Indexen auf den Schreibvorgang liegt. Mit diesem Benchmark können Sie nachvollziehen, wie schnell neue Zeilen einer Tabelle mit und ohne Indexe hinzugefügt werden können. Außerdem wird die potenzielle Verlangsamung durch die Indexwartung während des Einfügens hervorgehoben.

AlloyDB verbessert die Schreibleistung von PostgreSQL, was auch die OLTP-Arbeitslasten verbessert. Um die Leistung von schreibintensiven OLTP-Szenarien zu verbessern, bietet AlloyDB Architekturinnovationen, darunter eine abgestufte Cache-Ebene für Lesevorgänge und eine verteilte und hochskalierbare Speicher-Engine-Technologie für Schreibvorgänge.

AlloyDB und den Clientcomputer einrichten

So richten Sie die Infrastruktur für die Ausführung eines Index Only Insert-Benchmarks ein:

  1. Erstellen Sie einen AlloyDB-Cluster und eine AlloyDB-Instanz und ersetzen Sie 16 vCPU and 128 GB RAM als Maschinentyp.

  2. Stellen Sie die Clientmaschine bereit und ersetzen Sie E2-standard-16 (minimum) als Maschinentyp.

  3. Benchmark-Treibermaschine einrichten

  4. Benchmark-Bereinigung durchführen

Benchmark „Nur Indexeinfügung“ ausführen

  1. Stellen Sie mit dem folgenden Beispielbefehl eine Verbindung zum Clientcomputer her:

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

  2. Richten Sie die Umgebung mit dem folgenden Befehl ein:

    export PGHOST=<private_ip>

  3. Erstellen Sie eine pgbench-Datenbank anhand des folgenden Beispiels. Wenn die Datenbank bereits vorhanden ist, löschen Sie sie und erstellen Sie sie neu.

    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. Initialisieren und laden Sie die pgbench-Datenbank, um sicherzustellen, dass das Benchmarking-Dataset erstellt und mit realistischen Daten gefüllt wird. Bearbeiten Sie die hervorgehobenen Parameter und führen Sie dann den folgenden Befehl aus:

    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. Prüfen Sie, ob die Ausgabe des vorherigen Befehls in etwa so aussieht:

    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. Erstellen Sie das Script index-init.sql mit den folgenden Befehlen:

    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. Führen Sie das index-init.sql-Skript aus:

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

  8. Optional: Datenbank-Schema und anfänglichen Ladevorgang validieren:

    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)

    Nach dem Laden wird die Datenbankgröße voraussichtlich etwa 365 GB betragen:

    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. Erstellen Sie das Script index-inserts-only.sql mit den folgenden Befehlen:

    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. Führen Sie den pgbench-Benchmark mit dem folgenden Befehl aus:

    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

Benchmark-Ergebnisse analysieren

Prüfen Sie die Ausgabe des vorherigen Befehls in der Datei /tmp/pgbench-index-insert-only-run.out. Während dieses Benchmarktests sollten Sie etwa 52.000 Transaktionen pro Sekunde und eine CPU-Auslastung von etwa 88% sehen, wie in der folgenden Beispielausgabe dargestellt.

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)

Benchmark „Nur auswählen“ auf einer Instanz mit 64 vCPUs ausführen

pgbench unterstützt ein integriertes, schreibgeschütztes Szenario, in dem SELECT-Abfragen von mehreren Clientverbindungen wiederholt für eine bestimmte Datenbank ausgeführt werden. Mit diesem Benchmark wird die Leseleistung der Datenbank gemessen, ohne dass der Aufwand für Datenänderungsvorgänge wie INSERT, UPDATE oder DELETE anfällt. Diese SELECT-Abfragen sind Punktabfragen, die die schnellste und effizienteste Art von SELECT-Abfragen sind, da sie nur auf eine einzelne Datenzeile direkt aus den Indexstrukturen zugreifen.

Mit einem Benchmark nur für die Auswahl können Sie Folgendes erreichen:

  • Maximalen Durchsatz erreichen: Da Punktabfragen für einen Index die effizienteste Form von Abfragen in einem Datenbanksystem sind, können Sie den maximal möglichen Durchsatz messen, den AlloyDB erreichen kann.

  • Skalierbarkeit: Wählen Sie nur Benchmarks aus, mit denen Sie die Skalierbarkeit von AlloyDB von 2 vCPUs bis zur maximalen vCPU-Konfiguration testen können, die von AlloyDB angeboten wird.

AlloyDB und den Clientcomputer einrichten

Richten Sie AlloyDB und den Clientcomputer auf einem Maschinentyp mit 64 vCPUs ein.

Benchmark „Nur auswählen“ ausführen

  1. Stellen Sie mit dem folgenden Beispielbefehl eine Verbindung zum Clientcomputer her:

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

  2. Richten Sie die Umgebung mit dem folgenden Befehl ein:

    export PGHOST=<private_ip>

  3. Erstellen Sie die pgbench-Datenbank anhand des folgenden Beispiels:

    psql -h $PGHOST -p 5432 -U postgres

postgres=> create database pgbench;
CREATE DATABASE

  4. Initialisieren Sie die pgbench-Datenbank. Mit dem folgenden Befehl wird die pgbench-Datenbank mit etwa 220 GB realistischen Daten initialisiert. Sie verwenden --scale=15000 für den vollständig im Cache gespeicherten Benchmark „Nur auswählen“.

    Führen Sie dazu diesen Befehl aus:

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

  5. Prüfen Sie, ob die Ausgabe des vorherigen Befehls in etwa so aussieht:

    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. Führen Sie pgbench aus. Dieser letzte Benchmarking-Schritt dauert über eine Stunde.

    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. Prüfen Sie nach Abschluss des Benchmarks die Datei /tmp/pgbench-select-only-run.out auf die endgültigen Ergebnisse.

Benchmark-Ergebnisse analysieren

Während dieses Benchmarktests sollten Sie etwa 467.000 Transaktionen pro Sekunde und eine CPU-Auslastung von etwa 95% beobachten, wie in der folgenden Beispielausgabe gezeigt.

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)

Zusammenfassung der AlloyDB-Benchmark-Ergebnisse

In den folgenden Tabellen sind die AlloyDB-Benchmark-Ergebnisse zusammengefasst, die auf den in diesem Dokument durchgeführten Tests basieren.

HammerDB TPC-C-Leistungsübersicht

AlloyDB-Maschinentyp TPC-C-Arbeitslastszenario NUM_WAREHOUSE NUM_USERS New Orders Per Minute (NOPM) Kumulativer TPM In TPS umgewandelt
16 vCPUs 30% im Cache gespeichert 3200 256 252.970 582.385 9.706
16 vCPUs 100% im Cache gespeichert 576 256 428.316 974.264 16.238
64 vCPUs 30% im Cache gespeichert 12800 1.024 589.598 1.371.160 22.853
64 vCPUs 100% im Cache gespeichert 2304 1.024 716.138 1.665.438 27.757

pgbench-Leistungsübersicht

AlloyDB-Maschinentyp pgbench-Arbeitslast-Szenario Skalierungsfaktor TPS CPU %
16 vCPUs TPC-B-ähnlich, vollständig im Cache gespeichert 4000 20.359 96 %
16 vCPUs TPC-B-ähnlich, teilweise im Cache gespeichert 50.000 14.060 94 %
16 vCPUs Nur Indexeinfügungen 25.000 51.742 88 %
64 vCPUs Max. Durchsatz (nur Auswahl) 15000 467.583 95 %

OLTP-Benchmarking in Cloud SQL for PostgreSQL ausführen

Sie können die entsprechende OLTP-Leistung in PostgreSQL in Cloud SQL for PostgreSQL auf einem Maschinentyp mit 16 vCPUs für eine vergleichende Analyse testen. In diesem Abschnitt wird beschrieben, wie Sie eine Cloud SQL for PostgreSQL-Instanz (oder einen beliebigen PostgreSQL-Server, der auf der Infrastruktur Ihrer Wahl bereitgestellt wird) einrichten, die mit der AlloyDB-Einrichtung vergleichbar ist, die in diesem Leitfaden zum Benchmarking der OLTP-Leistung verwendet wird. In diesem Szenario wird die 16vCPU-SKU ausgewählt, die Hochverfügbarkeit (HA) aktiviert und der Speicher vorkonfiguriert.

Hinweis

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

    Roles required to select or create a project

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

    Go to project selector

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

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

    Roles required to enable APIs

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

    Enable the APIs

  4. Install the Google Cloud CLI.

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

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

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

    gcloud init
  7. Achten Sie darauf, dass Sie für Ihr Nutzerkonto die Rollen "Cloud SQL-Administrator" und "Compute-Betrachter" haben.

    Zur IAM-Seite

    Weitere Informationen zu Rollen und Berechtigungen

Cloud SQL for PostgreSQL-Instanz bereitstellen

  1. Erstellen Sie eine PostgreSQL-Instanz und ersetzen Sie die folgenden Werte:

    • Datenbankversion: PostgreSQL 14
    • Wählen Sie zuerst eine Konfiguration aus: Produktion
    • Region und zonale Verfügbarkeit auswählen: Wählen Sie us-central1 als Region aus.
    • Zonale Verfügbarkeit: Mehrere Zonen (Hochverfügbarkeit)
      • Primäre Zone: us-central1-c
      • Sekundäre Zone: us-central-1-f
    • Maschinentyp: High Memory, 16 vCPUs, 104 GB Dies ist die Maschine, die Cloud SQL for PostgreSQL der entsprechenden AlloyDB-Instanz, die Sie im AlloyDB-Benchmarking-Abschnitt dieses Dokuments erstellt haben, am nächsten kommt.
    • Speicherkapazität: Benutzerdefiniert, 1.500 GB
      • Automatische Speichererhöhungen aktivieren
    • Verschlüsselung: Google-owned and Google-managed encryption key
    • Verbindungen: Private IP-Adresse
      • Netzwerk: default
      • Öffentliche IP-Adresse: Aktiviert

  2. Klicken Sie auf Instanz erstellen.

  3. Notieren Sie sich nach dem Erstellen der PostgreSQL-Instanz die private IP-Adresse. Sie verwenden die IP-Adresse als PGHOST, um Verbindungen mit dem Benchmark herzustellen.

Clientcomputer bereitstellen

  1. Cloud SQL for PostgreSQL-Instanz bereitstellen Wenn Sie den OLTP-Benchmark Ihrer Wahl ausführen möchten, benötigen Sie einen Clientcomputer mit hoher CPU-Leistung in derselben Zone wie die primäre Cloud SQL for PostgreSQL-Instanz in Cloud SQL.

  2. Optional: Alternativ zum vorherigen Schritt können Sie denselben Clientcomputer verwenden, den Sie für das AlloyDB-Benchmarking eingerichtet haben, sofern Folgendes zutrifft:

    • Der Clientcomputer befindet sich in derselben Zone wie die neue primäre PostgreSQL-Instanz (Cloud SQL for PostgreSQL).
    • Der Clientcomputer erfüllt die Mindestanforderungen an CPU, RAM und Laufwerksgröße.

    In diesem Benchmarking-Leitfaden haben Sie die Clientmaschinen wiederverwendet, wenn sie sich in derselben Zone wie die primäre Instanz befanden und groß genug waren, um den Server auf seine volle Kapazität zu bringen.

  3. Wenn Sie einen neuen Clientcomputer erstellt haben, richten Sie den Benchmark-Treibercomputer ein. Folgen Sie andernfalls der Anleitung in diesem Leitfaden für den Benchmark, den Sie ausführen möchten.

Nächste Schritte