Quand choisirait-on un magasin de données clé-valeur plutôt qu'une base de données relationnelle ? Quelles considérations entrent en jeu pour décider de l'un ou de l'autre ? Quand le mélange des deux est-il la meilleure option ? Veuillez fournir des exemples si possible.
Les systèmes de bases de données clé-valeur, hiérarchiques, map-reduce, ou graphiques 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 de ces systèmes est s'il existe un argument de performance convaincant et s'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 il est préférable de décider à l'avance de vos requêtes.
Les systèmes de bases de données relationnelles essaient de séparer le modèle logique, orienté vers le business, de la représentation physique sous-jacente et des stratégies de traitement. Cette séparation est imparfaite, mais elle est quand même assez bonne. Les systèmes relationnels sont excellents pour gérer des faits et extraire des informations fiables à partir de collections de faits. Les systèmes relationnels sont également très performants pour les requêtes ad hoc, ce qui est notoirement mauvais pour les autres systèmes. C'est un excellent choix dans le monde des affaires et de nombreux autres domaines. C'est pourquoi les systèmes relationnels sont si répandus.
S'il s'agit d'une application commerciale, un système relationnel est presque toujours la réponse. Pour d'autres systèmes, c'est probablement la réponse. Si vous avez davantage un problème de traitement des données, comme une chaîne de processus qui doit se dérouler et que vous avez d'énormes quantités de données, et que vous connaissez toutes vos requêtes à l'avance, un autre système peut être fait pour vous.
Si vos données sont simplement une liste de choses et que vous pouvez déduire un identifiant unique pour chaque élément, alors un KVS est un bon choix. Ce sont des implémentations proches des structures de données simples que nous avons apprises en informatique au premier cycle et ne permettent pas de relations complexes.
Un test simple: pouvez-vous représenter vos données et toutes leurs relations sous forme de liste chaînée ou de table de hachage ? Si oui, un KVS peut fonctionner. Sinon, vous avez besoin d'un RDB.
Vous devez toujours trouver un KVS qui fonctionnera dans votre environnement. Le support pour les KVS, même les principaux, est loin d'être aussi bon que pour, par exemple, PostgreSQL et MySQL/MariaDB.
À mon avis, la paire clé-valeur (par exemple, les 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 qu'elle n'en vaut la peine car vous devrez apporter de nombreux changements au schéma et/ou faire des sauts à travers des obstacles pour conformer vos données à la structure.
KVP / JSON / NoSql est génial car les changements apportés à la structure des données ne nécessitent pas de refactoriser complètement le modèle de données. Ajouter un champ à votre objet de données n'est qu'une question de l'ajouter aux données. L'autre côté de la médaille est qu'il y a moins de contraintes et de vérifications de validation dans une base de données KVP / Nosql qu'une base de données relationnelle, donc vos données pourraient devenir confuses.
Il y a des avantages en termes de performances et d'économie d'espace pour les modèles de données relationnelles. Des données relationnelles normalisées peuvent rendre la compréhension et la validation des données plus faciles car il existe des relations de clé de table et des contraintes pour vous aider.
Un des pires schémas que j'aie vu est d'essayer d'avoir les deux options. Essayer de mettre une paire clé-valeur dans une base de données relationnelle est souvent une recette pour le désastre. Je recommanderais d'utiliser la technologie qui convient le mieux à vos données en premier lieu.
Si vous voulez des recherches O(1) de valeurs basées sur des clés, alors vous voulez un magasin KV. Cela signifie que si vous avez des données sous la forme de k1={foo}, k2={bar}, etc., même lorsque les valeurs sont de plus grandes structures/nichées, et que vous voulez des recherches rapides, vous voulez un magasin KV. Même avec un indexage approprié, vous ne pouvez pas obtenir des recherches O(1) dans une base de données relationnelle pour des clés arbitraires. Parfois, cela est appelé "recherches aléatoires".
Autrement dit, si vous interrogez toujours uniquement par une colonne, une "clé primaire" si vous voulez, pour récupérer le reste des données, alors utiliser cette colonne comme espace de clés et le reste des données comme une valeur dans un magasin KV est le moyen le plus efficace de faire des recherches.
En revanche, si vous interrogez souvent les données par l'une des plusieurs colonnes, autrement dit si vous prenez en charge une API de requête plus riche pour les données, alors vous voudrez peut-être une base de données relationnelle.
Une base de données relationnelle traditionnelle rencontre des problèmes d'évolutivité au-delà d'un certain point. Où se situe ce point dépend un peu de ce que vous essayez de faire.
Tous (ou la plupart?) des fournisseurs de cloud computing proposent des magasins de données clé-valeur.
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.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
