【问题标题】:Relational vs Columnar and Document Databases - aren't they one in the same?关系数据库与列式数据库和文档数据库——它们不是一回事吗?
【发布时间】:2013-02-24 13:10:57
【问题描述】:

我了解面向文档的 NoSQL DB 是 KV 模型的“扩展”,因为它们允许您查询的不仅仅是单个查找键。但是一旦某个东西是“文档”,我觉得它已经包含了一个关系模型:

"myJson": {
    "fizz": 4,
    "buzz": "true",
    "widget" : {
        ...etc.
    }
}

对我来说,我看不出这个 JSON 与带有 fizzbuzz 字段的 json_objects 表以及与第二个 widgets 表的外键关系之间的区别。

像 Cassandra 这样的“列式”数据库听起来就像是直接的关系/表数据库。

所以我问:面向文档和面向列的 DB 有何不同,以及如何区分(与 RDBMS)?它们最适合解决哪些问题,使它们在某些情况下优于关系数据库?提前致谢!

【问题讨论】:

    标签: mongodb cassandra document-oriented-db column-oriented nosql


    【解决方案1】:

    首先我想说的是,您说NoSql 与关系数据库不同 是非常正确的,因此很难进行比较。话虽如此,两者之间有许多可以比较的重大区别。

    缩放
    尽管您可以对 MySql 数据库进行分片,但 issues 带有分片,enforcing ACID properties 当 RDMS 在多台机器上时将非常具有挑战性,像 Cassandra 这样的 NoSql 解决方案以其在某些情况下管理 400 nodes in a cluster 的能力而闻名没有问题。 Cassandra 数据库不仅易于扩展,而且性能也不会受到影响。

    架构(更少)模型。
    NoSQL 数据库系统旨在管理大量不遵循固定模式的数据。这意味着,例如,您希望向 Cassandra 中的现有列族添加新列,您无需返回并修改列族,因此无需这样做:

    ALTER TABLE table_name ALTER COLUMN column_name datatype;
    

    我们可以改为添加新列,并可能最终得到以下“表格”:

     key         | follower1  | follower2   | follower2          
    -------------+------------+-------------+-----------
     lyubent     | joeb       | chuckn      | gordonf     
     chuckn      | joeb       | gordonf                   
     gordonf     | chuckn                                 
     joeb        | chuckn     | lyubent     | joeb        
    

    这使数据模型变得灵活且易于扩展,但这样做数据变得不那么结构化。

    速度
    NoSql 数据库针对high write speeds 进行了优化,而 RDBM 的目标是高读取速度。但即使考虑到这一点,NoSql 解决方案在读取方面仍然倾向于outperform RDBMs 系统。这是因为 NoSql 数据库没有实现许多降低关系模型中读/写/更新操作的功能,例如 ACID 属性和事务。

    When should it be used?

    • 您的应用程序/网站需要快速发展,但您希望从小处着手。
    • 您更关心的是写入数据而不是读回数据。 (发布了很多推文,但并非所有推文都被阅读)
    • 系统的可用性比 100% 更新的数据更为重要。 (因此,如果您是银行,则不需要 NoSql,但如果您是需要 100% 正常运行时间的网站,它可能是一个不错的选择)
    • 如果正在写入的数据需要 100% 成功,但最终一致性不成问题。

    仅作为一个直观的说明,这对我理解不同的 sql 解决方案适合数据库世界的位置以及每种解决方案如何适合一个目的有很大帮助。

    【讨论】:

    • 该图完全错误,您不能拥有 CA db。如果它不是分区容错的,它就不能有 A。该图是由误解 CAP 定理的人绘制的。您不能选择 2,您需要在 C 或 A 之间进行选择。codahale.com/you-cant-sacrifice-partition-tolerance 该链接由 Brewer(CAP 定理的作者)发布。想想看,分布式MySql(sharded(有那个HBase没有吗?给我看一个MySql有可用性而HBase没有的场景。
    • RDBMS 系统保证一致性,分片使系统能够容忍分区。由定理可知,系统因此不能保证可用性,所以 RDBMS 系统是 CP。
    • @user1944408 批评总是很受欢迎,但是你说这个图是完全错误的,因为 HBase 和 MySql 在图中的位置。你忽略了其余的。该图像已在多个answers 中使用,请阅读this article 说明为什么将 MySql 放置为 CA 的理由,或者如果您不想......他们在那里进行比较,这是一个指南到 NoSql 数据库,而不是 RDBM。
    • 我知道那篇文章是错误的。它说 Postgres、MySQL 等传统 RDBMS 是 CA,这是不正确的。他们没有 A 属性。我也知道在许多答案中人们使用了这个错误的图表。互联网上有许多博客文章将 CAP 定理解释为“选择任何 2”,这是错误的,因此 Brewer 表示他将写一篇新论文来澄清为什么这是不正确的。他在论文中从未说过“选择任何两个”,那只是一种错误的解释。
    • 另外,这只是一个友好的批评,旨在澄清您帖子中的一个小问题。对于你写的所有其他内容,我都给了你 +1。
    【解决方案2】:

    在无模式数据库中,您没有固定的列和类型。

    例如,产品“牛仔裤”可以有属性“价格”、“长度”和“型号”(M/W),但对于产品书,您有属性“价格”、“作者”和“标题”。对于手机,您将拥有“屏幕类型”、“操作系统”等。

    在 RDBMS 中建模非常困难,因为您不灵活并且用户无法插入任意属性,因此使用针对此类数据优化的文档数据库更容易,以便您可以轻松地按值搜索和过滤任意属性(例如,所有长度>30 且型号=w 的产品)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-03-19
      • 2018-01-07
      • 2023-04-08
      • 1970-01-01
      • 2013-02-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多