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 vers DynamoDB depuis une base de données relationnelle

La migration d'une base de données relationnelle vers DynamoDB nécessite une planification minutieuse pour garantir un résultat réussi. Ce guide vous aidera à comprendre le fonctionnement de ce processus, les outils dont vous disposez, puis comment évaluer les stratégies de migration potentielles et sélectionner celle qui répondra à vos besoins.

Raisons justifiant la migration vers DynamoDB

La migration vers Amazon DynamoDB présente de nombreux avantages intéressants pour les entreprises et les organisations. Voici quelques avantages clés qui font de DynamoDB un choix intéressant pour la migration de bases de données :

Considérations relatives à la migration d'une base de données relationnelle vers DynamoDB

Les systèmes de base de données relationnelle et les SQL bases de données No ont des forces et des faiblesses différentes. Ces différences différencient la conception des bases de données entre les deux systèmes.

Concevoir pour aucune SQL base de données nécessite un état d'esprit différent de celui de concevoir pour un système de gestion de base de données relationnelle (RDBMS). Par exempleRDBMS, vous pouvez créer un modèle de données normalisé sans penser aux modèles d'accès. Vous pouvez l'étendre ultérieurement, pour répondre à de nouvelles questions et de nouveaux besoins d'interrogation. Vous pouvez organiser chaque type de données dans sa propre table.

Sans SQL conception, vous pouvez concevoir votre schéma pour DynamoDB lorsque vous connaissez les questions auxquelles il devra répondre. Il est essentiel de comprendre les problèmes commerciaux et les modèles de lecture et d'écriture des applications. Vous devez également vous efforcer de conserver le moins de tables possible dans une application DynamoDB. Le fait d'avoir moins de tables rend les choses plus évolutives, nécessite moins de gestion des autorisations et réduit les frais généraux pour votre application DynamoDB. Cela peut également contribuer à maintenir des coûts de sauvegarde globalement plus faibles.

La modélisation des données relationnelles pour DynamoDB et la création d'une nouvelle version de l'application frontale font l'objet d'une autre rubrique. Ce guide part du principe que vous disposez d'une nouvelle version de votre application conçue pour utiliser DynamoDB, mais vous devez tout de même déterminer la meilleure façon de migrer et de synchroniser les données historiques lors du passage à un autre.

Considérations relatives au dimensionnement

La taille maximale de chaque élément (ligne) que vous stockez dans une table DynamoDB est de 400 Ko. Pour de plus amples informations, veuillez consulter Quotas de service, de compte et de table dans Amazon DynamoDB. La taille de l'élément est déterminée par la taille totale de tous les noms et valeurs d'attributs d'un élément. Pour de plus amples informations, veuillez consulter Tailles et formats des éléments DynamoDB.

Si votre application doit stocker plus de données dans un élément que la limite de taille autorisée par DynamoDB, divisez l'élément en une collection d'articles, compressez les données de l'article ou stockez l'article sous forme d'objet dans Amazon Simple Storage Service (Amazon S3) tout en stockant l'identifiant d'objet Amazon S3 dans votre élément DynamoDB. Consultez Bonnes pratiques pour le stockage d'éléments et d'attributs volumineux dans DynamoDB. Le coût de mise à jour d'un article est basé sur sa taille réelle. Pour les charges de travail qui nécessitent des mises à jour fréquentes des éléments existants, la mise à jour de petits éléments d'un ou deux Ko coûtera moins cher que celle d'éléments plus volumineux. Voir Collections d'éléments : comment modéliser one-to-many les relations dans DynamoDB pour plus d'informations sur les collections d'articles.

Lorsque vous choisissez les attributs clés de partition et de tri, les autres paramètres de table, la taille et la structure des éléments, et lorsque vous souhaitez créer des index secondaires, n'oubliez pas de consulter la documentation de modélisation DynamoDB ainsi que le guide de. Optimisation des coûts sur les tables DynamoDB Assurez-vous de tester votre plan de migration afin que votre solution DynamoDB soit rentable et réponde aux fonctionnalités et limites de DynamoDB.

Comprendre le fonctionnement d'une migration vers DynamoDB

Avant de passer en revue les outils de migration mis à notre disposition, réfléchissez à la manière dont les écritures sont traitées par DynamoDB.

L'opération d'écriture par défaut, la plus courante, est une PutItemAPIopération unique. Vous pouvez effectuer une PutItem opération en boucle pour traiter des ensembles de données. DynamoDB prend en charge un nombre pratiquement illimité de connexions simultanées. Par conséquent, en supposant que vous puissiez configurer et exécuter une routine de chargement massivement multithread telle MapReduce que ou Spark, la vitesse d'écriture n'est limitée que par la capacité de la table cible (qui est également généralement illimitée).

Lorsque vous chargez des données dans DynamoDB, il est important de comprendre la vitesse d'écriture de votre chargeur. Si les éléments (lignes) que vous chargez ont une taille inférieure ou égale à 1 Ko, cette vélocité correspond simplement au nombre d'éléments par seconde. La table cible peut ensuite être provisionnée avec suffisamment WCU (unités de capacité d'écriture) pour gérer ce taux. Si votre chargeur dépasse la capacité allouée à chaque seconde, les demandes supplémentaires peuvent être limitées ou carrément rejetées. Vous pouvez vérifier les limites dans les CloudWatch graphiques de l'onglet de surveillance de la console DynamoDB.

La deuxième opération qui peut être effectuée concerne un API appel connexe BatchWriteItem. BatchWriteItemvous permet de combiner jusqu'à 25 demandes d'écriture en un seul API appel. Elles sont reçues par le service et traitées comme des PutItem demandes distinctes adressées à la table. À l'heure actuelleBatchWriteItem, lors de votre choix, vous ne bénéficierez pas de l'avantage des tentatives automatiques incluses dans le AWS SDKlorsque vous passez des appels singleton avecPutItem. Ainsi, s'il y a des erreurs (telles que des exceptions de limitation), vous devrez rechercher la liste des écritures ayant échoué dans l'appel de réponse à. BatchWriteItem Pour plus d'informations sur la gestion des avertissements de limitation au cas où ils seraient détectés dans les graphiques de CloudWatch régulation, voir. Problèmes de régulation pour DynamoDB

Le troisième type d'importation de données est possible grâce à la fonctionnalité d'importation DynamoDB depuis S3. Cette fonctionnalité vous permet de créer un ensemble de données volumineux dans Amazon S3 et de demander à DynamoDB d'importer automatiquement les données dans une nouvelle table. L'importation n'est pas instantanée et prendra un temps proportionnel à la taille du jeu de données. Cependant, c'est pratique car il ne nécessite aucune ETL plateforme ni aucun code DynamoDB personnalisé. DynamoDB charge les données dans une nouvelle table créée par l'importation. Actuellement, il ne vous permet pas de charger des données dans une table existante. DynamoDB importe les données telles quelles, sans aucune transformation. De mêmePutItem, il nécessite un processus en amont et écrit les données dans le format que vous avez choisi dans un compartiment Amazon S3.

Outils pour faciliter la migration vers DynamoDB

Il existe plusieurs ETL outils et outils courants que vous pouvez utiliser pour migrer des données vers DynamoDB.

Amazon fournit une multitude d'outils de données qui peuvent être utilisés pour la migration, notamment AWS Service de migration de base de données (DMS), AWS GlueEMR, Amazon et Amazon Managed Streaming pour Apache Kafka. Tous ces outils peuvent être utilisés pour effectuer une migration pendant un temps d'arrêt, et ils peuvent tirer parti des fonctionnalités de capture des données de modification (CDC) de la base de données relationnelle pour prendre en charge les migrations en ligne. Lorsque vous choisissez un outil, il est utile de prendre en compte les compétences et l'expérience de votre organisation avec chaque outil, ainsi que les fonctionnalités, les performances et le coût de chacun d'entre eux.

De nombreux clients choisissent d'écrire leurs propres scripts et tâches de migration afin de créer des transformations de données personnalisées pour le processus de migration. Si vous envisagez d'exploiter une table DynamoDB à volume élevé avec un trafic d'écriture important ou des tâches régulières de chargement en masse de grande taille, vous souhaiterez peut-être écrire vous-même le code de migration afin de vous familiariser avec le comportement de DynamoDB en cas de trafic d'écriture intense. Des scénarios tels que la gestion des accélérateurs et le provisionnement efficace des tables peuvent être expérimentés au début du projet lors de la réalisation d'une migration pratique.

Choix de la stratégie appropriée pour migrer vers DynamoDB

Une application de base de données relationnelle de grande taille peut s'étendre sur une centaine de tables ou plus et prendre en charge plusieurs fonctions d'application différentes. Lorsque vous vous apprêtez à effectuer une migration de grande envergure, pensez à diviser votre application en composants plus petits ou en microservices, et à migrer un petit ensemble de tables à la fois. Vous pouvez ensuite migrer des composants supplémentaires vers DynamoDB par vagues.

Lors du choix d'une stratégie de migration, différents facteurs peuvent vous orienter vers une solution ou une autre. Nous pouvons présenter ces options dans un arbre de décision afin de simplifier les options qui s'offrent à nous en fonction de nos besoins et des ressources disponibles. Les concepts sont brièvement mentionnés ici (mais seront abordés plus en détail plus loin dans le guide) :

Réalisation d'une migration hors ligne vers DynamoDB

Les migrations hors ligne conviennent lorsque vous pouvez autoriser une période d'indisponibilité pour effectuer la migration. Les bases de données relationnelles prennent généralement au moins un certain temps d'arrêt par mois pour des raisons de maintenance et de correction, ou peuvent être plus longues pour les mises à niveau matérielles ou les mises à niveau de versions majeures.

Amazon S3 peut être utilisé comme zone de transit lors d'une migration. Les données stockées au format CSV (valeurs séparées par des virgules) ou JSON DynamoDB peuvent être automatiquement importées dans une nouvelle table DynamoDB à l'aide de la fonctionnalité d'importation DynamoDB depuis S3.

Vous souhaiterez peut-être combiner des tables pour tirer parti de modèles uniques SQL d'absence d'accès (par exemple, transformer quatre anciennes tables en une seule table DynamoDB). Une demande de document contenant une valeur clé unique ou une requête pour une collection d'éléments pré-groupés est généralement renvoyée avec une latence supérieure à celle d'une SQL base de données qui effectue une jointure multitable. Cela complique toutefois la tâche de migration. Une SQL vue peut effectuer le travail au sein de la base de données source pour préparer un ensemble de données unique représentant les quatre tables d'un seul ensemble.

Cette vue permet de dénormaliser JOIN les tables ou de maintenir les entités normalisées et d'empiler les tables à l'aide d'un. SQL UNION Les décisions clés relatives à la refonte des données relationnelles sont abordées dans cette vidéo. Pour les migrations hors ligne, l'utilisation d'une vue pour combiner des tables est un excellent moyen de façonner les données d'un schéma de table unique DynamoDB.

Planifier

Effectuez une migration hors ligne à l'aide d'Amazon S3

Outils

La migration entièrement hors ligne est simple et directe, mais elle risque de ne pas être populaire auprès des propriétaires et des utilisateurs d'applications. Les utilisateurs bénéficieraient si l'application pouvait fournir des niveaux de service réduits pendant la migration, au lieu de ne pas fournir de service du tout.

Vous pouvez ajouter des fonctionnalités pour désactiver les écritures pendant la migration hors ligne, tout en permettant aux lectures de se poursuivre normalement. Les utilisateurs de l'application peuvent toujours parcourir et interroger en toute sécurité les données existantes pendant la migration des données relationnelles. Si c'est ce que vous recherchez, poursuivez votre lecture pour en savoir plus sur les migrations hybrides.

Réalisation d'une migration hybride vers DynamoDB

Bien que toutes les applications de base de données exécutent des opérations de lecture et d'écriture, les types d'opérations d'écriture effectués doivent être pris en compte lors de la planification d'une migration hybride ou en ligne. Les écritures de base de données peuvent être classées en trois catégories : les insertions, les mises à jour et les suppressions. Certaines applications peuvent ne pas nécessiter de traitement immédiat des suppressions. Ces applications peuvent, par exemple, reporter les suppressions à un processus de nettoyage en masse à la fin du mois. Ces types d'applications peuvent être plus simples à migrer tout en garantissant une disponibilité partielle.

Planifier

Effectuez une migration hybride en ligne/hors ligne avec deux écritures d'application

Outils

Réalisation d'une migration en ligne vers DynamoDB en faisant migrer chaque table 1:1

De nombreuses bases de données relationnelles disposent d'une fonctionnalité appelée Change Data Capture (CDC), qui permet aux utilisateurs de demander une liste des modifications apportées à une table avant ou après un moment donné. CDCutilise des journaux internes pour activer cette fonctionnalité et il n'est pas nécessaire que la table contienne une colonne d'horodatage pour fonctionner.

Lorsque vous migrez un schéma de SQL tables vers une base de SQL données sans base de données, vous souhaiterez peut-être combiner et remodeler vos données en un nombre réduit de tables. Cela vous permettra de collecter des données en un seul endroit et d'éviter d'avoir à joindre manuellement les données associées lors d'opérations de lecture en plusieurs étapes. Cependant, la mise en forme des données d'une seule table n'est pas toujours requise et vous devez parfois migrer des tables une pour une vers DynamoDB. Ces migrations de tables individuelles sont moins compliquées car vous pouvez tirer parti de la CDC fonctionnalité de base de données source à l'aide d'ETLoutils courants qui prennent en charge ce type de migration. Les données de chaque ligne peuvent toujours être transformées dans de nouveaux formats, mais la portée de chaque table reste la même.

Envisagez de migrer SQL les tables 1 à 1 vers DynamoDB, en précisant que DynamoDB ne prend pas en charge les jointures côté serveur. Vous devez ajouter une logique à votre application pour combiner les données de plusieurs tables.

Planifier

Effectuez une migration en ligne de chaque table dans DynamoDB à l'aide de AWS DMS

Outils

Effectuez une migration en ligne vers DynamoDB à l'aide d'une table intermédiaire personnalisée

Comme dans le scénario de migration hors ligne ci-dessus, vous pouvez choisir de combiner des tables pour tirer parti de modèles uniques SQL d'absence d'accès (par exemple, transformer quatre anciennes tables en une seule table DynamoDB). A SQL VIEW pourrait effectuer le travail dans la base de données source pour préparer un ensemble de données unique représentant les quatre tables d'un seul ensemble.

Toutefois, pour les migrations en ligne avec des données en temps réel et changeantes, vous ne pouvez pas tirer parti CDC des fonctionnalités car elles ne sont pas prises en charge pour VIEW nous. Si vos tables incluent une colonne d'horodatage mise à jour pour la dernière fois et que celle-ci est incorporée dans la colonneVIEW, vous pouvez créer une ETL tâche personnalisée qui les utilise pour effectuer un chargement en bloc avec synchronisation.

Une nouvelle approche pour relever ce défi consiste à utiliser des SQL fonctionnalités standard telles que les vues, les procédures stockées et les déclencheurs pour créer une nouvelle SQL table au format DynamoDB No final souhaité. SQL

Si votre serveur de base de données dispose de la capacité inutilisée, il est possible de créer cette table intermédiaire unique avant le début de la migration. Pour ce faire, vous devez écrire une procédure stockée qui lira les données des tables existantes, transformera les données selon les besoins et écrira dans la nouvelle table intermédiaire. Vous pouvez ajouter un ensemble de déclencheurs pour répliquer les modifications apportées aux tables dans la table intermédiaire en temps réel. Si les déclencheurs ne sont pas autorisés conformément à la politique de l'entreprise, les modifications apportées aux procédures stockées peuvent produire le même résultat. Vous devez ajouter quelques lignes de code à toute procédure qui écrit des données, afin d'écrire en outre les mêmes modifications dans la table intermédiaire.

La mise en place de cette table intermédiaire entièrement synchronisée avec les anciennes tables d'applications constitue un excellent point de départ pour une migration en direct. Outils utilisant une base de données CDC pour effectuer des migrations dynamiques, tels que AWS DMS, peut désormais être utilisé contre ce tableau. L'avantage de cette approche est qu'elle utilise des SQL compétences et des fonctionnalités bien connues disponibles dans le moteur de base de données relationnelle.

Planifier

Effectuez une migration en ligne à l'aide d'une SQL table intermédiaire en utilisant AWS DMS

Outils

Ce guide présentait plusieurs considérations et approches relatives à la migration des données de base de données relationnelle vers DynamoDB, en mettant l'accent sur la réduction des temps d'arrêt et l'utilisation d'outils et de techniques de base de données courants. Pour plus d’informations, consultez les ressources suivantes :