Microsoft Azure menyediakan Platform as a Service (PaaS) Database Engine melalui platform Azure SQL Database, sehingga kami dapat menggunakan database ini untuk aplikasi berbasis cloud. Keuntungan utama dari Azure SQL Database adalah memungkinkan penskalaan yang mudah tanpa waktu henti dan tidak memerlukan proses peningkatan versi atau penambalan apa pun. Selain itu, kami tidak perlu khawatir tentang masalah perangkat keras.

Namun, pertimbangan yang signifikan dari Azure SQL Database adalah untuk memenuhi persyaratan kinerja dari database yang disebarkan dengan biaya minimum. Tidak diragukan lagi, tidak ada yang mau membayar uang untuk sumber daya atau fitur yang berlebihan yang tidak mereka gunakan atau rencanakan untuk digunakan.

Pada titik ini, Microsoft Azure menawarkan dua model pembelian yang berbeda untuk memberikan efisiensi biaya:

• Model pembelian Berbasis Unit Transaksi Basis Data (DTU).
• Model pembelian berbasis Virtual Core (vCore)

Keputusan model pembelian secara langsung mempengaruhi kinerja database dan jumlah total tagihan. Menurut pendapat saya, Jika database yang digunakan tidak akan menghabiskan terlalu banyak sumber daya, model pembelian Berbasis DTU akan lebih cocok.

Sekarang, kita akan membahas detail tentang kedua model pembelian ini di bagian berikut.

Model pembelian Berbasis Unit Transaksi Basis Data (DTU)

Untuk memahami model pembelian Berbasis DTU lebih jelas, kita perlu mengklarifikasi apa yang masuk akal DTU di Azure SQL Database. DTU adalah singkatan dari “Database Transaction Unit” dan menjelaskan metrik unit kinerja untuk Azure SQL Database. Kita bisa saja seperti DTU ke tenaga kuda di dalam mobil karena secara langsung mempengaruhi kinerja database. DTU mewakili campuran metrik kinerja berikut sebagai unit kinerja tunggal untuk Azure SQL Database:

• CPU
• Memori
• I/O Data dan I/O Log

Gagasan utama dari konsep DTU adalah untuk menawarkan konfigurasi sumber daya yang telah dikonfigurasi sebelumnya kepada klien sehingga menyederhanakan penskalaan kinerja pada satu metrik. Misalnya, jika kita membutuhkan lebih banyak kinerja, kita dapat menggeser bilah dan menambah jumlah DTU di Azure SQL Database.

Model pembelian Berbasis DTU berisi tiga tingkat layanan yang berbeda dan tingkat layanan ini menawarkan DTU dan opsi fitur yang berbeda. Tabel berikut menggambarkan tingkat layanan yang telah mengambil bagian dalam model pembelian berbasis DTU.

Seperti yang dapat kita lihat, DTU dan fitur maksimum bervariasi menurut tingkat layanannya. Selain itu, model penetapan harga akan diubah terkait dengan tingkat layanan. Misalnya, konfigurasi berikut untuk satu database dalam Model Pembelian Berbasis DTU adalah $584,00 per bulan.

Kolam Elastis

Secara singkat, Elastic Pool membantu kami untuk secara otomatis mengelola dan menskalakan beberapa database yang memiliki permintaan sumber daya yang tidak dapat diprediksi dan bervariasi pada kumpulan sumber daya bersama. Melalui Elastic Pool, kita tidak perlu menskalakan database secara terus menerus terhadap fluktuasi permintaan sumber daya. Basis data yang mengambil bagian dalam kumpulan menggunakan sumber daya Pangkalan Elastis saat dibutuhkan tetapi tidak dapat melebihi batasan sumber daya Pangkalan Elastis sehingga memberikan solusi hemat biaya.

Estimasi DTU dengan Benar untuk Database Azure SQL

Setelah memutuskan untuk menggunakan model pembelian berbasis DTU, kita harus mengetahui pertanyaan-jawaban berikut dengan alasan yang logis:

• Tingkat layanan mana dan berapa banyak DTU yang diperlukan untuk beban kerja saya saat bermigrasi ke Azure SQL?

Kalkulator DTU akan menjadi solusi utama untuk memperkirakan kebutuhan DTU saat kami memigrasikan database lokal ke Azure SQL Database. Ide utama alat ini adalah menangkap berbagai metrik pemanfaatan dari SQL Server yang ada yang memengaruhi DTU dan kemudian mencoba memperkirakan kira-kira DTU dan tingkat layanan berdasarkan pemanfaatan kinerja yang dikumpulkan. Kalkulator DTU mengumpulkan metrik berikut melalui Utilitas Baris Perintah atau Skrip PowerShell dan menyimpan metrik ini ke file CSV.

• Prosesor - % Waktu Prosesor
• Disk Logis - Pembacaan Disk/dtk
• Disk Logis - Penulisan Disk/dtk
• Database - Log Byte Flushed/dtk

Dalam artikel ini, kita akan mempelajari penggunaan Utilitas Baris Perintah karena ini adalah proyek dan kode sumber terbuka yang dihosting di GitHub. Dengan demikian, kita dapat melakukan perubahan dengan mudah jika kita membutuhkannya. Setelah mengunduh dan membuka ritsleting Utilitas Baris Perintah, dua file akan muncul di depan kita.

SqlDtuPerfmon.exe.config membantu kita menentukan beberapa parameter Utilitas Baris Perintah:

CsvPath menentukan jalur file CSV tempat metrik yang dikumpulkan akan disimpan.

SampleInterval menentukan berapa detik interval sampel akan dikumpulkan

MaxSamples menentukan jumlah maksimum sampel yang akan dikumpulkan.

Pada titik ini, kita harus mempertimbangkan beberapa pertimbangan tentang Kalkulator DTU. Kalkulator DTU mengumpulkan pemanfaatan total metrik di komputer. Untuk alasan ini, proses lain yang mempengaruhi konsumsi CPU, memori dan disk harus dihentikan jika tidak maka akan sulit untuk membuat estimasi DTU yang akurat. Masalah lainnya adalah, mungkin, kita perlu mengumpulkan pemanfaatan metrik yang mencakup interval waktu beban kerja puncak. Dengan cara ini, Kalkulator DTU menawarkan rekomendasi terbaik dan kami menemukan persyaratan DTU maksimum dengan perkiraan yang lebih mendekati. Sekarang, kita akan menjalankan SqlDtuPerfmon.exe dan itu akan langsung mulai mengumpulkan pemanfaatan sumber daya dan menyimpan file CSV yang ditentukan.

Setelah selesai mengumpulkan pemanfaatan sumber daya, kami akan memasukkan jumlah inti dan mengunggah file CSV ke situs web Kalkulator DTU.

Saat kita mengklik tombol Hitung, pertama, diagram lingkaran Tingkat Layanan/Tingkat Kinerja muncul di layar dan menunjukkan perkiraan tingkat layanan yang dibagi menjadi beberapa bagian dengan rincian persentase. Menurut Kalkulator DTU, Standar - Tingkat S6 akan memberikan kinerja yang memuaskan untuk beban kerja ini.

Tepat di bawah bagan ini, bagan DTU Over Time ditampilkan dan bagan ini mewakili DTU yang berubah terhadap periode waktu. Sebelum mengevaluasi bagan ini, kita dapat menambahkan beberapa informasi tambahan untuk menafsirkannya dengan lebih mudah.

Seperti yang Anda lihat, bagan garis menunjukkan beban kerja yang tidak stabil, tetapi lebih masuk akal saat kami menambahkan catatan informasi. Menurut saya, bagan ini sangat berguna untuk memahami interaksi antara perubahan beban kerja dan DTU. Dengan demikian, kita dapat membuat estimasi yang lebih tepat dari DTU yang dibutuhkan. Seperti yang kami sebutkan di awal artikel, tujuan utama kami adalah menemukan solusi biaya yang efektif untuk beban kerja.

Namun, saran ini tidak mengungkapkan persyaratan yang tepat dari DTU di Azure SQL. Untuk alasan ini, kami mungkin perlu mengubah Tingkat Layanan atau Model Pembelian setelah penyebaran database ke Azure SQL.

Saat kita mengklik View More Details, beberapa laporan tambahan akan ditampilkan dan laporan ini mewakili rekomendasi individual untuk penggunaan sumber daya CPU, IOPS, dan Log. Mereka akan sangat membantu untuk memahami khususnya pemanfaatan ini.

Model Pembelian Berbasis Inti Virtual (vCore)

Konsep ini mirip dengan pendekatan tradisional karena kita dapat memutuskan setiap sumber daya dari database. Kami dapat mengatur VCore dan opsi ukuran data maksimal secara manual dalam model ini. Namun, kami tidak dapat menentukan sumber daya memori. Setiap VCore hadir dengan memori khusus dan nilai memori khusus tergantung pada pembuatan VCore.

Terakhir, dalam model ini kita dapat memilih tingkatan layanan berikut:

• Tujuan Umum.
• Bisnis Penting.
• Hiperskala

Kesimpulan

Dalam artikel ini, kami menjelajahi model pembelian Database Azure SQL dan kami menemukan petunjuk penggunaan Kalkulator DTU untuk memperkirakan DTU yang diperlukan di Azure SQL untuk database lokal.