OLTP-Leistung in AlloyDB for PostgreSQL benchmarken

In diesem Dokument wird beschrieben, wie Sie AlloyDB for PostgreSQL und einen Clientcomputer konfigurieren, um die Leistung von AlloyDB mit TPC-C, einer OLTP-Benchmarkspezifikation, zu vergleichen. In diesem Dokument wird auch beschrieben, wie Sie benutzerdefinierte, lese- und schreibintensive OLTP-Szenarien ausführen, z. B. Index Insert Only (Nur Indexeinfügung) und Select Only (Nur Auswahl).

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 Unternehmensebene, die für alle Unternehmen und kritischen Arbeitslasten geeignet sind. AlloyDB bietet die folgenden Komponenten und Funktionen, die eine hohe Leistung für transaktionale (OLTP), analytische (OLAP) und hybride (HTAP) Arbeitslasten ermöglichen:

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

Bei relationalen Datenbanksystemen muss in der Regel ein Datenbankadministrator die Datenbank für das Benchmarking optimieren. Dazu gehören die Konfiguration der Transaktionsprotokolleinstellungen, die Festlegung der richtigen Pufferpoolgrößen und die Änderung anderer Datenbankparameter oder Flags und Merkmale. Diese Einstellungen variieren je nach Größe und Typ der Instanz.

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

Unterstützte Benchmark-Typen

In diesem Dokument erfahren Sie, 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, mit denen Sie die Datenbankgröße, die Anzahl der Rechenzentren und andere Arbeitslastmerkmale anpassen können, um verschiedene Szenarien zu simulieren.

HammerDB enthält eine TPC-C-Benchmarkimplementierung 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ßhandelslieferantenumgebung nachahmen.
pgbench pgbench ist ein Benchmarking-Tool, das im Lieferumfang von PostgreSQL enthalten ist. Mit pgbench können Sie Transaktionslasten wie das Einfügen, Aktualisieren und Auswählen von Daten simulieren und die Leistung des Datenbanksystems in Transaktionen pro Sekunde (TPS) messen.

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

Hinweise

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

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

    Go to project selector

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

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

    Go to project selector

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

  6. Aktivieren Sie die Cloud APIs, die zum Erstellen von AlloyDB for PostgreSQL und zum Herstellen einer Verbindung zu dieser Instanz 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 mit einem 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 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. Rufen Sie die Seite Cluster auf.

    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 Zonaler 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 Database version (Datenbankversion) die Option PostgreSQL 15 aus.

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

  8. Klicken Sie auf Cluster erstellen.

Clientcomputer bereitstellen

Für die Ausführung von OLTP-Benchmarks benötigen Sie einen Clientcomputer mit ausreichender Rechenleistung. Benchmark-Tools wie HammerDB und pgbench laufen sehr parallel und verbrauchen viel CPU. Ein Clientcomputer darf kein Engpass sein, wenn Sie einen OLTP-Benchmark ausführen.

Sofern nicht anders angegeben, wird in der Anleitung in diesem Dokument ein E2-standard-32-Rechner mit 128 GB Festplattenspeicher als Client für OLTP-Benchmarks verwendet, um eine AlloyDB-Instanz auf einem Computer mit 16 vCPUs und 128 GB RAM zu steuern. 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 zu provisionieren:

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

    Zu „VM-Instanzen“

  2. Wählen Sie das Projekt mit der AlloyDB-Instanz aus, 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. Übernehmen Sie die Standardwerte im Abschnitt Betriebssystem und Speicher.
  9. Klicken Sie auf den Bereich Netzwerk und legen Sie unter 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 wurde, maximieren Sie es und legen Sie dann Netzwerk auf das VPC-Netzwerk fest.
  10. Behalten Sie im Abschnitt Observability (Sichtbarkeit) die Standardwerte bei.
  11. Klicken Sie auf den Abschnitt Sicherheit.
  12. Legen Sie unter Identität und API-Zugriff die Option 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. Stellen Sie nach dem Erstellen der VM über SSH eine Verbindung zu der von Ihnen erstellten Compute Engine-VM her.

Benchmark-Referenzcomputer 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 den Benchmark-Rechner 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. Installieren Sie den PostgreSQL-Client.

    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. Mit dem folgenden Befehl können Sie prüfen, ob der Client funktioniert und ob 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. Führen Sie die folgenden Befehle aus, um den pgbench-Treiber für TPC-B und verschiedene OLTP-Benchmarks zu installieren:

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

    Wenn die 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 Benchmark-Ergebnisse zu erhalten.

Durch die Bereinigung der Benchmark wird sichergestellt, dass sich die Leistungsmessungen der neuen Benchmark nicht durch Resteffekte aus früheren Benchmarks beeinflussen lassen. Benchmark-Bereinigungen tragen auch dazu bei, Konsistenz und Wiederholbarkeit der Benchmarkergebnisse zu gewährleisten. Dies ist wichtig, um aussagekräftige Vergleiche zwischen verschiedenen Systemen durchzuführen oder Optimierungsmöglichkeiten bei Hardware, Software oder Konfiguration zu identifizieren.

Führen Sie die folgenden Schritte aus, um eine Benchmark-Bereinigung durchzuführen, bevor Sie einen weiteren Benchmark ausführen:

  1. Löschen Sie die bisherigen Benchmark-Daten oder die Benchmark-Datenbank. Verwenden Sie auf dem Clientcomputer den folgenden psql-Befehl, 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. Dabei werden die Caches auf Datenbank- und Betriebssystemebene geleert.

TPC-C-Benchmark ausführen

HammerDB ist ein Benchmarking-Tool, das eine TPC-C-Benchmarkimplementierung 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ßhandelslieferantenumgebung nachahmen.

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

Szenarien zur Leistungsbewertung

Die Leistung von TPC-C-Benchmarks wird anhand der folgenden Methoden bewertet:

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

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

    Da bei TPC-C-Transaktionen nur minimale I/Os ausgeführt werden, da Lesevorgänge hauptsächlich aus dem Puffercache stammen, ist in diesem Modus ein höherer TPM im Vergleich zu Ausführungen mit teilweisem Cache zu erwarten. Dieses Szenario gilt für die OLTP-Anforderungen von Nutzern mit sehr geringen E/A-Anforderungen.

Clientcomputer einrichten

  1. Richten Sie den Benchmark-Rechner ein.

  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 von diesem Verzeichnis aus, um den Clientcomputer einzurichten.

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

    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. Ersetzen Sie dazu alle hervorgehobenen Parameterwerte durch Parameterwerte, die am besten zu Ihrer Umgebungseinrichtung passen.

  6. Optional: Teste den teilweisen (~ 30%) Cache-Modus, indem du in der Datei setup.env NUM_WAREHOUSE in 3200 änderst. Weitere Informationen finden Sie unter Szenarien zur Leistungsbewertung.

  7. Optional: Testen Sie den vollständigen (100%) Cache-Modus, indem Sie in setup.env file NUM_WAREHOUSE in 576 ändern. Weitere Informationen finden Sie unter Szenarien zur Leistungsbewertung.

TPC-C-Daten in die Datenbank laden

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

Während des Ladevorgangs 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 auf verschiedenen Systemen vergleichbar sind.

Nach Abschluss des Ladevorgangs befindet sich die Datenbank in einem konsistenten Zustand mit einer definierten Reihe 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 Basisverzeichnis des Benchmarks:

    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 Befehl aus und warten Sie, bis er abgeschlossen ist.

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

  4. Laden Sie die Datei hoch und prüfen Sie, ob sie korrekt geladen wurde. Nachdem das vorherige Script abgeschlossen ist, sollten Sie prüfen, ob die Datenbank geladen wurde. So prüfen Sie die Datenbankgröße:

    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)

Bei einer TPC-C-Konfiguration mit 30% im Cache (mit 3.200 Lagern) beträgt die Größe der tpcc-Datenbank etwa 300 GB.

Bei einer TPC-C-Konfiguration mit 100% im Cache (mit 576 Data 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 aus dem Ladeschritt gefüllten Datenbank ausgeführt. Der Benchmark generiert eine Reihe von Transaktionen, die eine typische Geschäftsumgebung simulieren, einschließlich Auftragseingabe, Zahlungsabwicklung und Inventarverwaltung. Die Auslastung wird in Transaktionen pro Minute (TPM) gemessen. Dieser Wert gibt an, wie viele abgeschlossene Geschäftstransaktionen das System in einer Minute verarbeiten kann.

Der Ausführungsschritt soll das Datenbanksystem unter realistischen Bedingungen belasten und eine standardmäßige Leistungsmessung ermöglichen, die Sie mit verschiedenen Datenbanksystemen vergleichen können. Anbieter und Nutzer verwenden häufig die Ergebnisse des TPC-C-Benchmarks, um die Leistung verschiedener Datenbanksysteme und Hardwarekonfigurationen zu bewerten.

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

  1. Wechseln Sie zum Basisverzeichnis des Benchmarks:

    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 Script 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 run-tpcc.sh-Script abgeschlossen ist. Die Ausführung des Scripts dauert etwa 1 Stunde und 10 Minuten. Nach Abschluss des Scripts können Sie die Ergebnisse analysieren.

Benchmarkergebnisse analysieren

Bei TPC-C-Benchmarks werden die Leistungsmesswerte „Neue Bestellungen pro Minute“ (New Orders Per Minute, NOPM) und „Transaktionen pro Minute“ (Transactions Per Minute, TPM) verwendet, um die Leistung eines Datenbanksystems zu messen.

  • NOPM:Gibt die Anzahl der Transaktionen für neue Bestellungen an, 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:Gibt die Gesamtzahl der abgeschlossenen Geschäftstransaktionen an, die das System in einer Minute verarbeiten kann. Transaktionen umfassen Transaktionen für neue Bestellungen sowie andere Transaktionstypen, die im TPC-C-Benchmark definiert sind, 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. Die 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 einem Computer mit 16 vCPUs ansehen

Verwenden Sie den folgenden Befehl, um die Leistungszahlen 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 TPC-C-Datenbank mit 30% im Cache auf einem 16-vCPU-Rechner (mit NUM_WAREHOUSE=3200 und NUM_USERS=256) werden 252.970 tpm-C (Neue Bestellung pro Minute) bei einem kumulativen AlloyDB-TPM von 582.385 beobachtet.

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

Auf einer TPC-C-Datenbank mit 100% im Cache auf einem Computer mit 16 vCPUs (mit NUM_WAREHOUSE=576 und NUM_USERS=256) werden 428.316 tpmC (Neue Bestellung pro Minute) bei einem kumulativen AlloyDB-TPM von 974.264 erfasst.

Verwenden Sie den folgenden Befehl, um die Leistungszahlen 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 einem Computer mit 16 vCPUs

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

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

Leistungsmesswerte für Datenbanken beobachten

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

Nach dem Ausführen dieses Benchmarks sehen Sie beispielsweise auf der Seite AlloyDB-Übersicht in der Google Cloud Console, dass die durchschnittliche CPU-Auslastung für den TPC-C-Lauf mit 100% im Cache 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, führen Sie dieselben Einrichtungsschritte wie unter TPC-C-Benchmark ausführen aus, verwenden aber andere Maschinentypen.

AlloyDB und den Clientcomputer einrichten

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

  2. Richten Sie den Clientcomputer ein und ersetzen Sie n2-standard-64 durch den Maschinentyp.

  3. Richten Sie den Benchmark-Rechner ein.

Benchmark ausführen

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

  2. Richte den Clientcomputer ein und ersetze dabei die folgenden Werte:

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

  3. Richten Sie eine TPC-C-Datenbank ein und laden Sie sie. Um das Laden zu beschleunigen, ändern Sie den Wert von pg_num_vu in build-tpcc.sh in 64.diset tpcc pg_num_vu 64

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

Benchmarkergebnisse analysieren

In der folgenden Tabelle sind die Benchmark-Leistungsergebnisse auf einem Computer mit 64 vCPUs zusammengefasst:

Benchmark-Modus NUM_WAREHOUSE NUM_USERS NOPM Kumulatives TPM
30% im Cache 12800 1.024 589.598 1.371.160
100% im Cache 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 Bankszenario, in dem mehrere Bankschalter Transaktionen auf Kundenkonten ausführen. Die Arbeitslast besteht aus den folgenden Transaktionstypen:

  • Einzahlungen
  • Abhebungen
  • Kontoabfragen

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

Der TPC-B-Modus in pgbench generiert eine synthetische Datenbank und simuliert einen Mix aus Transaktionen, der der TPC-B-Arbeitslast ähnelt. Er ist jedoch nicht offiziell von der TPC-Organisation zertifiziert. Der TPC-B-Modus in pgbench bietet zwar eine nützliche Näherung an die TPC-B-Leistung, kann aber nicht als Nachweis der Einhaltung der TPC-B-Standards verwendet werden.

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 mit --scale= 50000 eine große Datenbank (ca. 650 GB) ein und initialisieren sie. Eine große Datenbank, die nicht in den Arbeitsspeicher passt und erhebliche Laufwerks-E/A-Vorgänge verursacht, ist eine realistische Darstellung vieler Produktionslasten.

Eine große Datenbank, die erhebliche Festplatten-E/A verursacht, kann die Bedeutung des Datenbankdesigns und der Abfrageoptimierung unterstreichen. Bei einer großen Datenbank können auch Leistungsprobleme im Zusammenhang mit der Laufwerks-E/A auftreten, z. B. langsamer Laufwerkszugriff oder ineffiziente Abfragen, die bei einer kleinen oder vollständig speicherinternen Datenbank nicht auftreten.

Szenario mit vollständig im Cache gespeicherter Datenbank

In diesem Szenario richten Sie eine Datenbank mit einer Größe von etwa 60 GB mit --scale=4000 ein und initialisieren sie so, dass 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.

In einer speicherresidenten Datenbank werden alle Daten im PostgreSQL-Pufferpool gespeichert. Dadurch wird das E/A-Engpassproblem beseitigt, das beim Zugriff auf Daten auf dem Laufwerk auftreten kann. Mit diesem Modus lassen sich Leistungsengpässe identifizieren, die nicht mit der E/A zusammenhängen, z. B. CPU-Auslastung oder Sperrungsprobleme, die beim Benchmarking einer Datenbank, die auf Laufwerk-E/A basiert, 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 dabei 16 vCPU, 128GB durch den Maschinentyp.

  2. Richten Sie den Clientcomputer ein und ersetzen Sie E2-standard-16 (minimum) durch den Maschinentyp.

  3. Richten Sie den Benchmark-Rechner ein.

  4. Führen Sie eine Benchmark-Bereinigung durch.

pgbench-TPC-B-Benchmark ausführen

  1. Stellen Sie über den 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 setup.env-Datei und ersetzen Sie den folgenden Parameterwert durch Werte, die zu Ihrer Umgebungskonfiguration passen.

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

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

    Vollständig im Cache 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 8.000 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. Dadurch wird sichergestellt, dass der Benchmarking-Datensatz mit realistischen Daten erstellt und gefüllt wird, 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

    Voraussichtliche Ladezeiten:

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

  6. Optional: Führen Sie eine Prüfung der Ladegenauigkeit durch. Der Inhalt der /tmp/pgbench-tpcb-partially-cached-db-init.out-Datei 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: Um die Richtigkeit der Datenbelastung weiter zu überprüfen, führen Sie den folgenden PostgreSQL-Befehl aus, mit dem die Größe aller pgbench-Tabellen gemessen wird:

    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 die Arbeitslast eines Finanzbuchhaltungssystems zu simulieren. Dazu werden 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

Benchmarkergebnisse 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ändiger und teilweiser Caching-Datenbank angezeigt werden.

Ergebnisse mit einer vollständig im Cache gespeicherten Datenbank

Die Ausgabe des letzten Befehls unter 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 nachvollziehen möchten, können Sie mit der Google Cloud Console Systemmesswerte wie CPU-Auslastung, Arbeitsspeichernutzung und Transaktionen pro Sekunde überwachen. Weitere Informationen finden Sie unter Instanzen überwachen.

Ergebnisse mit einer teilweise im Cache gespeicherten Datenbank

Die Ausgabe des letzten Befehls unter 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 50.000 17.460 96 %
Vollständig im Cache 4000 21.750 94 %

Benchmark für Indexeinfügungen ausführen

Der Benchmark „Nur Indexeinfügen“ ist ein hochgradig paralleles, schreibintensives Szenario, das in diesem Abschnitt angepasst wird, um die Leistungsvorteile von AlloyDB für die meisten OLTP-Anwendungen zu zeigen. Um diesen Benchmark auszuführen, 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.

Mit den Benchmarks für Index-Inserts wird die Leistung beim Einfügen von Daten in eine Datenbanktabelle gemessen. Dabei liegt der Schwerpunkt auf den Auswirkungen von Indexen auf den Schreibvorgang. Anhand dieses Benchmarks können Sie nachvollziehen, wie schnell einer Tabelle mit und ohne Index neue Zeilen 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 sich auch positiv auf OLTP-Arbeitslasten auswirkt. Um die Leistung bei schreibintensiven OLTP-Szenarien zu verbessern, bietet AlloyDB architektonische Innovationen wie eine abgestufte Cacheebene für Lesevorgänge und eine verteilte und hoch skalierbare Speicher-Engine-Technologie für Schreibvorgänge.

AlloyDB und den Clientcomputer einrichten

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

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

  2. Richten Sie den Clientcomputer ein und ersetzen Sie E2-standard-16 (minimum) durch den Maschinentyp.

  3. Richten Sie den Benchmark-Rechner ein.

  4. Führen Sie eine Benchmark-Bereinigung durch.

Benchmark „Nur Indexeinträge“ 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 anhand des folgenden Beispiels eine pgbench-Datenbank. 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, damit der Benchmarking-Datensatz 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. Die Ausgabe des vorherigen Befehls sollte in etwa so aussehen:

    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 index-init.sql-Script 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 Skript index-init.sql aus:

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

  8. Optional: Validieren Sie das Datenbankschema und den ersten Ladevorgang:

    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 beträgt die Datenbankgröße voraussichtlich etwa 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. Erstellen Sie das index-inserts-only.sql-Script 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

Benchmarkergebnisse analysieren

Prüfen Sie die Ausgabe des vorherigen Befehls in der Datei /tmp/pgbench-index-insert-only-run.out. Während dieses Benchmark-Tests 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 Szenario, bei dem SELECT-Abfragen aus mehreren Clientverbindungen wiederholt an eine bestimmte Datenbank ausgeführt werden. Mit diesem Benchmark wird die Leseleistung der Datenbank gemessen, ohne dass der Overhead von Datenänderungsvorgängen wie INSERT, UPDATE oder DELETE entsteht. Diese SELECT-Abfragen sind Suchanfragen, die die schnellste und effizienteste Art von SELECT-Abfragen sind, da nur auf eine einzelne Datenzeile direkt aus den Indexstrukturen zugegriffen wird.

Wenn Sie einen Benchmark für „Nur auswählen“ ausführen, können Sie Folgendes erreichen:

  • Maximal möglichen Durchsatz erreichen: Da Punktabfragen in einem 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, um die Skalierbarkeit von AlloyDB von 2 vCPUs bis zur maximalen vCPU-Konfiguration von AlloyDB zu testen.

AlloyDB und den Clientcomputer einrichten

AlloyDB und den Clientcomputer auf einem Maschinentyp mit 64 vCPUs einrichten

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 mit dem folgenden Beispiel:

    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 realistischer Daten initialisiert. Sie verwenden --scale=15000 für den Benchmark „Nur auswählen“ mit vollständig im Cache gespeicherten Daten.

    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. Die Ausgabe des vorherigen Befehls sollte in etwa so aussehen:

    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. Nach Abschluss des Benchmarks finden Sie die endgültigen Ergebnisse in der Datei /tmp/pgbench-select-only-run.out.

Benchmarkergebnisse analysieren

Sie sollten während dieses Benchmark-Tests etwa 467.000 Transaktionen pro Sekunde und eine CPU-Auslastung von etwa 95% beobachten, wie in der folgenden Beispielausgabe dargestellt.

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-Benchmarkergebnisse

In den folgenden Tabellen sind die AlloyDB-Benchmarkergebnisse basierend auf den in diesem Dokument durchgeführten Tests zusammengefasst.

HammerDB TPC-C-Leistungsübersicht

AlloyDB-Maschinentyp TPC-C-Arbeitslastszenario NUM_WAREHOUSE NUM_USERS Neue Bestellungen pro Minute (NOPM) Kumulatives TPM In TPS umgewandelt
16 vCPU 30% im Cache 3200 256 252.970 582.385 9.706
16 vCPU 100% im Cache 576 256 428.316 974.264 16.238
64 vCPU 30% im Cache 12800 1.024 589.598 1.371.160 22.853
64 vCPU 100% im Cache 2304 1.024 716.138 1.665.438 27.757

Leistungsübersicht von pgbench

AlloyDB-Maschinentyp pgbench-Arbeitslastszenario Skalierungsfaktor TPS CPU-%
16 vCPU TPC-B-Ähnlich, vollständig im Cache 4000 20.359 96 %
16 vCPU TPC-B-Ähnlich, teilweise im Cache 50.000 14.060 94 %
16 vCPU Nur Indexeinträge 25.000 51.742 88 %
64 vCPU Maximaler Durchsatz (nur auswählen) 15000 467.583 95 %

OLTP-Benchmarking in Cloud SQL for PostgreSQL ausführen

Sie können die entsprechende OLTP-Leistung von PostgreSQL in Cloud SQL for PostgreSQL auf einem Maschinentyp mit 16 vCPUs für eine Vergleichsanalyse testen. In diesem Abschnitt wird beschrieben, wie Sie eine Cloud SQL for PostgreSQL-Instanz (oder einen beliebigen PostgreSQL-Server, der in der Infrastruktur Ihrer Wahl bereitgestellt wird) einrichten, die mit der AlloyDB-Konfiguration vergleichbar ist, die in diesem Leitfaden für den OLTP-Leistungsvergleich verwendet wird. In diesem Szenario müssen Sie unter anderem die SKU mit 16 vCPU auswählen, die Hochverfügbarkeit (HA) aktivieren und den Speicher vorkonfigurieren.

Hinweise

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

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

    Go to project selector

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

  4. Install the Google Cloud CLI.

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

    gcloud init

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

    Go to project selector

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

  8. Install the Google Cloud CLI.

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

    gcloud init
  10. 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)
      • Hauptzone: us-central1-c
      • Sekundäre Zone: us-central-1-f
    • Maschinentyp: Maschine mit großem Arbeitsspeicher, 16 vCPUs, 104 GB Dies ist der Computer, der in Cloud SQL for PostgreSQL der AlloyDB-Instanz am nächsten kommt, die Sie im Abschnitt zum AlloyDB-Benchmarking dieses Dokuments erstellt haben.
    • 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 zum Benchmark herzustellen.

Clientcomputer bereitstellen

  1. Cloud SQL for PostgreSQL-Instanz bereitstellen Um den OLTP-Benchmark Ihrer Wahl auszuführen, 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 folgende Voraussetzungen erfüllt sind:

    • 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 Clientcomputer 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-Rechner ein. Andernfalls folgen Sie der Anleitung in diesem Leitfaden für den Benchmark, den Sie ausführen möchten.

Nächste Schritte