Ringkasan model pembelian berbasis DTU

Berlaku untuk:Azure SQL Database

Dalam artikel ini, pelajari model pembelian berbasis DTU untuk Azure SQL Database.

Untuk mempelajari selengkapnya, tinjau model pembelian berbasis vCore dan bandingkan model pembelian.

Unit transaksi database (DTU)

Unit transaksi database (DTU) mewakili ukuran campuran CPU, memori, baca, dan tulis. Tingkat layanan di model pembelian berbasis DTU dibedakan berdasarkan rentang spesifikasi komputasi dengan jumlah penyimpanan bawaan tetap, periode retensi tetap untuk cadangan, dan harga tetap. Semua tingkat layanan di model pembelian berbasis DTU memberikan fleksibilitas mengubah spesifikasi komputasi dengan waktu henti minimal. Namun, terdapat periode peralihan di mana konektivitas terputus ke database selama beberapa saat, yang dapat dimitigasi menggunakan logika coba lagi. Database tunggal dan kumpulan elastis ditagih per jam berdasarkan tingkat layanan dan ukuran komputasi.

Untuk database tunggal pada spesifikasi komputasi tertentu dalam tingkat layanan, Azure SQL Database menjamin tingkat sumber daya tertentu untuk database tersebut (terlepas dari database lain). Jaminan ini memberikan tingkat performa yang dapat diprediksi. Jumlah sumber daya yang dialokasikan untuk database dihitung sebagai sejumlah DPU dan merupakan ukuran yang dibundel dari sumber daya komputasi, penyimpanan, dan I/O.

Rasio di antara sumber daya ini awalnya ditentukan oleh beban kerja tolok ukur pemrosesan transaksi online (OLTP) yang dirancang untuk menjadi tipikal beban kerja OLTP dunia nyata. Ketika beban kerja Anda melebihi jumlah sumber daya ini, throughput Anda dibatasi, menghasilkan performa dan waktu habis yang lebih lambat.

Untuk database tunggal, sumber daya yang digunakan oleh beban kerja Anda tidak memengaruhi sumber daya yang tersedia bagi database lain di cloud Azure. Selain itu, sumber daya yang digunakan oleh beban kerja lain tidak memengaruhi sumber daya yang tersedia untuk database Anda.

DTU sangat berguna untuk memahami sumber daya relatif yang dialokasikan untuk database pada ukuran komputasi dan tingkat layanan yang berbeda. Contohnya:

• Menggandakan DPU dengan meningkatkan ukuran komputasi database sama dengan menggandakan set sumber daya yang tersedia untuk database tersebut.
• Database P11 tingkat layanan Premium dengan 1750 DTU menyediakan daya komputasi DTU 350 kali lebih banyak daripada database tingkat layanan dasar dengan 5 DTU.

Untuk mendapatkan wawasan yang lebih mendalam tentang penggunaan sumber daya (DTU) beban kerja Anda, gunakan wawasan performa kueri untuk:

• Mengidentifikasi kueri teratas berdasarkan jumlah CPU/durasi/eksekusi yang berpotensi disetel untuk peningkatan performa. Misalnya, kueri intensif I/O mungkin mendapat manfaat dari teknik pengoptimalan dalam memori untuk memanfaatkan memori yang tersedia dengan lebih baik pada tingkat layanan dan ukuran komputasi tertentu.
• Menelusuri kueri dengan detail untuk menampilkan teks dan riwayat penggunaan sumber dayanya.
• Lihat rekomendasi penyetelan performa yang memperlihatkan tindakan yang diambil oleh SQL Database Advisor.

Unit transaksi database elastis (eDTU)

Sebagai ganti dari menyediakan kumpulan sumber daya khusus (DTU) yang mungkin tidak selalu diperlukan, Anda dapat menempatkan database ini ke dalam kumpulan elastis. Database dalam kumpulan elastis ini menggunakan instans tunggal dari mesin database tunggal dan berbagi kumpulan sumber daya yang sama.

Sumber daya bersama dalam kumpulan elastis diukur oleh unit transaksi database elastis (eDTU). Kumpulan elastis memberikan solusi sederhana dan hemat biaya untuk mengelola tujuan performa untuk beberapa database yang memiliki pola penggunaan yang sangat bervariasi dan tidak dapat diprediksi. Kumpulan elastis menjamin bahwa semua sumber daya tidak dapat digunakan oleh satu database dalam kumpulan, sambil memastikan bahwa setiap database dalam kumpulan selalu menyediakan jumlah minimum sumber daya yang diperlukan.

Kumpulan diberi set eDTU untuk harga yang ditetapkan. Dalam kumpulan elastis, database individual dapat melakukan penskalaan otomatis dalam batas yang dikonfigurasi. Database di bawah beban yang lebih berat mengonsumsi lebih banyak eDTU untuk memenuhi permintaan. Database di bawah beban yang lebih ringan menggunakan lebih sedikit eDTU. Database tanpa beban tidak menggunakan eDTU. Karena sumber daya diprovisikan untuk seluruh kumpulan, bukan per database, kumpulan elastis menyederhanakan tugas manajemen Anda dan menyediakan anggaran yang dapat diprediksi untuk kumpulan.

Anda dapat menambahkan lebih banyak eDTU ke kumpulan yang ada dengan waktu henti database minimal. Demikian pula, jika Anda tidak lagi memerlukan eDTU tambahan, keluarkan dari kumpulan yang ada kapan saja. Anda juga bisa menambahkan database atau mengurangi database dari kumpulan kapan saja. Untuk mengalokasikan eDTU bagi database lain, batasi jumlah eDTU yang dapat digunakan database dalam kondisi beban berat. Jika database memiliki penggunaan sumber daya tinggi yang berdampak pada database lain di kumpulan, pindahkan database dari kumpulan dan konfigurasi sebagai database tunggal dengan jumlah sumber daya yang diperlukan dan dapat diprediksi.

Beban kerja yang mendapat manfaat dari kumpulan elastis sumber daya

Kumpulan sangat cocok untuk database dengan rata-rata pemanfaatan sumber daya yang rendah dan lonjakan pemanfaatan yang relatif jarang. Untuk informasi selengkapnya, lihat Kapan Anda harus mempertimbangkan kumpulan elastis SQL Database?.

Menentukan jumlah DTU yang diperlukan oleh beban kerja

Jika Anda ingin memigrasikan beban kerja mesin virtual SQL Server atau lokal yang ada ke SQL Database, baca rekomendasi SKU untuk memperkirakan jumlah DTU yang diperlukan. Untuk beban kerja SQL Database yang ada, gunakan wawasan performa kueri untuk memahami penggunaan sumber daya database (DTU) Anda dan dapatkan wawasan yang lebih mendalam untuk mengoptimalkan beban kerja Anda. Tampilan manajemen dinamis (DMV) sys.dm_db_resource_stats memungkinkan Anda melihat penggunaan sumber daya selama satu jam terakhir. Tampilan katalog sys.resource_stats menampilkan penggunaan sumber daya selama 14 hari terakhir, tetapi dengan ketepatan yang lebih rendah dari rata-rata lima menit.

Menentukan pemanfaatan DTU

Untuk menentukan persentase rata-rata pemanfaatan DTU/eDTU relatif terhadap batas DTU/eDTU database atau kumpulan elastis, gunakan rumus berikut:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

Nilai input untuk rumus ini dapat diperoleh dari DMV sys.dm_db_resource_stats, sys.resource_stats, dan sys.elastic_pool_resource_stats. Dengan kata lain, untuk menentukan persentase pemanfaatan DTU/eDTU terhadap batas DTU/eDTU database atau kumpulan elastis, pilih nilai persentase terbesar dari yang berikut: avg_cpu_percent, avg_data_io_percent, dan avg_log_write_percent pada titik waktu tertentu.

Catatan

Batas DTU database ditentukan oleh CPU, baca, tulis, dan memori yang tersedia untuk database. Namun, karena mesin SQL Database biasanya menggunakan semua memori yang tersedia untuk cache datanya untuk meningkatkan performa, avg_memory_usage_percent nilainya biasanya akan mendekati 100 persen, terlepas dari beban database saat ini. Oleh karena itu, meskipun memori secara tidak langsung memengaruhi batas DTU, memori tidak digunakan dalam rumus pemanfaatan DTU.

Konfigurasi perangkat keras

Dalam model pembelian berbasis DTU, pelanggan tidak dapat memilih konfigurasi perangkat keras yang digunakan untuk database mereka. Meskipun database tertentu biasanya tetap menggunakan jenis perangkat keras tertentu untuk waktu yang lama (umumnya selama beberapa bulan), ada peristiwa tertentu yang dapat menyebabkan database dipindahkan ke perangkat keras lain.

Misalnya, database dapat dipindahkan ke perangkat keras yang berbeda jika skalanya ditingkatkan atau diturunkan ke tujuan layanan yang berbeda, atau jika infrastruktur yang saat ini ada di pusat data mendekati batas kapasitasnya, atau jika perangkat keras yang saat ini digunakan dinonaktifkan karena masa pakainya berakhir.

Jika database dipindahkan ke perangkat keras yang berbeda, performa beban kerja dapat berubah. Model DTU menjamin bahwa throughput dan waktu respons beban kerja tolok ukur DTU akan tetap identik secara substansial ketika database dipindahkan ke jenis perangkat keras yang berbeda, selama tujuan layanannya (jumlah DTU) tetap sama.

Namun, di seluruh spektrum luas beban kerja pelanggan yang berjalan di Azure SQL Database, dampak penggunaan perangkat keras yang berbeda untuk tujuan layanan yang sama dapat lebih jelas. Beban kerja yang berbeda dapat memperoleh manfaat dari konfigurasi dan fitur perangkat keras yang berbeda. Oleh karena itu, untuk beban kerja selain tolok ukur DTU, Anda dapat melihat perbedaan performa jika database berpindah dari satu jenis perangkat keras ke jenis lain.

Pelanggan dapat menggunakan model vCore untuk memilih konfigurasi perangkat keras pilihan mereka selama pembuatan dan penskalaan database. Dalam model vCore, batas sumber daya dari setiap tujuan layanan pada setiap konfigurasi perangkat keras didokumentasikan untuk database tunggal dan kumpulan elastis. Untuk informasi selengkapnya tentang perangkat keras dalam model vCore, lihat Konfigurasi perangkat keras untuk SQL Database atau Konfigurasi perangkat keras untuk SQL Managed Instance.

Membandingkan tingkat layanan

Pemilihan tingkat layanan sangat bergantung pada kebutuhan terkait kelangsungan, penyimpanan, performa bisnis.

	Dasar	Standard	Premium
Beban kerja target	Pengembangan dan produksi	Pengembangan dan produksi	Pengembangan dan produksi
Waktu aktif SLA	99,99%	99,99%	99,99%
Cadangan	Pilihan penyimpanan cadangan geo-redundan, zona-redundan, atau redundan secara lokal, retensi 1-7 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 locally-redundant (LRS), zone-redundant (ZRS), atau geo-redundant (GRS) Retensi 1-35 hari (7 hari secara default), dengan retensi jangka panjang hingga 10 tahun tersedia
CPU	Kurang Penting	Rendah, Sedang, Tinggi	Sedang, Tinggi
IOPS (perkiraan)*	1-4 IOPS per DTU	1-4 IOPS per DTU	>25 IOPS per DTU
Latensi IO (perkiraan)	5 ms (baca), 10 ms (tulis)	5 ms (baca), 10 ms (tulis)	2 ms (baca/tulis)
Pengindeksan penyimpan kolom	T/A	Standar S3 dan yang lebih tinggi	Didukung
OLTP dalam memori	T/A	T/A	Didukung

* Semua IOPS baca dan tulis terhadap file data, termasuk IO latar belakang (titik pemeriksaan dan penulis malas).

Penting

Tingkat layanan Basic, S0, S1, dan S2 menyediakan kurang dari satu vCore (CPU). Untuk beban kerja intensif CPU, disarankan untuk menggunakan tingkat layanan S3 atau yang lebih besar.

Dalam tingkat layanan Basic, S0, dan S1, file database disimpan di Azure Standard Storage, yang menggunakan media penyimpanan berbasis hard disk drive (HDD). Tingkat layanan ini paling cocok untuk pengembangan, pengujian, dan beban kerja lain yang jarang diakses yang tidak terlalu sensitif terhadap variabilitas performa.

Tip

Untuk melihat batas pengelolaan sumber daya sesungguhnya untuk database atau kumpulan elastis, kueri tampilansys.dm_user_db_resource_governance. Untuk database tunggal, satu baris dikembalikan. Untuk database dalam kumpulan elastis, baris dikembalikan untuk setiap database di kumpulan.

Catatan

Anda bisa mendapatkan database gratis di Azure SQL Database di tingkat layanan Dasar dengan akun gratis Azure. Untuk informasi, lihat Membuat database cloud terkelola dengan akun gratis Azure Anda.

Batas Sumber Daya

Batas sumber daya berbeda untuk database tunggal dan yang terkumpul.

Batas penyimpanan database tunggal

Di Azure SQL Database, ukuran komputasi dinyatakan dalam hal Unit Transaksi Database (DTU) untuk database tunggal dan Unit Transaksi Database elastis (eDTU) untuk kumpulan elastis. Untuk mempelajari selengkapnya, tinjau Batas sumber daya untuk database tunggal.

	Dasar	Standard	Premium
Ukuran penyimpanan maksimum	2 GB	1 TB	4 TB
DTU Maksimum	5	3000	4000

Penting

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

Batas kumpulan elastis

Untuk mempelajari selengkapnya, tinjau Batas sumber daya untuk database terkumpul.

	Dasar	Standard	Premium
Ukuran penyimpanan maksimum per database	2 GB	1 TB	1 TB
Ukuran penyimpanan maksimum per kumpulan	156 GB	4 TB	4 TB
eDTU maksimum per database	5	3000	4000
Maksimum eDTU per kumpulan	1600	3000	4000
Jumlah maksimum database per kumpulan	500	500	100

Penting

Lebih dari 1 TB penyimpanan di tingkat Premium saat ini tersedia di semua wilayah kecuali: Tiongkok Timur, Tiongkok Utara, Jerman Tengah, dan Jerman Timur Laut. Di wilayah ini, maksimal penyimpanan di tingkat Premium dibatasi sebesar 1 TB. Untuk informasi selengkapnya, lihat Batasan P11-P15 saat ini.

Penting

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

Tolok ukur DTU

Karakteristik fisik (CPU, memori, IO) yang terkait dengan setiap ukuran DTU dikalibrasi menggunakan tolok ukur yang mensimulasikan beban kerja database dunia nyata.

Pelajari tentang skema, jenis transaksi yang digunakan, campuran beban kerja, pengguna dan pacing, aturan penskalaan, dan metrik yang terkait dengan tolok ukur DTU.

Membandingkan model pembelian berbasis DTU dan vCore

Meskipun model pembelian berbasis DTU didasarkan pada bundel ukuran sumber daya komputasi, penyimpanan, dan I/O, dengan membandingkan model pembelian vCore untuk Azure SQL Database memungkinkan Anda memilih dan menskalakan sumber daya komputasi dan penyimpanan secara independen.

Model pembelian berbasis vCore juga memungkinkan Anda menggunakan Azure Hybrid Benefit untuk SQL Server guna menghemat biaya, dan menawarkan opsi Serverless dan Hyperscale untuk Azure SQL Database yang tidak tersedia dalam model pembelian berbasis DTU.

Pelajari selengkapnya di Membandingkan model pembelian berbasis vCore dan DTU pada Azure SQL Database.

Langkah berikutnya

Pelajari selengkapnya tentang model pembelian dan konsep terkait dalam artikel berikut:

• Untuk detail ukuran komputasi dan pilihan ukuran penyimpanan tertentu yang tersedia untuk database tunggal, lihat Batas sumber daya berbasis DTU SQL Database untuk database tunggal.
• Untuk detail ukuran komputasi dan pilihan ukuran penyimpanan tertentu yang tersedia untuk kumpulan elastis, lihat Batas sumber daya berbasis DTU SQL Database.
• Untuk informasi tentang tolok ukur yang terkait dengan model pembelian berbasis DTU, lihat Tolok ukur DTU.
• Membandingkan model pembelian berbasis vCore dan DTU pada Azure SQL Database.