Planen Sie Azure Database for PostgreSQL-Bereitstellungen für die betriebliche Leistungsfähigkeit

Cloud Computing hat die Datenbankhostinglandschaft erheblich umgestaltet. Es bietet Teams Zugriff auf Skalierbarkeit, Resilienz, globale Reichweite und Funktionen, die zuvor nicht erreichbar waren. Anstatt erhebliche Kosten und Overhead zu verursachen, indem sie die größtmögliche Arbeitslast planen (und diese Kosten von Tag eins an tragen), können Teams jetzt die genaue Skalierung optimieren, die sie benötigen, und sich anpassen, wenn sich ihre Anforderungen ändern.

Einführung

Die Flexibilität bei der Auswahl des geeigneten Gleichgewichts von Ressourcen ist besonders für PostgreSQL-Datenbankbereitstellungen nützlich. PostgreSQL-Datenbankworkloads können klein beginnen, schnell wachsen, saisonal steigen, von Leselasten zu Schreiblasten wechseln oder sich von Transaktionsworkloads in Hybridbetriebs- und Analysesysteme in Echtzeit entwickeln. Azure Database for PostgreSQL sicherstellen, dass Ihre Lösungen Ihre Ziele erreichen, indem sie eine breite Palette von Auswahlmöglichkeiten für Compute, Speicher, Verfügbarkeit, Replikation, Sicherheit, Sicherung und Betriebsverwaltung bieten.

Aber mit all dieser Leistungsfähigkeit kommt die Verantwortung, insbesondere bei der Planung Ihrer Bereitstellungen. Um die bestmögliche Leistung zu erzielen, müssen Ihre Bereitstellungsentscheidungen den Anforderungen Ihrer gesamten Workload entsprechen.

Eine erfolgreiche Azure Database for PostgreSQL Bereitstellung ist nicht nur eine Frage der Auswahl von "die meisten Kerne und Arbeitsspeicher, die wir benötigen." Stattdessen besteht die maximale Betriebsleistung darin, das Verhalten Ihrer Anwendung, das Verhalten des Clients, die Berechnungs-, Speicher- und Datenbankwachstumsmerkmale zu verstehen und wie sich diese alle überschneiden und interagieren.

Die beste Architektur ist die, bei der diese Teile absichtlich ausgerichtet sind.

Cloudleistungsplanung ist eine gemeinsame Verantwortung

Einer der wichtigsten Vorteile der Umstellung auf eine vertrauenswürdige Cloudplattform ist das Modell der gemeinsamen Verantwortung. Microsoft bietet die globale Infrastruktur, verwaltete Dienste, Hardwareinnovation, Zuverlässigkeit, Sicherheit und Betriebstechnik. Ihre Teams bringen die spezifische Anwendungskontextkompetenz mit sich: Unternehmenskritischität, Arbeitsauslastungsverhalten, Datenmodellentwurf, Netzwerkdatenverkehrprofil, Wachstumserwartungen, Wiederherstellungsziele und Anforderungen an die Endbenutzererfahrung.

Die stärksten Ergebnisse ergeben sich, wenn diese beiden Kräfte vereinheitlicht sind.

Azure bietet hoch skalierbare Postgres-Infrastruktur, aber Ihr Team muss Einblicke in diese Bereiche bringen:

Wie viele gleichzeitige Benutzer werden während normaler und Spitzenzeiten erwartet?
Sind die wichtigsten Operationen leseintensiv, schreibintensiv oder gemischt?
Spitzt sich die Nachfrage während des Monatsendes, des Quartals, der Feiertage, der Starts oder der Berichterstellungsfenster an?
Wie schnell wächst das Dataset?
Welche Vorgänge sind latenzempfindlich?
Welche Abfragen oder Aufträge können längere Laufzeiten tolerieren?
Ist die Workload in erster Linie OLTP, OLAP oder Hybrid?
Befinden sich die Clients in der Nähe der Datenbankregion, sind sie global verteilt, oder sind sie auf eine bestimmte Geografie konzentriert?

Erfassen Sie diese Details vor der Bereitstellung, nicht nach einem Produktionsvorfall. Cloudbereitstellungen vereinfachen die Skalierung, aber die leistungsstärksten und kosteneffizientesten Designs beginnen weiterhin mit fundierten Anforderungen und der richtigen Planung. In den meisten Fällen können diese Fragen auf die Beziehungen zwischen gleichzeitigen Verbindungen, maximalen IOPS und erforderlichem Durchsatz destilliert werden.

Die Leistung verfügt über mehrere Ebenen

Die Datenbankleistung wird selten durch eine einzelne Einstellung bestimmt. Erfolgreiche Bereitstellungserfahrungen sind von mehreren Ebenen abhängig, die zusammenarbeiten:

Leistung der Anwendungsschicht.
Diese Ebene umfasst Anwendungscode, Abfragemuster, Indexabdeckung, Triggerverwendung, Datenpartitionierung, Verbindungsbehandlung, Zwischenspeicherung, Wiederholungslogik, Pooling, ORM-Verhalten, Transaktionsentwurf und Hintergrundauftragsverhalten.
Client- und Netzwerkschichtleistung.
Diese Ebene umfasst, wo sich Clients befinden, wie sie eine Verbindung herstellen, ob Anforderungen regionenübergreifend verarbeitet werden und Verfügbarkeitszonen betreffen, Netzwerklatenz, TLS-Overhead, Verbindungsfluktuationen und ob die Anwendung Verbindungs-Pooling effizient verwendet.
Leistung der Datenbankplattform.
Diese Ebene umfasst die Konfiguration der Postgres-Bereitstellung, die Computegröße, den Arbeitsspeicher, die CPU, den Speichertyp, die Speichergröße, die Speicher-IOPS, den Speicherdurchsatz, hohe Verfügbarkeit, Replikate und Wartungsvorgänge.This layer includes Postgres deployment configuration, compute size, memory, CPU, storage type, storage size, storage IOPS, storage throughput, high availability, replicas, and maintenance operations.

Dieser Artikel konzentriert sich in erster Linie auf die dritte Ebene: Die Planung der Azure Postgres-Datenbankbereitstellung, sodass Compute- und Speicheroptionen das erforderliche Leistungsprofil unterstützen.

Azure Database for PostgreSQL bietet Flexibilität, aber die Planung ist unerlässlich.

Azure Database for PostgreSQL Flexible Server bietet eine Vielzahl von Bereitstellungsoptionen, darunter:

Bereitstellungsgebiet	Verfügbare Auswahlmöglichkeiten
Compute	Computestufen, virtuelle Maschinen-Generationen (VM-Generationen), Allzweckkonfigurationen und speicheroptimierte Konfigurationen.
Storage	Azure Premium SSD v1, Premium SSD v2, Speicherskalierung, IOPS-Konfiguration und Durchsatzkonfiguration.
Verfügbarkeit	Hohe Verfügbarkeit, Sicherung und Wiederherstellung sowie georedundante Sicherungen in unterstützten Konfigurationen.
Replikation	Lesen von Replikaten und Georeplikaten.
Security	Vom Kunden verwaltete Schlüssel und Unternehmenssicherheitsintegration.

Diese Flexibilität ist leistungsfähig, da unterschiedliche Workloads unterschiedliche Funktionen erfordern. Ein schreibintensives Transaktionssystem benötigt nicht das gleiche Profil wie ein berichtsintensives System. Eine globale SaaS-Anwendung benötigt nicht den gleichen Entwurf wie eine interne regionale Anwendung. Eine Datenbank, die 5% pro Jahr wächst, benötigt nicht denselben Speicherplan wie eine, die monatlich um 200% wächst.

Das Planungsziel besteht darin, Die Anforderungen Ihres Workload-Leistungsprofils zu identifizieren und dann die richtigen Optionen für Compute- und Speicheroptionen zu implementieren, um Ihre End-to-End-Lösungen erfolgreich bereitzustellen.

Beginnen Mit dem Workloadprofil

Definieren Sie vor der Auswahl von Compute oder Speicher die Workload. Zu den nützlichen Planungsdimensionen gehören:

Planungsbereich	Zu beantwortende Fragen
Geografie	Wo befinden sich Benutzer, Anwendungen, Replikate und Integrationen?
Konkurrenz	Wie viele gleichzeitige Verbindungen und aktive Abfragen werden erwartet?
Datengröße	Was ist die aktuelle Datenbankgröße, und was ist die erwartete Wachstumsrate?
Änderungsrate	Wie schnell wachsen Daten im Monat? Wie viel Write-Ahead-Log (WAL) wird generiert?
Workload-Typ	Ist das System OLTP, OLAP, Berichtslastig, Batchlast oder Hybrid?
Mischung aus Lese-/Schreib-Operationen	Welcher Prozentsatz der Vorgänge sind Lese- und Schreibvorgänge?
Spitzenverhalten	Gibt es vorhersehbare Geschäftszyklen, saisonale Spitzen oder Batchfenster?
Latenzempfindlichkeit	Welche Transaktionen sind benutzerseitig und latenzkritisch?
Durchsatzanforderungen	Gibt es große Datenabfragen, -exporte, -importe oder Extraktionen, Transformations- und Ladeprozesse (ETL-Prozesse)?
Skalierungserwartungen	Benötigen die Arbeitsauslastung vorübergehende Brüche oder eine dauerhafte höhere Leistung?

Das Ziel ist nicht, die Zukunft perfekt vorherzusagen. Ziel ist es, blindes Entwerfen zu vermeiden.

Grundlegendes zu den drei Kernkonzepten der Speicherleistung

Azure Speicherleistungsplanung ergibt sich in der Regel aus drei verwandten, aber unterschiedlichen Konzepten: IOPS, Durchsatz und Latenz. Diese Faktoren sind entscheidend für die Anwendungsleistungsplanung.

IOPS

IOPS bedeutet Eingabe-/Ausgabevorgänge pro Sekunde. Sie misst, wie viele Lese- oder Schreibvorgänge die Datenbank pro Sekunde an den Speicher senden kann.

IOPS ist besonders wichtig für OLTP-Workloads. Diese Systeme führen häufig viele kleine, zufällige Lese- und Schreibvorgänge aus, z. B. Einfügungen, Aktualisierungen, Indexsuche, Punktlesevorgänge und kurze Transaktionen. Eine Transaktionsworkload mit Tausenden gleichzeitiger Benutzer benötigt möglicherweise hohe IOPS, auch wenn jeder einzelne Vorgang klein ist.

Typische IOPS-empfindliche Szenarien umfassen:

Verarbeitung von Großaufträgen
Benutzerprofilaktualisierungen
Bestandssysteme
Ereigniserfassung
Zahlungs- oder Abrechnungssysteme
Stark konkurrierende SaaS-Anwendungen

Durchsatz

Der Durchsatz, manchmal als Bandbreite bezeichnet, misst, wie viel Daten im Laufe der Zeit ausgelesen oder in den Speicher geschrieben werden können. Er wird in MB/s ausgedrückt.

Der Durchsatz ist wichtig, wenn Vorgänge große Datenmengen verschieben. Analytische Abfragen, Sicherungen, Wiederherstellungen, Batchaufträge, Indexbuilds, Tabellenscans und ETL-Workflows benötigen möglicherweise hohen Durchsatz, auch wenn sie nicht die höchsten IOPS erfordern.

Zu den gängigen Durchsatzsensitiven Szenarien gehören:

Berichtsabfragen über große Tabellen
Massenimporte oder Exporte
Scans im Data Warehouse-Stil
Sicherungs- und Wiederherstellungsvorgänge
Große Indexerstellungs- oder Neuerstellungsvorgänge
Batchverarbeitung

Latenz

Latenz ist die Zeit, die für die Ausführung einer einzelnen E/A-Anforderung benötigt wird. Geringe Latenz ist für benutzerorientierte Datenbankvorgänge unerlässlich, insbesondere wenn viele kleine Vorgänge in einer Transaktion verkettet werden.

Ein System kann hohe theoretische IOPS aufweisen, aber dennoch langsam wirken, wenn die Latenz hoch ist. Bei Postgres-Workloads kann sich die Speicherlatenz direkt auf Abfrageantwortzeiten, Transaktions-Commit-Verhalten, Prüfpunktverhalten und allgemeine Reaktionsfähigkeit der Anwendung auswirken.

Note

Premium SSD v1-Datenträger sind für einstellige Millisekundenlatenzen bei den meisten E/A-Vorgängen ausgelegt, und insbesondere kann das Festplattencaching die Leselatenz für Datenträgerkonfigurationen unter 4 TB weiter reduzieren. Premium SSD v2 und Ultra Disk bieten Submillisekundenlatenz.

IOPS, Durchsatz und Latenz müssen zusammen berücksichtigt werden

IOPS und Durchsatz sind verbunden. Eine Arbeitslast, die mehrere kleine 8-KiB-Vorgänge ausführt, kann hohe IOPS ohne hohen Durchsatz erzielen. Ein Workload, der große Multi-MB-Vorgänge ausgibt, kann hohen Durchsatz mit niedrigeren IOPS erzielen.

Eine einfache Möglichkeit, darüber nachzudenken:

IOPS x E/A-Größe = Durchsatz

Bei Postgres besteht die praktische Auswirkung darin, dass die Speicherplanung von Arbeitsauslastungen auf dem beobachteten oder geschätzten Arbeitsauslastungsverhalten basieren sollte, nicht allein auf der Datenbankgröße. Beispiel:

Ein OLTP-System mit hoher Parallelität benötigt möglicherweise mehr IOPS und geringere Latenz.
Ein Berichterstellungsintensives System benötigt möglicherweise mehr Durchsatz.
Ein Hybridsystem benötigt möglicherweise beides, insbesondere bei Spitzenzyklen.
Ein OLTP-System mit hoher Parallelität benötigt möglicherweise mehr IOPS und geringere Latenz.
Ein Berichterstellungsintensives System benötigt möglicherweise mehr Durchsatz.
Ein Hybridsystem benötigt möglicherweise beides, insbesondere bei Spitzenzyklen.

Ihre Bereitstellungsoptionen wirken sich direkt auf die Speicherleistung aus

Ein häufiger Fehler ist das Festlegen des Speichers für eine Zielleistungsnummer, ohne vollständig zu prüfen, ob Ihre ausgewählte Compute-SKU dieselben Leistungsstufen steuern kann.

Die Leistung des Azure Speichers berücksichtigt mehrere Aspekte. Zu diesen Details gehören:

Der Berechnungsfunktionssatz (maximale Compute-IOPS- und Durchsatzgrenzwerte).
Die Speichergenerierung (SSD v1, SSD v2, Ultra Disk).
Die Größe des Speicherlaufwerks (SSD v1-Datenträger unter 4.096 GB beinhalten Host-Caching, das IOPS-Spitzen über die festgelegten Standardbasislinien hinaus ermöglicht).
Die Speicher-IOPS-Kapazität.
Die Speicherdurchsatzkapazität.

Praktisch ausgedrückt: Ihre effektive Leistungsobergrenze ist Ihr niedrigster relevanter Grenzwert in der Kette.

Wenn die Speicherkonfiguration 80.000 IOPS bereitstellen kann, die Compute-SKU jedoch nur 20.000 IOPS steuern kann, liefert die Bereitstellung keine 80.000 IOPS. Wenn die VM-Generation dagegen hohe IOPS unterstützt, die ausgewählte Speicherebene jedoch eine niedrigere Begrenzung aufweist, wird die Speicherebene zum limitierenden Faktor.

Die Berechnungs- und Speicherplanung sollte zusammen erfolgen.

Premium SSD v1: starke Basisleistung mit wichtigem Zwischenspeicherungsverhalten

Premium SSD v1 ist eine häufige Wahl für produktionsbezogene Azure Postgres-Workloads, die vorhersehbare, bereitgestellte Leistung benötigen. Azure Postgres SSD v1-Speicher unterstützt bis zu 32 TB Speicherplatz, 20.000 IOPS und 900 MB/s Durchsatz.

Premium SSD v1 eignet sich gut für Workloads, die vom Host-Caching profitieren. Azure Postgres unterstützt Hostzwischenspeicherung für SSD v1-Datenträgergrößen weniger als 4.096 GB. Jeder Datenträger, der bis zu 4.095 GB bereitgestellt wurde, kann von Host-Caching profitieren. Sobald der Speicher auf 4.096 GB oder höher bereitgestellt ist, wird Host-Caching nicht unterstützt. Diese Grenze ist wichtig. Bei Premium-SSD v1-Bereitstellungen unter 4 TB kann die Zwischenspeicherung die Leseleistung verbessern und die Leselatenz verringern. Diese Zwischenspeicherung schafft eine hervorragende Kosten-zu-Leistungs-Effizienz für leseintensive oder gemischte Workloads, die unter den Zwischenspeicherungsschwellenwert passen.

Warum die Grenze von 4 TB wichtig ist

Wenn eine Premium SSD v1-Bereitstellung über den zwischenspeicher-unterstützten Bereich hinaus wächst, kann sich das Leistungsprofil ändern.

Lesevorgänge profitieren nicht mehr vom Hostcache.
Weitere Lesevorgänge stammen direkt vom zugrunde liegenden Datenträger.
Lesevorgänge zählen gegen die IOPS- und Durchsatzgrenzwerte von Festplatten.
Latenzempfindliche Lesearbeitslasten könnten ein unterschiedliches Verhalten zeigen.
Eine Konfiguration, die zuvor effizient war, benötigt möglicherweise mehr bereitgestellte IOPS, mehr Durchsatz, Computeskalierung, Abfrageoptimierung oder eine andere Speicheroption.

Das Überschreiten von 4 TB ist nicht schlecht, aber Sie müssen planen.

Wenn Sie erwarten, dass eine Datenbank mehr als 4 TB wachsen wird, sollten Sie den zukünftigen Zustand während des Architekturentwurfs berücksichtigen. Ein Entwurf, der bei 2 TB mit Zwischenspeicherung gut funktioniert, benötigt möglicherweise einen anderen Leistungsplan mit 5 TB ohne Zwischenspeicherung.

Burst hilft bei Spitzen, ersetzt aber keine nachhaltige Kapazität

Azure Postgres Premium SSD v1 Speicherzuweisungen unter 4 TB unterstützen Bursts von Host-Caching, was in bestimmten Szenarien wie:

Startaktivität
Kurze Batchaufträge
Datenverkehrsspitzen
Monatsendverarbeitung
Temporäre Arbeitsauslastungsspitzen

Obwohl das Bursten nützlich ist, sollten Sie es sorgfältig verwenden. Bursting kann temporäre Spitzen absorbieren, sollte jedoch nicht die Grundlage für eine dauerhafte Arbeitslast sein. Wenn die Workload häufig über dem Baseline-Niveau ausgeführt wird, ist es besser, eine höhere Leistungsstufe bereitzustellen, die Speicherleistungseinstellungen anzupassen, die Rechenleistung zu skalieren oder das Workload-Muster neu zu gestalten.

Eine gute Planungsfrage ist: Ist dies eine temporäre Spitze, oder ist dies die neue Normalität?

Vorübergehende Spitzen könnten gute Kandidaten zum Bursten sein. Bewältigen Sie anhaltende Nachfrage mit bewusster Kapazitätsplanung.

Premium SSD v2 entkoppelt Kapazität, IOPS und Durchsatz

Premium SSD v2 ändert das Planungsmodell durch Entkoppeln von Datenträgergröße, IOPS und Durchsatz. Azure Database for PostgreSQL Flexible Server Premium SSD v2 unterstützt:

Kapazität von 32 GB bis 64 TB.
Bis zu 80.000 IOPS.
Bis zu 1.200 MB/s Durchsatz.
Granulare Kapazitätsanpassungen in 1-GB-Schritten.
Flexible IOPS- und Durchsatzkonfiguration.
Niedrigere Latenz als Premium SSD v1.
Kein Host-Caching.

Diese Änderung ist eine große Veränderung. Mit Premium SSD v1 ist die Leistung enger mit der Datenträgergröße gekoppelt. Mit Premium SSD v2 können Sie die Leistung direkt im Hinblick auf die Arbeitsauslastung konfigurieren.

Eine datenbank mit Transaktionslast benötigt z. B. möglicherweise hohe IOPS, ohne eine große Speichermenge zu benötigen. Azure Postgres bietet grundlegende IOPS und Durchsatz ohne zusätzliche Kosten, wobei zusätzliche IOPS und Durchsatz für zusätzliche Gebühren zur Verfügung stehen. Premium SSD v2 bietet:

Datenträger mit bis zu 399 GB erhalten einen Basisplan von 3.000 IOPS und 125 MB/s.
Datenträger mit 400 GB oder höher erhalten einen Basisplan von 12.000 IOPS und 500 MB/s.
Datenträger können bis zu 80.000 IOPS erreichen, wenn sie mindestens 160 GB verfügbaren Speicherplatz haben.
Der Durchsatz kann bis zu 1.200 MB/s skalieren.

Premium SSD v2 ist oft attraktiv, wenn Sie eine präzisere Kontrolle über Kosten und Leistung benötigen. Anstatt die Speicherkapazität zu skalieren, um die Leistung zu entsperren, können Sie die Leistung absichtlicher bereitstellen.

Ultra Disk (Vorschau): die High-End-Azure Datenträgerleistungsklasse

Ultra Disk ist die Option der höchsten Leistung. Azure Ultra Disk bietet Leistungsniveaus bis zu:

400.000 IOPS
10.000 MB/s Durchsatz
Kapazität von 64 TB
Designziele für Submillisekunden-Latenz
Unabhängig konfigurierbare Kapazität, IOPS und Durchsatz

Ultra Disk Storage wurde entwickelt, um E/A-intensive Workloads für Datenbanken der obersten Ebene, SAP HANA und transaktionsintensive Systeme zu unterstützen. Dieses neue Speicherangebot bietet top-of-the-line Performance für Ihre unternehmenskritischen Workloads. Ihr Team muss jedoch einige wichtige Bereitstellungsfunktionen, regionale Verfügbarkeitseinschränkungen und Konfigurationsoptionen bei der Planung einer Bereitstellung berücksichtigen:

Das automatische Speicherwachstum wird für Server mit Ultra Disk nicht unterstützt.
Die Datenverschlüsselung mit vom Kunden verwalteten Schlüsseln wird für Server mit Ultra Disk nicht unterstützt.
Ultra Disks unterstützen keine Datenträgerzwischenspeicherung

Es ist wichtig, die Ultra Disk-Funktionen als Teil der umfassenderen Azure Speicherleistungslandschaft zu verstehen. Sie müssen jedoch die Dienstverfügbarkeit und -unterstützung für Ihre spezifische Azure Postgres-Workload überprüfen. Wenden Sie sich an Ihren Microsoft Vertreter, ob die Ultra Disk Preview für Ihre Azure Postgres-Bereitstellung verfügbar ist.

Die praktische Erkenntnis: Ultra Disk stellt das obere Ende der Azure Speicherleistung dar, aber Ihr End-to-End Postgres-Design muss vergleichbar unterstützte Kombinationen für die ausgewählte Compute-SKU, Region und Release-Ebene enthalten.

Vm-Generation ist wichtig: V5 und V6 Compute Storage Ceilings unterscheiden sich

Die Berechnungsgenerierung kann sich wesentlich auf die Speicherleistung auswirken. Wenn Sie das höchste Ende der Azure Speicherleistung erkunden, vermeiden Sie das Missverständnis, dass "großer Compute" automatisch "maximaler Speicher" bedeutet. Sie müssen die ausgewählte Compute-SKU auf die beabsichtigte Speicherebene überprüfen. Lassen Sie uns diesen Punkt veranschaulichen, indem wir zwei gleich große Rechengenerationen, Ddsv5 und Ddsv6, in Betracht ziehen:

Die Ddsv5-Serie unterstützt Storage Premium (mit Zwischenspeicherung), Premium SSD v2 und Ultra Disk auf VM-Familienebene. Die aggregierten Remotespeichergrenzwerte des virtuellen Computers definieren jedoch weiterhin die Obergrenze für das, was diese VM steuern kann. Ddsv5-Serie bietet Speicherleistung von bis zu 80.000 IOPS und 2.600 MB/s.

Die Ddsv6-Serie bietet einen höheren Speicherumschlag von bis zu 400.000 IOPS und 12.000 MB/s. V6-Series Compute bietet auch eine höhere Skalierbarkeit als frühere Generationen, mit bis zu 192 vCPU und 768-GiB Speicher.

Diese generationale Veränderung ist für hochleistungsfähiges Postgres-Design wichtig. Wenn Ihre Zielarchitektur eine hohe Speicherleistung erfordert, kann die Auswahl einer Berechnungsgenerierung mit einer niedrigeren Aggregatspeichergrenze verhindern, dass die Bereitstellung die vollständige Speicherfunktion verwendet.

Beispiel: Warum die End-to-End-Ausrichtung wichtig ist

Betrachten Sie eine PostgreSQL-Workload mit einem zielgerichteten Speicherziel von 400.000 IOPS.

Auf der Datenträgerebene unterstützt Azure Ultra Disk bis zu 400.000 IOPS pro Datenträger. Premium SSD v2 unterstützt bis zu 80.000 IOPS pro Datenträger, und höhere Aggregatdesigns erfordern je nach Servicesupport möglicherweise mehrere Datenträger oder eine Abstraktion auf Plattformebene.

Die Speicherfunktion allein reicht jedoch nicht aus.

Eine V5-Serie-Konfiguration verfügt möglicherweise über eine Speichergrenze, die niedriger als das Ziel ist. Wie bereits erwähnt, unterstützen SKUs der V5-Serie bis zu 260.000 IOPS für Premium SSD-Fernspeicherdurchsatz. In diesem Fall wird die Wahl der Rechenschicht der V5-Serie für dieses Ziel zum limitierenden Faktor, bevor ein IOPS-Ziel von 400.000 erreicht wird.

Im Gegensatz dazu bietet die Dokumentation der Ddsv6-Serie bis zu 400.000 IOPS und 12.000 MB/s. Dies macht V6-Serie und neuere Generationen strategisch wichtig für Designs, die Compute und Speicher um die höchsten Speicherleistungsklassen ausrichten müssen.

Die Lektion ist einfach: Maximale Datenbankleistung ist eine End-to-End-Eigenschaft, keine speichergeschützte Eigenschaft.

Planen Sie für Geschäftszyklen, nicht nur den Normalbetrieb.

Viele Systeme verfügen nicht über ein einzelnes Leistungsprofil. Sie haben mehrere:


Normaler Wochentagsverkehr.	Spitzenzeiten.
Monats- oder Quartalsendverarbeitung.	Urlaub oder saisonale Nachfrage.
Produktstartereignisse.	Berichterstellungsfenster.
Wartungsfenster.	Azure Batch Aufnahmeperioden.
Sicherungs- und Wiederherstellungsszenarien.	Notfallwiederherstellungsereignisse.

Eine Datenbank, die für die durchschnittliche Auslastung dimensioniert ist, könnte in den entscheidenden Momenten Probleme haben. Umgekehrt kann eine Datenbank, die konstant für einen monatlichen Spitzenwert ausgelegt ist, unnötig teuer sein.

Die Flexibilität Azure ermöglicht Es Teams, differenziertere Entscheidungen zu treffen. Beispiel:

Verwenden Sie Premium SSD v2, um IOPS und Durchsatz anzupassen, da sich die Workload weiterentwickeln muss.
Verwenden Sie lesereplikate, um leseintensive Workloads ggf. auslagern zu können.
Skalierungsberechnung für bekannte Spitzenzeiten.
Optimieren Sie Abfragen, Indizes und Verbindungspooling vor der Skalierung der Infrastruktur.
Verwenden Sie Observability, um festzustellen, ob der Engpass bei der CPU, dem Arbeitsspeicher, den IOPS, dem Durchsatz, bei Sperrkonflikten, Verbindungsdruck oder dem Abfragedesign liegt.

Die beste Bereitstellung ist nicht immer die größte Bereitstellung. Es ist das Design, das der Workload entspricht und sicher weiterentwickelt werden kann.

Observability ist Teil der Architektur

Die Leistungsplanung sollte bei der Bereitstellung nicht beendet werden. Die Workloads von Postgres ändern sich im Laufe der Zeit. Daten wachsen, Abfragemuster wechseln, neue Funktionen werden eingeführt, Kundentraffic ändert sich, und operative Aufgaben häufen sich an.

Überwachungsbereich	Zu überprüfende Signale
Compute	CPU-Auslastung und Arbeitsspeicherdruck.
Verbindungen	Aktive Verbindungen, Leerlaufverbindungen und Verbindungspoolverhalten.
Abfragen	Abfragedauer, Abfrageplanänderungen und Indexverwendung.
Storage	Speicherprozentsatz, Leselatenz, Schreiblatenz, IOPS-Auslastung und Durchsatzstatistiken.
Maintenance	Tabellenblähungen, Indexblähungen, WAL-Merkmale, Sicherungszeitpläne und Wartungszeitpläne.
Replikation	Replikatverzögerung, sofern relevant.

Azure Database for PostgreSQL-Dokumentation hebt die Überwachung des E/A-Verbrauchs durch Metriken des Azure-Portals oder der Azure CLI hervor, einschließlich Speichergrenzwert, Speicherprozentsatz, verwendeter Speicher und E/A-Prozentsatz.

Diese Metriken helfen bei der Beantwortung der wichtigsten betrieblichen Frage: Welche Ebene schränkt die Leistung tatsächlich ein?

Ohne Beobachtbarkeit könnten Teams die falsche Sache skalieren. Ein Abfrageplanproblem könnte wie ein Speicherproblem aussehen. Verbindungsstürme können wie CPU-Druck aussehen. Ein fehlender Index könnte wie unzureichende IOPS aussehen. Ein regionales Clientplatzierungsproblem könnte wie die Datenbanklatenz aussehen.

Mithilfe der Überwachung können Teams gezielte Änderungen vornehmen, anstatt teure Vermutungen anzustellen.

Prüfliste für die praktische Planung

Bevor Sie die Produktionskonfiguration Azure Database for PostgreSQL auswählen, erfassen Sie die folgenden Informationen.

Category	Planungseingaben
Workload-Typ	OLTP, OLAP, Hybrid, Berichterstellung, Batch und Datenaufnahme.
Mischung aus Lese-/Schreib-Operationen	Prozentsatz von Lesevorgängen, Schreibvorgängen, zufälligen E/A und sequentiellen E/A.
Aktuelle Leistung	Basis-IOPS, Durchsatz, Latenz, CPU, Arbeitsspeicher und Verbindungen.
Spitzenleistung	90. Perzentil- und 99. Perzentilauslastungsanforderungen.
Datengröße	Aktuelle Größe, erwartetes Wachstum, Große Objektnutzung und Indexwachstum.
Wachstumsrate	Monats- und Jahres-über-Jahr-Speicherprojektionen.
Konkurrenz	Aktive Sitzungen, Leerlaufsitzungen und Verbindungspoolverhalten.
Geschäftszyklen	Tägliche, wöchentliche, monatliche, saisonale und launchgetriebene Spitzen.
Verfügbarkeit	Hohe Verfügbarkeit, Replikate, Notfallwiederherstellung, Sicherung, Wiederherstellung, Wiederherstellungspunktziel (RPO) und Wiederherstellungszeitziel (RTO).
Speicherauswahl	Premium SSD, Premium SSD v2, unterstützte Regionen und unterstützte Features.
Auswirkungen auf das Zwischenspeichern	Gilt die Zwischenspeicherung von Premium SSD v1-Hosts auch unter 4 TB?
Berechnungsgenerierung	Gibt an, ob die ausgewählte SKU die erforderlichen IOPS und den erforderlichen Durchsatz steuern kann.
Skalierungsmodell	Manuelle Skalierung, geplante Skalierung, Leistungsanpassung und Replikate.
Beobachtbarkeit	Metriken, Warnungen, Abfrageerkenntnisse und Workload-Überprüfungsprozess.

Empfohlene Designprinzipien

Verwenden Sie die folgenden Prinzipien, wenn Sie Azure Postgres-Bereitstellungen für die betriebliche Leistung planen.

Größe an die Arbeitslastform anpassen und nicht nur an die Datengröße.
Eine 500-GB-Datenbank kann mehr IOPS als eine 5-TB-Datenbank benötigen, wenn sie hochgradig transaktions- und latenzempfindlich ist. Größe ist wichtig, aber Arbeitsauslastungsverhalten ist wichtiger.
Überprüfen Sie die Berechnung und speicherung zusammen.
Wählen Sie den Speicher nicht nur basierend auf Datenträgergrenzwerten aus. Vergewissern Sie sich, dass die ausgewählte Compute-SKU die erforderlichen IOPS und den erforderlichen Durchsatz steuern kann.
Behandeln Sie die 4-TB Premium SSD-Cachegrenze als Designmeilenstein.
Premium-SSD-Bereitstellungen unter 4 TB können von der Hostzwischenspeicherung profitieren. Bei 4.096 GB und höher wird der Host-Cache nicht unterstützt. Wenn das Wachstum diesen Schwellenwert überschreiten wird, planen Sie das zukünftige Leistungsmodell frühzeitig.
Berücksichtigen Sie Premium SSD v2 für flexible Leistungsoptimierungen.
Premium SSD v2 ermöglicht eine genauere Steuerung von Kapazität, IOPS und Durchsatz. Es kann eine geeignete Lösung sein, wenn die Leistungsanforderungen nicht genau auf feste Datenträgergrößen abgestimmt sind.
Verwenden Sie Bursting für Bursts, nicht für anhaltende Nachfrage.
Bursting kann bei kurzlebigen Spitzen helfen, aber häufige oder anhaltendes Bursting bedeutet in der Regel, dass die Basiskonfiguration überarbeitet werden sollte.
Erzeugung an Zielsetzungen anpassen.
Für High-End-Leistungsziele können neuere Computegenerationen wie die v6-Serie höhere aggregierte Grenzwerte für Remotespeicher als frühere Generationen mit allgemeinem Zweck verfügbar machen. Wenn das Ziel eine Architektur der 400.000-IOPS-Klasse ist, wählen Sie die Berechnungsgenerierung entsprechend aus.
Messen Sie vor und nach Änderungen.
Die Skalierung ist in der Cloud einfacher, aber die Messung macht die Skalierung effektiv. Erfassen Sie Baseline-, Höchst- und Nachänderungsmetriken, sodass Leistungsentscheidungen nachweisbasiert sind.

Echte Benchmarks: Vergleich von Speicherkonfigurationen unter Last

Die in diesem Artikel beschriebenen Prinzipien sind nicht theoretisch. Um zu veranschaulichen, wie Compute, Speicher und Workload in der Praxis interagieren, fasst dieser Abschnitt Benchmarks pgbench zusammen, die Speicherkonfigurationen und Computeebenen unter kontrollierten, gemessenen Bedingungen vergleichen.

Benchmark-Einrichtung und -Methodik

Die Benchmarks verwenden pgbench, das Standardmäßige PostgreSQL-Benchmark-Tool, um eine Transaktionsworkload in fünf verschiedenen Speicher- und Computekonfigurationen zu simulieren. Der Test beginnt mit 500 gleichzeitigen Verbindungen und führt nach einem anfänglichen Zeitraum bis zu 750 gleichzeitige Verbindungen durch, wobei diese erhöhte Verbindungslast für den Rest des Testfensters beibehalten wird. Dieses Ramp-up-Muster simuliert, wie viele echte Anwendungen die Last im Laufe der Zeit erhöhen, während der Datenverkehr wächst, und misst, wie die Datenbank sowohl auf die anfängliche Spitzen- als auch auf die anhaltende hohe Parallelität reagiert.

Alle Benchmarks werden auf Azure Database for PostgreSQL Flexible Server in derselben Region innerhalb derselben Verfügbarkeitszone ausgeführt, wobei dasselbe Testdatenbank- und Workloadprofil verwendet wird. Indem Sie Speicher isolieren und als Variablen berechnen, stellen Sie sicher, dass Leistungsunterschiede die tatsächlichen Plattformfunktionen anstelle von Netzwerk-, Anwendungs- oder Workloadvariationen widerspiegeln.

Konfigurationsdetails

Testen Sie fünf verschiedene Konfigurationen, die sowohl die Speicherebene als auch die Computegröße variieren, um wichtige Planungskonzepte zu veranschaulichen.

Konfiguration	Berechnen der SKU	V-Kerne	Gedächtnis	Max. Compute-IOPS	Speichertypus	Kapazität	IOPS	Durchsatz
Config 1	Standard_D16ds_v5	16	64 GB	25.600 (40.000 Burst)	Premium SSD (P50)	4.095GB	7,500	250 MB/s
Konfiguration 2	Standard_D16ds_v5	16	64 GB	25.600 (40.000 Burst)	Premium SSD (P50)	4.096 GB	7,500	250 MB/s
Konfiguration 3	Standard_D16ds_v5	16	64 GB	25.600 (40.000 Burst)	Premium SSD (P80)	32 TB	20,000	900 MB/s
Konfiguration 4	Standard_D16ds_v5	16	64 GB	25.600 (40.000 Burstrate)	Premium-SSD v2	4.095GB	40,000	1.200 MB/s
Konfiguration 5	Standard_D32ds_v5	32	128 GB	51.200	Premium-SSD v2	4.095GB	60.000	1.200 MB/s

Wichtige Beobachtungen aus dem Konfigurationsentwurf:

Config 1 vs. Config 2: Diese Konfigurationen unterscheiden sich nur in der Speichergröße, 4.095 GB im Vergleich zu 4.096 GB. Dieser Vergleich testet die Host-Caching-Grenze für Premium-SSD v1-Disk.
Config 2 vs. Config 3: Beide Konfigurationen verwenden SSD v1, aber Config 3 skaliert auf 32 TB Kapazität, um höhere IOPS und Durchsatz zu entsperren.
Config 3 vs. Config 4: Beide Konfigurationen verwenden die gleiche Rechenleistung, aber Config 4 veranschaulicht die flexiblen IOPS und den Durchsatz der Premium SSD v2 unabhängig von der Kapazität.
Config 4 vs. Config 5: Bei Config 5 wird die Compute-SKU verdoppelt, um zu veranschaulichen, wie höherstufige Rechenleistung mehr Speicherleistungskapazität freischaltet.

Leistungsergebnisse

Konfiguration 1: 4.095 GB Premium SSD v1 mit Host Caching

Konfiguration 1 verwendet die 4.095-GB-Größe der Premium SSD v1, die von der Host-Caching-Funktionalität dieser Serie profitiert. Während der Workload hat diese Konfiguration Folgendes aufrechterhalten:

Max IOPS: 24.773, begrenzt durch 7.500 bereitgestellte IOPS auf Premium SSD v1, wobei das Caching die effektive Leistung erhöht.
Max. Lese-IOPS: 21.330 und profitiert vom Hostcache für leseintensive Vorgänge.
Max. Schreib-IOPS: 7.610.

Die Hostzwischenspeicherung bietet Leseverstärkung, sodass effektive IOPS die bereitgestellten IOPS-Grenzwerte von 7.500 der Datenträger und die Grenzen der Rechenleistung vorübergehend überschreiten.

Konfiguration 2: 4.096-GB Premium SSD v1 ohne Hostzwischenspeicherung

Konfiguration 2 verwendet die 4.096-GB-Größe der Premium SSD v1, überschreitet die Caching-Grenze und verliert die Vorteile des Host-Cachings. Die Auswirkungen sind sichtbar:

Max. IOPS: Niedrigere effektive IOPS im Vergleich zu Config 1 aufgrund des Verlusts der Zwischenspeicherung.
Max. Lese-IOPS: Deutlich reduziert ohne Hostcache.
Max. Schreib-IOPS: 7.610, unverändert.

Diese Konfiguration veranschaulicht die praktische Bedeutung der Zwischenspeicherungsgrenze von 4 TB. Das Überschreiten von 4.095 GB auf 4.096 GB ändert das Leistungsprofil, indem zwischengespeicherte Lesevorgänge entfernt werden. Planen Sie für wachsende Datenbanken, die diesen Schwellenwert erreichen, voraus.

Konfiguration 3: 32-TB Premium SSD v1 mit höheren IOPS

Konfiguration 3 adressiert Premium SSD v1 obere IOPS- und Durchsatzgrenzwerte durch Skalierung auf 32 TB Kapazität. Diese Konfiguration wurde erfolgreich umgesetzt:

Max. IOPS: 20.000.
Max. Lese-IOPS: Ungefähr 12.000.
Max. Schreib-IOPS: Ungefähr 5.000.

Das Erhöhen der zugrunde liegenden Premium SSD v1-Speicherkapazität erhöht IOPS und Durchsatz. Sie können weiterhin die oberen Grenzwerte des Rechenspeicherbereichs für intensive Workloads erreichen.

Konfiguration 4: Premium SSD v2 mit 40.000 IOPS

Konfiguration 4 veranschaulicht die flexible Leistungskonfiguration der Premium-SSD v2, Bereitstellung von 40.000 IOPS und einem Durchsatz von 1.200 MB/s bei einer Kapazität von 4.095 GB.

Max IOPS: Höhere effektive Auslastung aufgrund der Premium SSD v2-Latenz- und Durchsatzmöglichkeiten.
Max. Lese-IOPS: Verbesserte Leistung im Vergleich zu Premium SSD v1-Konfigurationen.
Max. Schreib-IOPS: Höhere dauerhafte Schreibkapazität.

Premium SSD v2 ermöglicht die Bereitstellung hoher IOPS, ohne dass eine große Speicherkapazität erforderlich ist, wodurch sie für transaktionsintensive Workloads effizient ist.

Konfiguration 5: Premium SSD v2 mit 60.000 IOPS auf D32ds_v5 Compute

Konfiguration 5 skaliert die Speicherleistung auf 60.000 IOPS und berechnet mit Standard_D32ds_v5 und 32 vCores. Diese Konfiguration veranschaulicht das Ende-zu-Ende-Ausrichtungsprinzip:

Max. IOPS: Deutlich höher als alle vorherigen Konfigurationen.
Max. Lese-IOPS: Starke Verbesserung durch zusätzliche Rechenkapazität.
Max. Schreib-IOPS: Anhaltende höhere Schreibkapazität.

Durch die Ausrichtung von Compute und Speicher auf höhere Leistungsstufen erreicht diese Konfiguration den besten Durchsatz und den niedrigsten CPU-Druck. Die höhere Speichergrenze von D32ds_v5 ermöglicht es, den 60.000-IOPS Premium SSD v2-Datenträger vollständiger zu verwenden.

Lehren aus den Benchmarks

Diese fünf Konfigurationen veranschaulichen die wichtigsten Prinzipien aus diesem Artikel:

Die 4-TB-Zwischenspeicherungsgrenze ist wichtig.
Config 1 vs. Config 2 zeigt, dass die Zwischenspeicherung von Hosten eine messbare Leseleistungsverstärkung unter 4 TB bietet, während der Übergang zu 4.096 GB diesen Vorteil entfernt.
Kapazität ist keine Leistung.
Config 3 hat 32 TB bereitgestellt, aber nicht die höchsten IOPS bereitgestellt. Die Speicherkapazität allein bestimmt nicht den Transaktionsdurchsatz.
Premium SSD v2 bietet flexible Leistungsoptimierung.
Die Konfiguration 4 demonstrierte hohe IOPS bei bescheidener Kapazität und bestätigte das entkoppelte Modell, das Premium SSD v2 ermöglicht.
Rechenleistung und Speicher müssen ausgerichtet werden.
Config five zeigt, dass um die Speicherleistung zu maximieren, ausreichende Rechenkapazität erforderlich ist. Die höhere Speichergrenze von D32ds_v5 war erforderlich, um die 60.000-IOPS-Bereitstellung vollständig zu nutzen.

Die Benchmarkergebnisse überprüfen das Kernprinzip: Maximale Leistung ist eine End-to-End-Eigenschaft. Kein einzelner Layer, z. B. Speicher, Compute oder Netzwerk, bestimmt das Ergebnis. Erfolg erfordert eine absichtliche Ausrichtung über alle Ebenen, gemessene Validierung und kontinuierliche Beobachtung, während Workloads sich entwickeln.

Conclusion

Azure Postgres bietet eine leistungsstarke und flexible Plattform zum Erstellen moderner, in der Cloud gehosteter Datenbanklösungen. Das Engineering in Azure Compute, Storage, Networking, High Availability, Replication, Security und Observability ermöglicht einige der leistungsstärksten und stabilsten Postgres-Architekturen.

Die maximale Leistung geschieht nicht versehentlich.

Die maximale betriebliche Leistung erfordert ein Verständnis der Anwendung, der Clients, der Workload, des Datenwachstumsprofils, des Lese-/Schreibmixes und der Geschäftszyklen, die die Nachfrage gestalten. Außerdem muss sowohl Die Berechnungs- als auch die Speicherauswahl so ausgerichtet werden, dass IOPS-, Durchsatz- und Latenzziele end-to-End erreicht werden.

Premium SSD v1 kann eine starke vorhersagbare Leistung bieten, insbesondere, wenn die Hostzwischenspeicherung auf Daten unter der Grenze von 4 TB angewendet wird. Premium SSD v2 bietet eine flexiblere Leistungskonfiguration durch Entkoppeln von Kapazität, IOPS und Durchsatz. Ultra Disk ist die höchste Azure verwaltete Datenträger-Leistungsklasse, während neuere Rechnergenerationen wesentlich höhere maximale Remotespeicherkapazitäten für High-End-Architekturen bieten.

Die besten Azure Postgres-Bereitstellungen kombinieren Plattformfunktionen mit bewusster Planung, kontinuierlicher Überwachung und klarem betrieblichem Besitz. Mit den richtigen Anforderungen und der richtigen Architektur können Teams erstklassige Postgres-Erfahrungen bereitstellen, die Spitzenleistung bieten.

Feedback

War diese Seite hilfreich?

Last updated on 2026-05-08