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
- Hiperscale
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.
Catatan
- 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 memprovisikan satu replika baca-saja atau lebih untuk membongkar beban kerja baca dan digunakan sebagai siaga panas.
- Peningkatan skala otomatis, penurunan skala, dan penagihan untuk komputasi berdasarkan penggunaan dengan komputasi tanpa server.
- Harga/performa yang dioptimalkan untuk sekelompok database Hyperscale dengan berbagai tuntutan sumber daya dengan kumpulan elastis (dalam pratinjau).
- Penyimpanan penskalaan otomatis dengan dukungan hingga 100 TB database atau ukuran kumpulan elastis.
- Performa keseluruhan yang lebih tinggi karena throughput log transaksi yang lebih tinggi dan waktu penerapan transaksi yang lebih cepat dengan volume data berapa pun.
- Pencadangan database cepat (berdasarkan rekam jepret file) terlepas dari ukuran tanpa dampak I/O pada sumber daya komputasi.
- Pemulihan atau salinan database cepat (berdasarkan rekam jepret file) dalam 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 tentang dikotakkan 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 dan transaksi hibrid dan pemrosesan analitik (HTAP).
Catatan
Kumpulan elastis untuk Hyperscale saat ini dalam pratinjau.
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 secara otomatis dialokasikan antara 10 GB dan 100 TB dan tumbuh dalam kenaikan 10 GB sesuai kebutuhan.
Untuk informasi selengkapnya tentang harga Hyperscale, lihat Harga Azure SQL Database.
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 |
|---|---|---|---|
| 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 cepat menggunakan beberapa replika siaga panas. | Berbagai beban kerja terluas. Ukuran penyimpanan penskalaan otomatis hingga 100 TB, penskalaan komputasi vertikal dan horizontal yang cepat, pemulihan database yang cepat. |
| Ukuran komputasi | 2 hingga 128 vCore | 2 hingga 128 vCore | 2 hingga 128 vCore 1 |
| Jenis penyimpanan | Penyimpanan jarak jauh premium (per instans) | Penyimpanan SSD lokal super cepat (per instans) | Penyimpanan yang dipisahkan dengan cache SSD lokal (per replika komputasi) |
| Ukuran penyimpanan1 | 1 GB – 4 TB | 1 GB – 4 TB | 10 GB – 100 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 maks Hyperscale adalah arsitektur multi-tingkat dengan penembolokan di berbagai tingkatan. 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, tidak ada peluasan skala baca, ketersediaan tinggi zona-redundan | Tiga replika, satu read scale-out, zona-redundan HA | Beberapa replika, hingga empat baca scale-out, zona-redundan HA |
| Pencadangan | Pilihan penyimpanan redundan lokal (LRS), zona-redundan (ZRS), atau geo-redundan (GRS) Retensi 1-35 hari (tujuh hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia |
Pilihan penyimpanan redundan lokal (LRS), zona-redundan (ZRS), atau geo-redundan (GRS) Retensi 1-35 hari (tujuh hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia |
Pilihan penyimpanan redundan lokal (LRS), zona-redundan (ZRS), atau geo-redundan (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 untuk setiap replika, penyimpanan data yang dialokasikan, dan penyimpanan cadangan dikenakan biaya. IOPS tidak dikenakan biaya. |
| Modeldiskon 2 | Instans yang dipesan Azure Hybrid Benefit3 Langganan Pengembangan/Pengujian Enterprise dan PAYG |
Instans yang dipesan Azure Hybrid Benefit3 Langganan Pengembangan/Pengujian Enterprise dan PAYG |
Instans yang dipesan Azure Hybrid Benefit3 Langganan Pengembangan/Pengujian Enterprise dan PAYG |
1Gambaran umum kumpulan elastis Hyperscale di Azure SQL Database saat ini dalam pratinjau.
2 Harga yang disederhanakan untuk SQL Database Hyperscale tiba pada Desember 2023. Tinjau blog harga Hyperscale untuk detailnya.
3 Per 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 harga Hyperscale.
Sumber daya komputasi
| Konfigurasi perangkat keras | CPU | Memori |
|---|---|---|
| Seri Standar (Gen5) | Komputasi yang tersedia - 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 titik waktu tertentu, beban kerja mungkin menggunakan dan ditagih untuk memori 240 GB dan hanya 10 vCore. |
Komputasi yang tersedia - 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.
Tanpa server hanya didukung pada perangkat keras Seri Standar (Gen5).
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 (target awal adalah 100 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 memutar ke atas/bawah simpul komputasi baca-saja tambahan, arsitektur Hyperscale memungkinkan kemampuan skala baca yang signifikan dan juga dapat membebaskan simpul 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.
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 Mulai 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 tingkat Hyperscale adalah ukuran operasi data. | Pelajari cara memigrasikan database yang ada ke Hyperscale. |
| Membalikkan migrasi database Hyperscale ke tingkat layanan Tujuan Umum | Jika sebelumnya Anda memigrasikan Azure SQL Database yang ada ke tingkat layanan Hyperscale, Anda dapat membalikkan migrasi database ke tingkat layanan Tujuan Umum dalam waktu 45 hari sejak migrasi awal 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. |
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), baik redundansi zona dikonfigurasi atau tidak, dan pada keberadaan setidaknya satu replika high availability. 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.
Mencadangkan dan memulihkan
Operasi pencadangan dan pemulihan untuk database Hyperscale berbasis 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 untuk memulihkan database Hyperscale di Azure SQL Database ke wilayah selain database yang saat ini dihosting, sebagai bagian dari operasi pemulihan bencana atau latihan, relokasi, atau alasan lain, metode utamanya adalah melakukan pemulihan geo database. Pemulihan geografis hanya tersedia ketika penyimpanan geo-redundan (RA-GRS) telah dipilih untuk redundansi penyimpanan.
Pelajari selengkapnya dalam memulihkan database Hyperscale ke wilayah lain.
Pembatasan yang diketahui
Ini adalah batasan saat ini untuk tingkat layanan Hyperscale. Kami berupaya aktif menghapus sebanyak mungkin batasan ini.
| Masalah | Deskripsi |
|---|---|
| Memulihkan database dari tingkat layanan lain | Database non-Hyperscale tidak dapat dipulihkan sebagai database Hyperscale, dan database Hyperscale tidak dapat dipulihkan sebagai 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. |
| Kumpulan Elastis | Kumpulan elastis sekarang dalam pratinjau. |
| 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 OLTP In-Memory OLTP dan dependensinya harus dijatuhkan. Setelah database dimigrasikan, objek-objek ini dapat dibuat ulang. Tabel yang dioptimalkan memori tahan lama dan tidak tahan lama saat ini tidak didukung di Hyperscale dan harus diubah ke tabel disk. |
| Menyusutkan Database | DBCC SHRINKDATABASE, DBCC SHRINKFILE, atau mengatur AUTO_SHRINK ke AKTIF di tingkat database, saat ini tidak didukung untuk database Hyperscale. |
| Pemeriksaan integritas database | DBCC CHECKDB saat ini tidak didukung untuk database Hyperscale. DBCC CHECKTABLE ('TableName') DENGAN TABLOCK dan DBCC CHECKFILEGROUP DENGAN TABLOCK mungkin digunakan sebagai solusinya. Lihat Integritas Data di Azure SQL Database untuk detail tentang manajemen integritas data di Azure SQL Database. |
| Pekerjaan Elastis | Menggunakan database Hyperscale karena 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 Metadata Hub atau Sinkronisasi tidak didukung. Namun, database Hyperscale dapat menjadi database anggota di topologi Sinkronisasi Data. |
| Perangkat keras seri premium tingkat layanan Hyperscale | Perangkat keras seri premium dan seri premium yang dioptimalkan memori saat ini tidak mendukung tingkat komputasi tanpa server. |
| Ketersediaan regional | Seri premium tingkat layanan Hyperscale dan perangkat keras yang dioptimalkan memori seri premium tersedia di wilayah Azure 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
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk