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 Computer umgebung bereitstellen können. AlloyDB Omni und der vollständig verwaltete AlloyDB-Dienst in Google Cloud verwenden dieselben Kern komponenten. AlloyDB verwendet eine cloudnative Speicherebene, die die WAL-Leistung optimiert, während AlloyDB Omni dieselbe Standardschnittstelle des Dateisystems verwendet, die auch von PostgreSQL verwendet wird.

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 die folgenden Szenarien:

  • Sie benötigen eine skalierbare und leistungsstarke Version von PostgreSQL, können aber aufgrund von gesetzlichen oder datensouveränitätsbezogenen Anforderungen keine Datenbank in der Cloud ausführen.
  • Sie benötigen eine Datenbank, die auch dann ausgeführt wird, wenn sie nicht mit dem Internet verbunden ist.
  • Um die Latenz zu minimieren, möchten Sie Ihre Datenbank so nah wie möglich an Ihren Nutzern platzieren.
  • Sie möchten von einer Legacy-Datenbank migrieren, ohne eine vollständige Cloudmigration durchzuführen.

AlloyDB Omni enthält keine AlloyDB Funktionen, die auf dem Betrieb in Google Cloudbasieren. 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, genau wie bei jedem anderen anfänglichen Datenimport.

Wichtige Features

In unseren Leistungstests sind transaktionsorientierte 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 eine Verbindung zu einem Standard-PostgreSQL-Datenbankserver herstellen und mit ihm kommunizieren. Auch die Nutzerzugriffssteuerung basiert auf PostgreSQL-Standards.

Von der Protokollierung über die Bereinigung 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-Laufzeiten wie Docker und Podman ausführen können. Im Betrieb bieten Container die folgenden Vorteile:

  • Transparente Abhängigkeitsverwaltung: 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: Sie können davon ausgehen, dass AlloyDB Omni in allen Umgebungen konsistent funktioniert.
  • Sicherheitsisolation: Sie wählen aus, worauf der AlloyDB Omni-Container auf dem Hostcomputer Zugriff hat.
  • Ressourcenverwaltung: Sie können die Menge der Rechenressourcen definieren, die der AlloyDB Omni-Container verwenden soll.
  • Nahtloses Patchen und Aktualisieren: Wenn Sie einen Container patchen möchten, 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 nach einem regelmäßigen Zeitplan. Sie können jederzeit eine Wiederherstellung aus einer Sicherung in einen AlloyDB Omni-Datenbankcluster durchführen, 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 Replikation über Rechenzentren hinweg 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 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 Architektursätzen: PostgreSQL-Komponenten mit AlloyDB for PostgreSQL-Erweiterungen und AlloyDB for PostgreSQL-Komponenten. Im folgenden Diagramm sind beide Komponentensätze, die Infrastrukturebene, auf der sie sich auf einer VM oder einem Server befinden, und die zugehörigen Funktionen aufgeführt, die Sie für jede Komponente erwarten können.

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 Abfrage von einem Client in einen ausführbaren Plan
  2. Sucht die Daten, die zum Beantworten der Abfrage 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 Abfragen von Clientanwendungen zu reagieren.

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

  1. Die Abfrageverarbeitungsebene wandelt die Abfrage in einen Ausführungsplan um, der an die Abfrageausführungsebene gesendet wird.
  2. Die Abfrageausführungsebene 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 Puffer-Cache oder direkt aus dem Speicher geladen werden. Wenn die Daten aus dem Speicher geladen werden, werden sie zur zukünftigen Verwendung im Cache gespeichert.

Zu den Ressourcen, die bei der Verarbeitung der Abfrage des Clients verwendet werden, gehören CPU, Arbeitsspeicher, E/A, Netzwerk und Synchronisierungspunkte wie Datenbanksperren. Die Leistungsoptimierung zielt darauf ab, die Ressourcennutzung in jedem Schritt der Abfrageausführung zu optimieren.

Ziel eines leistungsstarken Datenbankmoduls ist es, auf eine Abfrage mit den wenigsten erforderlichen Ressourcen zu reagieren. Dieses Ziel beginnt mit einem guten Datenmodell und einem guten Abfragedesign.

  • Wie können Abfragen beantwortet werden, ohne dass zu viele Daten berücksichtigt werden müssen?
  • Welche Indexe sind erforderlich, um den Suchraum und die E/A zu reduzieren?
  • Für das Sortieren von Daten sind CPU-Ressourcen und bei großen Datasets häufig auch der Zugriff auf das Laufwerk erforderlich. Wie kann das Sortieren von Daten vermieden werden?

Datenspeicher

AlloyDB Omni speichert Daten auf Seiten mit fester Größe, die im zugrunde liegenden Dateisystem gespeichert sind. Wenn eine Abfrage auf Daten zugreifen muss, prüft AlloyDB Omni zuerst den Pufferpool. Wenn die Seiten 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 eine Anwendung zugreifen wird.

Ressourcenverwaltung

AlloyDB Omni verwendet die dynamische Speicherverwaltung, damit der Pufferpool je nach Arbeitsspeicherbedarf des Systems innerhalb der konfigurierten Grenzen dynamisch vergrößert und verkleinert werden kann. Daher ist es nicht erforderlich, die Größe des Pufferpools zu optimieren. Bei der Diagnose von Leistungsproblemen sind die ersten Messwerte, die Sie berücksichtigen sollten, die Trefferrate des Pufferpools und die Leserate, um zu sehen, ob Ihre Anwendung vom Pufferpool profitiert. Wenn nicht, bedeutet das, dass das Dataset der Anwendung nicht in den Pufferpool passt. Sie können dann eine größere Maschine mit mehr Arbeitsspeicher in Betracht ziehen.

Für das Abrufen, Filtern, Aggregieren, Sortieren und Projizieren von Daten sind CPU-Ressourcen auf dem Datenbankserver erforderlich. Um die für diesen Vorgang erforderliche Menge an CPU-Ressourcen zu reduzieren, minimieren Sie die Menge der Daten, die bearbeitet werden müssen. Überwachen Sie die CPU-Auslastung auf dem Datenbankserver, um sicherzustellen, dass die Auslastung im Normalzustand bei etwa 70 % liegt. Dieser Wert lässt ausreichend Spielraum auf dem Server für Auslastungsspitzen oder Änderungen der Zugriffsmuster im Laufe der Zeit. Eine Auslastung von fast 100% führt zu Overhead aufgrund der Prozessplanung und des Kontextwechsels und kann Engpässe in anderen Teilen des Systems verursachen. Eine hohe CPU-Auslastung ist ein weiterer wichtiger Messwert, der bei Entscheidungen zu den Maschinenspezifikationen verwendet werden sollte.

Die 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-Limits des Datenbankspeichers nicht zu überschreiten, minimieren Sie die Lese- und Schreibvorgänge im Speicher, indem Sie die Menge der Daten maximieren, die in den Pufferpool passen.

Spaltenbasierte Engine

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

  • Speicherinterner 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 des Arbeitsspeichers ä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 kontinuierlich die Speichernutzung in einer gesamten AlloyDB Omni-Instanz. 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 gemeinsam genutzten Puffer-Cache zu. Wenn Sie die Obergrenze für die Größe des gemeinsam genutzten 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 Autovacuum analysiert Vorgänge basierend auf der Arbeitslast der Datenbank und passt die Häufigkeit der Bereinigung automatisch an. Diese automatische Anpassung trägt dazu bei, dass die Datenbank auch bei sich ändernder Arbeitslast mit maximaler Leistung ausgeführt wird, ohne dass der Bereinigungsvorgang stört.

Das adaptive Autovacuum verwendet die folgenden Faktoren, 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 Bereinigungsgeschwindigkeit

Das adaptive Autovacuum bietet folgende Vorteile:

  • Dynamische Ressourcenverwaltung für die Bereinigung: Anstelle eines festen Kostenlimits verwendet AlloyDB Omni Echtzeit-Ressourcenstatistiken, um die Bereinigungs-Worker anzupassen. Wenn das System ausgelastet ist, werden der Bereinigungsvorgang 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 Bereinigungszeit von Anfang bis Ende zu verkürzen.
  • Dynamische XID-Drosselung: Überwacht automatisch und kontinuierlich den Fortschritt der Bereinigung und die Geschwindigkeit des Verbrauchs von Transaktions-IDs. Wenn ein Risiko für einen Transaktions-ID-Wraparound erkannt wird, verlangsamt AlloyDB Omni Transaktionen, um den ID-Verbrauch zu drosseln. Außerdem weist AlloyDB Omni den Bereinigungs-Workern mehr Ressourcen zu, um die Tabellen zu verarbeiten, die das Vorrücken und Freigeben von Transaktions-ID-Speicherplatz blockieren. Während dieses Vorgangs wird die Gesamtzahl der Transaktionen pro Sekunde reduziert, bis sich die Transaktions-IDs in einer sicheren Zone befinden (zu sehen als Sitzungen, die auf AdaptiveVacuumNewXidDelay warten). Wenn das Alter der Transaktions-ID zunimmt, wird die Anzahl der Bereinigungs-Worker dynamisch erhöht.
  • Effiziente Bereinigung für größere Tabellen: Die Standard-PostgreSQL-Logik die verwendet wird, um zu entscheiden, wann eine Tabelle bereinigt werden soll, basiert auf tabellenspezifischen Statistiken die in pg_stat_all_tables gespeichert sind und das Verhältnis der fehlerhaften Tupel enthalten. 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, mit dem die automatische Bereinigung häufiger ausgelöst werden kann. Dieser Scanmechanismus scannt Teile großer Tabellen und entfernt fehlerhafte Tupel effizienter als die Standard-PostgreSQL-Logik.
  • Warnmeldungen protokollieren: In AlloyDB Omni werden Bereinigungsblocker wie Transaktionen mit langer Ausführungszeit oder vorbereitete Transaktionen oder Replikations slots, 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 KI/ML-Hintergrund-Worker alle Funktionen, die zum Aufrufen von Vertex AI-Modellen direkt 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.