NoSQL 数据库无法处理的任务示例（如果有）答案

【问题标题】：Example of a task that a NoSQL database can't handle (if any)NoSQL 数据库无法处理的任务示例（如果有）
【发布时间】：2011-07-23 05:59:18
【问题描述】：

我想测试 NoSQL 世界。这只是好奇，而不是绝对需要（还）。我已经阅读了一些关于 SQL 和 NoSQL 数据库之间差异的内容。我对潜在的优势深信不疑，但我有点担心 NoSQL 不适用的情况。如果我理解 NoSQL 数据库基本上错过了 ACID 属性。

有人可以举一个 ACID 关系数据库可以处理但 NoSQL 数据库可能会惨遭失败的现实世界操作（例如电子商务网站、科学应用程序或...）的示例，或者系统地由于某种竞争条件或停电等原因？

完美的例子是在不修改数据库引擎的情况下无法解决任何问题。 NoSQL 数据库性能不佳的示例最终将是另一个问题，但在这里我想看看理论上我们何时不能使用这种技术。

也许找到这样的例子是特定于数据库的。如果是这样，让我们以 MongoDB 来代表 NoSQL 世界。

编辑：为了澄清这个问题，我不想争论哪种数据库更适合某些情况。我想知道这项技术在某些情况下是否会成为绝对的死胡同，因为无论我们如何努力尝试 SQL 数据库提供的某些功能无法在 nosql 存储之上实现。由于有许多可用的 nosql 存储，我可以接受选择现有的 nosql 存储作为支持，但我最感兴趣的是存储应该提供的功能的最小子集，以便能够实现更高级别的功能（比如可以使用不提供 X...) 的商店。

【问题讨论】：

尝试在任何 NoSQL 人群中编写类似总账（簿记）应用程序......不太适合。
这个问题是关于数据库理论的，有具体的应用程序（如果证明没有解决方案，就知道什么时候不值得尝试为现实世界的问题找到解决方案）。这绝对是关于事实，而不是关于哪种技术更好的主观辩论

标签： mongodb rdbms acid nosql

【解决方案1】：

这个问题有点像问什么样的程序不能用命令式/函数式语言编写。任何图灵完备的语言，并表达每一个可以通过图灵机加工解决的程序。问题是你作为程序员真的想用非便携式机器指令为财富 500 强公司编写会计系统吗？

归根结底，NoSQL 可以做任何基于 SQL 的引擎可以做的事情，不同之处在于作为程序员的你可能负责 MySQL 免费提供给你的 Redis 之类的逻辑。 SQL 数据库对数据完整性采取非常保守的观点。 NoSQL 运动放宽了这些标准，以获得更好的可扩展性，并使 Web 应用程序常见的任务更容易。

MongoDB（我目前的偏好）使复制和分片（水平扩展）变得容易，插入速度非常快，并且不需要严格的方案。作为交换，MongoDB 的用户必须在不存在索引时围绕较慢的查询编写代码，在应用程序中实现事务逻辑（可能需要三阶段提交），并且我们会影响存储效率。

CouchDB 有类似的权衡，但也牺牲了即席查询，以便能够离线处理数据然后与服务器同步。

Redis 和其他键值存储要求程序员编写 SQL 数据库中内置的大部分索引和连接逻辑。作为交换，应用程序可以利用有关其数据的领域知识来使索引和连接比 SQL 所需的通用解决方案更有效。 Redis 还要求所有数据都适合 RAM，但作为交换，它的性能与 Memcache 相当。

最后，您真的可以使用 OS 文件系统命令来完成 MySQL 或 Postgres 所做的所有事情（毕竟编写这些数据库引擎的人就是这样做的）。这一切都取决于您希望数据存储为您做什么以及您愿意放弃什么作为回报。

【讨论】：

说得好，约翰。这是我没有明确指出的一点。数据完整性、强类型化、关系完整性、安全性和查询接口在大多数情况下都是必须在应用层完成的，如果你需要的话。
@Jonh F. Miller：考虑到您提到的三阶段提交，应用程序是否可以通过数据库实现这一点（即在某个表中写入一些内容以指示新事务等）还是他们需要在与数据库引擎通信之前独立通信（例如与 tcp，不使用 MongoDB）？
@ascobol：这取决于事务，但一般情况下，不需要在数据库之外进行通信。
@Jonh F. Miller：谢谢。我在这里找到了一个两阶段提交的示例。事实上，应用程序之间不需要通信。 mongodb.org/display/DOCS/two-phase+commit你有三阶段提交的链接吗？

【解决方案2】：

好问题。首先澄清一下。虽然关系存储领域由相当坚实的原则基础组成，每个供应商都选择在功能或定价方面增加价值，但非关系 (nosql) 领域的异构性要大得多。

有一些文档存储（MongoDB、CouchDB）非常适合内容管理和类似情况，在这些情况下，您需要围绕某个主题构建一组扁平的变量属性。采取网站定制。使用文档存储来管理定义用户希望查看其页面的方式的自定义属性非常适合该平台。尽管他们在营销上大肆宣传，但这些商店的规模并没有那么好。可以做到，但并不理想。 MongoDB 有很多关系数据库中的特性，例如动态索引（每个集合/表最多 40 个）。 CouchDB 被构建为在发生故障时绝对可恢复。

有非常适合高度分布式存储的键/值存储（Cassandra、HBase...）。 Cassandra 用于低延迟，HBase 用于更高延迟。这些技巧是您必须在开始输入数据之前定义查询需求。它们对于针对任何属性的动态查询效率不高。例如，如果您正在构建客户事件记录服务，您可能希望将密钥设置在客户的唯一属性上。从那里，您可以将各种日志结构推送到您的存储中，并根据需要通过客户密钥检索所有日志。但是，除非您决定将其设置为辅助键，否则尝试通过日志查找类型为“失败”的日志事件会更加昂贵。另一件事：我上次查看 Cassandra 时，您无法在 M/R 查询中运行 regexp。这意味着，如果您想在一个字段中查找模式，您必须提取该字段的所有实例，然后通过正则表达式运行它以找到您想要的元组。

图形数据库与上述两个非常不同。项目（对象、元组、元素）之间的关系是流动的。它们不会扩展到 TB，但这不是它们的设计目的。它们非常适合提出诸如“嘿，我的用户中有多少喜欢绿色？其中有多少人住在加利福尼亚？”之类的问题。使用关系数据库，您将拥有静态结构。使用图形数据库（当然，我过于简单化了），您就有了属性和对象。您可以合理地连接它们，而无需强制执行架构。

我不会将任何重要的东西放入非关系型存储中。例如，在商业领域，您希望在交付产品之前保证交易已完成。您想要保证完整性（或至少有保证完整性的最佳机会）。如果用户丢失了他/她的站点自定义设置，没什么大不了的。如果你失去了一笔商业交易，那就大不了了。可能有些人不同意。

我也不会将复杂的结构放入上述任何非关系存储中。他们不能很好地进行大规模连接。而且，这没关系，因为这不是他们应该工作的方式。如果您可能将 address_type 的身份放入关系系统中的 customer_address 表中，您可能希望将 address_type 信息嵌入存储在文档或键/值中的客户元组中。数据效率不是文档或键/值存储的领域。重点是分布和纯粹的速度。牺牲就是足迹。

还有其他标记为“nosql”的商店系列子类型，我在这里没有介绍。有大量（最后统计为 122 个）不同的项目专注于针对各种类型的数据问题的非关系解决方案。 Riak 是我一直听说的另一个，迫不及待想尝试一下。

这就是诀窍。大额关系供应商一直在关注，而且很有可能，他们都在构建或计划构建自己的非关系解决方案以与他们的产品相结合。在接下来的几年里，如果不是更早的话，我们将看到这一运动变得成熟，大公司收购了最好的品种，关系供应商开始为那些还没有的供应商提供集成解决方案。

在数据管理领域工作是一个非常激动人心的时刻。你应该尝试其中的一些。您可以下载 Couch 或 Mongo 并在几分钟内启动并运行它们。 HBase 有点难。

无论如何，我希望我在没有混淆的情况下告知我，我已经开悟了，没有明显的偏见或错误。

【讨论】：

【解决方案3】：

RDBMS 擅长连接，而 NoSQL 引擎通常不擅长。 NoSQL 引擎擅长分布式可扩展性，RDBMS 通常不擅长。

RDBMS 擅长数据验证约束，而 NoSQL 引擎通常不擅长。 NoSQL 引擎擅长灵活且无模式的方法，RDBMS 通常不擅长。

这两种方法都可以解决任何一组问题；区别在于效率。

【讨论】：

【解决方案4】：

您的问题的可能答案是 mongodb 可以处理任何任务（也可以处理 sql）。但是在某些情况下最好选择mongodb，在其他情况下选择sql数据库。关于优缺点可以阅读here。

正如 @Dmitry 所说，mongodb 敞开大门，通过复制和分片轻松实现水平和垂直扩展。

【讨论】：

【解决方案5】：

RDBMS 强制执行强一致性，而大多数 no-sql 最终是一致的。因此，在从 no-sql 数据库读取数据的给定时间点，它可能不代表该数据的最新副本。

一个常见的例子是银行交易，当用户取款时，节点A会更新这个事件，如果同时节点B查询这个用户的余额，它可以返回一个过期的余额。这在 RDBMS 中不会发生，因为一致性属性保证数据在被读取之前已经更新。

【讨论】：

您对很多 NoSQL 技术都是正确的，但如果您愿意，MongoDB 尤其可以提供强一致性语义。您还可以在集群设置中使用 MongoDB 以实现最终一致性。用户拥有完全控制权，并且可以根据用例以任何一种方式使用它。

【解决方案6】：

RDBM 非常适合从表中快速汇总总和、平均值等。例如SELECT SUM(x) FROM y WHERE z。如果您想立即获得答案，这在大多数 NoSQL 数据库中是非常难以做到的。一些 NoSQL 存储提供 map/reduce 作为解决同一问题的一种方式，但它不像在 SQL 世界中那样是实时的。

【讨论】：