如今，许多数据库即服务(DBaaS)解决方案将计算层和存储层分开，包括AmazonAurora和GoogleBigQuery。由于数据存储和数据复制可以由现有服务处理，因此DBaaS无需担心这种复杂性，这是一个有吸引力的解决方案。然而，这种设计的性能有时可能不如传统方式：使用本地磁盘作为存储。本文将介绍如何慎重选择弹性块存储（EBS）类型，辅以巧妙的优化，在EBS上部署DBaaS可以获得比本地磁盘更好的性能。为什么要考虑EBS？为了说明我们使用EBS的动机，我们先简单介绍一下TiDB。TiDB是一个兼容MySQL的分布式数据库。TiDBServer是处理SQL请求的计算节点。PlacementDriver(PD)是TiDB的大脑，负责配置负载均衡和提供元数据服务。TiKV是一个面向行的键值存储系统，用于处理事务查询。TiFlash是处理分析查询的列存储扩展。本文主要介绍TiKV。图1TiKV提供分布式key-value服务。首先，它将数据拆分成若干个Region，Region是用于复制和负载均衡的最小数据单元。为了实现高可用性（HA），每个Region被复制3次，然后分布在不同的TiKV节点中。一个Region的副本组成一个Raft组。TiDB可以接受这种情况：丢失一个节点，从而丢失部分Region的副本。但是，同时丢失两个副本会导致问题，因为Raft组的大多数成员都丢失了。因此，该区域不可用，无法再访问其数据。需要人为干预来解决这些问题。图2在部署TiDBCloud时，我们有放置规则来确保一个Region的副本将分布在多个可用性区域(AZ)。丢失可用区(AZ)不会对TiDBCloud产生巨大影响。但是，如果出现AZ+1故障（即一个可用区中的至少一个节点和另一个可用区中的至少一个节点同时发生故障），则该区域将变得不可用。我们在生产环境中遇到过这样的故障，费了好大劲才把TiDB集群恢复正常。为了避免这种惨痛的经历再次发生，EBS进入了我们的视线。AWSElasticBlockStore(EBS)是AWS提供的一种可以附加到EC2实例的块存储服务。但是EBS上的数据是独立于EC2实例的，所以当EC2实例出现故障时，数据依然存在。当EC2实例出现故障时，您可以使用Kubernetes自动将EBS重新挂载到正在运行的EC2实例。此外，EBS卷是为关键任务系统设计的，因此它们可以在AZ内复制。这意味着EBS发生故障的可能性较小，因此我们可以高枕无忧。选择正确的EBS卷类型基于SSD的EBS卷通常有四种类型：gp2、gp3、io1和io2。（io2BlockExpress在我们设计和实现TiDBCloud的时候还处于预览模式，所以我们没有考虑。）下表总结了这些卷类型的特性。卷类型耐久性(%)带宽(MB/s)IOPS（每GB）成本说明GP299.8-99.92503突发低通用卷GP399.8-99.9125-10003000-16000具有灵活带宽的低通用卷IO199.8-99.9upto1000upto64000highIOPSio299.999upto1000upto64000highIOPS，最好的性能可以在这里对比。请注意，在下图中，四种类型的EBS卷附加到r5b实例，而本地磁盘上的一些测量是在i3实例上进行的。这是因为r5b实例只能使用EBS。我们使用i3作为类似的替代方案。每个图表显示所有操作的平均延迟和第99个百分位延迟。我们从读写延迟开始横向比较。第一个工作负载很简单。它有1000IOPS，每个I/O为4KB。以下两个图表显示了平均延迟和第99个百分位数的延迟。图3.只有一个线程的简单工作负载的写入延迟。（数字越低越好）图4只有一个线程的简单工作负载的读取延迟。（数字越低越好）我们设计了具有相似设置的相似工作负载。这次我们使用8个线程来提供总共3000IOPS到磁盘，每个I/O仍然是4KB。同样，我们概述了平均延迟和第99个百分位延迟并绘制了下面的两个图表。图5具有八个线程的简单工作负载的写入延迟。（数字越低越好）图6.具有八个线程的简单工作负载的读取延迟。（数字越小越好）从前面两次实验来看，本地盘似乎更好一些。真的吗？这是另一个显示略有不同的故事的基准。我们设计了一个混合工作负载来模拟TiKVIO使用：小的顺序写入模拟前台预写日志(WAL)写入，大的顺序写入模拟压缩写入。回想一下，TiDB使用RocksDB作为存储引擎。RocksDB基于日志结构的合并树（LSM树），它会定期压缩最近写入的数据。我们也有小的随机读取来模拟前景读取。我们发现，当后台I/O变得更加密集时，前台延迟增加，本地磁盘和EBS之间的延迟差距变小，见下图。图7.一些合成工作负载的平均操作延迟。（数字越低越好）在我们针对TiDB（这是一个更全面的基准）运行TPC-C工作负载后，EBS和本地磁盘之间的性能差距变得更小了。下图显示了结果。使用的TiDB版本是v5.0.0。我们在具有不同EBS卷类型的r5b.2xlarge实例或使用本地nvme磁盘的i3.2xlarge实例上部署了三个TiKV节点。TiDB节点、PlacementDriver(PD)和TPC-C客户端部署在c5.4xlarge实例上。我们在实验环境中使用了5000个仓库（约350GB数据），分别有50、200和800个客户端。结果如下三图所示。第一张图显示了TPC-C工作负载中的每分钟事务数(TPMC)。第二张图显示了以毫秒为单位的事务的平均延迟。第三张图显示了第99个百分位数的延迟（以毫秒为单位）。图8.TPC-C工作负载中的每分钟事务数(TPMC)。（数字越高越好）图9.TPC-C工作负载中的平均操作延迟(ms)。（数字越低越好）图10.TPC-C工作负载中第99个百分位数的操作延迟(ms)。（数字越小越好。）一般来说，我们可以看到使用EBS的实例可以达到与使用本地磁盘的实例相似的性能，有时甚至更好。这是因为TiKV在此工作负载以及我们尝试过的许多其他基准测试中受CPU限制。I/O性能不是瓶颈。由于使用EBS的实例类型是r5b，它的CPU比使用本地磁盘的实例类型i3更好，因此性能结果看起来相似，甚至更好。此外，在第三张图中（TPC-C工作负载中的第99个百分位操作延迟），EBS卷类型gp2的第99个百分位延迟在800个线程时出现峰值。这是因为就gp2而言，带宽已达到极限。最后，我们选择gp3作为EBS类型。EBSvolumeio2不在我们的考虑范围内，因为当初设计实现TiDBCloud的时候，r5b实例是无法使用的。此外，当时io2blockexpress仍处于预览模式。EBSvolumeio1的延迟一般与gp2相当，io1提供了更高的带宽IOPS限制。但是，io1会根据预配置的IOPS产生额外费用。EBS卷gp2的带宽和IOPS有限且不可配置。这给TiDB带来了额外的约束。因此，我们选择了gp3。原标题：ImprovePerformanceandDataAvailabilitywithElasticBlockStore(EBS)，作者：BokangZhang链接：https://www.datasciencecentral.com/improve-performance-and-data-availability-with-elastic-block-store-EB/
