Tables, éléments et clés primaires

Amazon DynamoDB est une base de données clé-valeur et documentaire entièrement gérée et sans serveur, conçue pour offrir des performances de l’ordre de quelques millisecondes, quelle que soit l’échelle. Contrairement aux bases de données relationnelles, DynamoDB est sans schéma : chaque élément peut posséder un ensemble d’attributs différent, à condition que la clé primaire soit présente.

DynamoDB stocke les données dans des tables, qui constituent le conteneur de niveau supérieur analogue à une table SQL. Les tables sont automatiquement réparties entre plusieurs nœuds de stockage situés dans différentes AZ, ce qui fournit une redondance intégrée sans nécessiter de configuration de votre part.

Une table DynamoDB contient une collection d’éléments, chacun étant une collection d’attributs. Les attributs sont des valeurs typées : chaîne (S), nombre (N), binaire (B), booléen (BOOL), valeur nulle (NULL), liste (L), mappage (M) et ensembles (SS, NS, BS).

Chaque élément d’une table doit inclure les attributs de la clé primaire ; tous les autres attributs sont facultatifs et peuvent différer d’un élément à l’autre. La taille maximale d’un élément est de 400 KB, en incluant tous ses noms et valeurs d’attributs.

Une clé primaire simple se compose d’un seul attribut appelé clé de partition (également appelée clé de hachage). DynamoDB applique une fonction de hachage interne à la valeur de la clé de partition afin de déterminer quelle partition de stockage contient l’élément. Tous les éléments ayant la même valeur de clé de partition sont stockés ensemble.

Avec une clé primaire simple, aucun élément de la table ne peut avoir la même valeur de clé de partition qu’un autre : cette valeur identifie chaque élément de manière unique. Cette conception convient aux tables dans lesquelles vous accédez toujours aux données à l’aide d’un identifiant unique, comme un ID utilisateur ou un ID de commande.

Une clé primaire composite utilise à la fois une clé de partition et une clé de tri (également appelée clé de plage). Les éléments ayant la même clé de partition sont stockés ensemble et triés selon la valeur de la clé de tri, ce qui permet d’effectuer des requêtes par plage au sein d’une partition.

Cette conception est extrêmement flexible : plusieurs éléments peuvent partager la même clé de partition, à condition que leurs clés de tri soient différentes. Par exemple, une table Orders peut utiliser CustomerId comme clé de partition et OrderDate comme clé de tri, ce qui vous permet d’interroger toutes les commandes d’un client, triées par date.

Le choix de la clé de partition appropriée est la décision de conception la plus importante dans DynamoDB. Une bonne clé de partition présente une forte cardinalité (de nombreuses valeurs distinctes) et répartit les accès uniformément entre les partitions. Les mauvais choix entraînent des partitions surchargées, dans lesquelles une partition reçoit une part disproportionnée du trafic, ce qui provoque une limitation de débit.

Modèles à éviter : utiliser un indicateur booléen (seulement deux valeurs), une date qui regroupe toutes les écritures du jour ou un champ d’état à faible cardinalité. Bons choix : ID utilisateur, ID d’appareil, UUID aléatoire ou valeurs composites telles que tenantId#entityType.

Les trois opérations fondamentales de DynamoDB sur les éléments sont les suivantes :

• PutItem : écrit un nouvel élément ou remplace complètement un élément existant ayant la même clé primaire
• GetItem : récupère un seul élément à partir de sa clé primaire exacte (la clé complète est requise : clé de partition et, si elle est composite, clé de tri)
• DeleteItem : supprime un élément à partir de sa clé primaire exacte

Ces trois opérations sont atomiques au niveau de l’élément. Par défaut, GetItem utilise des lectures à cohérence éventuelle ; l’ajout de --consistent-read force une lecture fortement cohérente qui renvoie toujours la dernière valeur écrite.

UpdateItem modifie certains attributs d’un élément existant sans le remplacer entièrement, contrairement à PutItem. Vous pouvez ajouter ou supprimer des attributs, ou effectuer atomiquement des opérations arithmétiques sur des attributs Number (par exemple, incrémenter un compteur).

Les expressions conditionnelles vous permettent de spécifier qu’une opération ne doit réussir que si une condition est vraie. Par exemple, vous pouvez mettre à jour l’état d’un élément uniquement s’il est actuellement PENDING. Cela permet d’implémenter des mécanismes de verrouillage optimiste sans transactions et constitue une technique de conception essentielle pour DynamoDB.

Query récupère les éléments qui partagent la même valeur de clé de partition, avec la possibilité d’appliquer des conditions sur la clé de tri. Query est efficace : l’opération ne lit que la partition ciblée. Vous pouvez utiliser des conditions sur la clé de tri telles que begins_with, between, =, < et > pour affiner les résultats au sein de la partition.

Scan lit chaque élément de la table, puis applique éventuellement une expression de filtrage. Les opérations Scan sont coûteuses sur les grandes tables et doivent être évitées dans les modèles de requêtes en production. Si vous constatez que vous devez effectuer fréquemment des opérations Scan, revoyez la conception de votre table ou ajoutez un index secondaire global.

DynamoDB stocke trois copies de vos données dans plusieurs zones de disponibilité (AZ). Les lectures à cohérence éventuelle (par défaut) peuvent renvoyer une valeur légèrement obsolète si une écriture récente ne s’est pas encore propagée à toutes les copies, mais elles consomment la moitié des unités de capacité de lecture des lectures à cohérence forte.

Les lectures à cohérence forte renvoient toujours la dernière écriture validée, mais coûtent deux fois plus de RCU et ne sont pas disponibles sur les Global Secondary Indexes. Choisissez les lectures à cohérence éventuelle pour les charges de travail à haut débit et principalement orientées lecture, et les lectures à cohérence forte uniquement lorsque votre application nécessite les données les plus récentes.

DynamoDB prend en charge les transactions ACID via TransactWriteItems et TransactGetItems. Une transaction peut regrouper jusqu’à 100 opérations d’écriture sur plusieurs éléments, voire plusieurs tables, en garantissant que toutes réussissent ou que toutes soient annulées de manière atomique.

Utilisez les transactions dans des scénarios tels que le transfert d’argent entre comptes (débiter un élément et en créditer un autre) ou la réservation d’une place (vérifier sa disponibilité et la réserver de manière atomique). Les transactions coûtent deux fois plus de RCU/WCU que les opérations normales ; utilisez-les donc uniquement lorsqu’une atomicité entre plusieurs éléments est réellement nécessaire.

La limite de 400 Ko par élément de DynamoDB influence la modélisation des données. Pour les charges utiles volumineuses (par exemple, des images ou de gros documents), stockez les données binaires dans S3 et uniquement la clé de l’objet S3 dans DynamoDB. Pour les données hiérarchiques profondément imbriquées, modélisez chaque type de nœud avec son propre modèle de clé de partition en utilisant une conception à table unique : une seule table contient plusieurs types d’entités, différenciés par le préfixe de la clé de partition et le modèle de clé de tri.

La conception à table unique réduit le nombre de tables et permet des modes d’accès efficaces en regroupant les éléments associés dans la même partition. Il s’agit d’une technique avancée qui réduit la charge opérationnelle et améliore les performances pour les modes d’accès complexes.

Dans cette leçon, vous avez appris que les tables DynamoDB contiennent des éléments sans schéma limités à 400 Ko, que les clés primaires simples utilisent uniquement une clé de partition, tandis que les clés composites ajoutent une clé de tri pour les requêtes par plage, et que les clés de partition à forte cardinalité évitent les partitions surchargées. Utilisez Query plutôt que Scan pour accéder efficacement aux données. Nous allons ensuite étudier les modes de capacité provisionnée et à la demande.