Tingkat layanan Hyperscale
Berlaku untuk:
Azure SQL Database
Azure SQL Database didasarkan pada arsitektur Mesin Database SQL Server yang disesuaikan dengan lingkungan cloud untuk memastikan high availability bahkan dalam kasus kegagalan infrastruktur. Ada tiga pilihan tingkat layanan dalam model pembelian vCore untuk Azure SQL Database:
- Tujuan Umum
- Bisnis Kritis
- Hiperskala
Tingkat layanan Hyperscale cocok untuk semua jenis beban kerja. Arsitektur cloud-native-nya menyediakan komputasi dan penyimpanan yang dapat diskalakan secara independen untuk mendukung berbagai aplikasi tradisional dan modern yang terluas. Sumber daya komputasi dan penyimpanan di Hyperscale secara substansial melebihi sumber daya yang tersedia di tingkat Tujuan Umum dan Bisnis Kritis.
Untuk detail tentang tingkatan layanan Tujuan Umum dan Bisnis Penting dalam model pembelian berbasis vCore, lihat tingkat Tujuan Umum dan Layanan Bisnis Penting. Untuk perbandingan model pembelian berbasis vCore dengan model pembelian berbasis DTU, lihat Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database.
Tingkat layanan Hyperscale saat ini hanya tersedia untuk Azure SQL Database, dan bukan untuk Azure SQL Managed Instance.
Apa saja kemampuan Hyperscale
Tingkat layanan Hyperscale di Azure SQL Database menyediakan kemampuan tambahan berikut:
- Peningkatan skala cepat - Anda dapat, dalam waktu konstan, meningkatkan sumber daya komputasi Anda untuk mengakomodasi beban kerja yang berat saat diperlukan, lalu menurunkan skala sumber daya komputasi saat tidak diperlukan.
- Peluasan skala cepat - Anda dapat menyediakan satu atau lebih replika baca-saja untuk mengalihkan beban kerja baca dan digunakan sebagai siaga panas.
- Peningkatan kapasitas otomatis, penurunan kapasitas, dan penagihan untuk komputasi yang disesuaikan berdasarkan pemakaian dengan komputasi tanpa server.
- Harga/performa optimal untuk sekelompok database Hyperscale yang memiliki tuntutan sumber daya yang bervariasi dengan pool elastis.
- Penyimpanan penskalaan otomatis dengan dukungan hingga 128 TB database atau ukuran kumpulan elastis 100 TB.
- Performa keseluruhan yang lebih tinggi karena throughput log transaksi yang lebih tinggi dan waktu komit transaksi yang lebih cepat tanpa memandang volume data.
- Pencadangan database yang cepat (berdasarkan cuplikan file), tanpa memperhatikan ukuran, dan tanpa dampak I/O pada sumber daya komputasi.
- Pemulihan atau penyalinan database yang cepat (berdasarkan cuplikan file) dalam hitungan menit, bukan jam atau hari.
Tingkat layanan Hyperscale menghapus banyak batas praktis yang secara tradisional terlihat dalam database cloud. Di mana sebagian besar database lain dibatasi oleh sumber daya yang tersedia dalam satu simpul, database di tingkat layanan Hyperscale tidak memiliki batas seperti itu. Dengan arsitektur penyimpanannya yang fleksibel, penyimpanan tumbuh sesuai kebutuhan. Bahkan, database Hyperscale tidak dibuat dengan ukuran maks yang ditentukan. Database Hyperscale tumbuh sesuai kebutuhan - dan Anda hanya ditagih untuk kapasitas penyimpanan yang dialokasikan. Untuk beban kerja baca intensif, tingkat layanan Hyperscale menyediakan peluasan skala cepat dengan menyediakan replika tambahan sesuai kebutuhan untuk menurunkan beban kerja baca.
Selain itu, waktu yang diperlukan untuk membuat cadangan database atau untuk meningkatkan atau menurunkan skala tidak lagi terkait dengan volume data dalam database. Database Hyperscale dicadangkan secara virtual secara instan. Anda juga dapat menskalakan database dalam puluhan terabyte ke atas atau ke bawah dalam hitungan menit di tingkat komputasi yang disediakan atau menggunakan tanpa server untuk menskalakan komputasi secara otomatis. Kemampuan ini membebaskan Anda dari kekhawatiran terjebak oleh pilihan konfigurasi awal Anda.
Untuk informasi selengkapnya tentang ukuran komputasi untuk tingkat layanan Hyperscale, lihat Karakteristik tingkat layanan.
Siapa yang harus mempertimbangkan tingkat layanan Hyperscale
Tingkat layanan Hyperscale ditujukan untuk semua pelanggan yang membutuhkan performa dan ketersediaan yang lebih tinggi, pencadangan dan pemulihan yang cepat, dan/atau penyimpanan cepat dan skalabilitas komputasi. Termasuk pelanggan yang beralih ke cloud untuk memodernisasi aplikasi mereka dan pelanggan yang sudah menggunakan tingkat layanan lain di Azure SQL Database. Tingkat layanan Hyperscale mendukung berbagai beban kerja database, dari OLTP murni hingga analitik murni. Ini dioptimalkan untuk beban kerja OLTP serta pemrosesan transaksi dan analitik hibrid (HTAP).
Model harga Hyperscale
Catatan
Harga yang disederhanakan untuk Azure SQL Database Hyperscale telah tiba! Tinjau tingkat harga baru untuk pengumuman Azure SQL Database Hyperscale, dan untuk detail perubahan harga, lihat Azure SQL Database Hyperscale – harga yang lebih rendah dan disederhanakan!.
Tingkat layanan Hyperscale hanya tersedia dalam model vCore. Untuk menyelaraskan dengan arsitektur baru, model harga sedikit berbeda dari tingkatan layanan Tujuan Umum atau Bisnis Penting:
Komputasi yang disediakan:
Harga satuan komputasi Hyperscale adalah per replika. Pengguna mungkin menyesuaikan jumlah total replika sekunder dengan ketersediaan tinggi dari 0 hingga 4, tergantung pada persyaratan ketersediaan dan skalabilitas, dan membuat hingga 30 replika bernama untuk mendukung berbagai beban kerja peluasan skala baca.
Komputasi tanpa server:
Penagihan komputasi tanpa server didasarkan pada penggunaan. Untuk informasi selengkapnya, lihat Tingkat komputasi tanpa server untuk Azure SQL Database.
Penyimpanan:
Anda tidak perlu menentukan ukuran data maksimum saat mengonfigurasi database Hyperscale. Di tingkat Hyperscale, Anda dikenakan biaya penyimpanan untuk database Anda berdasarkan alokasi yang ada. Penyimpanan dialokasikan secara otomatis antara 10 GB dan 128 TB dan bertambah dalam kenaikan 10 GB sesuai kebutuhan.
Untuk informasi selengkapnya tentang harga Hyperscale, lihat Harga Azure SQL Database.
Arsitektur fungsi terdistribusi
Hyperscale memisahkan mesin pemrosesan kueri dari komponen yang menyediakan penyimpanan data dan daya tahan jangka panjang. Arsitektur ini memungkinkan Anda untuk menskalakan kapasitas penyimpanan dengan lancar sejauh yang diperlukan (hingga 128 TB), dan kemampuan untuk menskalakan sumber daya komputasi dengan cepat.
Diagram berikut mengilustrasikan arsitektur Hyperscale fungsional:
Pelajari selengkapnya tentang Arsitektur fungsi terdistribusi Hyperscale.
Keunggulan skala dan performa
Dengan kemampuan untuk dengan cepat menambah atau mengurangi node komputasi hanya-baca tambahan, arsitektur Hyperscale memungkinkan kapasitas skala baca yang signifikan dan juga dapat membebaskan node komputasi utama untuk melayani lebih banyak permintaan penulisan. Selain itu, simpul komputasi dapat diskalakan naik/turun dengan cepat karena arsitektur penyimpanan bersama arsitektur Hyperscale. Simpul komputasi baca-saja di Hyperscale juga tersedia di tingkat komputasi tanpa server, yang secara otomatis menskalakan komputasi berdasarkan permintaan beban kerja.
Ketersediaan tinggi database di Hyperscale
Seperti di semua tingkatan layanan lainnya, Hyperscale menjamin ketahanan data untuk transaksi yang dilakukan terlepas dari ketersediaan replika komputasi. Tingkat waktu henti karena replika primer menjadi tidak tersedia bergantung pada jenis failover (direncanakan vs. tidak direncanakan), apakah redundansi zona telah dikonfigurasi, dan pada keberadaan setidaknya satu replika dengan ketersediaan tinggi. Dalam failover yang direncanakan (seperti peristiwa pemeliharaan), sistem membuat replika utama baru sebelum memulai failover, atau menggunakan replika ketersediaan tinggi yang ada sebagai target failover. Dalam failover yang tidak direncanakan (seperti kegagalan perangkat keras pada replika utama), sistem menggunakan replika ketersediaan tinggi sebagai target failover jika ada, atau membuat replika utama baru dari kumpulan kapasitas komputasi yang tersedia. Dalam kasus terakhir, durasi waktu henti lebih lama karena adanya langkah tambahan yang diperlukan untuk membuat replika utama baru.
Anda dapat memilih jendela pemeliharaan yang memungkinkan Anda membuat peristiwa pemeliharaan yang berdampak dapat diprediksi dan kurang mengganggu beban kerja Anda.
Untuk Hyperscale SLA, lihat SLA untuk Azure SQL Database.
Kumpulan buffer, ekstensi kumpulan buffer yang tangguh, dan penyiapan berkelanjutan
Di Azure Database Hyperscale, ada pemisahan yang berbeda antara komputasi dan penyimpanan. Penyimpanan berisi semua halaman database dalam satu database, dan dapat dialokasikan melalui beberapa komputer saat database tumbuh. Namun, simpul komputasi hanya menyimpan cache apa yang digunakan baru-baru ini. Halaman terpanas dalam komputasi dipertahankan dalam memori dalam struktur yang disebut kumpulan buffer (BP). Ini juga disimpan di SSD lokal, ekstensi kumpulan buffer tangguh (RBPEX), sehingga data dapat diambil lebih cepat jika proses komputasi dimulai ulang.
Dalam sistem cloud, komputasi dapat berpindah ke komputer yang berbeda sesuai kebutuhan. Lapisan komputasi dapat memiliki beberapa replika. Satu adalah primer, dan menerima semua pembaruan, sementara yang lain adalah replika sekunder. Jika terjadi kegagalan utama, salah satu replika sekunder ketersediaan tinggi dapat dengan cepat dipromosikan ke primer dalam proses yang disebut failover. Replika sekunder mungkin tidak memiliki cache di BP dan RBPEX yang telah dioptimalkan untuk mendukung beban kerja utama.
Priming berkelanjutan adalah proses yang mengumpulkan informasi tentang halaman mana yang terpanas di semua replika komputasi. Informasi tersebut dikumpulkan, dan replika sekunder dengan ketersediaan tinggi menggunakan daftar halaman paling aktif yang sesuai dengan beban kerja tipikal pelanggan. Ini mengisi BP dan RBPEX dengan halaman terpanas secara terus-menerus, agar tetap sejalan dengan perubahan beban kerja pelanggan.
Tanpa persiapan berkelanjutan, baik BP maupun RBPEX tidak diwariskan oleh replika ketersediaan tinggi baru, dan hanya dibangun kembali selama beban kerja pengguna. Priming berkelanjutan menghemat waktu dan mencegah performa yang tidak konsisten, karena tidak ada penantian sebelum cache sepenuhnya terhidrasi lagi. Dengan priming berkelanjutan, replika sekunder ketersediaan tinggi baru akan segera mulai mem-priming BP dan RBPEX mereka. Ini akan membantu mempertahankan performa secara lebih konsisten saat failover terjadi.
Priming berkelanjutan bekerja dengan kedua cara: replika sekunder berketersediaan tinggi akan menyimpan halaman memori yang digunakan dalam replika utama, dan replika utama akan menyimpan halaman memori dengan beban kerja dari replika sekunder.
Catatan
Priming berkelanjutan saat ini dalam pratinjau terbatas dan tidak tersedia untuk basis data tanpa server. Untuk informasi selengkapnya dan untuk berpartisipasi dalam priming terus menerus, lihat Blog: Peningkatan Hyperscale November 2024.
Mencadangkan dan memulihkan
Operasi pencadangan dan pemulihan untuk database Hyperscale menggunakan file-snapshot. Hal ini memungkinkan operasi ini menjadi hampir spontan. Karena arsitektur Hyperscale menggunakan lapisan penyimpanan untuk pencadangan dan pemulihan, beban pemrosesan dan dampak performa ke replika komputasi berkurang. Pelajari selengkapnya di Pencadangan hyperscale dan redundansi penyimpanan.
Pemulihan bencana untuk database Hyperscale
Jika Anda perlu memulihkan database Hyperscale di Azure SQL Database ke wilayah selain yang saat ini dihosting, sebagai bagian dari operasi pemulihan bencana atau latihan, relokasi, atau alasan lain, metode utama adalah melakukan pemulihan geografis database. Pemulihan geografis hanya tersedia ketika penyimpanan redundan geografis (RA-GRS) dipilih untuk redundansi penyimpanan.
Pelajari selengkapnya dalam memulihkan database Hyperscale ke wilayah lain.
Membandingkan batas sumber daya
Tingkat layanan berbasis vCore dibedakan berdasarkan ketersediaan database, jenis penyimpanan, performa, dan ukuran penyimpanan maksimum. Perbedaan ini dijelaskan dalam tabel berikut:
| ㅤ | Tujuan Umum | Kritis Bisnis | Hyperscale |
|---|---|---|---|
| Pilihan terbaik untuk | Menawarkan opsi komputasi dan penyimpanan seimbang berorientasi anggaran. | Aplikasi OLTP dengan tingkat transaksi tinggi dan latensi I/O rendah. Menawarkan ketahanan tinggi terhadap kegagalan dan failover yang cepat dengan menggunakan beberapa replika siaga aktif. | Ragam beban kerja yang terluas. Ukuran penyimpanan penskalaan otomatis hingga 128 TB, penskalaan komputasi vertikal dan horizontal yang cepat, pemulihan database yang cepat. |
| Hitung ukuran | 2 hingga 128 vCore | 2 hingga 128 vCore | 2 hingga 128 vCore |
| Jenis penyimpanan | Penyimpanan jarak jauh premium (per instans) | Penyimpanan SSD lokal super cepat (per satuan) | Penyimpanan terpisah dengan cache SSD lokal (per replika komputasi) |
| Ukuran penyimpanan | 1 GB – 4 TB | 1 GB – 4 TB | 10 GB – 128 TB |
| IOPS | 320 IOPS per vCore dengan 16.000 IOPS maksimum | 4.000 IOPS per vCore dengan 327.680 IOPS maksimum | 327,680 IOPS dengan SSD lokal maksimum Hyperscale adalah arsitektur multi-tingkat dengan penyimpanan sementara pada berbagai level. IOPS yang efektif tergantung pada beban kerja. |
| Memori/vCore | 5,1 GB | 5,1 GB | 5,1 GB atau 10,2 GB |
| Ketersediaan | Satu replika, tanpa peluasan kapasitas pembacaan, ketersediaan tinggi dengan redundansi zona | Tiga replika, satu pembacaan scale-out, redundansi zona untuk Ketersediaan Tinggi (HA) | Beberapa replika, hingga empat baca scale-out, zona-redundan HA |
| Pencadangan | Pilihan penyimpanan redundan lokal (LRS), redundan zona (ZRS), atau redundan geografis (GRS) Retensi 1-35 hari (tujuh hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia |
Pilihan penyimpanan redundan lokal (LRS), redundan zona (ZRS), atau redundan geografis (GRS) Retensi 1-35 hari (tujuh hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia |
Pilihan penyimpanan redundan lokal (LRS), redundan zona (ZRS), atau redundan geografis (GRS) Retensi 1-35 hari (tujuh hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia |
| Harga/tagihan |
vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya. IOPS tidak dikenakan biaya. |
vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya. IOPS tidak dikenakan biaya. |
vCore pada setiap replika, penyimpanan data yang dialokasikan, dan penyimpanan cadangan akan dikenakan biaya. IOPS tidak dikenakan biaya. |
| Diskon model1 |
Instans Cadangan Azure Hybrid Benefit2 Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan |
Instans Cadangan Azure Hybrid Benefit2 Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan |
Instans Cadangan Azure Hybrid Benefit2 Enterprise dan Dev/Test Pay-As-You-Go penawaran langganan |
1 Harga yang disederhanakan untuk SQL Database Hyperscale tiba pada Desember 2023. Tinjau blog harga Hyperscale untuk mendapatkan detailnya.
2 Pada Desember 2023, Azure Hybrid Benefit tidak tersedia untuk database Hyperscale baru, atau dalam langganan dev/test. Database tunggal Hyperscale yang ada dengan komputasi yang disediakan dapat terus menggunakan Azure Hybrid Benefit untuk menghemat biaya komputasi hingga Desember 2026. Untuk informasi selengkapnya, tinjau blog tentang harga Hyperscale.
Sumber daya komputasi
| Konfigurasi perangkat keras | CPU | Memori |
|---|---|---|
| Seri Standar (Gen5) |
Komputasi yang dialokasikan - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) prosesor - Menyediakan hingga 80 vCore (hyper-threaded) Komputasi tanpa server - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) prosesor - Skala otomatis hingga 80 vCore (hyper-threaded) - Rasio memori-ke-vCore secara dinamis beradaptasi dengan memori dan penggunaan CPU berdasarkan permintaan beban kerja dan dapat setinggi 24 GB per vCore. Misalnya, pada suatu saat tertentu, beban kerja mungkin menggunakan dan ditagih untuk memori 240 GB dan hanya 10 vCores. |
Komputasi yang dialokasikan - 5,1 GB per vCore - Provisi hingga 625 GB Komputasi tanpa server - Skala otomatis hingga 24 GB per vCore - Skala otomatis maksimal hingga 240 GB |
| Seri premium | - Prosesor Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Menyediakan hingga 128 vCore (hyper-threaded) |
- 5,1 GB per vCore |
| Memori seri premium dioptimalkan | - Prosesor Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Menyediakan hingga 80 vCore (hyper-threaded) |
- 10.2 GB per vCore |
1 Dalam tampilan manajemen dinamis sys.dm_user_db_resource_governance , pembuatan perangkat keras untuk database yang menggunakan prosesor Intel® SP-8160 (Skylake) muncul sebagai Gen6, pembuatan perangkat keras untuk database menggunakan Intel® 8272CL (Cascade Lake) muncul sebagai Gen7, dan pembuatan perangkat keras untuk database menggunakan Intel® Xeon® Platinum 8370C (Ice Lake) atau AMD® EPYC® 7763v (Milan) muncul sebagai Gen8. Untuk ukuran komputasi dan konfigurasi perangkat keras tertentu, batas sumber daya sama terlepas dari jenis CPU. Untuk informasi selengkapnya, lihat batas sumber daya untuk database tunggal dan kumpulan elastis.
Serverless hanya didukung pada perangkat keras Seri Standar (Gen5).
Membuat dan mengelola database Hyperscale
Anda dapat membuat dan mengelola database Hyperscale menggunakan Portal Azure, T-SQL, PowerShell, dan Azure CLI. Untuk informasi selengkapnya, lihat Panduan Cepat: Membuat database Hyperscale.
| Operasi | Rincian | Pelajari lebih lanjut |
|---|---|---|
| Membuat database Hyperscale | Database Hyperscale hanya tersedia menggunakan model pembelian berbasis vCore. | Temukan contoh untuk membuat database Hyperscale di Mulai Cepat: Membuat database Hyperscale di Azure SQL Database. |
| Meningkatkan database yang ada ke Hyperscale | Melakukan migrasi database yang sudah ada di Azure SQL Database ke lapis Hyperscale adalah operasi data berskala besar. | Pelajari cara memigrasikan database yang ada ke Hyperscale. |
| Migrasi kembali database Hyperscale ke tier Layanan Umum | Jika sebelumnya Anda memigrasikan Azure SQL Database yang ada ke Hyperscale, Anda dapat memigrasikan kembali database ke tingkat layanan Tujuan Umum dalam waktu 45 hari dari migrasi asli ke Hyperscale. Jika Anda ingin memigrasikan database ke tingkat layanan lain, seperti Business Critical, lakukan migrasi balik terlebih dahulu ke tingkat layanan Tujuan Umum, lalu ubah tingkat layanan. |
Pelajari cara melakukan migrasi balik dari Hyperscale, termasuk batasan untuk migrasi balik. |
Keterbatasan
Ini adalah batasan saat ini untuk tingkat layanan Hyperscale. Kami berupaya aktif menghapus sebanyak mungkin batasan ini.
| Masalah | Deskripsi |
|---|---|
| Penyusutan diblokir ketika TDE dinonaktifkan | Saat ini, operasi penyusutan database dan file tidak didukung saat Transparent Data Encryption (TDE) dinonaktifkan di Azure SQL Database Hyperscale. |
| Memulihkan database dari tingkat layanan lain | Database non-Hyperscale tidak dapat dipulihkan menjadi database Hyperscale, dan database Hyperscale tidak dapat dipulihkan menjadi database non-Hyperscale. Untuk database yang dimigrasikan ke Hyperscale dari tingkat layanan Azure SQL Database lain, pencadangan pra-migrasi disimpan selama durasi periode retensi cadangan dari database sumber, termasuk kebijakan retensi jangka panjang. Memulihkan cadangan pra-migrasi dalam periode retensi cadangan database didukung melalui baris perintah. Anda dapat memulihkan cadangan ini ke tingkatan layanan non-Hyperscale. |
| Migrasi database dengan objek OLTP In-Memory | Hyperscale mendukung subset objek OLTP In-Memory, termasuk jenis tabel yang dioptimalkan memori, variabel tabel, dan modul yang dikompilasi secara asli. Namun, ketika ada objek OLTP Dalam Memori dalam database yang sedang dimigrasikan, migrasi dari tingkat layanan Premium dan Business Critical ke Hyperscale tidak didukung. Untuk memigrasikan database seperti itu ke Hyperscale, objek In-Memory OLTP dan dependensinya harus dihapus. Setelah database dimigrasikan, objek-objek ini dapat dibuat ulang. Tabel yang dioptimalkan memori, baik yang tahan lama maupun tidak tahan lama, saat ini tidak didukung di Hyperscale dan harus diubah menjadi tabel disk. |
| Pemeriksaan integritas basis data | DBCC CHECKDB saat ini tidak didukung untuk database Hyperscale. DBCC CHECKTABLE ('TableName') dengan TABLOCK dan DBCC CHECKFILEGROUP dengan TABLOCK mungkin dapat digunakan sebagai solusi. Lihat Integritas Data di Azure SQL Database untuk detail tentang manajemen integritas data di Azure SQL Database. |
| Pekerjaan Elastis | Menggunakan database Hyperscale sebagai database pekerjaan tidak didukung. Namun, pekerjaan elastis dapat menargetkan database Hyperscale dengan cara yang sama seperti database di Azure SQL Database lainnya. |
| Sinkronisasi Data | Menggunakan database Hyperscale sebagai database Hub atau Metadata Sinkronisasi tidak didukung. Namun, database Hyperscale dapat menjadi database anggota di topologi Sinkronisasi Data. |
| Perangkat keras seri premium pada lapisan layanan Hyperscale | Perangkat keras seri premium dan seri premium yang dioptimalkan memori saat ini tidak mendukung lapisan komputasi tanpa server. |
| Ketersediaan regional | Tingkat layanan Hyperscale seri premium dan perangkat keras seri premium yang dioptimalkan untuk memori tersedia di wilayah Azure yang terbatas. Untuk daftar, lihat Ketersediaan seri premium Hyperscale. |
Konten terkait
- Tanya jawab umum tentang Hyperscale
- Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database
- Manajemen sumber daya di Azure SQL Database
- Batas sumber daya untuk database tunggal yang menggunakan model pembelian vCore
- Perbandingan fitur: Azure SQL Database dan Azure SQL Managed Instance
- Arsitektur fungsi terdistribusi Hyperscale
- Cara mengelola database Hyperscale