Tolok ukur DTU
Berlaku untuk: Azure SQL Database
Unit transaksi database (DTU) adalah unit ukuran yang mewakili ukuran campuran CPU, memori, pembacaan, dan penulisan. Karakteristik fisik (CPU, memori, IO) yang terkait dengan setiap ukuran DTU dikalibrasi menggunakan tolok ukur yang mensimulasikan beban kerja database dunia nyata. Artikel ini merangkum tolok ukur DTU dan membagikan informasi tentang skema, jenis transaksi yang digunakan, campuran beban kerja, pengguna dan kecepatan, aturan penyekalaan, dan metrik yang terkait dengan tolok ukur.
Untuk informasi umum tentang model pembelian berbasis DTU, lihat ringkasan model pembelian berbasis DTU.
Ringkasan tolok ukur
Tolok ukur DTU mengukur performa gabungan operasi database dasar yang paling sering terjadi dalam beban kerja pemrosesan transaksi online (OLTP). Meskipun tolok ukur dirancang dengan pertimbangan komputasi cloud, skema database, populasi data, dan transaksi telah dirancang untuk dapat mewakili elemen dasar yang paling sering digunakan dalam beban kerja OLTP.
Mengkorelasikan hasil tolok ukur ke kinerja database dunia nyata
Penting untuk dipahami bahwa semua tolok ukur hanya bersifat representatif dan indikatif. Tingkat transaksi yang dicapai dengan aplikasi tolok ukur tidak akan sama dengan yang mungkin dicapai dengan aplikasi lain. Tolok ukur terdiri dari kumpulan jenis transaksi yang berbeda yang dijalankan pada skema yang berisi berbagai jenis tabel dan data. Meskipun tolok ukur menjalankan operasi dasar yang sama yang umum untuk semua beban kerja OLTP, tolok ukur tidak mewakili kelas database atau aplikasi tertentu. Tujuan dari tolok ukur adalah untuk memberikan panduan yang masuk akal untuk performa relatif sebuah database yang mungkin diharapkan ketika melakukan penskalaan di antara ukuran komputasi.
Pada kenyataannya, database memiliki ukuran dan kompleksitas yang berbeda-beda, menghadapi campuran beban kerja yang berbeda-beda, dan akan merespons dengan cara yang berbeda pula. Misalnya, aplikasi intensif IO dapat mencapai ambang IO lebih awal, atau aplikasi intensif CPU dapat mencapai batas CPU lebih awal. Di bawah peningkatan beban, tidak ada jaminan bahwa database tertentu akan menskala dengan cara yang sama seperti tolok ukur.
Tolok ukur dan metodologinya dijelaskan secara lebih rinci dalam artikel ini.
Skema
Skema ini dirancang untuk memiliki variasi dan kompleksitas yang cukup untuk mendukung berbagai operasi. Tolok ukur berjalan pada database yang terdiri dari enam tabel. Tabel terbagi dalam tiga kategori: ukuran tetap, penskalaan, dan berkembang. Terdapat dua tabel ukuran tetap; tiga tabel penskalaan; dan satu tabel berkembang. Tabel ukuran tetap memiliki jumlah baris yang konstan. Tabel penskalaan memiliki kardinalitas yang sebanding dengan performa database, tetapi tidak berubah selama tolok ukur. Tabel Berkembang berukuran seperti tabel penskalaan pada muatan awal, tetapi kemudian kardinalitasnya berubah saat tolok ukur dijalankan karena ada baris-baris yang disisipkan dan dihapus.
Skema ini mencakup campuran tipe data, termasuk bilangan bulat, numerik, karakter, dan tanggal/waktu. Skema ini mencakup kunci primer dan sekunder, tetapi tidak mencakup kunci asing - yaitu, tidak ada batasan integritas referensial di antara tabel.
Program pembuatan data menghasilkan data untuk database awal. Data bilangan bulat dan numerik dihasilkan dengan berbagai cara. Dalam beberapa kasus, nilai didistribusikan secara acak dalam satu rentang. Dalam kasus lain, sekumpulan nilai diubah secara acak untuk memastikan distribusi tertentu. Bidang teks dihasilkan dari daftar kata yang tertimbang untuk menghasilkan data yang tampak realistis.
Database berukuran berdasarkan faktor skala. Faktor skala (disingkat SF) menentukan kardinalitas tabel penskalaan dan tabel berkembang. Seperti dijelaskan di bawah ini di bagian Pengguna dan Pacing, ukuran database, jumlah pengguna, dan performa maksimum semua diskala secara proporsional satu sama lain.
Transaksi
Beban kerja terdiri dari sembilan jenis transaksi, seperti yang ditunjukkan pada tabel di bawah ini. Setiap transaksi dirancang untuk mengutamakan serangkaian karakteristik sistem tertentu dalam komputer database dan perangkat keras sistem, yang sangat kontras dengan transaksi lainnya. Pendekatan ini memudahkan penilaian dampak komponen yang berbeda terhadap performa keseluruhan. Misalnya, transaksi "Read Heavy" menghasilkan sejumlah besar operasi baca dari disk.
Jenis Transaksi | Deskripsi |
---|---|
Baca Ringan | PILIH; dalam memori; baca-saja |
Baca Sedang | PILIH; sebagian besar dalam memori; baca-saja |
Baca Berat | PILIH; sebagian besar di luar memori; baca-saja |
Perbarui Ringan | PERBARUI; dalam memori; baca-tulis |
Perbarui Berat | PERBARUI; sebagian besar di luar memori; baca-tulis |
Sisipkan Ringan | SISIPKAN; dalam memori; baca-tulis |
Sisipkan Berat | SISIPKAN; Sebagian besar tidak dalam memori; baca-tulis |
Hapus | HAPUS; campuran dalam memori dan luar memori; baca-tulis |
CPU Berat | PILIH; dalam memori; beban CPU yang relatif berat; baca-saja |
Campuran beban kerja
Transaksi dipilih secara acak dari distribusi tertimbang dengan campuran keseluruhan berikut. Campuran keseluruhan memiliki rasio baca/tulis sekitar 2:1.
Jenis Transaksi | % dari Campuran |
---|---|
Baca Ringan | 35 |
Baca Sedang | 20 |
Baca Berat | 5 |
Perbarui Ringan | 20 |
Perbarui Berat | 3 |
Sisipkan Ringan | 3 |
Sisipkan Berat | 2 |
Hapus | 2 |
CPU Berat | 10 |
Pengguna dan Pacing
Beban kerja tolok ukur dijalankan dari alat yang mengirimkan transaksi pada serangkaian koneksi untuk mensimulasikan perilaku sejumlah pengguna secara bersamaan. Meskipun semua koneksi dan transaksi dihasilkan mesin, untuk kesederhanaan, kami menyebut koneksi ini sebagai pengguna. Meskipun setiap pengguna beroperasi secara independen, semua pengguna melakukan siklus langkah yang sama seperti yang ditunjukkan di bawah ini:
- Membangun koneksi database.
- Ulangi hingga sinyal keluar:
- Pilih transaksi secara acak (dari distribusi tertimbang).
- Lakukan transaksi yang dipilih dan ukur waktu respons.
- Tunggu pacing delay.
- Tutup koneksi database.
- Keluar.
Pacing delay (di langkah 2c) dipilih secara acak, tetapi dengan distribusi yang memiliki rata-rata 1,0 detik. Dengan demikian setiap pengguna rata-rata dapat menghasilkan paling banyak satu transaksi per detik.
Aturan penskalaan
Jumlah pengguna ditentukan oleh ukuran database (dalam unit faktor skala). Terdapat satu pengguna untuk setiap lima unit faktor skala. Karena pacing delay, satu pengguna dapat menghasilkan rata-rata paling banyak satu transaksi per detik.
Misalnya, database dengan 500 faktor skala(SF =500) akan memiliki 100 pengguna dan dapat mencapai tingkat maksimum 100 TPS. Untuk mendorong tingkat TPS yang lebih tinggi, dibutuhkan lebih banyak pengguna dan database yang lebih besar.
Durasi pengukuran
Tolok ukur yang valid memerlukan durasi pengukuran yang stabil setidaknya satu jam.
Metrik
Metrik utama dalam tolok ukur adalah throughput dan waktu respons.
- Throughput adalah ukuran performa yang penting dalam tolok ukur. Throughput dilaporkan dalam transaksi per unit-of-time, yang menghitung semua jenis transaksi.
- Waktu respons adalah ukuran prediktabilitas performa. Batasan waktu respons bervariasi menurut kelas layanan. Kelas layanan yang lebih tinggi memiliki persyaratan waktu respons yang lebih ketat, seperti yang ditunjukkan di bawah ini.
Kelas Layanan | Ukuran Throughput | Persyaratan Waktu Respons |
---|---|---|
Premium | Transaksi per detik | Persentil ke-95 dalam 0,5 detik |
Standard | Transaksi per menit | Persentil ke-90 dalam 1,0 detik |
Dasar | Transaksi per jam | Persentil ke-80 dalam 2,0 detik |
Catatan
Metrik waktu respons bersifat khusus untuk Tolok Ukur DTU. Waktu respons untuk beban kerja lainnya bergantung pada beban kerja dan akan berbeda.
Langkah berikutnya
Pelajari selengkapnya tentang model pembelian dan konsep terkait dalam artikel berikut:
- Gambaran umum model pembelian berbasis DTU
- Model pembelian vCore - Azure SQL Database
- Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database
- Memigrasikan Azure SQL Database dari model berbasis DTU ke model berbasis vCore
- Batas sumber daya untuk database tunggal menggunakan model pembelian DTU - Azure SQL Database
- Batas sumber daya untuk kumpulan elastis menggunakan model pembelian DTU