Bagikan melalui


Peluasan skala dengan Azure SQL Database

Berlaku untuk: Azure SQL Database

Anda dapat dengan mudah meluaskan skala database di Azure SQL Database menggunakan alat Elastic Database. Alat dan fitur ini memungkinkan Anda menggunakan sumber daya database Azure SQL Database untuk membuat solusi untuk beban kerja transaksional, terutama aplikasi Software as a Service (SaaS). Fitur Elastic Database terdiri dari:

Grafik berikut ini memperlihatkan arsitektur yang menyertakan fitur Elastic Database dalam kaitannya dengan kumpulan database.

Dalam grafik ini, warna database mewakili skema. Database dengan warna yang sama berbagi skema yang sama.

  1. Satu set database SQL dihosting di Azure menggunakan arsitektur pemecahan.
  2. Pustaka klien Elastic Database digunakan untuk mengelola set pecahan.
  3. Subset database dimasukkan ke dalam kumpulan elastis.
  4. Pekerjaan Elastic Database menjalankan skrip T-SQL terhadap semua database.
  5. Alat pisah-gabung digunakan untuk memindahkan data dari satu pecahan ke pecahan lainnya.
  6. Kueri Elastic Database memungkinkan Anda menulis kueri yang menjangkau semua database dalam set pecahan.
  7. Transaksi elastis memungkinkan Anda untuk menjalankan transaksi yang menjangkau beberapa database.

Diagram alat database elastis.

Mengapa menggunakan alat?

Mencapai elastisitas dan skala untuk aplikasi cloud sangat mudah untuk VM dan penyimpanan blob - cukup tambahkan atau kurangi unit, atau tingkatkan daya. Tetapi tetap menjadi tantangan bagi pemrosesan data stateful dalam database hubungan. Tantangan muncul dalam skenario ini:

  • Menumbuhkan dan menyusutkan kapasitas untuk bagian database hubungan dari beban kerja Anda.
  • Mengelola hotspot yang mungkin timbul memengaruhi subset data tertentu - seperti pelanggan akhir (penyewa) yang sibuk.

Secara tradisional, skenario seperti ini telah diatasi dengan berinvestasi di server berskala besar untuk mendukung aplikasi. Namun, opsi ini terbatas di cloud yang semua pemrosesannya terjadi pada perangkat keras komoditas yang telah ditentukan. Sebagai gantinya, mendistribusikan data dan pemrosesan di banyak database terstruktur identik (pola peluasan data yang dikenal sebagai "pemecahan") memberikan alternatif untuk pendekatan peningkatan skala tradisional baik dalam hal biaya dan elastisitas.

Penskalaan horizontal dan vertikal

Gambar berikut menunjukkan dimensi penyekalaan horizontal dan vertikal, yang merupakan cara dasar database elastis dapat diskalakan.

Diagram menjelaskan peluasan skala horizontal versus vertikal.

Penskalakan horizontal mengacu pada penambahan atau penghapusan database untuk menyesuaikan kapasitas atau performa keseluruhan, juga disebut "perluasan skala." Sharding, di mana data dipartisi di seluruh kumpulan database yang terstruktur secara identik, adalah cara umum untuk menerapkan penskalaan horizontal.

Penyekalaan vertikal mengacu pada peningkatan atau penurunan ukuran komputasi database individu, juga dikenal sebagai "peningkatan skala."

Sebagian besar aplikasi database skala cloud menggunakan kombinasi dari dua strategi ini. Misalnya, aplikasi Perangkat Lunak sebagai Layanan mungkin menggunakan penskalaan horizontal untuk menyediakan pelanggan akhir baru dan penskalaan vertikal untuk memungkinkan setiap database pelanggan akhir untuk menumbuhkan atau menyusutkan sumber daya sesuai kebutuhan oleh beban kerja.

  • Penyekalaan horizontal dikelola menggunakan pustaka klien Elastic Database.
  • Penyekalaan vertikal dilakukan menggunakan cmdlet Azure PowerShell untuk mengubah tingkat layanan, atau dengan menempatkan database di kumpulan elastis.

Sharding

Sharding adalah teknik untuk mendistribusikan sejumlah besar data terstruktur identik di banyak database independen. Ini sangat populer di kalangan pengembang cloud yang membuat penawaran Software as a Service (SAAS) untuk pelanggan akhir atau bisnis. Pelanggan akhir ini sering disebut sebagai "penyewa." Sharding mungkin diperlukan karena sejumlah alasan:

  • Jumlah total data terlalu besar untuk muat dalam batasan database individu
  • Throughput transaksi dari keseluruhan beban kerja melebihi kemampuan database individu
  • Penyewa mungkin memerlukan isolasi fisik satu sama lain, sehingga database terpisah diperlukan untuk setiap penyewa
  • Bagian database yang berbeda mungkin perlu berada di geografi yang berbeda untuk alasan kepatuhan, performa, atau geopolitik.

Dalam skenario lain, seperti konsumsi data dari perangkat terdistribusi, pemecahan dapat digunakan untuk mengisi set database yang diatur secara temporal. Misalnya, database terpisah dapat didedikasikan untuk setiap hari atau minggu. Dalam kasus ini, kunci pemecahan dapat menjadi bilangan bulat yang mewakili tanggal (ada di semua baris tabel yang dipecah) dan kueri yang mengambil informasi untuk rentang tanggal harus dirutekan oleh aplikasi ke subset database yang mencakup rentang yang dimaksud.

Pemecahan berfungsi paling baik ketika setiap transaksi dalam aplikasi dapat dibatasi untuk satu nilai kunci pemecahan. Itu memastikan bahwa semua transaksinya lokal untuk database tertentu.

Multipenyewa dan penyewa tunggal

Beberapa aplikasi menggunakan pendekatan paling sederhana untuk membuat database terpisah untuk setiap penyewa. Pendekatan ini adalah pola pemecahan penyewa tunggal yang menyediakan isolasi, kemampuan pencadangan/pemulihan, dan penyekalaan sumber daya pada granularitas penyewa. Dengan sharding penyewa tunggal, setiap database dikaitkan dengan nilai ID penyewa tertentu (atau nilai kunci pelanggan), tetapi kunci tersebut tidak perlu ada dalam data itu sendiri. Adalah tanggung jawab aplikasi untuk merutekan setiap permintaan ke database yang sesuai - dan pustaka klien dapat menyederhanakan tugas ini.

Diagram penyewa tunggal versus multipenyewa.

Skenario lain membuat paket beberapa penyewa bersama-sama ke dalam database, daripada mengisolasinya ke dalam database terpisah. Pola ini adalah pola sharding multipenyewa yang khas - dan mungkin didorong oleh fakta bahwa aplikasi mengelola sejumlah besar penyewa kecil. Dalam sharding multipenyewa, baris dalam tabel database semuanya dirancang untuk membawa kunci yang mengidentifikasi ID penyewa atau kunci sharding. Sekali lagi, tingkat aplikasi bertanggung jawab untuk merutekan permintaan penyewa ke database yang sesuai, dan ini dapat didukung oleh pustaka klien database elastis. Selain itu, keamanan tingkat baris dapat digunakan untuk memfilter baris mana yang dapat diakses setiap penyewa - untuk detailnya, lihat Aplikasi multipenyewa dengan alat database elastis dan keamanan tingkat baris. Mendistribusikan ulang data di antara database mungkin diperlukan dengan pola sharding multipenyewa, dan difasilitasi oleh alat split-merge database elastis. Untuk mempelajari selengkapnya tentang pola desain untuk aplikasi SaaS menggunakan kumpulan elastis, lihat Pola penyewaan database SaaS multipenyewa.

Memindahkan data dari beberapa ke database penyewaan tunggal

Saat membuat aplikasi SaaS, calon pelanggan biasanya ditawarkan versi percobaan perangkat lunak. Dalam hal ini, hemat biaya untuk menggunakan database multipenyewa untuk data. Namun, ketika prospek menjadi pelanggan, database penyewa tunggal lebih baik karena memberikan performa yang lebih baik. Jika pelanggan membuat data selama periode uji coba, gunakan alat pisah-gabung untuk memindahkan data dari multipenyewa ke database penyewa tunggal baru.

Catatan

Memulihkan dari database multipenyewa ke satu penyewa tidak dimungkinkan.

Sampel dan tutorial

Untuk sampel aplikasi yang menunjukkan pustaka klien, lihat Memulai dengan alat Elastic Database.

Untuk mengonversi database yang sudah ada untuk menggunakan alat tersebut, lihat Melakukan migrasi database yang sudah ada untuk meluaskan skala.

Untuk melihat secara spesifik kumpulan elastis, lihat Pertimbangan harga dan performa untuk kumpulan elastis, atau buat kumpulan baru dengan kumpulan elastis.

Belum menggunakan alat database elastis? Lihat Panduan Memulai kami. Jika memiliki pertanyaan, hubungi kami di halaman pertanyaan Tanya Jawab Microsoft untuk SQL Database dan untuk permintaan fitur, tambahkan ide-ide baru atau ambil suara terbanyak untuk ide yang sudah ada di forum umpan balik SQL Database.