Qu'est-ce qu'une base de données de magasin de clés / valeurs?
J'ai consulté la page wikipedia de NoSQL et elle répertorie plusieurs variantes de la base de données du magasin de clés/valeurs, mais je ne trouve aucun détail sur ce que cela signifie par magasin de clés/valeurs dans ce contexte. Quelqu'un pourrait-il m'expliquer ou me lier une explication? Aussi, quand utiliserais-je une telle base de données?
Connaissez-vous le concept de paire clé/valeur? En supposant que vous connaissez bien Java ou C # c'est dans le langage comme une carte/hachage/datatable/KeyValuePair (le dernier est dans le cas de C #)
La façon dont cela fonctionne est illustrée dans ce petit exemple de graphique:
Color Red
Age 18
Size Large
Name Smith
Title The Brown Dog
Lorsque vous avez une clé (à gauche) et une valeur (à droite) ... notez qu'il peut s'agir d'une chaîne, d'un entier ou similaire. La plupart des objets KVP vous permettent de stocker n'importe quel objet sur la droite, car ce n'est qu'une valeur.
Étant 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 cette clé unique et obtenir les résultats du nœud qui a l'objet (c'est pourquoi c'est bon pour les systèmes distribués, car il y a d'autres choses impliquées, comme l'interrogation des n premiers nœuds pour renvoyer une valeur qui correspond aux retours d'autres nœuds).
Maintenant, mon exemple ci-dessus est très simple, voici donc 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 simple variation, mais je pense que nous commençons à comprendre que tant que nous pouvons définir la partie à gauche et la mettre en forme de manière cohérente, nous pouvons retirer la valeur.
Notez qu'il n'y a aucune restriction sur la valeur de la clé (ok, il peut y avoir des limitations, comme le texte uniquement) ou sur la propriété value (il peut y avoir une restriction de taille) mais jusqu'à présent, je n'ai pas eu de systèmes vraiment complexes. 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 mathématiques derrière tout cela) et vous demanderiez simplement au système distribué la valeur dont vous avez besoin par son nom.
À tout le moins, c'est ma compréhension de la façon dont tout 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 étant la clé (primaire) et l'autre étant la valeur. Et c'est tout, c'est toute la magie de NoSQL.
Vous utiliseriez NoSQL pour une raison principale: l'évolutivité.
Si votre application doit gérer des millions de requêtes par seconde, la seule façon d'y parvenir est d'ajouter plus de serveurs. C'est très bon marché 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 grands sites Web exploitent réellement le plein potentiel de NoSQL, c'est-à-dire Facebook, ayant des milliers de serveurs exécutés Cassandra .
Je recommande fortement de lire ce billet de blog, en comparant SQL, NoSQL et ORM:
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 clés est l'un des modèles de base de données sans relation, comme les modèles de base de données orientés graphique et document.
Magasins de valeurs clés et mouvement NoSQL
D'une manière générale, SQL a réussi à traiter des données spécialement structurées et a permis des requêtes très dynamiques en fonction des besoins du service concerné.
Bien qu'il n'y ait toujours pas de véritables concurrents 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 très dynamique de requêtes remplies de jointures externes et internes, d'unions et de calculs complexes sur de grandes tables. 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 dans le back-end ne sont généralement pas modélisées pour une base de données, mais pour l'intégrité logique qui aide également les gens à être en mesure de faire face à la compréhension d'énormes infrastructures logicielles. Ce qui est fait pour mettre ces modèles orientés objet dans des bases de données relationnelles est une grande quantité de normalisation qui conduit à des hiérarchies complexes de tables et s'oppose complètement à l'idée principale derrière la programmation orientée objet. Les serveurs qui adhèrent à la norme SQL doivent également implémenter une grande partie du code qui n'est d'aucune utilité pour un simple stockage de données, ce qui ne fait que gonfler l'encombrement de la mémoire, les risques de sécurité et les résultats en conséquence.
Le fait que SQL permette des requêtes dynamiques arbitraires pour des ensembles complexes de données est rendu inutile en utilisant une base de données SQL uniquement pour le stockage persistant de données orientées objet, ce qui est essentiellement la plupart des applications de nos jours.
C'est là que les magasins Key Value entrent en jeu.
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 qui est organisé par les liaisons des langages de programmation vers le magasin de valeurs clés. Cela remplace la nécessité d'un modèle de données fixe et rend l'exigence de données correctement formatées moins stricte.
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 "plus simples" est la façon dont vous pouvez (ou ne pouvez pas) authentifier ou accéder à différents magasins (si possible). Bien que les avantages de la vitesse de stockage et de récupération des données puissent être une raison de les considérer par rapport aux bases de données SQL courantes, un autre gros avantage qui se dégage lors 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 intégrées dans votre langage de programmation. C'est quelque chose que les gens ont tendance à combattre avec des cadres de mappage relationnel-objet tels que Hibernate ou Active Record. Avoir un mappeur relationnel d'objet semble fondamentalement émuler un magasin de valeurs clés en ajoutant beaucoup de code vraiment complexe entre une base de données SQL et un langage de programmation orienté objet.Toute une communauté de personnes se rassemble sous la balise " NoSQL " et discute de ces avantages ainsi que des inconvénients de l'utilisation d'alternatives aux systèmes de gestion de bases de données relationnelles. en savoir plus
C'est un article un peu ancien, mais je l'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, et une décision discutable ... Vous devez prendre en compte de nombreux facteurs comme l'évolutivité, les performances, etc.
Consultez les diapositives/articles ci-dessous et vous aurez une idée, quand, pourquoi et pourquoi ne pas utiliser le magasin de valeurs clés :)
D'autres l'ont expliqué, mais je vais quand même essayer.
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. Comme toutes les valeurs sont uniques, les recherches sont incroyablement rapides: c'est toujours une simple recherche de disque.
La valeur est 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 ou se soucie s'il s'agit de XML, JSON, de texte ou d'une image. En effet, ce que nous faisons dans un magasin de clés/valeurs déplace la responsabilité de comprendre comment les données sont stockées hors de la base de données vers les applications qui récupèrent nos données. Étant donné que vous n'avez qu'une seule plage de clés à vous soucier par compartiment, il est très facile de répartir les clés sur de nombreux serveurs et d'utiliser des techniques de programmation réparties pour permettre d'accéder rapidement à 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 dans vos données de compartiment, soit vous devez créer index secondaires vous-même.
Il y a plusieurs raisons pour lesquelles vous voudrez peut-être utiliser une base de données clé/valeur:
- Lorsque les performances d'écriture sont votre priorité absolue. Mozilla Test Pilot utilise une base de données clé/valeur pour enregistrer rapidement les données.
- Lorsque les lectures ne sont garanties 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 qu'il y a à utiliser un SGBDR et il y a autant d'arguments pour justifier l'un que l'autre. Il est important de regarder comment vous interrogez vos données et de comprendre comment ce modèle d'accès aux données guide la façon 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 l'expérimenter:
create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);
C'est ainsi que toutes les bases de données étaient, avec Berkeley DBM en étant un bon exemple, à partir de 1979. Depuis lors, les choses ont avancé (vous pouvez avoir beaucoup valeurs par clé dans n'importe quel SGBDR). Pour de nombreuses applications, un magasin de valeurs-clés est suffisant (par exemple, c'est ainsi que sendmail stocke ses alias). Mais si vous vous retrouvez à prétraiter la valeur dans votre propre code (ou à concaténer des chaînes pour créer votre "clé"), peut-être en divisant la valeur sur un délimiteur ou en l'analysant, avant de pouvoir l'utiliser, vous serez probablement mieux avec un SGBDR et le stocker de cette façon.