是什么使Cassandra（以及NoSQL）成为RDBMS的更好的解决方案？

嗯，NoSQL现在是一个流行词，所以我一直在研究它。我还没开始考虑家庭和超级柱等等。。。但我一直在研究数据是如何映射的

在阅读了这篇文章和其他文章之后，数据似乎是以类似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而不是RDBMS？”

另一方面，正如我所说，我仍然不完全理解如何实现Cassandra数据库。即，如何在新数据库中创建上述用户表？任何教程，文档等，你可以指向将是伟大的。我的谷歌搜索在“从无到有”方面并没有太大进展

我想我要问的是“什么时候我应该选择NoSQL而不是RDBMS？”

[注意：我以前从未读过NoSQL]

---

据介绍，NoSQL不擅长连接：这意味着（对我来说）没有引用完整性和规范化。

NoSQL的优点是它更简单，如果你有OO指示灯，它可以满足你所有的持久性需求

基于SQL的实时数据库的优点是，您可以轻松地以原始设计中未设想的方式重用和扩展数据。此外，“对象”数据库在执行类似于SQLs聚合查询（如COUNT、SUM、AVG）时往往表现得非常糟糕（即使可能）

---

Google BIGTABLE是世界上最大的OO数据库（可能也是最大的数据库周期），它还支持SQL和SQL特性，如索引和强类型

我能想到的最简单的答案是：当您的数据不符合关系模型时。

NoSQL的主要优点是水平可扩展性和分布式存储。这意味着您可以拥有大量的“集群节点”，并并行写入它们。集群将确保更改最终传播到其他集群节点（最终一致性）

---

NoSQL与SQL无关（术语的意思是“不仅仅是SQL”）。事实上，一些NoSQL产品确实支持SQL的一个子集。数据格式不同的原因（JSON或属性/值对列表与表格数据）是：在关系数据库中，列数（和列名）是在中心位置定义的，这与水平可伸缩性不匹配（需要停止所有集群节点进行模式更改）。此外，连接不太受支持，因为这会破坏水平可伸缩性（如果数据是分布式的，则可能需要读取来自多个群集节点的数据）。

RDBMS'都是关于一致性的。他们在数据方面做得很好，这些数据在交易中被大量搅动。另见酸性（原子性、一致性、隔离性、耐久性）。有时，您不需要所有这些，比如在存储日志中的数据或处理不会改变的数据时，只需累积即可

---

NoSQL数据库可以让您放松对事务的要求，并获得更好的性能（以及更容易扩展到大型分布式存储库）。

如果您是google，那么NoSQL可能比RDBMS更适合您。由于您不是，RDBMS提供的许多优势可能会有一些用处。值得注意的是，在单个节点上，NoSQL绝对没有RDBMSE的优势。不过，RDBMS与NoSQL相比有很多优势。它们是什么

RDBMS使用一些非常深刻的魔法来理解它所拥有的数据，以及您所需要的数据，以使它能够以最有效的方式返回这些数据。如果您没有询问某个列，rdbms不会浪费任何精力来检索它。如果您对两个表中具有公共字段的行感兴趣（顺便说一句，这是一个连接），RDBMS不必检查每一对行的匹配情况，或者NoSQL db通常只需提供所有信息并让您进行检查。使用RDBMS，您通常可以构造实际上“关于”正在使用的数据的查询，如“如果日期是星期二”，如果您的索引支持它（如果您经常进行该查询，那么您将添加这样的索引），则可以高效地获取这些行

---

RDBMS很好还有另一个原因。事务在RDBMS上很容易实现，但在NoSQL数据库上很难实现。假设您正在实现一个博客引擎。假设帖子标题（出现在URL中）需要在所有帖子中都是唯一的。在RDBMS中，您可以很容易地确定不会意外地出错。对于NoSQL数据库，如果它确实支持某种事务完整性，那么它通常是在碎片级别，任何可能需要这种完整性的东西都必须在同一个碎片上。因为任何一对用户都可能在同一时刻发布，所以每个用户的帖子必须在同一个碎片上才能获得相同的效果。好吧，那么你从NoSQL中根本得不到任何好处

NoSQl数据库适用于一些不需要事务处理或一致性的网站，您所做的只是提供一些数据（但在您变得非常大之前，它们并不是非常需要）

但如果您需要强制执行财务规则（或其他复杂的数据完整性规则）或内部控制，或报告和聚合数据以进行报告，则需要RDBMS。我敢打赌，即使是谷歌也会将RDBMS用于自己的人力资源和财务数据等

对于某些web应用程序，您甚至可能需要两者的组合：用于某些类型信息的nosql数据库、用于订单的事务关系数据库以及其他事务一致性为