rdbms nosql_不是NoSQL与RDBMS，而是ACID +外键与最终一致性

rdbms nosql

背景

来自不同的背景并且处理过许多分布式系统，我经常遇到一种情况，我需要解释为什么由符合酸标准的RDBMS管理的外键（无论多么昂贵或太棒）都会导致可伸缩性问题这可能是极其昂贵的解决方案。 在开始之前，我还想澄清一个重要点，可伸缩性不等于二进制的是或否答案，可伸缩性应始终表示为每单位规模的成本，我将说明原因。

让我们使用常见Web体系结构的简化模型。

在此模型中，工作在应用程序服务器（计算）和数据库服务器（存储）之间划分。 如果我们假设外键需要在存储级别进行验证，那么无论我们的应用程序层如何可扩展，我们都将遇到存储扩展问题。 注意：Oracle RAC就是这种模型……总之，无论您添加多少个RAC节点，通常只扩展计算能力，而不是存储。

为了解决此问题，逻辑步骤是还要分配存储。 在这种情况下，模型会略有变化，并且开始看起来像这样。

在此模型中，分布式数据库解决方案（包括高端酸性兼容数据库，例如Oracle RAC或Exadata或IBM purescale）使用的模型中，信息存储分布在负责存储的节点之间，并且这些节点不共享磁盘。 在数据库扩展社区中，这是“无共享”架构。 为了进一步说明这一点，大多数分布式数据库在无共享架构中的工作方式是以下两种方式之一，对于每种数据，它们都是：

• 散列键并使用该散列查找具有数据的节点
• 使用主节点维护节点与数据的关联

那么，问题解决了吗？ 从理论上讲，特别是如果我使用的是非常快速/高效的哈希方法，则可以通过在适当的层上简单地添加更多节点来很好地扩展。

问题

问题与外键，ACID合规性以及它们产生的开销有关。 具有讽刺意味的是，这种开销实际上会对可伸缩性产生潜在的严重负面影响。 而且，我们对这种模型及其级别抽象的依赖经常使我们看不到瓶颈，并导致神秘的幻象减慢和性能不一致。

让我们首先回顾一下几件事（可以在这里找到更详细的背景信息，以供那些需要进一步阅读的人使用。

• 外键是一个表中的键与另一个表中的键的关系，为了成功进行更新或插入，必须存在外键（比这要复杂一些，但我们将使其保持简单）
• 遵循ACID是指一组关于交易含义的规则，但是在我们的上下文中，这意味着对于更新A，我必须查询信息B

碰巧的是，即使具有完美分区的无共享架构，如果我们需要保持ACID与外键的一致性，就会遇到一个特殊的问题。 如果更新A的密钥在一个节点上，而更新B的密钥在另一个节点上……我们需要在集群的各个节点之间进行查找。 避免此问题的唯一方法是…放弃外键和/或放宽对ACID的遵守。 的确，完善的前瞻性知识可能使我们能够设计数据存储装置，而这并不是真正的问题，但现实却并非如此。

因此，最终，当人们大声疾呼有关NoSQL如何比RDBMS更好时，他们实际上是在说他们要使用以下两种数据库：

• 符合ACID标准，因此无需使用外键
• 不符合ACID

从扩展性的角度来看，我认为我们有充分的理由这么做。

翻译自: https://www.javacodegeeks.com/2014/08/its-not-nosql-versus-rdbms-its-acid-foreign-keys-versus-eventual-consistency.html

rdbms nosql