【问题标题】:What does "Document-oriented" vs. Key-Value mean when talking about MongoDB vs Cassandra?在谈论 MongoDB 和 Cassandra 时,“面向文档”与键值是什么意思?
【发布时间】:2011-03-04 00:36:53
【问题描述】:

与 KV 存储相比,基于文档的 NoSQL 选项会给您带来什么好处,反之亦然?

【问题讨论】:

标签: mongodb cassandra nosql


【解决方案1】:

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

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

【讨论】:

    【解决方案2】:

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

    面向文档的数据库扩展了先前的模型,并且值以数据库可以理解的结构化格式(文档,因此得名)存储。例如,一个文档可以是一篇博文和 cmets 和以非规范化方式存储的标签。由于数据是透明的,存储可以做更多的工作(如索引文档的字段),并且您不限于按键查询。正如我所暗示的,此类数据库允许通过单个查询获取整个页面的数据,并且非常适合面向内容的应用程序(这就是 Facebook 或 Amazon 等大型网站喜欢它们的原因)。

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

    另见

    【讨论】:

    • 键值存储不必通过磁盘访问完成,在某些实现中称它们为非易失性是不正确的。您可以在内存中创建键值存储,无需直写或回写到非易失性存储介质。将数据称为长期存在的数据也具有误导性,因为数据的生命周期与您检索它的方式无关。
    • 这个定义可能有点用词不当。基本上两者都只是键值存储。在一种情况下,“值”是不透明的,数据库不知道在值中放入了什么——只能通过键查询。在另一种情况下(“文档”),数据库可以更好地理解值中的内容,并且可以根据值的某些属性生成索引等,并在以后查询..
    【解决方案3】:
    1. 在键值数据库模型中,用户可以选择键是什么,而文档 文档模型中的标识符通常是系统生成的。

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

    3. 虽然文档数据库中的文档具有明确的内部结构 定义(因此,可以由 DBMS 操作;例如,创建索引), 键值数据库中的值并非如此,其中任何可能的内部 从 DBMS 的角度来看,这些值的结构是不透明的。

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-09-21
      • 1970-01-01
      • 2011-06-23
      • 1970-01-01
      • 1970-01-01
      • 2010-12-17
      相关资源
      最近更新 更多