Azure SQL Database saat ini memiliki tiga tingkat layanan yang dapat dipilih untuk beban kerja Anda. Tingkatan ini terdiri dari Basic, Standard, dan Premium. Basic hanya mendukung satu ukuran 5 DTU. Premium mulai dari 125 DTU dan naik hingga 4.000 DTU. Tingkat Premium adalah tingkat teratas yang dibuat untuk beban kerja I/O yang lebih tinggi dan memberikan latensi yang lebih rendah per I/O, dan urutan besarnya lebih banyak IOPS per DTU, daripada di tingkat Standar.
Sebelum Agustus 2017, tingkat Standar hanya mendukung ukuran DTU antara 15 dan 100 DTU. Saat ini tersedia dalam pratinjau adalah tingkat kinerja baru dan add-on penyimpanan yang menawarkan manfaat pengoptimalan harga untuk beban kerja intensif CPU. Dengan itu, tingkat Standar sekarang mendukung hingga 3.000 DTU.
Pada titik ini, Anda mungkin bertanya pada diri sendiri apa sebenarnya DTU itu? DTU adalah Unit Transaksi Basis Data dan merupakan campuran dari CPU, memori, dan data serta log transaksi I/O. (Andy Mallon, @AMtwo, baru-baru ini membahas ini di "Apa itu DTU?") Anda dapat mencapai batas DTU Anda dengan memaksimalkan CPU, memori, atau I/O.
Sebelumnya, tier Standar hanya menawarkan 4 level:15, 30, 50, dan 100 DTU, dengan batas ukuran database 250GB, dengan disk standar. Jika Anda memiliki database yang lebih besar dari 250GB, namun tidak membutuhkan lebih dari 100 DTU untuk CPU, memori, atau I/O, Anda harus membayar harga Premium hanya untuk ukuran database. Dengan perubahan baru, Anda sekarang dapat memiliki database hingga 1 TB di tingkat Standar; Anda hanya perlu membayar penyimpanan ekstra. Saat ini penyimpanan ditagih sebesar $0,085/GB selama pratinjau. Peningkatan dari ukuran yang disertakan 250GB menjadi 1TB meningkat sebesar 774GB dengan biaya $65,79 per bulan.
Ukuran DTU pratinjau Standar yang baru mendukung opsi 200, 400, 800, 1.600, dan 3.000 DTU. Jika Anda memiliki beban kerja database SQL Server yang lebih terikat pada CPU daripada I/O, opsi tingkat Standar ini berpotensi menghemat banyak uang; namun, jika beban kerja Anda terikat I/O, tingkat Premium akan mengungguli tingkat Standar.
Saya memutuskan untuk mencoba dua beban kerja yang berbeda untuk melihat betapa berbedanya tingkat Standar dan Premium dibandingkan satu sama lain. Saya ingin membuat tes yang sederhana dan dapat direproduksi sehingga orang lain dapat mencoba memvalidasinya sendiri. Untuk pengujian pertama saya, saya ingin menghasilkan perpaduan yang sehat antara CPU dan I/O. Saya berharap bahwa saya akan mendorong lebih banyak CPU daripada I/O, dan dapat menunjukkan bahwa tingkat Standar yang diperluas akan mengungguli tingkat Premium dengan ukuran DTU yang sama. Saya tidak benar-benar mendapatkan hasil yang saya harapkan.
Untuk menyiapkan demo ini, saya membuat tabel dengan tiga kolom GUID, menyisipkan 1 juta baris, lalu memperbarui dua dari tiga kolom dengan ID baru. Contoh kode di bawah ini:
CREATE TABLE dbo.TestTable ( Table_id UNIQUEIDENTIFIER DEFAULT NEWID(), Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(), Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40)) ); SET NOCOUNT ON; GO INSERT INTO dbo.TestTable DEFAULT VALUES; GO 1000000 CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable] ( [Table_id] ASC, [Customer_id] ASC ); SET STATISTICS TIME ON; UPDATE TestTable SET Table_id = NEWID(), Customer_id = NEWID();
Saat saya menjalankan serangkaian tes, kinerja terus meningkat di tingkat Standar sampai saya mendapatkan opsi S12 di mana, anehnya, CPU dan waktu yang telah berlalu meningkat. Saya menjalankan tes beberapa kali dan S12 secara konsisten 54 detik. Cukup jelas dengan pengujian pertama saya, bahwa tingkat Premium mengungguli tingkat Standar. Misalnya, S9 dan P2 paling dekat dalam waktu, namun ukuran DTU untuk Standar adalah 1.600 dibandingkan dengan 250 untuk P2. Tes ini lebih tentang kemampuan I/O. Bagan di bawah ini menunjukkan ukuran, level DTU, biaya, waktu CPU, waktu berlalu, dan waktu dalam detik untuk setiap pengujian:
Saat pengujian dijalankan, saya mengamati di dasbor monitor bahwa persentase I/O data dan log I/O adalah kekuatan pendorong di belakang persentase DTU. Bagan berikut berasal dari pengujian terhadap database S4:
Saya kemudian memutuskan untuk mencoba serangkaian tes lain yang akan lebih banyak menggunakan CPU. Untuk pengujian itu saya menggunakan skrip berikut:
SET STATISTICS TIME ON;
SELECT SUM(CONVERT(BIGINT, t1.object_id)
+ CONVERT(BIGINT, t2.object_id)
+ CONVERT(BIGINT, t3.object_id)
+ CONVERT(BIGINT, t4.object_id))
FROM sys.objects t1
CROSS JOIN sys.objects t2
CROSS JOIN sys.objects t3
CROSS JOIN sys.objects t4; Apa yang saya amati di dasbor monitor pada rangkaian pengujian ini adalah bahwa persentase CPU adalah satu-satunya pendorong persentase DTU. Saat saya menjalani serangkaian pengujian di tingkat Standar, pengujian tersebut tampaknya berhenti pada kira-kira 27 detik, dan dimulai pada ukuran S4. Apa yang menurut saya aneh adalah bahwa S4 pada 200 DTU membutuhkan waktu 27 detik untuk menyelesaikannya dan P2 yang sesuai pada 250 DTU membutuhkan waktu 38 detik; P4 pada 500 DTU lebih sebanding. Jika kita melihat perbedaan biaya untuk demo ini, S4 selama pratinjau hanya berharga $150,01, sedangkan P4 berharga $1,860; S4 memberikan penghematan biaya lebih dari $1.700. Mari kita bayangkan bahwa P2 pada 250 DTU bekerja seperti yang kita harapkan; P2 berharga $930 dan masih akan berharga $780 lebih mahal daripada S4.
Hasil lengkap dari semua tes di demo kedua termasuk dalam bagan berikut:
Tidak seperti demo pertama, ini 100% digerakkan oleh CPU. Saya telah mencoba memasukkan satu gabungan silang tambahan, tetapi demo kemudian memakan waktu berjam-jam per sesi, bukan menit. Untuk pengujian di masa mendatang, saya akan mencoba membuat beberapa skenario tambahan yang mendorong beban kerja OLTP yang lebih realistis; satu yang lebih tinggi CPU, dan satu yang lebih terikat I/O, dan kemudian perpaduan yang layak dari keduanya.
Anda dapat melihat dari grafik di bawah ini bahwa, saat dijalankan melawan database S4, CPU melonjak hampir 50%, sementara persentase DTU sama persis:
Dari dua beban kerja berbeda yang saya uji, sangat jelas bahwa jika Anda memiliki beban kerja I/O yang signifikan, Anda akan memerlukan tingkat Premium, tetapi jika beban kerja Anda sebagian besar terikat dengan CPU tanpa kebutuhan I/O yang signifikan, semakin tinggi Tingkat standar dapat memberi Anda penghematan besar dibandingkan tingkat Premium.
Jika Anda mempertimbangkan migrasi ke Azure SQL Database, kalkulator DTU adalah tempat yang tepat untuk mulai mendapatkan ide tentang titik awal untuk menentukan ukuran; namun, pada saat penulisan, kalkulator DTU tidak mempertimbangkan tingkat Standar yang diperluas. Apa yang hebat tentang kalkulator DTU adalah ia akan memecah penggunaan CPU, IOP, dan log untuk memberi tahu Anda apa faktor pendorong untuk rekomendasi level DTU. Misalnya, saya menjalankan demo terakhir pada mesin virtual 4 vCPU, 4GB, dan kalkulator DTU merekomendasikan P2. Ketika saya memilih untuk 'melihat detail lebih lanjut,' saya mendapat pesan berikut.
Tingkat Layanan/Tingkat Kinerja untuk CPU – Hanya berdasarkan penggunaan CPU, kami sarankan Anda memigrasikan beban kerja SQL Server Anda ke Premium – P2. Tingkat Layanan/Tingkat Kinerja ini harus mencakup sekitar 100,00% penggunaan CPU Anda.
Tingkat Layanan/Tingkat Kinerja untuk Iops – Hanya berdasarkan penggunaan Iops, kami sarankan Anda memigrasikan beban kerja SQL Server Anda ke Basic. Tingkat Layanan/Tingkat Kinerja ini harus mencakup sekitar 89,92% penggunaan Iops Anda.
CATATAN:Ada sekitar 10,08% beban kerja Anda yang masuk ke Tingkat Layanan/Tingkat Kinerja yang lebih tinggi. Setelah memigrasi database ke Azure, Anda harus mengevaluasi kinerja database menggunakan panduan yang disebutkan di bagian informasi di atas.
Tingkat Layanan/Tingkat Kinerja untuk Log – Hanya berdasarkan penggunaan Log, kami menyarankan Anda untuk memigrasikan beban kerja SQL Server Anda ke Basic. Tingkat Layanan/Tingkat Kinerja ini harus mencakup sekitar 100,00% dari penggunaan Log Anda.
Karena saya tahu beban kerja ini sangat terikat dengan CPU, jika saya tidak dapat menyesuaikan beban kerja untuk mengurangi kebutuhan CPU, saya memiliki hingga 3.000 DTU yang tersedia di tingkat Standar. Daripada menghabiskan $930 per bulan untuk P2 dengan 250 DTU, S4 dengan 200 DTU dengan harga $150 per bulan (atau S6 dengan 400 DTU dengan harga $300,02 per bulan) akan menjadi pilihan yang jauh lebih ekonomis.
Sebagai kesimpulan, ada alat yang tersedia untuk membantu Anda menentukan titik awal yang baik untuk ukuran migrasi Azure SQL Database Anda, namun metode terbaik mutlak adalah menguji beban kerja Anda. Memigrasikan salinan database produksi Anda, menangkap beban kerja produksi, dan memutar ulang beban kerja tersebut terhadap Azure SQL Database akan memberi Anda pemahaman yang jauh lebih baik tentang ukuran DTU yang benar-benar Anda butuhkan.
