Migration von PostgreSQL zu Aurora DSQL - Amazon Aurora DSQL
Framework- und ORM-Kompatibilität Allgemeine MigrationsmusterArchitektonische Unterschiede verstehenKI-gestützte MigrationErwä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 anstelle vonTRUNCATE.

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

Konfiguration des Systems

Aurora DSQL unterstützt keine ALTER SYSTEM Befehle, da das System vollständig verwaltet wird. Die Konfiguration erfolgt automatisch auf der Grundlage von Workload-Mustern.

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:

Sequenzen für Schlüssel

Verwenden Sie UUIDs oder zusammengesetzte Schlüssel anstelle von automatisch inkrementierenden Sequenzen. Automatisch inkrementierende Sequenzen führen in einem verteilten System zu einer Vielzahl von Konflikten, da mehrere Autoren versuchen, dieselben Daten zu aktualisieren. UUIDs bieten dieselbe Funktion, erfordern aber keine Koordination.

Beispiel: id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Referenzielle Integritätsmuster

Aurora DSQL unterstützt Tabellenbeziehungen und JOIN Operationen, erzwingt aber noch keine Fremdschlüsseleinschränkungen. Diese Designentscheidung 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 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 für die logische Trennung oder verwenden Sie Schemas innerhalb eines einzelnen Clusters.

Keine temporären Tabellen

Temporäre Tabellen werden in Aurora DSQL noch nicht unterstützt. Allgemeine Tabellenausdrücke (CTEs) und Unterabfragen können als Alternative für komplexe Abfragen verwendet werden.

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

Aurora DSQL unterstützt keine Trigger.

Migrationsstrategie: Verschieben Sie die Triggerlogik in den Anwendungscode, verwenden Sie ereignisgesteuerte Architekturen mit AWS Services wie EventBridge oder implementieren Sie Audit-Trails mithilfe der 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 eine 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, aber Fremdschlüsseleinschränkungen werden noch nicht unterstützt. Die Durchsetzung der referenziellen Integrität kann zwar nützlich sein, aber kaskadierende Operationen (wie das Kaskadieren von Löschungen) können zu unerwarteten Leistungsproblemen 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 SQL benötigt keine VACUUMTRUNCATE, oder ALTER SYSTEM Befehle. Das System verwaltet automatisch die Speicheroptimierung, die Erfassung von Statistiken und die Leistungsoptimierung.

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. Manuelle Partitionierung und Sequenzen sind nicht erforderlich.

Migrationstipp: Entfernen Sie die manuelle Partitionierungslogik und lassen Sie Aurora DSQL die Datenverteilung übernehmen. Verwenden Sie UUIDs oder von der Anwendung generierte Sequenzen anstelle IDs von Sequenzen.

KI-gestützte Migration

Sie können KI-Tools nutzen, um Ihre Codebasis zu Aurora DSQL zu migrieren:

Verwenden Sie Kiro zur Unterstützung bei der Migration

Programmieragenten wie Kiro können Ihnen helfen, Ihren PostgreSQL-Code zu analysieren und zu Aurora DSQL zu migrieren:

  • Schemaanalyse: Laden Sie Ihre vorhandenen Schemadateien hoch und bitten Sie Kiro, mögliche Kompatibilitätsprobleme zu identifizieren und Alternativen vorzuschlagen

  • Codetransformation: Geben Sie Ihren Anwendungscode an und bitten Sie Kiro, Ihnen zu helfen, die Triggerlogik umzugestalten, Sequenzen durch Transaktionsmuster zu ersetzen oder diese zu ändern UUIDs

  • Migrationsplanung: Bitten Sie Kiro, einen step-by-step Migrationsplan zu erstellen, der auf Ihrer spezifischen Anwendungsarchitektur basiert

Beispiel für Eingabeaufforderungen von Kiro:

"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"

"Help me refactor this trigger function into application-level logic for DSQL migration"

"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"

Aurora DSQL-MCP-Server

Der Aurora DSQL Model Context Protocol (MCP) -Server ermöglicht es KI-Assistenten wie Claude, sich direkt mit Ihrem Aurora DSQL-Cluster zu verbinden und die Aurora DSQL-Dokumentation zu durchsuchen. Dies ermöglicht der KI:

  • Analysieren Sie Ihr bestehendes Schema und schlagen Sie Migrationsänderungen vor

  • Testen Sie Abfragen und überprüfen Sie die Kompatibilität während der Migration

  • Stellen Sie genaue up-to-date Anleitungen bereit, die auf der neuesten Aurora DSQL-Dokumentation basieren

Informationen zur Verwendung des Aurora DSQL MCP-Servers mit Claude oder anderen KI-Assistenten finden Sie in den Setup-Anweisungen für den Aurora DSQL MCP-Server.

Ü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 namens postgres. Sie können keine zusätzlichen Datenbanken erstellen oder die postgres-Datenbank umbenennen oder löschen.

  • Die postgres-Datenbank verwendet UTF-8-Zeichencodierung. Sie können die Serverkodierung nicht ändern.

  • Die Datenbank verwendet ausschließlich C-Sortierung.

  • Aurora DSQL verwendet UTC als Systemzeitzone. Postgres speichert alle zeitzonenbezogenen Datums- und Uhrzeitangaben 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:

    • Eine Transaktion kann DDL- und DML-Operationen nicht kombinieren

    • 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 erlaubt derzeit keine Ausführung von GRANT [permission] ON DATABASE. Bei einem Versuch, diese Anweisung auszuführen, gibt Aurora DSQL die Fehlermeldung ERROR: unsupported object type in GRANT zurück.

  • Aurora DSQL erlaubt keine Ausführung des CREATE SCHEMA-Befehls für Benutzerrollen ohne Administratorrechte. Sie können den GRANT [permission] on DATABASE-Befehl nicht ausführen und auch keine CREATE-Berechtigungen für die Datenbank gewähren. Wenn eine Benutzerrolle ohne Administratorrechte versucht, ein Schema zu erstellen, gibt Aurora DSQL die Fehlermeldung ERROR: permission denied for database postgres zurück.

  • Benutzer ohne Administratorrechte können keine Objekte im öffentlichen Schema erstellen. Nur Benutzer mit Administratorenrechten können Objekte im öffentlichen Schema erstellen. Die Admin-Benutzerrolle ist berechtigt, Benutzern ohne Administratorrechte Lese-, Schreib- und Änderungszugriff auf diese Objekte zu gewähren, sie kann jedoch keine CREATE-Berechtigungen für das öffentliche Schema selbst gewähren. Benutzer ohne Administratorenrechte müssen andere, vom Benutzer erstellte Schemas für die Objekterstellung verwenden.

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.