面向对象的NoSQL与文档不同
我读过的三种NoSQL数据库是关键值，列导向和面向文档。
键值非常简单 - 一个明码标价。
我已经将面向文档的数据库描述为像键值一样，但是值可以是一个结构，就像一个JSON对象。 每个“文档”可以具有全部，部分或不具有与另一个相同的密钥。
面向列似乎非常像面向文档，因为你没有指定结构。
那么这两者之间有什么区别，为什么你会使用另一个呢？
我专门研究了MongoDB和Cassandra。 我基本上需要一个可以改变的动态结构，但不会影响其他值。 同时我需要能够搜索/过滤特定的键并运行报告。 对于CAP，AP对我来说是最重要的。 只要不存在冲突或数据丢失，数据可以“最终”跨节点同步。 每个用户将获得他们自己的“表”。
在Cassandra中，每行（由一个关键字寻址）包含一个或多个“列”。 列本身是键值对。 列名不需要预定义，即结构不固定。 一行中的列根据其键（名称）按排序顺序存储。
在某些情况下，您可能在一行中包含非常大量的列（例如充当启用特定种类查询的索引）。 Cassandra可以高效地处理这种大型结构，并且可以检索特定范围的列。
还有更高层次的结构（不常用）称为超级列，其中列包含嵌套（子）列。
你可以把整体结构看作是一个嵌套的散列表/字典，有2或3级密钥。
普通列族：
row
col col col ...
val val val ...
超级柱子系列：
row
supercol supercol ...
(sub)col (sub)col ... (sub)col (sub)col ...
val val ... val val ...
还有更高级别的结构 - 列族和密钥空间 - 可用于划分或分组数据。
另见这个问题：Cassandra：什么是子列
或http://wiki.apache.org/cassandra/ArticlesAndPresentations中的数据建模链接
Re：与面向文档的数据库进行比较 - 后者通常插入整个文档（通常是JSON），而在Cassandra中，可以对单个列或超级列进行处理，并分别进行更新，即它们以不同的粒度级别进行工作。 每列都有其自己的单独时间戳/版本（用于协调分布式群集中的更新）。
Cassandra列的值只是字节，但可以键入为ASCII，UTF8文本，数字，日期等。
当然，通过插入包含JSON的列，您可以将Cassandra用作原始文档存储 - 但您无法获得真正的面向文档的存储的所有功能。
主要区别在于文档存储（例如MongoDB和CouchDB）允许任意复杂的文档，即子文档中的子文档，文档列表等，而列存储（例如Cassandra和HBase）只允许固定格式，例如严格的单层或两级字典。
在“插入”中，要使用rdbms单词，基于文档的单词更加一致和直接。 请注意，与cassandra相比，您可以与法定人数概念保持一致，但这不适用于所有基于列的系统，并且会降低可用性。 在一次写入/读取往往很繁重的系统上，请去MongoDB。 如果你总是打算读取对象的整个结构，那么也要考虑它。 一个基于文档的系统被设计为当你得到它时返回整个文档，并且在整行的返回部分不是很强。
像Cassandra这样的基于列的系统比“更新”中的文档更好。 您甚至可以在不读取包含该列的行的情况下更改列的值。 写入不需要在同一台服务器上完成，一行可能包含在多台服务器的多个文件中。 在巨大的快速发展的数据系统上，请去Cassandra。 如果您打算每个密钥都有非常大的数据块，并且不需要在每个查询中加载所有数据，那么也要考虑它。 在“选择”中，Cassandra让你只加载你需要的列。
还要考虑到Mongo DB是用C ++编写的，并且是第二个主要版本，而Cassandra需要在JVM上运行，并且它的第一个主要版本仅在昨天发布候选版本（但是0.X版本转换为大公司已经）。
另一方面，Cassandra的设计部分基于Amazon Dynamo，它的核心是构建高可用性解决方案，但这与基于列的格式没有任何关系。 MongoDB也可以扩展，但不像Cassandra那样优雅。
链接地址: http://www.djcxy.com/p/86409.html