Quelle est la différence entre NoSQL orienté colonne et 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 une valeur-clé, 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 car vous ne spécifiez pas de structure.
Alors, quelle est la différence entre ces deux, et pourquoi voudriez-vous utiliser 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 sans affecter 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 colonne n'ont pas besoin d'être prédéfinis, c'est-à-dire que la structure n'est pas fixe. Les colonnes d'une rangée 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 agir comme un index afin d'activer des types particuliers de requête). Cassandra peut gérer de telles structures de manière efficace 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 normale:
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 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 des bases de données orientées documents - 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 possède son propre horodatage/version (utilisé pour réconcilier les mises à jour à travers le cluster distribué).
Les valeurs de la colonne Cassandra ne sont que des octets, mais peuvent être saisies en ASCII, texte UTF8, nombres, 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 vrai magasin orienté documents.
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. tandis que les magasins de colonnes (par exemple Cassandra et HBase) autorisent uniquement un format fixe, par exemple dictionnaires stricts à un ou deux niveaux.
Dans "insert", pour utiliser les mots 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'appliquera pas à tous les systèmes basés sur des colonnes et réduira la disponibilité. Sur un système lourd à écriture unique/lecture fréquente , optez pour MongoDB. Considérez-le également si vous prévoyez toujours de lire la structure entière de l'objet. Un système basé sur un document est conçu pour renvoyer le document entier lorsque vous l'obtenez, 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 ceux basés sur des documents dans les "mises à jour". Vous pouvez changer la valeur d'une colonne sans même lire la ligne qui la contient. L'écriture ne doit être fait sur le même serveur, une ligne peut être contenue dans plusieurs fichiers de plusieurs serveurs. Sur un énorme système de données à évolution rapide, optez pour Cassandra. Considérez-le également si vous prévoyez d'avoir un très gros bloc de données par clé, et vous n'aurez pas besoin de les charger tous à chaque requête. Dans "select", Cassandra vous permet de charger uniquement la colonne dont vous avez besoin.
Tenez également compte du fait que Mongo DB est écrit en C++ et en est à sa deuxième version majeure, tandis que Cassandra doit s'exécuter sur une machine virtuelle Java, et sa première version majeure n'est en version candidate que depuis hier (mais les sorties 0.X se sont déjà transformées en productions de grandes entreprises).
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 aussi, mais pas aussi gracieusement que Cassandra.