AlloyDB Omni – Übersicht

AlloyDB Omni ist ein herunterladbares Datenbanksoftwarepaket, mit dem Sie eine optimierte Version von AlloyDB for PostgreSQL in von Ihnen verwalteten Rechenumgebungen bereitstellen können. AlloyDB Omni und der vollständig verwaltete AlloyDB-Dienst auf Google Cloudhaben dieselben Kernkomponenten. AlloyDB verwendet eine cloudnative, disaggregierte Speicherebene, während AlloyDB Omni auf dem Speicher Ihrer Wahl bereitgestellt wird.

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

  • Ihre privaten Rechenzentren
  • Beliebige öffentliche Cloud
  • Ihr Laptop
  • Cloudbasierte VM-Instanzen

AlloyDB Omni bietet zusätzlich zu Standard-PostgreSQL mehrere Verbesserungen, die Skalierbarkeit, Verfügbarkeit, Zuverlässigkeit, Leistung, KI und natürliche Sprache unterstützen. Weitere Informationen finden Sie unter AlloyDB Omni-Ergänzungen für Standard-PostgreSQL.

Anwendungsfälle für AlloyDB Omni

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

  • Sie benötigen eine skalierbare, leistungsstarke Version von PostgreSQL, die Sie aufgrund von behördlichen oder datenschutzrechtlichen Anforderungen lokal ausführen müssen.
  • Sie benötigen eine Datenbank, die auch dann weiter ausgeführt wird, wenn sie nicht mit dem Internet verbunden ist.
  • Sie möchten von einer Legacy-Datenbank migrieren, ohne sich für einen vollständig verwalteten Clouddienst wie AlloyDB for PostgreSQL zu entscheiden.

Wichtige Features

  • Ein 100% 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 Autopilot-Funktionen aus AlloyDB for PostgreSQL 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.

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

In 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 auf eine der folgenden Arten installieren:

  • AlloyDB Omni für Container: ein eigenständiger Datenbankcontainer. Führen Sie AlloyDB Omni auf einem Linux-System mit SSD-Speicher und mindestens 8 GB Arbeitsspeicher pro CPU aus.

  • AlloyDB Omni für Kubernetes: Teil eines Containers in einer Kubernetes-Umgebung. 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.

    Der AlloyDB Omni-Operator vereinfacht grundlegende Datenbankvorgänge. So können Sie Einzel- oder Hochverfügbarkeitsbereitstellungen (High Availability, HA) und Day-2-Vorgänge wie Sicherung, Wiederherstellung, Failover und die Einrichtung der regionsübergreifenden Notfallwiederherstellung (Disaster Recovery, DR) automatisieren.

  • AlloyDB Omni für Linux (Vorabversion): ein RPM-Paketmanager (Red Hat Package Manager), der direkt auf einer VM oder auf Bare Metal ausgeführt wird. AlloyDB Omni für Linux wird als eine Reihe integrierter Softwarekomponenten direkt auf dem Hostbetriebssystem ausgeführt. Es wird das Standard-Linux-Dateisystem für die Speicherung verwendet, sodass Sie Ihre vorhandene Speicherinfrastruktur und Verwaltungspraktiken nutzen können.

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

Von der Protokollierung über die VACUUM-Funktion bis hin zur spaltenbasierten Engine können Sie das Verhalten der AlloyDB Omni-Datenbank 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. Sie können AlloyDB Omni-Container auch in einer Kubernetes-Umgebung bereitstellen, wobei viele grundlegende Vorgänge automatisiert werden.

Im Betrieb bieten Container folgende Vorteile:

  • Transparente Verwaltung von Abhängigkeiten: 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.
  • Portierbarkeit: AlloyDB Omni funktioniert in allen Umgebungen konsistent.
  • 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: Wenn Sie einen Container patchen möchten, ersetzen Sie das vorhandene Image durch ein neues.

Vorteile der Ausführung von AlloyDB Omni in einer RHEL-Umgebung

AlloyDB Omni für Linux (Vorabversion) ist für Umgebungen konzipiert, in denen eine nicht containerisierte Datenbankbereitstellung bevorzugt wird. Dieses Bereitstellungsmodell unterstützt Bare-Metal-Server und virtuelle Maschinen.

Sie können AlloyDB Omni für Linux direkt in einer RHEL-Umgebung (Red Hat Enterprise Linux) oder einer mit Red Hat kompatiblen Umgebung mit Standard-Betriebssystempaketmanagern installieren.

AlloyDB Omni für Linux unterstützt RHEL 9 und Rocky Linux 9.

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

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 bestimmten 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.

AlloyDB Omni-Komponenten

AlloyDB Omni besteht aus zwei Gruppen von Architekturkomponenten: PostgreSQL-Komponenten mit AlloyDB-Erweiterungen und AlloyDB-spezifischen Komponenten.

Das folgende Diagramm zeigt beide Komponentensätze, einschließlich der Infrastrukturschicht, in der sich die Komponenten befinden, und der Funktionen für jede Komponente.

AlloyDB Omni-Komponentenarchitektur mit AlloyDB for PostgreSQL-spezifischen Komponenten und PostgreSQL-Komponenten.

Abbildung 1. AlloyDB Omni-Architektur

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, prüft AlloyDB Omni zuerst den Zwischenspeicherpool. Wenn die Seiten mit den erforderlichen Daten nicht im Zwischenspeicherpool 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. Die Pufferpoolgröße für die Daten, auf die eine Anwendung zugreift, zu maximieren, ist ein wichtiger Faktor. Optional können Sie eine ultraschnelle Cacheebene hinzufügen, um die Abfrageleistung weiter zu verbessern.

Ressourcenverwaltung

AlloyDB Omni verwendet die automatische 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. Wenn Sie Leistungsprobleme diagnostizieren, sollten Sie zuerst Messwerte wie die Trefferrate des Zwischenspeicherpools und die Leseraten 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 größere 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 zu manipulierende Datenmenge minimieren. Überwachen Sie die CPU-Auslastung auf dem Datenbankserver, um sicherzustellen, dass die Steady-State-Auslastung 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 Maschinenspezifikationen berücksichtigt werden sollte.

IOPS (Input/Output Operations Per Second, Eingabe-/Ausgabevorgänge pro Sekunde) 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 oder die Cache-Ebene passt.

Spaltenbasierte Engine

Die integrierte spaltenbasierte Engine beschleunigt die Verarbeitung analytischer Abfragen, die in der Regel vollständige Tabellenscans, komplexe Joins und Aggregate umfassen.

  • 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 30% 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.

  • Spaltenbasierte Abfrageplanung und Ausführungs-Engine: Unterstützt die Verwendung des Spaltenspeichers in Abfragen.

Automatische Speicherverwaltung

Der automatische Arbeitsspeicher-Manager überwacht und optimiert den Arbeitsspeicherverbrauch 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.

Adaptives Autovacuum

Das adaptive Autovakuum analysiert Vorgänge basierend auf der Arbeitslast der Datenbank und passt die Häufigkeit des Staubsaugens automatisch an. Diese automatische Anpassung trägt dazu bei, dass die Datenbank auch bei sich ändernden Arbeitslasten eine optimale Leistung beibehält, ohne dass der VACUUM-Prozess eingreift.

Adaptive Autovacuum verwendet die folgenden Faktoren, um die Häufigkeit und Intensität von Vacuum-Vorgängen 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
  • Ressourcennutzung

KI-/ML-Worker

In AlloyDB Omni bietet der AI/ML-Hintergrundworker die 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.

Nächste Schritte