在谈论MongoDB与Cassandra时，“面向文档”与键值是什么意思？

基于文档的NoSQL选项会如何在KV商店中为您带来收益，反之亦然？

一个key-value存储提供了最简单的数据模型和正是顾名思义：它是一个存储系统，用于存储值由密钥索引。您只能按键查询，并且值是不透明的，商店什么都不知道关于他们。这允许非常快速的读取和写入操作（简单的磁盘访问），我将此模型视为一种非易失性缓存（即，如果需要通过密钥访问长寿命数据进行快速访问，则非常适合）。

甲面向文档的数据库延伸先前模型和值被存储在一结构化的格式（文件，因此得名），该数据库可以理解。例如，文档可以是博客帖子，评论和标签以非规范化方式存储。由于数据是透明的，因此商店可以做更多的工作（例如文档的索引字段），而且您不仅限于按键查询。正如我所暗示的，此类数据库允许通过单个查询获取整个页面的数据，并且非常适合面向内容的应用程序（这就是为什么像Facebook或Amazon这样的大型网站都喜欢它们的原因）。

其他种类的NoSQL数据库包括面向列的存储，图形数据库甚至对象数据库。但这超出了问题。

也可以看看

• 将文档数据库与键值存储区进行比较
• NoSQL格局分析
• 考虑NoSQL数据库（分类和用例）

好吧，过去一个月左右，我一直在自己调查NoSQL。我认为通常可以这样说

• KV商店不知道密钥实际存储的值内容
• 基于数据库的文档使您可以在值内容中定义二级索引，因为数据库知道文档的结构（例如博客文章的标签）。
• 每个NoSQL解决方案都具有应考虑的特定功能，例如
  • KV存储中的特殊数据类型（例如，像redis一样具有左/右弹出/推入的集合）
  • 正如riak所说的那样，易于扩展/缩小集群（我还没有尝试过……）
  • 如Voldemort中的可插入数据存储
  • 内置的Web配置和Web应用程序支持，例如在CouchDB / couchapp中

面向文档的数据库或文档存储用于存储，检索和管理面向文档的信息，该信息是半结构化数据。键值存储是面向文档的数据库的继承。区别在于处理数据的方式。在键值存储中，数据对于数据库固有地是不透明的，而面向文档的系统则依靠文档中的内部结构来提取元数据，以便数据库引擎将其用于进一步优化。

如果我们讨论一下MOngoDb和Cassandra之间的区别。MongoDB的行为很像关系数据库。它的数据模型包括一个顶层数据库，然后是集合（例如，类似于MySQL中的表），然后是包含在集合中的文档（例如，MySQL中的行）。每个文档都有一个字段和一个值，与MySQL中的列和值相似。字段可以是简单的键/值，例如{'name'：'David Mytton'}，但它们还可以包含其他文档，例如{'name'：{'first'：David，'last'：'Mytton'}}。在Cassandra中，文档被称为“列”，实际上只是一个键和值。例如{'key'：'name'，'value'：'David Mytton'}。还有一个时间戳字段，用于内部复制和一致性。该值可以是单个值，但也可以包含另一个“列”。这些列然后存在于列族中，这些列族基于列中的特定值（由键引用）对数据进行排序。

但是，在顶层，有一个键空间，它类似于MongoDB数据库。