关系数据库可以横向扩展吗答案

【问题标题】：Can relational database scale horizontally关系数据库可以横向扩展吗
【发布时间】：2015-01-25 06:11:06
【问题描述】：

经过一番谷歌搜索，我发现：

来自mysql docs的备注：

MySQL Cluster 自动跨节点分片（分区）表，使数据库能够在低成本、商品上水平扩展服务于读取和写入密集型工作负载的硬件，同时访问从 SQL 和直接通过 NoSQL API。

关系型数据库可以横向扩展吗？它会以某种方式基于 NoSQL 数据库吗？

有人有任何现实世界的例子吗？

如何在这样的数据库中管理sql请求、事务等？

【问题讨论】：

看看JetPants，看看你的想法。这个问题对于 StackOverflow 格式来说太宽泛了。
最终，所有数据库都是 NoSQL，除非您在它们之上添加 SQL。我是在开玩笑，但我是认真的。 dbms 所做的只是将文件组织成可快速访问的键值对。
CAP 定理是一个答案。

标签： mysql transactions scalability horizontal-scaling nosql

【解决方案1】：

这是可能的，但需要大量维护工作，解释 -

数据的垂直缩放（SQL 数据库中的规范化的同义词） 被称为将数据列明智地拆分为多个表，以减少空间冗余。用户表示例 -

数据的水平缩放（与分片同义）被称为将行明智地拆分为多个表，以减少获取数据所花费的时间。用户表示例 -

这里要注意的重点是，因为我们可以看到 SQL 数据库中的表被规范化为多个相关数据表。为了在多台机器上对此类表的数据进行分片，您需要相应地对相关的规范化数据进行分片，这反过来会增加维护工作。就像上面展示的 SQL 数据库示例一样，

与 Order 以一对多关系关联的客户表表

如果您将一些客户数据行移动到其他机器上（称为分片），您还需要将其相关订单数据移动到同一台机器上，如果有多个相关表，这将是一项麻烦的任务。

NOSQL 数据库遵循平面表结构，便于分片（数据以聚合形式而非规范化形式存储）。

【讨论】：

假设您有 TB 字节的数据。您希望不同的客户端停留在不同机器上的不同数据库实例上吗？应用服务器如何知道并查询。（假设永远不需要跨客户端查询）
@Jailbroken 用于将记录与机器实例映射的算法由您使用的数据库客户端本身提供。例如，在 NOSQL 数据库中使用散列算法（如一致性散列），在存储数据时将记录映射到特定机器，在检索数据时使用相同的算法。同样，对于 SQL 数据库，数据库客户端本身提供了用于存储和检索数据的算法。
@Keshav 当涉及到 RDBMS 和 NoSQL 数据库时，我在哪里可以深化分片和映射记录/机器的主题？ Algorithms for mapping records with machine instances are provided by database client itself which you use... Similarly for SQL databases database client itself provides algorithm for storing and retrieving data. 作为一名应用程序开发人员，我是需要开发此类映射算法的人，还是客户端（例如 MySQL DB 客户端）提供开箱即用的功能？如果是，那是什么？我的查询将如何显示？引入分片时它们会改变吗？谢谢！

【解决方案2】：

我认为答案是肯定的。您必须记住，SQL 只是一种数据访问语言。绝对没有理由不能跨多台计算机和网络分区进行扩展。这是一个具有挑战性的问题吗？最肯定的是，这就是为什么这样做的软件还处于起步阶段。

现在，我想您想问的是“我所熟悉的以及标准 SQL 类型关系数据库管理系统中的所有功能都可以开发为以这种方式与多个服务器一起使用吗？”虽然我承认我没有深入研究过这个问题，但有一些定理说“不，它不能”。 Consistency-Availability-Partition Theorem 认为我们不可能同时拥有这三种品质。

现在，出于所有实际目的，“分片”或“分区”或任何你想称之为的东西都不会消失；从相反的方面来说。这意味着，鉴于 CAP 定理的适用程度，我们将不得不改变我们对数据库的看法，以及我们如何与它们交互（至少在一定程度上）。许多开发人员已经做出了在 No-SQL 平台上取得成功所必需的转变，但更多的开发人员还没有。最终，将开发出足够成熟的模型和足够有效的变通方法，以使传统 SQL 数据库，在您所指的意义上，将或多或少在多台机器上实用。这已经开始出现了，我会说再给它几年，我们会达到这一点。或者，我们将集体转变思维，使其不再需要，世界将变得更美好。 :)

【讨论】：

谢谢，我从未听说过 CAP，但在阅读相关内容时，我发现了有关 NoSQL infoq.com/articles/MarkLogic-NoSQL-with-Transactions 事务的有用链接。
可能过于简单化了，但我听说 ACID DB 防止水平扩展的主要功能是多步骤交易（例如，从我的银行存款中扣除 50 到您的银行存款中）。如果您的数据库系统不需要支持这些，许多剩余的功能仍然可以在水平扩展的系统中工作。或者我听说过一次

【解决方案3】：

感谢您的提问和回答。我试图向这样的人解释这一点：

根据CAP 定理，您不能同时拥有这三个。所以当分区（网络或服务器故障）发生时：

单个服务器上的relational database 为您提供C（一致性）。所以当一个 P（分区-服务器/网络故障）发生，你不能有A （可用性 - 数据库下降）
nosql datastore 给你A，所以当P 出现时，你不能有C（您的一个或多个复制分区将超出同步，直到 n/w 返回并且它们都同步）。所以只会是eventually consistent

【讨论】：

这似乎不正确。首先，CAP 定理适用于分布式系统。所以第1点没有意义。第 2 点是完全错误的，因为我们有各种 nosql 数据库，当 P 发生时，它们保证 C 但不保证 A。
我同意@ManishBansal。但是，如果您正在考虑使用分布式数据库，则必须保证分区容差 P，因为如果集群中的某个节点发生故障，则无法交付数据库服务。因此 CA 只能在单个节点中交付。关于这一点，如果最终分区在 P 中失败，您有两个选择：i）设想可用性，显示可能不一致（最终一致）的最新写入数据；或者 ii) 如果不能保证最近的写入，则通过显示错误来设想一致性。
在现实生活中，一致性与可用性是一个范围。您可以拥有一个完全一致的数据库，该数据库具有不可扩展的丰富功能集，甚至可以拥有像 Redis 这样的超快速、水平可扩展的键值存储，它没有查询功能。两者之间的一切都是权衡，这就是为什么有这么多数据库产品的原因。在一致性/可用性方面存在交易。例如，DB 可能对读取具有高可用性，但具有写入一致性保证等......

【解决方案4】：

Google Spanner 是一个可以水平扩展的关系数据库示例。分片和复制是自动完成的，因此无需担心。欲了解更多信息，请查看此paper。

【讨论】：

【解决方案5】：

是的，但是当存储增加时需要迁移。

一些开源工具可以支持该功能，例如：Vitess 或Apache ShardingSphere。

【讨论】：