Migration von PostgreSQL zu Aurora DSQL - Amazon Aurora DSQL
Framework- und ORM-KompatibilitätAllgemeine MigrationsmusterArchitektonische Unterschiede verstehenErwägungen zur KompatibilitätBenötigen Sie Hilfe bei der Migration?

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migration von PostgreSQL zu Aurora DSQL

Aurora DSQL ist so konzipiert, dass es PostgreSQL-kompatibel ist und relationale Kernfunktionen wie ACID-Transaktionen, Sekundärindizes, Joins und Standard-DML-Operationen unterstützt. Die meisten vorhandenen PostgreSQL-Anwendungen können mit minimalen Änderungen zu Aurora DSQL migriert werden.

Dieser Abschnitt enthält praktische Anleitungen für die Migration Ihrer Anwendung zu Aurora DSQL, einschließlich Framework-Kompatibilität, Migrationsmustern und architektonischen Überlegungen.

Framework- und ORM-Kompatibilität

Aurora DSQL verwendet das standardmäßige PostgreSQL-Wire-Protokoll und gewährleistet so die Kompatibilität mit PostgreSQL-Treibern und Frameworks. Die beliebtesten ORMs arbeiten mit Aurora DSQL mit minimalen oder keinen Änderungen. Referenzimplementierungen und verfügbare ORM-Integrationen finden Aurora DSQL-Adapter und -Dialekte Sie unter.

Allgemeine Migrationsmuster

Bei der Migration von PostgreSQL zu Aurora DSQL funktionieren einige Funktionen anders oder haben eine alternative Syntax. Dieser Abschnitt enthält Anleitungen zu gängigen Migrationsszenarien.

Alternativen zum DDL-Betrieb

Aurora DSQL bietet moderne Alternativen zu herkömmlichen PostgreSQL-DDL-Operationen:

Erstellung von Indizes

Verwenden Sie CREATE INDEX ASYNC statt CREATE INDEX für die blockierungsfreie Indexerstellung.

Vorteil: Indexerstellung für große Tabellen ohne Ausfallzeiten.

Entfernung von Daten

Verwenden Sie DELETE FROM table_name stattTRUNCATE.

Alternative: Verwenden Sie zur vollständigen Neuerstellung der Tabelle DROP TABLE gefolgt vonCREATE TABLE.

Konfiguration des Systems

Aurora DSQL wird vollständig verwaltet, sodass die Konfiguration automatisch auf der Grundlage von Workload-Mustern erfolgt. Verwenden Sie die AWS Managementkonsole oder API, um die Cluster-Einstellungen zu verwalten.

Vorteil: Datenbankoptimierung oder Parameterverwaltung sind nicht erforderlich.

Schema-Entwurfsmuster

Passen Sie diese gängigen PostgreSQL-Muster an, um die Aurora DSQL-Kompatibilität zu gewährleisten:

Referenzielle Integritätsmuster

Aurora DSQL unterstützt Tabellenbeziehungen und JOIN Operationen. Implementieren Sie für referenzielle Integrität die Validierung in Ihrer Anwendungsebene. Dieses Design entspricht modernen Mustern verteilter Datenbanken, bei denen die Validierung auf Anwendungsebene mehr Flexibilität bietet und Leistungsengpässe durch kaskadierende Operationen vermeidet.

Muster: Implementieren Sie referenzielle Integritätsprüfungen in Ihrer Anwendungsebene unter Verwendung einheitlicher Namenskonventionen, Validierungslogik und Transaktionsgrenzen. Viele anspruchsvolle Anwendungen bevorzugen diesen Ansatz, um die Fehlerbehandlung und Leistung besser kontrollieren zu können.

Temporäre Datenverarbeitung

Verwenden Sie CTEs Unterabfragen oder reguläre Tabellen mit Bereinigungslogik anstelle von temporären Tabellen.

Alternative: Erstellen Sie Tabellen mit sitzungsspezifischen Namen und bereinigen Sie sie in Ihrer Anwendung.

Architektonische Unterschiede verstehen

Die verteilte, serverlose Architektur von Aurora DSQL unterscheidet sich bewusst in mehreren Bereichen von herkömmlichem PostgreSQL. Diese Unterschiede ermöglichen die wichtigsten Vorteile von Aurora DSQL in Bezug auf Einfachheit und Skalierbarkeit.

Vereinfachtes Datenbankmodell

Eine Datenbank pro Cluster

Aurora DSQL bietet eine integrierte Datenbank, die postgres pro Cluster benannt ist.

Migrationstipp: Wenn Ihre Anwendung mehrere Datenbanken verwendet, erstellen Sie separate Aurora DSQL-Cluster für die logische Trennung oder verwenden Sie Schemas innerhalb eines einzelnen Clusters.

Keine temporären Tabellen

Für die Verarbeitung temporärer Daten SOLLTEN Sie allgemeine Tabellenausdrücke (CTEs) und Unterabfragen verwenden, die flexible Alternativen für komplexe Abfragen bieten.

Alternative: Verwenden Sie CTEs WITH Klauseln für temporäre Ergebnismengen oder reguläre Tabellen mit eindeutiger Benennung für sitzungsspezifische Daten.

Automatische Speicherverwaltung

Aurora DSQL macht Tablespaces und manuelles Speichermanagement überflüssig. Der Speicher wird automatisch auf der Grundlage Ihrer Datenmuster skaliert und optimiert.

Vorteil: Sie müssen den Festplattenspeicher nicht überwachen, die Speicherzuweisung planen oder Tablespace-Konfigurationen verwalten.

Moderne Anwendungsmuster

Aurora DSQL fördert moderne Anwendungsentwicklungsmuster, die die Wartbarkeit und Leistung verbessern:

Logik auf Anwendungsebene statt Datenbank-Trigger

Implementieren Sie für triggerähnliche Funktionen eine ereignisgesteuerte Logik in Ihrer Anwendungsebene.

Migrationsstrategie: Verschieben Sie die Triggerlogik in den Anwendungscode, verwenden Sie ereignisgesteuerte Architekturen mit AWS Diensten wie oder implementieren Sie Prüfpfade mithilfe der EventBridge Anwendungsprotokollierung.

SQL-Funktionen für die Datenverarbeitung

Aurora DSQL unterstützt SQL-basierte Funktionen, aber keine prozeduralen Sprachen wie PL/pgSQL.

Alternative: Verwenden Sie SQL-Funktionen für Datentransformationen oder verschieben Sie komplexe Logik auf Ihre Anwendungsebene oder AWS Lambda-Funktionen.

Optimistische Parallelitätssteuerung statt pessimistischer Sperren

Aurora DSQL verwendet Optimistic Concurrency Control (OCC), einen Ansatz ohne Sperren, der sich von herkömmlichen Datenbanksperrmechanismen unterscheidet. Anstatt Sperren zu erwerben, die andere Transaktionen blockieren, ermöglicht Aurora DSQL den Fortgang von Transaktionen ohne Blockierung und erkennt Konflikte beim Festschreiben. Dadurch werden Deadlocks vermieden und langsame Transaktionen daran gehindert, andere Operationen zu blockieren.

Hauptunterschied: Wenn Konflikte auftreten, gibt Aurora DSQL einen Serialisierungsfehler zurück, anstatt Transaktionen auf Sperren warten zu lassen. Dies erfordert, dass Anwendungen eine Wiederholungslogik implementieren, die der Behandlung von Sperrzeitüberschreitungen in herkömmlichen Datenbanken ähnelt. Konflikte werden jedoch sofort gelöst, anstatt zu blockierenden Wartezeiten zu führen.

Entwurfsmuster: Implementieren Sie idempotente Transaktionslogik mit Wiederholungsmechanismen. Entwerfen Sie Schemas, um Konflikte zu minimieren, indem Sie zufällige Primärschlüssel verwenden und Updates über Ihren gesamten Schlüsselbereich verteilen. Details hierzu finden Sie unter Parallelitätssteuerung in Aurora DSQL.

Beziehungen und referenzielle Integrität

Aurora DSQL unterstützt Fremdschlüsselbeziehungen zwischen Tabellen, einschließlich JOIN Operationen. Um die referenzielle Integrität zu gewährleisten, implementieren Sie die Validierung in Ihrer Anwendungsebene. Die Durchsetzung der referenziellen Integrität kann zwar nützlich sein, aber kaskadierende Operationen (wie das Kaskadieren von Löschungen) können zu unerwarteten Leistungseinbußen führen. Beispielsweise wird das Löschen einer Bestellung mit 1.000 Einzelposten zu einer Transaktion mit 1.001 Zeilen. Viele Kunden vermeiden aus diesem Grund Beschränkungen durch Fremdschlüssel.

Entwurfsmuster: Implementieren Sie referenzielle Integritätsprüfungen in Ihrer Anwendungsebene, verwenden Sie eventuelle Konsistenzmuster oder nutzen Sie AWS Dienste zur Datenvalidierung.

Operative Vereinfachungen

Aurora DSQL macht viele traditionelle Datenbankwartungsaufgaben überflüssig und reduziert so den betrieblichen Aufwand:

Keine manuelle Wartung erforderlich

Aurora DSQL verwaltet automatisch die Speicheroptimierung, die Erfassung von Statistiken und die Leistungsoptimierung. Herkömmliche Wartungsbefehle wie VACUUM werden vom System verarbeitet.

Vorteil: Eliminiert die Notwendigkeit von Datenbankwartungsfenstern, Vakuumplanung und Systemparameteroptimierung.

Automatische Partitionierung und Skalierung

Aurora DSQL partitioniert und verteilt Ihre Daten automatisch auf der Grundlage von Zugriffsmustern. Verwenden UUIDs oder von der Anwendung für eine optimale Verteilung generieren IDs .

Migrationstipp: Entfernen Sie die manuelle Partitionierungslogik und lassen Sie Aurora DSQL die Datenverteilung übernehmen. Verwenden UUIDs oder von der Anwendung für eine optimale Verteilung generieren IDs . Wenn für Ihre Anwendung sequenzielle Identifikatoren erforderlich sind, finden Sie weitere Informationen unter. Sequenzen und Identitätsspalten

Überlegungen zur PostgreSQL-Kompatibilität mit Aurora DSQL

Aurora DSQL unterscheidet sich von der Funktionsunterstützung von selbstverwaltetem PostgreSQL, was die verteilte Architektur, den serverlosen Betrieb und die automatische Skalierung ermöglicht. Die meisten Anwendungen funktionieren innerhalb dieser Unterschiede ohne Änderungen.

Allgemeine Überlegungen finden Sie unter Überlegungen zur Arbeit mit Amazon Aurora DSQL. Kontingente und Limits finden Sie unter Cluster-Kontingente und Datenbanklimits in Amazon Aurora DSQL.

  • Aurora DSQL verwendet eine einzige integrierte Datenbank, die postgres pro Cluster benannt ist. Erstellen Sie für die logische Trennung separate Aurora DSQL-Cluster oder verwenden Sie Schemas innerhalb eines einzelnen Clusters.

  • Die postgres Datenbank verwendet die UTF-8-Zeichenkodierung, die eine breite internationale Zeichenunterstützung bietet.

  • Die Datenbank verwendet ausschließlich C-Sortierung.

  • Aurora DSQL verwendet UTC als Systemzeitzone. Postgres speichert alle Zeitzonendaten und Uhrzeiten intern in UTC. Sie können den TimeZone Konfigurationsparameter so einstellen, dass er konvertiert, wie er dem Client angezeigt wird, und er als Standard für die Client-Eingabe dient, die der Server für die interne Konvertierung in UTC verwendet.

  • Die Transaktionsisolationsebene ist bei PostgreSQL auf Repeatable Read festgelegt.

  • Transaktionen haben die folgenden Einschränkungen:

    • DDL- und DML-Operationen erfordern separate Transaktionen

    • Eine Transaktion kann nur 1 DDL-Anweisung enthalten

    • Eine Transaktion kann unabhängig von der Anzahl der Sekundärindizes bis zu 3 000 Zeilen ändern

    • Die Obergrenze von 3 000 Zeilen gilt für alle DML-Anweisungen (INSERT, UPDATE, DELETE)

  • Das Timeout für Datenbankverbindungen liegt bei 1 Stunde.

  • Aurora DSQL verwaltet Berechtigungen über Zuschüsse auf Schemaebene. Admin-Benutzer erstellen Schemas mithilfe von CREATE SCHEMA und gewähren Zugriff mithilfe von. GRANT USAGE ON SCHEMA Admin-Benutzer verwalten Objekte im öffentlichen Schema, während Benutzer ohne Administratorrechte Objekte in von Benutzern erstellten Schemas erstellen, um klare Eigentumsgrenzen zu erreichen. Weitere Informationen finden Sie unter Autorisieren von Datenbankrollen zur Verwendung von SQL in Ihrer Datenbank.

Wenn Sie auf Funktionen stoßen, die für Ihre Migration wichtig sind, aber derzeit nicht in Aurora DSQL unterstützt werden, finden Sie unter Informationen Feedback zu Amazon Aurora DSQL geben zum Teilen von Feedback mit AWS.