View a markdown version of this page

Migration de PostgreSQL vers Aurora DSQL - Amazon Aurora DSQL
Compatibilité avec le framework et l'ORMSchémas migratoires 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 Compatibilité des fonctionnalités SQL dans Aurora DSQL 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 en ce qui concerne 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 PostgreSQL standard, garantissant la compatibilité avec les pilotes et les frameworks PostgreSQL. Les ORM les plus courants fonctionnent avec Aurora DSQL avec peu ou pas de modifications. Consultez Adaptateurs et dialectes Aurora DSQL les implémentations de référence et les intégrations ORM disponibles.

Schémas migratoires courants

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

Alternatives de fonctionnement DDL

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

Création d'index

À utiliser CREATE INDEX ASYNC au lieu de CREATE INDEX pour la création d'index non bloquant.

Avantage : création d' Zero-downtime index sur de grandes tables.

Suppression de données

Utiliser à la DELETE FROM table_name place deTRUNCATE.

Alternative : Pour une détente complète à la table, utilisez DROP TABLE suivi deCREATE TABLE.

Configuration du système

Aurora DSQL est entièrement géré, de sorte que 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érentielle

Aurora DSQL prend en charge les relations et les JOIN opérations entre 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 offre plus de flexibilité et évite les goulots d'étranglement liés aux opérations en cascade en termes de performances.

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 mieux contrôler la gestion des erreurs et les performances.

Traitement temporaire des données

Utilisez des CTE, des sous-requêtes ou des tables classiques avec une logique de nettoyage au lieu de tables temporaires.

Alternative : créez des tableaux 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 diffère intentionnellement de PostgreSQL traditionnel à plusieurs égards. Ces différences sont à l'origine des 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

Pour le traitement temporaire des données, VOUS DEVEZ utiliser des expressions de table communes (CTE) et des sous-requêtes, qui fournissent des alternatives flexibles pour les requêtes complexes.

Alternative : utilisez des CTE avec des WITH clauses pour les ensembles de résultats temporaires, ou des tableaux classiques avec un nom unique pour les données spécifiques à une session.

Gestion automatique du stockage

Aurora DSQL élimine les tablespaces et la gestion manuelle du stockage. Le stockage évolue 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 :

Application-level logique au lieu de déclencheurs de base de données

Pour bénéficier d'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 pilotées par 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 SQL-based des fonctions mais pas des langages procéduraux tels que PL/pgSQL.

Alternative : utilisez les 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 le contrôle de simultanéité optimiste (OCC), une approche sans verrouillage 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.

Différence essentielle : en cas de conflit, Aurora DSQL renvoie une erreur de sérialisation au lieu de faire attendre le verrouillage des transactions. Cela oblige les applications à implémenter 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 temps d'attente bloquants.

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 votre plage de clés. Pour en savoir plus, consultez Contrôle de simultanéité dans Aurora DSQL.

Simplifications opérationnelles

Aurora DSQL élimine de nombreuses tâches traditionnelles de maintenance des bases de données, 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 VACUUM sont gérées par le système.

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

Partitionnement et dimensionnement automatiques

Aurora DSQL partitionne et distribue automatiquement vos données en fonction de modèles d'accès. Utilisez des UUID ou des ID générés par l'application pour une distribution optimale.

Conseil de migration : supprimez la logique de partitionnement manuel et laissez Aurora DSQL gérer la distribution des données. Utilisez des UUID ou des ID générés par l'application 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

Aurora DSQL présente des fonctionnalités différentes de celles de PostgreSQL autogéré en matière de prise en charge, qui permettent son architecture distribuée, son fonctionnement sans serveur et sa mise à l'échelle automatique. La plupart des applications fonctionnent avec 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 base de données intégrée unique 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 UTF-8 caractères, qui fournit une large prise en charge internationale des caractères.

  • 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 des fuseaux horaires 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 paramètre par défaut pour les entrées 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 administrateurs créent des schémas à l'aide de. Ils accordent CREATE SCHEMA l'accès à l'aide GRANT USAGE ON SCHEMA de. Les administrateurs gèrent les objets du schéma public, tandis que les utilisateurs non administrateurs créent des objets dans des schémas créés par les utilisateurs afin de 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 les informations sur la manière de partager vos commentaires avec AWS.