Principales différences et principes de conception de No SQL Design

Aucun système SQL de base de données tel qu'Amazon Keyspaces 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 qu'Amazon Keyspaces, il est important de comprendre les principales différences et les approches de conception spécifiques.

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). Bonnes pratiques de modélisation des données : recommandations pour la conception de modèles de données

• Dans une SQL base de données non utilisée telle qu'Amazon Keyspaces, 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 Amazon Keyspaces, vous concevez votre schéma 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 devriez pas commencer à concevoir votre schéma pour Amazon Keyspaces tant que vous ne connaissez pas les questions auxquelles il 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 Amazon Keyspaces. Le fait de disposer de moins de tables permet de rendre les choses plus évolutives, de réduire la gestion des autorisations et de réduire la charge de travail de votre application Amazon Keyspaces. Cela peut également contribuer à maintenir des coûts de sauvegarde globalement plus faibles.

Absence SQL de design

La première étape de la conception de votre application Amazon Keyspaces consiste à identifier les modèles de requêtes spécifiques auxquels le système doit répondre.

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 en une seule fois permet de déterminer le moyen le plus efficace de 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 telle sorte 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é.

• Vélocité des données : Amazon Keyspaces évolue en augmentant le nombre de partitions physiques disponibles pour traiter les requêtes et en distribuant efficacement les données entre 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.   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. Cela vaut également pour les SQL systèmes No d'aujourd'hui, où le fait de conserver les données associées à proximité a un impact majeur sur les coûts et les performances. Au lieu de répartir les éléments de données connexes sur plusieurs tables, vous devez conserver les éléments connexes dans votre SQL système No 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 Amazon Keyspaces.

  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 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 ».

Ces principes généraux se traduisent par des modèles de conception courants que vous pouvez utiliser pour modéliser efficacement les données dans Amazon Keyspaces.