Azure SQL 数据库“超大规模”常见问题解答Azure SQL Database Hyperscale FAQ

本文就客户对 Azure SQL 数据库“超大规模”服务层级中的数据库(在本常见问题解答的剩余部分简称为“超大规模”)提出的常见问题做出回答。This article provides answers to frequently asked questions for customers considering a database in the Azure SQL Database Hyperscale service tier, referred to as just Hyperscale in the remainder of this FAQ. 本文介绍“超大规模”支持的方案,以及与“超大规模”兼容的功能。This article describes the scenarios that Hyperscale supports and the features that are compatible with Hyperscale.

  • 本常见问题解答适用于对“超大规模”服务层级有基本了解并希望其具体问题得到解答的读者。This FAQ is intended for readers who have a brief understanding of the Hyperscale service tier and are looking to have their specific questions and concerns answered.
  • 本常见问题解答不是指南,不解答关于如何使用“超大规模”数据库的问题。This FAQ isn’t meant to be a guidebook or answer questions on how to use a Hyperscale database. 有关“超大规模”的简介,建议参考 Azure SQL 数据库“超大规模”文档。For an introduction to Hyperscale, we recommend you refer to the Azure SQL Database Hyperscale documentation.

一般问题General Questions

什么是“超大规模”数据库What is a Hyperscale database

超大规模数据库是“超大规模”服务层级中的 Azure SQL 数据库,由超大规模横向扩展存储技术提供支持。A Hyperscale database is an Azure SQL database in the Hyperscale service tier that is backed by the Hyperscale scale-out storage technology. 一个“超大规模”数据库支持最多 100 TB 的数据,提供高吞吐量和高性能,可以快速缩放以适应工作负荷要求。A Hyperscale database supports up to 100 TB of data and provides high throughput and performance, as well as rapid scaling to adapt to the workload requirements. 缩放对应用程序透明 - 连接、查询处理等等,都与其他任何 Azure SQL 数据库一样工作。Scaling is transparent to the application - connectivity, query processing, etc. work like any other Azure SQL database.

哪些资源类型和购买模型支持“超大规模”What resource types and purchasing models support Hyperscale

“超大规模”服务层级仅适用于在 Azure SQL 数据库中使用基于 vCore 的购买模型的单一数据库。The Hyperscale service tier is only available for single databases using the vCore-based purchasing model in Azure SQL Database.

“超大规模”服务层级与“常规用途”和“业务关键”服务层级有何区别How does the Hyperscale service tier differ from the General Purpose and Business Critical service tiers

根据下表中所述的数据库可用性、存储类型性能和最大大小区分基于 vCore 的服务层级。The vCore-based service tiers are differentiated based on database availability and storage type, performance, and maximum size, as described in the following table.

资源类型Resource type 常规用途General Purpose 超大规模Hyperscale 业务关键Business Critical
最适用于Best for 全部All 提供以预算导向的、均衡的计算和存储选项。Offers budget oriented balanced compute and storage options. 大多数业务工作负荷。Most business workloads. 自动缩放存储大小,最大可达 100 TB,快速的垂直和水平计算缩放,快速数据库还原。Autoscaling storage size up to 100 TB, fast vertical and horizontal compute scaling, fast database restore. 事务率较高、IO 延迟较低的 OLTP 应用程序。OLTP applications with high transaction rate and low IO latency. 使用多个同步更新的副本提供最高故障复原能力和快速故障转移。Offers highest resilience to failures and fast failovers using multiple synchronously updated replicas.
资源类型Resource type 单一数据库/弹性池/托管实例Single database / elastic pool / managed instance 单一数据库Single database 单一数据库/弹性池/托管实例Single database / elastic pool / managed instance
计算大小Compute size 单一数据库/弹性池*Single database / elastic pool * 1 - 80 个 vCore1 to 80 vCores 1 - 80 个 vCore*1 to 80 vCores* 1 - 80 个 vCore1 to 80 vCores
托管实例Managed instance 8、16、24、32、40、64、80 个 vCore8, 16, 24, 32, 40, 64, 80 vCores 不适用N/A 8、16、24 个 vCore8, 16, 24 vCores
存储类型Storage type 全部All 高级远程存储(每个实例)Premium remote storage (per instance) 具有本地 SSD 缓存的分离的存储(每个实例)De-coupled storage with local SSD cache (per instance) 超快的本地 SSD 存储(每个实例)Super-fast local SSD storage (per instance)
存储大小Storage size 单一数据库/弹性池*Single database / elastic pool * 5 GB - 4 TB5 GB - 4 TB 最多 100 TBUp to 100 TB 5 GB - 4 TB5 GB - 4 TB
托管实例Managed instance 32 GB - 8 TB32 GB - 8 TB 不适用N/A 32 GB - 2 TB32 GB - 2 TB
IOPSIOPS 单一数据库Single database 每个 vCore 提供 500 IOPS,最大 7000 IOPS500 IOPS per vCore with 7000 maximum IOPS 超大规模是具有多个级别缓存的多层体系结构。Hyperscale is a multi-tiered architecture with caching at multiple levels. 有效 IOPS 将取决于工作负荷。Effective IOPS will depend on the workload. 5000 IOPS,最大 200,000 IOPS5000 IOPS with 200,000 maximum IOPS
托管实例Managed instance 取决于文件大小Depends on file size 不适用N/A 1375 IOPS/vCore1375 IOPS/vCore
可用性Availability 全部All 1 个副本,无读取扩展,无本地缓存1 replica, no Read Scale-out, no local cache 多个副本,最多 4 个读取扩展,部分本地缓存Multiple replicas, up to 4 Read Scale-out, partial local cache 3 个副本,1 个读取扩展,完整的本地存储3 replicas, 1 Read Scale-out, full local storage
备份Backups 全部All RA-GRS,7-35 天保留期(默认为 7 天)RA-GRS, 7-35 day retention (7 days by default) RA-GRS,7 天保留期,恒定的时间时点恢复 (PITR)RA-GRS, 7 day retention, constant time point-in-time recovery (PITR) RA-GRS,7-35 天保留期(默认为 7 天)RA-GRS, 7-35 day retention (7 days by default)

*“超大规模”服务层级不支持弹性池* Elastic pools are not supported in the Hyperscale service tier

哪些群体应使用“超大规模”服务层级Who should use the Hyperscale service tier

“超大规模”服务层级面向拥有大型本地 SQL Server 数据库并希望通过迁移到云来实现应用程序现代化的客户,或已使用 Azure SQL 数据库并且想大大拓展数据库增长可能性的客户。The Hyperscale service tier is intended for customers who have large on-premises SQL Server databases and want to modernize their applications by moving to the cloud, or for customers who are already using Azure SQL Database and want to significantly expand the potential for database growth. “超大规模”服务层级也适用于那些寻求高性能和高可伸缩性的客户。Hyperscale is also intended for customers who seek both high performance and high scalability. 使用“超大规模”服务层级,可以:With Hyperscale, you get:

  • 数据库大小最大为 100 TBDatabase size up to 100 TB
  • 快速进行数据库备份,无需考虑数据库大小(备份基于存储快照)Fast database backups regardless of database size (backups are based on storage snapshots)
  • 快速进行数据库还原,无需考虑数据库大小(从存储快照还原)Fast database restores regardless of database size (restores are from storage snapshots)
  • 无论数据库大小和 vCore 数目如何,都可提高日志吞吐量Higher log throughput regardless of database size and the number of vCores
  • 使用一个或多个只读副本的读取扩展,用于卸载读取工作负荷,并用作热备用服务器。Read Scale-out using one or more read-only replicas, used for read offloading and as hot standbys.
  • 在恒定时间内快速纵向扩展计算,以便提高适应繁重工作负荷的能力;然后在恒定时间内纵向缩减。Rapid scale up of compute, in constant time, to be more powerful to accommodate the heavy workload and then scale down, in constant time. 例如,这与在 P6 和 P11 之间来回缩放类似,但速度更快,因为这不是一种数据大小操作。This is similar to scaling up and down between a P6 and a P11, for example, but much faster as this is not a size of data operation.

哪些区域当前支持“超大规模”What regions currently support Hyperscale

“超大规模”服务层级目前已在 Azure SQL 数据库“超大规模”概述下面列出的区域中推出。The Hyperscale service tier is currently available in the regions listed under Azure SQL Database Hyperscale Overview.

能否为每个逻辑服务器创建多个“超大规模”数据库Can I create multiple Hyperscale databases per logical server

是的。Yes. 有关每个逻辑服务器的“超大规模”数据库数量的详细信息和限制,请参阅逻辑服务器上单一和共用数据库的 SQL 数据库资源限制For more information and limits on the number of Hyperscale databases per logical server, see SQL Database resource limits for single and pooled databases on a logical server.

“超大规模”数据库的性能特征有哪些What are the performance characteristics of a Hyperscale database

“超大规模”体系结构提供高性能和吞吐量,同时支持大型数据库。The Hyperscale architecture provides high performance and throughput while supporting large database sizes.

什么是“超大规模”数据库的可伸缩性What is the scalability of a Hyperscale database

“超大规模”根据工作负荷需求,提供快速的可伸缩性。Hyperscale provides rapid scalability based on your workload demand.

  • 增加/减少Scaling Up/Down

    使用“超大规模”数据库,可以纵向扩展 CPU、内存等资源的主要计算大小,然后在恒定的时间内将其减少。With Hyperscale, you can scale up the primary compute size in terms of resources like CPU and memory, and then scale down, in constant time. 因为是共享存储,所以纵向扩展和缩减不是数据大小操作。Because the storage is shared, scaling up and scaling down is not a size of data operation.

  • 缩小/扩大Scaling In/Out

    借助“超大规模”数据库,还能够预配一个或多个额外的计算副本,用于为读取请求提供服务。With Hyperscale, you also get the ability to provision one or more additional compute replicas that you can use to serve your read requests. 这意味着,可以将这些额外的计算副本用作只读副本,从主计算卸载读取工作负荷。This means that you can use these additional compute replicas as read-only replicas to offload your read workload from the primary compute. 这些副本除用作只读副本外,在主计算发生故障转移时,还充当热备用节点。In addition to read-only, these replicas also serve as hot-standbys in case of a failover from the primary.

    对每个额外的计算副本的预配可在恒定时间内完成,并且是联机操作。Provisioning of each of these additional compute replicas can be done in constant time and is an online operation. 将连接字符串的 ApplicationIntent 参数设置为 ReadOnly,即可连接到这些额外的只读计算副本。You can connect to these additional read-only compute replicas by setting the ApplicationIntent argument on your connection string to ReadOnly. 具有 ReadOnly 应用程序意向的任何连接均自动路由到某个额外的只读计算副本。Any connections with the ReadOnly application intent are automatically routed to one of the additional read-only compute replicas.

深入的问题Deep Dive Questions

是否可以在单个逻辑服务器中混合使用超大规模数据库和单一数据库Can I mix Hyperscale and single databases in a single logical server

可以。Yes, you can.

“超大规模”数据库需要更改应用程序编程模型吗Does Hyperscale require my application programming model to change

不,应用程序编程模型保持原样。No, your application programming model stays as is. 可以照常使用连接字符串和其他常规方式,以与“超大规模”数据库进行交互。You use your connection string as usual and the other regular ways to interact with your Hyperscale database.

“超大规模”数据库中的默认事务隔离级别是什么What transaction isolation level is the default in a Hyperscale database

在主要副本上,默认的事务隔离级别为 RCSI(已提交读快照隔离)。On the primary replica, the default transaction isolation level is RCSI (Read Committed Snapshot Isolation). 在读取扩展次要副本上,默认隔离级别为“快照”。On the Read Scale-out secondary replicas, the default isolation level is Snapshot.

能否将我的本地或 IaaS SQL Server 许可证引入“超大规模”Can I bring my on-premises or IaaS SQL Server license to Hyperscale

能,Azure 混合权益适用于“超大规模”。Yes, Azure Hybrid Benefit is available for Hyperscale. 每个 SQL Server Standard 核心都可以映射到 1 个超大规模 vCore。Every SQL Server Standard core can map to 1 Hyperscale vCores. 每个 SQL Server Enterprise 核心都可以映射到 4 个“超大规模”vCore。Every SQL Server Enterprise core can map to 4 Hyperscale vCores. 对于次要副本,不需要 SQL 许可证。You don't need a SQL license for secondary replicas. Azure 混合权益价格会自动应用到读取扩展(次要)副本。The Azure Hybrid Benefit price will be automatically applied to Read Scale-out (secondary) replicas.

哪种工作负荷专为“超大规模”设计What kind of workloads is Hyperscale designed for

“超大规模”支持所有 SQL Server 工作负荷,但它主要针对 OLTP 进行了优化。Hyperscale supports all SQL Server workloads, but it is primarily optimized for OLTP. 还可以引入混合 (HTAP) 和分析(数据市场)工作负荷。You can bring Hybrid (HTAP) and Analytical (data mart) workloads as well.

如何在 Azure SQL 数据仓库和 Azure SQL 数据库“超大规模”之间做出选择How can I choose between Azure SQL Data Warehouse and Azure SQL Database Hyperscale

如果目前运行的是使用 SQL Server 作为数据仓库的交互式分析查询,“超大规模”是很好的选择,因为能以较低费用托管中小型数据仓库(例如几 TB 到 100 TB),并且只需对 T-SQL 代码进行极少量的更改,即可将 SQL Server 数据仓库工作负荷迁移到“超大规模”。If you are currently running interactive analytics queries using SQL Server as a data warehouse, Hyperscale is a great option because you can host small and mid-size data warehouses (such as a few TB up to 100 TB) at a lower cost, and you can migrate your SQL Server data warehouse workloads to Hyperscale with minimal T-SQL code changes.

如果大规模运行包含复杂查询且持续引入速率超过 100 MB/秒的数据分析,并使用并行数据仓库 (PDW)、Teradata 或其他大规模并行处理 (MPP) 数据仓库,则 SQL 数据仓库可能是最佳选择。If you are running data analytics on a large scale with complex queries and sustained ingestion rates higher than 100 MB/s, or using Parallel Data Warehouse (PDW), Teradata, or other Massively Parallel Processing (MPP) data warehouses, SQL Data Warehouse may be the best choice.

“超大规模”计算问题Hyperscale Compute Questions

能不能随时暂停计算Can I pause my compute at any time

目前不能,但可以缩减计算和副本数量,以降低非高峰时段的成本。Not at this time, however you can scale your compute and number of replicas down to reduce cost during non-peak times.

能不能为内存密集型工作负荷预配包含额外 RAM 的计算副本Can I provision a compute replica with extra RAM for my memory-intensive workload

否。No. 要获取更多 RAM,需要升级到更大的计算大小。To get more RAM, you need to upgrade to a higher compute size. 有关详细信息,请参阅超大规模存储和计算大小For more information, see Hyperscale storage and compute sizes.

能不能预配大小不同的多个计算副本Can I provision multiple compute replicas of different sizes

否。No.

支持多少个读取扩展副本How many Read Scale-out replicas are supported

默认情况下,超大规模数据库是使用一个读取扩展副本(包括主要副本共有 2 个副本)创建的。The Hyperscale databases are created with one Read Scale-out replica (two replicas including primary) by default. 可以使用 Azure 门户REST API 将只读副本的数目缩放为 0 到 4 个。You can scale the number of read-only replicas between 0 and 4 using Azure portal or REST API.

若要实现高可用性,是否需要预配额外的计算副本For high availability, do I need to provision additional compute replicas

在超大规模数据库中,数据复原能力是在存储级别提供的。In Hyperscale databases, data resiliency is provided at the storage level. 只需一个副本即可提供复原能力。You only need one replica to provide resiliency. 计算副本关闭后,系统自动创建一个新副本,且不会丢失数据。When the compute replica is down, a new replica is created automatically with no data loss.

但是,如何只有一个副本,故障转移后可能需要一些时间才能在新副本中生成本地缓存。However, if there’s only one replica, it may take some time to build the local cache in the new replica after failover. 在缓存重新生成阶段,数据库直接从页面服务器中提取数据,导致存储延迟提高,查询性能下降。During the cache rebuild phase, the database fetches data directly from the page servers, resulting in higher storage latency and degraded query performance.

对于需要高可用性且只能对故障排除造成轻微影响的任务关键应用,应该预配至少 2 个计算副本(包括主要计算副本)。For mission-critical apps that require high availability with minimal failover impact, you should provision at least 2 compute replicas including the primary compute replica. 这是默认配置。This is the default configuration. 这样,就有一个充当故障转移目标的热备用副本可用。That way there is a hot-standby replica available that serves as a failover target.

数据大小和存储问题Data Size and Storage Questions

“超大规模”支持的最大数据库大小是多少What is the maximum database size supported with Hyperscale

100 TB。100 TB.

“超大规模”数据库事务日志的大小What is the size of the transaction log with Hyperscale

“超大规模”数据库的事务日志几乎是无穷大的。The transaction log with Hyperscale is practically infinite. 不需要担心在具有高日志吞吐量的系统上耗尽日志空间。You do not need to worry about running out of log space on a system that has a high log throughput. 但是,可能为连续主动写入工作负荷限制日志生成速率。However, log generation rate might be throttled for continuous aggressively writing workloads. 峰值持续日志生成速率为 100 MB/秒。The peak sustained log generation rate is 100 MB/s.

tempdb 是否会随着数据库增长而缩放Does my tempdb scale as my database grows

tempdb 数据库位于本地 SSD 存储,其大小与预配的计算大小成比例。Your tempdb database is located on local SSD storage and is sized proportionally to the compute size that you provision. 为提供最大性能优势,对 tempdb 进行了优化。Your tempdb is optimized to provide maximum performance benefits. tempdb 大小不可配置,它由你管理。tempdb size is not configurable and is managed for you.

数据库大小是否自动增长,我是否需要管理数据文件的大小Does my database size automatically grow, or do I have to manage the size of data files

你的数据库会随着你插入/引入更多数据自动增长。Your database size automatically grows as you insert/ingest more data.

“超大规模”支持或最初使用的最小数据库大小是多少What is the smallest database size that Hyperscale supports or starts with

40 GB。40 GB. 创建的“超大规模”数据库的初始大小为 10 GB。A Hyperscale database is created with a starting size of 10 GB. 然后,它每隔 10 分钟增大 10 GB,直至达到 40 GB 大小。Then, it starts growing by 10 GB every 10 minutes, until it reaches the size of 40 GB. 其中的每个 10 GB 区块在不同的页面服务器中分配,以提供更大的 IOPS 和更高的 I/O 并行度。Each of these 10 GB chucks is allocated in a different page server in order to provide more IOPS and higher I/O parallelism. 由于这种优化,即使选择小于 40 GB 的初始数据库大小,数据库也会自动扩大为至少 40 GB。Because of this optimization, even if you choose initial database size smaller than 40 GB, the database will grow to at least 40 GB automatically.

数据库的大小按多少增量增长In what increments does my database size grow

每个数据文件以 10 GB 增量增长。Each data file grows by 10 GB. 多个数据文件可以同时增长。Multiple data files may grow at the same time.

“超大规模”中的存储是本地存储还是远程存储Is the storage in Hyperscale local or remote

在“超大规模”数据库中,数据文件存储在 Azure 标准存储中。In Hyperscale, data files are stored in Azure standard storage. 数据完全缓存在本地 SSD 存储中靠近计算副本的页面服务器上。Data is fully cached on local SSD storage, on page servers that are close to the compute replicas. 此外,计算副本在本地 SSD 和内存中均有数据缓存,以便降低从远程页面服务器提取数据的频率。In addition, compute replicas have data caches on local SSD and in memory, to reduce the frequency of fetching data from remote page servers.

能否使用“超大规模”数据库管理或定义文件或文件组Can I manage or define files or filegroups with Hyperscale

否。No. 自动添加数据文件。Data files are added automatically. 创建其他文件组的常见原因在“超大规模”存储体系结构中不适用。The common reasons for creating additional filegroups do not apply in the Hyperscale storage architecture.

能否为我的数据库的数据增长预配硬上限Can I provision a hard cap on the data growth for my database

否。No.

如何使用“超大规模”排列数据文件How are data files laid out with Hyperscale

数据文件由页面服务器控制,每个数据文件有一个页面服务器。The data files are controlled by page servers, with one page server per data file. 随着数据大小的增长添加数据文件和关联的页面服务器。As the data size grows, data files and associated page servers are added.

是否支持数据库收缩Is database shrink supported

否。No.

是否支持数据压缩Is data compression supported

是,包括行、页和列存储压缩。Yes, including row, page, and columnstore compression.

如果表格巨大,表格数据是否会分布在多个数据文件中If I have a huge table, does my table data get spread out across multiple data files

是的。Yes. 与给定表格关联的数据页可在多个数据文件中出现,它们均属于相同文件组。The data pages associated with a given table can end up in multiple data files, which are all part of the same filegroup. SQL Server 使用按比例填充策略在数据文件间分布数据。SQL Server uses proportional fill strategy to distribute data over data files.

数据迁移问题Data Migration Questions

能否将现有 Azure SQL 数据库迁移到“超大规模”服务层级Can I move my existing Azure SQL databases to the Hyperscale service tier

是的。Yes. 可以将现有 Azure SQL 数据库迁移到“超大规模”服务层级。You can move your existing Azure SQL databases to Hyperscale. 这是一种单向迁移。This is a one-way migration. 无法将数据库从“超大规模”层级移到另一个服务层级。You can’t move databases from Hyperscale to another service tier. 对于概念证明 (POC),我们建议创建数据库的副本,并将副本迁移到“超大规模”。For proofs of concept (POCs), we recommend you make a copy of your database and migrate the copy to Hyperscale.

能否将“超大规模”数据库迁移到其他服务层级Can I move my Hyperscale databases to other service tiers

否。No. 目前,无法将超大规模数据库迁移到其他服务层级。At this time, you can’t move a Hyperscale database to another service tier.

迁移到“超大规模”服务层级后,是否会丢失一些功能Do I lose any functionality or capabilities after migration to the Hyperscale service tier

是的。Yes. 目前,部分 Azure SQL 数据库功能不受支持,包括但不限于长期备份保留。Some of Azure SQL Database features are not supported in Hyperscale yet, including but not limited to long term backup retention. 将数据库迁移到“超大规模”服务层级后,这些功能将停止运行。After you migrate your databases to Hyperscale, those features stop working. 我们预期这些限制是暂时性的。We expect these limitations to be temporary.

能否将我的本地 SQL Server 数据库或云虚拟机中的 SQL Server 数据库迁移到“超大规模”Can I move my on-premises SQL Server database, or my SQL Server database in a cloud virtual machine to Hyperscale

是的。Yes. 可以使用所有现有的迁移技术迁移到“超大规模”,包括事务复制,以及任何其他数据移动技术(批量复制、Azure 数据工厂、SSIS)。You can use all existing migration technologies to migrate to Hyperscale, including transactional replication, and any other data movement technologies (Bulk Copy, Azure Data Factory, SSIS). 另请参阅支持许多迁移方案的 Azure 数据库迁移服务See also the Azure Database Migration Service, which supports many migration scenarios.

从本地或虚拟机环境迁移到“超大规模”期间,我的停机时间有多长,如何尽量减少停机时间What is my downtime during migration from an on-premises or virtual machine environment to Hyperscale, and how can I minimize it

迁移到“超大规模”造成的停机时间与将数据库迁移到其他 Azure SQL 数据库服务层级造成的停机时间相同。Downtime for migration to Hyperscale is the same as the downtime when you migrate your databases to other Azure SQL Database service tiers. 可以使用事务复制尽量减少大小最多几 TB 的数据库的故障时间迁移。You can use transactional replication to minimize downtime migration for databases up to few TB in size. 对于非常大的数据库(10 TB 以上),可以考虑使用 ADF、Spark 或其他数据移动技术迁移数据。For very large databases (10+ TB), you can consider to migrate data using ADF, Spark, or other data movement technologies.

向“超大规模”引入 X 数据量需要多少时间How much time would it take to bring in X amount of data to Hyperscale

“超大规模”每秒能够使用 100 MB 的新数据/更改的数据,但将数据移入 Azure SQL 数据库所需的时间也会受到可用网络吞吐量、源读取速度和目标数据库服务级别目标的影响。Hyperscale is capable of consuming 100 MB/s of new/changed data, but the time needed to move data into Azure SQL databases is also affected by available network throughput, source read speed and the target database service level objective.

能否从 blob 存储读取数据并执行快速加载(如 SQL 数据仓库中的 Polybase)Can I read data from blob storage and do fast load (like Polybase in SQL Data Warehouse)

可让客户端应用程序从 Azure 存储中读取数据并将数据加载到“超大规模”数据库(就像对任何其他 Azure SQL 数据库执行的操作一样)。You can have a client application read data from Azure Storage and load data load into a Hyperscale database (just like you can with any other Azure SQL database). Azure SQL 数据库当前不支持 Polybase。Polybase is currently not supported in Azure SQL Database. 作为提供快速加载的替代方法,可以使用 Azure 数据工厂As an alternative to provide fast load, you can use Azure Data Factory. SQL 的 Spark 连接器支持批量插入。The Spark connector to SQL supports bulk insert.

还可以使用 BULK INSERT 或 OPENROWSET 从 Azure Blob 存储批量读取数据:批量访问 Azure Blob 存储中的数据的示例It is also possible to bulk read data from Azure Blob store using BULK INSERT or OPENROWSET: Examples of Bulk Access to Data in Azure Blob Storage.

“超大规模”数据库中不支持简单恢复或批量日志记录模式。Simple recovery or bulk logging model is not supported in Hyperscale. 提供高可用性和时点恢复需要完整恢复模式。Full recovery model is required to provide high availability and point-in-time recovery. 但是,相比于其他 Azure SQL 数据库服务层级而言,“超大规模”日志体系结构提供更佳的数据引入速率。However, Hyperscale log architecture provides better data ingest rate compared to other Azure SQL Database service tiers.

“超大规模”是否允许预配多个节点,用于并行引入大量数据Does Hyperscale allow provisioning multiple nodes for parallel ingesting of large amounts of data

否。No. “超大规模”是对称多处理 (SMP) 体系结构,而不是大规模并行处理 (MPP) 或多主数据库体系结构。Hyperscale is a symmetric multi-processing (SMP) architecture and is not a massively parallel processing (MPP) or a multi-master architecture. 只能创建多个副本来横向扩展只读工作负荷。You can only create multiple replicas to scale out read-only workloads.

支持迁移到“超大规模”的 SQL Server 最早版本是什么What is the oldest SQL Server version supported for migration to Hyperscale

SQL Server 2005。SQL Server 2005. 有关详细信息,请参阅迁移到单一数据库或共用数据库For more information, see Migrate to a single database or a pooled database. 对于兼容性问题,请参阅解决数据库迁移的兼容性问题For compatibility issues, see Resolving database migration compatibility issues.

“超大规模”是否支持从其他数据源(如 Amazon Aurora、MySQL、PostgreSQL、Oracle、DB2)和其他数据库平台进行迁移Does Hyperscale support migration from other data sources such as Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2, and other database platforms

是的。Yes. Azure 数据库迁移服务支持许多迁移方案。Azure Database Migration Service supports many migration scenarios.

业务连续性和灾难恢复问题Business Continuity and Disaster Recovery Questions

对“超大规模”数据库提供的 SLA 是什么What SLAs are provided for a Hyperscale database

请参阅 Azure SQL 数据库的 SLASee SLA for Azure SQL Database. 更多的次要计算副本可提高可用性,对于包含两个或更多个次要计算副本的数据库,SLA 高达 99.99%。Additional secondary compute replicas increase availability, up to 99.99% for a database with two or more secondary compute replicas.

Azure SQL 数据库服务是否托管我的数据库备份Are the database backups managed for me by the Azure SQL Database service

是的。Yes.

创建数据库备份的频率How often are the database backups taken

“超大规模”数据库没有传统的完整、差异和日志备份。There are no traditional full, differential, and log backups for Hyperscale databases. 但有数据文件的定期存储快照。Instead, there are regular storage snapshots of data files. 生成的日志只是按配置的保留期按原样保留,因此可以还原到保留期内的任意时间点。Log that is generated is simply retained as-is for the configured retention period, allowing restore to any point in time within the retention period.

“超大规模”是否支持时间点还原Does Hyperscale support point in time restore

是的。Yes.

“超大规模”中的数据库还原的恢复点目标 (RPO)/恢复时间目标 (RTO) 是什么What is the Recovery Point Objective (RPO)/Recovery Time Objective (RTO) for database restore in Hyperscale

无论数据库大小,RPO 最少为 0,RTO 目标不超过 10 分钟。The RPO is 0 min. The RTO goal is less than 10 minutes, regardless of database size.

数据库备份是否影响主要副本或次要副本的计算性能Does database backup affect compute performance on my primary or secondary replicas

否。No. 备份由存储子系统管理,利用存储快照。Backups are managed by the storage subsystem, and leverage storage snapshots. 它们不会影响用户工作负荷。They do not impact user workloads.

能否对“超大规模”数据库执行异地还原Can I perform geo-restore with a Hyperscale database

是的。Yes. 完全支持异地还原。Geo-restore is fully supported. 与时间点还原不同,异地还原需要数据大小操作。Unlike point-in-time restore, geo-restore requires a size-of-data operation. 将并行复制数据文件,因此此操作的持续时间主要取决于数据库中最大文件的大小,而不是数据库总大小。Data files are copied in parallel, so the duration of this operation depends primarily on the size of the largest file in the database, rather than on total database size. 如果将数据库还原到与源数据库的区域配对的 Azure 区域中,则异地还原时间会明显缩短。Geo-restore time will be significantly shorter if the database is restored in the Azure region that is paired with the region of the source database.

能否对“超大规模”数据库设置异地复制Can I set up geo-replication with Hyperscale database

目前没有。Not at this time.

能否备份“超大规模”数据库,并还原到我的本地服务器或 VM 中的 SQL ServerCan I take a Hyperscale database backup and restore it to my on-premises server, or on SQL Server in a VM

否。No. “超大规模”数据库的存储格式不同于任何 SQL Server 发行版,你不控制备份且无权访问备份。The storage format for Hyperscale databases is different from any released version of SQL Server, and you don't control backups or have access to them. 若要将数据移出“超大规模”数据库,可以使用任何数据移动技术(例如 Azure 数据工厂、SSIS 等)提取数据。To take your data out of a Hyperscale database, you can extract data using any data movement technologies, i.e. Azure Data Factory, SSIS, etc.

跨功能问题Cross-Feature Questions

迁移到“超大规模”服务层级后,是否会丢失一些功能Do I lose any functionality or capabilities after migration to the Hyperscale service tier

是的。Yes. 部分 Azure SQL 数据库功能不受支持,包括但不限于长期备份保留。Some of Azure SQL Database features are not supported in Hyperscale, including but not limited to long term backup retention. 将数据库迁移到“超大规模”服务层级后,这些功能将停止运行。After you migrate your databases to Hyperscale, those features stop working.

Polybase 是否适用于“超大规模”Will Polybase work with Hyperscale

否。No. Azure SQL 数据库不支持 Polybase。Polybase is not supported in Azure SQL Database.

“超大规模”是否支持 R 和 PythonDoes Hyperscale have support for R and Python

目前没有。Not at this time.

计算节点是否是容器化的Are compute nodes containerized

否。No. “超大规模”进程在 Service Fabric 节点 (VM) 上运行,而不是在容器中运行。Hyperscale processes run on a Service Fabric nodes (VMs), not in containers.

性能问题Performance Questions

可以在“超大规模”数据库中推送多少写入吞吐量How much write throughput can I push in a Hyperscale database

对于任何“超大规模”计算大小,事务日志吞吐量上限设置为 100 MB/秒。Transaction log throughput cap is set to 100 MB/s for any Hyperscale compute size. 实现此速率的能力取决于多种因素,包括但不限于工作负荷类型、客户端配置,以及在主要计算副本上提供足够的计算容量来以此速率生成日志。The ability to achieve this rate depends on multiple factors, including but not limited to workload type, client configuration, and having sufficient compute capacity on the primary compute replica to produce log at this rate.

在最大的计算节点上可以获得多少 IOPSHow many IOPS do I get on the largest compute

IOPS 和 IO 延迟根据工作负荷模式而异。IOPS and IO latency will vary depending on the workload patterns. 如果访问的数据缓存在计算副本上,则它的 IO 性能与使用本地 SSD 时类似。If the data being accessed is cached on the compute replica, you will see similar IO performance as with local SSD.

吞吐量是否受备份影响Does my throughput get affected by backups

否。No. 计算节点与存储层分离。Compute is decoupled from the storage layer. 这消除了备份对性能的影响。This eliminates performance impact of backup.

当我预配其他计算副本时,吞吐量是否会受到影响Does my throughput get affected as I provision additional compute replicas

由于存储已共享,并且主要计算副本和次要计算副本之间没有发生直接物理复制,添加次要副本不会直接影响主要副本上的吞吐量。Because the storage is shared and there is no direct physical replication happening between primary and secondary compute replicas, the throughput on primary replica will not be directly affected by adding secondary replicas. 但我们可以限制在主要副本上连续主动写入工作负荷,从而允许日志应用到次要副本和页面服务器上,并避免次要副本上读取性能不佳。However, we may throttle continuous aggressively writing workload on the primary to allow log apply on secondary replicas and page servers to catch up, to avoid poor read performance on secondary replicas.

如何诊断和排查“超大规模”数据库中的性能问题How do I diagnose and troubleshoot performance problems in a Hyperscale database

对于大多数性能问题,尤其是根本原因与存储无关的性能问题,可以采取常用的 SQL Server 诊断和故障排除步骤。For most performance problems, particularly the ones not rooted in storage performance, common SQL Server diagnostic and troubleshooting steps apply. 有关特定于“超大规模”的存储诊断,请参阅 SQL 超大规模服务层级性能故障排除诊断For Hyperscale-specific storage diagnostics, see SQL Hyperscale performance troubleshooting diagnostics.

可伸缩性问题Scalability Questions

纵向扩展和减少计算副本需要多长时间How long would it take to scale up and down a compute replica

无论数据大小如何,纵向扩展或缩减计算节点都需要 5 到 10 分钟时间。Scaling compute up or down should take 5-10 minutes regardless of data size.

进行纵向扩展/缩减操作时,数据库是否处于脱机状态Is my database offline while the scaling up/down operation is in progress

否。No. 纵向扩展/缩减操作为联机操作。The scaling up and down will be online.

缩放操作过程中,连接是否会断开Should I expect connection drop when the scaling operations are in progress

如果在缩放操作结束时发生故障转移,纵向扩展或缩减操作会导致现有连接断开。Scaling up or down results in existing connections being dropped when a failover happens at the end of the scaling operation. 添加次要副本不会导致连接断开。Adding secondary replicas does not result in connection drops.

纵向扩展和缩减计算副本是自动的操作还是由最终用户触发的操作Is the scaling up and down of compute replicas automatic or end-user triggered operation

是由最终用户触发的。End-user. 不是自动的。Not automatic.

计算纵向扩展时,tempdb 数据库大小是否也会随之增长Does the size of my tempdb database also grow as the compute is scaled up

是的。Yes. tempdb 数据库会随着计算自动纵向扩展。The tempdb database will scale up automatically as the compute grows.

能否预配多个主要计算副本(例如多主数据库系统,其中多个主要计算标头可以驱动更高的并发级别)?Can I provision multiple primary compute replicas, such as a multi-master system, where multiple primary compute heads can drive a higher level of concurrency

否。No. 只有主要计算副本接受读/写请求。Only the primary compute replica accepts read/write requests. 次要计算副本只接受只读请求。Secondary compute replicas only accept read-only requests.

读取扩展问题Read Scale-out Questions

可以预配多少个次要计算副本How many secondary compute replicas can I provision

默认情况下,我们将为“超大规模”数据库创建一个辅助副本。We create one secondary replica for Hyperscale databases by default. 若要调整副本数目,可以使用 Azure 门户REST APIIf you want to adjust the number of replicas, you can do so using Azure portal or REST API.

如何连接到这些次要计算副本How do I connect to these secondary compute replicas

将连接字符串的 ApplicationIntent 参数设置为 ReadOnly,即可连接到这些额外的只读计算副本。You can connect to these additional read-only compute replicas by setting the ApplicationIntent argument on your connection string to ReadOnly. 任何标记为 ReadOnly 的连接均自动路由到某个额外的只读计算副本。Any connections marked with ReadOnly are automatically routed to one of the additional read-only compute replicas.

如何使用 SSMS 或其他客户端工具验证是否已成功连接到辅助计算副本?How do I validate if I have successfully connected to secondary compute replica using SSMS or other client tools?

可执行以下 T-SQL 查询:SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability')You can execute the following T-SQL query: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). 如果已连接到只读辅助副本,则结果为 READ_ONLY;如果已连接到主要副本,则结果为 READ_WRITEThe result is READ_ONLY if you are connected to a read-only secondary replica, and READ_WRITE if you are connected to the primary replica. 请注意,必须将数据库上下文设置为“超大规模”数据库的名称,而不能设置为 master 数据库的名称。Note that the database context must be set to the name of the Hyperscale database, not to the master database.

能否为读取扩展副本创建专用终结点Can I create a dedicated endpoint for a Read Scale-out replica

否。No. 只能通过指定 ApplicationIntent=ReadOnly 连接到读取扩展副本。You can only connect to Read Scale-out replicas by specifying ApplicationIntent=ReadOnly.

系统是否对读取工作负荷进行智能负载均衡Does the system do intelligent load balancing of the read workload

否。No. 具有只读意向的新连接将重定向到任意读取扩展副本。A new connection with read-only intent is redirected to an arbitrary Read Scale-out replica.

能否独立于主要副本纵向扩展/缩减次要计算副本Can I scale up/down the secondary compute replicas independently of the primary replica

否。No. 辅助计算副本也用作高可用性故障转移目标,因此它们的配置需要与主要副本相同,才能在故障转移后提供预期的性能。The secondary compute replica are also used as high availability failover targets, so they need to have the same configuration as the primary to provide expected performance after failover.

对于我的主要计算副本和额外的次要计算副本,能否获得不同的 tempdb 大小Do I get different tempdb sizing for my primary compute and my additional secondary compute replicas

否。No. tempdb 数据库根据计算大小预配进行配置,辅助计算副本的大小与主要计算副本相同。Your tempdb database is configured based on the compute size provisioning, your secondary compute replicas are the same size as the primary compute.

能否对次要计算副本添加索引和视图Can I add indexes and views on my secondary compute replicas

否。No. “超大规模”数据库有共享存储,这表示所有计算副本会看到相同的表格、索引和视图。Hyperscale databases have shared storage, meaning that all compute replicas see the same tables, indexes, and views. 如果要使次要副本上的额外索引得到读取优化,必须在主要副本上添加索引。If you want additional indexes optimized for reads on secondary, you must add them on the primary.

主要和次要计算副本之间的延迟是多少How much delay is there going to be between the primary and secondary compute replicas

从在主要副本上提交事务的时间开始算起,到该事务显示在次要副本上的时间为止的数据延迟取决于当前日志生成速率。Data latency from the time a transaction is committed on the primary to the time it is visible on a secondary depends on current log generation rate. 典型的数据延迟只有几毫秒。Typical data latency is in low milliseconds.

后续步骤Next Steps

有关“超大规模”服务层级的详细信息,请参阅“超大规模”服务层级For more information about the Hyperscale service tier, see Hyperscale service tier.