Bonnes pratiques de modélisation des données relationnelles dans DynamoDB. - Amazon DynamoDB

Bonnes pratiques de modélisation des données relationnelles dans DynamoDB.

Les plates-formes traditionnelles du système de gestion de bases de données relationnelles (SGBDR) stockent les données dans une structure relationnelle normalisée. Cette structure réduit les structures de données hiérarchiques à un ensemble d'éléments communs stockés sur plusieurs tables. Le schéma suivant est un exemple d'application générique de saisie de commande avec le schéma RH prenant en charge les systèmes de support d'exploitation et d'activités d'un fabricant fictif.

Exemple de schéma de SGBDR.

Les plateformes de SGBDR utilisent un langage de requête ad hoc (en général une version de SQL) afin de générer ou de matérialiser des vues de données normalisées pour prendre en charge des modèles d'accès à la couche d'application.

Par exemple, pour générer une liste d'articles de bon de commande triés selon la quantité en stock dans tous les entrepôts pouvant livrer chacun d'entre eux, vous pouvez exécuter la requête suivante sur le schéma précédent :

SELECT * FROM Orders INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID ORDER BY Quantity_on_Hand DESC

Les requêtes ponctuelles de ce type fournissent une API flexible pour accéder aux données, mais elles nécessitent un volume de traitement important. Vous devez souvent interroger les données de plusieurs emplacements, et les résultats doivent être assemblés pour être présentés. La requête précédente initie des requêtes complexes sur plusieurs tables, puis trie et intègre les données résultantes.

Un autre facteur qui peut ralentir les SGBDR est la nécessité de prendre en charge une infrastructure de transaction conforme à ACID. Les structures de données hiérarchiques utilisées par la plupart des applications de traitement de transaction en ligne (OLTP) doivent être décomposées et réparties dans plusieurs tables logiques lorsqu'elles sont stockées dans un SGBDR. Par conséquent, une infrastructure de transaction conforme à ACID est nécessaire pour éviter les conditions de concurrence pouvant avoir lieu si une application tente de lire un objet qui est en cours d'écriture. Une telle infrastructure de transaction ajoute nécessairement un traitement supplémentaire important au processus d'écriture.

Ces deux facteurs sont les principaux obstacles à la mise à l'échelle des plateformes de SGBDR traditionnelles. Reste à savoir si la communauté NewSQL peut réussir à fournir une solution de SGBDR distribué. Mais il est peu probable que même une telle solution puisse résoudre les deux limites décrites précédemment. Quelle que soit la façon dont la solution est fournie, les coûts de traitement de la normalisation et des transactions ACID resteront forcément conséquents.

C'est la raison pour laquelle, lorsque votre activité exige une réponse à faible latence pour des requêtes à trafic élevé, il est généralement judicieux, d'un point de vue technique et économique, de tirer parti des avantages d'un système NoSQL. Amazon DynamoDB aide à résoudre les problèmes qui restreignent la capacité de mise à l'échelle d'un système relationnel en les évitant.

Une base de données relationnelle ne se met pas bien à l'échelle pour les raisons suivantes :

  • Elle normalise les données et les stocke dans plusieurs tables qui nécessitent plusieurs requêtes pour l'écriture sur disque.

  • Elle entraîne généralement les coûts de performances d'un système de transaction conforme à ACID.

  • Elle utilise des jointures coûteuses pour reconstituer les vues de résultats de requête requises.

DynamoDB se met à l'échelle coorectement pour les raisons suivantes :

  • Grâce à la flexibilité de son schéma, DynamoDB peut stocker des données hiérarchiques complexes au sein d'un seul élément.

  • Une conception de clé composite permet à ce service de stocker les éléments liés proches les uns des autres dans la même table.

Les requêtes sur le magasin de données deviennent beaucoup plus simples, en prenant souvent la forme suivante :

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

DynamoDB exécute beaucoup moins de tâches pour renvoyer les données demandées, comparé au SGBDR de l'exemple précédent.