Quand utiliser un magasin de données clé-valeur par rapport à une base de données relationnelle plus traditionnelle?
Quand choisirait-on un magasin de données clé-valeur sur une base de données relationnelle? Quelles considérations entrent dans la décision de l'un ou l'autre? Quand le mélange des deux est-il le meilleur itinéraire? Veuillez fournir des exemples si vous le pouvez.
5 réponses
D'après mon expérience, si vous posez même la question de savoir s'il faut utiliser des pratiques traditionnelles vs ésotériques, alors allez traditionnel. Alors que les pratiques ésotériques sont sexy, stimulantes et amusantes, 99,999% des applications nécessitent une approche traditionnelle.
En ce qui concerne relationnel vs KV, la question que vous devriez poser est:
Pourquoi ne voudrais-je pas Utiliser un modèle relationnel pour ce scénario: ...
Puisque vous n'avez pas décrit le scénario, il est impossible pour quiconque de vous dire pourquoi vous ne devriez pas l'utiliser. La raison" fourre-tout " de KV est l'évolutivité, ce qui n'est pas un problème maintenant. Connaissez-vous les règles de l'optimisation?
- Ne pas le faire.
- (pour les experts seulement) ne le faites pas maintenant.
KV est une solution hautement optimisée pour l'évolutivité qui sera probablement complètement inutile pour votre application.
Les systèmes de base de données Key-value, heirarchical, Map-reduce ou graph sont beaucoup plus proches des stratégies de mise en œuvre, ils sont fortement liés à la représentation physique. La principale raison de choisir l'un d'entre eux est s'il existe un argument de performance convaincant et qu'il correspond très étroitement à votre stratégie de traitement des données. Attention, les requêtes ad hoc ne sont généralement pas pratiques pour ces systèmes, et vous feriez mieux de décider de vos requêtes à l'avance.
Les systèmes de bases de données relationnelles séparer le modèle logique et axé sur les affaires des stratégies de représentation physique et de traitement sous-jacentes. Cette séparation est imparfaite, mais toujours assez bonne. Les systèmes relationnels sont parfaits pour gérer les faits et extraire des informations fiables à partir de collections de faits. Les systèmes relationnels sont également excellents pour les requêtes ad hoc, ce que les autres systèmes sont notoirement mauvais. C'est un grand ajustement dans le monde des affaires et bien d'autres endroits. C'est pourquoi les systèmes relationnels le sont répandu.
S'il s'agit d'une application métier, un système relationnel est presque toujours la réponse. Pour d'autres systèmes, c'est probablement la réponse. Si vous avez plus d'un problème de traitement des données, comme un pipeline de choses qui doivent se produire et vous avez des quantités massives de données, et vous connaissez toutes vos requêtes à l'avance, un autre système peut être bon pour vous.
Si vos données sont simplement une liste de choses et que vous pouvez dériver un identifiant unique pour chaque élément, alors un KVS est une bonne correspondance. Ce sont des implémentations proches des structures de données simples que nous avons apprises en informatique de première année et ne permettent pas de relations complexes.
Un test simple: Pouvez-vous représenter vos données et toutes ses relations sous la forme d'une liste liée ou d'une table de hachage? Si oui, un KVS peut fonctionner. Si non, vous avez besoin D'un RDB.
Vous devez toujours trouver un KVS qui fonctionnera dans votre environnement. Le Support pour KVSes, même les plus importants, est loin de ce qu'il est pour, disons, PostgreSQL et MySQL / MariaDB.
Une base de données relationnelle traditionnelle a des problèmes de mise à l'échelle au-delà d'un point. Ce point dépend un peu de ce que vous essayez de faire.
Tous (le plus?) des fournisseurs de cloud computing fournissent des magasins de données de valeur clé.
Cependant, si vous avez une application de taille raisonnable avec une structure de données compliquée, le support que vous obtenez en utilisant une base de données relationnelle peut réduire vos coûts de développement.
IMO, paire de valeurs clés (par exemple, bases de données NoSQL) fonctionne mieux lorsque les données sous-jacentes sont non structurées, imprévisibles ou changent souvent. Si vous n'avez pas de données structurées, une base de données relationnelle va poser plus de problèmes que sa valeur car vous devrez faire beaucoup de changements de schéma et/ou Sauter à travers des cerceaux pour conformer vos données à la structure.
KVP / JSON / NoSql est génial car les modifications apportées à la structure de données ne nécessitent pas de refactoring complet du modèle de données. L'ajout d'un champ et l'objet de données est simplement une question d'ajouter à ces données. L'autre côté de la médaille est qu'il y a moins de contraintes et de contrôles de validation dans une base de données KVP / Nosql qu'une base de données relationnelle, donc vos données pourraient devenir désordonnées.
Il y a des avantages de performance et d'économie d'espace pour les modèles de données relationnelles. Les données relationnelles normalisées peuvent faciliter la compréhension et la validation des données, car il existe des relations et des contraintes clés de table pour vous aider.
Un parmi les pires modèles que j'ai vus, j'essaie de l'avoir dans les deux sens. Essaye de mettre une paire clé-valeur dans une base de données relationnelle est souvent une recette pour le désastre. Je recommande d'utiliser la technologie qui convient à vos données avant tout.