blocks|key|770167|text|在“插入”中，用rdbms的话来说，基于文档是更一致和直接的前进。请注意，cassandra允许您与quorum的概念保持一致，但这并不适用于所有基于列的系统，这会降低可用性。在一次写入/经常读取的繁重系统上，使用MongoDB。如果您总是计划读取对象的整个结构，也要考虑它。基于文档的系统被设计为在获取文档时返回整个文档，并且在返回整行的部分内容方面不是很强。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|770168|像Cassandra这样的基于列的系统在“更新”方面比基于文档的系统要好得多。您可以更改列的值，甚至不需要读取包含它的行。写操作实际上不需要在同一台服务器上完成，行可以包含在多个服务器的多个文件中。在快速发展的大型数据系统上，选择Cassandra。如果您计划每个键都有非常大的数据块，并且不需要在每次查询时加载所有数据块，请考虑这一点。在"select“中，Cassandra允许您只加载所需的列。|770169|还要考虑到Mongo+DB是用C%2B%2B编写的，并且是它的第二个主要版本，而Cassandra需要在JVM上运行，它的第一个主要版本是从昨天才发布的候选版本(但0.X版本已经成为主要公司的产品)。|770170|另一方面，Cassandra的设计部分基于Amazon+Dynamo，它的核心构建为高可用性解决方案，但这与基于列的格式没有任何关系。MongoDB也可以向外扩展，但不像Cassandra那样优雅。|770171|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

In "insert", to use rdbms words, Document-based is more consistent and straight foward. Note than cassandra let you achieve consistency with the notion of quorum, but that won't apply to all column-based systems and that reduce availibility. On a write-once / read-often heavy system, go for MongoDB. Also consider it if you always plan to read the whole structure of the object. A document-based system is designed to return the whole document when you get it, and is not very strong at returning parts of the whole row.

The column-based systems like Cassandra are way better than document-based in "updates". You can change the value of a column without even reading the row that contains it. The write doesn't actualy need to be done on the same server, a row may be contained on multiple files of multiple server. On huge fast-evolving data system, go for Cassandra. Also consider it if you plan to have very big chunk of data per key, and won't need to load all of them at each query. In "select", Cassandra let you load only the column you need.

Also consider that Mongo DB is written in C++, and is at its second major release, while Cassandra needs to run on a JVM, and its first major release is in release candidate only since yesterday (but the 0.X releases turned in productions of major company already).

On the other hand, Cassandra's designed was partly based on Amazon Dynamo, and it is built at its core to be an High Availibility solution, but that does not have anything to do with the column-based format. MongoDB scales out too, but not as gracefully as Cassandra.

blocks|key|553670|text|主要区别在于文档存储(例如MongoDB和CouchDB)允许任意复杂的文档，即子文档内的子文档、带有文档的列表等，而列存储(例如Cassandra和HBase)只允许固定格式，例如严格的一级或二级字典。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|553671|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The main difference is that document stores (e.g. MongoDB and CouchDB) allow arbitrarily complex documents, i.e. subdocuments within subdocuments, lists with documents, etc. whereas column stores (e.g. Cassandra and HBase) only allow a fixed format, e.g. strict one-level or two-level dictionaries.

blocks|key|553723|text|我想说，主要的区别在于这些DB类型中的每一种物理存储数据的方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|553724|对于列类型，数据按列存储，这可以在特定列上实现有效的聚合操作/查询。|553725|对于文档类型，整个文档在逻辑上存储在一个位置，通常作为一个整体进行检索(不可能对“列”/“字段”进行有效的聚合)。|553726|令人困惑的一点是，宽列“行”可以很容易地表示为文档，但如上所述，它们以不同的方式存储并针对不同的目的进行优化。|553727|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I would say that the main difference is the way each of these DB types physically stores the data. 
With column types, the data is stored by columns which can enable efficient aggregation operations / queries on a particular column. 
With document types, the entire document is logically stored in one place and is generally retrieved as a whole (no efficient aggregation possible on &quot;columns&quot; / &quot;fields&quot;).
The confusing bit is that a wide-column &quot;row&quot; can be easily represented as a document, but, as mentioned they are stored differently and optimized for different purposes.

The three types of NoSQL databases I've read about is key-value, column-oriented, and document-oriented.

Key-value is pretty straight forward - a key with a plain value.

I've seen document-oriented databases described as like key-value, but the value can be a structure, like a JSON object. Each "document" can have all, some, or none of the same keys as another.

Column oriented seems to be very much like document oriented in that you don't specify a structure.

So what is the difference between these two, and why would you use one over the other?

I've specifically looked at MongoDB and Cassandra. I basically need a dynamic structure that can change, but not affect other values. At the same time I need to be able to search/filter specific keys and run reports. With CAP, AP is the most important to me. The data can "eventually" be synced across nodes, just as long as there is no conflict or loss of data. Each user would get their own "table".

How does column-oriented NoSQL differ from document-oriented?

数据丢失

SQL数据库

数据库

服务器

Cassandra

MongoDB

HBase

NoSQL

JSON

我读到过的三种类型的NoSQL数据库是键值、面向列和面向文档。Key-value非常简单--一个带有普通值的键。我见过像key-value这样的面向文档的数据库，但是值可以是一个结构，比如JSON对象。每个“文档”可以具有与另一个相同的所有、部分或不相同的关键字。面向列似乎与面向文档非常相似，因为您不需要指定结构。那么...

问面向列的NoSQL与面向文档的How有什么不同？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问面向列的NoSQL与面向文档的How有什么不同？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问面向列的NoSQL与面向文档的How有什么不同？
EN