Azure SQL Database ハイパースケールに関する FAQAzure SQL Database Hyperscale FAQ

適用対象: Azure SQL Database

この記事では、Azure SQL Database ハイパースケール サービス レベル (以降、この FAQ ではハイパースケールと呼びます) のデータベースをご検討中のお客様向けに、よく寄せられる質問の回答を紹介します。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.

  • この FAQ は、ハイパースケール サービス レベルの概要を理解し、具体的な質問や懸案事項の回答を求める読者を対象としています。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.
  • この FAQ はガイドブックではなく、ハイパースケール データベースの使用方法に関する質問に回答するものでもありません。This FAQ isn’t meant to be a guidebook or answer questions on how to use a Hyperscale database. ハイパースケールの概要については、Azure SQL Database ハイパースケールに関する記事をご覧ください。For an introduction to Hyperscale, we recommend you refer to the Azure SQL Database Hyperscale documentation.

一般的な質問General questions

ハイパースケール データベースとはWhat is a Hyperscale database

ハイパースケール データベースとは、ハイパースケール スケールアウト ストレージ テクノロジによって支えられている、ハイパースケール サービス レベルの SQL Database データベースです。A Hyperscale database is a database in 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 Database のデータベースと変わりません。Scaling is transparent to the application – connectivity, query processing, etc. work like any other database in Azure SQL Database.

ハイパースケールをサポートするリソースの種類と購入モデルWhat resource types and purchasing models support Hyperscale

ハイパースケール サービス レベルを利用できるのは、Azure SQL データベース において仮想コアベースの購入モデルを使用する単一のデータベースのみです。The Hyperscale service tier is only available for single databases using the vCore-based purchasing model in Azure SQL Database.

ハイパースケール サービス レベルと General Purpose サービス レベルおよび Business Critical サービス レベルとの違いHow does the Hyperscale service tier differ from the General Purpose and Business Critical service tiers

次の表で説明するように、仮想コアベースのサービス レベルは、データベースの可用性とストレージの種類、パフォーマンス、および最大サイズに基づいて区別されます。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 PurposeGeneral Purpose ハイパースケールHyperscale Business CriticalBusiness Critical
最適な用途Best for AllAll 予算重視のバランスの取れたコンピューティングおよびストレージ オプションを提供します。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 SQL Database/SQL Managed InstanceSQL Database / SQL Managed Instance 単一データベースSingle database SQL Database/SQL Managed InstanceSQL Database / SQL Managed Instance
コンピューティング サイズCompute size SQL Database*SQL Database* 1 - 80 の仮想コア1 to 80 vCores 1 - 80 の仮想コア *1 to 80 vCores* 1 - 80 の仮想コア1 to 80 vCores
コンピューティング サイズCompute size SQL Managed InstanceSQL Managed Instance 8、16、24、32、40、64、80 の仮想コア8, 16, 24, 32, 40, 64, 80 vCores 該当なしN/A 8、16、24、32、40、64、80 の仮想コア8, 16, 24, 32, 40, 64, 80 vCores
ストレージの種類Storage type AllAll Premium リモート ストレージ (インスタンスあたり)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 SQL Database *SQL Database * 5 GB – 4 TB5 GB – 4 TB 最大 100 TBUp to 100 TB 5 GB – 4 TB5 GB – 4 TB
ストレージ サイズStorage size SQL Managed InstanceSQL Managed Instance 32 GB – 8 TB32 GB – 8 TB 該当なしN/A 32 GB – 4 TB32 GB – 4 TB
IOPSIOPS 単一データベースSingle database 仮想コアあたり 500 IOPS (最大 7000 IOPS)500 IOPS per vCore with 7000 maximum IOPS Hyperscale は、複数のレベルのキャッシュが存在する複数レベル アーキテクチャです。Hyperscale is a multi-tiered architecture with caching at multiple levels. 有効な IOPS はワークロードによって異なります。Effective IOPS will depend on the workload. 5000 IOPS (最大 200,000 IOPS)5000 IOPS with 200,000 maximum IOPS
IOPSIOPS SQL Managed InstanceSQL Managed Instance ファイル サイズによって異なるDepends on file size 該当なしN/A 1375 IOPS/仮想コア1375 IOPS/vCore
可用性Availability AllAll 1 レプリカ、読み取りスケールアウトなし、ローカル キャッシュなし1 replica, no Read Scale-out, no local cache 複数のレプリカ、最大 4 読み取りスケールアウト、部分的ローカル キャッシュMultiple replicas, up to 4 Read Scale-out, partial local cache 3 レプリカ、1 読み取りスケールアウト、ゾーン冗長 HA、完全ローカル ストレージ3 replicas, 1 Read Scale-out, zone-redundant HA, full local storage
バックアップBackups AllAll 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

Hyperscale サービス レベルの対象として意図されているのは、大規模なオンプレミスの SQL Server データベースを備えていて、クラウドに移行することによりアプリケーションを最新化することを考えているお客様、または既に Azure SQL Database を使用しており、データベースのサイズを増大するために大幅な拡張を望むお客様です。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 TB のデータベース サイズDatabase 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)
  • データベースのサイズと仮想コアの数にかかわらないログ スループットの向上Higher log throughput regardless of database size and the number of vCores
  • 1 つ以上の読み取り専用レプリカを使用した読み取りスケールアウト (読み取りオフロードやホット スタンバイに対応)。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 Database のハイパースケールの概要のページに示されているリージョンで利用可能です。The Hyperscale service tier is currently available in the regions listed under Azure SQL Database Hyperscale Overview.

サーバーごとに複数のハイパースケール データベースを作成できるかCan I create multiple Hyperscale databases per server

はい。Yes. サーバーあたりのハイパースケール データベース数の詳細や制約について詳しくは、サーバー上の単一データベースおよびプールされたデータベースの SQL Database のリソース制限に関するページをご覧ください。For more information and limits on the number of Hyperscale databases per server, see SQL Database resource limits for single and pooled databases on a 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

    ハイパースケールでは、読み取り要求を処理するために使用できる 1 つ以上の追加計算レプリカをプロビジョニングする機能も提供されます。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

1 つのサーバー上でハイパースケールと単一データベースを混在できるかCan I mix Hyperscale and single databases in a single 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 (Read Committed スナップショット分離) です。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 つのハイパースケール仮想コアにマップできます。Every SQL Server Standard core can map to 1 Hyperscale vCores. SQL Server Enterprise コアそれぞれを 4 つのハイパースケール仮想コアにマップできます。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 Synapse Analytics と Azure SQL Database ハイパースケールのどちらを選ぶべきかHow can I choose between Azure Synapse Analytics 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/秒を超えるデータ インジェスト速度で大規模にデータ分析を実行している場合、または Parallel Data Warehouse (PDW)、Teradata またはその他の超並列処理 (MPP) データ ウェアハウスを使用している場合は、Azure Synapse Analytics (旧称 SQL Data Warehouse) が最適な選択肢となるでしょう。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, Azure Synapse Analytics (formerly 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

ハイパースケール データベースは、既定で 1 つの読み取りスケールアウト レプリカを含むように作成されます (プライマリを含めて 2 つのレプリカ)。The Hyperscale databases are created with one Read Scale-out replica (two replicas including primary) by default. Azure portal または 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. 回復性を実現するために必要なのは 1 つのレプリカだけです。You only need one replica to provide resiliency. コンピューティング レプリカが停止すると、新しいレプリカが自動的に作成されるためデータは失われません。When the compute replica is down, a new replica is created automatically with no data loss.

ただし、レプリカが 1 つしかない場合は、フェールオーバー後に新しいレプリカにローカル キャッシュを構築するために少し時間がかかることがあります。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. IOPS とI/O 並列処理を向上させるために、これらの 10 GB チャンクはそれぞれ別のページ サーバーに割り当てられます。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 Standard ストレージに格納されます。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

データ ファイルはページ サーバーによって制御されます。ページ サーバーはデータ ファイルごとに 1 つあります。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 Database のデータベースをハイパースケール サービス レベルに移行できるかCan I move my existing databases in Azure SQL Database to the Hyperscale service tier

はい。Yes. ハイパースケールには既存の Azure SQL Database データベースを移行できます。You can move your existing databases in Azure SQL Database 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.

既存のデータベースを Hyperscale に移動するのに必要な時間は、データのコピーにかかる時間と、データのコピー中にソース データベースに加えられた変更を再生する時間で構成されます。The time required to move an existing database to Hyperscale consists of the time to copy data, and the time to replay the changes made in the source database while copying data. データのコピー時間は、データのサイズに比例します。The data copy time is proportional to data size. 書き込み操作が少ない期間に移動が行われた場合、変更の再生にかかる時間は短くなります。The time to replay changes will be shorter if the move is done during a period of low write activity.

ハイパースケール データベースを他のサービス レベルに移行できるか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 Database の一部の機能は、まだハイパースケールではサポートされていません。Some 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 Data Factory、Azure Databricks、SSIS) などの Hyperscale に移行することができます。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, Azure Databricks, SSIS). Azure Database Migration Service に関するページもご覧ください。このサービスでは、多くの移行シナリオがサポートされています。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 Database サービス レベルに移行する際のダウンタイムと同じです。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 Database のデータベースにデータを移動するために必要な時間は、使用可能なネットワーク スループット、ソースの読み取り速度、ターゲット データベースのサービス レベル目標の影響も受けます。Hyperscale is capable of consuming 100 MB/s of new/changed data, but the time needed to move data into databases in Azure SQL Database is also affected by available network throughput, source read speed and the target database service level objective.

BLOB ストレージからデータを読み取って高速読み込みできるか (Azure Synapse Analytics の Polybase のように)Can I read data from blob storage and do fast load (like Polybase in Azure Synapse Analytics)

クライアント アプリケーションで Azure Storage からデータを読み取り、ハイパースケール データベースに読み込むことができます (他の Azure SQL Database データベースの場合と同様です)。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 database in Azure SQL Database). Polybase は現在 Azure SQL Database でサポートされていません。Polybase is currently not supported in Azure SQL Database. 高速読み込みを提供する代替手段として、Azure Data Factory を使用するか、SQL 用 Spark コネクタで Spark ジョブを Azure Databricks で使用できます。As an alternative to provide fast load, you can use Azure Data Factory, or use a Spark job in Azure Databricks with the Spark connector for SQL. SQL 用の Spark コネクタでは一括挿入がサポートされます。The Spark connector to SQL supports bulk insert.

BULK INSERT または OPENROWSET を使用して、Azure BLOB ストアからデータを一括で読み取ることもできます。Azure Blob Storage のデータに一括アクセスする例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 Database サービス レベルと比較してデータ取り込み率が向上しています。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 Database Migration Service では多くの移行シナリオがサポートされています。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 Database の SLA」を参照してください。See SLA for Azure SQL Database. セカンダリ計算レプリカを追加することで可用性が上がります。複数のセカンダリ計算レプリカを持つデータベースでは最大 99.99% になります。Additional secondary compute replicas increase availability, up to 99.99% for a database with two or more secondary compute replicas.

Azure SQL Database によってデータベース バックアップが管理されるかAre the database backups managed for me by Azure SQL Database

はい。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 分です。ほとんどの復元操作は、データベース サイズにかかわらず、60 分以内に完了します。The RPO is 0 min. Most restore operations complete within 60 minutes regardless of database size. 大規模なデータベースの場合、および復元ポイントの前とそこに至るまでの時間に大量の書き込みアクティビティが発生した場合は、復元時間が長くなる可能性があります。Restore time may be longer for larger databases, and if the database had experienced significant write activity before and up to the restore point in time.

データベース バックアップは、プライマリ レプリカまたはセカンダリ レプリカのコンピューティング パフォーマンスに影響するか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.

ハイパースケール データベースを使用して geo リストアを実行できるかCan I perform geo-restore with a Hyperscale database

はい。Yes. geo リストアは完全にサポートされています。Geo-restore is fully supported. ポイントインタイム リストアとは異なり、geo リストアでは、データ サイズに応じた操作が必要です。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 リストアの時間は大幅に短くなります。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.

ハイパースケール データベースを使用して geo レプリケーションを設定できるかCan I set up geo-replication with Hyperscale database

現時点ではありません。Not at this time.

ハイパースケール データベースのバックアップを使って、それをオンプレミス サーバーまたは VM の SQL Server に復元できるかCan 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 Data Factory、Azure Databricks、SSIS などのデータ移動テクノロジを使用して、データを抽出できます。To take your data out of a Hyperscale database, you can extract data using any data movement technologies, i.e. Azure Data Factory, Azure Databricks, SSIS, etc.

移行前後の機能に関する質問Cross-feature questions

ハイパースケール サービス レベルに移行した後で使えなくなる機能があるかDo I lose any functionality or capabilities after migration to the Hyperscale service tier

はい。Yes. 長期的なバックアップ リテンション期間を始めとする Azure SQL Database の一部の機能は、ハイパースケールではサポートされていません。Some 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. Polybase は Azure SQL Database でサポートされていません。Polybase is not supported in Azure SQL Database.

ハイパースケールで R と Python がサポートされるかDoes Hyperscale have support for R and Python

現時点ではありません。Not at this time.

計算ノードはコンテナー化されるかAre compute nodes containerized

いいえ。No. ハイパースケール プロセスは、コンテナーではなく Service Fabric ノード (VM) で実行されます。Hyperscale processes run on 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.

最大のコンピューティングにおいて得られる IOPS 数How 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 の診断とトラブルシューティングの手順が適用されます。For most performance problems, particularly the ones not rooted in storage performance, common SQL diagnostic and troubleshooting steps apply. ハイパースケール固有のストレージ診断については、「SQL Hyperscale のパフォーマンスのトラブルシューティング診断」を参照してください。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

コンピューティングのスケールアップまたはスケールダウンには、データ サイズに関係なく、通常、最大 2 分かかります。Scaling compute up or down typically takes up to 2 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 データベースと RBPEX キャッシュのサイズも増大するかDoes the size of my tempdb database and RBPEX cache also grow as the compute is scaled up

はい。Yes. コンピューティング ノードの tempdb データベースと RBPEX キャッシュのサイズは、コア数の増加に応じて自動的にスケールアップされます。The tempdb database and RBPEX cache size on compute nodes will scale up automatically as the number of cores is increased.

複数のプライマリ コンピューティング ヘッドでより高レベルの同時実行を推進できる、複数のプライマリ計算レプリカ (マルチマスター システムなど) をプロビジョニングできるか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

既定では、ハイパースケール データベース用にセカンダリ レプリカが 1 つ作成されます。We create one secondary replica for Hyperscale databases by default. レプリカの数を調整する場合は、Azure portal または REST API を使用します。If 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. 詳細については、「読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする」を参照してください。For details, see Use read-only replicas to offload read-only query workloads.

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_WRITE になります。The 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 readable on a secondary depends on current log generation rate, transaction size, load on the replica, and other factors. 小規模なトランザクションの一般的なデータ待機時間は数十ミリ秒ですが、データ待機時間に上限はありません。Typical data latency for small transactions is in tens of milliseconds, however there is no upper bound on data latency. 特定のセカンダリ レプリカのデータは、トランザクションに対して常に一貫性があります。Data on a given secondary replica is always transactionally consistent. ただし、特定の時点でのデータの待機時間は、セカンダリ レプリカによって異なる場合があります。However, at a given point in time data latency may be different for different secondary replicas. コミットされたデータの読み取りが直ちに必要なワークロードは、プライマリ レプリカで実行される必要があります。Workloads that need to read committed data immediately should run on the primary replica.

次のステップNext steps

ハイパースケール サービス レベルについて詳しくは、ハイパースケール サービス レベルに関するページをご覧ください。For more information about the Hyperscale service tier, see Hyperscale service tier.