model pembelian vCore - Azure SQL Database

Berlaku untuk: Azure SQL Database

• Azure SQL Database
• Instans Terkelola Azure SQL

Artikel ini meninjau model pembelian vCore untuk Azure SQL Database.

Gambaran Umum

Virtual core (vCore) mewakili CPU logis dan menawarkan opsi untuk memilih karakteristik fisik perangkat keras (misalnya, jumlah core, memori, dan ukuran penyimpanan). Model pembelian berbasis vCore memberi Anda fleksibilitas, kontrol, transparansi penggunaan sumber daya individu, dan cara mudah untuk menerjemahkan persyaratan beban kerja lokal ke cloud. Model ini mengoptimalkan harga, dan memungkinkan Anda memilih sumber daya komputasi, memori, dan penyimpanan berdasarkan kebutuhan beban kerja Anda.

Dalam model pembelian berbasis vCore, biaya Anda bergantung pada pilihan dan penggunaan:

• Tingkat layanan
• Konfigurasi perangkat keras
• Sumber daya komputasi (jumlah vCores dan jumlah memori)
• Penyimpanan database yang dicadangkan
• Penyimpanan cadangan aktual

Penting

Sumber daya komputasi, I/O, dan penyimpanan data dan log dikenakan biaya per database atau kumpulan elastis. Penyimpanan Microsoft Azure Backup dibebankan per setiap database. Untuk detail harga, lihat halaman harga Azure SQL Database.

Membandingkan model pembelian vCore dan DTU

Model pembelian vCore yang digunakan oleh Azure SQL Database memberikan beberapa manfaat atas model pembelian berbasis DTU:

• Komputasi, memori, I/O, dan batas penyimpanan yang lebih tinggi.
• Pilihan konfigurasi perangkat keras agar lebih sesuai dengan persyaratan komputasi dan memori beban kerja.
• Diskon harga untuk Azure Hybrid Benefit (AHB).
• Transparansi yang lebih besar dalam detail perangkat keras yang mendukung komputasi, yang memfasilitasi perencanaan migrasi dari penyebaran lokal.
• Harga instans yang dipesan hanya tersedia untuk model pembelian vCore.
• Skala granularitas yang lebih tinggi dengan beberapa ukuran komputasi tersedia.

Untuk bantuan dalam memilih antara model pembelian vCore dan DTU, lihat perbedaan antara model pembelian berbasis vCore dan DTU

Compute

Model pembelian berbasis vCore memiliki tingkat komputasi yang disediakan dan tingkat komputasi tanpa server. Di tingkat komputasi yang diprovisikan, biaya komputasi mencerminkan total kapasitas komputasi berkelanjutan yang ditentukan untuk aplikasi terpisah dari aktivitas beban kerja. Pilih alokasi sumber daya yang paling sesuai dengan kebutuhan bisnis Anda berdasarkan vCore dan persyaratan memori, lalu tambah atau kurangi sumber daya sesuai kebutuhan beban kerja Anda. Di tingkat komputasi tanpa server untuk Azure SQL Database, sumber daya komputasi diskalakan otomatis berdasarkan kapasitas beban kerja dan ditagih untuk jumlah komputasi yang digunakan, per detik.

Untuk meringkas:

• Sementara tingkat komputasi yang disediakan menyediakan sejumlah sumber daya komputasi tertentu yang terus disediakan secara independen dari aktivitas beban kerja, tingkat komputasi tanpa server menskalakan sumber daya komputasi berdasarkan aktivitas beban kerja.
• Saat tingkat komputasi tersedia ditagih berdasarkan komputasi yang disediakan dengan harga tetap per jam, tingkatan komputasi server ditagih berdasarkan jumlah komputasi, per jam.

Terlepas dari tingkat komputasi, tiga replika sekunder ketersediaan tinggi tambahan secara otomatis dialokasikan di tingkat layanan Business Critical untuk memberikan ketahanan tinggi terhadap kegagalan dan failover cepat. Replika tambahan ini membuat biaya sekitar 2,7 kali lebih tinggi daripada di tingkat layanan Tujuan Umum. Demikian juga, biaya penyimpanan yang lebih tinggi per GB di tingkat layanan Business Critical mencerminkan batas IO yang lebih tinggi dan latensi penyimpanan SSD lokal yang lebih rendah.

Di Hyperscale, pelanggan mengontrol jumlah replika ketersediaan tinggi tambahan dari 0 hingga 4 untuk mendapatkan tingkat ketahanan yang diperlukan oleh aplikasi mereka sambil mengontrol biaya.

Untuk informasi selengkapnya tentang komputasi di Azure SQL Database, lihat Sumber daya komputasi (CPU dan memori).

Batas Sumber Daya

Untuk batas sumber daya vCore, tinjau konfigurasi Perangkat Keras yang tersedia, lalu tinjau batas sumber daya untuk:

• server logis
• database tunggal
• database dalam kumpulan elastis

Penyimpanan data dan log

Faktor-faktor berikut memengaruhi jumlah penyimpanan yang digunakan untuk data dan file log, dan berlaku untuk Tujuan Umum dan Kritis Bisnis.

• Setiap ukuran komputasi mendukung ukuran data maksimum yang dapat dikonfigurasi, dengan nilai default 32 GB.
• Saat Anda mengonfigurasi ukuran data maksimum, tambahan 30 persen penyimpanan yang dapat ditagih secara otomatis ditambahkan untuk file log.
• Di tingkat layanan Tujuan Umum, tempdb menggunakan penyimpanan SSD lokal, dan biaya penyimpanan ini sudah termasuk dalam harga vCore.
• Di tingkat layanan Kritis Bisnis, tempdb berbagi penyimpanan SSD lokal dengan data dan file log, dan biaya penyimpanan tempdb sudah termasuk dalam harga vCore.
• Di tingkat Tujuan Umum dan Bisnis Penting, Anda dikenakan biaya untuk ukuran penyimpanan maksimum yang dikonfigurasi untuk database atau kumpulan elastis.
• Untuk SQL Database, Anda dapat memilih ukuran data maksimum antara 1 GB dan ukuran penyimpanan yang didukung maksimum, dalam kenaikan 1 GB.

Pertimbangan penyimpanan berikut berlaku untuk Hyperscale:

• Ukuran penyimpanan data maksimum diatur ke 100 TB dan tidak dapat dikonfigurasi.
• Anda hanya dikenakan biaya untuk penyimpanan data yang dialokasikan, bukan untuk penyimpanan data maksimum.
• Anda tidak dikenakan biaya untuk penyimpanan log.
• tempdb menggunakan penyimpanan SSD lokal, dan biayanya termasuk dalam harga vCore. Untuk memantau ukuran penyimpanan data yang dialokasikan dan digunakan saat ini di SQL Database, gunakan metrik Azure Monitor allocated_data_storage dan storage sesuai urutan.

Untuk memantau ukuran penyimpanan data individual dan file log yang dialokasikan dan digunakan saat ini dalam database dengan menggunakan T-SQL, gunakan tampilan sys.database_files dan fungsi FILEPROPERTY(... , 'SpaceUsed').

Tip

Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi lebih lanjut, lihat Mengelola ruang file di Azure SQL Database.

Penyimpanan cadangan

Penyimpanan untuk cadangan database dialokasikan untuk mendukung kemampuan pemulihan titik waktu (PITR) dan retensi jangka panjang (LTR) SQL Database. Penyimpanan ini terpisah dari penyimpanan data dan file log, dan ditagih secara terpisah.

• PITR:Di tingkat General Purpose dan Business Critical, tiap-tiap pencadangan database disalin ke penyimpanan Azure secara otomatis. Ukuran penyimpanan meningkat secara dinamis saat cadangan baru dibuat. Penyimpanan digunakan oleh pencadangan penuh, diferensial, dan log transaksi. Konsumsi penyimpanan tergantung pada tingkat perubahan database dan periode penyimpanan yang dikonfigurasi untuk pencadangan. Anda dapat mengonfigurasi periode retensi terpisah untuk setiap database antara 1 dan 35 hari untuk SQL Database. Jumlah penyimpanan cadangan yang sama dengan ukuran data maksimum yang dikonfigurasi disediakan tanpa biaya tambahan.
• LTR: Anda juga dapat mengonfigurasi retensi jangka panjang pencadangan penuh hingga 10 tahun. Jika Anda menyiapkan kebijakan LTR, cadangan ini disimpan dalam penyimpanan Azure Blob secara otomatis, tetapi Anda dapat mengontrol seberapa sering cadangan disalin. Untuk memenuhi persyaratan kepatuhan yang berbeda, Anda dapat memilih periode retensi yang berbeda untuk pencadangan mingguan, bulanan, dan/atau tahunan. Konfigurasi yang Anda pilih menentukan berapa banyak penyimpanan yang digunakan untuk pencadangan LTR. Untuk mengetahui informasi selengkapnya, lihat Retensi cadangan jangka panjang.

Untuk penyimpanan cadangan di Hyperscale, lihat Pencadangan otomatis untuk database Hyperscale.

Tingkat layanan

Opsi tingkat layanan dalam model pembelian vCore mencakup Tujuan Umum, Keperluan Bisnis, dan Hyperscale. Tingkat layanan umumnya menentukan jenis dan performa penyimpanan, ketersediaan tinggi dan opsi pemulihan bencana, dan ketersediaan fitur tertentu seperti OLTP Dalam Memori.

Gunakan huruf besar	Tujuan Umum	Kritis Bisnis	Hyperscale
Terbaik untuk	Sebagian besar beban kerja bisnis. Menawarkan opsi komputasi dan penyimpanan yang berorientasi anggaran, seimbang, dan dapat diskalakan.	Menawarkan aplikasi bisnis ketahanan tertinggi terhadap kegagalan dengan menggunakan beberapa replika sekunder ketersediaan tinggi, dan memberikan performa I/O tertinggi.	Berbagai beban kerja terluas, termasuk beban kerja tersebut dengan penyimpanan yang sangat dapat diskalakan dan persyaratan skala baca. Menawarkan ketahanan yang lebih tinggi terhadap kegagalan dengan memungkinkan konfigurasi lebih dari satu replika sekunder ketersediaan tinggi.
Ukuran komputasi	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 instans)	Penyimpanan yang dipisahkan dengan cache SSD lokal (per replika komputasi)
Ukuran penyimpanan	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
Pencadangan	Pilihan penyimpanan cadangan geo-redundan, zona-redundan, atau redundan secara lokal, retensi 1-35 hari (default 7 hari) Retensi jangka panjang tersedia hingga 10 tahun	Pilihan penyimpanan cadangan geo-redundan, zona-redundan, atau redundan secara lokal, retensi 1-35 hari (default 7 hari) Retensi jangka panjang tersedia hingga 10 tahun	Pilihan penyimpanan redundan lokal (LRS), zona-redundan (ZRS), atau geo-redundan (GRS) Retensi 1-35 hari (7 hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia
Ketersediaan	Satu replika, tidak ada replika skala baca, ketersediaan tinggi zona-redundan (HA)	Tiga replika, satu replika skala baca, ketersediaan tinggi zona-redundan (HA)	ketersediaan tinggi zona-redundan (HA)
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 dan penyimpanan yang digunakan dikenai biaya. IOPS tidak dikenakan biaya.
Model diskon	Instans yang dipesan Keuntungan Azure Hibrida (tidak tersedia pada langganan pengembangan/pengujian) Langganan penawaran Dev/Test Enterprise dan Pay-As-You-Go	Instans yang dipesan Keuntungan Azure Hibrida (tidak tersedia pada langganan pengembangan/pengujian) Langganan penawaran Dev/Test Enterprise dan Pay-As-You-Go	Azure Hybrid Benefit (tidak tersedia pada langganan dev/test) 1 Langganan penawaran Dev/Test Enterprise dan Pay-As-You-Go
Tabel OLTP dalam memori	Tidak	Ya	Tidak

¹ Harga yang disederhanakan untuk SQL Database Hyperscale segera hadir. Tinjau blog harga Hyperscale untuk detailnya.

Untuk detail yang lebih jelas, tinjau batas sumber daya untuk server logika, database tunggal, dan database kumpulan.

Catatan

Untuk informasi selengkapnya tentang Perjanjian SLA, lihat SLA untuk Azure SQL Database

Tujuan Umum

Model arsitektur untuk tingkat layanan Tujuan Umum didasarkan pada pemisahan komputasi dan penyimpanan. Model arsitektur ini bergantung pada ketersediaan tinggi dan keandalan penyimpanan Azure Blob yang secara transparan mereplikasi file database dan menjamin tidak ada kehilangan data jika kegagalan infrastruktur yang mendasar terjadi.

Gambar berikut menunjukkan empat node dalam model arsitektur standar dengan lapisan komputasi dan penyimpanan yang dipisahkan.

Dalam model arsitektur untuk tingkat layanan Tujuan Umum, ada dua lapisan:

• Lapisan komputasi stateless yang menjalankan sqlservr.exe proses dan hanya berisi data sementara dan cache (misalnya – cache paket, kumpulan buffer, kumpulan penyimpan kolom). Stateless node ini dioperasikan oleh Microsoft Azure Service Fabric yang menginisialisasi proses, mengontrol kondisi node, dan melakukan failover ke tempat lain jika perlu.
• Lapisan stateful data dengan file database (.mdf/.ldf) yang disimpan dalam penyimpanan Azure Blob. Penyimpanan Azure Blob menjamin bahwa tidak ada kehilangan data dari rekaman apa pun yang ditempatkan dalam file database apa pun. Azure Storage memiliki ketersediaan/redundansi data bawaan yang memastikan bahwa setiap rekaman dalam file log atau halaman dalam file data dipertahankan meskipun prosesnya crash.

Setiap kali mesin database atau sistem operasi ditingkatkan, beberapa bagian dari infrastruktur yang mendasar gagal, atau jika beberapa masalah penting terdeteksi dalam sqlservr.exe proses, Azure Service Fabric memindahkan proses stateless ke simpul komputasi stateless lainnya. Ada sekumpulan simpul cadangan yang menunggu untuk menjalankan layanan komputasi baru jika failover node utama terjadi untuk meminimalkan waktu failover. Data di lapisan penyimpanan Azure tidak terpengaruh, dan file data/log dilampirkan ke proses yang baru diinisialisasi. Proses ini menjamin ketersediaan 99,99% secara default dan ketersediaan 99,995% ketika redundansi zona diaktifkan. Mungkin ada beberapa dampak performa pada beban kerja berat yang sedang dalam penerbangan karena waktu transisi dan fakta bahwa simpul baru dimulai dengan cache dingin.

Kapan memilih tingkat layanan ini

Tingkat layanan Tujuan Umum adalah tingkat layanan default di Azure SQL Database yang dirancang untuk sebagian besar beban kerja generik. Jika Anda memerlukan mesin database yang dikelola sepenuhnya dengan SLA default dan latensi penyimpanan antara 5 ms dan 10 ms, tingkat Tujuan Umum adalah opsi untuk Anda.

Kritis Bisnis

Model tingkat layanan Bisnis Kritis didasarkan pada kluster proses mesin database. Model arsitektur ini bergantung pada kuorum simpul mesin database untuk meminimalkan dampak performa pada beban kerja Anda, bahkan selama aktivitas pemeliharaan. Peningkatan dan patch sistem operasi, driver, dan mesin database yang mendasar terjadi secara transparan, dengan waktu henti minimal untuk pengguna akhir.

Dalam model Business Critical, komputasi dan penyimpanan terintegrasi pada setiap simpul. Replikasi data antara proses mesin database pada setiap simpul kluster empat node mencapai ketersediaan tinggi, dengan setiap simpul menggunakan SSD yang terpasang secara lokal sebagai penyimpanan data. Diagram berikut menunjukkan bagaimana tingkat layanan Business Critical mengatur kluster simpul mesin database dalam replika grup ketersediaan.

Baik proses mesin database maupun file .mdf/.ldf yang mendasar ditempatkan pada node yang sama dengan penyimpanan SSD yang terpasang secara lokal, memberikan latensi rendah pada beban kerja Anda. Ketersediaan tinggi diimplementasikan menggunakan teknologi yang mirip dengan Grup Ketersediaan AlwaysOn SQL Server. Setiap database adalah kluster simpul database dengan satu replika utama yang dapat diakses untuk beban kerja pelanggan, dan tiga replika sekunder yang berisi salinan data. Replika utama terus-menerus mendorong perubahan ke replika sekunder untuk memastikan data tersedia pada replika sekunder jika primer gagal karena alasan apa pun. Failover ditangani oleh Service Fabric dan mesin database – satu replika sekunder menjadi replika utama, dan replika sekunder baru dibuat untuk memastikan ada cukup node dalam kluster. Beban kerja secara otomatis dialihkan ke replika utama baru.

Selain itu, kluster Business Critical memiliki kemampuan Read Scale-Out bawaan yang menyediakan replika baca-saja gratis yang digunakan untuk menjalankan kueri baca-saja (seperti laporan) yang tidak akan memengaruhi performa beban kerja pada replika utama Anda.

Kapan memilih tingkat layanan ini

Tingkat layanan Business Critical dirancang untuk aplikasi yang memerlukan respons latensi rendah dari penyimpanan SSD yang mendasarinya (rata-rata 1-2 ms), pemulihan yang lebih cepat jika infrastruktur yang mendasarinya gagal, atau perlu melepas beban laporan, analitik, dan kueri baca-saja ke bebas biaya replika sekunder yang dapat dibaca dari database utama.

Alasan kunci mengapa Anda harus memilih tingkat layanan Bisnis Kritis dan bukan tingkat Tujuan Umum adalah:

• Persyaratan latensi I/O rendah – beban kerja yang membutuhkan respons cepat secara konsisten dari lapisan penyimpanan (rata-rata 1-2 milidetik) harus menggunakan tingkat Business Critical.
• Beban kerja dengan kueri pelaporan dan analitik di mana satu replika baca-saja sekunder gratis sudah cukup.
• Ketahanan yang lebih tinggi dan pemulihan yang lebih cepat atas kegagalan. Jika ada kegagalan sistem, database pada instans utama dinonaktifkan dan salah satu replika sekunder segera menjadi database utama baca-tulis baru, siap untuk memproses kueri.
• Perlindungan kerusakan data tingkat lanjut. Karena tingkat Business Critical menggunakan replika database di belakang layar, layanan menggunakan perbaikan halaman otomatis yang tersedia dengan pencerminan dan grup ketersediaan untuk membantu mengurangi kerusakan data. Jika replika tidak dapat membaca halaman karena masalah integritas data, salinan baru halaman diambil dari replika lain, menggantikan halaman yang tidak dapat dibaca tanpa kehilangan data atau waktu henti pelanggan. Fungsionalitas ini tersedia di tingkat Tujuan Umum jika database memiliki replika geo-sekunder.
• Ketersediaan yang lebih tinggi - Tingkat Bisnis Penting dalam konfigurasi zona multi-ketersediaan memberikan ketahanan terhadap kegagalan zonal dan SLA ketersediaan yang lebih tinggi.
• Pemulihan geografis cepat - Saat replikasi geografis aktif dikonfigurasi, tingkat Bisnis Penting memiliki Tujuan Titik Pemulihan (RPO) yang terjamin selama 5 detik dan Tujuan Waktu Pemulihan (RTO) selama 30 detik untuk 100% dari jam yang disebarkan.

Hyperscale

Tingkat layanan Hyperscale cocok untuk semua jenis beban kerja. Arsitektur asli cloud-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 mempelajari lebih lanjut, tinjau Tingkat layanan Hyperscale untuk Azure SQL Database.

Kapan memilih tingkat layanan ini

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 penyimpanan yang fleksibel, database Hyperscale tumbuh sesuai kebutuhan - dan Anda hanya ditagih untuk kapasitas penyimpanan yang Anda gunakan.

Selain kemampuan penskalaannya yang canggih, Hyperscale adalah opsi yang bagus untuk beban kerja apa pun, bukan hanya untuk database besar. Dengan Hyperscale, Anda dapat:

• Mencapai ketahanan tinggi dan pemulihan kegagalan yang cepat sambil mengontrol biaya, dengan memilih jumlah replika ketersediaan tinggi dari 0 hingga 4.
• Tingkatkan ketersediaan tinggi dengan mengaktifkan redundansi zona untuk komputasi dan penyimpanan.
• Mencapai latensi I/O rendah (rata-rata 1-2 milidetik) untuk bagian database Anda yang sering diakses. Untuk database yang lebih kecil, ini mungkin berlaku untuk seluruh database.
• Terapkan berbagai skenario peluasan skala baca dengan replika bernama.
• Manfaatkan penskalaan cepat, tanpa menunggu data disalin ke penyimpanan lokal pada simpul baru.
• Nikmati pencadangan database berkelanjutan tanpa dampak dan pemulihan cepat.
• Mendukung persyaratan kelangsungan bisnis dengan menggunakan grup failover dan replikasi geografis.

Konfigurasi perangkat keras

Konfigurasi perangkat keras umum dalam model vCore mencakup seri standar (Gen5), seri Fsv2, dan seri DC. Hyperscale juga menyediakan opsi untuk perangkat keras seri premium dan memori seri premium yang dioptimalkan. Konfigurasi perangkat keras mendefinisikan batas komputasi dan memori serta karakteristik lain yang memengaruhi performa beban kerja.

Konfigurasi perangkat keras tertentu seperti seri standar (Gen5) dapat menggunakan lebih dari satu jenis prosesor (CPU), seperti yang dijelaskan dalam sumber daya Komputasi (CPU dan memori). Meskipun database atau kumpulan elastis tertentu cenderung tetap berada di perangkat keras dengan jenis CPU yang sama untuk waktu yang lama (biasanya selama beberapa bulan), ada peristiwa tertentu yang dapat menyebabkan database atau kumpulan dipindahkan ke perangkat keras yang menggunakan jenis CPU yang berbeda.

Database atau kumpulan dapat dipindahkan untuk berbagai skenario, termasuk tetapi tidak terbatas pada kapan:

• Tujuan layanan diubah
• Infrastruktur saat ini di pusat data mendekati batas kapasitas
• Perangkat keras yang saat ini digunakan sedang dinonaktifkan karena akhir masa pakainya
• Konfigurasi zona-redundan diaktifkan, pindah ke perangkat keras yang berbeda karena kapasitas yang tersedia

Untuk beberapa beban kerja, perpindahan ke jenis CPU yang berbeda dapat mengubah performa. SQL Database mengonfigurasi perangkat keras dengan tujuan untuk memberikan performa beban kerja yang dapat diprediksi bahkan jika jenis CPU berubah, menjaga perubahan performa dalam rentang yang sempit. Namun, di seluruh spektrum beban kerja pelanggan yang luas di SQL Database, dan saat jenis CPU baru tersedia, terkadang mungkin untuk melihat perubahan performa yang lebih nyata, jika database atau kumpulan berpindah ke jenis CPU yang berbeda.

Terlepas dari jenis CPU yang digunakan, batas sumber daya untuk database atau kumpulan elastis (seperti jumlah inti, memori, IOPS data maks, laju log maks, dan pekerja bersamaan maks) tetap sama selama database tetap pada tujuan layanan yang sama.

Sumber daya komputasi (CPU dan memori)

Tabel berikut membandingkan sumber daya komputasi dalam konfigurasi perangkat keras dan tingkat komputasi yang berbeda:

Konfigurasi perangkat keras	CPU	Memori
Seri Standar (Gen5)	Komputasi yang tersedia - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, prosesor AMD EPYC 7763v (Milan) - Menyediakan hingga 128 vCore (hyper-threaded) Komputasi tanpa server - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, prosesor AMD EPYC 7763v (Milan) - 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 dapat digunakan 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 Fsv2	- Prosesor Intel® 8168 (Skylake) - Menampilkan kecepatan jam turbo semua inti berkelanjutan sebesar 3,4 GHz dan kecepatan jam turbo core tunggal maksimum 3,7 GHz. - Menyediakan hingga 72 vCore (hyper-threaded)	- 1,9 GB per vCore - Ketentuan hingga 136 GB
Seri DC	- Prosesor Intel® Xeon® E-2288G - Menampilkan Intel Software Guard Extension (Intel SGX) - Menyediakan hingga 8 vCore (fisik)	4.5 GB per vCore

* 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 yang 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 (Intel Broadwell, Skylake, Ice Lake, Cascade Lake, atau AMD Milan).

Untuk informasi selengkapnya, lihat batas sumber daya untuk database tunggal dan kumpulan elastis.

Untuk sumber daya dan spesifikasi komputasi database Hyperscale, lihat Sumber daya komputasi Hyperscale.

Seri Standar (Gen5)

• Perangkat keras seri standar (Gen5) menyediakan sumber daya komputasi dan memori yang seimbang, dan cocok untuk sebagian besar beban kerja database.

Perangkat keras seri standar (Gen5) tersedia di semua wilayah publik di seluruh dunia.

Seri premium Hyperscale

• Opsi perangkat keras seri premium menggunakan teknologi CPU dan memori terbaru dari Intel dan AMD. Seri premium memberikan dorongan terhadap performa komputasi relatif terhadap perangkat keras seri standar.
• Opsi seri premium menawarkan performa CPU yang lebih cepat dibandingkan dengan seri Standar dan jumlah vCore maksimum yang lebih tinggi.
• Opsi memori seri premium yang dioptimalkan menawarkan jumlah memori dua kali lipat relatif terhadap seri Standar.
• Memori seri standar, seri premium, dan seri premium yang dioptimalkan tersedia untuk kumpulan elastis Hyperscale.

Untuk informasi selengkapnya, lihat pengumuman blog seri premium Hyperscale.

Untuk wilayah yang tersedia, lihat Ketersediaan seri premium Hyperscale.

Seri Fsv2

• Seri Fsv2 adalah konfigurasi perangkat keras komputasi yang dioptimalkan yang memberikan latensi CPU rendah dan kecepatan jam tinggi untuk beban kerja yang paling banyak menggunakan CPU. Mirip dengan konfigurasi perangkat keras hyperscale seri premium, seri Fsv2 didukung oleh teknologi CPU dan memori terbaru dari Intel dan AMD, memungkinkan pelanggan untuk memanfaatkan perangkat keras terbaru saat menggunakan database dan kumpulan elastis di tingkat layanan Tujuan Umum.
• Bergantung pada beban kerja, seri Fsv2 dapat memberikan lebih banyak performa CPU per vCore daripada jenis perangkat keras lainnya. Misalnya, ukuran komputasi 72 vCore Fsv2 dapat memberikan lebih banyak performa CPU daripada 80 vCore pada seri Standar (Gen5), dengan biaya lebih rendah.
• Fsv2 menyediakan lebih sedikit memori dan tempdb per vCore daripada perangkat keras lainnya, sehingga beban kerja yang sensitif terhadap batas tersebut mungkin berkinerja lebih baik pada seri standar (Gen5).

Seri Fsv2 hanya didukung di tingkat General Purpose. Untuk wilayah di mana seri Fsv2 tersedia, lihat Ketersediaan seri Fsv2.

Seri DC

• Perangkat keras seri DC menggunakan prosesor Intel dengan teknologi Software Guard Extensions (Intel SGX).
• Seri DC diperlukan untuk Always Encrypted dengan beban kerja enklave aman yang memerlukan perlindungan keamanan enklave perangkat keras yang lebih kuat, dibandingkan dengan enklave Keamanan berbasis Virtualisasi (VBS).
• Seri DC dirancang untuk beban kerja yang memproses data sensitif dan menuntut kemampuan pemrosesan kueri rahasia, yang disediakan oleh Always Encrypted dengan enclave yang aman.
• Perangkat keras seri DC menyediakan sumber daya komputasi dan memori yang seimbang.

Seri DC hanya didukung untuk Komputasi yang disediakan (Tanpa Server tidak didukung) dan tidak mendukung redundansi zona. Untuk wilayah di mana seri DC tersedia, lihat Ketersediaan seri DC.

Jenis penawaran Azure yang didukung oleh seri DC

Untuk membuat database atau kumpulan elastis pada perangkat keras seri DC, langganan harus merupakan jenis penawaran berbayar termasuk PAYG atau Perjanjian Enterprise (EA). Untuk daftar lengkap jenis penawaran Azure yang didukung oleh seri DC, lihat penawaran saat ini tanpa batas pengeluaran.

Pilih konfigurasi perangkat keras

Anda dapat memilih konfigurasi perangkat keras untuk database atau kumpulan elastis di SQL Database pada saat pembuatan. Anda juga dapat mengubah konfigurasi perangkat keras database atau kumpulan elastis yang ada.

Untuk memilih konfigurasi perangkat keras saat membuat SQL Database atau kumpulan

Untuk informasi selengkapnya, lihat Membuat SQL Database.

Pada tab Dasar-dasar, pilih tautan Konfigurasikan database di bagian Komputasi + penyimpanan, lalu pilih tautan Ubah konfigurasi:

Pilih konfigurasi perangkat keras yang diinginkan:

Untuk mengubah konfigurasi perangkat keras dari SQL Database atau kumpulan yang sudah ada

Untuk database, pada halaman Ringkasan, pilih tautan tingkat Harga:

Untuk kumpulan, pada halaman Gambaran Umum , pilih Konfigurasikan.

Ikuti langkah-langkah untuk mengubah konfigurasi, dan pilih konfigurasi perangkat keras seperti yang dijelaskan di langkah sebelumnya.

Ketersediaan perangkat keras

Untuk informasi tentang perangkat keras generasi sebelumnya, lihat Ketersediaan perangkat keras generasi sebelumnya.

Seri Standar (Gen5)

Perangkat keras seri standar (Gen5) tersedia di semua wilayah publik di seluruh dunia.

Seri premium Hyperscale

Perangkat keras seri premium tingkat layanan Hyperscale dan perangkat keras yang dioptimalkan memori seri premium tersedia untuk database tunggal dan kumpulan elastis di wilayah berikut:

• Australia Timur **
• Australia Tenggara
• Brasil Selatan **
• Kanada Tengah **
• Kanada Timur
• Asia Timur
• Eropa Utara **
• Eropa Barat **
• Prancis Tengah
• Jerman Barat Tengah
• India Tengah
• India Selatan
• Jepang Timur **
• Jepang Barat
• Asia Tenggara**
• Swiss Utara
• Swedia Tengah **,*
• UK Selatan **
• UK Barat *
• AS Tengah **
• US Timur **
• AS Timur 2 **
• Tengah Utara AS
• Tengah Selatan AS
• Barat Sentral AS
• AS Barat 1
• AS Barat 2 **
• AS Barat 3 **

* Perangkat keras yang dioptimalkan memori seri premium saat ini tidak tersedia.

** Termasuk dukungan untuk redundansi zona.

Seri Fsv2

Seri Fsv2 tersedia di wilayah berikut:

• Australia Tengah
• Australia Tengah 2
• Australia Timur
• Australia Tenggara
• Brasil Selatan
• Kanada Tengah
• Asia Timur
• Eropa Utara
• Eropa Barat
• Prancis Tengah
• India Tengah
• Korea Tengah
• Korea Selatan
• Afrika Selatan Utara
• Asia Tenggara
• UK Selatan
• UK Barat
• US Timur
• AS Barat 2

Seri DC

Seri DC tersedia di wilayah berikut:

• Kanada Tengah
• Eropa Barat
• Eropa Utara
• Asia Tenggara
• UK Selatan
• Barat AS
• US Timur

Jika Anda memerlukan seri DC di wilayah yang saat ini tidak didukung, kirimkan permintaan dukungan. Di halaman Dasar, sediakan hal-hal berikut:

1. Untuk Jenis masalah, pilih Teknis.
2. Berikan langganan yang diinginkan untuk perangkat keras. Pilih Selanjutnya.
3. Untuk Jenis layanan, pilih Azure SQL Database.
4. Untuk Sumber Daya, pilih Pertanyaan umum.
5. Untuk Ringkasan, berikan ketersediaan dan wilayah perangkat keras yang diinginkan.
6. Untuk Jenis masalah, pilih Keamanan, Privat, dan Kepatuhan.
7. Untuk Subjenis masalah, pilih Selalu Dienkripsi.

Perangkat keras generasi sebelumnya

Gen4

Perangkat keras Gen4 telah dihentikan dan tidak tersedia untuk provisi, peningkatan, atau penurunan skala. Migrasikan database Anda ke pembuatan perangkat keras yang didukung untuk berbagai vCore dan skalabilitas penyimpanan yang lebih luas, jaringan terakselerasi, performa IO terbaik, dan latensi minimal. Tinjau opsi perangkat keras untuk database tunggal dan opsi perangkat keras untuk kumpulan elastis. Untuk informasi selengkapnya, lihat Dukungan telah berakhir untuk perangkat keras Gen 4 di Azure SQL Database.

Langkah selanjutnya

Mulai cepat: Membuat database tunggal - Azure SQL Database

Konten terkait

• Halaman harga Azure SQL Database
• Batas sumber daya untuk database tunggal yang menggunakan model pembelian vCore
• Batas sumber daya untuk kumpulan elastis menggunakan model pembelian vCore