Comment est orientée colonne NoSQL diffèrent orientée document?
les trois types de bases de données NoSQL que j'ai lues sont key-value, column-oriented et document-oriented.
Clé-valeur est assez simple - une clé avec une simple valeur.
j'ai vu des bases de données orientées documents décrites comme des valeurs clés similaires, 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.
colonne orientée semble être très comme le document orienté en ce que vous ne spécifiez pas de structure.
alors quelle est la différence entre ces deux-là, et pourquoi utiliser l'un plutôt que l'autre?
J'ai spécifiquement regardé MongoDB et Cassandra. J'ai fondamentalement besoin d'une structure dynamique qui peut changer, mais qui n'affecte pas les autres valeurs. En même temps j'ai besoin d'être en mesure de rechercher/filtrer les touches spécifiques et exécuter des rapports. Avec CAP, AP est le plus important pour moi. Les données peuvent "éventuellement" être synchronisés entre les noeuds, aussi longtemps qu'il n'y a pas de conflit ou de perte de données. Chaque utilisateur obtiendrait sa propre "table".
3 réponses
dans Cassandra, chaque ligne (adressée par une clé) contient une ou plusieurs"colonnes". Les colonnes sont elles-mêmes des paires de valeurs clés. 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 dans une rangée sont stockées dans l'ordre trié selon leurs clés (noms).
dans certains cas, vous pouvez avoir un très grand nombre de colonnes dans une rangée (par exemple pour agir comme un index pour permettre des types particuliers de requête). Cassandra peut gérer de telles grandes structures efficacement, et vous pouvez récupérer des gammes spécifiques de colonnes.
il y a un autre niveau de structure (pas si couramment utilisé) appelé super-colonnes, où une colonne contient des (sous -) colonnes imbriquées.
vous pouvez penser à la structure globale comme un Hashtable/dictionnaire imbriqué, avec 2 ou 3 niveaux de clé.
famille normale de la colonne:
row
col col col ...
val val val ...
Super colonne famille:
row
supercol supercol ...
(sub)col (sub)col ... (sub)col (sub)col ...
val val ... val val ...
il y a aussi des structures de plus haut niveau-familles de colonnes et claviers - 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: la comparaison avec le document orienté bases de données - ces dernières insèrent généralement des documents entiers (généralement JSON), tandis que dans Cassandra vous pouvez adresser les colonnes individuelles ou supercolumns, et les mettre à jour individuellement, c.-à-d. ils travaillent à un niveau différent de granularité. Chaque colonne a son propre horodatage/version (utilisé pour rapprocher les mises à jour à travers le cluster distribué).
les valeurs de la colonne Cassandra ne sont que des octets, mais elles peuvent être dactylographiées en ASCII, texte UTF8, nombres, dates, etc.
de bien sûr, vous pouvez utiliser Cassandra comme un magasin de documents primitif en insérant des colonnes contenant JSON - mais vous n'obtiendriez 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) permettent des documents arbitrairement complexes, c'est-à-dire des sous-documents à l'intérieur de sous-documents, des listes avec des documents, etc. tandis que les stocks de colonnes (par exemple Cassandra et HBase) ne permettent qu'un format fixe, par exemple des dictionnaires à un ou deux niveaux.
Dans "insertion", pour utiliser sgbdr mots, le Document de base est plus uniforme et rectiligne de l'avant. 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 colonne-basés et qui réduisent la disponibilité. Sur une écriture-une fois / lire-souvent système lourd, aller 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 des documents est conçu pour retourner le document entier lorsque vous l'obtenez, et n'est pas très fort au retour des parties de toute la rangée.
les systèmes basés sur des colonnes comme Cassandra sont bien meilleurs que ceux basés sur des documents dans"updates". Vous pouvez changer la valeur d'une colonne sans même lire la ligne qui la contient. L'écriture n'a pas besoin d'être faite 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 également si vous prévoyez d'avoir un très grand morceau de données par clé, et n'aura pas besoin pour tous les charger à chaque requête. Dans" select", Cassandra vous permet de charger uniquement la colonne dont vous avez besoin.
considère aussi que Mongo DB est écrit en C++, et est à sa deuxième sortie majeure, tandis que Cassandra doit courir sur un JVM, et sa première sortie majeure est en version candidate seulement depuis hier (mais le 0.X sorties tournés dans les productions de la grande société déjà).
D'un autre côté, Cassandra conçu était en partie basé sur Amazon Dynamo, et il est construit à son cœur pour être une solution de haute disponibilité, mais qui n'a rien à voir avec le format colonne-basé. MongoDB s'écaille aussi, mais pas aussi gracieusement que Cassandra.