Azure SQL 数据库：服务级别与性能问答

ShawnBice    2014 年 5 月 5 日上午 10:00

几天前，我发表了一篇文章，并就 4 月 24 日发布的适用于Windows Azure SQL 数据库的新服务级别提供了一些预料中的问题和解答，在其中为读者介绍了一些详细信息。在这篇跟进文章中，我想提供一些关于这些服务级别如何影响 SQL 数据库性能的更多信息。

与上一篇文章一样，本文档的最初写作目的也是帮助微软团队人员解决有关新服务级别的常见问题，当然，这些信息也肯定与您密切相关。

Shawn Bice
数据平台团队项目主管

新服务级别如何提升 SQL 数据库性能？

客户一直向我们反映，他们非常重视性能的可预测性。为了解决这一问题，我们起初推出了高级服务级别，以便为具有高吞吐量需求的数据库工作负荷提供支持。我们始终致力于提高性能的可预测性，为此，我们以更低的价格推出了新的服务级别（基本和标准级别），它们在性能上存在主要差别。随着性能水平的提升，可用吞吐量也会随之增加。此项服务设计可以使客户通过部署合理数量的资源来获得其数据库所需的吞吐量。

高级服务级别有何变化？

自 4 月 24 日起，Azure SQL 数据库高级级别预览版推出了全新的 500 GB 最大容量、拥有另一性能级别 (P3)、新的业务连续性功能（活动异地复制和自助式还原）以及简化的配置和计费体验。

高级服务级别有哪些新功能？

活动异地复制： 可以在任何 Azure 区域创建多达四个活动可读辅助数据库并选择何时进行故障转移，以此控制灾难恢复过程。有关使用活动异地复制的详细信息，请参见灾难恢复文档 。

自助式还原： 有了 SQL 数据库高级服务级别，在数据被人为删除或被程序删除的情况下，您可以将数据库还原回过去 35 天内的任意时间点。对数据库还原进行自助式控制可以取代导入/导出的方法。有关使用自助式还原的更多信息，请参见还原服务文档。

更大的数据库容量： 维护高达 500 GB 数据库的费用会包括在日常成本中（不会单独针对数据库容量另行收费）。

新增高级性能级别： 增加了 P3 性能级别，可满足高吞吐量需求，可以最大程度地提升要求最苛刻的数据库工作负荷的性能。要了解有关 SQL 数据库高级服务级别和定价的详细信息，请访问 SQL 数据库定价页面。

什么是性能级别？

Azure SQL 数据库服务级别提出了性能级别的概念。基本、标准和高级服务级别共有 7 个性能级别。这些性能级别分别为基本、S0、S1、S2、P1、P2 和 P3。每个性能级别都可以为运行从轻型到重型的不同数据库工作负荷提供一组所需的资源。

对于不同性能级别可实现的性能水平，客户有何见解？

为了让客户获得可预测性更强的性能体验，SQL 数据库推出了数据库吞吐量单位 (DTU)。DTU 代表数据库引擎的性能，是一个合并了CPU、内存和读写速率的度量单位。此度量单位可以帮助用户评估 SQL 数据库七大性能级别（基本、S0、S1、S2、P1、P2 和 P3）的相对性能。

性能级别可提供以下 DTU：

客户如何才能不考虑硬件规格而选择性能级别？

我们深知，无论是内部部署环境还是虚拟机环境，都会通过计算机规格来评估系统可以为数据库工作负荷提供的运行能力。然而，在平台即服务环境下，这一方法却起不到应有的作用，这种环境本身会对底层硬件和操作系统进行抽象化，并以此作为价值主张，为客户提供整体优势。

客户不断地向我们反馈说，他们会通过选择性能级别、构建应用程序并根据需要测试和优化这些应用程序来评估构建云设计应用程序的性能要求。在内部部署环境下，复杂的硬件规格评估要求比较重要，因为这种环境需要纵向扩展，因此就需要更为谨慎地进行考量和计算。而如果使用数据库即服务，则可以通过 API 或 Azure 门户轻松地调整性能水平。

有关详细信息，请参见 MSDN 上的性能指南。

客户如何才能查看某个性能级别的资源利用率？

客户可以监视可用 CPU、内存和读写 IO 随时间变化的百分比。

每小时、每分钟和每秒事务率是指什么？

每种性能级别的吞吐量都会不断提高。通过汇总每个服务级别的吞吐量，并用每小时、每分钟和每秒支持事务率来表示，客户就可以轻松地将服务级别的功能与应用程序的需求快速关联起来。例如，基本服务级别适用于按每小时事务数对活动进行衡量的应用程序。举例来说，一个面包店的某个销售点 (POS) 终端所需的吞吐量是，在一小时内卖出上百个面包。标准服务级别适用于按每分钟几十个或几百个事务衡量吞吐量的应用程序。高级服务级别适用于密度最高的任务关键型吞吐量，也就是说，每秒需要支持成百上千个并发事务。

如果客户想要用易懂的语言精确地了解 DTU 运行能力，应该如何做？

为了让客户能够使用比较熟悉的参考点来选择合适的性能级别，微软为 7 个性能级别（基本、S0、S1、S2、P1、P2 和 P3）中的每一个性能级别发布了相应的 OLTP 基准数字。这些事务率数据来自内部的微软云基准环境，用于模拟典型 OLTP 云应用程序的数据库工作负荷。与所有其他基准一样，这些事务率数据仅供参考。真实的数据库具有不同的容量和复杂度，并会运行各种各样的工作负荷，其响应方式也各不相同。但是，微软发布的这些事务率数据有助于客户了解每种性能级别的相对吞吐量。微软发布的基准事务率如下所示，有关方法的文章，请参见此处。

谈到 DTU，我们可以参考汽车行业的大量类似情形。使用马力衡量引擎动力时，赛车和卡车对马力的使用有很大不同，因此结果也会不同。同样，对于不同的工作负荷类型，数据库使用 DTU 运行能力也会获得不同的结果。微软基准数字是基于一个已定义的 OLTP 工作负荷（如赛车）的，而客户需要为其独特的工作负荷需求评估性能水平。

通过已发布的基准来定义数据库运行能力相当于在云环境下模拟 TPC-C。TPC-C 是一种传统的行业标准方法，用来定义数据库工作负荷的最大潜在运行能力。熟悉传统数据库和数据库系统的客户会很清楚基准数字的价值以及不足之处。我们发现，初创公司以及新入行的开发人员不太了解标杆行业，然而，他们会更热情地投入到构建、测试和优化之中。

我们认为，为客户提供基准定义的事务率，并使其可以快速构建、试验和优化（纵向扩展），便可满足大多数客户的性能评估需求。

已发布的事务率可以保证吞吐量吗？

微软发布的基准以及相关的事务率并不代表对客户做出事务保证。尽管客户的工作负荷各不相同，但客户不能将高峰期间的事务累积在一起，也不能将各个事务分摊到每秒、每分钟、每小时和每天。客户要想评估实际性能需求，最好的做法就是在 Azure 门户上查看实际资源使用率。详细视图会采用可用 CPU、内存和读写操作在已定义性能级别下的百分比来显示资源使用率随时间变化的情况。

为什么微软不直接为数据库标杆行业标准 TPC 发布基准呢？

目前，TPC 不允许云提供商为数据库工作负荷发布 TPC 基准。当前还没有制定出其他云供应商行业标准。

微软是否会发布可在客户自有环境中运行的基准代码？

目前尚无向客户发布基准的计划。但是，微软将公布一些方法细节（请参见此处），帮助客户运行已定义的 OLTP 工作负荷来实现已公布的基准数字。

本文翻译自：

https://blogs.technet.com/b/dataplatforminsider/archive/2014/05/05/azure-sql-database-service-tiers-amp-performance-q-amp-a.aspx