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

Question

基于NoSQL选项的文档会让您通过KV商店购买，反之亦然？

Answer 1

键值存储提供了最简单的数据模型，正如其名称所暗示的那样：它是一个存储系统，用于存储由键索引的值。您只能按键查询，而值不透明，商店不知道任何。这允许非常快速的读写操作（简单的磁盘访问），我将此模型视为一种非易失性缓存（即如果需要通过密钥快速访问长期数据，则非常适合）。

面向文档的数据库扩展了以前的模型，值以数据库可以理解的结构化格式（文档，因此名称）存储。例如，文档可以是博客文章和评论和以非规范化方式存储的标记。由于数据是透明，因此商店可以执行更多工作（例如索引文档的字段），并且您不仅限于按键查询。正如我所暗示的，这样的数据库允许通过单个查询获取整个页面的数据，并且非常适合面向内容的应用程序（这就是像Facebook或亚马逊这样的大型网站喜欢它们的原因）。

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

另见

• Comparing Document Databases to Key-Value Stores
• Analysis of the NoSQL Landscape
• Thinking about NoSQL databases (classification and use cases)

Answer 2

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

• KV商店不知道价值 实际为密钥存储的内容
• 基于文档可让您定义辅助 值内容中的索引，如 db知道文档结构 （例如博客文章的标签）。
• NoSQL解决方案每个都有特定的功能，应该加以考虑，例如
  • KV商店中的特殊数据类型（例如，使用redis中的左/右pop / push设置）
  • 像riak所说的那样轻松扩大/缩小集群（我还没试过......）
  • 可插拔数据存储，如Voldemort
  • 内置Web配置和Web应用程序支持，如CouchDB / couchapp

Answer 3

面向文档的数据库或文档存储用于存储，检索和管理面向文档的信息，这是半结构化数据。 键值存储是Document Oriented数据库的继承。 不同之处在于数据的处理方式;在键值存储中，数据被认为对数据库本身是不透明的，而面向文档的系统依赖于文档中的内部结构，以便提取数据库引擎用于进一步优化的元数据。

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

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

Answer 4

1. 在键值数据库模型中，用户可以选择键是什么，而文档 文档模型中的标识符通常是系统生成的。

2. 键值数据库模型中的键值对不能分组，而在 在文档数据库中，我们可以将键值对分组为单独的文档；而且，一些 文档数据库的形式使我们甚至可以将这些文档进一步分组，即 因此，称为“集合”或“域”。

3. 尽管文档数据库中的文档具有清晰的内部结构 定义（因此可以由DBMS进行操作；例如，以创建索引）， 对于键值数据库中的值，情况可能并非如此 从DBMS的角度来看，这样的值的结构是不透明的。

4. 在键值模型中，访问多个数据库条目（在这种情况下为键值对） 需要单独的请求。另一方面，在文档模型中，多个数据库 条目（在这种情况下为文档）可以在单个请求中检索。