Tolok ukur DTU

Artikel
05/30/2023

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.

Schema

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:

Bagikan melalui