Quelle est la différence entre un système NoSQL orienté colonnes et un système orienté documents ?

Question

Les trois types de bases de données NoSQL dont j'ai entendu parler sont les bases de données clé-valeur, les bases de données orientées colonnes et les bases de données orientées documents.

Le principe de la clé-valeur est assez simple : une clé avec une valeur simple.

J'ai vu des bases de données orientées documents décrites comme étant de type clé-valeur, mais la valeur peut être une structure, comme un objet JSON. Chaque "document" peut avoir toutes, certaines ou aucune des mêmes clés qu'un autre.

L'orientation par colonne semble très proche de l'orientation par document, en ce sens que l'on ne spécifie pas de structure.

Quelle est donc la différence entre les deux et pourquoi utiliser l'un plutôt que l'autre ?

J'ai particulièrement étudié MongoDB et Cassandra. J'ai besoin d'une structure dynamique qui peut changer, mais qui n'affecte pas les autres valeurs. En même temps, j'ai besoin de pouvoir rechercher/filtrer des clés spécifiques et d'exécuter des rapports. Avec CAP, AP est le plus important pour moi. Les données peuvent "éventuellement" être synchronisées entre les nœuds, à condition qu'il n'y ait pas de conflit ou de perte de données. Chaque utilisateur aurait sa propre "table".

Answer 1

La principale différence réside dans le fait que les magasins de documents (par exemple MongoDB et CouchDB) autorisent des documents arbitrairement complexes, c'est-à-dire des sous-documents dans des sous-documents, des listes avec des documents, etc. alors que les magasins de colonnes (par exemple Cassandra et HBase) n'autorisent qu'un format fixe, par exemple des dictionnaires stricts à un ou deux niveaux.

Answer 2

Dans Cassandra, chaque ligne (adressée par une clé) contient une ou plusieurs "colonnes". Les colonnes sont elles-mêmes des paires clé-valeur. Les noms des colonnes ne doivent pas être prédéfinis, c'est-à-dire que la structure n'est pas fixe. Les colonnes d'une ligne sont stockées dans un ordre trié en fonction de leurs clés (noms).

Dans certains cas, vous pouvez avoir un très grand nombre de colonnes dans une ligne (par exemple, pour servir d'index afin de permettre certains types de requêtes). Cassandra peut gérer efficacement ces grandes structures et vous pouvez récupérer des plages spécifiques de colonnes.

Il existe un autre niveau de structure (moins couramment utilisé) appelé super-colonnes, où une colonne contient des (sous-)colonnes imbriquées.

Vous pouvez considérer la structure globale comme une table de hachage/un dictionnaire imbriqué(e), avec 2 ou 3 niveaux de clé.

Famille de colonnes normales :

row
    col  col  col ...
    val  val  val ...

Super colonne familiale :

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

Il existe également des structures de niveau supérieur - familles de colonnes et espaces-clés - qui peuvent être utilisées pour diviser ou regrouper vos données.

Voir aussi cette question : Cassandra : Qu'est-ce qu'une sous-colonne ?

Ou les liens sur la modélisation des données de http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re : comparaison avec les bases de données orientées documents - ces dernières insèrent généralement des documents entiers (typiquement JSON), alors que dans Cassandra vous pouvez adresser des colonnes individuelles ou des supercolonnes, et les mettre à jour individuellement, c'est-à-dire qu'elles travaillent à un niveau de granularité différent. Chaque colonne a son propre horodatage/version (utilisé pour réconcilier les mises à jour à travers le cluster distribué).

Les valeurs des colonnes Cassandra ne sont que des octets, mais peuvent être saisies sous forme de texte ASCII, UTF8, de nombres, de dates, etc.

Bien sûr, vous pouvez utiliser Cassandra comme un magasin de documents primitif en insérant des colonnes contenant du JSON, mais vous n'obtiendrez pas toutes les fonctionnalités d'un véritable magasin orienté documents.

Answer 3

En ce qui concerne l'"insertion", pour utiliser les termes de rdbms, Document-based est plus cohérent et plus direct. Notez que cassandra vous permet d'atteindre la cohérence avec la notion de quorum, mais cela ne s'applique pas à tous les systèmes basés sur des colonnes et cela réduit la disponibilité. Pour un système lourd en écriture unique / lecture fréquente, optez pour MongoDB. Pensez-y également si vous prévoyez toujours de lire la structure complète de l'objet. Un système basé sur les documents est conçu pour renvoyer le document entier lorsque vous l'obtenez, et n'est pas très performant pour renvoyer des parties de la ligne entière.

Les systèmes basés sur les colonnes, comme Cassandra, sont bien meilleurs que les systèmes basés sur les documents en ce qui concerne les "mises à jour". Vous pouvez modifier la valeur d'une colonne sans même lire la ligne qui la contient. L'écriture n'a pas besoin d'être effectuée sur le même serveur, une ligne peut être contenue dans plusieurs fichiers sur plusieurs serveurs. Pour les systèmes de données à évolution rapide, optez pour Cassandra. Pensez-y également si vous prévoyez d'avoir de très gros morceaux de données par clé, et que vous n'avez pas besoin de les charger tous à chaque requête. Dans "select", Cassandra vous permet de charger uniquement la colonne dont vous avez besoin.

Il faut également tenir compte du fait que Mongo DB est écrit en C++ et en est à sa deuxième version majeure, alors que Cassandra doit fonctionner sur une JVM et que sa première version majeure n'est en release candidate que depuis hier (mais les versions 0.X se sont déjà transformées en productions d'entreprises majeures).

D'autre part, la conception de Cassandra était en partie basée sur Amazon Dynamo, et il est construit à la base pour être une solution de haute disponibilité, mais cela n'a rien à voir avec le format basé sur les colonnes. MongoDB est également évolutif, mais pas aussi gracieusement que Cassandra.

Answer 4

Je dirais que la principale différence réside dans la manière dont chacun de ces types de BD stocke physiquement les données.
Avec les types de colonnes, les données sont stockées par colonnes, ce qui permet des opérations d'agrégation et des requêtes efficaces sur une colonne particulière.
Avec les types de documents, le document entier est logiquement stocké en un seul endroit et est généralement récupéré dans son ensemble (aucune agrégation efficace n'est possible sur les "colonnes" / "champs").

Ce qui est déroutant, c'est qu'une "rangée" de colonnes larges peut facilement être représentée comme un document, mais, comme nous l'avons mentionné, ils sont stockés différemment et optimisés à des fins différentes.