Question

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

阅读this文章和其他文章后，似乎数据以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在“从头开始”方面并没有太多变化......

Answer 1

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

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

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

Answer 2

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

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

Answer 3

NoSQl数据库适用于某些您不需要事务或一致性的网站，其中您所做的只是呈现一些数据（但在您真正变大之前，它们并不是非常需要）。

但是，如果您需要强制执行财务规则（或其他复杂数据完整性规则）或内部控制或报告和汇总数据以进行报告，则需要RDBMS。我敢打赌，即使Google使用RDBMS来获取他们自己的人力资源和财务数据等等。

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

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

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

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

Answer 4

答案很简单。如果您需要数据存储 - 使用NoSQL，如果您需要更多功能，那么只需存储数据 - 使用RDBMS。

Answer 5

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

[警告：我以前从未读过关于NoSQL的内容]

根据Wikipedia，NoSQL不擅长连接：这意味着（对我而言）没有参照完整性，也没有规范化。

Answer 6

NoSql的优势在于它更简单，如果你有你的OO眼罩就满足了你所有的持久性需求。

基于SQL的实际数据库的优势在于，您可以轻松地以原始设计中未设想的方式重复使用和扩展数据。当您想要执行等同于SQL聚合查询（如COUNT，SUM，AVG）时，“对象”数据库往往执行得非常糟糕（即使它可能）。

谷歌BIGTABLE是任何地方最大的OO数据库（可能是最大的数据库时期）也支持SQL和sql功能，如索引和强类型。

Answer 7

RDBMS'都是关于一致性的。他们在数据上做得非常好，这些数据很容易被交易所搅动。另请参见ACID（原子性，一致性，隔离性，耐久性）。有时你并不需要所有这些，比如从日志中存储数据或处理不会改变的数据时，只需积累。

NoSQL数据库可以让您放松交易要求并获得更好的性能（以及更轻松地扩展到大型分布式存储孤岛）。

Answer 8

关于NoSQL提到的很多书，并不是关于哪个数据库比另一个更好。它更符合您的需求。

正如大家在其他答案中所说的那样，许多NoSQL数据库支持水平可扩展性，并且专注于高可用性，但它们并不总是最适合您的需求。

例如，Cassandra非常适合在群集中添加或删除节点，从而实现高可扩展性。但是当你在一个只有一个节点（一个服务器）的环境中比较Cassandra和MySQL，并且没有分布式架构时，没有很多不同，因为没有使用Cassandra的主要优点。

现在，为什么要使用SQL？最常见的原因是交易管理。目前，没有流行的NoSQL数据库本身支持事务。您可以模拟它们，但它们不像大多数SQL数据库那样是本机功能的一部分。

对于Cassandra，https://academy.datastax.com

提供全面免费培训

在那里，你不会只找到安装和配置Cassandra的培训，而是使用它的工具。它甚至可以为您提供完成证书。

Datastax有自己的Cassandra发行版，但它遵循与Apache项目相同的指导原则;它提供了一些额外的工具。

Answer 9

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

Answer 10

我在OSCON上发表了关于何时NoSQL可能是正确选择的讨论，以及一些需要注意的不同子类：http://assets.en.oreilly.com/1/event/45/The%20NoSQL%20Ecosystem%20Presentation.pdf

Answer 11

Cassandra本身并不比RDBMS好。在某些情况下更好。 RDBMS非常适用于事务处理，主数据管理，参考数据，数据仓库和（某些形式的）BI。

如果您的应用程序需要灵活的架构，可变长度的行，可变类型的列，最终的完整性，商用服务器上的水平可伸缩性以及通过分布式架构实现的高可用性，请使用NOSQL。

NOSQL由于以下几个原因不进行连接：您已经在加载NOSQL文件之前加入了数据，因此不需要;因为远程服务器上的分布式连接会占用大量资源。上面的第一个原因很简单：您已将所需的所有数据嵌入到单个结构中。如果您没有嵌入数据并且必须链接，那么不要期望它具有很好的性能。链接是应用程序提供的连接的委婉说法，没有像连接那样整合数据的好处。假设散列密钥是数据分发的方法，则具有相同散列密钥的不同记录将被并置。因此，如果允许加入，则连接的数据将全部在同一服务器上。

这不仅仅是黑与白。

Answer 12

如果您不到50岁，并且拥有容错，高可用性，高度可扩展，最终一致的存储系统，可以使用Cassandra，该存储系统可以随着您的初创企业无限扩展至大数据。

如果您的年龄超过50岁，仍然使用旧的方法，并且不想学习新知识并且快要退休了，请使用SQL。如果您不在那里，可伸缩性就没关系。

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

12 个答案: