在 vCore 和 DTU 购买模型之间进行选择Choose between the vCore and the DTU purchasing model

使用 Azure SQL 数据库,可以轻松购买适合你的性能和成本要求的完全托管的 PaaS 数据库引擎。Azure SQL Database enables you to easily purchase fully managed PaaS database engine that fits your performance and cost needs. 你可以根据 Azure SQL 数据库的部署模型选择适合你的需求的购买模型:Depending on the deployment model of Azure SQL Database, you can select the purchasing model that fits your needs:

  • 基于 vCore 的购买模型(推荐)。vCore-based purchasing model (recommended). 此购买模型允许在预配的计算层级和无服务器(预览)计算层级之间进行选择。This purchasing model provides a choice between the provisioned compute tier and serverless (preview) compute tier. 使用预配的计算层级时,可以选择始终为工作负荷预配的确切计算量。With the provisioned compute tier, you choose the exact amount of compute that is always provisioned for your workload. 使用无服务器计算层级时,可以配置对计算进行的自动缩放(在可配置的计算范围内)。With the serverless compute tier, you configure the auto-scaling of compute over a configurable compute range. 使用此计算层级时,还可以根据工作负荷活动自动暂停和恢复数据库。With this compute tier, you also have an option to automatically pause and resume the database based on workload activity. 预配计算层级中单位时间的 vCore 单位价格低于无服务器计算层级中的相应价格。The vCore unit price per unit of time is lower in the provisioned compute tier than in the serverless compute tier.
  • 基于 DTU 的购买模型DTU-based purchasing model. 此购买模型针对常见工作负荷提供均衡的捆绑计算和存储包。This purchasing model provides bundled compute and storage packages balanced for common workloads.

Azure SQL 数据库部署模型中提供了不同的购买模型:Different purchasing models are available in Azure SQL Database deployment models:

以下表格和图表对 vCore 和 DTU 购买模型做了对比。The following table and chart compare and contrast the vCore and the DTU purchasing models.

购买模型Purchasing model 说明Description 最适用于Best for
基于 DTU 的模型DTU-based model 此模型基于计算、存储和 IO 资源的捆绑度量。This model is based on a bundled measure of compute, storage, and IO resources. 单一数据库的计算大小以数据库事务单位 (DTU) 表示,弹性池则以弹性数据库事务单位 (eDTU) 表示。Compute sizes are expressed in terms of Database Transaction Units (DTUs) for single databases and elastic Database Transaction Units (eDTUs) for elastic pools. 有关 DTU 和 eDTU 的详细信息,请参阅什么是 DTU 和 eDTU?For more on DTUs and eDTUs, see What are DTUs and eDTUs?. 最适合希望获得简单预配置资源选项的客户。Best for customers who want simple, pre-configured resource options.
基于 vCore 的模型vCore-based model 此模型允许单独选择计算和存储资源。This model allows you to independently choose compute and storage resources. 基于 vCore 的购买模型还允许使用适用于 SQL Server 的 Azure 混合权益来节省成本。The vCore-based purchasing model also allows you to use Azure Hybrid Benefit for SQL Server to gain cost savings. 最适合注重灵活性、控制度和透明度的客户。Best for customers who value flexibility, control, and transparency.

定价模型

计算成本Compute costs

预配计算成本Provisioned compute costs

在预配计算层级中,计算成本反映针对应用程序预配的总计算容量。In the provisioned compute tier, the compute cost reflects the total compute capacity that is provisioned for the application. 在“业务关键”服务层级中,我们会自动分配至少 3 个副本。In the business critical service tier, we automatically allocate at least 3 replicas. 为了反映计算资源的此额外分配,在基于 vCore 的购买模型中,“业务关键”服务层级的价格比“常规用途”服务层级的价格高约 2.7 倍。To reflect this additional allocation of compute resources, the price in the vCore-based purchasing model is approximately 2.7x higher in the business critical service tier than in the general purpose service tier. 出于相同的原因,“业务关键”服务层级中更高的每 GB 存储价格反映了 SSD 存储的高 IO 和低延迟。For the same reason, the higher storage price per GB in the business critical service tier reflects the high IO and low latency of the SSD storage. 同时,备份存储成本在这两个服务层级之间并无不同,因为在这两种情况下,我们都使用某类标准存储。At the same time, the cost of backup storage is not different between these two service tiers because in both cases we use a class of standard storage.

无服务器计算成本Serverless compute costs

对于无服务器计算层级,请参阅 SQL Database serverless (preview)(SQL 数据库无服务器(预览版)),了解如何定义计算容量以及如何计算成本。For the serverless compute tier, see SQL Database serverless (preview) for a description of how compute capacity is defined and costs are calculated.

存储费用Storage costs

不同存储类型的计费方式各不相同。Different types of storage are billed differently. 对于数据存储,你要根据所选的最大数据库或池大小支付预配存储的费用。For data storage, you are charged for the provisioned storage based upon the maximum database or pool size you select. 除非减小或增大该最大值,否则费用不会变化。The cost does not change unless you reduce or increase that maximum. 备份存储与实例的自动备份相关联,并动态分配。Backup storage is associated with automated backups of your instance and is allocated dynamically. 延长备份保留期会使实例使用的备份存储空间增大。Increasing your backup retention period increases the backup storage that’s consumed by your instance.

默认情况下,数据库的 7 天自动备份会复制到 RA-GRS 标准 blob 存储。7 days of automated backups of your databases are copied to RA-GRS Standard blob storage by default. 存储由每周完整备份、每日差异备份和 5 分钟复制一次的事务日志备份使用。The storage is used by weekly full backups, daily differential backups, and transaction log backups copied every 5 minutes. 事务日志的大小取决于数据库的变化率。The size of the transaction log depends on the rate of change of the database. 提供与 100% 数据库大小相等的最小存储量,不收取额外费用。A minimum storage amount equal to 100% of database size is provided at no extra charge. 超出此部分的其他备份存储用量将以 GB 为单位每月进行收费。Additional consumption of backup storage will be charged in GB/month.

有关存储价格的详细信息,请参阅定价页。For more information about storage prices, see the pricing page.

基于 vCore 的购买模型vCore-based purchasing model

虚拟核心表示通过一个选项提供的逻辑 CPU,该选项允许在硬件的层代和硬件的物理特性(例如,核心数、内存、存储大小)之间进行选择。A virtual core represents the logical CPU offered with an option to choose between generations of hardware and physical characteristics of hardware (for example, number of cores, memory, storage size). 基于 vCore 的购买模型提供使用单项资源的灵活性、控制度和透明度,并提供简单明了的方法将本地工作负荷要求转换到云。The vCore-based purchasing model gives you flexibility, control, transparency of individual resource consumption and a straightforward way to translate on-premises workload requirements to the cloud. 此模型允许根据工作负荷需求来选择计算、内存和存储。This model allows you to choose compute, memory, and storage based upon their workload needs. 在基于 vCore 的购买模型中,可为单一数据库弹性池选择常规用途业务关键服务层级。In the vCore-based purchasing model, you can choose between general purpose and business critical service tiers for single databases, elastic pools. 对于单一数据库,还可以选择超大规模服务层级For single databases, you can also choose the hyperscale service tier.

使用基于 vCore 的购买模型,可以单独选择计算和存储资源、匹配本地性能,以及优化价格。The vCore-based purchasing model enables you to independently choose compute and storage resources, match on-premises performance, and optimize price. 在基于 vCore 的购买模型中,客户的费用包括:In the vCore-based purchasing model, customers pay for:

  • 计算(服务层级 + vCore 数目和内存量 + 硬件层代)Compute (service tier + number of vCores and amount of memory + generation of hardware)
  • 数据和日志存储的类型与数量Type and amount of data and log storage
  • 备份存储 (RA-GRS)Backup storage (RA-GRS)

Important

计算、IO、数据和日志存储按数据库或弹性池收费。Compute, IOs, data and log storage are charged per database or elastic pool. 备份存储按每个数据库收费。Backups storage is charged per each database.

如果单一数据库或弹性池消耗的 DTU 超过 300 个,则转换为基于 vCore 的购买模型可以降低成本。If your single database or elastic pool consumes more than 300 DTUs, converting to the vCore-based purchasing model may reduce your cost. 如果决定进行转换,可以使用所选的 API 或 Azure 门户进行转换,无需停机。If you decide to convert, you can convert using your API of choice or using the Azure portal, with no downtime. 但是,转换不是必需的并且不会自动完成。However, conversion is not required and is not done automatically. 如果基于 DTU 的购买模型可以满足性能和业务要求,应继续使用它。If the DTU-based purchasing model meets your performance and business requirements, you should continue using it. 如果决定从基于 DTU 的购买模型转换为基于 vCore 的购买模型,请使用以下经验法则来选择计算大小:If you decide to convert from the DTU-based purchasing model to the vCore-based purchasing model, select the compute size using the following rules of thumb:

  • 标准层中的每 100 个 DTU 至少需要常规用途层中的 1 个 vCoreEach 100 DTU in Standard tier requires at least 1 vCore in General Purpose tier
  • 高级层中的每 125 个 DTU 至少需要业务关键层中的 1 个 vCoreEach 125 DTU in Premium tier requires at least 1 vCore in Business Critical tier

基于 DTU 的购买模型DTU-based purchasing model

数据库事务单位 (DTU) 表示 CPU、内存、读取和写入的混合度量。The Database Transaction Unit (DTU) represents a blended measure of CPU, memory, reads, and writes. 基于 DTU 的购买模型提供一组预配置的计算资源套件和随附的存储,以实现不同级别的应用程序性能。The DTU-based purchasing model offers a set of pre-configured bundles of compute resources and included storage to drive different levels of application performance. 偏爱预配置套件简易性和每月定价付款的客户,可能会发现基于 DTU 的模型更适合其需求。Customers who prefer the simplicity of a pre-configured bundle and fixed payments each month, may find the DTU-based model more suitable for their needs. 在基于 DTU 的购买模型中,客户可为单一数据库弹性池选择“基本”、“标准”或“高级”服务层级。In the DTU-based purchasing model, customers can choose between basic, standard, and premium service tiers for both single databases and elastic pools.

数据库事务单位 (DTU)Database transaction units (DTUs)

对于服务层级内特定计算大小的单一数据库,Azure 保证该数据库(独立于 Azure 云中的任何其他数据库)可获得一定级别的资源,从而提供可预测的性能级别。For a single database at a specific compute size within a service tier, Azure guarantees a certain level of resources for that database (independent of any other database in the Azure cloud), providing a predictable level of performance. 此资源量是以若干数据库事务单位或 DTU 计算的,是计算资源、存储资源和 IO 资源的捆绑度量值。The amount of resources is calculated as a number of Database Transaction Units or DTUs and is a bundled measure of compute, storage, and IO resources. 这些资源之间的比例最初由 OLTP 基准工作负荷确定,该工作负荷是一种典型的真实 OLTP 工作负荷。The ratio amongst these resources was originally determined by an OLTP benchmark workload, designed to be typical of real-world OLTP workloads. 工作负荷超过任何以上资源量时,吞吐量将受到限制,从而导致性能下降和超时。When your workload exceeds the amount of any of these resources, your throughput is throttled - resulting in slower performance and timeouts. 工作负荷使用的资源不会影响 Azure 云中其他 SQL 数据库可用的资源,而其他工作负荷使用的资源也不会影响用户自己的 SQL 数据库可用的资源。The resources used by your workload do not impact the resources available to other SQL databases in the Azure cloud, and the resources used by other workloads do not impact the resources available to your SQL database.

边界框

要了解 Azure SQL 数据库在不同计算大小和服务层级之间的资源相对数量,DTU 将最为有用。DTUs are most useful for understanding the relative amount of resources between Azure SQL databases at different compute sizes and service tiers. 例如,提高数据库的计算大小可使 DTU 加倍,这等同于使该数据库可用的资源集增加一倍。For example, doubling the DTUs by increasing the compute size of a database equates to doubling the set of resources available to that database. 例如,具有 1750 个 DTU 的高级 P11 数据库提供的 DTU 计算能力是具有 5 个 DTU 的基本数据库的 350 倍。For example, a Premium P11 database with 1750 DTUs provides 350x more DTU compute power than a Basic database with 5 DTUs.

若要更深入地了解工作负荷的资源 (DTU) 消耗,请使用查询性能见解To gain deeper insight into the resource (DTU) consumption of your workload, use query performance insights to:

  • 按 CPU/持续时间/执行计数确定热门查询,可以对这些查询进行调整来提高性能。Identify the top queries by CPU/Duration/Execution count that can potentially be tuned for improved performance. 例如,IO 密集型查询可能会受益于使用内存中优化技术,以便通过特定的服务层级和计算大小更好地利用可用内存。For example, an IO intensive query might benefit from the use of in-memory optimization techniques to make better use of the available memory at a certain service tier and compute size.
  • 深入了解查询详情,查看其文本和资源使用历史记录。Drill down into the details of a query, view its text and history of resource utilization.
  • 访问性能优化建议,这些建议可显示 SQL 数据库顾问执行的操作。Access performance tuning recommendations that show actions performed by SQL Database Advisor.

弹性数据库事务单位 (eDTU)Elastic Database Transaction Units (eDTUs)

可将数据库放在 SQL 数据库服务器上的弹性池中,该服务器在这些数据库之间共享资源池,而不必为 SQL 数据库提供一组始终可用的专用资源 (DTU),因为有时可能并不需要。Rather than provide a dedicated set of resources (DTUs) that may not always be needed for a SQL Database that is always available, you can place databases into an elastic pool on a SQL Database server that shares a pool of resources among those databases. 弹性池中的共享资源用弹性数据库事务单位或 eDTU 度量。The shared resources in an elastic pool are measured by elastic Database Transaction Units or eDTUs. 弹性池提供一种简单的低成本高效益的解决方案,用于管理使用模式变化很大且不可预测的多个数据库的性能目标。Elastic pools provide a simple cost effective solution to manage the performance goals for multiple databases having widely varying and unpredictable usage patterns. 弹性池可保证不出现一个数据库使用池中所有资源的情况,同时确保池中的每个数据库始终可以使用最少量的必需资源。An elastic pool guarantees resources cannot be consumed by one database in the pool, while ensuring each database in the pool always has a minimum amount of necessary resources available.

为池提供的 eDTU 的数量和价格是固定的。A pool is given a set number of eDTUs for a set price. 在弹性池中,单独的数据库都被赋予了在配置的边界内自动缩放的灵活性。Within the elastic pool, individual databases are given the flexibility to auto-scale within the configured boundaries. 负载较重的数据库消耗较多的 eDTU 来满足需求。A database under heavier load will consume more eDTUs to meet demand. 负载较轻的数据库消耗较少的 eDTU。Databases under lighter loads will consume less eDTUs. 无负载的数据库不消耗任何 eDTU。Databases with no load will consume no eDTUs. 为整个池而不是每个数据库预配资源可以简化管理任务,使池的预算可预测。By provisioning resources for the entire pool, rather than per database, management tasks are simplified, providing a predictable budget for the pool.

可以向现有池添加额外的 eDTU,不会造成数据库关闭,对池中的数据库也不会有影响。Additional eDTUs can be added to an existing pool with no database downtime and with no impact on the databases in the pool. 同样,可以随时从现有池中删除不再需要的额外 eDTU。Similarly, if extra eDTUs are no longer needed, they can be removed from an existing pool at any point in time. 可以在池中添加或删除数据库,或者限制重负载数据库的 eDTU 用量,以便为其他数据库预留 eDTU。You can add or subtract databases to the pool or limit the amount of eDTUs a database can use under heavy load to reserve eDTUs for other databases. 如果可以预见到某个数据库的资源利用率不高,可将其移出池,并使用所需的可预测资源量将它配置为单一数据库。If a database is predictably under-utilizing resources, you can move it out of the pool and configure it as a single database with a predictable amount of required resources.

确定工作负荷所需的 DTU 数Determine the number of DTUs needed by a workload

如果打算将现有的本地或 SQL Server 虚拟机工作负荷迁移到 Azure SQL 数据库,可以使用 DTU 计算器来估计所需的 DTU 数。If you are looking to migrate an existing on-premises or SQL Server virtual machine workload to Azure SQL Database, you can use the DTU calculator to approximate the number of DTUs needed. 对于现有的 Azure SQL 数据库工作负荷,可以使用查询性能见解来了解数据库资源使用量 (DTU),更深入地了解如何优化工作负荷。For an existing Azure SQL Database workload, you can use query performance insight to understand your database resource consumption (DTUs) to gain deeper insight for optimizing your workload. 也可以使用 sys.dm_db_ resource_stats DMV 查看最近一小时的资源消耗。You can also use the sys.dm_db_ resource_stats DMV to view resource consumption for the last hour. 目录视图 sys.resource_stats 也可显示最近 14 天的资源消耗,不过,五分钟平均值的准确性较低。Alternatively, the catalog view sys.resource_stats displays resource consumption for the last 14 days, but at a lower fidelity of five-minute averages.

受益于资源弹性池的工作负荷Workloads that benefit from an elastic pool of resources

池很适合具有特定使用模式的大量数据库。Pools are suited for a large number of databases with specific utilization patterns. 对于给定的数据库,此模式的特征是低平均使用量与相对不频繁的使用高峰。For a given database, this pattern is characterized by a low utilization average with relatively infrequent utilization spikes. SQL数据库自动评估现有 SQL 数据库服务器中数据库的历史资源使用率,并在 Azure 门户中推荐适当的池配置。SQL Database automatically evaluates the historical resource usage of databases in an existing SQL Database server and recommends the appropriate pool configuration in the Azure portal. 有关详细信息,请参阅何时使用弹性池?For more information, see when should an elastic pool be used?

购买模型:常见问题解答 (FAQ)Purchase models: frequently asked questions (FAQ)

是否需要将应用程序脱机,才能将基于 DTU 的数据库转换为基于 vCore 的服务层级Do I need to take my application offline to convert from a DTU-based database to a vCore-based service tier

新服务层级提供简单的在线转换方式,与现有“标准”和“高级”服务层级间的升级和降级过程类似。The new service tiers offer a simple online conversion method that is similar to the existing process of upgrading databases from Standard to Premium service tier and vice versa. 可以使用 Azure 门户、PowerShell、Azure CLI、T-SQL 或 REST API 启动此转换。This conversion can be initiated using the Azure portal, PowerShell, Azure CLI, T-SQL, or the REST API. 请参阅管理单一数据库管理弹性池See Manage single databases and Manage elastic pools.

是否可以将数据库从使用基于 vCore 的购买模型的服务层级转换为使用基于 DTU 的购买模型的服务层级?Can I convert a database from a service tier using the vCore-based purchase to a service tier using the DTU-based purchasing model

是的,可以使用 Azure 门户、PowerShell、Azure CLI、T-SQL 或 REST API 轻松将数据库转换为支持的任何性能目标。Yes, you can easily convert your database to any supported performance objective using Azure portal, PowerShell, Azure CLI, T-SQL, or the REST API. 请参阅管理单一数据库管理弹性池See manage single databases and manage elastic pools.

后续步骤Next steps