Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Aucune SQL conception pour DynamoDB
Aucun système SQL de base de données tel qu'Amazon DynamoDB n'utilise de modèles alternatifs pour la gestion des données, tels que les paires clé-valeur ou le stockage de documents. Lorsque vous passez d'un système de gestion de base de données relationnelle à un système sans SQL base de données tel que DynamoDB, il est important de comprendre les principales différences et les approches de conception spécifiques.
Rubriques
Différences entre la conception de données relationnelles et Non SQL
Les systèmes de base de données relationnelle (RDBMS) et Aucune base de SQL données présentent des points forts et des points faibles différents :
-
DansRDBMS, les données peuvent être interrogées de manière flexible, mais les requêtes sont relativement coûteuses et ne s'adaptent pas bien dans les situations de trafic élevé (voir). Premiers pas pour la modélisation des données relationnelles dans DynamoDB
-
Dans une SQL base de données sans base de données telle que DynamoDB, les données peuvent être consultées efficacement d'un nombre limité de manières, 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 :
-
DansRDBMS, vous concevez dans un souci de flexibilité sans vous soucier des détails de mise en œuvre ou 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 clés pour No SQL Design
Aucun SQL design ne nécessite un état d'esprit différent de celui RDBMS du design. Par ailleursRDBMS, vous pouvez créer un modèle de données normalisé sans penser 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.
Comment aucun SQL design n'est différent
-
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. Le fait d'avoir moins de tables rend les choses plus évolutives, nécessite moins de gestion des autorisations et réduit les frais généraux pour votre application DynamoDB. Cela peut également contribuer à maintenir des coûts de sauvegarde globalement plus faibles.
Pas de SQL design en approche
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 remodeler les données lorsqu'une requête est traitée (comme le fait un RDBMS système), une SQL base de données Non organise les données de manière à ce que leur forme dans la base de données corresponde à ce qui sera demandé. 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é I/O.
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. Des recherches ont montré que le principe de la « localité de référence », qui consiste à regrouper les données associées en un seul endroit, est un facteur clé pour améliorer les performances et les temps de réponse dans les SQL systèmes No, tout comme il s'est avéré important pour optimiser les tables de routage il y a de nombreuses années.
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 non SQL design importante.
-
Répartissez les requêtes. Il est également important qu'un grand nombre de requêtes ne soient pas focalisées sur une partie de la base de données, où elles peuvent dépasser la capacité d'E/S. Vous devez plutôt concevoir des clés de données pour répartir le trafic de manière aussi uniforme que possible entre les partitions, en évitant les points chauds.
-
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.
Pas de SQL Workbench pour DynamoDB
Pas de SQL Workbench pour DynamoDBest une GUI application multiplateforme côté client que vous pouvez utiliser pour le développement et l'exploitation de bases de données modernes. Il est disponible pour Windows, macOS et Linux. No SQL Workbench est un outil de développement visuel qui fournit des fonctionnalités de modélisation, de visualisation des données, de génération d'échantillons de données et de développement de requêtes pour vous aider à concevoir, créer, interroger et gérer des tables DynamoDB. Avec No SQL Workbench for DynamoDB, vous pouvez créer de nouveaux modèles de données à partir de modèles de données existants ou concevoir des modèles basés sur ceux-ci, qui répondent aux modèles d'accès aux données de votre application. À la fin du processus, vous pouvez également importer et exporter le modèle de données conçu. Pour de plus amples informations, veuillez consulter Création de modèles de données avec No SQL Workbench.
