Today we pre-announced the public preview of Azure SQL Database Hyperscale. SQL Database Hyperscale is a new SQL-based and highly scalable service tier for single databases that adapts on-demand to your workload’s needs. With SQL Database Hyperscale, databases can quickly auto-scale up to 100TB, eliminating the need to pre-provision storage resources, and significantly expanding the potential for app growth without being limited by storage size. The public preview will be available on October 1st, 2018.
Compared to current Azure SQL Database service tiers, Hyperscale provides the following additional capabilities:
- Supports up to 100TB database size
- Rapid scale up/down and point-in-time restore, regardless of the database size
- Higher log throughput than current service tiers
- Scale out read-only workload with read-scale replicas without data copy
Azure SQL Database Hyperscale is built based on a new cloud-born architecture which decouples compute, log and storage.
Compute nodes
The compute nodes look like a traditional SQL Server, but without local data files or log files. The primary compute node writes transactional logs to the log service and fetches data pages from page servers if they are not found in the local data cache or RBPEX (Resilient Buffer Pool Extension)
Log service
The log service externalizes the transactional log from a Hyperscale database. The primary compute instance writes the log to the log service. The page servers and secondary compute instances consume the log from the log service. The Log service also offloads log records to cheaper long-term storage to support point in time restore.
Page servers
The page servers host and maintain the data files. It consumes the log stream from the log services and applies the data modifications described in the log stream to data files. Read requests of data pages that are not found in the compute’s local data cache or RBPEX are sent over the network to the page servers that own the pages. In page servers, the data files are persisted in Azure Storage and are heavily cached through RBPEX.
Multiple page servers will be created for a large database. When the database is growing and available space in existing page servers is lower than a threshold, a new page server is automatically added to the database. Since page servers are working independently, it allows us to grow the database with no local resource constraints.
Automated backup and point in time restore
In a Hyperscale database, snapshots of the data files are taken from the page servers periodically to replace the traditional streaming backup. It allows us to backup a very large database in just a few seconds. Together with the log records stored in the log service, you can restore the database to any point in time during retention (7 days in public preview) in a very short time, regardless of the database size.
We’re excited about the new levels of scalability that SQL Database Hyperscale introduces. You can create a Hyperscale database in 12 different Azure regions, starting October 1st. For more details, please refer to the Azure SQL Database documentation.