我不想 MySQL 分片

《高效 MySQL 性能》（Efficient MySQL Performance）第五章论述了分片问题，这个问题很难写，但并不是因为技术原因。关于这一问题，让我多说几句。

这是我从第五章中删除的一段话和脚注：

然而，横向扩展并不是关系型数据存储的固有特性。这是历史原因导致的：关系型数据模型创建于 20 世纪 70 年代，当时由于硬件体积庞大且价格昂贵，所以横向扩展是不可能的。简单地说，关系型数据库不是为横向扩展而设计的。_{[1]}因此，横向扩展关系型数据存储需要一个外部过程：分片。_{[1]}尽管关系型数据库不是为了横向扩展而设计的，但这既不是对其的批评，也不是它的缺陷，关系型模型在过去 40 多年里的流行程度不仅令人难以置信，并且毫无疑问，它已经成为技术和互联网不可或缺的一部分。

我删除了这一段（以及脚注），原因是其中有误导或错误，正如 Fernando Ipar（我的技术审稿人之一）指出的那样：

最好能找出一种方式（在这里或在现有的脚注上）来表达。严格来说，关系模型是一种逻辑模型，与物理层没有任何关系。这么说可能让人有点恼火，但以本人愚见，如果说关系模型不能扩展，那是因为我们已经达到了特定关系（或者更准确地说是受关系启发的）产品的极限。那就像是在说，由于你的尝试操作在特定型号的计算器造成了计算溢出，就断言算术无法扩展。‍

区别就是为什么其他数据库有可能在支持分片的情况下，同时支持一些关系特性，并且对用户的透明程度要超过 MySQL（比如 ockroachDB、TiDB，甚至 MySQL Cluster）。我认为澄清这个问题的一个很好的建议就是《深度探索关系数据库》（Database in Depth，C.J. Date 著，由 O'Reilly 于 2005 年出版） 一书中第一章《模型与实施》（Model Versus Implementation）的内容。

事实上，这是 Data 在这本书第一章中的相关陈述（强调是我的观点）：

首先要知道，性能，归根结底是实现的问题，而非模型问题——尽管存在着极其普遍的、与之相反的误解。比如，我们经常被告知“连接很慢”，但这样的说法毫无任何意义！连接（JOIN）是模型的一部分，而模型自身也不能称之为“快”或“慢”；只有“实现”可以说具有这样的特性。因此，我们可以这样说，某些特定产品 X 的连接实现比另一些特定产品 Y 更快或更慢，但也仅此而已。

我经常有 Date 和 iPar 所说的误解，如果不是 iPar 纠正我的话，我差点也会把同样的想法付诸印刷。更糟糕的是，我实际上还陈述了两个有些矛盾的理由：

1.关系型数据模型创建于 20 世纪 70 年代，当时由于硬件体积庞大且价格和昂贵，所以横向扩展是不可能的。

2.关系型数据库不是为了横向扩展而设计的。

从表面上来看，这不是一个明显的逻辑错误，但它是错误的：1 是真的，但 2 并不是由 1 得出的。

诚然，从 20 世纪 70 年代一直到 21 世纪初，硬件体积都很庞大且价格昂贵（与今天的情况相比）。因此，企业不可能随心所欲地提供 100 个新数据库。（作为参考，亚马逊 EC2 于 2006 年发布。）采购任何服务器就如同购买一辆汽车：一项谨慎而又代价高昂的决策，打算拥有并持续运营数年之久。需要更多的容量？扩大现有服务器的规模：更多的内存，更大的硬盘，诸如此类。还需要更多的容量？那就购买“更大”的服务器：支持更快的 CPU，更多的 RAM 芯片，更多的硬盘托架，诸如此类。

但是，“关系型数据库不是为了横向扩展而设计的”这一说法并不正确。我不应该加上这句话，因为这正是 Date 在他书里第一章抨击的误解，这有充分的理由。引用 Date 的话：性能从根本上说是一个实现问题，而不是一个模型问题。规模是性能的一部分。

现在是 2022 年 5 月，1 TB 的内存是存在的，但远非常态。最大的亚马逊云科技 RDS 实例类型是 db.x1e.32xlarge，具有 3904 GB 内存，几乎 4 TB。这令人印象深刻，但是我不想这样：我希望它是 2022 年的规范。

如果 TB 级的内存是常态，那么单个 MySQL 实例就有望能够处理几十 TB 的数据。我之所以强调“可能”，是因为尽管内存在避免分片时起着至关重要的作用，但它并不是唯一的因素。有时候，为了扩展写操作，需要进行分片。在这种情况下，存储 I/O 和延迟就成了更关键的因素。一些插到 PCIe 插槽的 NVMe 系统具有令人难以置信的性能，但就像 TB 级的内存一样，它们远非常态。即使内存和存储 I/O 解决了问题，那么网络传输速度呢？以 10Gbps 的速度传输 10TB 需要大约 2 小时。有更快的网速，但它们现在也还不是常态。

不要忘记模式迁移（OSC）和其他数据操作。目前，MySQL 只有两个 OSC 工具：pt-online-schema-change 和 gh-ost。这两者都可以处理 TB 级的数据，但都没有真正地优化速度或并行性，所以 TB 级的数据需要花上很多小时才能改变。

我认为，目前使用 MySQL（或其他类似的关系型数据库）是不可能避免分片的，原因是数据的增长速度已经远远超过了 MySQL 的硬件和工具。在过去的 20 年里，MySQL 做了很好的工作，但我认为，由于普遍可用的（和可负担得起的）硬件和工具，它已经接近了一个软极限。现在，我想这个软极限是 10TB 的数据——具有有利的（即轻量级）访问模式，较小的工作集大小，以及相对稳定的模式（或一个真正有耐心的团队 / 公司）。

数据量不断增加。即使不在技术领域内，人们也知道数年前的设备能够存储 5GB 的数据，而现在可以存储 256GB。iPod 就是一个例子：人们意识到“我可以存储更多的数据”。（这个例子很及时，因为苹果公司的 iPod 在 20 年才停产）。让我们姑且假定这种长期存在的趋势是合理的，而不是由于数据膨胀或浪费。（我个人觉得，我们对数据的浪费是非常严重的，这就是为什么我在《高效 MySQL 性能》的第三章和第四章中详细阐述了这个问题）。

自从计算机出现以来，硬件的容量就在迅速增加（而成本在下降），这在技术领域也是广为人知的。因此，它跟上了数据增长的步伐，以至于不需要改变范式：只要继续购买更大的硬件（因为它变得更低廉），问题就解决了。这就是旧的范式：扩展你已经拥有的硬件规模。我只是泛泛而谈，总是有一些例外。

但近年来，有四件事发生了变化：

1.硬件容量的增长略微滞后。

2.数据的增长显著增加。

3.云变得普遍。

4.发明了编排。

第 1 点说得很谨慎，因为硬件容量肯定一直在增加；第 2 点才是掩盖了第 1 点的主要变化，并使之复杂化。数据增长很容易爆炸，因为产生数据很容易。在市场上开发和推广硬件要困难得多（而且缓慢），因为大的变化需要其他新的硬件（例如从 SATA 到 PCIe）、新的内核和驱动程序，以及能够充分利用前面提到的新应用。

数据飞速增长，硬件也在努力追赶，云（第 3 点）在 2006 年亚马逊 EC2 推出时悄无声息地出现。但是，云实际上不过是另一个你租用而不是拥有的服务器。这意味着，亚马逊云科技（和其他云厂商）在幕后所使用的硬件和你可能原本计划购买的一样。（这不再是实际情况了，有些云厂商定制了他们自己的硬件）。

但云还是很有用的，因为它提供了一个抽象层，隐藏了采购和管理硬件的复杂性。人们经常使用“弹性”这个词：云中的计算资源具有弹性。这意味着你能够持续地将更多的数据存储到云端中，而无需过多关注其运行方式。

从这个角度来说，云是一个重大的演变，因为在云之外，真正的挑战不在于“我可以买一个足够大的硬盘吗？”（你可以），而在于“我可以以多快的速度采购和配置硬件，以及它可以持续多久？”公司不可能（也不会）每年不顾一切地购置新硬件。

相反，他们会计划、预算、购买、等待、接收、“上架”，最后（有时是几个月后）让新硬件上线。鉴于这种努力，公司要求硬件工作多年以彻底收回投资。这就是公司难以与爆炸性增长的数据保持同步的原因。但是，云改变了这一点。它抽象化了采购和管理硬件的复杂性：你只要按需租用你所需的任何东西就可以了。

云对于改变这种范式来说是必要条件，但还并不够。你可以提供所有你想要的资源，但是如果你这么做了，你又会遇到另外一个问题：如何放养这些传说中的猫？这句话的意思是：你可以提供一个资源集群，但你如何控制并管理它？

在 2013 年和 2014 年，Docker 和 Kubernetes 相继问世。这些都是容器化的技术（以及延伸到微服务），但它们都是使编排大规模的云资源集群变得可行的最终必需。所以，我们现在能够用编程方式（而且有点容易）来提供并编排几乎无限的云资源，并以“弹性”方式（通常是创建和销毁并重新创建资源）。

现在范式已经改变了，因为在云中，实际上没有任何限制；这只是一个你能负担得起的问题。笼统地说，新的范式是：“只要在云中扩展规模”。（其中“只要”一词意味着，考虑到编排工具，这应该是很容易的，但“容易”这个词显然是高度相对的。)

回到 MySQL，围绕它的范式已经发生了改变。

一方面，我们有像 MySQL 这样的关系型数据库，这些数据库是在范式改变之前很久就创建了——当时的范式仍然是“扩大规模”：购买更大、更快的硬件。我认为对于 2000 年以后出生的工程师来说，了解这段历史很重要。

MySQL、Postgres 和类似的产品是在云或 Kubernetes 之前很久就问世了。在那时，无论你想要多少资源，“启动”的想法根本不可能。标准是扩大你已经拥有的资源，因为公司不愿意也不喜欢购买新硬件。这就是为什么 MySQL 在扩展方面非常出色，但却不能原生横向扩展的部分原因（为什么需要分片）。

另一方面，现代软件开发正在转向新范式，在新范式几乎没有资源限制：只要为你想要的大小 / 规模配置 Kubernetes（或任何编排工具），它（通常）就会提供任何需要的东西。（说“通常”是因为，如果你不知道，云有时确实会暂时耗尽资源）。

不足为奇的是，开发人员希望他们的数据库也可以做到这一点，但发现他们无法使用 MySQL、Postgres 和其他类似的数据库。这可如何是好？

我们越来越多地看到 NewSQL 数据存储，它将数据库的计算层和存储层分开，这样就可以通过编排在云中进行横向扩展。考虑到范式的变化，这样做是有意义的；考虑到硬件和工具没有保持在数据增长曲线的前面，这也是有意义的。

例如，如果有硬件和工具可以轻松处理单个 100TB 的 MySQL 实例，那么 NewSQL 很可能就不会有市场。但目前情况并非如此。因此，为了使 MySQL 达到一定规模，开发人员必须实施和维护应用级分片，或者转向 NewSQL。

虽然分片已经被证明是行之有效的（关于 MySQL 分片已经有了很多知识和成功案例），但这仍然是一项非开发任务，开发人员经常告诉我他们不想做。

我不能责怪他们：他们被雇来开发应用程序的功能——而我被雇来为他们扩展数据库。（当然，我希望他们不要再这么浪费数据了，不过我要这么说就是跑题了。)

我认为我们正在见证“创新者的困境”。单一实例上的 SQL 是现任者：一个巨大的价值网络，它扎根于四十年的成功经验。NewSQL 是一家颠覆性的小微初创企业，目前正致力于解决一个利基问题，而且它似乎没有占据主要的市场份额（小的价值网络）。NewSQL 有可能取代现任者，包括 MySQL，特别是当 TiDB 等产品明确地与 MySQL 兼容，以进入现任者的价值网络时。

而毫不奇怪的是，NewSQL 的一个障碍是成本。NewSQL 数据库更为复杂，这需要更多的云资源，而且成本也更高。但我们也看到了这种情况：随着颠覆者市场份额的增加，成本也会下降。

题外话：Vitess 和类似产品并不是颠覆者：它们是现有价值网络到新价值网络的桥梁。如果真正的颠覆者获胜，这些桥梁就将慢慢消失。

对 MySQL 进行分片仍然是必要的，因为我们还处于一个不确定的时期，还不知道怎么可以避免分片：要么是负担得起的硬件容量大爆发（这实际上只是提供了更多的跑道，将问题进一步推向未来），要么是 NewSQL 成功颠覆了传统 SQL，成为主流。

似乎符合逻辑的是，在未来，软件工程师将不必处理应用级别的分片，因为那并不是他们真正的工作，而且 NewSQL 已经证明它不需要存在。这就是为什么我个人认为 NewSQL 会获胜，但是至少需要 5 年时间，更现实的是 10 年。

不过不用担心，MySQL 和其他单实例关系型数据库将在更长时间内继续发挥重要作用，以至于今天学习 MySQL 几乎是必需的，因为它无处不在。

 内容推荐