Modélisation des données des joueurs d'un jeu avec Amazon DynamoDB

La modélisation des données est un processus visant à concevoir la manière dont une application stocke des données dans une base de données. La modélisation des données avec une base de données NoSQL, par exemple DynamoDB, diffère de celle avec une base de données relationnelle. Une base de données relationnelle est conçue pour être flexible ; elle peut être parfaitement adaptée pour les applications d’analyse. Dans la modélisation des données relationnelles, vous commencez par vos entités. Avec un modèle relationnel normalisé, vous pouvez satisfaire à n’importe quel modèle de requête dont vous avez besoin dans votre application.

Les bases de données NoSQL (non relationnelles) sont conçues pour offrir vitesse et échelle, sans flexibilité. Les performances de votre base de données relationnelle peuvent décroître au fur et à mesure que vous montez en échelle. Cependant, la mise à l’échelle horizontale des bases de données, par exemple DynamoDB, fournit des performances homogènes à n’importe quelle échelle. Certains utilisateurs de DynamoDB possèdent des tables de plus de 100 To, et leurs performances en lecture et en écriture sont identiques à celles de tables d’une taille inférieure à 1 Go.

Pour obtenir des résultats optimaux avec une base de données NoSQL, par exemple DynamoDB, vous devez changer de mentalité en ce qui concerne les bases de données relationnelles typiques. Utilisez les bonnes pratiques ci-dessous lors de la modélisation des données avec DynamoDB.

1. Mettez l’accent sur les modèles d’accès.
Quel que soit le type de modélisation des données que vous effectuez, vous devrez commencer par un diagramme entité-association (ERD) qui décrit les différents objets ou entités contenus dans votre application, ainsi que leurs interconnexions (ou les relations qui existent entre ces entités).

Dans les bases de données relationnelles, vous insérez directement vos entités dans les tables et spécifiez les relations en utilisant des clés étrangères. Une fois que vous avez défini vos tables de données, une base de données relationnelle fournit un langage de requêtes flexible permettant de renvoyer les données dans le format désiré.

Dans DynamoDB, vous devez penser aux modèles d’accès avant de démarrer la modélisation de votre table. Les bases de données NoSQL mettent l’accent sur la vitesse, et non la flexibilité. Vous devez d’abord vous demander comment vous accéderez à vos données, avant de les modéliser au format dans lequel vous y accéderez.

Avant de concevoir votre table DynamoDB, vous devez documenter toutes les exigences en lecture et en écriture des données de votre application. Soyez rigoureux et pensez à tous les flux présents dans votre application, car vous allez optimiser votre table pour vos modèles d’accès.

2. Optimisez le nombre de requêtes adressées à DynamoDB.
Une fois que vous avez documenté les exigences en termes de modèles d’accès de votre application, vous êtes prêt pour concevoir votre table. Vous devez concevoir votre table de manière à minimiser le nombre de requêtes adressées à DynamoDB pour chaque modèle d’accès. Dans l’idéal, chaque modèle d’accès ne doit nécessiter qu’une seule requête vers DynamoDB, en raison de la lenteur des requêtes réseau, ce qui limite le nombre de requêtes réseau que vous allez effectuer dans votre application.

Pour optimiser le nombre de requêtes adressées à DynamoDB, vous devez au préalable maîtriser quelques concepts de base :

● Clés principales
● Index secondaires
● Transactions

3. Ne simulez pas un modèle relationnel.
Les débutants sur DynamoDB essaient parfois d’implémenter un modèle relationnel conjointement à une base de données DynamoDB non relationnelle. Si vous tentez cette approche, vous perdrez tous les avantages de DynamoDB.

Les anti-modèles les plus courants (réponses inefficaces aux problèmes récurrents) avec DynamoDB sont répertoriés ci-dessous.

•  Normalisation : dans une base de données relationnelle, vous normalisez vos données pour réduire la redondance des données et l’espace de stockage, puis vous utilisez des jointures pour combiner différentes tables. Cependant, à grande échelle, les jointures sont lentes et onéreuses. DynamoDB n’autorise pas les jointures, car elles deviennent lentes au fil de la croissance de votre table.
• Un type de donnée par table : votre table DynamoDB peut parfois comporter différents types de données dans une seule et même table. Dans notre exemple, nous avons les entités Utilisateur, Jeu et UserGameMapping dans une table unique. Dans une base de données relationnelle, toutes ces entités seraient modélisées sous forme de trois tables différentes.
• Excès d’index secondaires : les gens essaient parfois de créer un index secondaire pour chaque modèle d’accès supplémentaire dont ils ont besoin. DynamoDB utilise une approche sans schéma, qui s’applique également à vos index. Tirez parti de la flexibilité de vos attributs pour réutiliser un index secondaire unique sur plusieurs types de données dans votre table. Cette démarche s’appelle surcharge d’index.

Dans les étapes ci-dessous, nous allons construire notre diagramme entité-association et définir à l’avance nos modèles d’accès. Ces étapes constituent des préliminaires absolus à votre utilisation de DynamoDB. Ensuite, dans les modules suivants, nous allons implémenter ces modèles d’accès lors de la conception de la table.