当谈论 MongoDB 和 Cassandra 时，“面向文档”和键值意味着什么？

小开

最大的区别是面向文档的数据库支持辅助索引，而 K/V 不支持。通常，面向文档的 dbs 倾向于允许更丰富的查询，允许范围查询、排序和其他类型的“高级”操作。

小开

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

KV 商店不知道价值实际为一个键存储的内容
基于文档使您可以定义次要的值内容中的索引，如数据库知道文档结构 (例如博客文章的标签)。
NoSQL 解决方案都有一些特定的特性，应该加以考虑，例如
- KV 存储中的特殊数据类型(例如，像 redis 中那样带有左/右弹出/推送的集合)
- 正如 Riak 所说的那样，可以轻松地向上/向下扩展集群(我还没有尝试过... ... 还没有)
- 伏地魔的可插式数据存储
- 内建的 web 配置和 web 应用程序支持，就像 CouchDB/couchapp

小开

最佳答案

键值存储器键值存储器提供了最简单的可能的数据模型，正如它的名字所暗示的那样: 它是一个存储系统，存储按键索引的值。您只能通过键进行查询，并且查询的值是 不透明，存储不知道关于它们的 什么都行。这允许非常快速的读写操作(一种简单的磁盘访问) ，我认为这种模型是一种非易失性缓存(也就是说，如果您需要通过键快速访问长寿命数据，这种模型非常适合)。

面向文档的数据库扩展了前面的模型，值以数据库可以理解的 结构化格式(文档，因此是名称)存储。例如，一个文档可以是一个博客文章还有的评论还有的标签存储在一个非规范化的方式。因为数据是 透明的，所以存储可以做更多的工作(比如为文档的字段建立索引) ，而且不受按键查询的限制。正如我所暗示的，这样的数据库允许通过单个查询获取整个页面的数据，并且非常适合面向内容的应用程序(这就是为什么像 Facebook 或亚马逊这样的大型网站喜欢它们)。

其他类型的 NoSQL 数据库包括 面向列的存储器、 图形数据库甚至 对象数据库。

参见

小开

在键-值数据库模型中，用户可以选择键是什么，而文档文档模型中的标识符通常是系统生成的。
键-值数据库模型中的键-值对不能分组，而在在文档数据库中，我们可以将键值对分组到单独的文档中; 文档数据库的形式甚至允许我们将这些文档进一步分组，即分为所以，称为“集合”或“域”。
而文档数据库中的文档有一个内部结构，这是显而易见的定义(因此，可以由 DBMS 操作; 例如，创建索引) , 键-值数据库中的值的情况则不同，因为其中任何可能的内部从 DBMS 的角度来看，这些值的结构是不透明的。
在键-值模型中，访问多个数据库条目(在本例中是键-值对) 另一方面，在文档模型中，需要多个数据库条目(在这种情况下是文档)可以在单个请求中检索。