Bagikan melalui

Ringkasan model pembelian berbasis DTU

  • Artikel

Berlaku untuk: Azure SQL Database

Artikel ini memberikan gambaran umum tentang model pembelian berbasis DTU untuk Azure SQL Database. Model pembelian berbasis DTU adalah ukuran komputasi, penyimpanan, dan sumber daya I/O yang sederhana dan dibundel. Ini paling cocok untuk sebagian besar pelanggan dengan beban kerja khas. Model pembelian berbasis DTU tersedia di tingkat layanan Dasar, Standar, dan Premium. Model pembelian berbasis DTU juga tersedia untuk kumpulan elastis.

Model pembelian berbasis DTU berbeda dengan model pembelian berbasis vCore, sehingga Anda dapat membandingkan 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.

Diagram tentang model pembelian DTU. Empat sisi kotak adalah Tulis, CPU, Bacaan, dan Memori, yang menjelaskan bagaimana beban kerja DTU adalah perpaduan tingkat CPU, memori, dan baca-tulis.

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 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 Kumpulan elastis di Azure 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 mungkin mendapat 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, lihat Konfigurasi perangkat keras.

Membandingkan tingkat layanan

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.

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 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 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 2 T/A Standar S3 dan yang lebih tinggi Didukung
OLTP dalam memori T/A T/A Didukung

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

2 Untuk informasi selengkapnya, lihat Mengubah tingkat layanan database yang berisi indeks penyimpan kolom.

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.

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 mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat Mengelola ruang file untuk database di Azure SQL Database.

Batas kumpulan elastis

Untuk mempelajari lebih lanjut, tinjau Batas sumber daya untuk kumpulan elastis menggunakan model pembelian DTU.

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 mengklaim 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 untuk menghemat biaya, dan menawarkan tingkat komputasi Tanpa Server untuk Azure SQL Database dan opsi tingkat layanan 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.

Konten terkait