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.

Durée du module : 20 minutes


  • Étape 1 : créer le diagramme entité-association

    Dans tout processus de modélisation des données, la première étape consiste à créer un diagramme pour montrer les entités formant votre application et les relations qui existent entre elles.

    Notre application comprend les entités ci-dessous :
    • Utilisateur
    • Jeu
    • UserGameMapping

    Une entité utilisateur désigne un utilisateur dans notre application. Un utilisateur peut créer plusieurs entités jeu, et le créateur d’un jeu détermine la carte qui est jouée et quand le jeu démarre. Un utilisateur peut créer plusieurs entités jeu. Il existe ainsi relation de un à plusieurs entre utilisateurs et jeux.

    Pour finir, un jeu comporte plusieurs utilisateurs, et un utilisateur peut jouer dans une multiplicité de jeux différents au fil du temps. Par conséquent, il existe une relation de plusieurs à plusieurs entre utilisateurs et jeux. Nous pouvons représenter ces relations avec l’entité UserGameMapping.

    Sur la base de ces entités et de ces relations, nous illustrons ci-dessous notre diagramme entité-association.

    (Cliquer pour agrandir)

  • Étape 2 : examiner les modèles d’accès aux profils utilisateurs

     Les utilisateurs de notre jeu doivent créer leurs profils utilisateurs. Il s’agit de données telles que le nom d’utilisateur, l’avatar, les statistiques de jeu et d’autres informations concernant chaque utilisateur. Le jeu affiche ces profils utilisateurs lors de la connexion d’un utilisateur. D’autres utilisateurs peuvent voir le profil d’un utilisateur donné à des fins de comparaison de leurs statistiques de jeu et d’autres détails.

    Au fur et à mesure qu’un utilisateur joue à des jeux, les statistiques de jeu sont mises à jour afin de refléter le nombre de jeux joués, le nombre de jeux gagnés et le nombre d’éliminations réussies par cet utilisateur.

    Sur la base de ces informations, nous disposons des trois modèles d’accès ci-dessous :

    •  Créer un profil utilisateur (Écriture)
    •  Actualiser un profil utilisateur (Écriture)
    • Obtenir un profil utilisateur (Lecture)
  • Étape 3 : examiner les modèles d’accès préjeu

    Notre jeu est de type « battle royale ». Les joueurs peuvent créer un jeu sur une carte donnée, et d’autres joueurs peuvent rejoindre le jeu en question. Lorsque 50 joueurs ont rejoint le jeu, il démarre et plus aucun autre joueur ne peut être admis à le rejoindre.

    Lorsque des joueurs cherchent des jeux à rejoindre, ils peuvent souhaiter jouer une carte en particulier. D’autres joueurs se soucient peu de la carte, et recherchent des jeux ouverts sur toutes les cartes.

    Sur la base de ces informations, nous disposons des sept modèles d’accès ci-dessous :

    • Créer un jeu (Écriture)
    • Rechercher les jeux ouverts (Lecture)
    • Rechercher les jeux ouverts par carte (Lecture)
    • Afficher un jeu (Lecture)
    • Afficher les utilisateurs d’un jeu (Lecture)
    • Rejoindre un jeu pour un utilisateur (Écriture)
    • Démarrer un jeu (Écriture)
  • Étape 4 : modèles d’accès pendant et après le jeu

    Pour finir, examinons les modèles d’accès pendant et après un jeu.

    Pendant le jeu, chaque joueur essaie d’infliger une défaite aux autres joueurs afin d’être le dernier survivant. Notre application effectue le suivi du nombre d’éliminations effectuées par chaque joueur pendant un jeu, ainsi que le temps de survie d’un joueur dans un jeu. Si un joueur est parmi les trois derniers survivants dans un jeu, il reçoit une médaille d’or, d’argent ou de bronze pour le jeu en question.

    Plus tard, les joueurs peuvent souhaiter passer en revue les jeux qu’eux ou d’autres ont joués précédemment.

    Sur la base de ces informations, nous disposons des trois modèles d’accès ci-dessous :

    • Actualiser un jeu pour un utilisateur (Écriture)
    • Actualiser un jeu (Écriture)
    • Rechercher tous les jeux précédents pour un utilisateur (Lecture)

    Nous avons à présent établi tous les modèles d’accès pour le jeu. Dans les prochains modules, nous allons implémenter ces modèles d’accès à l’aide de DynamoDB.

    Veuillez noter que la phase de planification peut nécessiter quelques itérations. Commencez par vous faire une idée générale des modèles d’accès dont votre application a besoin. Définissez la clé principale, les index secondaires et les attributs dans votre table. Retournez à la case départ pour vous assurer de la conformité de tous vos modèles d’accès. Lorsque vous avez la certitude que la phase de planification est achevée, passez à celle d’implémentation.