【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

我不想 MySQL 分片

  • 2022-07-01
  • 本文字数:4979 字

    阅读完需:约 16 分钟

我不想 MySQL 分片

Daniel Nichter 是《高效 MySQL 性能》(Efficient MySQL Performance)一书的作者,该由 O’Reilly 出版,目前尚无中译版本。Nichter 在本文中又对书中第五章中关于分片的问题进行了讨论。

 

《高效 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,围绕它的范式已经发生了改变。

 

一方面,我们有像 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 几乎是必需的,因为它无处不在。

 

原文链接:

https://hackmysql.com/post/book-5/

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2022-07-01 17:043780

评论

发布
暂无评论
发现更多内容

java培训 | API 接口如何实现统一格式返回

@零度

JAVA开发 API

全场景式全流程监控,博睿数据为券商IT运维难题提供范例

博睿数据

数字化转型 博睿数据 数据链DNA 证券行业

青藤《关键信息基础设施增强保护安全实践》论文入选中国科技核心期刊

青藤云安全

信息安全 关键信息 安全保护

使用 Amazon DevOps Guru for Serverless 自动检测 Lambda 函数中的运行问题

亚马逊云科技 (Amazon Web Services)

DevOps Lambda severless

直播预告丨 OpenHarmony 标准系统多媒体子系统之相机解读

OpenHarmony开发者

OpenHarmony

JavaScript== 和 ===

源字节1号

软件开发 前端开发 后端开发 小程序开发

有没有支持vmware/openstack/zstack私有云的堡垒机?

行云管家

私有云 云服务器 堡垒机 行云管家

国内私有云厂商有哪些?排名怎么样?

行云管家

网络安全 私有云 私有云厂商

开源夜聊栏目开播:聊聊新晋 CNCF 项目 sealer 背后的故事

阿里巴巴云原生

阿里云 开源 云原生 直播

知识管理在企业创新中的作用

小炮

知识管理

技术分享| 浅谈IM 产品中的“缩略图”功能

anyRTC开发者

音视频 IM 实时消息 发送图片 缩略图

Spring Cloud OpenFeign 的 5 个优化小技巧!

王磊

SpringCloud

汇顶科技GR551x系列开发板已支持OpenHarmony

科技汇

web前端培训 | Tree shaking问题排查

@零度

web前端开发

墨天轮高分技术文档分享——Oracle升级迁移篇(共96个)

墨天轮

MySQL 数据库 oracle postgresql 国产替代

监控告警平台的国产化选择—Rancher与夜莺的集成

Rancher

Kubernetes k8s rancher

洞见科技数据科学家王湾湾:隐私计算助推金融业数字化转型

洞见科技

数据挖掘 金融科技 隐私计算

单机GPU云服务器的深度学习训练和预测模型分析

Finovy Cloud

云服务器 GPU服务器

DCM:一个能够改善所有应用数据交互场景的中间件新秀

华为云开发者联盟

数据处理 数据交互 多样性数据源 DCM

Python 编程

兮子

5月月更

海豚调度5月Meetup:6个月重构大数据平台,帮你避开调度升级改造/集群迁移踩过的坑

Apache DolphinScheduler

Apache 大数据 开源 DolphinScheduler workflow

无聊科技正经事周刊(第8期):让子弹飞一会儿,用长期的眼光看中国开源

潘大壮

开源 程序员 周刊 开源中国 科技周刊

创建自定义的配置信息

Wk

5月月更

亚马逊云基础架构:一场从未停歇的技术创新革命

亚马逊云科技 (Amazon Web Services)

架构 亚马逊云

Wallys/QCN9074 /11ax/ 4x4 /5G M.2

wallys-wifi6

QCN9074 11 ax

GPU不可不知的指标项

AIWeker

人工智能 gpu 5月月更

Wallys/QCN9074 /11ax 4x4 6G M.2

wallys-wifi6

wifi6 m.2

直播预告 | 服务网格规模化应用下的 Istio Sidecar 灵活配置实践

阿里巴巴云原生

阿里云 云原生 直播 服务网格 Istio Sidecar

发现一个开源项目优化点,点进来就是你的了

捉虫大师

开源 性能优化 sentinel 5月月更

剧透!2022开发者关注的开源技术全解析

华为云开发者联盟

开源 mindspore kubeedge OpenHarmony open Euler

大数据培训 | 数据仓库构建方法论和实践

@零度

数据仓库 大数据开发

我不想 MySQL 分片_语言 & 开发_Daniel Nichter_InfoQ精选文章