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.
Utilisation d'une implémentation personnalisée dans .NET ou Java avec AWS SDKs
Au lieu de vous fier à d'autres AWS services pour copier des tables entre comptes, vous pouvez créer une solution personnalisée à l'aide de .NET, Java, Python ou d'un autre langage de programmation pris en charge. AWS fournit SDKs, qui permettent un accès programmatique aux AWS services ou APIs, dans plusieurs langues. Cette solution nécessite une expérience pratique du développement dans le langage que vous utilisez.
Vous pouvez créer une application console (ou un nouveau point de terminaison d'API, si vous travaillez sur une API Web) qui peut être invoquée pour effectuer une copie complète de la table. La solution personnalisée doit effectuer les étapes suivantes :
Supprimez la table DynamoDB dans le compte cible.
Créez la table DynamoDB (avec capacité à la demande) et les index dans le compte cible. Vous pouvez également utiliser le mode de capacité provisionnée et définir le RCUs et en WCUs fonction de vos besoins.
Copiez les données du compte source vers le compte cible, à l'aide de l'opération d'écriture par lots DynamoDB AWS dans le SDK afin de réduire le nombre d'appels de service vers DynamoDB.
Cette solution convient parfaitement aux tables DynamoDB de petite taille (moins de 500 Mo).
Pour une table DynamoDB contenant 200 000 éléments (taille moyenne des éléments 30 Ko et taille de table de 250 Mo), cette solution, qui inclut la création de tables et le peuplement des données, prend environ 5 minutes :
Mode capacité — Provisionné, avec 4000 RCUs et 4000 WCUs
Unités de capacité consommées — 30 K RCUs et environ 400 K WCUs
Avantages
La solution ne dépend d'aucun autre AWS service que DynamoDB, ce qui réduit les frais de maintenance.
La solution peut être rendue sans serveur en utilisant une AWS Lambda fonction pour l'exécuter. Toutefois, le temps d'exécution doit être inférieur ou égal à 15 minutes.
Désavantages
La solution consomme plus RCUs et WCUs.
Ce n'est peut-être pas une bonne solution pour les grands ensembles de données, car elle nécessite des connexions actives avec deux tables DynamoDB différentes dans deux comptes différents (en utilisant deux jetons de sécurité différents). Si la copie de table pour un ensemble de données volumineux prend du temps, il peut y avoir des interruptions de connexion ou l'expiration du jeton de sécurité. Vous devez donc implémenter une logique pour gérer ces possibilités. Vous devez également implémenter une logique pour continuer la copie là où elle a échoué.
Pour plus d'informations, consultez la section Copier les tables Amazon DynamoDB entre les comptes à l'aide d'un modèle d'implémentation personnalisé.
