Metal 是 PlanetScale 可扩展云 OLTP 数据库平台的最新迭代版本，由 Vitess（兼容 MySQL）和 Postgres 驱动，现在借助快速本地 NVMe 驱动器提供几乎无限的 IOPS，确保您的数据库飞速运行，尤其是在数据无法全部装入内存时。

典型的 PlanetScale Metal 配置在成本上与同等 PlanetScale 或 Amazon Aurora 配置持平甚至更低。当您考虑每美元所能获得的性能时，优势不言而喻。

Metal 与您已经熟知的 PlanetScale 的区别仅在于一点：我们用云提供商提供的快速本地 NVMe 驱动器替代了 Amazon EBS 和 Google Persistent Disk。但这一架构上的小小一步，代表着性能和价格上的巨大飞跃，同时无需牺牲持久性、可靠性或可扩展性。

为什么网络附加存储不适合数据库

像 Amazon EBS 和 Google Persistent Disk 这样的网络附加存储产品是一种最低通用标准的技术，它们使得构建相当可靠的系统变得非常容易。它们可以挂载到虚拟机上或从虚拟机上卸载，同时保留所存储的数据，这带来了便利性。它们在后台复制所存储的数据块，使这些卷比单个硬盘更耐用。

但它们存在存储与计算分离所固有的问题：高延迟且延迟波动极大。对这些网络附加卷的写入需要经过网卡、网络设备和另一台机器，才能最终落到硬盘上。云提供商再多的工程优化也无法掩盖网络附加存储距离遥远的物理现实。

它们的吞吐量也更低。即使在非常昂贵的高端产品上——例如 EBS io2——网络仍然制约着存储硬件的性能。本地 NVMe 驱动器的 IOPS 通常比网络附加存储卷高出一个数量级。

以 r6i.4xlarge EC2 实例的 EBS 性能为例。如果卷或卷组能够跟上，它可以执行 40,000 IOPS。（某些 EC2 实例类型需要跨多个 EBS 卷进行条带化才能达到最大性能。）相比之下，i4i.4xlarge EC2 实例使用本地 NVMe SSD 可以执行 220,000 次随机写入或 400,000 次随机读取 IOPS！

网络附加存储也很昂贵——从最慢配置的每 TB 80 美元到大多数实例所能支持的最高性能 EBS io2 卷的每 TB 2,573 美元不等。所有那些额外的（隐藏的）后台硬件成本加起来相当可观。例如，同样的 i4i.4xlarge 比挂载到 r6i.4xlarge 上仅有 16,000 IOPS 的同等大小 EBS gp3 卷更便宜。

Metal 的用途

PlanetScale Metal 适用于高 I/O 数据库。它面向最严苛、最关键的工作负载。它适用于微秒必争的数据库。而支撑 Metal 处理最困难工作负载的强大硬件，也让其他一切变得更快、更一致。

持续、大范围、随机读取？工作集无法放入 InnoDB 缓冲池？Metal 可以帮助你缩减甚至避免使用一组只读副本。memcached？让它留在盒子里吧。

海量写入吞吐？副本甚至跟不上主库？Metal 可以让你的工作负载适配更少的分片，甚至可能让分片变得完全不必要。

对高延迟容忍度低？Metal 的直接连接 NVMe 驱动器提供比任何网络附加存储更低且更一致的读写延迟。

为什么 Metal 很快

在 MySQL 赢得生产环境地位时常见的磁性硬盘，可能只能做到数百 IOPS。哪怕你只是稍微多看它们一眼，它们也会受限于 I/O。SSD 改变了这个局面，最初通过 SATA 连接，后来是 SAS，如今则是 NVMe。现在 I/O 延迟更低，因为 SSD 不需要寻道，而且互连也更快了。吞吐更高，因为互连具有更高的带宽。

而这正是 PlanetScale Metal 的真正秘诀：现在的硬件真的很好。其余则是 PlanetScale 尽一切努力让这些硬件充分发挥实力。

设想一个在 PlanetScale 上真实运行的百万 QPS 生产工作负载。它的网络附加存储卷报告的 I/O 延迟约为 1ms。我们最近将其迁移到 PlanetScale Metal，使用 I/O 延迟在微秒级的 NVMe 驱动器。结果，其 99 百分位查询延迟从 9ms 降至 4ms。

为什么 Metal 数据库是持久耐用的

任何分布式系统持久性声明的基础都是复制。PlanetScale 和 PlanetScale Metal 也不例外。这里重要的复制是从主库到两个副本的半同步、基于行的 MySQL 复制，这两个副本分布在一个云区域内的三个可用区中。

半同步复制确保每次写入在向客户端确认之前，已经到达两个可用区中的稳定存储。基于行的复制在逻辑上集成到事务处理中，从而支持可读副本和备份。

PlanetScale 数据库，无论是否采用 Metal，至少每天都会进行备份。更重要的是，每一个备份都会通过实际恢复并启动 MySQL 来进行测试。这使我们能够自动且快速地替换故障副本。

值得注意的是，PlanetScale 持久性基础中并不包含 Amazon EBS 和 Google Persistent Disk 等网络附加存储产品内置的复制功能。这些卷的故障率或性能下降程度相当高，因此它们根本不足以作为生产数据库持久性的基础。

然而，当服务于三个副本之一的虚拟机出现故障时，重新挂载存储卷的能力相比必须恢复备份，仅从实际耗时角度来看具有显著优势。为了量化这一差异，我们做了一些对 Metal 不利的假设，以观察它的表现。首先，我们假设 1% 的 Amazon EC2 实例会在 30 天内发生故障；这远高于我们在生产环境中观察到的频率。然后，我们假设分离 Amazon EBS 卷、启动新的 EC2 实例并将该卷挂载到新实例需要五分钟；我们认为这已经是偏快的合理估计。最后，我们假设恢复备份需要五个小时；与我们在生产环境中即使是 TB 级数据库所看到的恢复时间相比，这是极其保守的估计。

第一个值得注意的故障场景是失去写入可用性。这需要在重新挂载卷或恢复备份所需的时间内失去三个副本中的两个。基于这些假设，PlanetScale Metal 数据库因硬件故障而失去写入可用性的概率约为 0.000001%。

第二个故障场景是失去全部三个副本——即数据丢失。基于相同的假设，PlanetScale Metal 数据库因硬件故障而丢失数据的概率约为 0.00000000003%。

通过复制、备份和恢复实现的持久性非常强大。

这样的性能成本很低

通常，如果你想要性能和持久性，你会预期必须在价格上做出妥协。而实际上，由于从网络附加存储中榨取高性能的成本往往是基础网络附加存储的 30 倍，本地 NVMe 驱动器最终成为了高性能且低成本的选项。事实上，一个即使只能达到 20,000 IOPS 的高性能网络附加存储卷，其成本通常也高于它所挂载的虚拟机。

作为 PlanetScale Metal 如何以高性价比交付性能的具体衡量标准，请考虑以下在 AWS 上运行于 r6a 和 i4i 实例类型的各种配置的每美元 IOPS 比率：

| IOPS / $（按需价格） | xlarge | 2xlarge | 4xlarge |
| --- | --- | --- | --- |
| r6a 搭配 EBS gp3（3,000 IOPS） | 3.35 | 1.68 | 0.84 |
| r6a 搭配 EBS gp3（16,000 IOPS） | 13.2 | 7.57 | 4.11 |
| r6a 搭配 EBS io2（20,000 IOPS） | 3.80 | 3.18 | 2.40 |
| r6a 搭配 EBS io2（40,000 IOPS） | 4.45 | 3.99 | 3.31 |
| i4i 搭配实例存储 | 58.41 | 58.48 | 58.50 |

从纯粹的美元成本来看，AWS 中许多 PlanetScale Metal 配置甚至比使用 16,000 IOPS 的 Amazon EBS gp3 配置更便宜。

但这还不是全部。Amazon EBS 无法通过 Reserved Instances 或 Savings Plans 获得折扣，但 PlanetScale Metal 所用实例附带的实例存储可以。采用 Metal 的 PlanetScale Managed 客户可以实现更大的节省，同时获得网络附加存储无法企及的性能。

立即开始使用 Metal

PlanetScale Metal 现已在 AWS 和 GCP 上可用。访问您的 PlanetScale 仪表板以创建新的 Metal 数据库、将现有的 PlanetScale 数据库迁移到 Metal（自然是在线迁移），或从其他地方直接将数据库导入 PlanetScale Metal。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：PlanetScale Blog

原创地址：https://planetscale.com/blog/planetscale-metal-theres-no-replacement-for-displacement