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 base de données Amazon DynamoDB en tant que cible pour AWS Database Migration Service
Vous pouvez utiliser AWS DMS pour migrer les données vers une table Amazon DynamoDB. Amazon DynamoDB est un service de base de données NoSQL entièrement géré qui offre des performances exceptionnelles et prévisibles en termes de rapidité et de capacité de mise à l'échelle. AWS DMS prend en charge l'utilisation d'une base de données relationnelle ou de MongoDB en tant que source.
Dans DynamoDB, les tables, les éléments et les attributs sont les principaux composants que vous utilisez. Une table est une collection d'éléments et chaque élément est une collection d'attributs. DynamoDB utilise les clés primaires, appelées clés de partition, afin d'identifier de façon unique chaque élément d'une table. Vous pouvez également utiliser des clés et des index secondaires pour fournir une plus grande flexibilité d'interrogation.
Vous utilisez le mappage d'objet afin de migrer vos données d'une base de données source vers une table DynamoDB cible. Le mappage d'objet vous permet de déterminer l'emplacement des données sources dans la cible.
Quand AWS DMS crée les tables sur un point de terminaison cible DynamoDB, il crée autant de tables que dans le point de terminaison de la base de données source. AWS DMS définit également plusieurs valeurs de paramètre DynamoDB. Le coût de création de la table dépend de la quantité de données et du nombre de tables à migrer.
Note
L'option Mode SSL de la console AWS DMS ou de l'API ne s'applique pas à certains flux de données et services NoSQL tels que Kinesis et DynamoDB. Étant donné qu'ils sont sécurisés par défaut, AWS DMS indique que le paramètre du mode SSL est None (SSL Mode=None). Vous n'avez pas besoin de fournir de configuration supplémentaire pour que votre point de terminaison utilise le protocole SSL. Par exemple, lorsque DynamoDB est utilisé comme point de terminaison cible, il est sécurisé par défaut. Tous les appels d'API à DynamoDB utilisent le protocole SSL. Il n'est donc pas nécessaire d'ajouter une option SSL supplémentaire dans le point de terminaison AWS DMS. Vous pouvez placer et récupérer des données en toute sécurité via des points de terminaison SSL à l'aide du protocole HTTPS, utilisé par AWS DMS par défaut lors de la connexion à une base de données DynamoDB.
Pour augmenter la vitesse du transfert, AWS DMS prend en charge un chargement complet multithread sur une instance cible DynamoDB. DMS prend en charge ce traitement multithread avec des paramètres de tâche, notamment les suivants :
-
MaxFullLoadSubTasks: utilisez cette option pour indiquer le nombre maximal de tables sources à charger en parallèle. DMS charge chaque table dans sa table cible DynamoDB correspondante à l'aide d'une sous-tâche dédiée. La valeur par défaut est 8. La valeur maximale est 49. -
ParallelLoadThreads: utilisez cette option pour spécifier le nombre de threads utilisés par AWS DMS pour charger chaque table dans sa table cible DynamoDB. La valeur par défaut est 0 (à thread unique). La valeur maximale est 200. Vous pouvez demander une augmentation de cette limite maximale.Note
DMS attribue chaque segment d'une table à son propre thread pour le chargement. Par conséquent, définissez
ParallelLoadThreadssur le nombre maximal de segments que vous spécifiez pour une table de la source. -
ParallelLoadBufferSize: utilisez cette option pour spécifier le nombre maximal d'enregistrements à stocker dans la mémoire tampon utilisée par les threads de chargement parallèles pour charger les données dans la cible DynamoDB. La valeur par défaut est 50. La valeur maximale est 1 000. Utilisez ce paramètre avecParallelLoadThreads.ParallelLoadBufferSizeest valide uniquement dans le cas de plusieurs threads. -
Paramètres de mappage de table pour des tables individuelles : utilisez des règles
table-settingspour identifier les tables individuelles de la source que vous souhaitez charger en parallèle. Utilisez également ces règles pour spécifier comment segmenter les lignes de chaque table pour le chargement multithread. Pour de plus amples informations, veuillez consulter Règles des paramètres de table et de collection et opérations.
Note
Lorsque AWS DMS définit les valeurs des paramètres DynamoDB pour une tâche de migration, la valeur par défaut du paramètre RCU (Unités de capacité de lecture) est définie sur 200.
La valeur du paramètre WCU (Write Capacity Units) est également définie, mais sa valeur dépend de plusieurs autres paramètres :
-
La valeur par défaut du paramètre WCU est 200.
-
Si le paramètre de tâche
ParallelLoadThreadsest défini sur une valeur supérieure à 1 (0 par défaut), le paramètre WCU est défini à 200 fois la valeurParallelLoadThreads. Les frais d'utilisation standard d'AWS DMS s'appliquent aux ressources que vous utilisez.
Migration à partir d'une base de données relationnelle vers une table DynamoDB
AWS DMS prend en charge la migration de données vers les types de données scalaires DynamoDB. Lors d'une migration depuis une base de données relationnelle telle qu'Oracle ou MySQL vers DynamoDB, vous pouvez restructurer la manière dont vous stockez les données.
AWS DMS prend actuellement en charge la restructuration d'une table unique vers une table unique d'attributs de types scalaires DynamoDB. Si vous migrez des données vers DynamoDB depuis une table de base de données relationnelle, vous prenez les données d'une table et les reformatez en attributs de types de données scalaires DynamoDB. Ces attributs peuvent accepter des données de plusieurs colonnes et vous pouvez mapper directement une colonne à un attribut.
AWS DMS prend en charge les types de données scalaires DynamoDB suivants :
-
Chaîne
-
Nombre
-
Booléen
Note
Les données NULL provenant de la source sont ignorées dans la cible.
Prérequis pour l'utilisation de DynamoDB en tant que cible pour AWS Database Migration Service
Avant de commencer à utiliser une base de données DynamoDB en tant que cible pour AWS DMS, veillez à créer un rôle IAM. Ce rôle IAM doit permettre à AWS DMS d'assumer et d'accorder l'accès aux tables DynamoDB qui constituent la cible de la migration. L'ensemble d'autorisations d'accès minimum est indiqué dans la stratégie IAM suivante.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "dms.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Le rôle que vous utilisez pour la migration vers DynamoDB doit bénéficier des autorisations suivantes.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:CreateTable", "dynamodb:DescribeTable", "dynamodb:DeleteTable", "dynamodb:DeleteItem", "dynamodb:UpdateItem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:account-id:table/name1", "arn:aws:dynamodb:us-west-2:account-id:table/OtherName*", "arn:aws:dynamodb:us-west-2:account-id:table/awsdms_apply_exceptions", "arn:aws:dynamodb:us-west-2:account-id:table/awsdms_full_load_exceptions" ] }, { "Effect": "Allow", "Action": [ "dynamodb:ListTables" ], "Resource": "*" } ] }
Limitations de l'utilisation de DynamoDB en tant que cible pour AWS Database Migration Service
Les limitations suivantes s'appliquent à l'utilisation de DynamoDB en tant que cible :
-
DynamoDB limite la précision du type de données Number à 38 places. Stockez tous les types de données en tant que chaîne avec une meilleure précision. Vous devez le spécifier explicitement à l'aide de la fonction de mappage d'objet.
-
Étant donné que DynamoDB ne possède pas de type de données Date, les données utilisant le type de données Date sont converties en chaînes.
-
DynamoDB n'autorise pas les mises à jour des attributs de la clé primaire. Cette restriction est importante lors de l'utilisation de la réplication continue avec la capture des données modifiées (CDC), car elle peut entraîner des données non souhaitées dans la cible. En fonction de la façon dont l'objet est mappé, une opération CDC qui met à jour la clé primaire peut réaliser l'une des deux actions suivantes. Elle peut échouer ou insérer un nouvel élément avec la clé primaire mise à jour et des données incomplètes.
-
AWS DMS prend uniquement en charge la réplication de tables avec des clés primaires non composites. Une exception s'applique si vous spécifiez un mappage d'objet pour la table cible avec une clé de partition ou une clé de tri personnalisée, ou les deux.
-
AWS DMS ne prend pas en charge les données LOB à moins qu'il s'agisse de données CLOB. AWS DMS convertit les données CLOB en une chaîne DynamoDB lors de la migration des données.
-
Lorsque vous utilisez DynamoDB comme cible, seule la table de contrôle Appliquer les exceptions (
dmslogs.awsdms_apply_exceptions) est prise en charge. Pour plus d'informations sur les tables de contrôle, consultez Paramètres de tâche de la table de contrôle. AWS DMS ne prend pas en charge le paramètre de tâche
TargetTablePrepMode=TRUNCATE_BEFORE_LOADpour DynamoDB en tant que cible.AWS DMS ne prend pas en charge le paramètre de tâche
TaskRecoveryTableEnabledpour DynamoDB en tant que cible.
Utilisation du mappage d'objet pour migrer les données vers DynamoDB
AWS DMS utilise les règles de mappage de tables pour mapper les données depuis la source vers la table DynamoDB cible. Pour mapper des données vers une cible DynamoDB, utilisez un type de règle de mappage de tables dénommé object-mapping. Le mappage d'objet vous permet de définir le nom des attributs et les données qui doivent être migrées vers ceux-ci. Des règles de sélection doivent être définies lorsque vous utilisez le mappage d'objet.
DynamoDB ne dispose pas d'une structure prédéfinie autre qu'une clé de partition et une clé de tri facultative. Si vous disposez d'une clé primaire non composite, AWS DMS l'utilise. Si vous avez une clé primaire composite ou si vous souhaitez utiliser une clé de tri, définissez ces clés et les autres attributs dans votre table DynamoDB cible.
Pour créer une règle de mappage d'objet, vous spécifiez le rule-type comme mappage d'objet. Cette règle spécifie le type de mappage d'objet que vous souhaitez utiliser.
La structure de la règle est la suivante :
{ "rules": [ { "rule-type": "object-mapping", "rule-id": "<id>", "rule-name": "<name>", "rule-action": "<valid object-mapping rule action>", "object-locator": { "schema-name": "<case-sensitive schema name>", "table-name": "" }, "target-table-name": "<table_name>" } ] }
AWS DMS prend actuellement en charge map-record-to-record et map-record-to-document comme les seules valeurs valides pour le paramètre rule-action. Ces valeurs spécifient l'action par défaut d'AWS DMS sur les enregistrements qui ne sont pas exclus de par leur appartenance à la liste des attributs exclude-columns. Ces valeurs n'affectent en aucune façon les mappages d'attributs.
-
Vous pouvez utiliser
map-record-to-recordlors de la migration d'une base de données relationnelle vers DynamoDB. La clé primaire est utilisée depuis la base de données relationnelle comme clé de partition dans DynamoDB et crée un attribut pour chaque colonne dans la base de données source. Lorsque vous utilisezmap-record-to-record, pour toute colonne de la table source non répertoriée dans la liste d'attributsexclude-columns, AWS DMS crée un attribut correspondant sur l'instance DynamoDB cible. Cet attribut est créé, que la colonne source soit ou non utilisée dans un mappage d'attribut. -
Vous utilisez
map-record-to-documentpour placer des colonnes sources dans un mappage DynamoDB unique et plat sur la cible, avec le nom d'attribut « _doc ». Lorsque vous utilisezmap-record-to-document, AWS DMS place les données dans un attribut de mappage DynamoDB unique et plat sur la source. Cet attribut est appelé « _doc ». Ce placement s'applique à toute colonne de la table source non listée dans la liste d'attributsexclude-columns.
Une des manières de comprendre la différence entre les paramètres rule-action map-record-to-record et map-record-to-document consiste à voir les deux paramètres en action. Dans cet exemple, imaginons que vous commencez avec une ligne de table d'une base de données relationnelle, présentant la structure et les données suivantes :
Pour migrer ces informations vers DynamoDB, vous créez des règles pour mapper les données dans un élément de la table DynamoDB. Notez les colonnes listées pour le paramètre exclude-columns. Ces colonnes ne sont pas directement mappées à la cible. Le mappage d'attribut est plutôt utilisé pour combiner les données en nouveaux éléments, comme par exemple lorsque FirstName et LastName sont regroupés pour former CustomerName dans la cible DynamoDB. NickName et income ne sont pas exclus.
{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "test", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "object-mapping", "rule-id": "2", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": { "schema-name": "test", "table-name": "customer" }, "target-table-name": "customer_t", "mapping-parameters": { "partition-key-name": "CustomerName", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ { "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "${FirstName},${LastName}" }, { "target-attribute-name": "ContactDetails", "attribute-type": "document", "attribute-sub-type": "dynamodb-map", "value": { "M": { "Home": { "M": { "Address": { "S": "${HomeAddress}" }, "Phone": { "S": "${HomePhone}" } } }, "Work": { "M": { "Address": { "S": "${WorkAddress}" }, "Phone": { "S": "${WorkPhone}" } } } } } } ] } } ] }
En utilisant le rule-action paramètre map-record-to-record, les données de NickName et income sont mappées à des éléments du même nom dans la cible DynamoDB.
Toutefois, supposons que vous utilisez les mêmes règles mais que vous remplacez le paramètre rule-action par map-record-to-document. Dans ce cas, les colonnes non répertoriées dans le paramètre exclude-columns, NickName et income, sont mappées à un élément _doc.
Utilisation d'expressions de condition personnalisées avec le mappage d'objet
Vous pouvez utiliser une fonctionnalité de DynamoDB nommée « expressions conditionnelles » pour manipuler les données qui sont écrites dans une table DynamoDB. Pour plus d'informations sur les expressions de condition dans DynamoDB, consultez Expressions de condition.
Une expression de condition est constituée des éléments suivants :
-
une expression (obligatoire)
-
des valeurs d'attributs d'expressions (facultatif). Spécifie une structure DynamoDB json de la valeur de l'attribut
-
des noms d'attributs d'expressions (facultatif)
-
options pour déterminer quand utiliser l'expression de condition (facultatif). La valeur par défaut est apply-during-cdc = false et apply-during-full-load = true
La structure de la règle est la suivante :
"target-table-name": "customer_t", "mapping-parameters": { "partition-key-name": "CustomerName", "condition-expression": { "expression":"<conditional expression>", "expression-attribute-values": [ { "name":"<attribute name>", "value":<attribute value> } ], "apply-during-cdc":<optional Boolean value>, "apply-during-full-load": <optional Boolean value> }
L'exemple suivant illustre les sections utilisées pour l'expression de condition.
Utilisation du mappage d'attribut avec le mappage d'objet
La mappage d'attribut vous permet de spécifier une chaîne modèle, en utilisant les noms de la colonne source pour restructurer les données sur la cible. Aucun formatage n'est effectué, autre que ce qui est spécifié par l'utilisateur dans le modèle.
L'exemple suivant illustre la structure de la base de données source et la structure de cible DynamoDB souhaitée. La structure de la source est illustrée en premier, dans ce cas, une base de données Oracle, puis la structure souhaitée des données dans DynamoDB. L'exemple se termine avec le JSON utilisé pour créer la structure cible souhaitée.
La structure des données Oracle est la suivante :
| FirstName | LastName | StoreId | HomeAddress | HomePhone | WorkAddress | WorkPhone | DateOfBirth |
|---|---|---|---|---|---|---|---|
| Clé primaire | N/A | ||||||
| Randy | Marsh | 5 | 221B Baker Street | 1234567890 | 31 Spooner Street, Quahog | 9876543210 | 02/29/1988 |
La structure des données DynamoDB est la suivante :
| CustomerName | StoreId | ContactDetails | DateOfBirth |
|---|---|---|---|
| Clé de partition | Clé de tri | N/A | |
|
|
|
|
Le JSON suivant illustre le mappage d'objet et le mappage de colonne utilisés pour parvenir à la structure DynamoDB :
{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "test", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "object-mapping", "rule-id": "2", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": { "schema-name": "test", "table-name": "customer" }, "target-table-name": "customer_t", "mapping-parameters": { "partition-key-name": "CustomerName", "sort-key-name": "StoreId", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ { "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "${FirstName},${LastName}" }, { "target-attribute-name": "StoreId", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "${StoreId}" }, { "target-attribute-name": "ContactDetails", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "{\"Name\":\"${FirstName}\",\"Home\":{\"Address\":\"${HomeAddress}\",\"Phone\":\"${HomePhone}\"}, \"Work\":{\"Address\":\"${WorkAddress}\",\"Phone\":\"${WorkPhone}\"}}" } ] } } ] }
Une autre façon d'utiliser le mappage de colonne consiste à utiliser le format DynamoDB comme type de document. L'exemple de code suivant utilise dynamodb-map comme attribute-sub-type pour la mappage d'attribut.
{ "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "test", "table-name": "%" }, "rule-action": "include" }, { "rule-type": "object-mapping", "rule-id": "2", "rule-name": "TransformToDDB", "rule-action": "map-record-to-record", "object-locator": { "schema-name": "test", "table-name": "customer" }, "target-table-name": "customer_t", "mapping-parameters": { "partition-key-name": "CustomerName", "sort-key-name": "StoreId", "exclude-columns": [ "FirstName", "LastName", "HomeAddress", "HomePhone", "WorkAddress", "WorkPhone" ], "attribute-mappings": [ { "target-attribute-name": "CustomerName", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "${FirstName},${LastName}" }, { "target-attribute-name": "StoreId", "attribute-type": "scalar", "attribute-sub-type": "string", "value": "${StoreId}" }, { "target-attribute-name": "ContactDetails", "attribute-type": "document", "attribute-sub-type": "dynamodb-map", "value": { "M": { "Name": { "S": "${FirstName}" }, "Home": { "M": { "Address": { "S": "${HomeAddress}" }, "Phone": { "S": "${HomePhone}" } } }, "Work": { "M": { "Address": { "S": "${WorkAddress}" }, "Phone": { "S": "${WorkPhone}" } } } } } } ] } } ] }
Au lieu d'utiliser dynamodb-map, vous pouvez utiliser dynamodb-list comme attribute-sub-type pour le mappage d'attribut, comme indiqué dans l'exemple suivant.
{ "target-attribute-name": "ContactDetailsList", "attribute-type": "document", "attribute-sub-type": "dynamodb-list", "value": { "L": [ { "N": "${FirstName}" }, { "N": "${HomeAddress}" }, { "N": "${HomePhone}" }, { "N": "${WorkAddress}" }, { "N": "${WorkPhone}" } ] } }
Exemple 1 : utilisation du mappage d'attribut avec le mappage d'objet
L'exemple suivant migre les données depuis deux tables de base de données MySQL, nfl_data et sport_team, vers deux tables DynamoDB dénommées NFLTeams et SportTeams. La structure des tables et le JSON utilisés pour mapper les données depuis les tables de base de données MySQL vers les tables DynamoDB sont les suivants :
La structure de la table de base de données MySQL nfl_data est indiquée ci-dessous :
mysql> desc nfl_data; +---------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------------+-------------+------+-----+---------+-------+ | Position | varchar(5) | YES | | NULL | | | player_number | smallint(6) | YES | | NULL | | | Name | varchar(40) | YES | | NULL | | | status | varchar(10) | YES | | NULL | | | stat1 | varchar(10) | YES | | NULL | | | stat1_val | varchar(10) | YES | | NULL | | | stat2 | varchar(10) | YES | | NULL | | | stat2_val | varchar(10) | YES | | NULL | | | stat3 | varchar(10) | YES | | NULL | | | stat3_val | varchar(10) | YES | | NULL | | | stat4 | varchar(10) | YES | | NULL | | | stat4_val | varchar(10) | YES | | NULL | | | team | varchar(10) | YES | | NULL | | +---------------+-------------+------+-----+---------+-------+
La structure de la table de base de données MySQL sport_team est indiquée ci-dessous :
mysql> desc sport_team; +---------------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------------------------+--------------+------+-----+---------+----------------+ | id | mediumint(9) | NO | PRI | NULL | auto_increment | | name | varchar(30) | NO | | NULL | | | abbreviated_name | varchar(10) | YES | | NULL | | | home_field_id | smallint(6) | YES | MUL | NULL | | | sport_type_name | varchar(15) | NO | MUL | NULL | | | sport_league_short_name | varchar(10) | NO | | NULL | | | sport_division_short_name | varchar(10) | YES | | NULL | |
Les règles de mappage de table utilisées pour mapper les deux tables vers les deux tables DynamoDB sont indiquées ci-dessous :
{ "rules":[ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "dms_sample", "table-name": "nfl_data" }, "rule-action": "include" }, { "rule-type": "selection", "rule-id": "2", "rule-name": "2", "object-locator": { "schema-name": "dms_sample", "table-name": "sport_team" }, "rule-action": "include" }, { "rule-type":"object-mapping", "rule-id":"3", "rule-name":"MapNFLData", "rule-action":"map-record-to-record", "object-locator":{ "schema-name":"dms_sample", "table-name":"nfl_data" }, "target-table-name":"NFLTeams", "mapping-parameters":{ "partition-key-name":"Team", "sort-key-name":"PlayerName", "exclude-columns": [ "player_number", "team", "name" ], "attribute-mappings":[ { "target-attribute-name":"Team", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"${team}" }, { "target-attribute-name":"PlayerName", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"${name}" }, { "target-attribute-name":"PlayerInfo", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"{\"Number\": \"${player_number}\",\"Position\": \"${Position}\",\"Status\": \"${status}\",\"Stats\": {\"Stat1\": \"${stat1}:${stat1_val}\",\"Stat2\": \"${stat2}:${stat2_val}\",\"Stat3\": \"${stat3}:${ stat3_val}\",\"Stat4\": \"${stat4}:${stat4_val}\"}" } ] } }, { "rule-type":"object-mapping", "rule-id":"4", "rule-name":"MapSportTeam", "rule-action":"map-record-to-record", "object-locator":{ "schema-name":"dms_sample", "table-name":"sport_team" }, "target-table-name":"SportTeams", "mapping-parameters":{ "partition-key-name":"TeamName", "exclude-columns": [ "name", "id" ], "attribute-mappings":[ { "target-attribute-name":"TeamName", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"${name}" }, { "target-attribute-name":"TeamInfo", "attribute-type":"scalar", "attribute-sub-type":"string", "value":"{\"League\": \"${sport_league_short_name}\",\"Division\": \"${sport_division_short_name}\"}" } ] } } ] }
L'exemple de sortie pour la table DynamoDB NFLTeams est indiqué ci-dessous :
"PlayerInfo": "{\"Number\": \"6\",\"Position\": \"P\",\"Status\": \"ACT\",\"Stats\": {\"Stat1\": \"PUNTS:73\",\"Stat2\": \"AVG:46\",\"Stat3\": \"LNG:67\",\"Stat4\": \"IN 20:31\"}", "PlayerName": "Allen, Ryan", "Position": "P", "stat1": "PUNTS", "stat1_val": "73", "stat2": "AVG", "stat2_val": "46", "stat3": "LNG", "stat3_val": "67", "stat4": "IN 20", "stat4_val": "31", "status": "ACT", "Team": "NE" }
L'exemple de sortie de la table SportsTeams DynamoDB est indiqué ci-dessous :
{ "abbreviated_name": "IND", "home_field_id": 53, "sport_division_short_name": "AFC South", "sport_league_short_name": "NFL", "sport_type_name": "football", "TeamInfo": "{\"League\": \"NFL\",\"Division\": \"AFC South\"}", "TeamName": "Indianapolis Colts" }
Types de données cibles pour DynamoDB
Le point de terminaison DynamoDB pour AWS DMS prend en charge la plupart des types de données DynamoDB. Le tableau suivant présente les types de données cibles Amazon AWS DMS qui sont pris en charge lorsque vous utilisez AWS DMS et le mappage par défaut à partir des types de données AWS DMS.
Pour de plus amples informations sur les types de données AWS DMS, veuillez consulter Types de données pour AWS Database Migration Service.
Lorsqu'AWS DMS migre des données depuis des bases de données hétérogènes, nous mappons les types de données depuis la base de données source vers les types de données intermédiaires, dénommés types de données AWS DMS. Nous mappons ensuite les types de données intermédiaires vers les types de données cibles. Le tableau suivant illustre chaque type de données AWS DMS et le type de données qu'il mappe dans DynamoDB :
| Type de données AWS DMS | Type de données DynamoDB |
|---|---|
|
Chaîne |
Chaîne |
|
WString |
Chaîne |
|
Booléen |
Booléen |
|
Date |
Chaîne |
|
DateTime |
Chaîne |
|
INT1 |
Nombre |
|
INT2 |
Nombre |
|
INT4 |
Nombre |
|
INT8 |
Nombre |
|
Numérique |
Nombre |
|
Real4 |
Nombre |
|
Real8 |
Nombre |
|
UINT1 |
Nombre |
|
UINT2 |
Nombre |
|
UINT4 |
Nombre |
| UINT8 | Nombre |
| CLOB | Chaîne |
