面向列的NoSQL与面向文档有何不同？

Question

我读过的三种类型的NoSQL数据库是键值,面向列和面向文档.

键值非常简单 - 具有普通价值的键.

我已经看到面向文档的数据库被描述为键值,但值可以是一个结构,就像一个JSON对象.每个"文档"可以包含全部,一些或不具有与另一个相同的键.

面向列似乎非常像文档导向,因为您没有指定结构.

那么这两者之间有什么区别,为什么你会使用另一个呢？

我特意看了MongoDB和Cassandra.我基本上需要一个可以改变的动态结构,但不会影响其他值.同时,我需要能够搜索/过滤特定密钥并运行报告.有了CAP,AP对我来说是最重要的.只要没有冲突或数据丢失,数据就可以"最终"跨节点同步.每个用户都会得到他们自己的"桌子".

Answer 1

主要区别在于文档存储(例如MongoDB和CouchDB)允许任意复杂的文档,即子文档中的子文档,文档列表等,而列存储(例如Cassandra和HBase)仅允许固定格式,例如严格的一级或两级词典.

Answer 2

在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作为原始文档存储 - 但是您不会获得真正面向文档的存储的所有功能.

Answer 3

在"插入"中,要使用rdbms单词,基于文档的更加一致和直接的前瞻性.请注意,与cassandra相比,您可以实现与仲裁概念的一致性,但这不适用于所有基于列的系统,并且会降低可用性.在一次写入/读取常常很重的系统上,转到MongoDB.如果你总是计划阅读对象的整个结构,也要考虑它.基于文档的系统设计用于在获得整个文档时返回整个文档,并且在返回整行的部分时不是很强.

像Cassandra这样的基于列的系统比"更新"中的基于文档的方式更好.您可以更改列的值,甚至不读取包含它的行.写操作实际上不需要在同一台服务器上完成,一行可能包含在多个服务器的多个文件中.在巨大的快速发展的数据系统上,去找Cassandra.如果您计划每个密钥拥有非常大的数据块,并且不需要在每个查询中加载所有数据,请考虑它.在"选择"中,Cassandra允许您仅加载所需的列.

还要考虑Mongo DB是用C++编写的,并且是第二个主要版本,而Cassandra需要在JVM上运行,它的第一个主要版本仅在昨天发布候选版本(但0.X版本转向了主要公司已经).

另一方面,Cassandra的设计部分基于Amazon Dynamo,它的核心是高可用性解决方案,但这与基于列的格式没有任何关系.MongoDB也可以扩展,但不像Cassandra那样优雅.