Qu'est-ce qu'une base de données de magasins Key / Value?

J'ai consulté la page wikipedia pour NoSQL qui répertorie plusieurs variantes de la base de données de magasins Key / Value, mais je ne trouve aucun détail sur ce que cela signifie par magasin Key / Value dans ce contexte. Quelqu'un pourrait-il expliquer ou relier une explication à moi? Aussi, quand utiliserais-je une telle base de données?

Connaissez-vous le concept de paire clé / valeur? En supposant que vous maîtrisiez Java ou C #, le langage utilisé est une carte / un hachage / une date / KeyValuePair (le dernier s’applique à C #)

La façon dont cela fonctionne est démontrée dans ce petit exemple de tableau:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Où vous avez une clé (à gauche) et une valeur (à droite) ... remarquez que cela peut être une chaîne, un int, ou similaire. La plupart des objets KVP vous permettent de stocker n'importe quel objet à droite, car il ne s'agit que d'une valeur.

Etant donné que vous aurez toujours une clé unique pour un objet particulier que vous souhaitez renvoyer, vous pouvez simplement interroger la base de données pour obtenir cette clé unique et obtenir les résultats de n'importe quel nœud contenant l'objet (c'est pourquoi il est bon pour les systèmes distribués, étant donné qu'il y a d'autres choses impliquées, telles que l'interrogation des n premiers nœuds pour renvoyer une valeur qui correspond aux autres nœuds).

Maintenant, mon exemple ci-dessus est très simple, alors voici une version légèrement meilleure du KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Donc, comme vous pouvez le voir, la génération de clé simple consiste à mettre "utilisateur" le numéro d'utilisateur unique, un trait de soulignement et l'objet. Encore une fois, il s’agit d’une variation simple, mais je pense que nous commençons à comprendre que tant que nous pouvons définir la partie de gauche et la mettre en forme de manière cohérente, nous pouvons en extraire la valeur.

Notez qu'il n'y a aucune restriction sur la valeur de la clé (ok, il peut y avoir certaines limitations, telles que le texte uniquement) ou sur la propriété value (il peut y avoir une restriction de taille), mais je n'ai pas encore eu de système vraiment complexe. Essayons d'aller un peu plus loin:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Vous avez l’idée ... tous ceux-ci seraient stockés dans une "table" massive sur les nœuds distribués (il y a des calculs derrière tout cela) et vous demanderiez simplement au système distribué la valeur dont vous avez besoin par nom.

À tout le moins, je comprends comment cela fonctionne. J'ai peut-être quelques erreurs, mais c'est l'essentiel.

Lien wikipedia obligatoire http://en.wikipedia.org/wiki/Associative_array

En termes SQL, une base de données NoSQL est une table unique avec deux colonnes: l’une est la clé (primaire) et l’autre est la valeur. Et c'est tout, c'est toute la magie NoSQL.

Vous utiliseriez NoSQL pour une raison principale: l'évolutivité.

Si votre application doit gérer des millions de requêtes par seconde, le seul moyen de le faire consiste à ajouter plus de serveurs. C'est très économique et facile avec NoSQL. En revanche, la mise à l'échelle d'une base de données SQL traditionnelle est beaucoup plus compliquée.

Seuls les plus gros sites Web exploitent actuellement tout le potentiel de NoSQL, à savoir Facebook, avec des milliers de serveurs exécutant Cassandra .

Je recommande fortement de lire ce billet de blog comparant SQL, NoSQL et ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Je suppose que vous avez une compréhension de base du mouvement NoSQL et des modèles de bases de données non relationnelles.

Le magasin de valeurs de clé est l'un des modèles de base de données sans relation, comme les modèles de graphique, de base de données orientée document.

Les magasins Key Value et le mouvement NoSQL

En général, SQL réussissait à traiter des données spécialement structurées et autorisait des requêtes hautement dynamiques en fonction des besoins du service en question.

Bien qu'il n'y ait toujours pas de réel concurrent pour SQL dans ce domaine spécifique, le cas d'utilisation dans les applications Web quotidiennes est différent. Vous ne trouverez pas une gamme hautement dynamique de requêtes contenant des jointures externes et internes, des unions et des calculs complexes sur des tables volumineuses. Vous trouverez généralement une façon de penser très orientée objet. Surtout avec l'adoption de modèles tels que MVC, les données du back-end ne sont généralement pas modélisées pour une base de données, mais pour une intégrité logique qui aide également les personnes à être en mesure de comprendre d'importantes infrastructures logicielles. Ce qui est fait pour intégrer ces modèles orientés objet dans des bases de données relationnelles, c'est une grande quantité de normalisation qui conduit à des hiérarchies complexes de tables et à l'orientation totale contre l'idée principale de la programmation orientée objet.

Le fait que SQL autorise les requêtes dynamiques arbitraires pour des ensembles de données complexes devient inutile en utilisant une base de données SQL uniquement pour le stockage persistant de données orientées objet, comme le font actuellement la plupart des applications.

C'est ici qu'interviennent les magasins Key Value. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. Les données elles-mêmes sont généralement une sorte de primitive du langage de programmation (une chaîne, un entier, un tableau) ou un objet organisé par les liaisons de langages de programmation avec le magasin de valeurs de clé. Cela remplace le besoin d'un modèle de données fixe et rend moins stricte l'exigence de données correctement formatées.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. La plus grande différence pour les magasins «simples» réside dans la manière dont vous pouvez (ou ne pouvez pas) vous authentifier ou accéder à différents magasins (si possible). Si les avantages de la vitesse de stockage et de récupération des données peuvent être une raison de les considérer par rapport aux bases de données SQL courantes, un autre avantage important qui se dégage de l'utilisation des magasins de valeurs-clés est que le code résultant a tendance à paraître propre et simple par rapport aux chaînes SQL incorporées. votre langage de programmation. C'est une chose à laquelle les gens ont tendance à se battre avec les frameworks de mapping objet-relationnel tels que Hibernate ou Active Record. Avoir un mappeur relationnel objet semble fondamentalement émuler un magasin de valeurs de clé en ajoutant beaucoup de code très complexe entre une base de données SQL et un langage de programmation orienté objet.

Toute une communauté de personnes se réunit sous la balise " NoSQL " et discute de ces avantages et inconvénients, ainsi que des inconvénients liés à l'utilisation d'alternatives aux systèmes de gestion de base de données relationnelle. lire la suite
Ceci est un article un peu ancien, mais j'ai trouvé très utile.

when would I use such a database? Could someone explain or link an explanation to me?
C’est plus une décision architecturale qu’un point discutable ... Vous devez tenir compte de nombreux facteurs tels que l’évolutivité, les performances, etc.

Consultez les diapositives / articles ci-dessous et vous aurez une idée du moment, pourquoi et pourquoi ne pas utiliser le magasin de valeurs de clé :)

• Bases de données non relationnelles et magasins de clés / valeurs
• Key-Value-Stores - La clé de la mise à l'échelle?
• http://highscalability.com/blog/category/key-value-store [doit lire]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

D'autres l'ont expliqué, mais je vais quand même tenter le coup.

Une base de données clé / valeur stocke les données par une clé primaire. Cela nous permet d'identifier de manière unique un enregistrement dans un compartiment. Toutes les valeurs étant uniques, les recherches sont incroyablement rapides: il s’agit toujours d’une simple recherche de disque.

La valeur est juste n'importe quel type de valeur. La façon dont les données sont stockées est opaque pour la base de données elle-même. Lorsque vous stockez des données dans un magasin de clés / valeurs, la base de données ne sait pas s'il s'agit de XML, JSON, de texte ou d'une image. En réalité, ce que nous faisons dans un magasin de clés / valeurs consiste à transférer la responsabilité de comprendre comment les données sont stockées hors de la base de données vers les applications qui extraient nos données. Comme vous ne disposez que d'une seule gamme de clés par compartiment, il est très facile de les répartir sur de nombreux serveurs et d'utiliser des techniques de programmation distribuée pour permettre un accès rapide à ces données (chaque serveur stocke une plage de données). .

Un inconvénient de cette approche des données est que la recherche est une tâche très difficile. Vous devez soit lire chaque enregistrement de votre compartiment de données, soit créer des index secondaires vous-même.

Vous pouvez utiliser une base de données clé / valeur pour quelques raisons:

• Lorsque les performances en écriture sont votre priorité absolue. Mozilla Test Pilot utilise une base de données de clés / valeurs pour enregistrer rapidement des données.
• Lorsque les lectures sont garanties pour se produire que par PK.
• Lorsque vous travaillez avec un modèle de données plat.
• Lorsque vous travaillez avec un modèle de données riche et complexe qui ne peut pas être modélisé dans un SGBDR.

Il y a à peu près autant de raisons d'utiliser une base de données clé / valeur que d'utiliser un SGBDR et il y a autant d'arguments justifiant l'un par rapport à l'autre. Il est important d'examiner comment vous interrogez vos données et de comprendre comment leur modèle d'accès aux données guide la manière dont vous allez insérer et stocker des données.

N'oubliez pas qu'une base de données clé / valeur n'est qu'un type de base de données NoSQL.

Si vous avez une base de données relationnelle, vous pouvez facilement expérimenter avec ceci:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

C’est le cas de toutes les bases de données, Berkeley DBM étant un bon exemple, à partir de 1979. Depuis lors, les choses ont évolué (vous pouvez avoir beaucoup de valeurs par clé dans n’importe quel SGBDR). Pour de nombreuses applications, un magasin clé-valeur suffit (par exemple, c’est ainsi que sendmail stocke ses alias). Mais si vous vous retrouvez en train de pré-traiter la valeur dans votre propre code (ou de concaténer des chaînes pour en faire votre "clé"), en divisant ou en analysant la valeur sur un délimiteur, avant de pouvoir l'utiliser, vous serez probablement mieux loti. un SGBDR et le stocker de cette façon.