Pola pemecahan data (sharding)

Membagi penyimpanan data menjadi sekumpulan pecahan atau partisi horizontal. Pendekatan ini dapat meningkatkan skalabilitas saat Anda menyimpan dan mengakses data dalam volume besar.

Konteks dan masalah

Penyimpanan data di satu server memiliki batasan berikut:

Ruang penyimpanan: Penyimpanan data untuk aplikasi cloud skala besar dapat berisi sejumlah besar data yang tumbuh dari waktu ke waktu. Server menyediakan jumlah penyimpanan disk yang terbatas, dan Anda dapat mengganti disk yang ada dengan disk yang lebih besar atau menambahkan lebih banyak disk saat volume data tumbuh. Sistem akhirnya mencapai batas di mana Anda tidak dapat meningkatkan kapasitas penyimpanan pada satu server.
Sumber daya komputasi: Aplikasi cloud harus mendukung sejumlah besar pengguna bersamaan yang masing-masing menjalankan kueri terhadap penyimpanan data. Satu server mungkin tidak memberikan daya komputasi yang cukup untuk beban ini, yang menghasilkan waktu respons dan batas waktu yang diperpanjang. Anda dapat menambahkan memori atau meningkatkan prosesor, tetapi sistem mencapai batas di mana Anda tidak dapat meningkatkan sumber daya komputasi lebih lanjut.
Bandwidth jaringan: Tingkat di mana satu server dapat menerima permintaan dan mengirim balasan membatasi performa penyimpanan data. Volume lalu lintas jaringan dapat melebihi kapasitas koneksi jaringan, yang menghasilkan permintaan yang gagal.
Geografi: Persyaratan hukum, kepatuhan, atau performa mungkin mengharuskan Anda menyimpan data pengguna di wilayah geografis yang sama dengan pengguna. Jika pengguna menjangkau seluruh negara/wilayah, Anda mungkin tidak dapat menyimpan semua data aplikasi dalam satu penyimpanan data.

Untuk menunda batasan ini sementara, Anda dapat menskalakan secara vertikal dengan menambahkan kapasitas disk, daya pemrosesan, memori, dan koneksi jaringan. Aplikasi cloud yang harus mendukung sejumlah besar pengguna dan volume data tinggi perlu diskalakan secara horizontal.

Solusi

Bagi ruang penyimpanan data menjadi partisi horizontal atau pecahan. Setiap shard memiliki skema yang sama tetapi berisi subset datanya sendiri yang berbeda. Setiap shard adalah penyimpanan data lengkap yang dapat berisi data untuk banyak entitas dari berbagai jenis. Shard berjalan di server yang berfungsi sebagai simpul penyimpanan.

Pola ini memiliki manfaat sebagai berikut:

Anda dapat menskalakan sistem dengan menambahkan lebih banyak pecahan pada simpul penyimpanan tambahan.
Sistem dapat menggunakan perangkat keras bawaan daripada komputer khusus dan mahal untuk setiap simpul penyimpanan.
Anda dapat mengurangi perbedaan dan meningkatkan kinerja dengan menyeimbangkan beban kerja di seluruh pecahan.
Di cloud, pecahan dapat berada secara fisik dekat dengan pengguna yang mengakses data.

Saat Anda membagi penyimpanan data menjadi pecahan, putuskan data mana yang akan ditempatkan di setiap shard. Setiap shard biasanya menyimpan item yang dikelompokkan menurut satu atau beberapa atribut data. Atribut ini membentuk kunci shard, kadang-kadang disebut sebagai kunci partisi.

Sharding secara fisik mengorganisir data. Saat aplikasi menyimpan dan mengambil data, logika sharding mengarahkannya ke shard yang sesuai. Anda dapat menerapkan logika ini dalam kode akses data aplikasi atau dalam sistem penyimpanan data jika secara transparan mendukung sharding.

Mengabstraksi lokasi fisik data dalam logika sharding memberikan kontrol atas shard mana yang berisi data mana. Anda juga dapat memigrasikan data antar pecahan tanpa memodifikasi logika bisnis aplikasi saat Anda perlu mendistribusikan ulang data, seperti ketika pecahan menjadi tidak seimbang. Kompromi adalah overhead akses data tambahan untuk menentukan lokasi setiap item data selama pengambilan.

Pemilihan kunci pecahan

Kunci pecahan adalah keputusan desain paling penting dalam sistem pecahan. Untuk mengubah kunci shard setelah memilihnya, Anda biasanya harus memigrasikan semua data ke tata letak shard baru, yang merupakan operasi mahal dan berisiko pada sistem langsung. Buat keputusan ini dengan hati-hati sebelum Anda menulis kode apa pun.

Kunci shard yang efektif tidak dapat diubah, memiliki kardinalitas tinggi, mendistribusikan data dan beban secara merata, dan selaras dengan pola kueri dominan Anda sehingga sebagian besar permintaan dapat diselesaikan terhadap satu shard. Hindari meningkatkan nilai secara monoton (bilangan bulat autoincrement dan tanda waktu berurutan), atribut kardinalitas rendah (boolean dan set enum kecil), dan atribut volatil yang sering berubah. Atribut ini menyebabkan hotspot atau perpindahan data lintas shard yang mahal.

Jika tidak ada atribut tunggal yang memenuhi kriteria ini, tentukan kunci shard komposit dengan menggabungkan dua atribut atau lebih. Jika kueri perlu mengambil data berdasarkan atribut yang bukan bagian dari kunci shard, gunakan pola seperti pola Tabel Indeks untuk menyediakan pencarian sekunder.

Untuk informasi selengkapnya tentang cara memilih kunci partisi di seluruh layanan Azure, lihat Panduan partisi data dan Strategi pemartisian data.

Strategi Pemecahan

Gunakan salah satu strategi berikut saat Anda memilih kunci shard dan memutuskan cara mendistribusikan data di seluruh shard. Anda tidak memerlukan korespondensi satu-ke-satu antara pecahan dan server yang menghostingnya. Satu server dapat menghosting beberapa shard.

Strategi sharding pencarian

Dalam strategi pencarian, juga disebut strategi berbasis direktori, logika sharding mengimplementasikan peta yang merutekan permintaan data ke shard yang berisi data tersebut dengan menggunakan kunci shard. Dalam aplikasi multipenyewa, Anda mungkin menyimpan semua data untuk penyewa bersama-sama dalam shard dengan menggunakan ID penyewa sebagai kunci shard. Beberapa penyewa mungkin berbagi shard yang sama, tetapi data untuk satu penyewa tidak tersebar di beberapa shard. Diagram berikut menunjukkan data penyewa yang dipecah berdasarkan ID penyewa.

Pemetaan antara nilai kunci shard dan penyimpanan fisik bisa langsung, di mana setiap nilai kunci shard dipetakan ke partisi fisik. Teknik yang lebih fleksibel adalah pemartisian virtual, di mana nilai kunci shard dipetakan ke pecahan virtual, dan sistem kemudian memetakan pecahan virtual tersebut ke lebih sedikit partisi fisik. Aplikasi menemukan data dengan menggunakan nilai kunci shard yang mengacu pada pecahan virtual, dan sistem secara transparan memetakan pecahan virtual ke partisi fisik. Pemetaan antara pecahan virtual dan partisi fisik dapat berubah tanpa memerlukan modifikasi kode aplikasi.

Strategi sharding berbasis rentang

Strategi berbasis rentang mengelompokkan item terkait bersama-sama dalam pecahan yang sama dan mengurutkannya dengan kunci shard berurutan. Strategi ini mendukung aplikasi yang sering mengambil set item dengan menggunakan kueri rentang. Kueri rentang mengembalikan sekumpulan item data untuk kunci shard yang termasuk dalam rentang tertentu.

Misalnya, jika aplikasi secara teratur perlu menemukan semua pesanan yang dilakukan dalam bulan tertentu, Anda dapat mengambil data lebih cepat jika Anda menyimpan semua pesanan untuk sebulan dalam urutan tanggal dan waktu dalam shard yang sama. Jika Anda menyimpan setiap pesanan dalam shard yang berbeda, aplikasi harus mengambil setiap pesanan satu per satu dengan cara melakukan sejumlah besar kueri titik. Diagram berikut menunjukkan kumpulan berurutan, atau rentang, data yang disimpan dalam pecahan.

Dalam contoh ini, kunci shard adalah kunci komposit yang berisi bulan pesanan sebagai elemen paling signifikan, diikuti oleh hari dan waktu pesanan. Pesanan baru secara alami diurutkan saat dibuat dan ditambahkan ke shard.

Beberapa penyimpanan data mendukung kunci pecahan dua bagian. Kunci partisi mengidentifikasi pecahan, dan kunci baris secara unik mengidentifikasi item dalam pecahan. Shard biasanya menyimpan data dalam urutan berdasarkan kunci baris. Untuk item yang memerlukan kueri rentang dan harus dikelompokkan bersama, Anda dapat menggunakan kunci shard yang memiliki nilai yang sama untuk kunci partisi tetapi nilai unik untuk kunci baris.

Strategi sharding berbasis hash

Strategi berbasis hash mengurangi kemungkinan terjadinya hotspot, yang merupakan pecahan (shard) yang menerima jumlah beban kerja yang tidak proporsional. Strategi ini mendistribusikan data di seluruh pecahan untuk menyeimbangkan ukuran setiap pecahan dan beban rata-rata yang ditemui setiap shard. Logika sharding menghitung pecahan untuk menyimpan item berdasarkan hash dari satu atau lebih atribut dari data. Fungsi hashing yang dipilih harus mendistribusikan data secara merata di seluruh pecahan. Diagram berikut menunjukkan sharding data penyewa berdasarkan hash ID penyewa.

Untuk memahami keuntungan dari strategi hash daripada strategi sharding lainnya, pertimbangkan bagaimana aplikasi multipenyewa yang mendaftarkan penyewa baru secara berurutan dapat menetapkan penyewa ke pecahan di penyimpanan data. Saat Anda menggunakan strategi rentang, data untuk penyewa 1 hingga n disimpan dalam shard A, data untuk penyewa n+1 hingga m disimpan dalam shard B, dan rentang penyewa yang lebih baru dipetakan ke pecahan berturut-turut. Jika penyewa yang paling baru terdaftar juga merupakan yang paling aktif, sebagian besar aktivitas data terjadi dalam beberapa pecahan, yang dapat menyebabkan hotspot. Sebaliknya, strategi hash mengalokasikan penyewa ke pecahan berdasarkan hash ID penyewa mereka. Hash biasanya mendistribusikan tenant secara berurutan di berbagai shard, untuk menyeimbangkan beban. Diagram sebelumnya menunjukkan pendekatan ini untuk penyewa 55 dan 56.

Strategi sharding geografis

Strategi geografis menetapkan data ke pecahan berdasarkan asal geografis atau wilayah konsumsi yang dimaksudkan dari data tersebut. Dalam banyak beban kerja, pengguna dan data yang mereka hasilkan terkonsentrasi di wilayah tertentu. Persyaratan peraturan seperti undang-undang residensi data mungkin mengharuskan data tertentu tetap berada dalam yurisdiksi tertentu. Bahkan tanpa penggerak regulasi, meletakkan data yang dekat dengan pengguna yang paling sering mengaksesnya mengurangi latensi jaringan untuk pembacaan dan penulisan.

Dalam strategi ini, Anda mendapatkan kunci shard dari atribut geografis seperti negara/wilayah pengguna, wilayah pusat data asal, atau pengidentifikasi penyewa regional. Anda menempatkan setiap shard, atau memasangnya pada, infrastruktur dalam batas geografis tersebut.

Misalnya, aplikasi yang melayani pelanggan di Amerika Utara, Eropa, dan Asia-Pacific mungkin mempertahankan tiga grup pecahan, satu grup di setiap wilayah Azure yang sesuai. Aplikasi Eropa yang hanya melayani pengguna Eropa merutekan permintaan ke partisi Eropa. Pendekatan ini mengurangi latensi dan memenuhi persyaratan residensi data.

Sharding geografis memperkenalkan risiko distribusi data yang tidak merata. Jika sebagian besar pengguna Anda berada di satu wilayah, pecahan wilayah tersebut membawa bagian beban dan penyimpanan yang tidak proporsional. Anda dapat menggabungkan sharding geografis dengan strategi lain, seperti hash atau pencarian, di dalam setiap wilayah untuk mendistribusikan beban secara merata di beberapa pecahan di dalam batas geografis yang sama.

Keuntungan dan pertimbangan untuk setiap strategi

Empat strategi sharding memiliki keuntungan dan pertimbangan berikut:

Strategi pencarian memberikan kontrol lebih besar atas konfigurasi shard. Pecahan virtual mengurangi dampak penyeimbangan ulang karena Anda dapat menambahkan partisi fisik baru untuk menyeimbangkan beban kerja. Anda dapat memodifikasi pemetaan antara pecahan virtual dan partisi fisiknya tanpa memengaruhi kode aplikasi. Pencarian lokasi shard menambah overhead.
Strategi rentang mudah diterapkan dan berfungsi dengan baik dengan kueri rentang. Kueri rentang memungkinkan pengambilan beberapa item data dari satu shard dalam satu operasi. Manajemen data lebih sederhana. Misalnya, Anda dapat menjadwalkan pembaruan per zona waktu berdasarkan pola beban lokal saat pengguna di wilayah yang sama berbagi shard. Namun, strategi ini tidak menyeimbangkan beban secara merata di seluruh pecahan. Penyeimbangan ulang sulit dan mungkin tidak mengatasi beban yang tidak merata ketika sebagian besar aktivitas berkonsentrasi pada kunci shard yang berdekatan.
Strategi hash memberikan peluang yang lebih baik untuk distribusi data dan beban yang merata. Anda dapat merutekan permintaan secara langsung dengan menggunakan fungsi hash tanpa mempertahankan peta. Menghitung hash menghasilkan beberapa overhead. Penyeimbangan ulang sulit tanpa hash yang konsisten.
Strategi geografis memenuhi persyaratan residensi dan kedaulatan data yang tidak ditangani strategi lain secara inheren. Ini mengurangi latensi baca dan tulis saat pengguna mengakses data di wilayah mereka. Namun, sharding geografis dapat menyebabkan ketidakseimbangan data dan beban yang signifikan saat populasi pengguna tidak didistribusikan secara merata di seluruh wilayah. Kueri yang mencakup wilayah, seperti pelaporan global, harus mengambil data dari semua pecahan geografis dan menimbulkan latensi yang lebih tinggi. Gabungkan sharding geografis dengan strategi lain dalam setiap wilayah saat Anda memerlukan kepatuhan dan distribusi beban yang merata.

Sebagian besar sistem sharding menerapkan salah satu pendekatan ini, tetapi Anda juga harus mempertimbangkan persyaratan bisnis aplikasi Anda dan pola penggunaan datanya. Misalnya, dalam aplikasi multipenyewa:

Anda dapat memecah data berdasarkan beban kerja. Memisahkan data untuk penyewa yang sangat volatil dalam pecahan terpisah untuk meningkatkan kecepatan akses data bagi penyewa lain.
Anda dapat memecah data berdasarkan lokasi penyewa. Ambil data penyewa di wilayah geografis tertentu secara offline untuk pencadangan dan pemeliharaan selama jam tidak sibuk wilayah tersebut, sementara data penyewa di wilayah lain tetap online selama jam kerja mereka.
Tetapkan penyewa bernilai tinggi shard khusus dan dimuat dengan ringan. Penyewa bernilai lebih rendah dapat berbagi pecahan yang lebih padat.
Simpan data untuk penyewa yang membutuhkan isolasi data dan privasi yang kuat di server terpisah.

Penskalaan dan operasi pemindahan data untuk setiap strategi

Setiap strategi sharding menyediakan kemampuan dan tingkat kompleksitas yang berbeda untuk mengelola skala masuk, peluasan skala, pergerakan data, dan pemeliharaan status.

Strategi pencarian memungkinkan penskalakan dan operasi pergerakan data di tingkat pengguna, baik online atau offline. Untuk memindahkan data:
1. Menangguhkan beberapa atau semua aktivitas pengguna, biasanya selama periode di luar puncak.
2. Pindahkan data ke partisi virtual atau pecahan fisik baru.
3. Perbarui pemetaan.
4. Batalkan atau refresh cache apa pun yang menyimpan data ini.
5. Lanjutkan aktivitas pengguna.
Anda sering dapat mengelola operasi ini secara terpusat. Strategi pencarian mengharuskan data agar efisien di-cache dan mendukung replikasi.
Strategi rentang membatasi penskalaan dan operasi pergerakan data karena Anda harus membagi dan menggabungkan data di seluruh pecahan, biasanya saat sebagian atau semua penyimpanan data offline. Saat Anda memindahkan data ke shard untuk penyeimbangan ulang, Anda mungkin tidak dapat mengurangi beban yang tidak merata jika sebagian besar aktivitas terpusat pada kunci shard atau pengidentifikasi data yang berdekatan dalam rentang yang sama. Strategi rentang mungkin juga memerlukan status untuk memetakan rentang ke partisi fisik.
Strategi hash mempersulit penskalaan dan operasi pergerakan data. Kunci partisi adalah hasil hash dari kunci shard atau pengidentifikasi data. Dengan fungsi hash standar, seperti hash(key) mod N, menambahkan atau menghapus shard menetapkan ulang sebagian besar kunci dan memicu migrasi data skala besar. Hashing yang konsisten mengurangi dampak ini dengan mengatur ruang hash sehingga hanya sebagian kecil kunci yang bergerak saat jumlah shard berubah. Strategi hash tidak memerlukan pemeliharaan status peta yang terpisah.
Strategi geografis secara langsung menghubungkan operasi penskalakan ke provisi infrastruktur regional. Menambahkan kapasitas di satu wilayah tidak meringankan beban di wilayah lain. Persyaratan peraturan yang mengamanatkan sharding geografis juga dapat membatasi pergerakan data di seluruh batas geografis. Dalam setiap wilayah, penskalakan menggunakan strategi sekunder yang mendistribusikan data di seluruh pecahan wilayah tersebut.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

Gunakan sharding sebagai pelengkap untuk bentuk partisi lainnya, seperti partisi vertikal dan partisi fungsional. Misalnya, pecahan tunggal dapat berisi entitas yang dipartisi secara vertikal, dan Anda dapat menerapkan partisi fungsional sebagai beberapa pecahan. Untuk informasi selengkapnya, lihat Pemartisian data horizontal, vertikal, dan fungsi.
Jaga agar shard tetap seimbang sehingga masing-masing dapat menangani volume input/output (I/O) yang mirip. Penyimpangan data menumpuk dari waktu ke waktu ketika rekaman disisipkan dan dihapus, yang mengarah ke hotspot. Rencanakan penyeimbangan ulang secara berkala.

Penyeimbangan ulang memindahkan data antar pecahan dan sering menyebabkan waktu henti atau throughput yang berkurang. Untuk melakukan penyeimbangan ulang dengan frekuensi yang lebih rendah, gunakan partisi virtual. Petakan banyak partisi logis ke lebih sedikit pecahan fisik. Ketika pecahan kelebihan beban, distribusikan ulang partisi virtualnya ke pecahan fisik baru tanpa mengulangi seluruh himpunan data. Azure Cosmos DB menggunakan pendekatan ini untuk memisahkan skema partisi dari infrastruktur fisik.

Lebih suka banyak pecahan kecil daripada beberapa pecahan besar. Pecahan yang lebih kecil bermigrasi lebih cepat, menyeimbangkan beban lebih merata, dan memberikan lebih banyak fleksibilitas untuk redistribusi data.
Gunakan data yang stabil sebagai kunci pecahan. Jika kunci shard berubah, Anda mungkin perlu memindahkan item data yang sesuai antar shard, yang dapat meningkatkan beban operasi pembaruan. Hindari menggunakan kunci shard berdasarkan informasi yang berpotensi volatil. Pilih atribut yang invarian atau secara alami membentuk kunci.
Pastikan kunci pecahan bersifat unik. Misalnya, hindari menggunakan bidang yang secara otomatis meningkat sebagai kunci pecahan. Dalam beberapa sistem, bidang yang otomatis bertambah tidak dapat berkoordinasi di seluruh shard, yang dapat menyebabkan item di shard yang berbeda memiliki kunci shard yang sama.

Nota

Nilai yang di-autoinkrementasi di bidang lain yang bukan kunci shard juga dapat menyebabkan masalah. Misalnya, jika Anda menggunakan bidang autoincrement untuk menghasilkan ID unik, dua item berbeda dalam shard yang berbeda mungkin diberikan ID yang sama.
Pecahkan data untuk mendukung kueri yang paling sering dilakukan. Anda mungkin tidak dapat merancang kunci shard yang cocok dengan persyaratan setiap kueri terhadap data. Jika perlu, buat tabel indeks sekunder untuk mendukung kueri yang mengambil data berdasarkan atribut yang bukan bagian dari kunci shard. Untuk informasi selengkapnya, lihat Pola Tabel Indeks.
Rancang kunci shard dan model data Anda untuk menjaga sebagian besar operasi cukup pada satu shard. Kueri yang hanya mengakses satu shard lebih efisien daripada kueri yang mengambil data dari beberapa shard. Denormalisasi data Anda untuk menjaga entitas terkait yang umumnya dikueri bersama-sama, seperti pelanggan dan pesanan mereka, dalam shard yang sama untuk mengurangi jumlah operasi membaca terpisah.

Kueri lintas pecahan menambahkan latensi, konsumsi sumber daya, dan kompleksitas. Saat aplikasi harus memperoleh data dari beberapa shard, gunakan kueri fan-out paralel yang dijalankan secara bersamaan pada setiap shard dan mengagregasi hasilnya. Bahkan dengan paralelisme, pecahan paling lambat menentukan latensi keseluruhan.

Petunjuk / Saran

Jika entitas dalam satu shard mereferensikan entitas di shard lain, sertakan kunci shard untuk entitas kedua sebagai bagian dari skema untuk entitas pertama. Pendekatan ini dapat meningkatkan performa kueri yang mereferensikan data terkait di seluruh pecahan.
Pertimbangkan kembali kunci shard Anda atau apakah sharding sesuai dengan kebutuhan Anda jika beban kerja Anda memerlukan integritas transaksi yang kuat di seluruh batas shard. Transaksi lintas pecahan menghadirkan tantangan. Protokol koordinasi terdistribusi, seperti komit dua fase, menambahkan latensi, memperkenalkan mode kegagalan, dan mengurangi throughput. Sebagian besar sistem pecahan menghindari transaksi terdistribusi dan mengadopsi konsistensi akhir sebagai gantinya. Dalam model ini, setiap shard diperbarui secara independen, dan aplikasi menangani inkonsistensi sementara.
Pastikan sumber daya yang tersedia untuk setiap simpul penyimpanan shard dapat menangani persyaratan skalabilitas dalam hal ukuran dan throughput data. Untuk informasi selengkapnya, lihat Strategi pemartisian data.
Pertimbangkan untuk mereplikasi data referensi ke semua pecahan. Jika kueri terhadap shard juga mereferensikan data statis atau bergerak lambat, tambahkan data ini ke shard. Aplikasi kemudian dapat mengambil semua data untuk kueri tanpa melakukan perjalanan pulang pergi ke penyimpanan data terpisah.

Nota

Jika data referensi yang disimpan dalam beberapa pecahan berubah, sistem harus menyinkronkan perubahan ini di semua shard. Beberapa tingkat ketidakkonsistensian dapat terjadi saat sinkronisasi ini berjalan. Rancang aplikasi Anda untuk mentolerir inkonsistensi ini.
Sistem terpecah meningkatkan beban operasional. Antisipasi masalah ini:
- Pemantauan: Anda harus mengagregasi metrik dan log di semua pecahan untuk mendapatkan tampilan lengkap tentang kesehatan sistem.
- Pencadangan dan pemulihan: Anda harus mencadangkan setiap shard secara mandiri dan merancang prosedur pemulihan untuk mempertahankan konsistensi lintas shard. Pemulihan titik waktu dari satu shard dapat menciptakan inkonsistensi dengan shard lainnya.
- Perubahan skema: Anda harus mengoordinasikan perubahan Data Definition Language (DDL) di setiap shard.
Anda dapat menerapkan tugas-tugas ini dengan menggunakan skrip atau solusi otomatisasi lainnya.
Anda dapat mengatur lokasi shard untuk menempatkan data mereka di dekat instans aplikasi yang menggunakannya. Pendekatan ini dapat meningkatkan performa tetapi memerlukan perencanaan ekstra untuk operasi yang harus mengakses beberapa pecahan di lokasi yang berbeda.

Kapan menggunakan pola ini

Petunjuk / Saran

Sebelum Anda merancang lapisan sharding kustom, tentukan tanggung jawab sharding mana yang sudah ditangani platform data Anda. Beberapa layanan mengelola sharding sepenuhnya. Misalnya, Azure Cosmos DB mendistribusikan data di seluruh partisi fisik, menangani pemisahan, dan merutekan kueri tanpa keterlibatan aplikasi. Layanan lain mengelola pembagian data (sharding) sebagian. Misalnya, Azure SQL Database menyediakan alat database elastis untuk manajemen peta shard dan perutean tergantung data, tetapi Anda merancang kunci shard dan mengelola operasi pemisahan. Gunakan pola Sharding saat Anda membangun dan mengoperasikan logika sharding sendiri.

Gunakan pola ini ketika:

Total volume data melebihi kapasitas penyimpanan instans database tunggal, dan tidak ada opsi penskalaan vertikal yang mengatasi shortfall.
Throughput transaksi atau kesamaan kueri melebihi apa yang dapat dipertahankan oleh satu instance, dan hanya replika baca tidak dapat mengatasi hambatan karena beban tulis juga tinggi.

Nota

Sharding meningkatkan performa dan skalabilitas sistem, dan juga dapat meningkatkan ketersediaan. Kegagalan dalam satu partisi tidak selalu mencegah aplikasi mengakses data di partisi lain. Dan operator dapat melakukan pemeliharaan atau pemulihan satu partisi tanpa membuat semua data tidak tersedia. Untuk informasi selengkapnya, lihat Panduan pemartisian data.
Persyaratan peraturan atau kepatuhan mengamanatkan bahwa subset data tertentu berada di yurisdiksi geografis tertentu, dan tidak ada penyebaran wilayah tunggal yang dapat memenuhi semua persyaratan.
Penyewa atau segmen pelanggan yang berbeda memerlukan isolasi data fisik karena alasan keamanan, performa, atau kontraktual.

Dalam skenario seperti ini, pola sharding terkadang diterapkan di luar penyimpanan data tradisional. Misalnya, sistem manajemen zona DNS dapat dipecah oleh tim, lingkungan, atau wilayah untuk mengurangi radius ledakan perubahan DNS dan menetapkan batas kepemilikan yang jelas. Dalam konteks itu, motivasi utama adalah segmentasi operasional daripada skalabilitas. Untuk informasi selengkapnya, lihat Memecah zona DNS privat.

Sharding memperkenalkan kompleksitas yang substansial dan permanen ke dalam arsitektur data Anda. Kompleksitas tersebut memengaruhi pengembangan, operasi, pengujian, desain kueri, dan pemulihan kegagalan untuk masa pakai sistem.

Pola ini mungkin tidak cocok ketika:

Volume data dan throughput Anda cocok dalam satu instance basis data, bahkan dengan proyeksi pertumbuhan. Penskalaan vertikal mempertahankan kesederhanaan kueri dan integritas transaksional.
Hambatan Anda adalah volume baca, bukan volume tulis atau kapasitas penyimpanan. Replika baca dan lapisan caching dapat mengurangi beban lalu lintas baca tanpa kompleksitas kueri antar-pecahan yang diperkenalkan oleh sharding.
Mesin database Anda mendukung partisi tingkat tabel yang memenuhi kebutuhan performa Anda. Pemartisian dalam satu instans tidak memerlukan beberapa server atau logika perutean.
Pola kueri dominan Anda memerlukan gabungan lintas entitas, transaksi multientitas, atau agregasi himpunan data lengkap. Sharding membuat operasi ini mahal, dan beban tambahan kueri fan-out dan koordinasi yang terdistribusi dapat melebihi keuntungan penskalaan.

Desain beban kerja

Evaluasi cara menggunakan pola Sharding dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Data dan pemrosesan diisolasi pada shard, sehingga jika terjadi kerusakan dalam satu pecahan, kerusakan tersebut tetap terisolasi dalam pecahan tersebut. - Partisi data - RE:07 Perlindungan Diri
Pengoptimalan Biaya berfokus pada mempertahankan dan meningkatkanpengembalian beban kerja Anda pada investasi.	Sistem yang mengimplementasikan pecahan sering mendapat manfaat dari penggunaan beberapa instans sumber daya komputasi atau penyimpanan yang lebih murah daripada satu sumber daya yang lebih mahal. Dalam banyak kasus, konfigurasi ini dapat menghemat uang Anda. - Biaya komponen CO:07
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Saat Anda menggunakan sharding dalam strategi penskalaan, data dan pemrosesan diisolasi ke setiap shard, sehingga permintaan hanya bersaing untuk sumber daya dalam pecahan yang ditetapkan. Anda juga dapat menggunakan sharding untuk mengoptimalkan berdasarkan geografi. - PE:05 Penskalaan dan pemartisian - Kinerja data PE:08

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Pertimbangkan situs web yang menampilkan kumpulan informasi yang ekspansif tentang buku yang diterbitkan di seluruh dunia. Jumlah buku yang mungkin dikatalogkan dalam beban kerja ini dan kueri umum dan pola penggunaan melebihi apa yang dapat ditangani database relasional tunggal. Arsitek sistem kerja memutuskan untuk membagi data di beberapa instans database dengan menggunakan ISBN buku yang statis sebagai kunci shard. Secara khusus, arsitek menggunakan digit pemeriksa (0 - 10) ISBN, yang menyediakan 11 pecahan logis yang mungkin dengan distribusi data yang secara relatif seimbang.

Untuk memulai, arsitek menempatkan 11 pecahan logis ke dalam tiga database shard fisik. Dalam pendekatan partisi virtual ini, banyak partisi logis dipetakan ke lebih sedikit simpul fisik. Arsitek menggunakan pendekatan sharding lookup dan menyimpan pemetaan kunci ke server dalam basis data peta shard.

Diagram yang memperlihatkan arsitektur SQL Database pecahan untuk aplikasi katalog buku.

Peta pencarian shard

Database peta shard berisi tabel dan data pemetaan shard berikut.

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

Contoh kode situs web: akses shard tunggal

Situs web tidak mengetahui berapa banyak database shard fisik yang ada (tiga dalam hal ini) atau logika yang memetakan kunci shard ke instans database. Hanya diketahui bahwa digit pemeriksaan dari ISBN buku adalah kunci shard. Situs web ini memiliki akses baca-saja ke basis data peta shard dan akses baca-tulis ke semua basis data shard. Dalam contoh ini, situs web menggunakan identitas terkelola sistem dari host Azure App Service untuk otorisasi, yang menjaga agar rahasia tidak dimasukkan ke dalam string koneksi.

Situs web dikonfigurasi dengan string koneksi berikut, baik dalam file, seperti yang ditunjukkan dalam contoh ini, atau melalui pengaturan aplikasi pada layanan App Service.

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

Kode berikut menunjukkan cara situs web menjalankan kueri pembaruan terhadap kumpulan shard database beban kerja.

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information.
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

Dalam contoh kode sebelumnya, jika book.Isbn adalah 978-8-1130-1024-6, maka isbnCheckDigit harus 6. Panggilan OpenShardConnectionForKeyAsync(6) biasanya diimplementasikan dengan menggunakan pendekatan cache-aside. Jika informasi shard yang di-cache untuk kunci shard 6 tidak tersedia, metode ini akan meminta database peta shard yang string sambungannya diidentifikasi oleh ShardMapDb. Metode ini mengambil nilai bookdbshard2 dari cache aplikasi atau database shard dan menggantinya SHARD dalam BookDbFragment string koneksi. Metode ini kemudian menetapkan atau membangun kembali koneksi yang dikumpulkan ke bookdbshard2.database.windows.net, membukanya, dan mengembalikannya ke kode panggilan. Kode kemudian memperbarui rekaman yang ada pada instans database tersebut.

Contoh kode situs web: akses beberapa shard

Dalam kasus yang jarang terjadi ketika situs web memerlukan kueri lintas shard langsung, aplikasi melakukan kueri fan-out paralel di semua shard.

...

// Retrieve all shard keys.
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Run the query in a fan-out style against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Collect the results into a thread-safe data structure.
    }

    reader.Close();
  }
});

...

Sebagai alternatif untuk kueri lintas pecahan, beban kerja ini dapat menggunakan indeks yang dikelola secara eksternal di Azure AI Search untuk pencarian situs atau navigasi tersaring.

Menambahkan instance shard

Tim beban kerja tahu bahwa jika katalog data atau penggunaan bersamaannya tumbuh secara signifikan, mereka mungkin memerlukan lebih dari tiga instans database. Tim beban kerja tidak berharap untuk menambahkan server database secara dinamis, dan mereka menerima waktu henti beban kerja ketika shard baru online. Untuk mengaktifkan instans shard baru, mereka harus memindahkan data dari shard yang ada ke shard baru dan memperbarui tabel peta shard. Dengan pendekatan yang cukup statis ini, beban kerja dapat dengan percaya diri menyimpan pemetaan database kunci shard dalam kode situs web.

Logika kunci shard dalam contoh ini memiliki batas atas 11 pecahan fisik. Jika tim beban kerja menentukan melalui estimasi beban bahwa mereka akhirnya memerlukan lebih dari 11 instans database, mereka harus membuat perubahan invasif pada logika kunci shard. Perubahan ini melibatkan perencanaan modifikasi kode dan migrasi data yang cermat ke logika kunci baru.

Fungsionalitas SDK

Alih-alih menulis kode kustom untuk manajemen shard dan perutean kueri ke instans SQL Database, lakukan evaluasi terhadap pustaka klien database elastis. Pustaka ini mendukung manajemen peta shard, perutean kueri berbasis data, dan kueri lintas shard di C# dan Java.

Langkah selanjutnya

Tingkat konsistensi di Azure Cosmos DB: Mendistribusikan data di seluruh shard memperkenalkan kompromi konsistensi. Artikel ini menjelaskan spektrum model konsistensi, dari yang kuat hingga akhirnya, dan efeknya pada ketersediaan dan latensi.

Pemartisian data horizontal, vertikal, dan fungsi: Artikel ini menjelaskan strategi lain untuk mempartisi data di cloud untuk meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan performa.
Pola Tabel Indeks: Terkadang Anda tidak dapat mendukung semua kueri melalui desain kunci shard saja. Aplikasi dapat menggunakan pola Tabel Indeks untuk mengambil data dari penyimpanan data besar dengan menentukan kunci selain kunci shard.
Pola Tampilan Materialisasi: Untuk mempertahankan performa beberapa operasi kueri, Anda dapat membuat tampilan materialisasi yang menggabungkan dan meringkas data, terutama jika Anda mendistribusikan data tersebut di seluruh pecahan.

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-04-03