Différence entre les bases de données basées sur des documents et basées sur des clés / valeurs?

97

Je sais qu'il existe trois types différents et populaires de bases de données non SQL.

  • Clé / valeur: Redis, Tokyo Cabinet, Memcached
  • Colonne Famille: Cassandra, HBase
  • Document: MongoDB, CouchDB

J'ai lu de longs blogs à ce sujet sans trop comprendre.

Je connais les bases de données relationnelles et je me familiarise avec les bases de données documentaires telles que MongoDB / CouchDB.

Quelqu'un pourrait-il me dire quelles sont les principales différences entre ceux-ci et les 2 premiers sur la liste?

mongodb couchdb cassandra redis non-relational-database never_had_a_name
la source
4
il y en a cinq: (1) Magasins de valeurs-clés: Oracle Coherence, Redis, Kyoto Cabinet (2) Bases de données de style BigTable: Apache HBase, Apache Cassandra (3) Bases de données de documents: MongoDB, CouchDB (4) Moteurs de recherche en texte intégral: Apache Lucene, Apache Solr (5) Bases de données graphiques: neo4j, FlockDB, voir nosql-data-modelage-techniques
Gary Gauh

Réponses:

74

Les principales différences sont le modèle de données et les capacités d'interrogation.

Magasins de valeurs clés

Le premier type est très simple et n'a probablement pas besoin d'explications supplémentaires.

Modèle de données: plus que des magasins de valeurs-clés

Bien qu'il y ait un débat sur le nom correct des bases de données telles que Cassandra, j'aimerais les appeler des magasins de familles de colonnes . Bien que les paires clé-valeur soient une partie essentielle de Cassandra, ce n'est pas limité à cela. Il vous permet d'imbriquer des paires clé-valeur, afin qu'une clé puisse faire référence à plusieurs paires sous-clé-valeur.

Cependant, vous ne pouvez pas imbriquer des paires clé-valeur indéfiniment. Vous êtes limité à trois niveaux (familles de colonnes) ou quatre niveaux d'imbrication (familles de super-colonnes). Dans le cas où le terme famille de colonnes ne sonne pas une cloche, voir le WTF est un article SuperColumn , c'est une bonne explication du modèle de données de Cassandra.

Les bases de données de documents , telles que CouchDB et MongoDB, stockent des documents entiers sous la forme d' objets JSON . Vous pouvez considérer ces objets comme des paires clé-valeur imbriquées. Contrairement à Cassandra, vous pouvez imbriquer des paires clé-valeur autant que vous le souhaitez. JSON prend également en charge les tableaux et comprend différents types de données, tels que les chaînes, les nombres et les valeurs booléennes.

Requête

Je pense que les magasins de familles de colonnes ne peuvent être interrogés que par clé ou en écrivant des fonctions de réduction de carte. Vous ne pouvez pas interroger les valeurs comme vous le feriez dans une base de données SQL. Si votre application a besoin de requêtes plus complexes, votre application devra créer et maintenir des index afin d'accéder aux données souhaitées.

Les bases de données de documents prennent également en charge les requêtes par clé et les fonctions de réduction de carte, mais vous permettent également d'effectuer des requêtes de base par valeur, telles que "Donnez-moi tous les utilisateurs avec plus de 10 messages". Les bases de données de documents sont ainsi plus flexibles.

Niels van der Rest
la source
2
Ainsi, les magasins de valeurs-clés comme redit ne vous permettent pas de stocker des clés imbriquées: des valeurs? Et d'après votre description, stocker une base de données entière (à partir du SGBDR) dans Cassandra ne semble pas très intelligent car il ne permet pas une requête flexible et a une profondeur d'imbrication limitée, n'est-ce pas?
never_had_a_name
7
@ajsie: Correct, les magasins clé-valeur ne prennent pas en charge les paires clé-valeur imbriquées. La plupart d'entre eux supportent cependant des valeurs spécialisées, telles que les listes. Cassandra est très différent d'un SGBDR, car les deux sont conçus pour résoudre des problèmes très différents. Les systèmes SGBDR sont destinés aux données relationnelles qui nécessitent des requêtes complexes, tandis que Cassandra vise à traiter d'énormes quantités de données pour la plupart non relationnelles. Bien sûr, il est possible de déplacer une base de données SGBDR vers Cassandra, mais pas très malin en effet. Chacun d'eux a sa propre utilisation.
Niels van der Rest
Ainsi, chaque base de données de documents est-elle également une clé, un magasin de valeurs où la valeur est simplement un JSON comme {value: base64 (val)}?
GroovyDotCom
@GroovyDotCom: Oui, vous pouvez utiliser une base de données de documents pour stocker des objets clé / valeur simples.
Niels van der Rest le
15

Ayende a donné une belle explication concernant la différence entre la base de données de valeurs clés et de documents:

Une base de données de documents est, à la base, un magasin de clés / valeurs à une exception près. Au lieu de simplement stocker n'importe quel objet blob, une base de données de document nécessite que les données soient stockées dans un format que la base de données peut comprendre (c'est-à-dire JSON, XML, etc.). Dans la plupart des dbs doc, cela signifie que nous pouvons désormais autoriser les requêtes sur les données du document.

Ashraf Alam
la source