View a markdown version of this page

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 zentrale relationale Funktionen 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 Standard-PostgreSQL-Wire-Protokoll und gewährleistet so die Kompatibilität mit PostgreSQL-Treibern und Frameworks. Die meisten gängigen ORMs funktionieren 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 für den DDL-Betrieb

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

Erstellung eines Indexes

Verwenden Sie CREATE INDEX ASYNC anstelle von CREATE INDEX für die nicht blockierende Indexerstellung.

Vorteil: Zero-downtime Indexerstellung für große Tabellen.

Entfernung von Daten

Verwenden Sie DELETE FROM table_name stattTRUNCATE.

Alternative: Verwenden Sie, um die Tabelle vollständig neu zu erstellen, 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 Management Console 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:

Muster der referentiellen Integrität

Aurora DSQL unterstützt Tabellenbeziehungen und JOIN Operationen. Implementieren Sie die Validierung in Ihrer Anwendungsebene, um die referentielle Integrität zu gewährleisten. Dieses Design entspricht modernen verteilten Datenbankmustern, bei denen die Validierung auf Anwendungsebene mehr Flexibilität bietet und Leistungsengpässe aufgrund von kaskadierenden Vorgängen vermeidet.

Muster: Implementieren Sie referenzielle Integritätsprüfungen in Ihrer Anwendungsebene unter Verwendung einheitlicher Namenskonventionen, Validierungslogik und Transaktionsgrenzen. Viele umfangreiche 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 einzige 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 zur logischen Trennung oder verwenden Sie Schemas innerhalb eines einzelnen Clusters.

Keine temporären Tabellen

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

Alternative: Verwenden Sie CTEs mit 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:

Application-level Logik statt Datenbank-Trigger

Implementieren Sie ereignisgesteuerte Logik in Ihrer Anwendungsebene, um triggerähnliche Funktionen zu erzielen.

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

SQL-Funktionen für die Datenverarbeitung

Aurora DSQL unterstützt SQL-based 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 auf AWS Lambda-Funktionen.

Optimistische Parallelitätskontrolle statt pessimistischer Sperrung

Aurora DSQL verwendet Optimistic Concurrency Control (OCC), einen Ansatz ohne Sperren, der sich von herkömmlichen Mechanismen zum Sperren von Datenbanken unterscheidet. Anstatt Sperren zu erwerben, die andere Transaktionen blockieren, ermöglicht Aurora DSQL, dass Transaktionen ohne Blockierung fortgesetzt werden, und erkennt Konflikte bei der Übertragung. Dadurch werden Deadlocks beseitigt und verhindert, dass langsame Transaktionen andere Operationen 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, ähnlich wie bei der Behandlung von Sperr-Timeouts in herkömmlichen Datenbanken, aber Konflikte werden sofort gelöst, anstatt zu blockierenden Wartezeiten zu führen.

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

Operative Vereinfachungen

Aurora DSQL macht viele herkömmliche 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: Zeitfenster für die Datenbankwartung, Wartungsintervalle und die Optimierung der Systemparameter entfallen.

Automatische Partitionierung und Skalierung

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

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

Überlegungen zur PostgreSQL-Kompatibilität mit Aurora DSQL

Die Funktionsunterstützung von Aurora DSQL unterscheidet sich von selbstverwaltetem PostgreSQL, die die verteilte Architektur, den serverlosen Betrieb und die automatische Skalierung ermöglichen. 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 zur logischen Trennung separate Aurora DSQL-Cluster oder verwenden Sie Schemas innerhalb eines einzelnen Clusters.

  • Die postgres Datenbank verwendet eine 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 zeitzonenabhängigen Daten und Uhrzeiten intern in UTC. Sie können den TimeZone Konfigurationsparameter so einstellen, dass er konvertiert, wie er auf dem Client angezeigt wird, und als Standard für Client-Eingaben dienen, die der Server intern zur UTC-Konvertierung 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 durch Zuweisungen 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 Nicht-Admin-Benutzer Objekte in von Benutzern erstellten Schemas erstellen, um klare Eigentumsgrenzen zu gewährleisten. 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 von entscheidender Bedeutung sind, aber derzeit in Aurora DSQL nicht unterstützt werden, finden Sie unter Informationen Feedback zu Amazon Aurora DSQL geben zum Teilen von Feedback mit AWS.