En quoi NoSQL orienté colonne diffère-t-il de celui orienté document?

Les trois types de bases de données NoSQL que j'ai lus sont les valeurs-clés, les colonnes et les documents.

La valeur-clé est assez simple - une clé avec une valeur simple.

J'ai vu des bases de données orientées document décrites comme des valeurs-clés, 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 colonne semble être très similaire à l'orientation document en ce que vous ne spécifiez pas de structure.

Alors, quelle est la différence entre ces deux, et pourquoi utiliseriez-vous l'un sur l'autre?

J'ai spécifiquement examiné MongoDB et Cassandra. J'ai essentiellement besoin d'une structure dynamique qui peut changer, mais n'affecte pas les autres valeurs. En même temps, je dois pouvoir rechercher / filtrer des clés spécifiques et 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, tant qu'il n'y a pas de conflit ou de perte de données. Chaque utilisateur obtiendrait sa propre «table».

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 de colonnes n'ont pas besoin d'être prédéfinis, c'est-à-dire que la structure n'est pas fixe. Les colonnes d'une ligne sont stockées dans l'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 agir comme un index pour activer des types particuliers de requête). 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 (pas si 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 / dictionnaire imbriquée, avec 2 ou 3 niveaux de clé.

Famille de colonnes normales:

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

Famille de super colonnes:

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 de 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 de modélisation de données de http://wiki.apache.org/cassandra/ArticlesAndPresentations

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

Les valeurs de la colonne 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 magasin de documents primitif en insérant des colonnes contenant JSON - mais vous n'obtiendrez pas toutes les fonctionnalités d'un véritable magasin orienté document.

La principale différence est 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 un dictionnaires à deux niveaux.

Dans «insérer», pour utiliser des mots rdbms, Document-based est plus cohérent et direct. Notez que cassandra vous permet d'être cohérent avec la notion de quorum, mais cela ne s'appliquera pas à tous les systèmes basés sur des colonnes et cela réduira la disponibilité. Sur un système à écriture unique / souvent en lecture, optez pour MongoDB. Considérez-le également si vous prévoyez toujours de lire toute la structure de l'objet. Un système basé sur des documents est conçu pour renvoyer le document entier lorsque vous le recevez, et n'est pas très efficace pour renvoyer des parties de la ligne entière.

Les systèmes basés sur des colonnes comme Cassandra sont bien meilleurs que les systèmes basés sur des documents dans 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 vraiment besoin d'être effectuée sur le même serveur, une ligne peut être contenue sur plusieurs fichiers de plusieurs serveurs. Sur un énorme système de données en évolution rapide, optez pour Cassandra. Considérez-le également si vous prévoyez d'avoir un très gros morceau de données par clé et que vous n'aurez pas besoin de les charger toutes à chaque requête. Dans "sélectionner", Cassandra vous permet de charger uniquement la colonne dont vous avez besoin.

Considérez également que Mongo DB est écrit en C ++, et en est à sa deuxième version majeure, tandis 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 ont tourné en productions de grande entreprise déjà).

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

Je dirais que la principale différence réside dans la manière dont chacun de ces types de bases de données stocke physiquement les données.
Avec les types de colonnes, les données sont stockées par des colonnes qui peuvent permettre des opérations / requêtes d'agrégation efficaces sur une colonne particulière.
Avec les types de document, 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 possible sur les «colonnes» / «champs»).

Le peu déroutant est qu'une «rangée» de colonnes larges peut être facilement représentée comme un document, mais, comme mentionné, elles sont stockées différemment et optimisées à des fins différentes.