是什么让Cassandra(以及NoSQL一般)成为RDBMS的更好解决方案？

好吧,NoSQL现在是一个流行语,所以我一直在研究它.我还没有理解ColumnFamilies和SuperColumns等...但我一直在研究数据是如何映射的.

看完这个文章,和其他人,似乎数据在像格式的JSON映射.

Users = {
    1: {
        username: "dave",
        password: "blahblah",
        dateReged: "1/1/1"
    },
    2: {
        username: "etc",
        password: "blahblah",
        dateReged: "2/1/1",
        comment: "this guy has a comment and dave doesns't"
    },
}

RDBMS格式为:

Table name: "Users"

id | username | password | dateReged | comment
---+----------+----------+-----------+--------
 1 |  dave    | blahblah |  1/1/1    |
---+----------+----------+-----------+--------
 2 |  etc     | blahblah |  2/1/1    | this guy has a comment and dave doesn't

假设我理解正确并且上面的示例是正确的,为什么我会选择RDBMS设计而不是NoSQL设计？就个人而言,我更愿意使用JSON结构......这是否意味着我应该选择NoSQL而不是MySQL？

我想我要问的是"我什么时候应该选择NoSQL over RDBMS？"

另外,正如我所说,我还没有完全理解如何实现Cassandra数据库.即,如何在新数据库中创建上述Users表？您可以指出的任何教程,文档等都会很棒.我的google'ing在"从头开始"方面并没有太多变化......

1> SingleNegati..：

---

如果你是谷歌,那么你可能会比你的RDBMS更容易使用NoSQL.既然你没有,RDBMS为你提供的许多优点可能会有所帮助.值得注意的是,在单个节点上,NoSQL完全没有优于RDBMS的优势.但是,与NoSQL相比,RDBMS提供了许多优势.这些是什么？

RDBMS使用一些非常深刻的魔法来理解它拥有的数据以及您要求的数据,以便能够以最有效的方式返回数据.如果您没有询问某些列,rdbms不会浪费任何检索它的工作.如果您对两个表中具有相同字段的行感兴趣(这是一个连接,顺便说一句),RDBMS不必检查每一对匹配行,或者NoSQL数据库通常做的只是给出你做的一切,让你做检查.使用RDBMS,您通常可以构建实际上与您正在使用的数据相关的查询,例如"如果日期是星期二",并且如果您的索引支持它(如果您执行该查询,那么您将添加这样的index)你可以有效地获得这些行.

RDBMSs还有另外一个原因.在RDBMS上交易很容易,但在NoSQL数据库上更难找到.假设您正在实施博客引擎.假设帖子标题(显示在URL中)需要在所有帖子中都是唯一的.在RDBMS中,您可以轻松确保不会意外地弄错.使用NoSQL数据库,如果它确实支持某种事务完整性,它通常在分片级别,任何可能需要这种完整性的东西必须在同一个分片上.由于任何一对用户都可能在同一时间发布,因此每个用户的帖子必须位于同一个分片上才能获得相同的效果.好吧,那么你从NoSQL中得不到任何好处.

---

"值得注意的是,在单个节点上,NoSQL完全没有优于RDBMS的优势.但是,与NoSQL相比,RDBMS提供了许多优势.这些是什么？' - erm No.一个例子:MongoDB的写入时间明显快于MS SQL服务器的写入时间.它有点误导,规定没有优势.它可能不适合此目的,但如果您追求速度,那么它就有优势.

---

是的,无模式是不同的.问题是关于为什么这是一件好事？我对无模式设置有点怀疑.从理论上讲,它使更改变得更容易.在数据库级别,当然可以,您不必花费任何长度来添加或删除该级别的属性.另一方面,它不会以任何方式使数据库迁移的语义结果变得更容易.处理可能为null的字段时,正确的行为是什么？无模式并没有丝毫减轻这一点.

---

MongoDB是无模式的,这在单个节点上也是一个很大的区别.

2> Thomas Muell..：

---

NoSQL的主要优点是水平可伸缩性和分布式存储.这意味着您可以拥有大量"群集节点"并并行写入它们.群集将确保最终将更改传播到其他群集节点(最终一致性).

NoSQL并不是关于SQL(这个术语意味着"不仅仅是SQL").事实上,一些NoSQL产品确实支持SQL的一个子集.数据格式不同(JSON或属性/值对列表与表格数据)的原因是:在关系数据库中,列(和列名称)的数量在中心位置定义,这对于水平不起作用可伸缩性(您需要停止所有集群节点以进行架构更改).此外,不支持连接,因为这会破坏水平可伸缩性(如果数据是分布式的,则可能需要读取来自多个群集节点的数据).

---

而Oracle,DB2,SqlServer,Teradata等不支持群集？好吧不是在1992年之前.

---

它们确实支持群集,但它们也不支持水平可伸缩性,因为它们试图支持所有ACID属性.NoSQL产品不会尝试支持所有ACID功能.有人说NoSQL真的意味着NoACID:http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html

3> HLGEM..：

---

NoSQl数据库适用于某些您不需要事务或一致性的网站,其中您所做的只是呈现一些数据(但是直到您真的非常大,它们才真正非常需要).

但是,如果您需要实施财务规则(或其他复杂数据完整性规则)或内部控制或报告和汇总数据以进行报告,则需要RDBMS.我敢打赌,即使谷歌使用RDBMS'来获取他们自己的人力资源和财务数据等.

对于某些Web应用程序,您甚至可能需要两者的组合,用于某些类型信息的nosql数据库,用于订单的事务关系数据库以及必须具有事务一致性的其他事物.

如果您开发网站,我认为在选择如何处理任何新功能之前,您需要彻底了解这两种类型的数据库及其背后的需求.

在我看来,你几乎不了解关系数据库,宁愿做一些对你个人而言比对项目更合适的事情.也许我没有正确阅读,但任何从未使用过连接的人都会对理解关系数据库感到怀疑.

你不是根据哪一个看起来更容易理解或哪个是本月的流行语来决定这两者,你根据所需的功能决定它们,不仅仅是用户界面,还有管理任务,报告,财务或其他类型的数据审计,政府监管,硬件故障时的数据恢复等.