Migration de PostgreSQL vers Aurora DSQL - Amazon Aurora DSQL
Compatibilité avec le framework et l'ORM Schémas de migration courantsComprendre les différences architecturalesMigration assistée par IAConsidérations de compatibilitéVous avez besoin d'aide pour la migration ?

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migration de PostgreSQL vers Aurora DSQL

Aurora DSQL est conçu pour être compatible avec PostgreSQL et prend en charge les fonctionnalités relationnelles de base telles que les transactions ACID, les index secondaires, les jointures et les opérations DML standard. La plupart des applications PostgreSQL existantes peuvent migrer vers Aurora DSQL avec un minimum de modifications.

Cette section fournit des conseils pratiques pour la migration de votre application vers Aurora DSQL, notamment la compatibilité du framework, les modèles de migration et les considérations architecturales.

Compatibilité avec le framework et l'ORM

Aurora DSQL utilise le protocole filaire standard de PostgreSQL, garantissant ainsi la compatibilité avec les pilotes et les frameworks PostgreSQL. Les plus courants ORMs fonctionnent avec Aurora DSQL avec peu ou pas de modifications. Voir Adaptateurs et dialectes Aurora DSQL pour les implémentations de référence et les intégrations ORM disponibles.

Schémas de migration courants

Lors de la migration de PostgreSQL vers Aurora DSQL, certaines fonctionnalités fonctionnent différemment ou ont une syntaxe alternative. Cette section fournit des conseils sur les scénarios de migration courants.

Alternatives de fonctionnement du DDL

Aurora DSQL propose des alternatives modernes aux opérations DDL PostgreSQL traditionnelles :

Création d'index

À utiliser CREATE INDEX ASYNC plutôt que CREATE INDEX pour la création d'index non bloquants.

Avantage : création d'index sans interruption sur de grandes tables.

Suppression des données

Utiliser DELETE FROM table_name au lieu deTRUNCATE.

Alternative : Pour une récréation complète de la table, utilisez DROP TABLE puisCREATE TABLE.

Configuration du système

Aurora DSQL ne prend pas en charge ALTER SYSTEM les commandes car le système est entièrement géré. La configuration est gérée automatiquement en fonction des modèles de charge de travail.

Avantage : pas besoin de réglage de la base de données ou de gestion des paramètres.

Modèles de conception de schémas

Adaptez ces modèles PostgreSQL courants pour assurer la compatibilité avec Aurora DSQL :

Séquences de touches

Utilisez UUIDs des clés composites au lieu de séquences à incrémentation automatique. Les séquences à incrémentation automatique génèrent de nombreux conflits dans un système distribué, car plusieurs rédacteurs tentent de mettre à jour les mêmes données. UUIDs fournissent la même fonction mais ne nécessitent aucune coordination.

Exemple : id UUID PRIMARY KEY DEFAULT gen_random_uuid()

Modèles d'intégrité référentiels

Aurora DSQL prend en charge les relations entre les tables et les JOIN opérations, mais n'applique pas encore les contraintes liées aux clés étrangères. Ce choix de conception s'aligne sur les modèles de bases de données distribuées modernes dans lesquels la validation de la couche application apporte plus de flexibilité et évite les problèmes de performance liés aux opérations en cascade.

Modèle : implémentez des contrôles d'intégrité référentielle dans votre couche d'application en utilisant des conventions de dénomination, une logique de validation et des limites de transaction cohérentes. De nombreuses applications à grande échelle préfèrent cette approche pour un meilleur contrôle de la gestion des erreurs et des performances.

Traitement temporaire des données

Utilisez CTEs des sous-requêtes ou des tables ordinaires avec une logique de nettoyage au lieu de tables temporaires.

Alternative : créez des tables avec des noms spécifiques à la session et nettoyez-les dans votre application.

Comprendre les différences architecturales

L'architecture distribuée et sans serveur d'Aurora DSQL se distingue intentionnellement de PostgreSQL traditionnel dans plusieurs domaines. Ces différences permettent d'exploiter les principaux avantages d'Aurora DSQL en termes de simplicité et d'évolutivité.

Modèle de base de données simplifié

Base de données unique par cluster

Aurora DSQL fournit une base de données intégrée nommée postgres par cluster.

Conseil de migration : si votre application utilise plusieurs bases de données, créez des clusters Aurora DSQL distincts pour une séparation logique, ou utilisez des schémas au sein d'un seul cluster.

Pas de tables temporaires

Les tables temporaires ne sont pas encore prises en charge dans Aurora DSQL. Les expressions de table communes (CTEs) et les sous-requêtes peuvent être utilisées comme alternative pour les requêtes complexes.

Alternative : à utiliser CTEs avec des WITH clauses pour des ensembles de résultats temporaires ou avec des tables ordinaires avec un nom unique pour les données spécifiques à la session.

Gestion automatique du stockage

Aurora DSQL élimine les tablespaces et la gestion manuelle du stockage. Le stockage s'adapte et s'optimise automatiquement en fonction de vos modèles de données.

Avantage : il n'est pas nécessaire de surveiller l'espace disque, de planifier l'allocation de stockage ou de gérer les configurations des tablespaces.

Modèles d'application modernes

Aurora DSQL encourage les modèles de développement d'applications modernes qui améliorent la maintenabilité et les performances :

Logique au niveau de l'application plutôt que des déclencheurs de base de données

Aurora DSQL ne prend pas en charge les déclencheurs.

Stratégie de migration : déplacez la logique de déclenchement vers le code de l'application, utilisez des architectures axées sur les événements avec des AWS services tels que EventBridge, ou implémentez des pistes d'audit à l'aide de la journalisation des applications.

Fonctions SQL pour le traitement des données

Aurora DSQL prend en charge les fonctions basées sur SQL, mais pas les langages procéduraux tels que PL/pgSQL.

Alternative : utilisez des fonctions SQL pour les transformations de données ou déplacez une logique complexe vers votre couche d'application ou vos fonctions AWS Lambda.

Un contrôle de simultanéité optimiste au lieu d'un verrouillage pessimiste

Aurora DSQL utilise un contrôle de simultanéité optimiste (OCC), une approche sans verrou qui diffère des mécanismes de verrouillage de base de données traditionnels. Au lieu d'acquérir des verrous qui bloquent d'autres transactions, Aurora DSQL permet aux transactions de se poursuivre sans blocage et détecte les conflits au moment de la validation. Cela élimine les blocages et empêche les transactions lentes de bloquer d'autres opérations.

Principale différence : en cas de conflit, Aurora DSQL renvoie une erreur de sérialisation plutôt que d'obliger les transactions à attendre le verrouillage. Cela nécessite que les applications mettent en œuvre une logique de nouvelle tentative, similaire à la gestion des délais de verrouillage dans les bases de données traditionnelles, mais les conflits sont résolus immédiatement au lieu de provoquer des blocages d'attente.

Modèle de conception : implémentez une logique de transaction idempotente avec des mécanismes de nouvelle tentative. Concevez des schémas pour minimiser les conflits en utilisant des clés primaires aléatoires et en répartissant les mises à jour sur l'ensemble de votre plage de clés. Pour en savoir plus, consultez Contrôle de simultanéité dans Aurora DSQL.

Relations et intégrité référentielle

Aurora DSQL prend en charge les relations de clé étrangère entre les tables, y compris les JOIN opérations, mais les contraintes liées aux clés étrangères ne sont pas encore prises en charge. Bien que le renforcement de l'intégrité référentielle puisse être utile, les opérations en cascade (comme les suppressions en cascade) peuvent créer des problèmes de performances inattendus. Par exemple, la suppression d'une commande comportant 1 000 articles devient une transaction de 1 001 lignes. C'est pourquoi de nombreux clients évitent les contraintes liées aux clés étrangères.

Modèle de conception : implémentez des contrôles d'intégrité référentiels dans votre couche d'application, utilisez d'éventuels modèles de cohérence ou tirez parti des AWS services pour la validation des données.

Simplifications opérationnelles

Aurora DSQL élimine de nombreuses tâches de maintenance de base de données traditionnelles, réduisant ainsi les frais d'exploitation :

Aucune maintenance manuelle requise

Aurora SQL ne nécessite pas VACUUM de TRUNCATE ALTER SYSTEM commandes. Le système gère automatiquement l'optimisation du stockage, la collecte de statistiques et le réglage des performances.

Avantage : élimine le besoin de fenêtres de maintenance des bases de données, de planification du vide et de réglage des paramètres système.

Partitionnement et mise à l'échelle automatiques

Aurora DSQL partitionne et distribue automatiquement vos données en fonction des modèles d'accès. Le partitionnement manuel et les séquences ne sont pas nécessaires.

Conseil de migration : supprimez la logique de partitionnement manuel et laissez Aurora DSQL gérer la distribution des données. Généré par l'utilisateur UUIDs ou par l'application IDs au lieu de séquences.

Migration assistée par IA

Vous pouvez tirer parti des outils d'intelligence artificielle pour vous aider à migrer votre base de code vers Aurora DSQL :

Utiliser Kiro pour l'assistance à la migration

Les agents de codage tels que Kiro peuvent vous aider à analyser et à migrer votre code PostgreSQL vers Aurora DSQL :

  • Analyse du schéma : téléchargez vos fichiers de schéma existants et demandez à Kiro d'identifier les problèmes de compatibilité potentiels et de suggérer des alternatives

  • Transformation du code : fournissez le code de votre application et demandez à Kiro de vous aider à refactoriser la logique de déclenchement, à remplacer des séquences par des séquences ou à modifier UUIDs les modèles de transaction

  • Planification de la migration : demandez à Kiro de créer un plan de step-by-step migration basé sur l'architecture spécifique de votre application

Exemple d'instructions 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"

Serveur Aurora SQL MCP

Le serveur Aurora DSQL Model Context Protocol (MCP) permet aux assistants d'intelligence artificielle tels que Claude de se connecter directement à votre cluster Aurora DSQL et de rechercher la documentation Aurora DSQL. Cela permet à l'IA de :

  • Analysez votre schéma existant et suggérez des modifications de migration

  • Tester les requêtes et vérifier la compatibilité lors de la migration

  • Fournissez des up-to-date conseils précis basés sur la dernière documentation d'Aurora DSQL

Pour utiliser le serveur Aurora DSQL MCP avec Claude ou d'autres assistants IA, consultez les instructions de configuration du serveur Aurora DSQL MCP.

Considérations relatives à Aurora DSQL pour la compatibilité avec PostgreSQL

La prise en charge des fonctionnalités d'Aurora DSQL présente des différences par rapport à PostgreSQL autogéré, qui permettent son architecture distribuée, son fonctionnement sans serveur et son dimensionnement automatique. La plupart des applications fonctionnent dans les limites de ces différences sans modification.

Pour des considérations générales, consultez Considérations relatives à l’utilisation d Amazon Aurora DSQL. Pour les quotas et les limites, consultez Quotas de cluster et limites de base de données dans Amazon Aurora DSQL.

  • Aurora DSQL utilise une seule base de données intégrée nommée postgres. Vous ne pouvez pas créer de bases de données supplémentaires, renommer ni supprimer la base de données postgres.

  • La base de données postgres utilise l’encodage de caractères UTF-8. Vous ne pouvez pas modifier le codage du serveur.

  • La base de données utilise uniquement le classement C.

  • Aurora DSQL utilise UTC comme fuseau horaire du système. Postgres stocke toutes les dates et heures tenant compte du fuseau horaire en interne en UTC. Vous pouvez définir le paramètre de TimeZone configuration pour convertir la façon dont il est affiché pour le client et servir de valeur par défaut pour les entrées du client que le serveur utilisera pour convertir en UTC en interne.

  • Le niveau d’isolement des transactions est défini dans PostgreSQL Repeatable Read.

  • Les transactions sont soumises aux contraintes suivantes :

    • Une transaction ne peut pas mélanger les opérations DDL et DML

    • Une transaction ne peut inclure qu’une seule instruction DDL

    • Une transaction peut modifier jusqu’à 3 000 lignes, quel que soit le nombre d’index secondaires

    • La limite de 3 000 lignes s’applique à toutes les instructions DML (INSERT, UPDATE, DELETE)

  • Les connexions à la base de données expirent au bout d’une heure.

  • Aurora DSQL ne vous permet pas d’exécuter GRANT [permission] ON DATABASE actuellement. Si vous tentez d’exécuter cette instruction, Aurora DSQL renvoie le message d’erreur ERROR: unsupported object type in GRANT.

  • Aurora DSQL n’autorise pas les rôles d’utilisateur non administrateur à exécuter la commande CREATE SCHEMA. Vous ne pouvez pas exécuter la commande GRANT [permission] on DATABASE et accorder les autorisations CREATE sur la base de données. Si un rôle d’utilisateur non administrateur tente de créer un schéma, Aurora DSQL renvoie le message d’erreur ERROR: permission denied for database postgres.

  • Les utilisateurs non administrateurs ne peuvent pas créer d’objets dans le schéma public. Seuls les utilisateurs administrateurs peuvent créer des objets dans le schéma public. Le rôle d’utilisateur administrateur est autorisé à accorder l’accès en lecture, en écriture et en modification à ces objets à des utilisateurs non administrateurs, mais il ne peut pas accorder d’autorisations CREATE au schéma public lui-même. Les utilisateurs non administrateurs doivent utiliser des schémas différents créés par l’utilisateur pour créer des objets.

Si vous rencontrez des fonctionnalités essentielles pour votre migration mais qui ne sont pas actuellement prises en charge dans Aurora DSQL, consultez Fournir des commentaires sur Amazon Aurora DSQL pour savoir comment partager des commentaires avec AWS.