当前，许多数据库即服务（DBaaS）解决方案将计算层与存储层分离，例如某些云厂商的组合模式。由于数据存储与复制可以由现成的服务处理，这类解决方案具有吸引力，但在某些场景下，使用本地磁盘作为存储的性能仍值得关注。本篇将介绍如何通过仔细选择弹性块存储（EBS）类型并结合优化，在 EBS 上部署数据库服务时获得更好的性能表现。
为什么要考虑 EBS？
为了解释使用 EBS 的动机，先简要介绍一个与 MySQL 兼容的分布式数据库族。核心组件包括计算节点来处理 SQL 请求、负责负载均衡与元数据服务的管理层，以及处理事务查询的分布式存储层。本文重点讲述分布式键值存储的部分。
[
]
图1
TiKV 提供分布式键值服务。它会将数据拆分成若干个区域（Region），作为复制与负载均衡的最小单位。为了实现高可用性，每个 Region 副本通常在不同节点间进行三份复制。一个 Region 的副本集合构成一个 Raft 组。前述架构在单点故障时可能失去多个副本，若失去多数成员，则 Region 将不可用，需要人工介入进行修复。
[
]
图2
在部署云端 TiDB 时，我们会设定副本跨越多个可用区（AZ）的放置规则，以便单个 AZ 的故障对集群影响有限。然而，若发生 AZ + 1 故障（一个可用区与另一个可用区中至少一个节点同时故障），Region 可能变得不可用。为避免这类情况，EBS 的使用进入了我们的视野。
选择合适的 EBS 卷类型
基于 SSD 的 EBS 卷通常有以下几种类型：gp2、gp3、io1 和 io2（本文设计阶段不考虑 io2 Block Express）。下表概览了各自的特性。
| 卷类型 | 耐久性（%） | 带宽（MB/s） | IOPS（每 GB） | 成本 | 说明 |
|---|---|---|---|---|---|
| gp2 | 99.8-99.9 | 250 | 3，突发式 | 低 | 通用卷 |
| gp3 | 99.8-99.9 | 125-1000 | 3000-16000 | 低 | 通用卷，有灵活的带宽 |
| io1 | 99.8-99.9 | 多达1000 | 多达64000 | 高 | 高 IO 量 |
| io2 | 99.999 | 多达1000 | 多达64000 | 高 | 高 IO 量，性能最佳 |
通过对比可以看到，不同卷类型在耐久性、带宽与 IOPS 上存在显著差异。下文中，我们将结合实际工作负载对比各类型在不同实例上的表现。
注：下图中四种 EBS 卷类型附加在 R5b 实例上，而本地磁盘的对比来自 i3 实例，以便在 R5b 实例只能使用 EBS 的前提下，找到更接近的替代方案。每张图展示的是各操作的平均延迟与第 99 百分位延迟。
我们先从读写延迟的简单工作负载开始比较。第一个工作负载较为简单，拥有 1000 IOPS、每次 I/O 4 KB。以下两张图显示了平均延迟与第 99 百分位延迟。
[
]
图3
单线程简单工作负载的写延迟（数字越小越好）
[
]
图4
单线程简单工作负载的读延迟（数字越小越好）
接着，我们设计了相似设置的另一组工作负载，使用 8 个线程提供总计 3000 IOPS、每 IO 仍为 4 KB。下方两图给出平均延迟与第 99 百分位延迟。
[
]
图5
八线程简单工作负载的写延迟（数字越小越好）
[
]
图6
八线程简单工作负载的读延迟（数字越小越好）
从这两组结果来看，本地磁盘在某些场景下的延迟表现略优。真实情况是否如此？另一组综合基准给出了一些不同的结论。我们设计了混合工作负载来模拟 TiKV 的 IO 使用场景，包含前台日志（WAL）写入的连续写入与大量顺序写入的压缩写入，以及少量随机读取的前台读取。
当后台 I/O 越发密集时，前台延迟会增加，本地磁盘与 EBS 的差距会缩小。如下图所示：
[
]
图7．一些综合工作负载的平均操作延迟（数字越小越好）
在进一步的基准中，我们对 TiDB 运行 TPC-C 工作负载（更全面的基准）进行了测试，比较 EBS 与本地磁盘的性能差异。结果表明差距缩小甚至趋近相近。下图展示了结果：TiDB 版本为 V5.0.0；EBS 在 R5b.2xlarge 实例上或本地 nvMe 的 i3.2xlarge 实例上部署了三个 TiKV 节点，TiDB、PD 及 TPC-C 客户端部署在 c5.4xlarge 实例上。数据规模约 350 GB，包含 50、200、800 个客户端。下列三个图分别给出每分钟交易数（TPMC）、平均延迟和第 99 百分位延迟的结果。
[
]
图8．TPC-C 工作负载中的每分钟事务（TPMC）（数字越大越好）
[
]
图9．TPC-C 工作负载中的平均操作延迟（Ms）（数字越小越好）
[
]
图10．TPC-C 工作负载中的第 99 百分位操作延迟（Ms）（数字越小越好）
综合来看，在多种场景下，启用 EBS 的实例能够达到与本地磁盘相近甚至更高的性能。原因在于某些工作负载对 CPU 的需求较高，而使用带有 EBS 的实例类型（如 R5b）时，其 CPU 性能往往优于仅搭载本地磁盘的实例类型（如 i3），从而使得总体性能趋于相近甚至更好。
此外，在第三张图中的第 99 百分位延迟（TPC-C 场景的极端并发），当并发达到 800 线程时，gp2 卷的该指标出现明显抬升，这是因为 gp2 的带宽已达到上限。
最终，我们选择 gp3 作为 EBS 的默认类型。io2 虽然性能更强，但在设计 TiDB Cloud 时未被考虑，因为当时 R5b 实例无法使用 io2 Block Express；io1 的延迟表现与 gp2 相近，但提供更高的带宽和 IOPS 限制，同时具有基于预配置 IO 的额外成本。由于 gp2 的带宽与 IOPS 是有限且不可配置的，这在 TiDB 的场景中带来额外制约，因此最终采用 gp3 作为首选。
