vCore 购买模型 - Azure SQL 数据库

适用于：Azure SQL 数据库

本文介绍了适用于 Azure SQL 数据库的 vCore 购买模型。

概述

虚拟核心 (vCore) 表示一个逻辑 CPU，使用它可以选择硬件的物理特性（例如核心数、内存和存储大小）。 基于 vCore 的购买模型提供使用单项资源的灵活性、控制度和透明度，并提供简单明了的方法将本地工作负荷要求转换到云。 此模型优化了价格，允许根据工作负荷需求来选择计算、内存和存储资源。

在基于 vCore 的购买模型中，成本取决于以下各项的选择情况和使用量：

• 服务层级
• 硬件配置
• 计算资源（vCore 数量和内存量）
• 保留的数据库存储
• 实际备份存储

比较 vCore 和 DTU 购买模型

Azure SQL 数据库使用的 vCore 购买模型相比于基于 DTU 的购买模型而言具备一些优势：

• 更高的计算、内存、I/O 和存储限制。
• 正确选择硬件配置，以更好地匹配工作负载的计算和内存要求。
• Azure 混合权益 (AHB) 的定价折扣。
• 为驱动计算的硬件细节提供更高的透明度，这有助于规划从本地部署进行的迁移。
• 缩放粒度更高，有多个可用的计算大小。

有关如何在 vCore 和 DTU 购买模型之间进行选择的帮助，请参阅 vCore 和基于 DTU 的购买模型之间的差异

计算

基于 vCore 的购买模型具有预配的计算层级和无服务器计算层级。 在预配的计算层级中，计算成本反映为应用程序持续预配的总计算容量，而与工作负荷活动无关。 根据 vCore 和内存要求选择最适合业务需求的资源分配，然后根据工作负荷的需要纵向缩放资源。 在 Azure SQL 数据库的无服务器计算层级中，计算资源根据工作负载容量自动缩放，按每秒使用的计算量计费。

总结：

• 虽然预配计算层级提供特定数量的计算资源，这些资源是独立于工作负载活动持续进行的预配，但无服务器计算层级会根据工作负载活动自动缩放计算资源。
• 预配计算层级按每小时固定价格对预配的计算量收费，而无服务器计算层级则按每秒使用的计算量收费。

无论使用哪种计算层级，都会在“业务关键”服务层级中自动分配三个额外的高可用性次要副本，以提供较高的故障复原原能力和快速故障转移。 这些其他副本使得成本比在“常规用途”服务层级中高出大约 2.7 倍。 同理，“业务关键”服务层级的每 GB 存储成本更高，对应的是本地 SSD 存储的 IO 限制更高，延迟更低。

在超大规模中，客户将额外的高可用性副本的数量控制在 0 到 4 之间，以获得应用程序所需的复原能力级别，同时控制成本。

有关 Azure SQL 数据库中计算的详细信息，请参阅计算资源（CPU 和内存）。

资源限制

• 逻辑服务器
• 单一数据库
• 弹性池中的 SQL 数据库

数据和日志存储

以下因素会影响用于数据和日志文件的存储量，并适用于“常规用途”和“业务关键”层级。

• 每个计算大小支持一个可配置的最大数据大小（默认值为 32 GB）。
• 配置最大数据大小时，将自动为日志文件额外添加 30% 的可计费存储。
• 在“常规用途”服务层级中，tempdb 使用本地 SSD 存储，此存储成本包含在 vCore 价格中。
• 在“业务关键”服务层级中，tempdb 与数据和日志文件共享本地 SSD 存储，tempdb 存储成本包含在 vCore 价格中。
• 在“常规用途”和“业务关键”层级中，你将按照为数据库或弹性池配置的最大存储大小付费。
• 对于 SQL 数据库，可以选择介于 1 GB 与受支持最大存储大小之间的任意最大数据大小，以 1 GB 为增量。

以下存储注意事项适用于超大规模：

• 最大数据存储大小设置为 128 TB，且不可配置。
• 只需为分配的数据存储而不是最大数据存储付费。
• 无需为日志存储付费。
• tempdb 使用本地 SSD 存储，其成本包含在 vCore 价格中。 若要监视 SQL 数据库中的当前已分配和已用数据存储大小，请分别使用 allocated_data_storage 和 storage Azure Monitor 指标。

若要使用 T-SQL 监视数据库中单个数据文件和日志文件的当前已分配和已用存储大小，请使用 sys.database_files 视图和 FILEPROPERTY(... , 'SpaceUsed') 函数。

备份存储

为数据库备份分配存储，以支持 SQL 数据库的时间点还原 (PITR) 和长期保留 (LTR) 功能。 此存储独立于数据和日志文件存储，并单独计费。

• PITR：在“常规用途”和“业务关键”层级中，各个数据库备份将自动复制到 Azure 存储。 创建新备份时，存储大小动态递增。 存储将由完整备份、差异备份和事务日志备份使用。 存储消耗量取决于数据库变化率以及为备份配置的保留期。 对于 SQL 数据库，可为每个数据库单独配置 1 到 35 天的保留期。 提供与配置的最大数据大小相等的备份存储量，不收取额外费用。
• LTR：你也可以将完整备份的长期保留配置为长达 10 年。 如果设置了 LTR 策略，则这些备份将自动存储在 Azure Blob 存储中，但你可以控制备份的复制频率。 为了满足不同的符合性要求，可为每周、每月和/或每年备份选择不同的保留期。 所选配置决定了多少存储用于 LTR 备份。 有关详细信息，请参阅长期备份保留。

有关超大规模中的备份存储，请参阅超大规模数据库的自动备份。

服务层

vCore 购买模型中的服务层级选项包括“常规用途”、“业务关键”和“超大规模”。 服务层级通常确定存储类型和性能、高可用性和灾难恢复选项，以及某些功能（例如内存中 OLTP）的可用性。

用例	常规用途	业务关键	超大规模
最适用于	大多数业务工作负荷。 提供预算导向的、均衡且可缩放的计算和存储选项。	使用多个高可用性次要副本为商业应用程序提供最高级别的故障复原能力，并提供最高的 I/O 性能。	最广泛的工作负载，包括具有高度可缩放存储和读取缩放要求的工作负载。 通过允许配置多个高可用性次要副本来提供更高的故障复原能力。
计算大小	2 到 80 个 vCore	2 到 80 个 vCore	2 到 80 个 vCore
存储类型	高级远程存储（每个实例）	超快的本地 SSD 存储（每个实例）	具有本地 SSD 缓存的分离的存储（每个计算副本）
存储大小	1 GB - 4 TB	1 GB - 4 TB	10 GB - 128 TB
IOPS	最大 12,800 IOPS	最大 204,800 IOPS	204,800 IOPS（具有最大本地 SSD） 超大规模是具有多个级别缓存的多层体系结构。 有效 IOPS 将取决于工作负载。
内存/vCore	5.1 GB	5.1 GB	5.1 GB
备份	选择异地冗余、区域冗余或本地冗余备份存储，1-35 天保留期（默认为 7 天） 长期保留期最长为 10 年	选择异地冗余、区域冗余或本地冗余备份存储，1-35 天保留期（默认为 7 天） 长期保留期最长为 10 年	可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储 1-35 天（默认值为 7 天）的保留期，最长的长期保留期为 10 年
可用性	1 个副本，无读取扩展副本， 区域冗余高可用性 (HA)	三个副本，一个读取缩放副本， 区域冗余高可用性 (HA)	区域冗余高可用性 (HA)
定价/计费	vCore、保留存储和备份存储收费。 IOPS 不收费。	vCore、保留存储和备份存储收费。 IOPS 不收费。	每个副本的 vCore 和已用存储收费。 IOPS 不收费。
折扣模型	Azure 混合权益（在开发/测试订阅中不可用） 企业和即用即付开发/测试产品/服务订阅	Azure 混合权益（在开发/测试订阅中不可用） 企业和即用即付开发/测试产品/服务订阅	Azure 混合权益（在开发/测试订阅中不可用）1 企业和即用即付开发/测试产品/服务订阅
内存中 OLTP 表	否	是	否

¹ SQL 数据库超大规模即将推出简化定价。 有关详情，请查看超大规模定价博客。

如需进一步的详细信息，请查看逻辑服务器、单一数据库和共用数据库的资源限制。

常规用途

“常规用途”服务层级的体系结构模型基于计算和存储的分离。 此体系结构模型依赖于 Azure Blob 存储的高可用性和可靠性，旨在以透明方式复制数据库文件，并确保在发生底层基础结构故障时不会丢失数据。

下图显示了计算层和存储层已隔离的标准体系结构模型中的四个节点。

“常规用途”服务层级的体系结构模型中有两个层：

• 无状态计算层，该层运行 sqlservr.exe 进程，仅包含暂时性的缓存数据（例如 - 计划缓存、缓冲池和列存储池）。 此无状态节点由 Azure Service Fabric 操作。Service Fabric 初始化进程、控制节点运行状况，并根据需要执行到另一位置的故障转移。
• 有状态数据层：包含存储在 Azure Blob 存储中的数据库文件 (.mdf/.ldf)。 Azure Blob 存储保证任何数据库文件中的任何记录都不会发生数据丢失。 Azure 存储具有内置的数据可用性/冗余，确保即使进程崩溃，也能保留日志文件中的每条记录或者数据文件中的每个页面。

每当升级数据库引擎或操作系统、底层基础结构的某个部件发生故障，或者在 sqlservr.exe 进程中检测到某个严重问题时，Azure Service Fabric 都会将无状态进程移到另一个无状态计算节点。 发生主节点故障转移时，将有一组备用节点等待运行新的计算服务，以尽量减少故障转移时间。 Azure 存储层中的数据不受影响，数据/日志文件将附加到新初始化的进程。 默认情况下，此进程保证 99.99% 的可用性，在启用区域冗余的情况下保证 99.995% 的可用性。 可能会对正在运行的重型工作负载造成一定的性能影响，原因是转换时间较长，并且新节点从冷缓存启动。

何时选择此服务层级

“常规用途”服务层级是 Azure SQL 数据库中的默认服务层级，专为大多数常规工作负载而设计。 如果需要一个具有默认 SLA 且存储延迟在 5 到 10 毫秒之间的完全托管数据库引擎，则可选择“常规用途”层级。

业务关键

“业务关键”服务层级模型基于数据库引擎进程群集。 此体系结构模型依赖于存在数据库引擎节点的仲裁，以最大限度地减少对工作负载性能的影响，即使在执行维护活动期间也是如此。 以透明方式升级和修补底层操作系统、驱动程序和数据库引擎，尽量减少最终用户的停机时间。

在“业务关键”模型中，计算和存储在每个节点上集成。 通过在一个四节点群集的每个节点上的数据库引擎进程之间复制数据可实现高可用性，其中每个节点都使用本地附加的 SSD 作为数据存储。 下图显示了业务关键服务层级如何在可用性组副本中组织数据库引擎节点群集。

数据库引擎进程和基础 .mdf/.ldf 文件都放置在同一个节点上，该节点在本地附加了 SSD 存储，使工作负载保持较低的延迟。 高可用性是使用类似于 SQL Server Always On 可用性组的技术来实现的。 每个数据库都是由数据库节点组成的群集，其中包含一个可供客户工作负载访问的主要副本和三个包含数据副本的次要副本。 主要副本不断地将更改推送到次要副本，以确保在主要副本出于任何原因失败时，可在次要副本上提供数据。 故障转移由 Service Fabric 和数据库引擎处理 - 一个次要副本成为主要副本，并创建新的次要副本来确保群集中有足够的节点。 工作负载自动重定向到新的主要副本。

此外，业务关键群集具有内置的读取扩展功能，该功能提供免费的只读副本，用于运行不会影响主要副本上的工作负载性能的只读查询（例如报告）。

何时选择此服务层级

“业务关键”服务层级专为具有以下特点的应用程序而设计：需要来自基础 SSD 存储的低延迟响应（平均 1-2 毫秒）、在底层基础结构发生故障时需要更快速的恢复或需要将报告、分析和只读查询分流到主数据库的免费可读次要副本。

选择“业务关键”服务层级而不是“常规用途”层级的主要原因包括：

• 低 I/O 延迟要求 - 需要存储层一致地快速做出响应（平均 1-2 毫秒）的工作负荷应使用“业务关键”层级。
• 包含报告和分析查询的工作负载，其中只需要有一个免费的辅助只读副本就足够了。
• 提高复原能力，并在故障后更快地恢复。 发生系统故障时，主实例上的数据库将被禁用，某个次要副本将立即成为新的读写主数据库，该数据库随时可以处理查询。
• 高级数据损坏防护。 由于“业务关键”层级在后台使用数据库副本，因此该服务使用镜像和可用性组提供的自动页修复来帮助缓解数据损坏。 如果副本由于数据完整性问题而无法读取某个页面，则会从另一个副本检索该页面的全新副本，并替换不可读的页面，而不会造成数据丢失或客户停机。 如果数据库具有异地次要副本，则此功能在“常规用途”层级中可用。
• 更高的可用性 - 采用多可用性区域配置的“业务关键”层级提供区域故障复原能力和更高的可用性 SLA。
• 快速异地恢复 - 在配置了活动异地复制时，针对 100% 的已部署小时，业务关键层级会有一个有保证的 5 秒的恢复点目标 (RPO) 和 30 秒的恢复时间目标 (RTO)。

超大规模

“超大规模”服务层级适用于所有工作负载类型。 该服务层级的云原生体系结构提供独立、可缩放的计算和存储，以支持最广泛的传统和现代应用程序。 超大规模中的计算和存储资源远远超过了“常规用途”和“业务关键”层级中可用的资源。

若要了解详细信息，请查看 Azure SQL 数据库的“超大规模”服务层级。

何时选择此服务层级

“超大规模”服务层级消除了传统上云数据库中出现的许多实际限制。 当大多数其他数据库受单个节点中可用资源的限制时，“超大规模”服务层级中的数据库则没有此类限制。 通过“超大规模”数据库的灵活存储体系结构，该数据库会按需扩大，你仅需为所使用的存储容量付费。

除了其高级缩放功能外，超大规模对于任何工作负载（而不仅仅是大型数据库）也是一个不错的选择。 借助超大规模，可以：

• 通过选择数量在 0 到 4 之间的高可用性副本，实现高复原能力和快速故障恢复，同时控制成本。
• 通过为计算和存储启用区域冗余来改进高可用性。
• 对于数据库的频繁访问部分，实现低 I/O 延迟（平均 1-2 毫秒）。 对于较小的数据库，这可能适用于整个数据库。
• 使用命名副本实现各种读取扩展方案。
• 利用快速缩放，无需等待数据复制到新节点上的本地存储。
• 使用“零影响连续数据库备份”和“快速还原”。
• 使用故障转移组和异地复制来支持业务连续性要求。

计算资源（CPU 和内存）

下表比较了不同硬件配置和计算层中的计算资源：

硬件配置	CPU	内存
标准系列 (Gen5)	预配计算 - Intel® E5-2673 v4 (Broadwell) 2.3 GHz、Intel® SP-8160 (Skylake)*、Intel® 8272CL (Cascade Lake) 2.5 GHz*、Intel® Xeon® Platinum 8370C (Ice Lake)* 和 AMD EPYC 7763v (Milan) 处理器 - 预配最多 80 个 vCore（超线程） 无服务器计算 - Intel® E5-2673 v4 (Broadwell) 2.3 GHz、Intel® SP-8160 (Skylake)*、Intel® 8272CL (Cascade Lake) 2.5 GHz*、Intel® Xeon® Platinum 8370C (Ice Lake)* 和 AMD EPYC 7763v (Milan) 处理器 - 自动纵向扩展到 40 个 vCore（超线程） - 内存与 vCore 比率根据工作负载需求动态适应内存和 CPU 使用率，每个 vCore 可能高达 24 GB。	预配计算 - 每个 vCore 5.1 GB - 最多预配 415 GB 无服务器计算 - 自动缩放为每个 vCore 24 GB - 自动纵向扩展为最大 120 GB

* 在 sys.dm_user_db_resource_governance 动态管理视图中，使用 Intel® SP-8160 (Skylake) 处理器的数据库的硬件代系会显示为 Gen6，使用 Intel® 8272CL (Cascade Lake) 的数据库的硬件代系会显示为 Gen7，使用 Intel® Xeon® Platinum 8370C (Ice Lake) 或 AMD® EPYC® 7763v (Milan) 的数据库的硬件代系会显示为 Gen8。 对于给定的计算大小和硬件配置，无论 CPU 类型是什么（Intel Broadwell、Skylake、Ice Lake、Cascade Lake 或 AMD Milan），资源限制都是相同的。

有关详细信息，请参阅单一数据库和弹性池的资源限制。

有关超大规模数据库计算资源和规范，请参阅超大规模计算资源。

标准系列 (Gen5)

• 标准系列 (Gen5) 硬件提供了均衡的计算和内存资源，适用于大多数数据库工作负载。

标准系列（第 5 代）硬件在所有区域都可用。

选择硬件配置

可以在创建时为 SQL 数据库中的数据库或弹性池选择硬件配置。 还可以更改现有数据库或弹性池的硬件配置。

在创建 SQL 数据库或池时选择硬件配置

有关详细信息，请参阅创建 SQL 数据库。

在“基本信息”选项卡上，选择“计算 + 存储”部分中的“配置数据库”链接，然后选择“更改配置”链接：

选择所需的硬件配置：

更改现有 SQL 数据库或池的硬件配置

对于数据库，请在“概述”页上选择“定价层”链接：

对于池，请在“概述”页上选择“配置”。

遵循相应的步骤更改配置，然后根据前面的步骤所述选择硬件配置。

硬件可用性

有关上一代硬件的信息，请参阅上一代硬件可用性。

标准系列 (Gen5)

Gen5 硬件在所有区域都可用。

上一代硬件

Gen4

Gen4 硬件已停用，不可用于预配、纵向扩展或缩减。 将数据库迁移到受支持的硬件代系，实现更广泛的 vCore 和存储可伸缩性、加速网络、最佳 IO 性能和最小延迟。 查看单一数据库的硬件选项和弹性池的硬件选项。 有关详细信息，请参阅 Azure SQL 数据库上对第 4 代硬件的支持已结束。

下一步

相关内容

• Azure SQL 数据库定价页
• 使用 vCore 购买模型的单一数据库的资源限制
• 使用 vCore 购买模型的弹性池的资源限制