Ringkasan model pembelian vCore - Azure SQL Database dan Azure SQL Managed Instance

Berlaku untuk: Azure SQL Managed Instance Database Azure SQL

Artikel ini menyediakan ringkasan singkat tentang model pembelian vCore yang digunakan oleh Azure SQL Database dan Azure SQL Managed Instance. Untuk mempelajari selengkapnya tentang model vCore untuk setiap produk, pelajari Azure SQL Databasedan Azure SQL Managed Instance.

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

Di Azure SQL Database, sumber daya komputasi (CPU dan memori), I/O, serta penyimpanan data dan log dikenakan biaya per database atau kumpulan elastis. Penyimpanan Microsoft Azure Backup dibebankan per setiap database.

Model pembelian vCore memberikan transparansi dalam CPU database, memori, dan alokasi sumber daya penyimpanan, konfigurasi perangkat keras, granularitas penskalaan yang lebih tinggi, dan diskon harga dengan Azure Hybrid Benefit (AHB) dan Instans Cadangan (RI).

Dalam kasus Azure SQL Database, model pembelian vCore menyediakan spesifikasi komputasi, memori, I/O, dan batas penyimpanan yang lebih tinggi daripada model DTU.

Tingkat layanan

Dua tingkat layanan vCore tersedia di Azure SQL Database dan Azure SQL Managed Instance:

  • Tujuan umum adalah tingkat ramah anggaran yang dirancang untuk sebagian besar beban kerja dengan persyaratan performa dan ketersediaan umum.
  • Tingkat Kritis Bisnis dirancang untuk beban kerja yang sensitif terhadap performa dengan persyaratan ketersediaan yang ketat.

Tingkat layanan Hyperscale juga tersedia untuk database tunggal di Azure SQL Database. Tingkat layanan ini dirancang untuk sebagian besar beban kerja bisnis, menyediakan penyimpanan yang sangat dapat diskalakan, peluasan skala baca, dan kemampuan pemulihan database yang cepat.

Batas Sumber Daya

Untuk informasi selengkapnya tentang batas sumber daya, lihat:

Komputasi biaya

Model pembelian berbasis vCore memiliki tingkatan komputasi yang ditentukan untuk Azure SQL Database dan Azure SQL Managed Instance, dan tingkatan komputasi tanpa server untuk Azure SQL Database.

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 database Azure SQL, sumber daya komputasi diskalakan secara otomatis berdasarkan kapasitas beban kerja dan ditagih sejumlah komputasi yang digunakan, per detik.

Karena tiga replika tambahan dialokasikan secara otomatis di tingkat layanan Business Critical, harganya akan menjadi sekitar 2,7 kali lebih tinggi dari yang menggunakan tingkat layanan General Purpose. Selain itu, harga 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.

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 dari 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.
  • Dalam tingkatan Tujuan Umum dan Bisnis Kritis, Anda dikenakan biaya untuk ukuran penyimpanan maksimum yang dikonfigurasi untuk database, kumpulan elastis, atau instans terkelola.
  • Di SQL Database, Anda dapat memilih ukuran data maksimum antara 1 GB dan ukuran penyimpanan maksimum yang didukung, dengan tahapan 1 GB. Untuk SQL Managed Instance, pilih ukuran data dengan kelipatan 32 GB hingga ukuran penyimpanan maksimum yang didukung.

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.

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

Tip

Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk merebut kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, 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 dan SQL Managed Instance. 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 selama SQL Database, dan 0 hingga 35 hari untuk Azure SQL Managed Instance. Jumlah penyimpanan cadangan yang sama dengan ukuran data maksimum yang dikonfigurasi disediakan tanpa biaya tambahan.
  • LTR:Anda juga memiliki opsi untuk mengonfigurasi penyimpanan cadangan penuh jangka panjang 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 akan digunakan untuk pencadangan LTR. Untuk mengetahui informasi selengkapnya, lihat Retensi cadangan jangka panjang.

Langkah berikutnya

Untuk memulai, lihat:

Untuk mengetahui detail tentang ukuran komputasi dan penyimpanan tertentu yang tersedia dalam tingkat layanan General Purpose dan Business Critical, lihat: