Migration de PostgreSQL vers Aurora DSQL - Amazon Aurora DSQL
Compatibilité avec le framework et l'ORMSchémas de migration courantsComprendre les différences architecturalesConsidé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 à la CREATE INDEX ASYNC place de 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 à la DELETE FROM table_name place deTRUNCATE.

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

Configuration du système

Aurora DSQL étant entièrement géré, la configuration est gérée automatiquement en fonction des modèles de charge de travail. Utilisez la console AWS de gestion ou l'API pour gérer les paramètres du cluster.

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 :

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

Aurora DSQL prend en charge les relations et les JOIN opérations entre les tables. Pour garantir l'intégrité référentielle, implémentez la validation dans votre couche d'application. Cette 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é

Une seule base de données 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

Pour le traitement des données temporaires, vous DEVEZ utiliser des expressions de table (CTEs) et des sous-requêtes communes, qui fournissent des alternatives flexibles 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

Pour une fonctionnalité similaire à un déclencheur, implémentez une logique pilotée par les événements dans votre couche d'application.

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. Pour garantir l'intégrité référentielle, implémentez la validation dans votre couche d'application. 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 pour cette raison que 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 DSQL gère automatiquement l'optimisation du stockage, la collecte de statistiques et le réglage des performances. Les commandes de maintenance traditionnelles telles que celles-ci VACUUM sont gérées par le système.

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. Généré par l' UUIDs utilisateur ou généré par l'application IDs pour une distribution optimale.

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' UUIDs utilisateur ou généré par l'application IDs pour une distribution optimale. Si votre application nécessite des identifiants séquentiels, consultez. Séquences et colonnes d'identité

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 par cluster. Pour une séparation logique, créez des clusters Aurora DSQL distincts ou utilisez des schémas au sein d'un seul cluster.

  • La postgres base de données utilise le codage de caractères UTF-8, qui fournit une large prise en charge des caractères internationaux.

  • 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 :

    • Les opérations DDL et DML nécessitent des transactions distinctes

    • 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 gère les autorisations par le biais d'autorisations au niveau du schéma. Les utilisateurs administrateurs créent des schémas à l'aide de CREATE SCHEMA et accordent l'accès à l'aide GRANT USAGE ON SCHEMA de. Les utilisateurs administrateurs gèrent les objets dans le schéma public, tandis que les utilisateurs non administrateurs créent des objets dans des schémas créés par les utilisateurs pour définir clairement les limites de propriété. Pour de plus amples informations, veuillez consulter Autoriser les rôles de la base de données à utiliser SQL dans votre base de données.

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.