Was ist Azure HorizonDB (Vorschau)?

Azure HorizonDB ist ein cloudeigener vollverwalteter, KI-fähiger Datenbankdienst, der auf PostgreSQL basiert. Es kombiniert eine aggregierte Compute- und Speicherarchitektur mit einem Datenbank-as-a-Log-Design, um vorhersehbare Leistung, Sicherheit auf Unternehmensniveau, hohe Verfügbarkeit und nahtlose Skalierbarkeit für unternehmenskritische Workloads zu bieten.

Azure HorizonDB ermöglicht Entwicklern, intelligente, KI-gestützte Anwendungen über native Unterstützung für Vektoreinbettungen und Integration mit Azure AI Foundry Tools zu erstellen und gleichzeitig die vollständige PostgreSQL-Kompatibilität beizubehalten, sodass vorhandene Anwendungen problemlos zu Azure HorizonDB migrieren können.

Azure HorizonDB-Anwendungsfälle

Azure HorizonDB ist eine cloudnative, skalierbare Alternative zu selbst verwaltetem PostgreSQL und wurde für unternehmenskritische Workloads entwickelt; dazu gehören unter anderem:

  • Transaktions-Workloads (OLTP) - Transaktionsverarbeitung mit hohem Durchsatz, geringer Latenz und vorhersehbarer Leistung für Geschäftsanwendungen, E-Commerce-Plattformen und SaaS-Backends.
  • KI und intelligente Anwendungen - Native Vektorsuche und Unterstützung für Embeddings ermöglichen es Ihnen, RAG-Pipelines (Retrieval-Augmented Generation), Empfehlungssysteme und semantische Suche direkt auf der Datenbankebene zu erstellen. Ki-Modellmanagement und KI-Pipelines vereinfachen die Erstellung intelligenter Anwendungen in der Datenbank weiter.
  • Massive horizontale Leseskalierung – Anwendungen, die von einer horizontalen Leseskalierung mit zonenresilienten Daten in gemeinsam genutzten Zonen profitieren können.
  • Hybride Anwendungen – Integration mit dem Azure-Ökosystem, transaktionale Daten in Fabric OneLake spiegeln und mit anderen Analysedaten integrieren.

Architektur von Azure HorizonDB

Azure HorizonDB basiert auf zwei grundlegenden Architekturprinzipien: der Trennung von Rechenleistung und Speicher sowie einem Datenbankdesign, bei dem die Datenbank als Protokoll aufgebaut ist.

Diagramm mit der Azure HorizonDB architecture.

Disaggregierte Compute- und Speicherressourcen

Die Architektur trennt die Computeebene vollständig von der Speicherebene:

  • Rechenschicht – Compute in Azure HorizonDB ist zustandslos. Computeressourcen (vCores und Arbeitsspeicher) können unabhängig skaliert werden, ohne dass sich dies auf den Speicher auswirkt und umgekehrt. Sie können Lesevorgänge horizontal skalieren, indem Sie dem HorizonDB-Cluster Replikate hinzufügen.
  • Speicherschicht – Die Speicherschicht verwendet zwei speziell ausgelegte Speicherflotten: eine dediziert für WAL, eine weitere für Daten; bei beiden wird die Dauerhaftigkeit durch Azure Storage abgesichert. Der gesamte Speicher ist standardmäßig zonensicher. Der Speicher skaliert automatisch mit wachsendem Datenvolumen, unabhängig vom bereitgestellten Computetarif.

Die Trennung von Compute und Speicher bietet mehrere Vorteile:

  • Skalieren Sie Compute und Speicher unabhängig nach Workloadanforderungen.
  • Schnelle Bereitstellung von Lesereplikaten, da sie denselben zugrunde liegenden Speicher gemeinsam nutzen und keine Datenreplikation erforderlich ist.
  • Schnelleres Failover für hohe Verfügbarkeit, da der gemeinsam genutzte dauerhafte WAL-Speicher und kein Protokollrücklauf erforderlich ist.

Datenbank-als-Log-Architektur

Azure HorizonDB setzt auf eine Database-as-a-Log-Architektur, bei der ausschließlich das WAL (Write-Ahead Log) von der Compute-Ebene in die Speicherschicht geschrieben wird. Datenseiten werden nicht aus den Computereplikaten in die Speicherebene geschrieben. WAL ist die maßgebliche Quelle für die Datenwahrheit im gesamten System.

  • Alle Schreibvorgänge (Write-Ahead-Log) werden einem dauerhaften Protokolldienst angehängt, bevor sie dem Client gegenüber bestätigt werden. Der WAL-Dienst ist für die Semantik eines Transaktionsprotokolls optimiert und für niedrige Latenz optimiert.
  • Gefiltertes WAL wird nur an die Speicherknoten gesendet, zu denen die Änderungen gehören.
  • Speicherknoten rekonstruieren den Seitenzustand, indem sie das WAL anwenden, und beseitigen so die herkömmlichen E/A-Engpässe bei Prüfpunkten.
  • Dieser Ansatz reduziert die Schreibverstärkung und liefert unabhängig von der Datenbankgröße eine konsistente, vorhersehbare Schreiblatenz.

Die Kombination dieser beiden Prinzipien ermöglicht es Azure HorizonDB, hohe Durchsatzleistung, niedrige Latenz und effiziente Ressourcenauslastung zu liefern und dabei vollständige ACID-Garantien aufrechtzuerhalten.

Cluster

Eine bereitgestellte Azure HorizonDB-Ressource ist ein Cluster. Ein Azure HorizonDB-Cluster hat:

  • Ein oder mehrere Computereplikate, eines davon ist ein beschreibbares primäres Replikat, die übrigen sind lesbare Standbyreplikate.
  • Eine einzelne Kopie der Daten in Zonenresilienzspeicher, die von allen Replikaten im Cluster gemeinsam genutzt werden.
  • Ein Lese-/Schreibzugriffsendpunkt, der immer auf das primäre Replikat verweist.
  • Ein schreibgeschützter Endpunkt, der den Lastenausgleich für Verbindungen zu allen Lesereplikaten übernimmt.

Compute-Replikate

Ein Azure HorizonDB-Computereplikat kann entweder das primäre Replikat (schreibbar) oder ein Standby-Replikat sein, das lesbar ist und gleichzeitig ein Kandidat für Failover ist. Das Computereplikat ist der Ort, an dem sich das relationale Modul PostgreSQL befindet und wo die Sprache, Abfrage und Transaktionsverarbeitung stattfindet. Alle Interaktionen mit dem Azure HorizonDB-Cluster erfolgen über die Computereplikate. Um eine zonenübergreifende Resilienz zu erreichen, benötigen Sie mindestens zwei Replikate im Cluster. Sie können Replikate dem Azure HorizonDB-Cluster hinzufügen oder entfernen, da ihre Workload sie benötigt.

Computereplikate verfügen über 8 GB Arbeitsspeicher pro Bereitgestelltem Kern. Computereplikate verfügen auch über einen lokalen SSD-Cache. Dieser Cache ist ein NVMe-Cache mit geringer Latenz, der hot pages zwischenspeichert und die Notwendigkeit minimiert, Daten aus der Remotespeicherebene abzurufen. Der Cache ist auf allen Replikaten, dem Primärserver und der Standby-Instanz vorhanden.

Computereplikate werden effizient genutzt, da sie Aufgaben im Zusammenhang mit Datenhaltbarkeit und Hochverfügbarkeit an die Speicherschicht auslagern. Diese Auslagerung bietet mehr CPU, Datenträger und Netzwerk, um Geschäftslogik von Anwendungen in der Datenbank auszuführen. Die folgenden Aufgaben werden von den Compute-Replikaten in die Speicherebene ausgelagert.

Aufgabe PostgreSQL-Prozess Ressourceneinsparungen
WAL-Senden von Replikaten walsender Datenträger-E/A, Netzwerk-E/A
WAL-Archivierung in Blob Storage Archivierer Datenträger-E/A, Netzwerk-E/A
Schreiben von modifizierten Seiten Hintergrundschreiber Datenträger-E/A
Setzen von Prüfpunkten Checkpointer Datenträger-E/A
Datensicherungen pg_dump, pg_basebackup, pg_backup_start, pg_backup_stop Datenträger-E/A
Full page writes Backend-Prozesse, die WAL schreiben Datenträger-E/A
PostgreSQL WAL-Wiederherstellung Starten der Wiederherstellung Datenträger-E/A
PostgreSQL-Lesereplikat – Wiederholen Starten der Wiederherstellung Datenträger-E/A

Storage

Azure HorizonDB führt zwei Speicherflotten aus, die von Azure BLOB-Speicher unterstützt werden. Alle Ebenen des Speicherstapels sind standardmäßig zonensicher.

WAL-Speicherung

DER WAL-Dienst ist ein zweckorientierter Dienst, der WAL aus dem primären Computereplikat akzeptiert und für niedrige Latenz und WAL-Schreibmuster optimiert ist. Wenn eine Datenänderung (Einfügen/Aktualisieren/Löschen) für das primäre Replikat vorgenommen wird, wird WAL in den WAL-Dienst geschrieben und die Transaktion wird bestätigt. WAL wird dann asynchron auf die jeweiligen Daten-Shards in der Speicherflotte angewendet, um die neuesten Änderungen zu übernehmen. Darüber hinaus wird WAL an sekundäre Computereplikate gesendet, um alle Änderungen an Seiten zu wiederholen, die sich im Arbeitsspeicher der Replikate befinden. WAL wird dann im Azure-Blobspeicher archiviert und für den konfigurierten kurzfristigen Aufbewahrungszeitraum beibehalten.

Datenspeicherung

Die Datenspeicherflotte ist ein Cache für alle Daten in der Datenbank, die Daten für alle Computereplikate im Azure HorizonDB-Cluster bereitstellt. Der Speicher wird dynamisch zugewiesen, da die Datenbank wächst, ohne die Speichergröße oder IOPS konfigurieren zu müssen. Daten aus Postgres-Beziehungen werden über die mehrere Speicherknoten in der Flotte verteilt, um eine verbesserte Skalierbarkeit zu ermöglichen. Es gibt mehrere Kopien derselben Datenshards, die über Zonen hinweg gespeichert sind, um Resilienz zu gewährleisten. Da WAL auf der Speicherflotte wiedergegeben wird, werden modifizierte Seiten aus der Speicherflotte dann in Azure Blob Storage geschrieben.

Azure Blob-Speicher

Azure Blob Storage gewährleistet die Dauerhaftigkeit von Datenbankdaten und dient auch als Datenspeicher für die WAL-Archivierung. Daten werden auf zonenredundanten Speicherkonten gespeichert. Datenbanksicherungen werden als Momentaufnahmen der Blobs implementiert.

Preis

Azure HorizonDB berechnet derzeit Folgende Gebühren:

  • Bereitgestellte Rechenleistung in Core-Stunden,
  • Verwendeter Datenbankspeicher (GB/Monat) und
  • Verwendeter Sicherungsspeicher für den kurzfristigen Aufbewahrungszeitraum.

Weitere Preisdetails finden Sie auf der Preisseite

Einschränkungen

Azure HorizonDB befindet sich derzeit in Preview. Die folgenden Features sind noch nicht verfügbar, wir arbeiten aktiv an diesen Features.

Funktion Status Hinweise
Konfigurierbare Aufbewahrung von Sicherungen Noch nicht verfügbar Derzeit beträgt die Aufbewahrungsdauer für Backups sieben Tage. Wir arbeiten daran, eine Sicherungsaufbewahrung von 1 bis 35 Tagen zu ermöglichen.
Regionsübergreifende Lesereplikate Noch nicht verfügbar Die regionsübergreifende Replikation für die Notfallwiederherstellung wird noch nicht unterstützt.
Vom Kunden verwaltete Schlüssel (CMK) für die Verschlüsselung Nicht verfügbar Verschlüsselung im Ruhezustand verwendet derzeit nur dienstverwaltete Schlüssel.
Konfigurierbare Wartungsfenster Noch nicht verfügbar Derzeit treten Upgrades in einem vom System verwalteten Wartungsfenster auf. Die Möglichkeit zum Konfigurieren von benutzerdefinierten Wartungsfenstern ist noch nicht verfügbar.
Verbindungspooling (PgBouncer) Noch nicht verfügbar Ein externer Verbindungspooler kann verwendet werden, während wir Connection-Pooling für den Dienst implementieren.
Langzeitaufbewahrung (Long-Term Retention, LTR) Nicht verfügbar Derzeit beträgt die Aufbewahrungsdauer für Backups sieben Tage.
Indexoptimierung Noch nicht verfügbar Die Indexoptimierung wird in Kürze verfügbar sein.
Einspeisung in virtuelle Netzwerke Nicht verfügbar Derzeit unterstützen wir den privaten Link. Die Integration virtueller Netzwerke wird noch nicht unterstützt.

Note

Diese Liste spiegelt den aktuellen Status des Diensts wider und kann sich ändern, wenn neue Funktionen veröffentlicht werden. Schauen Sie sich die Versionshinweise für die neuesten Updates an.

Azure-Regionen

Azure HorizonDB ist derzeit in den folgenden Azure Regionen verfügbar:

Geography Regions
Amerika Kanada Zentral, Zentral-USA, Ost-USA, West-USA 2, West-US 3
Europe Deutschland West Central, Schweden Zentral
Asia Pacific Australia East

Note

Die Verfügbarkeit von Regionen kann geändert werden, und wir werden bald weitere Regionen hinzufügen. Einige Regionen haben möglicherweise Einschränkungen für neue Bereitstellungen. Die neueste Verfügbarkeit der Region finden Sie im Azure Portal, oder wenden Sie sich an Azure-Support.

Feedback und Support

Wenn Sie Fragen oder Vorschläge zu Azure HorizonDB haben, können Sie Hilfe und Support über die folgenden Kanäle erhalten:

Verwandte Inhalte

  • Last updated on