Menjelaskan opsi penyebaran
Azure SQL Database, Platform as a Service (PaaS), menawarkan skalabilitas tinggi dan pemeliharaan minimal, menjadikannya solusi yang sangat baik untuk beban kerja tertentu. Ini cocok untuk pengembangan aplikasi baru, memberi pengembang fleksibilitas yang signifikan dalam membangun layanan baru dan menawarkan opsi penyebaran granular dalam skala besar. Solusi pemeliharaan rendah ini sangat ideal untuk berbagai beban kerja, memastikan pengembangan aplikasi yang efisien dan efektif.
Memahami model penyebaran
Saat menyebarkan Azure SQL Database, ada dua model penyebaran utama: database tunggal dan kumpulan elastis. Dalam model kumpulan elastis, sumber daya dibagikan di antara beberapa database dalam kumpulan yang sama, sedangkan dalam model database tunggal, sumber daya dikelola secara independen untuk setiap database.
Mirip dengan komputer virtual, SQL Database dapat disebarkan menggunakan berbagai metode, termasuk PowerShell, Azure CLI, atau portal Azure.
Database tunggal
Model penyebaran database tunggal adalah cara paling sederhana untuk menggunakan Azure SQL Database. Dalam model ini, Anda mengelola setiap database satu per satu dalam hal skala dan ukuran data. Setiap database memiliki sumber daya khususnya sendiri, bahkan jika beberapa database disebarkan di server logis yang sama.
Anda dapat memantau pemanfaatan sumber daya setiap database melalui portal Azure. Fitur ini memungkinkan Anda untuk dengan mudah melacak dan menilai performa database Anda.
Kumpulan database elastis
Kumpulan elastis memungkinkan Anda mengalokasikan penyimpanan dan sumber daya komputasi ke sekelompok database, menyederhanakan manajemen dibandingkan dengan menangani setiap database satu per satu. Mereka lebih mudah diskalakan daripada database tunggal, karena perubahan pada kumpulan elastis secara otomatis menyesuaikan sumber daya untuk semua database yang disertakan.
Model ini hemat biaya untuk aplikasi perangkat lunak sebagai layanan, karena sumber daya dibagikan di antara semua database. Anda dapat mengonfigurasi sumber daya menggunakan model pembelian berbasis DTU atau berbasis vCore.
Penting untuk terus memantau sumber daya untuk mengidentifikasi lonjakan performa yang dapat memengaruhi database lain di kumpulan. Mengunjungi kembali strategi alokasi Anda secara teratur memastikan sumber daya yang memadai untuk semua database.
Kumpulan elastis sangat ideal untuk arsitektur multipenyewa dengan pemanfaatan rata-rata rendah, di mana setiap penyewa memiliki salinan databasenya sendiri.
Memahami model pembelian
Setelah Anda memilih model penyebaran yang sesuai untuk SQL Database Anda, langkah selanjutnya adalah memilih model pembelian yang paling sesuai dengan beban kerja dan persyaratan anggaran Anda. Azure SQL Database menawarkan dua model pembelian: model vCore dan model berbasis DTU. Setiap model memiliki kelebihannya sendiri, jadi sangat penting untuk memahami mana yang paling selaras dengan persyaratan beban kerja dan pertimbangan biaya Anda.
Berbasis vCore
Ini adalah model pembelian yang direkomendasikan, di mana sumber daya komputasi dan penyimpanan dipisahkan. Ini berarti Anda dapat menskalakan penyimpanan dan menghitung sumber daya secara independen satu sama lain. Fleksibilitas ini memastikan bahwa Anda dapat menyesuaikan sumber daya sesuai dengan kebutuhan spesifik Anda tanpa memengaruhi komponen lain.
Dalam model pembelian berbasis vCore, biaya Anda bergantung pada beberapa faktor, termasuk tingkat layanan, konfigurasi perangkat keras, jumlah vCore dan jumlah memori, penyimpanan database yang dipesan, dan penyimpanan cadangan aktual.
Catatan
Untuk detail harga, lihat halaman harga Azure SQL Database.
Tingkat layanan adalah konfigurasi yang telah ditentukan sebelumnya yang menentukan performa, jenis penyimpanan, ketersediaan tinggi, opsi pemulihan bencana, dan ketersediaan fitur tertentu untuk database Anda.
Model pembelian vCore menawarkan tiga opsi tingkat layanan:
| Tingkat layanan | Kemampuan |
|---|---|
| Tujuan Umum | Tingkat layanan ini dirancang untuk operasi yang kurang intensif dan menawarkan keseimbangan opsi komputasi dan penyimpanan yang hemat biaya. Ini termasuk tingkat komputasi yang disediakan dan tanpa server, memberikan fleksibilitas untuk memenuhi berbagai tuntutan beban kerja sambil mengoptimalkan anggaran. |
| Kritis Bisnis | Tingkat ini sangat ideal untuk aplikasi yang menuntut latensi rendah dan penyimpanan berkinerja tinggi. Ini mendukung OLTP Dalam Memori dan menyertakan replika baca-saja bawaan. Selain itu, ia menawarkan lebih banyak memori per inti dan menggunakan penyimpanan SSD lokal, menjadikannya ideal untuk beban kerja yang sensitif terhadap performa. |
| Skala Tinggi | Tingkat ini disesuaikan untuk aplikasi dengan database besar dan persyaratan throughput tinggi. Hyperscale memperkenalkan fitur penskalaan horizontal tingkat lanjut, memungkinkan penambahan simpul komputasi saat ukuran data meningkat. Ini didukung secara eksklusif pada database SQL tunggal dan memungkinkan penskalaan penyimpanan dan sumber daya komputasi yang signifikan di luar batas tingkat layanan Tujuan Umum dan Bisnis Penting. |
Berbasis DTU
Dalam model DTU, ada tiga tingkat layanan: Dasar, Standar, dan Premium. Sumber daya komputasi dan penyimpanan bergantung pada tingkat DTU, menawarkan berbagai kemampuan performa dengan batas penyimpanan tetap, retensi cadangan, dan biaya.
Misalnya, jika database Anda mencapai batas penyimpanan maksimumnya, Anda harus meningkatkan kapasitas DTU Anda, bahkan jika pemanfaatan komputasi rendah. Selain itu, operasi penskalaan pada Azure SQL Database dapat menyebabkan gangguan koneksi singkat di akhir proses. Ini dapat terjadi dalam dua skenario utama:
- Memulai operasi penskalakan yang memerlukan failover internal.
- Menambahkan atau menghapus database dari kumpulan elastis.
Catatan
Untuk menangani kesalahan koneksi, terapkan logika coba lagi yang tepat di aplikasi Anda.
Memahami interplay antara model penyebaran dan pembelian sangat penting untuk mengoptimalkan performa dan efisiensi biaya. Dengan memilih kombinasi yang tepat dengan hati-hati, Anda dapat memastikan bahwa penyebaran Azure SQL Database Anda memenuhi tuntutan aplikasi Anda sambil tetap dalam anggaran.
Misalnya, jika Anda memilih model penyebaran database tunggal, Anda mungkin lebih suka model pembelian vCore karena fleksibilitasnya dalam menskalakan sumber daya komputasi dan penyimpanan secara independen. Di sisi lain, jika Anda memilih model penyebaran kumpulan elastis, model pembelian berbasis DTU bisa lebih hemat biaya, karena memungkinkan Anda berbagi sumber daya di antara beberapa database dalam kumpulan.
Melakukan pencadangan serta pemulihan
Azure menyediakan kemampuan pencadangan dan pemulihan yang mulus untuk SQL Database. Berikut adalah beberapa fitur utama:
Pencadangan berkelanjutan
Azure SQL Database memastikan pencadangan reguler, terus menyalinnya ke penyimpanan geo-redundan akses baca (RA-GRS). Pencadangan penuh terjadi setiap minggu, pencadangan diferensial setiap 12 hingga 24 jam, dan pencadangan log transaksi setiap 5 hingga 10 menit.
Pemulihan Geo
Dengan pencadangan geo-redundan secara default, Anda dapat dengan mudah memulihkan database ke berbagai wilayah, berguna untuk skenario pemulihan bencana yang kurang ketat. Penyimpanan cadangan ditagih secara terpisah tetapi dibuat tanpa biaya tambahan dengan ukuran maksimum tingkat data yang dipilih. Durasi pemulihan geografis tergantung pada ukuran database, log transaksi, dan permintaan pemulihan simultan.
Catatan
Pemulihan geografis tersedia jika properti penyimpanan cadangan redundansi diatur ke penyimpanan cadangan geo-redundan.
Pemulihan Point-in-Time (PITR)
Memungkinkan Anda mengonfigurasi kebijakan penyimpanan titik waktu tertentu untuk setiap database, mulai dari 1 hingga 35 hari (defaultnya adalah tujuh hari). Anda juga dapat memulihkan database ke titik waktu tertentu dalam server yang sama menggunakan portal Azure, PowerShell, CLI, atau REST API.
Retensi Jangka Panjang (LTR)
Retensi jangka panjang berguna untuk skenario yang mengharuskan Anda menetapkan kebijakan penyimpanan di luar apa yang ditawarkan oleh Azure. Anda dapat menetapkan kebijakan penyimpanan hingga 10 tahun, dan opsi ini dinonaktifkan secara default.
Untuk informasi selengkapnya tentang pencadangan otomatis, lihat Pencadangan otomatis - Azure SQL Database & Azure SQL Managed Instance.
Mengaktifkan penyetelan otomatis
Penyetelan otomatis adalah fitur bawaan canggih yang menerapkan pembelajaran mesin untuk mengoptimalkan performa kueri Anda. Ini secara otomatis mengidentifikasi peluang penyetelan dan mengimplementasikannya untuk meningkatkan efisiensi database Anda.
Saat ini, penyetelan otomatis mencakup fitur-fitur berikut:
- Mengidentifikasi Kueri Mahal
- Memaksa Rencana Eksekusi Baik Terakhir
- Menambahkan Indeks
- Menghapus Indeks
Layanan Azure menggunakan algoritma tingkat lanjut untuk menentukan indeks terbaik untuk pola kueri Anda. Indeks ini awalnya diuji pada salinan database Anda sebelum diterapkan ke lingkungan langsung, memastikan gangguan minimal.
Semua database mewarisi konfigurasinya dari server induk, dan Anda dapat dengan mudah menonaktifkan fitur ini jika diperlukan. Fleksibilitas ini memungkinkan pengembang untuk mempertahankan kontrol sekaligus mendapat manfaat dari peningkatan performa otomatis.
Menggunakan kueri elastis
Kueri elastis memungkinkan Anda menjalankan kueri T-SQL di beberapa database di SQL Database. Fitur ini berguna untuk aplikasi yang menggunakan nama tiga dan empat bagian yang tidak dapat diubah, dan meningkatkan portabilitas dengan memfasilitasi migrasi.
Kueri elastis mendukung skenario pemartisian berikut:
| Tingkat Layanan | Kemampuan |
|---|---|
| Pemartisian Vertikal | Juga dikenal sebagai kueri lintas database. Data dipartisi secara vertikal di beberapa database dengan skema yang berbeda. Misalnya, Anda mungkin memiliki satu database untuk data pelanggan dan database lain untuk informasi pembayaran. Pemartisian vertikal memungkinkan Anda menjalankan kueri lintas database di antara database ini. |
| Pemartisian Horizontal | Juga dikenal sebagai sharding. Data dipartisi secara horizontal untuk mendistribusikan baris di beberapa database yang diskalakan, semuanya berbagi skema yang sama. Topologi ini mendukung model penyewa tunggal dan multipenyewa. |
Fleksibilitas ini membuat kueri elastis menjadi alat yang canggih untuk mengelola dan mengkueri data di beberapa database.
Mengonfigurasi pekerjaan elastis
Fitur pekerjaan elastis berfungsi sebagai pengganti SQL Server Agent untuk Azure SQL Database, mirip dengan fitur Administrasi Multi Server dalam instans SQL Server lokal.
Dengan pekerjaan elastis, Anda dapat menjalankan perintah T-SQL di berbagai penyebaran target, termasuk SQL Database, kumpulan elastis SQL Database, dan SQL Database di peta shard. Sumber daya database ini dapat mencakup langganan dan wilayah Azure yang berbeda. Kemampuan eksekusi paralel berguna untuk mengotomatiskan tugas pemeliharaan database, memastikan efisiensi dan konsistensi di seluruh penyebaran Anda.
Memindahkan data menggunakan Sinkronisasi Data SQL
Sinkronisasi Data SQL memungkinkan sinkronisasi data secara bertahap di beberapa database, baik yang berjalan di SQL Database atau SQL Server lokal. Fitur ini berguna untuk membongkar beban kerja produksi intensif ke database terpisah untuk analitik atau operasi yang tidak dienkripsi.
Sinkronisasi Data beroperasi pada topologi hub, di mana satu database dalam grup sinkronisasi ditetapkan sebagai hub. Grup sinkronisasi dapat mencakup beberapa database anggota, dan sinkronisasi terjadi antara database hub dan anggota individual. Perubahan dilacak menggunakan sisipkan, perbarui, dan hapus pemicu melalui tabel historis yang dibuat pada database pengguna.
Saat membuat grup sinkronisasi, Anda harus menentukan database untuk menyimpan metadata grup sinkronisasi. Database metadata ini bisa baru atau yang sudah ada, selama berada di wilayah yang sama dengan grup sinkronisasi Anda.
Untuk informasi selengkapnya tentang cara mengonfigurasi SQL Data Sync, lihat Tutorial: Menyiapkan Sikronisasi Data SQL antara database di Azure SQL Database dan SQL Server.