Versionner les sources de données DynamoDB dans AWS AppSync

AWS AppSync prend actuellement en charge le versionnement sur les sources de données DynamoDB. Les opérations de détection de conflits, de résolution de conflits et de synchronisation nécessitent une source de données Versioned. Lorsque vous activez le contrôle de version sur une source de données, AWS AppSync cela va automatiquement :

• Améliorer les éléments avec les métadonnées de gestion des versions d'objets.

• Enregistrez les modifications apportées aux éléments avec AWS AppSync des mutations dans une table Delta.

• Conservez les éléments supprimés dans la table Base avec une « désactivation » pendant une durée configurable.

Configuration de source de données versionnée

Lorsque vous activez le contrôle de version sur une source de données DynamoDB, vous spécifiez les champs suivants :

BaseTableTTL

Nombre de minutes pour conserver les éléments supprimés dans la table Base avec une « désactivation » - champ de métadonnées indiquant que l'élément a été supprimé. Vous pouvez définir cette valeur sur 0 si vous souhaitez que les éléments soient retirés immédiatement lorsqu'ils sont supprimés. Ce champ est obligatoire.

DeltaSyncTableName

Nom de la table dans laquelle les modifications apportées aux éléments comportant AWS AppSync des mutations sont stockées. Ce champ est obligatoire.

DeltaSyncTableTTL

Nombre de minutes pour conserver les éléments dans la table Delta. Ce champ est obligatoire.

Enregistrement des tables de synchronisation Delta

AWS AppSync prend actuellement en charge la journalisation Delta Sync pour les mutations utilisant PutItemUpdateItem, et les opérations DeleteItem DynamoDB.

Lorsqu'une AWS AppSync mutation modifie un élément dans une source de données versionnée, un enregistrement de cette modification est stocké dans une table Delta optimisée pour les mises à jour incrémentielles. Vous pouvez choisir d'utiliser différentes tables Delta (par exemple, une par type, une par domaine) pour les autres sources de données versionnées ou une seule table Delta pour votre API. AWS AppSync recommande de ne pas utiliser une seule table Delta pour plusieurs APIs afin d'éviter la collision des clés primaires.

Le schéma requis pour cette table est le suivant :

ds_pk

Valeur de chaîne utilisée comme clé de partition. Il est construit en concaténant le nom de la source de données de base et le format ISO 8601 de la date à laquelle le changement s'est produit (par exemple). Comments:2019-01-01

Lorsque l'customPartitionKeyindicateur du modèle de mappage VTL est défini comme nom de colonne de la clé de partition (voir la référence du modèle de mappage Resolver pour DynamoDB dans le guide du AWS AppSync développeur), le format des ds_pk modifications et la chaîne est construite en y ajoutant la valeur de la clé de partition dans le nouvel enregistrement de la table de base. Par exemple, si l'enregistrement de la table de base possède une valeur de clé de partition 1a et une valeur de clé de tri de2b, la nouvelle valeur de la chaîne sera :Comments:2019-01-01:1a.

ds_sk

Valeur de chaîne utilisée comme clé de tri. Il est construit en concaténant le format ISO 8601 du moment où le changement s'est produit, la clé primaire de l'élément et la version de l'élément. La combinaison de ces champs garantit l'unicité de chaque entrée de la table Delta (par exemple, pour une heure, un identifiant 1a et une version de2, ce serait le cas09:30:00:1a:2). 09:30:00

Lorsque l'customPartitionKeyindicateur du modèle de mappage VTL est défini sur le nom de colonne de la clé de partition (voir la référence du modèle de mappage Resolver pour DynamoDB dans le guide du AWS AppSync développeur), le format des ds_sk modifications et la chaîne sont construits en remplaçant la valeur de la clé de combinaison par la valeur de la clé de tri dans la table de base. En utilisant l'exemple précédent ci-dessus, si l'enregistrement de la table de base a une valeur de clé de partition 1a et une valeur de clé de tri de2b, la nouvelle valeur de la chaîne sera :09:30:00:2b:3.

_ttl

Valeur numérique qui stocke l'horodatage, en secondes d'époque, lorsqu'un élément doit être supprimé de la table Delta. Cette valeur est déterminée en ajoutant la valeur DeltaSyncTableTTL configurée sur la source de données au moment où la modification s'est produite. Ce champ doit être configuré comme Attribut TTL DynamoDB.

Le rôle IAM configuré pour être utilisé avec la table Base doit également contenir l'autorisation d'opérer sur la table Delta. Dans cet exemple, la stratégie d'autorisations d'une table Base appelée Comments et d'une table Delta appelée ChangeLog s'affiche :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DeleteItem",
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:Query",
                "dynamodb:Scan",
                "dynamodb:UpdateItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-east-1:000000000000:table/Comments",
                "arn:aws:dynamodb:us-east-1:000000000000:table/Comments/*",
                "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog",
                "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog/*"
            ]
        }
    ]
}

Métadonnées de source de données versionnées

AWS AppSync gère les champs de métadonnées Versioned des sources de données en votre nom. La modification de ces champs vous-même peut entraîner des erreurs dans votre application ou une perte de données. Ces champs comprennent :

_version

Compteur à augmentation monotone qui est mis à jour chaque fois qu'un changement se produit sur un élément.

_lastChangedAt

Valeur numérique qui stocke l'horodatage, en millisecondes Epoch, lors de la dernière modification d'un élément.

_deleted

Valeur booléenne de désactivation qui indique qu'un élément a été supprimé. Cela peut être utilisé par les applications pour expulser les éléments supprimés des magasins de données locaux.

_ttl

Valeur numérique qui stocke l'horodatage, en secondes Epoch, lorsqu'un élément doit être supprimé de la source de données sous-jacente.

ds_pk

Valeur de chaîne utilisée comme clé de partition pour les tables Delta.

ds_sk

Valeur de chaîne utilisée comme clé de tri pour les tables Delta.

gsi_ds_pk

Attribut de valeur de chaîne généré pour prendre en charge un index secondaire global en tant que clé de partition. Il ne sera inclus que si les populateIndexFields indicateurs customPartitionKey et sont activés dans le modèle de mappage VTL (voir la référence du modèle de mappage Resolver pour DynamoDB dans le guide du développeur).AWS AppSync Si cette option est activée, la valeur sera construite en concaténant le nom de la source de données de base et le format ISO 8601 de la date à laquelle le changement s'est produit (par exemple, si la table de base est nommée Commentaires, cet enregistrement sera défini comme). Comments:2019-01-01

gsi_ds_sk

Attribut de valeur de chaîne généré pour prendre en charge un index secondaire global en tant que clé de tri. Il ne sera inclus que si les populateIndexFields indicateurs customPartitionKey et sont activés dans le modèle de mappage VTL (voir la référence du modèle de mappage Resolver pour DynamoDB dans le guide du développeur).AWS AppSync Si cette option est activée, la valeur sera construite en concaténant le format ISO 8601 du moment où le changement s'est produit, la clé de partition de l'élément de la table de base, la clé de tri de l'élément de la table de base et la version de l'élément (par exemple, pour une durée de, une valeur de clé de partition de09:30:00, une valeur de 1a clé de tri et une version de 2b3, ce serait le cas). 09:30:00:1a#2b:3

Ces champs de métadonnées auront un impact sur la taille globale des éléments de la source de données sous-jacente. AWS AppSync recommande de réserver une taille de stockage de 500 octets ou plus pour la clé primaire maximale pour les métadonnées des sources de données versionnées lors de la conception de votre application. Pour utiliser ces métadonnées dans les applications clientes, incluez les champs _version, _lastChangedAt et _deleted sur vos types GraphQL et dans le jeu de sélection pour les mutations.