是什么阻碍了关系数据库的水平扩展？

Question

当我在互联网上研究关系数据库的水平扩展时，我的印象是，包括写入扩展和读取扩展的唯一选项是分片，这似乎是一个手动设计过程，涉及复杂的应用程序特定配置，并且很难实现如果您需要更改分片结构，请维护。

另一方面，NoSQL 似乎原生支持水平扩展，但它有不支持事务、ACID 等的缺点。

最近似乎流行的另一个概念是 NewSQL 数据库。这些数据库有望达到最佳效果，既符合 ACID 标准，又能够通过自动分片或其他创新架构进行水平扩展。

我的问题是，如果我们将 SAN 与关系数据库一起使用，那么向集群添加更多数据库服务器并向 SAN 添加更多磁盘是否可以实现水平扩展？（添加磁盘会增加磁盘总IOPS和吞吐量以及磁盘空间。）那里会有什么瓶颈，以至于我们需要使用NewSQL数据库来实现ACID和水平扩展？

Answer 1

关系数据库中的水平扩展很难实现，因为当表（或同一个表的分片）跨不同的集群节点时，连接通常会变得非常低效。此外，还存在复制和保持 ACID 保证同时确保所有副本都具有最新数据的问题。然而，有一种可以水平扩展的RDBMS—— MySQL Cluster。来自文档：

MySQL Cluster 自动跨节点对表进行分片（分区），使数据库能够以低成本水平扩展。

MySQL 集群中的自动分片

与其他分片数据库不同，用户在跨分片执行查询和事务时不会失去执行 JOIN 操作的能力、牺牲 ACID 保证或引用完整性（外键）。

在我的公司，我们已经使用 MySQL Cluster 相当长一段时间了，它确实运行良好（并且可以水平扩展）。还有Citus（最近发布）是建立在PostgreSQL之上的，但还没有亲自尝试过。

尽管 https://planet.mysql.com/entry/?id=32245 缩放 MySQL 集群意味着一个节点退出意味着整个集群宕机，但您确实会失去可用性。这就是为什么其他 RDBMS 会纵向扩展而不是横向扩展 (2认同)
@gbn 由于 CAP 定理，一致性和可用性之间总是存在选择，正如您的答案中正确所述的那样。然而，MySQL 集群中单个节点的故障意味着整个集群宕机的说法并不正确。4 个节点的集群最多可以处理 2 个故障节点。另请参阅：https://www.mysql.com/products/cluster/availability.html (2认同)

Answer 2

答案是“ CAP定理”

您最多可以拥有一致性、可用性或分区容错性中的 2 个，但通常可以归结为

(Consistency OR availability) AND Partition Tolerance

考虑到传统 ACID 保证而设计的数据库系统（例如 RDBMS）选择一致性而不是可用性，而围绕 BASE 哲学设计的系统（例如在 NoSQL 运动中常见）选择可用性而不是一致性。 [6]

使用 NoSQL，如果节点退出，系统仍保持运行，但您可能无法获取最新数据。这当然是银行或计费系统中的一个巨大禁忌。但在社交媒体应用程序中，这并不重要。

更多示例

从这个网站