AlloyDB Omni – Übersicht

AlloyDB Omni ist ein herunterladbares Datenbanksoftwarepaket, mit dem Sie eine optimierte Version von AlloyDB for PostgreSQL in Ihrer eigenen Computing-Umgebung bereitstellen können. AlloyDB Omni und der vollständig verwaltete AlloyDB for PostgreSQL-Dienst auf Google Cloud teilen sich dieselben Kernkomponenten. AlloyDB for PostgreSQL verwendet eine cloudnative Speicherschicht, die die WAL-Leistung optimiert. AlloyDB Omni verwendet dieselbe Standarddateisystemoberfläche wie PostgreSQL.

Dank der Portabilität von AlloyDB Omni können Sie es in vielen Umgebungen ausführen, darunter:

  • Rechenzentren
  • Laptops
  • Cloudbasierte VM-Instanzen

Anwendungsfälle für AlloyDB Omni

AlloyDB Omni eignet sich gut für folgende Szenarien:

  • Sie benötigen eine skalierbare und leistungsstarke Version von PostgreSQL, können aber aufgrund von rechtlichen oder Datensouveränitätsanforderungen keine Datenbank in der Cloud ausführen.
  • Sie benötigen eine Datenbank, die auch dann weiter ausgeführt wird, wenn die Internetverbindung getrennt ist.
  • Um die Latenz zu minimieren, sollten Sie Ihre Datenbank möglichst nah an Ihren Nutzern platzieren.
  • Sie möchten von einer alten Datenbank migrieren, ohne sich zu einer vollständigen Cloud-Migration zu verpflichten.

AlloyDB Omni enthält keine AlloyDB for PostgreSQL-Funktionen, die auf die Ausführung in Google Cloudangewiesen sind. Wenn Sie Ihr Projekt auf die vollständig verwalteten Skalierungs-, Sicherheits- und Verfügbarkeitsfunktionen von AlloyDB for PostgreSQL umstellen möchten, können Sie Ihre AlloyDB Omni-Daten wie bei jedem anderen ersten Datenimport in einen AlloyDB for PostgreSQL-Cluster migrieren.

Wichtige Features

  • Ein PostgreSQL-kompatibler Datenbankserver.
  • Unterstützung für AlloyDB AI, mit der Sie generative KI-Anwendungen für Unternehmen mit Ihren Betriebsdaten erstellen können.
  • Integrationen in das Google Cloud KI-Ökosystem, einschließlich Vertex AI Model Garden und Open-Source-Tools für generative KI.

  • Unterstützung für Autopilotfunktionen von AlloyDB for PostgreSQL inGoogle Cloud , mit denen sich AlloyDB Omni selbst verwalten und optimieren lässt.

    AlloyDB Omni unterstützt beispielsweise die automatische Arbeitsspeicherverwaltung und die adaptive automatische Vakuumbereinigung von veralteten Daten.

  • Ein Indexberater, der häufig ausgeführte Abfragen analysiert und neue Indexe für eine bessere Abfrageleistung empfiehlt.

  • Die spaltenbasierte AlloyDB Omni-Engine, die häufig abgefragte Daten in einem speicherinternen Spaltenformat speichert, um die Leistung von Business Intelligence, Berichten sowie Arbeitslasten von hybriden transaktionsorientierten und analytischen Verarbeitungen (HTAP) zu verbessern.

In unseren Leistungstests sind Transaktionsarbeitslasten in AlloyDB Omni mehr als doppelt so schnell und analytische Abfragen bis zu 100-mal schneller als bei Standard-PostgreSQL.

So funktioniert AlloyDB Omni

Sie können AlloyDB Omni als eigenständigen Server oder als Teil einer Kubernetes-Umgebung installieren.

AlloyDB Omni wird in einem Docker-Container ausgeführt, den Sie in Ihrer eigenen Umgebung installieren. Wir empfehlen, AlloyDB Omni auf einem Linux-System mit SSD-Speicher und mindestens 8 GB Arbeitsspeicher pro CPU auszuführen.

Der AlloyDB Omni Kubernetes-Operator ist eine Erweiterung der Kubernetes API, mit der Sie AlloyDB Omni in den meisten CNCF-kompatiblen Kubernetes-Umgebungen ausführen können. Weitere Informationen finden Sie unter AlloyDB Omni auf Kubernetes installieren.

Ihre Anwendungen stellen eine Verbindung zu Ihrer AlloyDB Omni-Installation her und kommunizieren mit ihr, genau wie Anwendungen eine Verbindung zu einem Standard mit einem PostgreSQL-Datenbankserver herstellen und mit ihm kommunizieren. Auch die Nutzerzugriffssteuerung basiert auf PostgreSQL-Standards.

Mit Datenbank-Flags können Sie das Datenbankverhalten von AlloyDB Omni konfigurieren, z. B. für Logging, Datenbereinigung und die spaltenorientierte Engine.

Vorteile der Ausführung von AlloyDB Omni als Container

Google stellt AlloyDB Omni als Container bereit, den Sie mit Container-Laufzeiten wie Docker und Podman ausführen können. Aus betrieblicher Sicht bieten Container folgende Vorteile:

  • Transparente Abhängigkeitsverwaltung: Alle erforderlichen Abhängigkeiten werden im Container gebündelt und von Google getestet, um sicherzustellen, dass sie vollständig mit AlloyDB Omni kompatibel sind.
  • Portabilität: Sie können davon ausgehen, dass AlloyDB Omni in allen Umgebungen konsistent funktioniert.
  • Sicherheitsisolierung: Sie legen fest, auf welche Ressourcen auf dem Hostcomputer der AlloyDB Omni-Container zugreifen darf.
  • Ressourcenverwaltung: Sie können die Menge der Rechenressourcen definieren, die der AlloyDB Omni-Container verwenden soll.
  • Nahtloses Patchen und Upgraden: Um einen Container zu patchen, müssen Sie nur das vorhandene Image durch ein neues ersetzen.

Datensicherung und Wiederherstellung im Notfall

AlloyDB Omni bietet ein kontinuierliches Sicherungs- und Wiederherstellungssystem, mit dem Sie einen neuen Datenbankcluster zu einem beliebigen Zeitpunkt innerhalb eines einstellbaren Aufbewahrungszeitraums erstellen können. So können Sie bei einem versehentlichen Datenverlust schnell wiederherstellen.

Darüber hinaus kann AlloyDB Omni vollständige Sicherungen der Daten Ihres Datenbankclusters erstellen und speichern, entweder auf Anfrage oder nach einem regelmäßigen Zeitplan. Sie können jederzeit eine Sicherung in einem AlloyDB Omni-Datenbankcluster wiederherstellen, der zum Zeitpunkt der Erstellung der Sicherung alle Daten aus dem ursprünglichen Datenbankcluster enthält.

Weitere Informationen finden Sie unter AlloyDB Omni sichern und wiederherstellen.

Als weitere Methode zur Notfallwiederherstellung können Sie eine rechenzentrumsübergreifende Replikation erreichen, indem Sie sekundäre Datenbankcluster in separaten Rechenzentren erstellen. AlloyDB Omni streamt Daten asynchron von einem bestimmten primären Datenbankcluster an jeden seiner sekundären Cluster. Sie können einen sekundären Datenbankcluster bei Bedarf zu einem primären AlloyDB Omni-Datenbankcluster hochstufen.

Weitere Informationen finden Sie unter Rechenzentrumsübergreifende Replikation.

VM-Komponenten von AlloyDB Omni

AlloyDB Omni auf einer VM besteht aus zwei Architekturkomponenten: PostgreSQL-Komponenten mit AlloyDB for PostgreSQL-Optimierungen und AlloyDB for PostgreSQL-Komponenten. Im folgenden Diagramm sind beide Arten von Komponenten dargestellt, die Infrastrukturschicht, in der sie sich auf einer VM oder einem Server befinden, und die zugehörigen Funktionen, die Sie von jeder Komponente erwarten können.

Diagramm der AlloyDB Omni-Komponentenarchitektur, in dem AlloyDB for PostgreSQL-spezifische Komponenten von PostgreSQL-Komponenten getrennt werden

Abbildung 1. AlloyDB Omni-Architektur

Datenbankmodul

In diesem Dokument wird die Datenbankarchitektur in AlloyDB Omni in einem Container beschrieben. In diesem Dokument wird davon ausgegangen, dass Sie mit PostgreSQL vertraut sind.

Ein Datenbankmodul führt die folgenden Aufgaben aus:

  1. Wandelt eine Abfrage von einem Client in einen ausführbaren Plan um
  2. Sucht nach den Daten, die für die Abfrage erforderlich sind
  3. Führt alle erforderlichen Filter-, Sortier- und Aggregationsschritte aus
  4. Gibt die Ergebnisse an den Client zurück
Diagramm, das zeigt, wie die Clientanwendungen mit den Datenbankschichten interagieren.
Abbildung 1. Die Datenbankebenen, die zusammenarbeiten, um auf Abfragen von Clientanwendungen zu reagieren.

Wenn die Clientanwendung eine Abfrage an AlloyDB Omni sendet, geschieht Folgendes:

  1. Die Abfrageverarbeitungsschicht wandelt die Abfrage in einen Ausführungsplan um, der an die Abfrageausführungsschicht weitergeleitet wird.
  2. Die Abfrageausführungsschicht führt die Vorgänge aus, die zum Berechnen der Antwort auf die Abfrage erforderlich sind.
  3. Während der Ausführung können Daten aus dem Puffercache oder direkt aus dem Speicher geladen werden. Wenn die Daten aus dem Speicher geladen werden, werden sie für zukünftige Verwendungen im Cache gespeichert.

Zu den Ressourcen, die bei der Verarbeitung der Abfrage des Clients verwendet werden, gehören CPU, Arbeitsspeicher, E/A, Netzwerk und synchrone Primitive wie Datenbanksperren. Bei der Leistungsoptimierung wird die Ressourcennutzung bei jedem Schritt der Abfrageausführung optimiert.

Das Ziel einer leistungsstarken Datenbank-Engine besteht darin, eine Abfrage mit den geringsten erforderlichen Ressourcen zu beantworten. Dieses Ziel beginnt mit einem guten Datenmodell und Abfragedesign.

  • Wie können Abfragen mit möglichst wenigen Daten beantwortet werden?
  • Welche Indexe sind erforderlich, um den Suchraum und die I/O zu reduzieren?
  • Für die Sortierung von Daten ist bei großen Datensätzen die CPU und oft auch der Laufwerkzugriff erforderlich. Wie kann die Sortierung von Daten vermieden werden?

Datenspeicher

AlloyDB Omni speichert Daten in Seiten mit fester Größe, die im zugrunde liegenden Dateisystem gespeichert werden. Wenn eine Abfrage auf Daten zugreifen muss, prüft AlloyDB Omni zuerst den Pufferpool. Wenn die Seite(n) mit den erforderlichen Daten nicht im Pufferpool gefunden werden, liest AlloyDB Omni die erforderlichen Seite(n) aus dem Dateisystem. Der Zugriff auf Daten aus dem Pufferpool ist deutlich schneller als das Lesen aus dem Dateisystem. Daher ist es ein wichtiger Faktor, die Größe des Pufferpools für die Menge der Daten zu maximieren, auf die eine Anwendung zugreift.

Ressourcenverwaltung

AlloyDB Omni verwendet die dynamische Arbeitsspeicherverwaltung, um den Pufferpool je nach Arbeitsspeicheranforderungen des Systems dynamisch innerhalb der konfigurierten Grenzen zu vergrößern und zu verkleinern. Daher ist es nicht erforderlich, die Größe des Pufferpools zu optimieren. Bei der Diagnose von Leistungsproblemen sollten Sie zuerst die Pufferpool-Trefferrate und die Leserate prüfen, um festzustellen, ob Ihre Anwendung vom Pufferpool profitiert. Andernfalls passt der Datensatz der Anwendung nicht in den Pufferpool. Sie können dann die Größe auf eine größere Maschine mit mehr Arbeitsspeicher ändern.

Das Abrufen, Filtern, Aggregieren, Sortieren und Projektieren von Daten erfordert CPU-Ressourcen auf dem Datenbankserver. Um die für diesen Vorgang erforderlichen CPU-Ressourcen zu reduzieren, sollten Sie die Menge der zu manipulierenden Daten minimieren. Überwachen Sie die CPU-Auslastung auf dem Datenbankserver, damit die Auslastung im Steady State bei etwa 70 % liegt. Dieser Wert lässt auf dem Server ausreichend Spielraum für Auslastungsspitzen oder Änderungen der Zugriffsmuster im Laufe der Zeit. Eine Auslastung von annähernd 100% führt aufgrund der Prozessplanung und des Kontextwechsels zu einem Overhead und kann zu Engpässen in anderen Teilen des Systems führen. Eine hohe CPU-Auslastung ist ein weiterer wichtiger Messwert, der bei Entscheidungen über die Maschinenspezifikationen berücksichtigt werden sollte.

Die Anzahl der IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) ist ein wichtiger Faktor für die Leistung von Datenbankanwendungen. Sie gibt an, wie viele Eingabe- oder Ausgabevorgänge pro Sekunde das zugrunde liegende Speichergerät an die Datenbank senden kann. Um die IOPS-Grenzwerte des Datenbankspeichers nicht zu überschreiten, minimieren Sie Lese- und Schreibvorgänge im Speicher, indem Sie die Datenmenge maximieren, die in den Pufferpool passt.

Spaltenbasierte Engine

Die spaltenbasierte Engine beschleunigt die Verarbeitung von SQL-Abfragen für Scans, Joins und Aggregate mit den folgenden Komponenten:

  • In-Memory-Spaltenspeicher: Enthält Tabellen- und Materialized-View-Daten für ausgewählte Spalten in einem spaltenorientierten Format. Standardmäßig belegt der Spaltenspeicher 1 GB verfügbaren Arbeitsspeicher. Wenn Sie die Menge des Arbeitsspeichers ändern möchten, die vom Spaltenspeicher verwendet werden kann, legen Sie den Parameter google_columnar_engine.memory_size_in_mb in postgresql.conf fest, der von Ihrer AlloyDB Omni-Instanz verwendet wird.

    Weitere Informationen zum Ändern des Parameters finden Sie unter Konfigurationsparameter ändern.

  • Spaltenbasierter Abfrageplaner und ‑ausführungs-Engine: Unterstützt die Verwendung des Spaltenspeichers in Abfragen.

Automatische Speicherverwaltung

Der automatische Speichermanager überwacht und optimiert kontinuierlich den Arbeitsspeicherverbrauch in einer gesamten AlloyDB Omni-Instanz. Wenn Sie Ihre Arbeitslasten ausführen, passt dieses Modul die Größe des gemeinsamen Puffercaches anhand des Arbeitsspeicherdrucks an. Standardmäßig legt der automatische Speichermanager die Obergrenze auf 80 % des Systemspeichers fest und weist 10% des Systemspeichers dem gemeinsamen Puffercache zu. Wenn Sie die Obergrenze für die Größe des freigegebenen Puffercaches ändern möchten, legen Sie den Parameter shared_buffers in der postgresql.conf fest, die von Ihrer AlloyDB Omni-Instanz verwendet wird.

Weitere Informationen finden Sie unter Automatische Arbeitsspeicherverwaltung.

Adaptives Autovacuum

Das adaptive Autovakuum analysiert Vorgänge basierend auf der Arbeitslast der Datenbank und passt die Häufigkeit des Leeren automatisch an. Durch diese automatische Anpassung kann die Datenbank auch bei sich ändernder Arbeitslast mit maximaler Leistung ausgeführt werden, ohne dass der Löschvorgang die Leistung beeinträchtigt.

Bei der adaptiven automatischen Datenbereinigung werden die folgenden Faktoren verwendet, um die Häufigkeit und Intensität der Datenbereinigung zu bestimmen:

  • Größe der Datenbank
  • Anzahl der fehlerhaften Tupel in der Datenbank
  • Alter der Daten in der Datenbank
  • Anzahl der Transaktionen pro Sekunde im Vergleich zur geschätzten VACUUM-Geschwindigkeit

Adaptives Autovacuum bietet folgende Vorteile:

  • Dynamische Ressourcenverwaltung für die Datenbereinigung: Anstatt ein festes Kostenlimit zu verwenden, nutzt AlloyDB Omni Echtzeit-Ressourcenstatistiken, um die Bereinigungs-Worker anzupassen. Wenn das System ausgelastet ist, werden der Löschvorgang und die zugehörige Ressourcennutzung gedrosselt. Wenn genügend Arbeitsspeicher verfügbar ist, wird maintenance_work_mem zusätzlicher Arbeitsspeicher zugewiesen, um die End-to-End-Vakuumzeit zu verkürzen.
  • Dynamische XID-Drosselung: Der Fortschritt des Aufräumens und die Geschwindigkeit der Transaktions-ID-Nutzung werden automatisch und kontinuierlich überwacht. Wenn das Risiko eines Transaktions-ID-Wraparounds erkannt wird, verlangsamt AlloyDB Omni Transaktionen, um den ID-Verbrauch zu drosseln. Außerdem weist AlloyDB Omni den Vacuum-Workern mehr Ressourcen zu, um die Tabellen zu verarbeiten, die das Fortsetzen und Freigeben des Transaktions-ID-Bereichs blockieren. Während dieses Vorgangs werden die Transaktionen pro Sekunde insgesamt reduziert, bis sich die Transaktions-IDs in einem sicheren Bereich befinden (erkennbar an Sitzungen, die auf AdaptiveVacuumNewXidDelay warten). Wenn das Alter der Transaktions-ID zunimmt, werden die Vacuum-Worker dynamisch erhöht.
  • Effizientes Leeren für größere Tabellen: Die Standardlogik von PostgreSQL, die entscheidet, wann eine Tabelle geleert werden soll, basiert auf tabellenspezifischen Statistiken, die in pg_stat_all_tables gespeichert sind und das Verhältnis der inaktiven Tupel enthalten. Diese Logik funktioniert für kleine Tabellen, ist aber bei größeren Tabellen, die häufig aktualisiert werden, möglicherweise nicht effizient. AlloyDB Omni bietet einen aktualisierten Scanmechanismus, mit dem das automatische Ausräumen häufiger ausgelöst wird. Dieser Scanmechanismus scannt große Tabellen und entfernt inaktive Tupel effizienter als die standardmäßige PostgreSQL-Logik.
  • Warnungen protokollieren: In AlloyDB Omni werden Vacuum-Blocker wie langlaufende Transaktionen, vorbereitete Transaktionen oder Replikationsslots erkannt, die ihre Ziele verloren haben. Warnungen werden in den PostgreSQL-Protokollen protokolliert, damit Sie Probleme zeitnah beheben können.

KI-/ML-Arbeiter

In AlloyDB Omni bietet der KI/ML-Hintergrund-Worker alle Funktionen, die zum Aufrufen von Vertex AI-Modellen direkt über die Datenbank erforderlich sind. Der KI/ML-Arbeiter wird als Prozess namens omni ml worker ausgeführt.

Weitere Informationen finden Sie unter Generative KI-Anwendungen mit AlloyDB AI erstellen.