Conception NoSQL pour DynamoDB - Amazon DynamoDB

Conception NoSQL pour DynamoDB

Les systèmes de base de données NoSQL comme Amazon DynamoDB utilisent d'autres modèles pour la gestion des données, tels que les paires clé-valeur ou le stockage de documents. Il est important de comprendre les principales différences et les approches de conception spécifiques lorsque vous passez d'un système de gestion de base de données relationnelle (SGBDR) à un système de base de données NoSQL tel que DynamoDB.

Différences entre le système de base de données relationnelle et le système NoSQL

Les systèmes de gestion de bases de données relationnelles (SGBDR) et les bases de données NoSQL ont chacun leurs forces et leurs faiblesses :

  • Dans les SGBDR, les données peuvent être interrogées avec souplesse, mais les requêtes sont relativement coûteuses et ne sont pas bien mises à l'échelle dans les situations de trafic intense (consultez Premiers pas pour la modélisation des données relationnelles dans DynamoDB.).

  • Dans une base de données NoSQL comme DynamoDB, les données peuvent être interrogées efficacement d'un nombre limité de façons, en dehors desquelles les requêtes peuvent être coûteuses et lentes.

Ces différences entraînent une conception des bases de données très différente d'un système à l'autre :

  • Dans un SGBDR, la conception se concentre avant tout sur la flexibilité, sans se préoccuper des détails de l'implémentation ni des performances. En général, l'optimisation des requêtes n'affecte pas la conception du schéma, mais la normalisation est très importante.

  • Dans DynamoDB, votre schéma est conçu spécifiquement pour que les requêtes les plus courantes et les plus importantes soient aussi rapides et économiques que possible. Les structures de vos données sont adaptées aux exigences spécifiques de vos cas d'utilisation.

Deux concepts essentiels de la conception NoSQL

Pour concevoir un système NoSQL, il faut un autre état d'esprit que pour un SGBDR. Pour un SGBDR, vous pouvez créer un modèle de données normalisé sans réfléchir aux modèles d'accès. Vous pouvez l'étendre ultérieurement, pour répondre à de nouvelles questions et de nouveaux besoins d'interrogation. Vous pouvez organiser chaque type de données dans sa propre table.

En quoi la conception d'un système NoSQL est différente

  • En revanche, vous ne devez pas commencer à concevoir votre schéma pour DynamoDB tant que vous ne savez pas à quelle problématique celui-ci doit répondre. Il est essentiel d'identifier au préalable les problèmes métier et les cas d'utilisation de l'application.

  • Vous devez gérer le moins de tables possible dans une application DynamoDB.

Approche de la conception NoSQL

L'identification des modèles de requêtes spécifiques que le système doit satisfaire constitue la première étape de la conception de votre application DynamoDB.

Il est notamment important de comprendre trois propriétés fondamentales des modèles d'accès de votre application avant de commencer :

  • Taille des données : connaître la quantité de données qui sera stockée et demandée simultanément aide à déterminer le moyen le plus efficace pour partitionner les données.

  • Forme des données : au lieu de remodéliser les données lors du traitement d'une requête (comme c'est le cas dans un SGBDR), une base de données NoSQL organise les données de manière à ce que leur forme dans la base de données corresponde aux requêtes. C'est un élément clé pour augmenter la vitesse et la scalabilité.

  • Vitesse des données : DynamoDB effectue une mise à l'échelle en augmentant le nombre de partitions physiques disponibles pour traiter les requêtes, et en répartissant de manière efficace les données sur ces partitions. Connaître à l'avance les pics des charges de requête peut aider à déterminer comment partitionner les données afin de tirer pleinement parti de la capacité d'E/S.

Après avoir identifié les besoins de requête spécifiques, vous pouvez organiser les données en fonction des principes généraux qui déterminent la performance :

  • Rassemblez les données connexes.   Il y a 20 ans, les recherches visant à optimiser les tables de routage ont démontré que l'emplacement des références était le facteur le plus important pour accélérer le temps de réponse : il convient de rassembler les données connexes au même endroit. C'est toujours le cas dans les systèmes NoSQL aujourd'hui, dans lesquels le fait de conserver les données connexes à proximité a un impact très important sur les coûts et les performances. Au lieu de répartir des éléments de données connexes sur plusieurs tables, il est préférable de conserver les éléments connexes dans votre système NoSQL aussi près que possible les uns des autres.

    En règle générale, vous devez gérer le moins de tables possible dans une application DynamoDB.

    Les cas où des données de série chronologique volumineuses sont impliquées ou dans lesquels les ensembles de données ont des modèles d'accès très différents sont des exemples d'exceptions. Une table unique avec des index inversés peut généralement permettre à des requêtes simples de créer et récupérer les structures de données hiérarchiques complexes dont votre application a besoin.

  • Utilisez l'ordre de tri.   Les éléments connexes peuvent être regroupés et interrogés de manière efficace si la conception des clés permet de les trier ensemble. Il s'agit d'une stratégie de conception NoSQL importante.

  • Répartissez les requêtes.   Il est également important qu'un volume élevé de requêtes ne soit pas centré sur une même partie de la base de données, où la capacité d'E/S peut être dépassée. Au lieu de cela, vous devez concevoir les clés de données de manière à ce que le trafic soit, autant que possible, répartit de manière uniforme sur les partitions, évitant ainsi les « zones sensibles ».

  • Utilisez des index secondaires globaux.   En créant des index secondaires globaux spécifiques, vous pouvez accepter différentes requêtes que votre table principale peut prendre en charge, et qui restent rapides et relativement économiques.

Ces principes généraux se traduisent en modèles de conception courants disponibles pour modéliser les données de manière efficace dans DynamoDB.