比较 Babelfish 新版本的性能并将 Babelfish 的性能与 SQL Server 进行比较

在这篇博客文章中，我将比较 适用于Aurora PostgreSQL的最新版本的 Babelfish的性能， 并提供Babelfish和微软SQL S erver 2022之间的性能和性价比比较。

1。简介

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

今年，我们推出了 Babelfis h的几 款新版本 ，同时还推出了 Amazon Aurora PostgreSQL 的新版本 。 通过使用适用于 PostgreSQL 的 Aurora，Babelfish 受益于高级的 Aurora 存储 和可靠性功能。 Babelfish 最近发布的两个版本是适用于 Aurora 的 Babelfish PostgreSQL 3.1 和 3. 2 ，分别 基于 Aurora for PostgreSQL 版本 15.2 和 15.3。 每个版本都增加了新功能、性能改进和稳定性增强。这些版本的一个显著特点是 Amazon Aurora I/O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-

Babelfish 不断成熟并提供更多特性和功能，因此，它正在增加 Babelfish 上兼容的 SQL Server 工作负载的数量。越来越多的 亚马逊云科技 客户 计划或正在将 他们的 SQL Server 工作负载迁移到 Babelfish。为了降低迁移风险， babelfis h_compass GitHub 存储库 中提供的 Babelfish Compass 工具 会随着每个 Babelfish 新版本的发布而更新。此工具有助于评估您的数据库与 Babelfish 的兼容性，并 确定 Babelfish 功能改进 对迁移路径的影响 。

除了新的特性和功能外，现有的Babelfish客户还有兴趣了解升级到最新版本的Babelfish可以带来什么样的性能提升。同样，计划将其SQL Server工作负载迁移到Babelfish的客户想知道与Babelfish相比，他们在SQL Server上的性能会如何。为了回答这些问题，我按照博客文章《为 A urora PostgreSQL 设置 Babelfish 以使用 HammerDB 进行性能测试》中概述的 设置进行了一系列 Babelfish 性能测试。

2。Babelfish 基准测试场景

在本节中，我将回顾用于测试的数据库设置、选择特定实例类型来部署 SQL Server 和 Babelfish 集群的原因，以及选择工作负载级别的指南。我还将介绍用于比较的性能指标的选择以及如何确定每种测试配置的性能水平。

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

我将使用 HammerDB 4.4 OLTP 工作负载 进行 Babelfish 版本比较和 Babelfish 与 SQL Server 的比较基准测试，因为 OLTP 工作负载在 SQL Server 向 亚马逊云科技 的迁移中很普遍。对于OLTP工作负载测试，我生成了一个包含10,000个仓库的HammerDB数据库，如博客文章 基准 交易数据库中所述。 如果 每个仓库的数据库大小为 100 MB ，则测试数据库为 1TB。这个数据库比我在博客文章《 Babelfish for Aurora PostgreSQL 性能测试结果》中使用的8,000个仓库数据库稍大 ，但结果 应该仍然具有可比性。

2.2。选择要测试的实例类型

在我 之前的博客文章 中 ，典型的中端 Babelfish 集群是使用 内存优化 的 db.r6g 和 db. r6i 亚马逊 EC2 实例构建的。 这提供了最佳的性价比特征。为了比较 Babelfish 新版本的性能，我将基于这些实例系列在各种配置下使用 Babelfish 集群进行一系列测试。

由于 SQL Server 不支持 亚马逊云科技 Graviton-2 处理器，为了生成 SQL Server 性能数据，我将在不同大小的亚马逊 EC2 r6i 实例上使用 SQL Server 部署，这些实例 的大小与用于 Babelfish 的实例大小相当。

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

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

随着数据库接近饱和点，虚拟用户数量的增加导致 SQL Server 性能的提高幅度较小。因此，在HammerDB基准测试系列中，我设置了虚拟用户的数量以几何级数递增。对于较小的实例，我使用了 256 、 362 、 512 和 724 个 虚拟用户的集合，对于较大的实例，我将其扩展到了 256 、 362 、 512 、 724 和 1024 个 虚拟用户。

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

2.4。选择绩效指标

HammerDB 报告了两个绩效指标： 每分钟 交易量 (TPM) 和每分钟新订单数 ( NOPM)。 TPM 是一项传统指标，取决于数据库系统报告交易的方式。NOPM 是一个较新的指标。HammerDB 根据测试运行前后 n ew_order 表中的记录数来计算 NOPM，因此 NOPM 不依赖于数据库系统报告交易的方式。这允许使用 NOPM 指标进行跨平台比较，而 TPM 仅适用于比较同一平台内的性能。

除了比较 Babelfish 不同版本的性能外，我还想在 SQL Server 和 Babelfish 之间建立性能比较。我选择了 NOPM 作为衡量标准，用于测试运行的性能比较。

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

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

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

图 1。Babelfish 上有 10,000 个仓库 HammerDB 数据库的 r6g.8xlarge 性能测试结果。

在这种情况下，对于包含10,000个仓库的HammerDB数据库，Babelfish在512个虚拟用户的负载水平上达到了最佳性能。因此，我接受 512 个虚拟用户的 NOPM 值作为该集群的 Babelfish 性能。当为集群使用更强大的实例时，Babelfish 和 SQL Server 可能会在与更多虚拟用户相对应的负载级别上达到最佳性能。

3。比较 Babelfish 版本 3.1 和 3.2（以及 2.4）的性能

测试是使用不同大小和处理器架构的实例进行的，结果按实例大小分组。

3.1。8 倍大实例

在此类别中，我将重点介绍按处理器架构分组的 8xlarge 类别 中的实例之间的比较。该组的性能测试结果如表 1 所示。

表 1. 8xL arge 实例的性能测试结果

根据表 1 中的数据，对于选定的实例，Babelfish 3.2 与之前的版本相比提供了大约 3% 的 性能优势。

3.2。12 倍大实例

在此类别中，我将重点比较按处理器系列分组的 12xlarge 类别中的实例。对于这组测试，我可以用我的博客文章《 Babelfish for Aurora PostgreSQL 性能测试结果》中的结果来补充当前的 测试结果。 我无法直接比较性能数据，因为在那篇博客文章中，我使用了 8,000 个仓库的 HammerDB 数据库，而我当前的性能数据是使用 10,000 个仓库的数据库收集的。使用原始帖子图 4 中显示的 “ 性能与数据库大小 ” 图表，可以很容易地计算出调整系数，从而使用为 8,000 个仓库数据库获得的原始性能数据来估计 10,000 个仓库数据库的结果。计算出的调整系数介于 98% 到 99 % 之间。

现在，我们可以将 Babelfish 版本 3.1 和 3.2 获得的性能结果与 Babelfish 2.4 的早期结果进行比较。表 2 记录了我当前的测试结果以及上一篇博客文章中对 Babelfish 2.4 的调整结果：

表 2. 12xL arge 实例的性能测试结果

如表 2 所示，随后的每个 Babelfish 版本都表现出更好的性能。而且，对于基于Graviton-2处理器的Babelfish集群来说，Babelfish的性能提升似乎更为可观。

3.3。16 倍大实例

该组代表基于 16 xlarge 实例的 Babelfish 集群获得的测试结果。对于 Babelfish 2.4，我使用了之前博客文章中的调整后的性能数据。表 3 显示了该组的性能测试结果：

表 3.16xlarge 实例的性能测试结果

如表 3 所示，与旧版本相比，较新的 Babelfish 版本提供了显著的性能提升。

3.4。Babelfish 3.2 性能和性价比分析

根据测试，我们已经确定 Babelfish 表现最好的版本是 3.2 版本。 现在，让我们重点比较基于 Graviton-2 ( R6g ) 和英特尔 (R6i ) 实例的集群的性能。 相应的性能数据如表 4 所示：

表 4性能对比 — 基于英特尔的实例与 Graviton-2 的实例。

从性能比较来看，使用基于英特尔的实例的 Babelfish 集群的表现比使用基于 Graviton-2 的实例的相对规模的集群高出 3.5% 至 8.5%。

现在让我们看看不同大小的 Babelfish 集群和底层 Amazon EC2 实例之间的性能差异如何转化为每 1,000 NOPM 的成本。所有用于性能测试的 Babelfish 集群均使用 Aurora I/O 优化构建，可为使用 I/O 密 集型 应用程序的客户提供更高的性价比和可预测的价格。

由于所有测试数据库的大小都约为 1 TB，因此我使用了具有 1.3 TB 存储空间的 Aurora I/O 优化定价模型来估算成本。这些估计是针对 美国东部一号 亚马逊地区 的 ，在发布时是正确的。本次测试中使用的 Babelfish 3.2 集群的性价比数据如表 5 所示：

表 5.Babelfish 3.2 性价比分析。

值得注意的是，尽管性能存在显著差异，但在相同的计算机架构中，Aurora I/O 优化的 Babelfish 集群每千个 NOPM 的成本是稳定的。基于英特尔的集群可以提供更好的 Babelfish 性能，但每 1,000 NOPM 的成本更高。

4。将 SQL 服务器性能与 Babelfish 3.2 进行比较

Amazon EC2 提供了 多种 经过优化以适应不同用例的实例类型。实例类型包含 CPU、内存、存储和网络容量的不同组合，使您可以灵活地为应用程序选择适当的资源组合。每种实例类型都包含一种或多种实例大小，允许您扩展资源以满足目标工作负载的需求。对所有可能的配置实施 SQL Server 性能测试是不切实际的。

在本次分析中，我选择了专门 推荐用于 SQL 工作负载的新一代 Amazon EC2 实例 R6i 。 亚马逊 EC2 实例的 R6i 系列提供多种大小，因此，为了进行分析，我选择了 R6i.8xLarge 和 R6 i.12xLarge 等广受欢迎的中端 SQL Server 部署选项。

4.1。比较部署在 R6i.8xLarge 上的 SQL Server 与 Babelfish 3.2

R6i.8xLarge 实例提供 32 个 vCPU 和 256 GB 内存，最多可支持 40,000 次 IOPS。为了充分利用此实例的功能，我在 Windows Server 2022 上部署了 SQL Server 2022 企业版。我为这个实例配置了 1.3 TB 的 IO2 Block Expres s Amazon EBS 卷，该卷配置为 40,000 IOPS，以匹配 R 6i.8xLarge 实例 IOPS 限制。

HammerDB 测试数据库和 SQL Server 是按照 HammerDB 基准测试的 HammerDB SQL Server 性能和可扩展性最佳实践 文档配置的。使用这个配置，我使用相同的 10,000 个仓库数据库运行了 HammerDB 性能测试，以进行有效的比较。表 6 列出了这些测试的结果以及表 1 中同类硬件上的 Babelfish 3.2 的性能结果：

表 6. 适用于 8xlarge 实例的 SQL Server 和 Babelfish 3.2 的 NOPM 性能指标。

图 2 中的图表以图形形式表示表 6 中的数据。通过这些测试，Babelfish 3.2 提供了比 SQL Server 更好的性能。

图 2。 适用于 8xlarge 实例的 SQL Server 和 Babelfish 3.2 的 NOPM 性能指标。

有了既定的性能特征，让我们来看看相应解决方案的成本。为了估算 SQL Server 部署的成本，我使用了 亚马逊云科技 定价计算器 。我使用了无需预付款的按需部署选项，这与我在估算 Babelfish 集群成本时使用的假设相同。表 7 中记录了相应配置的成本估算值和性能数据：

表 7成本和性价比摘要

Babelfish 不仅降低了每 1,000 个 NOPM 的成本，而且总体部署成本也降低了多达 70%。

4.2。比较部署在 R6i.12xLarge 上的 SQL Server 与 Babelfish 3.2

下一步是对部署在 R6i. 12xLarge 实例上的 SQL Server 运行性能测试。此实例提供 48 个 vCPU 和 384 GB 内存，在与亚马逊 EBS 存储卷通信时支持 60,000 次 IOPS。与前一组测试中使用的 R6i.8xLarge 实例相比，每个功能参数都 增加了 50%。因此，SQL Server 的性能水平是在 R6 i.8xLarge 上达到的两倍也就不足为奇了。相关测试运行的结果如表 8 和图 3 中的图表所示：

表 8在可比实例上，SQL Server 12xlarge 和 Babelfish 3.2 的 NOPM 性能指标。

图 3。在可比实例上，SQL Server 12xlarge 和 Babelfish 3.2 的 NOPM 性能指标。

部署在 R6g.12xLarge 和 R6i.12xLarg e 实例上的 Babelfish 集群表现出良好的性能水平，但无法与 SQL Server 提供的性能水平相提并论。部署在大一步的实例上的 Babelfish 集群能够表现出相同或更高的性能水平。

就这些配置的总体成本和性价比而言，相关数据如表 9 所示：

表 9成本和性价比摘要

即使将 Babelfish 集群升级到更大的实例大小以匹配或超过 SQL Server 性能，Babelfish 部署的总体成本也 降低了多达 60% ，性价比也更高。

结论

根据本博客文章中提供的结果，我们可以得出以下两个结论：

1。Babelfish 版本 3.2 的性能优于之前发布的 Babelfish 版本。因此，如果您当前在 Babelfish 的早期版本上运行数据库工作负载，则升级部署是有意义的，特别是考虑到升级 Babelfish 集群 是一个相当简单的 操作。 如果你计划在 亚马逊云科技 上部署新的 Babelfish 或将 SQL Server 工作负载迁移到 Babelfish，请务必考虑最新的 Babelfish 版本。它将提供 更多功能 、更好的与 SQL Server 的兼容性以及更高的性能。

2。如果您的 SQL Server 工作负载与 Babelfish 兼容或可以与 Babelfish 兼容，则迁移到 Babelfish 将以低得多的成本为您提供相同或更好的性能，并使您摆脱许可要求。

如果你认为 Babelfish 可以满足你的功能和性能需求，并想将你的 SQL Server 工作负载迁移到 Babelfish，请阅读我们的 Auror a PostgreSQL 文档和使用 Babelfish 从 SQL Server 迁移到亚马逊 A urora 博客文章。

与任何其他云提供商相比，亚马逊云科技 提供的服务和这些服务中的功能要多得多，这使得将现有应用程序迁移到云端并构建几乎可以想象的任何东西变得更快、更容易、更具成本效益。为你的 Microsoft 应用程序提供所需的基础架构，以推动你想要的业务成果。访问我们的 亚马逊云科技 上的 .NET 和 亚马逊云科技 数据库 博客，获取有关微软工作负载的更多指导和选项。 联系我们 ，立即开始您的迁移和现代化之旅。