“超大规模”服务层级

适用于：Azure SQL 数据库

Azure SQL 数据库超大规模是一个经济高效的高性能云数据库。

Azure SQL 数据库基于 SQL 数据库引擎。 超大规模与其他Azure SQL 数据库服务层级不同：

  • 与其他服务层级不同，Hyperscale 无需支付 SQL 软件许可费用，因此对于高性能数据库，它相比 Azure SQL 数据库 的其他服务层级具有显著的价格优势。
  • 超大规模体系结构 是不同的：它为读取和写入提供几乎即时的备份、快速还原和高吞吐量。
  • 超大规模架构可按需快速扩展计算资源，无需迁移数据。
  • 读取扩展策略非常简单，支持多达 30 个命名副本，并且每个副本的计算资源都可独立配置；此外，还提供内置的高可用性副本，以及可在全球范围内配置的异地副本。

“超大规模”服务层级适用于所有工作负载类型。 “超大规模”中的计算和存储资源大大超出了Azure SQL 数据库“常规用途”和“业务关键”层中可用的资源。

可以轻松地将 Azure SQL 数据库 中的现有数据库转换到超大规模，或者从任何 SQL Server 数据库迁移到超大规模。 若要将其他数据库迁移到 Azure SQL 数据库，请参阅 Azure 数据库迁移指南。

“超大规模”服务层级目前仅可用于 Azure SQL 数据库，不可用于 Azure SQL 托管实例。

超大规模的功能有哪些

Azure SQL 数据库中的“超大规模”服务层级提供了以下附加功能：

  • 快速扩展 — 在需要时扩展计算资源以应对繁重负载，在不需要时再缩减计算资源。
  • 快速横向扩展 - 预配一个或多个 只读副本，以分担读取工作负载，并将其用作热备用副本。
  • 使用无服务器计算时，将根据使用情况自动对计算进行纵向扩展、缩减和计费。
  • 使用弹性池优化了一组具有不同资源需求的超大规模数据库的价格/性能。
  • 自动缩放存储，支持高达 128 TB 的数据库大小或 100 TB 的弹性池大小。
  • 由于事务日志吞吐量更高且事务提交速度更快，整体性能得到了提升，无论数据量大小。
  • 快速数据库备份（基于文件快照），无论大小如何，都不会对计算资源产生 I/O 影响。
  • 在几分钟内快速完成数据库还原或复制（基于文件快照），而不是需要花费数小时或数天。

“超大规模”服务层级消除了传统上云数据库中出现的许多实际限制。 当大多数其他数据库受单个节点中可用资源的限制时，“超大规模”服务层级中的数据库则没有此类限制。 它具备灵活的存储体系结构，存储可按需增长。 实际上，超大规模数据库没有预先设置的最大容量。 “超大规模”数据库会按需扩大，你仅需为所分配的存储容量付费。 对于读取密集型工作负载，“超大规模”服务层级通过按需预配其他副本来减轻读取工作负载，从而实现快速横向扩展。

此外，创建数据库备份或纵向扩展/横向扩展所需的时间不再与数据库中的数据卷相关。 几乎可以即时备份“超大规模”数据库。 还可以在几分钟内将预配的计算层中的数据库扩展或缩减至数十TB，或使用无服务器自动调整计算能力。 此功能使你无需担心受初始配置选项的约束。

有关“超大规模”服务层级计算大小的详细信息，请参阅服务层级特征。

有关基于 vCore 的购买模型中的“常规用途”服务层级和“业务关键”服务层级的详细信息，请参阅常规用途服务层级和业务关键服务层级。 有关基于 vCore 的购买模型与基于 DTU 的购买模型的比较，请参阅比较基于 vCore 和基于 DTU 的 Azure SQL 数据库购买模型。

哪些群体应考虑使用“超大规模”服务层级

超大规模服务层级适用于需要更高性能和可用性、快速备份和还原以及快速存储和计算可伸缩性的所有客户。 超大规模非常适合迁移到云以现代化其应用程序的客户，或者对于已在Azure SQL 数据库中使用其他服务层级的客户。 超大规模服务层级支持广泛的数据库工作负载（从纯 OLTP 到纯分析）。 它针对 OLTP 和混合事务与分析处理 (HTAP) 工作负载进行了优化。

“超大规模”定价模型

对于高性能数据库，“超大规模”为其他Azure SQL 数据库服务层级提供了显著的价格优势。

超大规模服务层级仅在 vCore 模型中 可用，并且有两个计算层。 超大规模计费基于预配的或无服务器计算层：

配置超大规模数据库时，不会指定最大数据大小。 在“超大规模”层中，根据实际分配为存储付费。 存储会自动分配 10 GB 到 128 TB，并根据需要增长。 有关详细信息，请参阅数据库大小增长的增量是多少？

规模和性能优势

超大规模将主数据库引擎与为数据提供长期存储和持久性的组件分开。 此体系结构允许你快速缩放计算资源，而无需移动数据，以及独立于计算缩放存储（高达 128 TB）。 有关更多详细信息，包括体系结构关系图，请参阅 “超大规模”体系结构。

  • 借助快速增减额外只读计算节点的能力，Hyperscale 架构能够实现显著的读扩展能力，还可以让主计算节点处理更多请求。
  • 可以为辅助节点预配计算，也可以使用 无服务器计算。 无论哪种情况，都可以由于超大规模共享存储体系结构而快速纵向扩展或缩减它们。
    • Hyperscale 中的辅助高可用计算节点副本遵循主节点的计算层级，从而实现低影响的故障转移。
  • 使用无服务器计算节点时，主计算节点或辅助计算节点会根据工作负荷需求自动缩放。

主Azure SQL 数据库超大规模数据库同时处理读取和写入工作负荷，但作为应用程序策略的一部分，可以轻松创建只读副本：

  • 可以根据可用性和可伸缩性要求，将 高可用性次要副本 总数从 0 调整为 4。
  • 最多可以创建 30 个命名副本，以支持读取横向扩展工作负载。
  • 可以通过使用 异地副本，在 Azure 全球数据中心之间实现读取横向扩展。

“超大规模”中的数据库高可用性

与所有其他服务层级一样，“超大规模”保证已提交事务的数据持久性，而不管计算副本的可用性如何。 由于主要副本不可用而导致的停机时间取决于故障转移的类型（计划内或计划外），是否配置区域冗余，以及是否至少存在一个高可用性副本。 在计划的故障转移（如维护事件）中，系统在启动故障转移之前创建新的主副本，或使用现有的高可用性副本作为故障转移目标。 在计划外故障转移（如主要副本发生硬件故障）中，系统使用高可用性副本作为故障转移目标（如果存在），或者从可用计算容量池中创建新的主要副本。 对于后一种情况，停机持续时间更长，因为需要执行额外的步骤来创建新的主要副本。

可以选择 一个维护时段 ，使有影响力的维护事件可预测且对工作负荷造成的影响较小。

有关“超大规模”SLA，请参阅 Azure SQL 数据库的 SLA。

缓冲池和弹性缓冲池扩展

在Azure“数据库超大规模”中，计算和存储之间存在不同的分离。 存储包含一个数据库中的所有数据库页，并且随着数据库的增长，可以分配在多台计算机上。 但是，计算节点仅缓存最近使用的内容。 计算中的最热门页面会以一种称为缓冲池 (BP) 的结构存储在内存中。 它还存储在本地 SSD（即弹性缓冲池扩展 (RBPEX)）中，这样，如果计算进程重新启动，便可以更快地检索数据。

在云系统中，计算可以根据需要移动到不同的计算机。 计算层可以有多个副本。 一个副本是主要副本，接收所有更新，而另一个副本是次要副本。 如果主副本失败，系统会在称为故障转移的进程中将其中一个高可用性次要副本提升为主副本。 次要副本在其 BP 和 RBPEX 中可能没有针对主工作负载进行优化的缓存。

连续启动

持续预热是一个用于收集所有计算副本中访问频率最高（最热）的页面信息的过程。 该过程聚合此信息，高可用性次要副本使用与典型客户工作负荷对应的最热页面列表。 此过程持续将最热页面填充到 BP 和 RBPEX 中，以适应客户工作负载的变化。

如果没有连续启动，BP 和 RBPEX 不会由新的高可用性副本继承，而只会在用户工作负载期间重新构造。 连续启动可以节省时间并避免性能不一致，因为无需等待缓存再次完全冻结。 通过连续启动，新的高可用性次要副本将立即开始启动其 BP 和 RBPEX。 这将有助于在发生故障转移时使性能保持更加一致。

连续启动是双向的：高可用性次要副本将缓存主要副本中正在使用的页面，而主要副本将缓存来自次要副本工作负荷的页面。

超大规模配置计算层目前提供连续启动。

备份和还原

超大规模数据库的备份和还原操作是基于文件快照的。 此方法使这些操作几乎瞬间完成。 由于超大规模体系结构使用存储层进行备份和还原，因此减少了对计算副本的处理负担和性能影响。 有关详细信息，请参阅 “超大规模备份和存储冗余”。

超大规模数据库的灾难恢复

若要将Azure SQL 数据库中的“超大规模”数据库还原到当前托管的数据库以外的区域，请执行 geo-restore。 此方法适用于灾难恢复操作、演练、重定位或任何其他原因。 仅当选择异地冗余存储（RA-GRS）进行存储冗余时，异地还原才可用。

有关详细信息，请参阅 将超大规模数据库还原到其他区域。

比较资源限制

基于 vCore 的服务层在数据库可用性、存储类型、性能和最大存储大小方面有所不同。 下表描述了这些差异：

常规用途 业务关键 超大规模
最适用于 面向预算的均衡计算和存储选项。 事务率高、I/O 延迟低的 OLTP 应用程序。 通过使用多个热备用副本，实现高故障弹性和快速故障转移。 各种各样的工作负载。 自动缩放存储大小高达 128 TB、快速垂直和水平计算缩放、快速数据库备份和还原。
计算大小 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 或 10.2 GB
可用性 1 个副本，无读取扩展，区域冗余 HA 3 个副本，1 个读取扩展，区域冗余 HA 多个副本，多达 4 个读取扩展，区域冗余 HA
备份 可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储
1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年		 可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储
1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年		 可以选择本地冗余 (LRS)、区域冗余 (ZRS) 或异地冗余 (GRS) 存储
1-35 天（默认值为七天）的保留期，最长的长期保留期为 10 年
定价/计费 vCore、保留存储和备份存储收费。
IOPS 不收费。		 vCore、保留存储和备份存储收费。
IOPS 不收费。		 收取每个副本 的 vCore、分配的数据存储和备份存储的费用。
IOPS 不收费。
折扣模型1 Azure 混合权益2
企业和按需付费开发/测试订阅		 Azure 混合权益2
企业和按需付费开发/测试订阅		 Azure 混合权益2
企业和按需付费开发/测试订阅

1 从 2023 年 12 月开始，超大规模 SQL 数据库已可享受更简化的定价。 有关详情，请查看超大规模定价博客。

2 从 2023 年 12 月开始，Azure 混合权益将不适用于新的超大规模数据库或开发/测试订阅。 在 2026 年 12 月之前，具有预配计算的现有超大规模单一数据库可以继续使用Azure 混合权益，以节省计算成本。 有关详细信息，请查看超大规模定价博客。

计算资源

下表比较了 Azure SQL 数据库超大规模不同硬件配置和计算层中的计算资源。 有关非超大规模 Azure SQL 数据库，请参阅 vCore 购买模型 - Azure SQL 数据库。

硬件配置 CPU 内存
标准系列（第五代） 预配计算
- 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（米兰）*、AMD EPYC 9004（基因a）*、Intel® Xeon® Platinum 8573C（绿绿急流）* 处理器
- 配置最多 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（米兰）*、AMD EPYC 9004（基因a）*、Intel® Xeon® Platinum 8573C（绿绿急流）* 处理器
- 自动缩放到多达 80 个 vCore（超线程）
- 内存与 vCore 比率根据工作负载需求动态适应内存和 CPU 使用率，每个 vCore 可能高达 24 GB。 例如，在给定的时间点，工作负载可能使用 240 GB 内存以及仅 10 个 vCore，并依此进行计费。		 预配计算
- 每个 vCore 5.1 GB
- 最多预配 415 GB

无服务器计算
- 自动扩展为每个 vCore 24 GB
最大可自动扩展至 240 GB
高级系列 预配计算
- Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（Milan）*、AMD EPYC 9004（Genoa）*、Intel® Xeon® Platinum 8573C（Emerald Rapids）* 处理器
- 预配最多 80 个 vCore（超线程）。		 每个 vCore 5.2 GB
高级系列内存优化 预配计算
- Intel® Xeon® Platinum 8370C（Ice Lake）*、AMD EPYC™ 7763v（Milan）*、AMD EPYC 9004（Genoa）*、Intel® Xeon® Platinum 8573C（Emerald Rapids）* 处理器
- 预配最多 40 个 vCore（超线程）。		 每个 vCore 10.2 GB

* 对于给定的计算大小和硬件配置，无论 CPU 类型（Intel® Broadwell、Skylake、Ice Lake、Cascade Lake、Green Rapid 或 AMD 米兰、吉诺亚），资源限制都是相同的。 在 sys.dm_user_db_resource_governance 动态管理视图中，使用数据库的硬件代。

  • Intel® SP-8160（Skylake）处理器被显示为 Gen6
  • Intel® 8272CL （Cascade Lake）显示为第七代
  • Intel® Xeon® Platinum 8370C （Ice Lake） 或 AMD EPYC™ 7763v （米兰） 显示为 Gen8
  • AMD EPYC™ 9004（Genoa）显示为 Gen9 或 Intel® Xeon® Platinum 8573C（Emerald Rapids）显示为 Gen10

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

创建和管理超大规模数据库

可以使用Azure门户、Transact-SQL、PowerShell 和Azure CLI来创建和管理超大规模数据库。 有关详细信息，请参阅快速入门：创建超大规模数据库。

操作 详细信息 了解详细信息
创建“超大规模”数据库 超大规模数据库仅可通过基于 vCore 的购买模型使用。 在快速入门：在 Azure SQL 数据库中创建超大规模数据库中查找用于创建超大规模数据库的示例。
将现有数据库转换为“超大规模” 可以将现有数据库转换为 Azure SQL 数据库超大规模层。 转换持续时间取决于数据的大小。 有关详细信息，请参阅将现有数据库转换为超大规模。
将超大规模数据库反向迁移到“常规用途”服务层级 如果以前将现有 Azure SQL 数据库迁移到“超大规模”，可以在原始迁移到“超大规模”后的 45 天内将数据库反向迁移到“常规用途”服务层级。

如果要将数据库迁移到另一个服务层（例如业务关键），请先反向迁移到常规用途服务层级，然后更改服务层。		 了解如何从超大规模反向迁移，包括反向迁移的限制。

局限性

这些限制目前适用于“超大规模”服务层级。 产品团队正积极努力消除尽可能多的这些限制。

问题 说明
当 TDE 被禁用时，收缩被阻止 目前，禁用透明数据加密（TDE）时，Azure SQL 数据库“超大规模”不支持数据库和文件收缩操作。
从其他服务层级还原数据库 无法将非超大规模数据库还原为“超大规模”数据库。 也不能将超大规模数据库还原为非超大规模数据库。

对于从其他Azure SQL 数据库服务层级迁移到“超大规模”的数据库，预迁移备份将保留到源数据库的 备份保留期期间，包括长期保留策略。 可以通过 命令行在数据库的备份保留期内还原迁移前备份。 可以将这些备份还原到任何非超大规模服务层级。
迁移包含内存中 OLTP 对象的数据库 超大规模支持内存中 OLTP 对象的子集，包括内存优化表类型、表变量和本机编译模块。 但是，如果要迁移的数据库中存在任何内存中 OLTP 对象，则不支持从“高级”和“业务关键”服务层级迁移到“超大规模”。 若要将此类数据库迁移到“超大规模”，必须删除所有 In-Memory OLTP 对象及其依赖项。 迁移数据库后，可以重新创建这些对象。 超大规模目前不支持持久的和非持久的内存优化表，必须将这些表更改为为磁盘表。
数据库完整性检查 “超大规模”数据库目前不支持 DBCC CHECKDB。 解决方法是使用 DBCC CHECKTABLE ('TableName') WITH TABLOCK 和 DBCC CHECKFILEGROUP WITH TABLOCK。 有关 Azure SQL 数据库 中数据完整性管理的详细信息，请参阅 Azure SQL 数据库 中的数据完整性。
弹性作业 不支持使用超大规模数据库作为作业数据库。 但是，弹性作业可将超大规模数据库用作目标，就如同将 Azure SQL 数据库中的任何其他数据库用作目标一样。
数据同步 不支持将超大规模数据库用作中心或同步元数据数据库。 但是，超大规模数据库可以是数据同步拓扑中的成员数据库。
超大规模服务层级高级系列硬件 高级系列和内存优化的高级系列硬件当前不支持无服务器计算层。 无服务器仅在标准系列 (Gen5) 硬件上受支持。

相关内容

  • Last updated on