AlloyDB ist ein vollständig verwalteter, PostgreSQL-kompatibler Datenbankdienst, der ACID-konforme Transaktionen (Atomicity, Consistency, Isolation, durability) unterstützt. Einige seiner Ansprüche sind:
Dieses Experiment konzentriert sich auf einen Vergleich der Leistung von analytischen Abfragen zwischen AlloyDB und BigQuery. Es gibt einen offiziellen Google-Cloud-Blog zum Benchmarking für AlloyDB, der jedoch mit Standard-PostgreSQL verglichen wird. Das Benchmark-Setup wird diesem Leitfaden folgen, mit zusätzlichen Teilen, um die Abfragen auch auf BigQuery laufen zu lassen.
Werfen wir einen Blick auf die AlloyDB-Komponenten.
Wir erstellen einen Cluster , der alle Ressourcen, wie Datenbanken, Protokolle und andere Metadaten, organisiert.
Ein Cluster enthält mehrere Knoten, d. h. virtuelle Maschineninstanzen, die für die Ausführung der Abfrage bestimmt sind. AlloyDB organisiert die Knoten in Instanzen. Es gibt zwei Arten von Instanzen:
Zwei Google Cloud Blog-Artikel erläutern die transaktionalen und analytischen Aspekte von AlloyDB for PostgreSQL:
1. Intelligente, datenbankgestützte Speicherung
Einige der wichtigsten Punkte aus diesem Artikel sind:
Der Protokollverarbeitungsdienst (LPS) ist ein AlloyDB-interner Dienst, der WAL-Datensätze verarbeitet und Datenbankblöcke erzeugt. Die Rechenschicht kommuniziert nur die WAL-Datensätze an die Speicherschicht. Es sind keine Blockschreibvorgänge erforderlich.
(Folie von der AlloyDB Partner Office Hours Anfang des Jahres)
Auch in anderen Bereichen wie Replikation und Wiederherstellung gibt es zahlreiche Leistungsoptimierungen, so dass sich ein Blick in den Artikel lohnt. Die beiden oben genannten Punkte sind Highlights, die eng mit dem Transaktionsaspekt zusammenhängen.
Ein wichtiges Highlight des Artikels ist, dass AlloyDB maschinelles Lernen verwendet, um auf intelligente Weise die besten Tabellen/Spalten auszuwählen, die im Spaltenformat gehalten werden sollen, und diese Daten später automatisch im Speicher zu halten. Beachten Sie, dass wir beim analytischen Benchmarking die Abfragen zunächst als "Warm-up" ausführen müssen, damit AlloyDB die Arbeitslasten prüfen kann. Erst danach messen wir die Leistung.
(Folie von der AlloyDB Partner Office Hours Anfang des Jahres)
Die Columnar-Engine ermöglicht nicht nur Aggregationsoperationen direkt auf den relevanten Spalten, ohne die Ergebnisse des Scans zu materialisieren, sondern beinhaltet auch mehrere algorithmische Optimierungen durch die Nutzung spaltenspezifischer Metadaten wie Min-Max-Werte, um den Scan zu beschleunigen.
Diese Folie unten ist eine Empfehlung aus den Partner Office Hours zu diesem Thema, die wir versuchen werden, im Benchmark zu überprüfen.
Wir verwenden den TPC-H-Datensatz für das Benchmarking. Ein TPC-H-Benchmark ist ein Transaktionsverarbeitungs- und Datenbank-Benchmark, der speziell für die Entscheidungsunterstützung, d. h. die Analyse, durchgeführt und vom Transaction Processing Performance Council verwaltet wird.
In diesem TPC-H-Setup haben wir acht Tabellen, deren Größe eingestellt werden kann, und Abfragen, die aus Joins und Aggregationen bestehen, um analytische Abfragen darzustellen.
Sie können die TPC-H-Spezifikation in diesem offiziellen Dokument überprüfen, insbesondere in Abschnitt 2.4 , um zu sehen, welche Abfragen verwendet werden.
TPCH_SCALE bestimmt die Größe der Daten in den Tabellen. Zum Beispiel:
- TPCH_SCALE=10 ergibt eine Gesamtzahl von 86.586.082 Zeilen, ~20 GB.
- TPCH_SCALE=30 ergibt eine Gesamtzahl von 259.798.402 Zeilen, ~60 GB.
In diesem Experiment wird AlloyDB mit dieser Spezifikation verwendet:
- Datenbankversion: PostgreSQL 14
- Region: us-central1
- Maschinentyp: 16vCPU / 128GB
Sowohl TPCH scale 10 als auch 30 passen in den Speicher der Columnar Engine. Die Datenbankflags, die gesetzt werden, sind:
Auf der Grundlage dieses spezifischen Experiments kann AlloyDB innerhalb eines bestimmten Schwellenwerts, in diesem Fall ~60 GB Daten, analytische Abfragen durchführen, die mit BigQuery vergleichbar sind. In diesem Experiment wurden alle Abfragen in weniger als 1 Minute abgeschlossen, was wohl tolerierbar ist, wenn man bedenkt, dass AlloyDB in erster Linie für transaktionale Workloads verwendet werden sollte. Die angekündigte hybride transaktionale und analytische Verarbeitung (HTAP) von AlloyDB scheint vielversprechend.
Mehr als 60 GB wären jedoch fragwürdig, da wir dem AlloyDB-Cluster mehr Ressourcen hinzufügen müssen. Die Leistung wäre schlechter als bei BigQuery, wo alle diese Abfragen in weniger als 10 Sekunden abgeschlossen wurden, ohne dass Tabellenpartitionierung oder Clustering verwendet wurden.
