De la base de données relationnelle à l’architecture monotable avec DynamoDB
Amazon DynamoDB est une base de données NoSQL hautement performante imaginée par Werner Vogel (CTO d’Amazon). Cette base fournit un stockage de données pour de nombreuses applications. Contrairement aux bases de données SQL traditionnelles, ce service n’utilise pas de jointures de tables. Ce qui vous pousse à repenser l’enregistrement de vos entités. Nous parlons alors de design en « single table » ou monotable.
La modélisation des données avec DynamoDB peut être délicate pour ceux qui sont habitués aux bases de données relationnelles. Voyons ensemble en quoi consiste une architecture de base de données monotable, les étapes à suivre pour en créer une, ses avantages, et ses inconvénients.
Définition : qu’est-ce qu’une architecture de base de données monotable ?
La conception monotable est une technique de modélisation des données utilisée pour représenter des structures de données relationnelles dans une table NoSQL unique.
Il s’agit d’organiser toutes vos données de manière intelligente dans une seule table (et non plus dans une table par entité !) et d’utiliser une primary key, une sort key et des index pour relier les entités entre elles et y accéder de manière rapide et efficace.
Comment concevoir une architecture de base de données monotable ?
La planification est essentielle dans ce type de conception. Vous devez savoir quelles sont vos données, comment elles sont liées les unes aux autres et, plus important encore, quels sont vos modèles d’accès (design pattern) – ils dictent comment vous devez organiser vos éléments.
Voici les étapes à suivre pour en créer une :
1. Créer les ERD (Entity / Relationship Diagram)
2. Déterminer les modèles d’accès (design pattern)
3. Définir les structures des clés (leading keys)
4. Définir les index physiques (primary key, sort key, GSI/LSI)
5. Définir les stratégies de conception clés
6. Définir les stratégies de relation d’entité utiles
Pour comprendre ce concept, examinons certaines modélisations dans des bases de données relationnelles, puis voyons ensemble pourquoi vous devez modéliser différemment dans DynamoDB.
Contexte de la modélisation SQL et des jointures
Avec les bases de données relationnelles, vous normalisez généralement vos données en créant une table pour chaque type d’entité dans votre application. Par exemple, si vous créez une application pour de la vente en ligne, vous aurez une table pour les clients et une table pour les commandes.
Chaque commande appartient à un certain client et vous utilisez des clés étrangères pour faire référence d’un enregistrement dans une table à un enregistrement dans une autre. Ces clés étrangères agissent comme des pointeurs – si j’ai besoin de plus d’informations sur un client qui a passé une commande particulière, je peux suivre la référence de clé étrangère pour récupérer des éléments sur le client.
Pour suivre ces pointeurs, le langage SQL d’interrogation des bases de données relationnelles a un concept de jointures. Les jointures vous permettent de combiner des enregistrements de deux tables ou plus au moment de la lecture.
Le problème des jointures manquantes dans DynamoDB
Bien que pratiques, les jointures SQL sont également coûteuses. Elles nécessitent :
– d’analyser de grandes portions de plusieurs tables de votre base de données relationnelle,
– de comparer différentes valeurs et de renvoyer un ensemble de résultats.
Les jointures en SQL sont limitées et peu scalables. Plus le volume de datas est grand, plus la performance diminue. DynamoDB contourne le problème en supprimant la possibilité de les utiliser.
Dans notre exemple ci-dessous, nous souhaitons obtenir à la fois un enregistrement client et toutes les commandes du client. Dans ce cas, de nombreux développeurs appliqueront des modèles de conception relationnels avec DynamoDB même s’ils ne disposent pas des outils relationnels tels que les jointures. Et comme il n’y a pas de jointures, ils devront effectuer plusieurs requêtes pour récupérer à la fois les commandes et l’enregistrement client.
Cela peut poser d’importants problèmes dans votre application, car, ainsi, vous effectuerez plusieurs requêtes en cascade. Au fur et à mesure que votre application évoluera, elle pourrait perdre en performance, en devenant de plus en plus lente.
La solution : regroupez vos données dans des collections grâce aux clés composites
Alors, comment obtenir des performances rapides et cohérentes de DynamoDB sans faire plusieurs requêtes à votre base de données ? En regroupant vos données à l’aide de collections d’éléments.
Une collection d’éléments dans DynamoDB fait référence à tous les éléments d’une table ou d’un index qui partagent une clé de partition. Dans l’exemple ci-dessous, nous avons une table DynamoDB qui contient les acteurs et les films dans lesquels ils ont joué.
La clé de partition est le nom de l’acteur, et la clé de tri est le nom du film.
Vous pouvez voir qu’il y a deux articles pour “Tom Hanks” – “Cast Away” et “Toy Story”. Comme ils ont la même clé de partition “Tom Hanks”, ils se trouvent dans la même collection d’éléments.
Vous pouvez utiliser l’API de DynamoDB “Query” pour lire plusieurs éléments avec la même clé de partition. Ainsi, si vous avez besoin de récupérer plusieurs éléments hétérogènes dans une seule requête, vous organisez ces éléments de sorte qu’ils se trouvent dans la même collection d’éléments.
Dans le cas d’une application de vente en ligne, la clé de partition est le nom de l’utilisateur et la clé de tri est l’enregistrement de la commande. Pour que cela soit possible en une seule requête, nous nous assurons que tous les enregistrements de commande existent dans la même collection que l’enregistrement d’utilisateur auquel ils appartiennent.
Désormais, lorsque nous voulons récupérer l’utilisateur et les commandes, nous pouvons le faire en une seule requête sans avoir besoin d’une opération de jointure coûteuse :
C’est la raison d’être de la conception monotable : organiser votre table afin que vos modèles d’accès puissent être gérés avec le moins de requêtes possible à DynamoDB, idéalement une.
Les avantages de la conception en monotable
Ce type d’architecture en monotable vous permet :
- d’accéder aux données + rapidement, en une ou deux requêtes.
- de minimiser le nombre de tables que vous devez gérer.
- d’éviter des surcoûts opérationnels (monitoring, backup etc …) comme on peut le constater dans un design classique comprenant plusieurs tables.
- de réaliser des économies : si vous avez un ou deux types d’entités dans votre monotable qui sont consultés beaucoup plus fréquemment que les autres, vous pouvez masquer une partie de la capacité supplémentaire pour les éléments moins fréquemment consultés dans la mémoire tampon des autres éléments.
- de profiter d’une mise à l’échelle quasi infinie grâce à DynamoDB.
- d’améliorer les performances de votre solution en effectuant une seule demande pour récupérer tous les éléments nécessaires.
Inconvénients d’une conception monotable
Il y a trois inconvénients à la conception monotable dans DynamoDB :
La courbe d’apprentissage abrupte de la conception monotable
Une seule table DynamoDB surchargée peut sembler vraiment étrange à première vue par rapport aux tables propres et normalisées de votre base de données relationnelle. Il est difficile de désapprendre toutes les leçons que vous avez apprises au fil des années de la modélisation de données relationnelles.
L‘inflexibilité d’ajouter de nouveaux modèles d’accès (access pattern)
Une deuxième difficulté concernant DynamoDB est celle d’adapter de nouveaux modèles d’accès dans une conception monotable. Lors de la modélisation d’une conception à monotable dans DynamoDB, vous commencez par vos modèles d’accès. Réfléchissez bien : comment accéderez-vous à vos données ? Puis modélisez soigneusement votre table pour satisfaire ces modèles d’accès. Vous organisez vos éléments en collections de sorte que chaque modèle d’accès puisse être traité avec le moins de requêtes possible, idéalement une seule requête.
La difficulté d‘exporter vos tables pour l’analyse
DynamoDB est conçu pour les cas d’utilisation OLTP — accès aux données à grande vitesse où vous travaillez sur quelques enregistrements à la fois. Mais les utilisateurs ont également besoin de modèles d’accès OLAP – de grandes requêtes analytiques sur l’ensemble de données pour trouver des éléments populaires, ou le nombre de commandes par jour, ou d’autres informations.
DynamoDB n’est pas bon pour les requêtes OLAP. C’est intentionnel. DynamoDB se concentre sur l’ultra-performance des requêtes OLTP et souhaite que vous utilisiez d’autres bases de données spécialement conçues pour OLAP. Pour ce faire, vous devrez transférer vos données de DynamoDB vers un autre système, par exemple en utilisant des DynamodbStream pour mettre la donnée dans S3 (requêtes ensuite via Athena) ou elasticsearch.
Si vous avez une conception monotable, il peut être difficile de la mettre au format approprié pour un système d’analyse (OLAP).
Conclusion
L’architecture de base de données monotable va de pair avec DynamoDB. Nous vous la conseillons si vous gérez un grand volume de datas sur lesquelles vous devez accédez très rapidement. Au-delà d’une dizaine d’entités, cela peut vous être grandement utile. En-deçà, attention, vous risquez de mettre en place une usine à gaz pour pas grand chose.
Nous vous conseillons également de la mettre en place à l’initialisation du projet sur tout ou une partie de votre application. Exemple : il est parfaitement possible de développer du monotable sur la partie panier d’un e-commerce, et d’utiliser des bases de données relationnelles sur tout le reste.
D’où l’importance de bien planifier la conception de ce type d’architecture de BDD avant de s’y lancer.
En suivant toutes ces informations, vous pouvez désormais créer votre bases de données monotable sur DynamoDB. Une fois que vous aurez modélisé votre table, vous la mettrez en action et écrirez le code pour l’implémenter. Votre application pourra ainsi évoluer à l’infini sans dégradation des performances.
Si vous souhaitez être conseillé et accompagné sur ce sujet, n’hésitez pas à contacter l’équipe de Premaccess. Experts AWS, ils vous accompagneront pas à pas dans la réalisation de ce projet.
Sources utilisées pour la rédaction de cet article :
- https://aws.amazon.com/fr/blogs/compute/creating-a-single-table-design-with-amazon-dynamodb/
- https://www.alexdebrie.com/posts/dynamodb-single-table/
- https://www.trek10.com/blog/dynamodb-single-table-relational-modeling
- https://dynobase.dev/dynamodb-single-table-design/
- https://fullstackdeveloper.tips/so-how-do-you-start-with-dynamodb/
- https://www.sensedeep.com/blog/posts/2021/dynamodb-singletable-design.html
