Babelfish 获得 Aurora PostgreSQL 性能测试结果

在这篇博客文章中，我将分享使用 Ham merDB数据库基准测试工具对 Babelfish进行Aurora PostgreSQL 性能测试的结果。根据托管 Babelfish 的各种 Aurora PostgreSQL 集群的测试结果，我还将从性价比的角度提供最佳实例选择建议。

这篇博客文章最后总结了你可能期望从 Babelfish 获得的性能值。我想强调的是，该分析并未将Babelfish与其他RDBMS进行比较，而是侧重于Babelfish本身的性能特征。

1。为什么我们需要 Babelfish 性能测试

适用于 Aurora PostgreSQL 的 Babelfish 是亚马逊 Aurora PostgreSQL 兼容版的一项功能，它使 Aurora 能够理解为微软 SQL Server 编写的应用程序中的命令。通过允许Aurora PostgreSQL理解 微软T-SQL 并通过SQL Server的专有 表格数据流 协议进行通信，Babelfish加快了兼容工作负载从SQL Server向开源数据库平台的迁移速度并降低了迁移风险。只需进行少量更改或不做任何更改，您就可以针对从 SQL Server 迁移的 Babelfish 数据库运行为 SQL Server 开发的应用程序。

随着 Babelfish 的成熟，可以提供更多的特性和功能，越来越多的 SQL Server 工作负载可以迁移到 Babelfish。因此，许多 亚马逊云科技 客户 计划或正在将 其 SQL Server 工作负载迁移到 Babelfish 也就不足为奇了。 Babelfish Compass 工具 有助于评估客户数据库与 Babelfish 的兼容性并确定迁移路径。

除了兼容 Babelfish 之外，这些客户还有兴趣了解他们可能期望 Babelfish 获得什么样的性能，以及他们应该如何设置 Aurora 集群以节省成本并优化其在 Babelfish 上的工作负载的性价比。为了回答这些问题，我按照博客文章为 A urora PostgreSQL 设置 Babelfish 以使用 HammerDB 进行性能测试中概述的 设置进行了一系列 Babelfish 性能测试。

2。选择 Babelfish 基准测试场景

2.1。设置用于基准测试的数据库

我将使用 HammerDB 4.4 OLTP 工作负载 进行 Babelfish 基准测试， 因为 OLTP 工作负载在 SQL Server 向 亚马逊云科技 的迁移中很普遍。 此外，对于 OLAP类型的工作负载，亚马逊云科技提供专业服务 ，例如 Amazon Red shift。

对于 OLTP 工作负载，我尝试涵盖各种场景，因此我使用 8, 000、30,000 和 75, 00 0 个 仓库生成了三个 HammerDB 数据库 ，结果生成了大约 0.87 、 3.3 和 8.2 太字节的测试数据库。 这些数据库代表了范围广泛的相对较小到相当大的工作负载。

2.2。选择实例类型

Aurora for PostgreSQL 是 Babelfish 的基础，它支持 许多实例类。 其中一些，比如 db.r4 和 db.r3 ，是遗留的，我不会考虑将它们用于测试。我也不会考虑 db.serverles s 类，因为 Aurora 会随着工作负载的变化动态调整计算、内存和网络资源。

我在测试中包含的第一个实例类是 db.r5 。此类中的实例是经过内存优化、基于 Nitro 的实例，非常适合内存密集型应用程序，例如高性能数据库。

Aurora 还支持 db.r6g 和 db.x2g 实例类，这两个类均由 亚马逊云科技 Graviton-2 处理器提供支持。 此外， db.x2g 实例类提供了较低的每 GiB 内存成本。建议将这两个类用于内存密集型工作负载，包括托管 Babelfish 的 PostgreSQL 等开源数据库。因此，我在 Babelfish 测试中加入了这些课程。

2022 年 7 月 15 日，亚马逊 Aurora PostgreSQL 兼容版 宣布支持 db.r6i 实例类。 该系列中的实例由第三代英特尔至强可扩展处理器提供支持，非常适合 SQL 和 NoSQL 数据库等内存密集型工作负载。由于 Aurora 现在支持这些新实例，因此将它们纳入 Babelfish 测试阵容是很自然的。

考虑到测试数据库的大小相对较大，我选择了每个类中的大型实例进行测试。最终选择进行测试的阵容如表 1 所示：

表 1.用于 Babelfish 性能测试的实例类型阵容。

2.3。选择用于基准测试的虚拟用户数量

HammerDB 虚拟用户 是对数据库进行压力测试的模拟用户。要估计系统的最大性能，最好从相对较少的虚拟用户开始，然后逐渐增加他们的数量，直到数据库达到其最高性能水平。当我们增加虚拟用户数量（代表系统负载）时，性能指标 将一直增长，直到达到饱和点 ，在此期间，增长停止甚至下降。

当数据库接近饱和点时，性能变化变得越来越慢。因此，对于 HammerDB 基准测试，一系列测试的虚拟用户数量通常按几何级数设置。 我为每个环境选择了以下一组虚拟用户： 256 、 362 、 512 、 724 和 1024 。

通常， 每个虚拟用户 有 4 到 5 个 仓库 是确保虚拟用户在配置的仓库中均匀分布的最低值。考虑到测试集中最小的数据库包含 8,000 个 仓库，将最大虚拟用户数设置为 1,024 是安全的。

2.4。选择绩效指标

HammerDB 报告了 两个绩效指标 ——每分钟交易量 (TPM) 和每分钟新订单 (NOPM)。TPM 是一项传统指标，取决于数据库系统报告交易的方式。NOPM 是一个较新的指标，它基于在测试运行期间插入到 HammerDB n ew_order 表中的订单 数量。HammerDB 根据测试运行前后 n ew_order 表中的记录数来计算 NOPM，因此 NOPM 不依赖于数据库系统报告交易的方式。此外，NOPM与 tpMC每分钟新订单的官方统计记录 密切相关。

基于这些因素，我选择了NOPM作为报告Babelfish性能测试运行的指标。

2.5。确定每种测试配置的性能

为了获得统计上稳定的结果，对于每组数据库（参见第 2.1 节）和每个 Aurora 集群配置（参见第 2.2 节），我使用第 2.3 节中定义的虚拟用户数量在不同的工作负载级别下进行了一系列性能测试。我重复了每项测试 3 次，并得出了相同工作量水平下的平均结果。

对于每个 Aurora 集群配置和每个数据库大小，我将 Babelfish 性能定义为相应配置达到的最大性能。例如，图 1 显示了 Babelfish 在配置有 d b.r5.12xlarge 实例的 Aurora 集群上进行性能测试的结果。此图表上的每个点都是 3 次测试运行的平均值。

在这种情况下，Babelfish 在三个数据库分别为 724 个 虚拟用户的负载级别上都达到了最佳性能，因此我接受每种数据库大小的 724 个 虚拟用户的 NOPM 值作为该集群对相应数据库的 Babelfish 性能。在为集群使用更强大的实例时，Babelfish 在对应于 1,024 个 虚拟用户的负载级别上达到了最高性能。

图 1。 基于 db.r5.12xlarge 的 Babelfish 集群基准测试结果。

3。分析性能结果

表 2 列出了我选择对三个数据库进行测试的所有 Babelfish Aurora 集群的基准测试结果。我还使用 亚马逊云科技 定价计算器 估算了每个集群的每月成本。当我比较相同大小的数据库中的集群之间的性能结果时，我仅估计了集群计算部分的成本，因为相同大小的数据库的数据存储成本是相同的。请注意表 2 最后一列中计算出的计算成本。

表 2.Babelfish 基准测试结果。

3.1。 比较 db.r5 和 db.r6i 实例类 的 结果

让我们首先重点比较 db.r5 和 db.r6i 类 的结果。 这两个类中的所有实例都经过内存优化且基于 Intel。 它们提供相同的实例大小，只是 db.r6i 类提供了 db.r6 i. 32xlarge 实例，而 db.r5 类 中没有可 比实例。 为了便于比较，表 3 显示了这两个类别的可比实例的 Babelfish 基准测试结果。

表 3. 可比 db.r5 和 db.r 6i 实例的基准测试结果。

如表 3 所示，可比的 db.r5 和 db.r 6i 实例为 Aurora 集群提供相同的成本，但提供的性能点却大不相同，在所有实例和数据库大小上，db.r6i 都超过了 db.r 5。 我总结了 db.r6i 实例与各种数据库的同类 db.r5 实例相比的性能增益，并在图 2 中给出了这些结果。

图 2。 在不同的数据库大小下， db.r6i 实例的性能比同类的 db.r 5 实例有所提高。

如图 2 所示，根据数据库的实例大小和大小， db.r6i 实例提供的性能提升介于 25% 到 45% 之间 。 为了解释这种性能差异，我采集了在 db.r 5.24xlarge 和 db.r6i.24xlarge 上运行的测试的 Amazon CloudWatch 指标（见图 3）。

图 3。亚马逊 CloudWatch 指标快照。

图 3 中的第一张图表表示 CPU 利用率。图表上的每个 “峰值” 对应一系列 3 次运行中的一次测试，从左边的 256 个虚拟用户发展到右边的 1,024 个虚拟用户。对于每个实例系列，CPU 利用率从50％左右开始，随着负载的增加达到70％左右。

但是，我们对 IOPS 的看法完全不同。 对于 db.r5.24xlarge ，IOPS达到约 22.5万个 ，而对于 db.r6i.24xlarge ，IOPS高出约20 ％，约为27.5万个 。 我们可以看到 db.r6i.24xlarge 的存储吞吐量也有类似的情况 ，它的吞吐量再次比 db.r5.24xlarge 高出大 约 25%。

回顾表 3，可比的 db.r6i 实例提供的 亚马逊弹性区块存储 (Amazon EBS) 吞吐量明显高于 db.r5 实例。 这种存储性能差异是基于 db.r6i 实例系列的 Aurora 集群比基于相同大小的 db.r 5 实例的集群提供更高的 Hammer D B 性能结果的原因。

考虑到基于相同大小的 db.r5 和 db.r 6i 实例的 Aurora PostgreSQL 集群的成本相同，以及 db.r 6i 系列的性能优势，考虑将 db.r 5 用于新的 Babelfish 部署毫无意义。 对于现有的 Babelfish 部署，将集群升级到 db.r6i 系列并通过在不牺牲性能的情况下缩小到较小的实例大小来节省成本是有意义的。因此，我将把 db.r5 实例类排除在进一步考虑之外。

3.2。分析各种实例类别的价格/性能

不包括 db.r5 实例，我们只有 8 个实例。表 4 显示了按性能级别分组（低端、中端和高端）的实例的测试结果。对于每个性能组，我还提供了每 1,000 NOPM 的计算成本，这为比较不同实例类型提供了良好的基础。

表 4.每 1,000 NOPM 的性能和成本。

db.x2g 系列的实例无法提供有竞争力的性能。内存的扩展导致该系列中实例的价格上涨，这意味着 Babelfish 性能略高，而产生的额外成本是不合理的。

表 5 总结了本次基准测试中 Babelfish OLTP 工作负载的最佳选项，即选定的数据库大小和虚拟用户范围。我按照 Aurora 集群的价格区间对表中的实例进行了分组。

表 5.Babelfish OLTP 工作负载的推荐实例系列。

在较低的价格区间中， db.r6g.12xlarge 实例尽管性能较低，但总体成本较低，因此在所有测试的数据库大小 中，每 1,000 NOPM 的成本相当，但略高。 中间括 号中的 db.r6g.16xlarge 和 db.r6i.16xl arge 实例之间也有类似的关系 。 排在第一位， db.r6i 高端实例性能最高，但价格更高。

3.3。性能是数据库大小的函数

另一个有趣的观点是分析 Babelfish 性能如何取决于各种集群配置的数据库大小。我在图 4 的图表上绘制了相关数据。低端实例，如 db.r6g.12xlarge 和 db.r6i.12xl arge，随着数据库大小的增加 ，性能呈 均匀线性下降。

图 4。性能与数据库大小。

我们用于 Babelfish 集群的实例越大，它对数据库大小的初始变化就越敏感，但随后随着数据库规模的进一步增长，性能的下降就会停止。

对于较小的实例，即使是最小的数据库也会大大超过可用 RAM 的数量。因此，从一开始，相应的 Babelfish 性能就由底层实例的 EBS 吞吐量定义。

对于较大的实例，有很大一部分（如果不是整个 0.87 TB 的数据库）可以存入 RAM。因此，从大小低于 1 TB 的数据库过渡到 3.3 TB 意味着从主要适合 RAM 的数据库过渡到大大超过可用 RAM 量的数据库。这就是开始时大幅下降的原因，后来由于Babelfish的性能越来越依赖于实例的EBS吞吐量，下降幅度逐渐趋于平稳。

4 结论

如果你的 SQL Server 数据库与 Babelfish 兼容，或者你可以让它兼容一些更改，那么 Babelfish 是简化 SQL Server 工作负载向亚马逊 Aurora 平台迁移的可靠工具。考虑将 DMS 与 Aurora PostgreSQL 目标终端节点一起使用， 以获得将 SQL Server 迁移到 Babelfish 的最佳性能。

考虑使用基于 Graviton2 的实例部署 Babelfish 集群，因为它们比基于英特尔的同类实例便宜，尽管性能水平略低。为 Babelfish 集群选择特定实例类型时，请检查您的数据库大小和所需的性能级别。

认识到需要对数据库运行负载测试以确定适用于您的工作负载的最佳 Aurora 集群配置。

亚马逊云科技 可以帮助您评估贵公司如何充分利用云计算。加入数百万信任我们在云端迁移和现代化他们最重要的应用程序的 亚马逊云科技 客户的行列。要了解有关对 Windows 服务器或 SQL Server 进行现代化的更多信息，请访问 亚马逊云科技 上的 Windows 。 立即联系我们 ，开始您的现代化之旅。