AlloyDB Omni – Übersicht

Wählen Sie eine Dokumentenversion aus:

AlloyDB Omni ist ein herunterladbares Datenbanksoftwarepaket, mit dem Sie eine optimierte Version von AlloyDB for PostgreSQL in Ihrer eigenen Rechenumgebung bereitstellen können. AlloyDB Omni und der vollständig verwaltete AlloyDB-Dienst auf Google Cloud haben dieselben Kernkomponenten. AlloyDB verwendet eine cloudnative Speicherebene, die die WAL-Leistung optimiert, während AlloyDB Omni dieselbe Standardschnittstelle des Dateisystems verwendet, die von PostgreSQL verwendet wird.

Dank der Portierbarkeit von AlloyDB Omni können Sie die Datenbank in vielen Umgebungen ausführen, darunter:

  • Rechenzentren
  • Laptops
  • Cloudbasierte VM-Instanzen

Anwendungsfälle für AlloyDB Omni

AlloyDB Omni eignet sich gut für die folgenden Szenarien:

  • Sie benötigen eine skalierbare und leistungsstarke Version von PostgreSQL, können aber aufgrund von behördlichen oder datenschutzrechtlichen Anforderungen keine Datenbank in der Cloud ausführen.
  • Sie benötigen eine Datenbank, die auch dann weiterläuft, wenn sie nicht mit dem Internet verbunden ist.
  • Um die Latenz zu minimieren, sollten Sie Ihre Datenbank geografisch so nah wie möglich an Ihren Nutzern platzieren.
  • Sie möchten von einer Legacy-Datenbank migrieren, ohne eine vollständige Cloud-Migration durchzuführen.

AlloyDB Omni enthält keine AlloyDB-Funktionen, die auf den Betrieb in Google Cloudangewiesen sind. Wenn Sie Ihr Projekt auf die vollständig verwalteten Skalierungs-, Sicherheits- und Verfügbarkeitsfunktionen von AlloyDB umstellen möchten, können Sie Ihre AlloyDB Omni-Daten in einen AlloyDB-Cluster migrieren. Das funktioniert genauso wie bei jedem anderen anfänglichen Datenimport.

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 mit dem Google Cloud KI-Ökosystem, einschließlich Vertex AI Model Garden und Open-Source-Tools für generative KI.

  • Unterstützung für Autopilot-Funktionen aus AlloyDB inGoogle Cloud , mit denen sich AlloyDB Omni selbst verwalten und optimieren kann.

    AlloyDB Omni unterstützt beispielsweise die automatische Arbeitsspeicherverwaltung und die adaptive automatische Bereinigung veralteter Daten.

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

  • Die spaltenbasierte AlloyDB-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 transaktionale Arbeitslasten in AlloyDB Omni mehr als doppelt so schnell und analytische Abfragen bis zu 100-mal schneller als in Standard-PostgreSQL.

Funktionsweise von 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 in Kubernetes installieren.

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

Von der Protokollierung über das Bereinigen bis hin zur spaltenbasierten Engine können Sie das Datenbankverhalten von AlloyDB Omni mit Datenbank-Flags konfigurieren.

Vorteile der Ausführung von AlloyDB Omni als Container

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

  • Transparentes Abhängigkeitsmanagement: Alle erforderlichen Abhängigkeiten sind im Container gebündelt und werden von Google getestet, um sicherzustellen, dass sie vollständig mit AlloyDB Omni kompatibel sind.
  • Portabilität: AlloyDB Omni funktioniert in allen Umgebungen gleich.
  • Sicherheitsisolation: Sie legen fest, worauf der AlloyDB Omni-Container auf dem Hostcomputer zugreifen kann.
  • Ressourcenverwaltung: Sie können die Menge an 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 System für kontinuierliche Sicherung und Wiederherstellung, mit dem Sie einen neuen Datenbankcluster basierend auf einem beliebigen Zeitpunkt innerhalb eines anpassbaren Aufbewahrungszeitraums erstellen können. So können Sie sich schnell von Datenverlusten erholen.

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

Weitere Informationen finden Sie unter AlloyDB Omni sichern und wiederherstellen.

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

Weitere Informationen finden Sie unter Rechenzentrumsübergreifende Replikation.

AlloyDB Omni-VM-Komponenten

AlloyDB Omni auf VM besteht aus zwei Architektursätzen: PostgreSQL-Komponenten mit AlloyDB for PostgreSQL-Erweiterungen und AlloyDB for PostgreSQL-Komponenten. Im folgenden Diagramm sind beide Gruppen von Komponenten, die Infrastrukturschicht, in der sie sich auf einer VM oder einem Server befinden, und die zugehörigen Funktionen dargestellt, die für jede Komponente zu erwarten sind.

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

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. Übersetzt eine Anfrage von einem Client in einen ausführbaren Plan
  2. Die Daten werden gefunden, die zur Beantwortung der Anfrage erforderlich sind.
  3. Führt alle erforderlichen Filter-, Sortier- und Aggregationsvorgänge aus.
  4. Gibt die Ergebnisse an den Client zurück
Diagramm, das zeigt, wie die Clientanwendungen mit den Datenbankebenen interagieren.
Abbildung 1. Zeigt die Datenbankebenen, die zusammenarbeiten, um auf Anfragen von Clientanwendungen zu reagieren.

Wenn die Clientanwendung eine Anfrage an AlloyDB Omni sendet, passiert Folgendes:

  1. In der Abfrageverarbeitungsebene wird die Abfrage in einen Ausführungsplan umgewandelt, der an die Abfrageausführungsebene gesendet wird.
  2. In der Ebene für die Ausführung von Abfragen werden die Vorgänge ausgeführt, die zum Berechnen der Antwort auf die Abfrage erforderlich sind.
  3. Während der Ausführung können Daten aus dem Puffer-Cache oder direkt aus dem Speicher geladen werden. Wenn die Daten aus dem Speicher geladen werden, werden sie für die zukünftige Verwendung im Cache gespeichert.

Zu den Ressourcen, die bei der Verarbeitung der Anfrage des Clients verwendet werden, gehören CPU, Arbeitsspeicher, E/A, Netzwerk und Synchronisierungspunkte wie Datenbanksperren. Beim Leistungs-Tuning soll die Ressourcennutzung in jedem Schritt der Abfrageausführung optimiert werden.

Das Ziel eines leistungsstarken Datenbankmoduls ist es, auf eine Abfrage mit den geringstmöglichen Ressourcen zu reagieren. Dazu sind ein gutes Datenmodell und ein gutes Abfragedesign erforderlich.

  • Wie können Fragen beantwortet werden, ohne dass dabei auf zu viele Daten zugegriffen wird?
  • Welche Indexe sind erforderlich, um den Suchbereich und die E/A zu reduzieren?
  • Das Sortieren von Daten erfordert CPU- und häufig auch Festplattenzugriff für große Datasets. Wie lässt sich das Sortieren von Daten vermeiden?

Datenspeicher

In AlloyDB Omni werden Daten auf Seiten mit fester Größe gespeichert, die im zugrunde liegenden Dateisystem gespeichert werden. Wenn für eine Abfrage auf Daten zugegriffen werden muss, wird zuerst der Zwischenspeicherpool in AlloyDB Omni geprüft. Wenn die Seite(n) mit den erforderlichen Daten nicht im Pufferpool gefunden werden, liest AlloyDB Omni die erforderlichen Seiten aus dem Dateisystem. Der Zugriff auf Daten aus dem Pufferpool ist deutlich schneller als das Lesen aus dem Dateisystem. Daher ist es wichtig, die Größe des Pufferpools für die Datenmenge zu maximieren, auf die von einer Anwendung zugegriffen wird.

Ressourcenverwaltung

AlloyDB Omni verwendet dynamische Arbeitsspeicherverwaltung, damit der Pufferpool je nach Arbeitsspeicheranforderungen des Systems dynamisch innerhalb der konfigurierten Grenzen wachsen und schrumpfen kann. Daher ist es nicht erforderlich, die Größe des Pufferpools anzupassen. Bei der Diagnose von Leistungsproblemen sollten Sie zuerst die Trefferrate des Zwischenspeicherpools und die Leserate berücksichtigen, um festzustellen, ob Ihre Anwendung vom Zwischenspeicherpool profitiert. Wenn nicht, bedeutet das, dass der Datensatz der Anwendung nicht in den Zwischenspeicherpool passt. Sie sollten dann in Erwägung ziehen, die Größe der Maschine zu ändern und eine Maschine mit mehr Speicher zu verwenden.

Für das Abrufen, Filtern, Aggregieren, Sortieren und Projizieren von Daten sind CPU-Ressourcen auf dem Datenbankserver erforderlich. Um die für diesen Prozess erforderliche Menge an CPU-Ressourcen zu reduzieren, sollten Sie die Menge der zu manipulierenden Daten minimieren. Behalten Sie die CPU-Auslastung auf dem Datenbankserver im Blick, damit die Auslastung im Steady State bei etwa 70 % liegt. Dieser Betrag lässt auf dem Server genügend Spielraum für Nutzungsspitzen oder Änderungen bei den Zugriffsmustern im Laufe der Zeit. Eine Auslastung von nahezu 100% führt zu Mehraufwand durch die Prozessplanung und den Kontextwechsel und kann Engpässe in anderen Teilen des Systems verursachen. Eine hohe CPU-Auslastung ist ein weiterer wichtiger Messwert, der bei Entscheidungen über die Maschinenspezifikationen berücksichtigt werden sollte.

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

Spaltenbasierte Engine

Die spaltenbasierte Engine beschleunigt die Verarbeitung von Scans, Joins und Aggregaten in SQL-Abfrage durch die folgenden Komponenten:

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

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

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

Automatische Speicherverwaltung

Die automatische Speicherverwaltung überwacht und optimiert den Arbeitsspeicherverbrauch in einer gesamten AlloyDB Omni-Instanz kontinuierlich. Wenn Sie Ihre Arbeitslasten ausführen, passt dieses Modul die Größe des gemeinsam genutzten Puffer-Cache basierend auf dem Arbeitsspeicherbedarf an. Standardmäßig legt die automatische Speicherverwaltung die Obergrenze auf 80 % des Systemspeichers fest und weist 10% des Systemspeichers für den gemeinsamen Zwischenspeicher zu. Wenn Sie die Obergrenze für die Größe des freigegebenen Puffer-Cache ä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 Speicherverwaltung.

Adaptives Autovacuum

Das adaptive Autovakuum analysiert Vorgänge basierend auf der Arbeitslast der Datenbank und passt die Häufigkeit der Bereinigung automatisch an. Durch diese automatische Anpassung kann die Datenbank mit maximaler Leistung ausgeführt werden, auch wenn sich die Arbeitslast ändert, ohne dass der VACUUM-Prozess eingreift.

Bei der adaptiven automatischen Bereinigung werden die folgenden Faktoren berücksichtigt, um die Häufigkeit und Intensität der Bereinigungsvorgänge 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

Die adaptive automatische Bereinigung bietet folgende Vorteile:

  • Dynamische Ressourcenverwaltung für VACUUM: Anstelle eines festen Kostenlimits verwendet AlloyDB Omni Echtzeit-Ressourcenstatistiken, um die VACUUM-Worker anzupassen. Wenn das System ausgelastet ist, werden der Vakuumprozess und die zugehörige Ressourcennutzung gedrosselt. Wenn genügend Arbeitsspeicher verfügbar ist, wird zusätzlicher Arbeitsspeicher für maintenance_work_mem zugewiesen, um die End-to-End-Vakuumzeit zu verkürzen.
  • Dynamische XID-Drosselung: Der Fortschritt der Bereinigung und die Geschwindigkeit des Verbrauchs von Transaktions-IDs 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 Vorrücken und Freigeben des Transaktions-ID-Bereichs blockieren. Während dieses Vorgangs wird die Gesamtzahl der Transaktionen pro Sekunde reduziert, bis die Transaktions-IDs in einem sicheren Bereich sind (zu sehen als Sitzungen, die auf AdaptiveVacuumNewXidDelay warten). Wenn das Alter der Transaktions-ID zunimmt, wird die Anzahl der Vacuum-Worker dynamisch erhöht.
  • Effizientes VACUUM für größere Tabellen: Die standardmäßige PostgreSQL-Logik, die entscheidet, wann eine Tabelle bereinigt werden soll, basiert auf tabellenspezifischen Statistiken, die in pg_stat_all_tables gespeichert sind. Diese enthalten das Verhältnis der inaktiven Tupel. Diese Logik funktioniert für kleine Tabellen, ist aber möglicherweise nicht effizient für größere, häufig aktualisierte Tabellen. AlloyDB Omni bietet einen aktualisierten Scanmechanismus, der dazu beiträgt, dass die automatische Bereinigung häufiger ausgelöst wird. Bei diesem Scanmechanismus werden Teile großer Tabellen gescannt und inaktive Tupel effizienter entfernt als mit der standardmäßigen PostgreSQL-Logik.
  • Warnmeldungen protokollieren: In AlloyDB Omni werden VACUUM-Blocker wie Transaktionen mit langer Ausführungszeit, vorbereitete Transaktionen oder Replikationsslots, die ihre Ziele verloren haben, erkannt und Warnungen werden in den PostgreSQL-Logs registriert, damit Sie Probleme rechtzeitig beheben können.

KI-/ML-Worker

In AlloyDB Omni bietet der AI/ML-Hintergrundworker alle Funktionen, die zum direkten Aufrufen von Vertex AI-Modellen aus der Datenbank erforderlich sind. Der KI/ML-Worker wird als Prozess mit dem Namen omni ml worker ausgeführt.

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

Nächste Schritte