高效MySQL性能的第5章讨论了切分，它写起来很困难，但不是因为技术原因。关于这件事，让我再多说一点。
这篇博文是十一篇博文中的第六篇：一篇为前言，十篇为我的书高效MySQL性能的每一章。完整列表是标签/高效mysql性能。
但首先：菲帕说…
这是我从第5章中移除的段落和脚注：
然而，向外扩展并不是内在的关系数据存储。原因是历史性的：关系数据模型创建于20世纪70年代，当时由于硬件的物理规模巨大且价格昂贵，不可能向外扩展。简单地说，关系数据库的设计不是为了向外扩展。[1] 因此，扩展关系数据存储需要一个外部过程：切分。
[1] 尽管关系数据库的设计不是为了扩展，但这既不是批评，也不是缺点，因为40多年来，关系模型不仅广受欢迎，而且对技术和互联网来说是不可或缺的。
正如费尔南多·伊帕尔（我的一位技术评论员）指出的那样，我删除了那一段（和脚注），因为它具有误导性或错误性：
最好找到一种方法（在这里或现有脚注上）来提及，严格来说，关系模型是一个逻辑模型，与物理层无关。这可能有点让人恼火，但IMHO说，关系模型不可扩展是因为已经达到了特定关系（或者更准确地说，受关系启发的）产品的极限，这似乎类似于说算术不可扩展是因为您尝试了一个操作，导致了特定计算器模型上的溢出。这种区别就是为什么其他数据库可以支持切分和一些关系特性，这种方式对用户来说比MySQL（例如，CockroachDB、TiDB，甚至MySQL Cluster）中的方式更透明。我认为澄清这一问题的一个好建议是C.J.Date《深入数据库》第一章中的“模型与实现”一节，O’Reilly，2005年。
事实上，这是那本书第一章（我的重点）中有关日期的陈述：
首先，请注意，性能从根本上来说是一个实现问题，而不是模型问题，尽管存在极为常见的相反误解。例如，我们经常被告知“连接很慢”但这样的话毫无意义！连接是模型的一部分，模型本身不能说是快或慢；只有实现可以说具有任何这样的质量。因此，我们可以合理地说，与其他特定产品Y相比，某些特定产品X对某些特定连接的实现更快或更慢，但仅此而已。
我经常遇到Date和Ipar所说的误解，如果Ipar没有纠正我的话，我几乎会将同样的想法付诸于印刷。更糟糕的是，我实际上陈述了两个相互矛盾的原因：
1.关系数据模型创建于20世纪70年代，当时不可能向外扩展，因为硬件在物理上庞大且昂贵
2.关系数据库的设计不是为了向外扩展
从表面上看，这不是逻辑上的明显错误，但它是错误的：1是真的，但2不遵循1。
诚然，从20世纪70年代一直到21世纪初，硬件都相当大且昂贵（与今天相比）。因此，公司不能只是一时兴起就提供100个新数据库。（作为参考，亚马逊EC2于2006年推出。）购买任何一台服务器就像买一辆车：这是一个谨慎而昂贵的决定，目的是拥有并运营多年。需要更多容量？扩大现有服务器的规模：更多的RAM、更大的硬盘等等。需要更多容量？买一个“更大”的服务器：一个支持更快的CPU，更多的RAM芯片，更多的硬盘驱动器托架，等等。
但“关系数据库不是为扩展而设计的”这一说法是不对的。我不应该再加上这句话，因为Date在他的书的第一章有充分的理由反对这种误解。重申：性能从根本上来说是一个实现问题，而不是模型问题。规模是绩效的一部分。
我们能避免分片吗？
现在是2022年5月，内存容量为1 TB，但远未达到标准。最大的AWS RDS实例类型是 db.x1e.32xlarge，3904 GB RAM，几乎4TB的 RAM。这令人印象深刻，但我希望不是这样：我希望这是2022年的常态。
如果以TB的RAM为标准，那么单个MySQL实例可能能够处理数十TB的数据。我强调“可能”，因为虽然RAM是避免切分的关键因素，但它不是唯一的因素。有时，需要分片来扩展写入，在这种情况下，存储输入/输出和延迟是更关键的因素。一些连接PCIe的NVMe系统具有令人难以置信的性能，但与TB级RAM一样，它们远未达到标准。即使RAM和存储I/O问题得到解决，网络传输速度又如何？以10 Gbps传输10 TB大约需要2小时。有更快的链接速度，但它们也不是标准。
我们不要忘记：模式迁移（OSC）和其他数据操作。目前，MySQL只有两个OSC工具：pt online schema change和gh ost。两者都可以处理TB级的数据，但都没有真正优化速度或并行性，因此更改TB级数据需要很多小时。
我认为，目前不可能避免使用MySQL（或其他类似的关系数据库）进行切分。原因是：MySQL的数据增长速度大大超过了硬件和工具。在过去的20年里，MySQL做了很大的努力，但我认为由于普遍可用（并且价格合理）的硬件和工具，它已经接近软限制。现在，我将把10 TB的软数据放在有利的（轻量级）访问模式、较小的工作集大小和相对稳定的模式（或真正有耐心的团队/公司）中。
数据增长和云
数据量不断增加。即使在科技之外，这也是常识：例如，人们知道多年前设备可以存储5GB，现在可以存储256GB。iPod就是一个及时的例子：人们意识到“我可以存储更多的数据！”（这个例子很及时，因为苹果刚刚在20年后停止了iPod。）让我们暂时假设这种长期趋势是合法的，而不是由于数据膨胀或浪费。（就我个人而言，我认为我们在数据方面极其浪费，这就是为什么我在高效MySQL性能的第3章和第4章中详细讨论了这个问题。）
自从计算机出现以来，硬件的容量迅速增加（并且成本降低），这在技术领域也是众所周知的。因此，它跟上了数据增长的步伐，因此不需要改变范式：只要继续购买更大的硬件（因为它变得更便宜），问题就解决了。这是一个旧的范例：扩大你已经拥有的硬件。我说的是一般情况；总是存在异常值。
但近年来有四件事发生了变化：
1.硬件容量增长略有滞后
2.数据增长显著
3.云变得很常见
4.编曲是发明的
第一点是谨慎陈述的，因为硬件容量肯定一直在增加；第二点，这是主要的变化。数据增长很容易爆发，因为生成数据很容易。在市场上开发和推广硬件要困难得多（也慢得多），因为大的变化需要其他新的硬件（例如SATA到PCIe）、新的内核和驱动程序，以及能够充分利用上述功能的新应用程序。
当数据增长全速前进，硬件竭尽全力跟上时，云（第三点）在2006年亚马逊EC2发布时悄然出现。但云实际上只是另一个你租用而不是拥有的服务器。这意味着，在幕后，AWS（和其他云提供商）正在使用您可能购买的相同硬件。（这不再是事实：一些云提供商定制自己的硬件。）但云仍然有帮助，因为它提供了一层抽象，隐藏了采购和管理硬件的复杂性。通常使用“弹性”世界：云中的计算资源是弹性的。这意味着你可以继续在云中存储越来越多的数据，而不必（过多）关心它的工作方式。在这种情况下，云是一个重大的演变，因为在云之外，真正的挑战不是“我能买一个足够大的硬盘吗？”，而是“我能以多快的速度采购和供应硬件，它能持续多久？”公司不能（也不会）每年漫不经心地购买新的硬件。相反，他们会计划、预算、购买、等待、接收并“安装”，有时几个月后，他们会将新硬件上线。考虑到这一努力，公司需要硬件工作很多年（以彻底收回投资）。这就是为什么公司很难跟上爆炸性的数据增长。但云改变了这一点，它消除了采购和管理硬件的复杂性：只需按需租用任何需要的硬件。
云对于改变范式是必要的，但这还不够。你可以提供你想要的所有资源，但这样做会产生另一个问题：如何放牧众所周知的猫？意思是：你可以提供一个资源车队，但你如何控制和管理它？分别在2013年和2014年输入Docker和Kubernetes。这些都是用于集装箱化的技术（也可以说是微服务），但它们是最后一项必要的技术，可以让协调大量云资源变得容易处理。因此，现在我们可以通过编程（编程难度不高）提供和协调几乎无限的云资源，并“弹性地”这样做（比如经常创建、销毁和重新创建资源）。现在，范式已经改变，因为在云中，几乎没有限制；这只是你能负担得起的问题。粗略地说，新范式是：“只需在云中扩展。”（其中“just”意味着给定编排工具应该很容易，但“easy”当然是高度相关的。）
新范式中的MySQL
回到MySQL：围绕它的范式已经改变。
一方面，我们有像MySQL这样的关系数据库，它们是在范式改变之前很久创建的，当时范式仍在“放大”：购买更大、更快的硬件。我认为，对于2000年后出生的工程师来说，了解这段历史是很重要的：MySQL、Postgres等都是在云或Kubernetes之前很久创建的。当时，无论你想要多少资源，“加速”的想法根本不可能。通常情况下，我们会扩大已有的资源，因为公司不愿意购买新的硬件，而且购买速度很慢。这就是MySQL非常善于扩展但无法在本机扩展的部分原因（为什么需要分片）。
另一方面，现代软件开发正在转向新的范式，在这种范式中，几乎没有资源限制，只需为您想要的大小/规模配置Kubernetes（或任何编排工具），它（通常）会提供所需的任何东西。（“通常”是因为，云有时确实会暂时耗尽资源。）不出所料，开发人员希望他们的数据库也能做到这一点，但发现他们无法使用MySQL、Postgres等。现在怎么办？
NewSQL和创新者的困境
我们越来越多地看到，NewSQL数据存储将数据库的计算层和存储层分隔开来，这样每个层都可以通过编排在云中扩展。考虑到范式的变化，这是有道理的，但考虑到硬件和工具尚未领先于数据增长曲线，这也是有道理的。例如，如果有硬件和工具可以轻松处理一个100 TB的MySQL实例，那么NewSQL可能就没有市场。但目前情况并非如此，因此对于大规模的MySQL，开发人员必须实现和维护应用程序级切分，或者飞跃到NewSQL。
虽然分片是经过实践的（关于分片MySQL的知识和成功经验有很多），但它仍然是一项非开发任务，开发人员经常告诉我他们不想做。我不能责怪他们：他们被雇来开发应用程序功能，我被雇来为他们扩展数据库。（当然，我希望他们不要再浪费数据了。）
我认为，我们正在目睹创新者在行动中的困境：单例SQL是义不容辞的：一个植根于四十年成功的巨大价值网络。NewSQL是一家颠覆性的小型初创公司，目前正在解决一个利基市场，但它似乎没有获得主要市场份额（小价值网络）。NewSQL有可能取代现有的MySQL，包括MySQL，尤其是当像TiDB这样的产品明确与MySQL兼容以进入现有的价值网络时。毫不奇怪的是，NewSQL的一个障碍是成本：NewSQL数据库更复杂，需要更多的云资源，成本也更高。但我们也看到了这种情况：成本随着破坏者市场份额的上升而下降。
旁注：Vitess和类似产品不是颠覆者：它们是从现有价值网络到新价值网络的桥梁。如果真正的破坏者获胜，桥梁将慢慢消失。
那么重点是什么？
切分MySQL仍然是必要的，因为我们还不确定什么可以让工程师避免切分：要么是负担得起的硬件容量激增（这实际上只是提供了更多的跑道，将问题进一步推向未来），要么是NewSQL成功地颠覆了传统SQL并成为主流。
似乎合乎逻辑的是，在未来，软件工程师将不必处理应用程序级切分，因为这不是他们真正的工作，而NewSQL已经证明它不需要存在。这就是为什么我个人认为NewSQL会赢，但实际上至少需要5年或10年。但不要担心：MySQL和其他单实例关系数据库将在更长的时间内继续发挥至关重要的作用，因为MySQL无处不在，所以今天实际上需要学习MySQL。
原文标题：I Don’t Want to Shard (MySQL)
原文链接：https://hackmysql.com/post/book-5/
