我不想 MySQL 分片

MySQL

第五章

高效 MySQL 性能》(Efficient MySQL Performance)(以下均采用中译名)第五章论述了分片问题,这个问题很难写,但并不是因为技术原因。关于这一问题,让我多说几句。

这篇博文是十一篇中的第六篇: 一篇作为序言,十篇作为我的书《高效 MySQL 性能》的每一章。完整的列表是 tag/effect-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,围绕它的范式已经发生了改变。

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

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

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

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

NewSQL 与创新者的困境

我们越来越多地看到 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 几乎是必需的,因为它无处不在。

本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。

原文地址:https://hackmysql.com/post/book-5/

译文地址:https://learnku.com/mysql/t/71816

本文为协同翻译文章,如您发现瑕疵请点击「改进」按钮提交优化建议
讨论数量: 1

不错,这书新出的,啥时候国内出版

4天前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!