Merancang strategi pemartisian data

2025-05-29

Panduan ini menjelaskan rekomendasi untuk merancang strategi pemartisian data untuk database dan teknologi penyimpanan data yang Anda sebarkan. Strategi ini membantu Anda meningkatkan keandalan data estate Anda.

Dalam banyak solusi skala besar, partisi digunakan untuk membagi data sehingga dapat dikelola dan diakses secara terpisah. Pemartisian data meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan performa. Terapkan pemartisian data untuk membagi data dengan pola penggunaan. Misalnya, Anda dapat mengarsipkan data yang lebih lama dalam penyimpanan data murah. Pilih strategi partisi Anda dengan hati-hati untuk memaksimalkan manfaat dan meminimalkan efek buruk.

Nota

Dalam artikel ini, istilah pemartisian berarti proses pembagian data secara fisik menjadi penyimpanan data terpisah. Ini berbeda dari partisi tabel SQL Server.

Anda dapat mempartisi data untuk:

Meningkatkan skalabilitas. Saat Anda meningkatkan sistem database tunggal, database akhirnya mencapai batas perangkat keras fisik. Jika Anda membagi data di beberapa partisi, dengan setiap partisi yang dihosting di server terpisah, Anda dapat memperluas skala sistem hampir tanpa batas waktu.
Meningkatkan performa. Di setiap partisi, operasi akses data dilakukan melalui volume data yang lebih kecil dibandingkan dengan data yang tidak dipartisi. Data partisi untuk membuat sistem Anda lebih efisien. Operasi yang memengaruhi lebih dari satu partisi dapat berjalan secara paralel.
Meningkatkan keamanan. Dalam beberapa kasus, Anda dapat memisahkan data sensitif dan tidak sensitif ke dalam partisi yang berbeda, dan menerapkan kontrol keamanan yang berbeda ke data sensitif.
Memberikan fleksibilitas operasional. Anda dapat mempartisi data untuk menyempurnakan operasi, memaksimalkan efisiensi administratif, dan meminimalkan biaya. Misalnya, Anda dapat menentukan strategi untuk manajemen, pemantauan, pencadangan dan pemulihan, dan tugas administratif lainnya berdasarkan pentingnya data di setiap partisi.
Cocokkan penyimpanan data dengan pola penggunaan. Anda dapat menyebarkan setiap partisi pada jenis penyimpanan data yang berbeda berdasarkan biaya dan fitur bawaan yang ditawarkan penyimpanan data. Misalnya, Anda dapat menyimpan data biner besar dalam penyimpanan blob, dan menyimpan data terstruktur dalam database dokumen. Untuk informasi selengkapnya, lihat Memahami model penyimpanan data.
Meningkatkan ketersediaan. Untuk menghindari satu titik kegagalan, Anda dapat memisahkan data di beberapa server. Jika satu instans gagal, hanya data dalam partisi tersebut yang tidak tersedia. Operasi terus berlanjut di partisi lainnya. Pertimbangan ini kurang relevan untuk penyimpanan data platform as a service (PaaS) terkelola karena memiliki redundansi bawaan.

Pilih strategi partisi yang tepat

Ada tiga strategi umum untuk mempartisi data:

Pemartisian horizontal (sering disebut sharding). Dalam strategi ini, setiap partisi adalah penyimpanan data terpisah, tetapi semua partisi memiliki skema yang sama. Setiap partisi dikenal sebagai shard dan menyimpan subset data, seperti sekumpulan pesanan pelanggan.
Pemartisian vertikal. Dalam strategi ini, setiap partisi menyimpan subset bidang untuk item di penyimpanan data. Bidang dibagi sesuai dengan pola penggunaannya. Misalnya, bidang yang sering diakses mungkin ditempatkan dalam satu partisi vertikal dan bidang yang kurang sering diakses di bidang lain.
Pemartisian fungsi. Dalam strategi ini, data dikumpulkan sesuai dengan bagaimana setiap konteks terikat dalam sistem menggunakan data. Misalnya, sistem e-niaga mungkin menyimpan data faktur dalam satu partisi dan data inventori produk di yang lain.

Pertimbangkan untuk menggabungkan strategi ini saat Anda merancang skema partisi. Misalnya, Anda dapat membagi data menjadi pecahan lalu menggunakan partisi vertikal untuk membagi data lebih lanjut di setiap shard.

Pemartisian horizontal (sharding)

Gambar berikut menunjukkan contoh pemartisian horizontal, atau sharding. Contoh ini membagi data inventaris produk menjadi pecahan yang didasarkan pada kunci produk. Setiap shard menyimpan data untuk rentang kunci shard yang berdampingan (A-G dan H-Z), diatur menurut abjad. Saat Anda melakukan sharding, proses ini menyebarkan beban ke lebih banyak komputer, yang mengurangi kontensi dan meningkatkan kinerja.

Kunci sharding yang Anda pilih adalah faktor terpenting. Mungkin sulit untuk mengubah kunci setelah sistem beroperasi. Kunci harus memastikan bahwa data dipartisi untuk menyebarkan beban kerja semaksimal mungkin di seluruh pecahan.

Pecahan tidak harus berukuran sama. Lebih penting untuk menyeimbangkan jumlah permintaan. Beberapa pecahan mungkin berukuran besar, namun setiap item di dalamnya memiliki jumlah operasi akses yang rendah. Pecahan lain mungkin lebih kecil, tetapi setiap item dalam pecahan diakses lebih sering. Penting juga memastikan bahwa sebuah shard tidak melebihi batas skala kapasitas dan sumber daya pemrosesan pada penyimpanan data.

Hindari membuat partisi panas yang dapat memengaruhi performa dan ketersediaan. Misalnya, jika Anda menggunakan huruf pertama nama pelanggan, itu dapat membuat distribusi yang tidak seimbang karena beberapa huruf lebih umum daripada yang lain. Sebagai gantinya, gunakan hash pengidentifikasi pelanggan untuk mendistribusikan data secara merata di seluruh partisi.

Pilih kunci sharding yang meminimalkan kebutuhan masa depan untuk membagi pecahan besar, menggabungkan pecahan kecil menjadi partisi yang lebih besar, atau mengubah skema. Operasi ini memakan waktu dan mungkin mengharuskan Anda untuk mengambil satu atau beberapa pecahan offline.

Jika pecahan direplikasi, Anda dapat menjaga beberapa replika tetap online saat yang lain dipisahkan, digabungkan, atau dikonfigurasi ulang. Namun, sistem mungkin membatasi operasi yang dapat dilakukan selama konfigurasi ulang. Misalnya, data dalam replika mungkin ditandai sebagai baca-saja untuk mencegah inkonsistensi data.

Untuk informasi selengkapnya, lihat Pola sharding.

Pemartisian vertikal

Penggunaan yang paling umum untuk partisi vertikal adalah mengurangi I/O dan biaya performa yang terkait dengan pengambilan item yang sering diakses. Gambar berikut menunjukkan contoh pemartisian vertikal. Dalam contoh ini, properti item yang berbeda disimpan dalam partisi yang berbeda. Satu partisi menyimpan data yang diakses lebih sering, termasuk nama produk, deskripsi, dan harga. Partisi lain menyimpan data inventori, termasuk jumlah stok dan tanggal pesanan terakhir.

Dalam contoh ini, aplikasi secara teratur mengkueri nama produk, deskripsi, dan harga saat menampilkan detail produk kepada pelanggan. Jumlah stok dan tanggal pesanan terakhir berada dalam partisi terpisah karena kedua item ini biasanya digunakan bersama-sama.

Lihat keuntungan partisi vertikal berikut:

Anda dapat memisahkan data yang bergerak relatif lambat (nama produk, deskripsi, dan harga) dari data yang lebih dinamis (tingkat stok dan tanggal pesanan terakhir). Data yang bergerak lambat adalah kandidat yang baik bagi aplikasi untuk di-cache dalam memori.
Anda dapat menyimpan data sensitif dalam partisi terpisah dengan kontrol keamanan tambahan.
Pemartisian vertikal dapat mengurangi jumlah akses bersamaan yang diperlukan.

Pemartisian vertikal beroperasi di tingkat entitas dalam penyimpanan data, sebagian menormalkan entitas untuk memecahnya dari item lebar ke sekumpulan item sempit . Ini sangat cocok untuk penyimpanan data berorientasi kolom, seperti HBase dan Cassandra. Jika data dalam kumpulan kolom tidak mungkin berubah, pertimbangkan untuk menggunakan penyimpanan kolom di SQL Server.

Pemartisian fungsional

Ketika konteks terikat dapat diidentifikasi untuk setiap area bisnis yang berbeda dalam aplikasi, pemartisian fungsi dapat meningkatkan isolasi dan performa akses data. Penggunaan umum lainnya untuk pemartisian fungsi adalah memisahkan data baca-tulis dari data baca-saja. Gambar berikut menunjukkan gambaran umum pemartisian fungsional yang memiliki data inventori yang dipisahkan dari data pelanggan.

Strategi partisi ini dapat membantu mengurangi ketidakcocokan akses data di berbagai bagian sistem.

Desain partisi untuk skalabilitas

Sangat penting untuk mempertimbangkan ukuran dan beban kerja untuk setiap partisi. Seimbangkan sehingga data didistribusikan untuk mencapai skalabilitas maksimum. Namun, Anda juga harus mempartisi data sehingga tidak melebihi batas penskalaan penyimpanan partisi tunggal.

Ikuti langkah-langkah ini saat Anda merancang partisi untuk skalabilitas:

Analisis aplikasi untuk memahami pola akses data, seperti ukuran kumpulan hasil yang dikembalikan setiap kueri, frekuensi akses, latensi yang melekat, dan persyaratan pemrosesan komputasi sisi server. Dalam banyak kasus, beberapa entitas utama menuntut sebagian besar sumber daya pemrosesan.
Gunakan analisis ini untuk menentukan target skalabilitas saat ini dan di masa mendatang, seperti ukuran data dan beban kerja. Kemudian distribusikan data di seluruh partisi untuk memenuhi target skalabilitas. Untuk pemartisian horizontal, pilih kunci shard yang tepat untuk memastikan distribusi yang merata. Untuk informasi selengkapnya, lihat Pola sharding.
Pastikan bahwa setiap partisi memiliki sumber daya yang cukup untuk menangani persyaratan skalabilitas dalam hal ukuran dan throughput data. Tergantung pada penyimpanan data, mungkin ada batasan untuk setiap partisi pada jumlah ruang penyimpanan, daya pemrosesan, atau bandwidth jaringan. Jika persyaratan cenderung melebihi batas ini, Anda mungkin perlu menyempurnakan strategi partisi Anda atau membagi data lebih lanjut. Anda mungkin perlu menggabungkan dua strategi atau lebih.
Pantau sistem untuk memverifikasi bahwa data didistribusikan seperti yang diharapkan dan bahwa partisi dapat menangani beban. Penggunaan aktual tidak selalu cocok dengan apa yang diprediksi analisis. Anda mungkin harus menyeimbangkan ulang partisi atau mendesain ulang beberapa bagian sistem untuk menghasilkan keseimbangan yang diperlukan.

Beberapa lingkungan cloud mengalokasikan sumber daya berdasarkan batas infrastruktur. Pastikan bahwa batas batas yang Anda pilih memberikan ruang yang cukup untuk mengantisipasi pertumbuhan volume data, penyimpanan data, daya pemrosesan, dan bandwidth.

Misalnya, jika Anda menggunakan Azure Table Storage, ada batasan volume permintaan yang dapat ditangani satu partisi dalam jangka waktu tertentu. Untuk informasi selengkapnya, lihat Skalabilitas dan target performa untuk akun penyimpanan standar. Shard yang sibuk mungkin membutuhkan lebih banyak sumber daya daripada yang bisa ditangani oleh satu partisi. Anda mungkin perlu mempartisi ulang pecahan untuk menyebarkan beban kerja. Jika ukuran total atau throughput tabel ini melebihi kapasitas akun penyimpanan, Anda mungkin perlu membuat lebih banyak akun penyimpanan dan menyebarkan tabel di seluruh akun ini.

Mendesain partisi untuk performa kueri

Anda dapat meningkatkan performa kueri dengan menggunakan himpunan data kecil dan menjalankan kueri paralel. Setiap partisi harus berisi proporsi kecil dari seluruh himpunan data. Pengurangan volume ini dapat meningkatkan performa kueri. Namun, pemartisian bukanlah alternatif untuk desain dan konfigurasi database yang sesuai. Pastikan Anda menerapkan indeks yang diperlukan.

Ikuti langkah-langkah ini saat Anda merancang partisi untuk performa kueri:

Periksa persyaratan dan performa aplikasi.
- Gunakan persyaratan bisnis untuk menentukan kueri penting yang harus selalu berkinerja cepat.
- Pantau sistem untuk mengidentifikasi kueri yang berkinerja lambat.
- Tentukan kueri yang paling sering dijalankan. Bahkan jika satu kueri memiliki biaya minimal, konsumsi sumber daya kumulatif bisa signifikan.
Partisi data yang menyebabkan performa lambat.
- Batasi ukuran setiap partisi sehingga waktu respons kueri berada dalam target.
- Jika Anda menggunakan partisi horizontal, rancang kunci shard sehingga aplikasi dapat dengan mudah memilih partisi yang sesuai. Spesifikasi ini mencegah kueri memindai setiap partisi.
- Pertimbangkan lokasi partisi. Cobalah untuk menyimpan data dalam partisi yang secara geografis dekat dengan aplikasi dan pengguna yang mengaksesnya.
Jika entitas memiliki persyaratan performa throughput dan kueri, gunakan pemartisian fungsional yang didasarkan pada entitas tersebut. Jika alokasi ini masih tidak memenuhi persyaratan, Anda dapat menambahkan partisi horizontal. Strategi partisi tunggal biasanya memadai, tetapi dalam beberapa kasus, lebih efisien untuk menggabungkan kedua strategi.
Jalankan kueri secara paralel di seluruh partisi untuk meningkatkan performa.

Rancang partisi untuk ketersediaan

Data partisi untuk meningkatkan ketersediaan aplikasi. Pemartisian memastikan bahwa seluruh himpunan data tidak memiliki satu titik kegagalan, dan Anda dapat mengelola subset himpunan data secara independen.

Pertimbangkan faktor-faktor berikut yang memengaruhi ketersediaan:

Tentukan kekritisan data. Identifikasi data bisnis penting, seperti transaksi, dan data operasional yang kurang penting, seperti file log.

Simpan data penting dalam partisi yang sangat tersedia, dan buat rencana pencadangan yang sesuai.
Tetapkan prosedur manajemen dan pemantauan terpisah untuk himpunan data yang berbeda.
Tempatkan data yang memiliki tingkat kekritisan yang sama dalam partisi yang sama sehingga dapat dicadangkan pada frekuensi yang sama. Misalnya, Anda mungkin perlu mencadangkan partisi yang menyimpan data transaksi lebih sering daripada partisi yang menyimpan informasi log atau pelacakan.

Mengelola partisi individual. Desain partisi untuk mendukung manajemen dan pemeliharaan independen. Praktik ini memberikan beberapa keuntungan, misalnya:

Jika partisi gagal, partisi dapat dipulihkan secara independen tanpa aplikasi yang mengakses data di partisi lain.
Pemartisian data berdasarkan area geografis memungkinkan tugas pemeliharaan terjadwal terjadi pada jam tidak sibuk untuk setiap lokasi. Pastikan partisi tidak terlalu besar sehingga mencegah pemeliharaan terencana selesai selama periode ini.

Replikasi data penting di seluruh partisi. Strategi ini meningkatkan ketersediaan dan performa tetapi juga dapat memperkenalkan masalah konsistensi. Dibutuhkan waktu untuk menyinkronkan perubahan dengan setiap replika. Selama sinkronisasi, partisi yang berbeda berisi nilai data yang berbeda.

Mengoptimalkan kode aplikasi untuk menggunakan partisi

Pemartisian menambah kompleksitas pada desain dan pengembangan sistem Anda. Data partisi sebagai bagian mendasar dari desain sistem Anda meskipun sistem awalnya hanya berisi satu partisi. Jika Anda memperlakukan pemartisian sebagai sesuatu yang dipikirkan belakangan, itu menantang karena Anda sudah memiliki sistem yang sedang berjalan untuk dipertahankan. Anda mungkin:

Harus mengubah logika akses data.
Harus memigrasikan sejumlah besar data yang ada untuk mendistribusikannya di seluruh partisi.
Mengalami tantangan karena pengguna berharap untuk terus menggunakan sistem selama migrasi.

Dalam beberapa kasus, pemartisian tidak penting karena himpunan data awal kecil dan satu server dapat dengan mudah menanganinya. Beberapa beban kerja dapat berjalan tanpa partisi, tetapi banyak sistem komersial perlu diperluas saat jumlah pengguna meningkat.

Beberapa penyimpanan data kecil juga mendapat manfaat dari partisi. Misalnya, ratusan klien bersamaan mungkin mengakses penyimpanan data kecil. Jika Anda mempartisi data dalam situasi ini, ini dapat membantu mengurangi ketidakcocokan dan meningkatkan throughput.

Pertimbangkan poin-poin berikut saat Anda merancang skema pemartisian data:

Minimalkan operasi akses data lintas partisi. Cobalah untuk menyimpan data untuk operasi database yang paling umum bersama-sama dalam partisi untuk meminimalkan operasi akses data lintas partisi. Ini bisa lebih memakan waktu untuk mengkueri di seluruh partisi daripada mengkueri dalam satu partisi. Tetapi mengoptimalkan partisi untuk satu set kueri mungkin berdampak buruk pada kumpulan kueri lainnya. Jika Anda harus mengkueri di seluruh partisi, minimalkan waktu kueri dengan menjalankan kueri paralel dan menggabungkan hasil dalam aplikasi. Dalam beberapa kasus, Anda tidak dapat menggunakan pendekatan ini, misalnya jika hasil dari satu kueri digunakan dalam kueri berikutnya.

Replikasikan data referensi statis. Jika kueri menggunakan data referensi yang relatif statis, seperti tabel kode pos atau daftar produk, pertimbangkan untuk mereplikasi data ini di semua partisi untuk mengurangi operasi pencarian terpisah di partisi yang berbeda. Pendekatan ini juga dapat mengurangi kemungkinan data referensi berubah menjadi dataset aktif dengan lalu lintas tinggi dari seluruh sistem. Ada biaya tambahan yang terkait dengan sinkronisasi perubahan pada data referensi.

Minimalkan gabungan lintas partisi. Jika memungkinkan, minimalkan persyaratan untuk integritas referensial di seluruh partisi vertikal dan fungsional. Dalam skema ini, aplikasi bertanggung jawab untuk mempertahankan integritas referensial di seluruh partisi. Kueri yang menggabungkan data di beberapa partisi tidak efisien karena aplikasi biasanya melakukan kueri berturut-turut yang didasarkan pada kunci dan kemudian kunci asing. Sebagai gantinya, pertimbangkan untuk mereplikasi atau mendenormalisasi data yang relevan. Jika gabungan lintas partisi diperlukan, jalankan kueri paralel melalui partisi dan gabungkan data dalam aplikasi.

Menerima konsistensi akhir. Mengevaluasi apakah konsistensi yang kuat adalah persyaratan. Pendekatan umum dalam sistem terdistribusi adalah menerapkan konsistensi akhir. Data di setiap partisi diperbarui secara terpisah, dan logika aplikasi memastikan bahwa pembaruan berhasil diselesaikan. Logika aplikasi juga menangani inkonsistensi yang terjadi saat mengkueri data selama operasi konsistensi akhirnya berjalan.

Pertimbangkan cara kueri menemukan partisi yang tepat. Jika kueri harus memindai semua partisi untuk menemukan data yang diperlukan, kueri tersebut secara signifikan memengaruhi performa, bahkan ketika beberapa kueri paralel berjalan. Dengan pemartisian vertikal dan fungsi, kueri dapat menentukan partisi. Di sisi lain, pemartisian horizontal dapat membuat menemukan item sulit karena setiap pecahan memiliki skema yang sama. Solusi umumnya adalah mempertahankan peta yang digunakan untuk mencari lokasi pecahan item. Terapkan peta ini dalam logika sharding aplikasi. Ini juga dapat dipertahankan oleh penyimpanan data jika penyimpanan data mendukung sharding transparan.

Seimbangkan kembali partisi secara berkala. Dengan pemartisian horizontal, menyeimbangkan ulang pecahan dapat membantu mendistribusikan data secara merata berdasarkan ukuran dan beban kerja. Seimbangkan kembali pecahan untuk meminimalkan hotspot, memaksimalkan performa kueri, dan mengatasi batasan penyimpanan fisik. Tugas ini rumit dan sering memerlukan alat atau proses kustom.

Mereplikasi partisi. Replikasi setiap partisi untuk memberikan perlindungan tambahan terhadap kegagalan. Jika satu replika gagal, kueri diarahkan ke salinan yang berfungsi.

Memperluas skalabilitas ke tingkat yang berbeda. Jika Anda mencapai batas fisik strategi partisi, Anda mungkin perlu memperluas skalabilitas ke tingkat yang berbeda. Misalnya, jika partisi berada di tingkat database, Anda mungkin perlu menemukan atau mereplikasi partisi dalam beberapa database. Jika partisi sudah berada di tingkat database, dan ada batasan fisik, Anda mungkin perlu menemukan atau mereplikasi partisi di beberapa akun hosting.

Hindari transaksi yang mengakses data dalam beberapa partisi. Beberapa penyimpanan data menerapkan konsistensi transaksional dan integritas untuk operasi yang memodifikasi data tetapi hanya ketika data terletak dalam satu partisi. Jika Anda memerlukan dukungan transaksi di beberapa partisi, terapkan sebagai bagian dari logika aplikasi Anda karena sebagian besar sistem partisi tidak memberikan dukungan asli.

Semua penyimpanan data memerlukan beberapa manajemen operasional dan aktivitas pemantauan. Tugas-tugas ini termasuk memuat data, mencadangkan dan memulihkan data, mengatur ulang data, dan memastikan bahwa sistem berkinerja dengan benar dan efisien.

Pertimbangkan faktor-faktor berikut yang memengaruhi manajemen operasional:

Terapkan tugas manajemen dan operasional yang sesuai saat data dipartisi. Tugas-tugas ini mungkin mencakup pencadangan dan pemulihan, pengarsipan data, pemantauan sistem, dan tugas administratif lainnya. Misalnya, mungkin sulit untuk mempertahankan konsistensi logis selama operasi pencadangan dan pemulihan.
Muat data ke dalam beberapa partisi, dan tambahkan data baru yang berasal dari sumber lain. Beberapa alat dan utilitas mungkin tidak mendukung operasi data pecahan, seperti memuat data ke dalam partisi yang benar.
Mengarsipkan dan menghapus data secara teratur. Untuk mencegah pertumbuhan partisi yang berlebihan, arsipkan dan hapus data setiap bulan. Anda mungkin perlu mengubah data agar sesuai dengan skema arsip yang berbeda.
Temukan masalah integritas data. Pertimbangkan untuk menjalankan proses berkala untuk menemukan masalah integritas data, seperti data dalam satu partisi yang mereferensikan informasi yang hilang di partisi lain. Proses ini dapat secara otomatis mencoba memperbaiki masalah ini atau membuat laporan untuk peninjauan manual.

Penyeimbangan ulang partisi

Saat sistem matang, Anda mungkin harus menyesuaikan skema partisi. Misalnya, partisi individual mungkin mulai menerima volume lalu lintas yang tidak proporsional dan menjadi terlalu sibuk, yang menyebabkan persaingan yang berlebihan. Atau Anda mungkin telah meremehkan volume data di beberapa partisi, yang menyebabkan partisi mendekati batas kapasitas.

Beberapa penyimpanan data, seperti Azure Cosmos DB, dapat menyeimbangkan kembali partisi secara otomatis. Dalam kasus lain, Anda dapat menyeimbangkan kembali partisi dalam dua tahap:

Tentukan strategi partisi baru.
- Partisi mana yang perlu dipisahkan atau digabungkan?
- Apa kunci partisi baru?
Migrasikan data dari skema partisi lama ke set partisi baru.

Anda mungkin perlu membuat partisi tidak tersedia saat Anda merelokasi data, yang disebut migrasi offline. Bergantung pada penyimpanan data, Anda mungkin memigrasikan data antar partisi saat digunakan. Teknik ini disebut migrasi online.

Migrasi offline

Migrasi offline mengurangi kemungkinan pertikaian terjadi. Untuk melakukan migrasi offline:

Tandai partisi sebagai offline. Anda dapat menandai partisi sebagai baca-saja sehingga aplikasi masih dapat membaca data saat Anda memindahkannya.
Pisahkan-gabungkan dan pindahkan data ke partisi baru.
Memverifikasi data.
Bawa partisi baru online.
Hapus partisi lama.

Migrasi online

Migrasi online lebih kompleks tetapi kurang mengganggu dibandingkan dengan migrasi offline. Prosesnya mirip dengan migrasi offline, tetapi Anda tidak menandai partisi asli sebagai offline. Tergantung pada granularitas proses migrasi, misalnya per item versus per shard, kode akses data di aplikasi klien harus membaca dan menulis data yang ada di dua lokasi, yaitu partisi asli dan partisi baru.

Dukungan Azure

Bagian berikut ini menjelaskan rekomendasi untuk mempartisi data yang disimpan di layanan Azure.

Partisi pada Azure SQL Database

Database SQL tunggal memiliki batas volume data yang dapat dimuatnya. Throughput dibatasi oleh faktor arsitektur dan jumlah koneksi bersamaan yang didukungnya.

kumpulan Elastis mendukung penskalaan horizontal untuk database SQL. Gunakan kumpulan elastis untuk mempartisi data Anda menjadi pecahan yang tersebar di beberapa database SQL. Anda juga dapat menambahkan atau menghapus pecahan saat volume data bertambah dan menyusut. Kumpulan elastis juga dapat membantu mengurangi ketidakcocokan dengan mendistribusikan beban di seluruh database.

Setiap shard diimplementasikan sebagai database SQL. Pecahan dapat menampung lebih dari satu himpunan data. Setiap himpunan data disebut shardlet. Setiap database memiliki metadata yang menjelaskan shardlet yang dikandungnya. Shardlet dapat berupa item data tunggal atau sekelompok item yang berbagi kunci shardlet yang sama. Misalnya, dalam aplikasi multipenyewa, kunci shardlet dapat menjadi ID penyewa, dan semua data untuk penyewa dapat berada di shardlet yang sama.

Aplikasi bertanggung jawab untuk mengaitkan himpunan data dengan kunci shardlet. Database SQL terpisah bertindak sebagai pengelola peta pembagian data global. Database ini memiliki daftar semua pecahan dan shardlet dalam sistem. Aplikasi terhubung ke database pengelola peta shard untuk mendapatkan salinan peta shard. Ini menyimpan peta shard secara lokal dan menggunakan peta untuk merutekan permintaan data ke shard yang sesuai. Fungsionalitas ini disembunyikan di balik serangkaian API yang terkandung dalam pustaka klien fitur Elastic Database dari SQL Database, yang tersedia untuk Java dan .NET.

Untuk informasi selengkapnya tentang kumpulan elastis, lihat Penskalaan keluar dengan SQL Database.

Untuk mengurangi latensi dan meningkatkan ketersediaan, Anda dapat mereplikasi database manajer peta shard global. Dengan tingkat harga premium, Anda dapat mengonfigurasi replikasi geografis aktif untuk terus menyalin data ke database di berbagai wilayah.

Atau, gunakan SQL Data Sync untuk SQL Database atau Azure Data Factory untuk mereplikasi database pengelola peta shard di seluruh wilayah. Bentuk replikasi ini berjalan secara berkala dan lebih sesuai jika peta shard jarang berubah dan tidak memerlukan tingkat langganan premium.

Elastic Database menyediakan dua skema untuk memetakan data ke shardlet dan menyimpannya dalam pecahan:

Peta shard daftar mengaitkan satu kunci dengan shardlet. Misalnya, dalam sistem multipenyewa, data untuk setiap penyewa dapat dikaitkan dengan kunci unik dan disimpan dalam shardletnya sendiri. Untuk menjamin isolasi, setiap shardlet dapat dipegang dalam pecahannya sendiri.

Unduh file Visio dari diagram ini.
Peta rentang shard mengasosiasikan sekumpulan nilai kunci yang bersebelahan dengan shardlet. Misalnya, Anda dapat mengelompokkan data untuk sekumpulan penyewa, masing-masing dengan kuncinya sendiri, dalam shardlet yang sama. Skema ini lebih murah daripada peta 'list shard' karena penyewa berbagi penyimpanan data, tetapi menawarkan isolasi yang lebih sedikit.

Mengunduh file Visio diagram ini

Satu shard dapat berisi data untuk beberapa shardlet. Misalnya, Anda dapat menggunakan shardlet daftar untuk menyimpan data untuk penyewa yang tidak bersebelahan yang berbeda dalam shard yang sama. Anda juga dapat menggabungkan shardlet rentang dan shardlet daftar dalam shard yang sama, tetapi kemudian diakses melalui peta yang berbeda. Diagram berikut menunjukkan pendekatan ini:

Unduh file Visio dari diagram ini.

Dengan kumpulan elastis, Anda dapat menambahkan dan menghapus pecahan saat volume data tumbuh dan menyusut. Aplikasi klien dapat membuat dan menghapus shard secara dinamis dan dengan cara yang transparan memperbarui pengelola peta shard. Namun, menghapus shard adalah operasi destruktif yang juga memerlukan penghapusan semua data dalam shard tersebut.

Jika aplikasi perlu membagi shard menjadi dua pecahan terpisah atau menggabungkan pecahan, gunakan alat split-merge . Alat ini berjalan sebagai layanan web Azure dan memigrasikan data dengan aman di antara pecahan.

Skema partisi dapat secara signifikan memengaruhi performa sistem Anda. Ini juga dapat memengaruhi tingkat di mana pecahan harus ditambahkan atau dihapus, atau data tersebut harus dipartisi ulang di seluruh pecahan. Pertimbangkan poin-poin berikut:

Mengelompokkan data yang digunakan bersama dalam shard yang sama, dan menghindari operasi yang mengakses data dari beberapa pecahan. Shard adalah database SQL sendiri, dan join lintas database harus dilakukan di sisi klien saat operasi mengakses beberapa shard.

Meskipun SQL Database tidak mendukung gabungan lintas database, Anda dapat menggunakan alat Elastic Database untuk melakukan kueri multi-pecahan. Kueri multi-pecahan mengirimkan kueri individual ke setiap database dan menggabungkan hasilnya.
Merancang sistem yang tidak memiliki dependensi antara pecahan. Batasan integritas referensial, pemicu, dan prosedur tersimpan dalam satu database tidak dapat mereferensikan objek di database lain.
Pertimbangkan untuk mereplikasi data di seluruh pecahan jika Anda memiliki data referensi yang sering digunakan oleh kueri. Pendekatan ini dapat menghilangkan kebutuhan untuk menggabungkan data di seluruh database. Idealnya, data tersebut harus statis atau bergerak lambat untuk meminimalkan upaya replikasi dan mengurangi kemungkinan data menjadi basi.
Gunakan skema yang sama untuk shardlet yang berada dalam peta shard yang sama. Panduan ini tidak diberlakukan oleh SQL Database, tetapi manajemen dan kueri data kompleks jika setiap shardlet memiliki skema yang berbeda. Sebagai gantinya, buat peta shard terpisah untuk setiap skema. Anda dapat menyimpan data milik shardlet yang berbeda dalam shard yang sama.
Simpan data dalam pecahan yang sama atau terapkan konsistensi akhir jika logika bisnis Anda perlu melakukan transaksi. Operasional transaksi hanya didukung untuk data yang berada dalam shard, dan bukan antar shard. Transaksi dapat mencakup shardlet jika itu adalah bagian dari shard yang sama.
Tempatkan pecahan yang dekat dengan pengguna yang mengakses data di pecahan tersebut. Strategi ini membantu mengurangi latensi.
Hindari memiliki kombinasi pecahan yang sangat aktif dan relatif tidak aktif. Cobalah untuk menyebarkan beban secara merata di seluruh pecahan. Anda mungkin harus melakukan hashing pada kunci sharding. Jika Anda menetapkan lokasi pecahan secara geografis, pastikan kunci yang di-hash memetakan ke shardlet yang disimpan dalam pecahan yang terletak dekat dengan pengguna yang mengakses data tersebut.

Pembagian di Azure Blob Storage

Dengan Blob Storage, Anda dapat menyimpan objek biner besar. Gunakan blob blok dalam skenario yang mengharuskan Anda mengunggah atau mengunduh data dalam volume besar dengan cepat. Gunakan blob halaman untuk aplikasi yang memerlukan akses acak, bukan serial, ke bagian data.

Setiap block blob atau page blob disimpan dalam kontainer di akun penyimpanan Azure. Gunakan kontainer untuk mengelompokkan blob terkait yang memiliki persyaratan keamanan yang sama. Pengelompokan ini logis daripada fisik. Di dalam kontainer, setiap blob memiliki nama yang unik.

Kunci partisi untuk blob adalah nama akun, nama kontainer, dan nama blob. Kunci partisi digunakan untuk mempartisi data ke dalam rentang. Rentang ini dibagi rata beban kerjanya di seluruh sistem. Blob dapat didistribusikan di banyak server untuk menskalakan akses ke server tersebut. Satu blob hanya dapat dilayani oleh satu server.

Jika skema penamaan Anda menggunakan tanda waktu atau pengidentifikasi numerik, itu dapat menyebabkan lalu lintas yang berlebihan ke satu partisi. Ini mencegah sistem dari penyeimbangan beban secara efektif. Misalnya, jika Anda memiliki operasi harian yang menggunakan objek blob dengan tanda waktu, seperti yyyy-mm-dd, semua lalu lintas untuk operasi tersebut masuk ke satu server partisi. Sebagai gantinya, awali nama dengan hash tiga digit. Untuk informasi selengkapnya, lihat Konvensi penamaan partisi.

Tindakan menulis satu blok atau halaman bersifat atomik, tetapi operasi yang melibatkan banyak blok, halaman, atau blob tidak bersifat atomik. Jika Anda perlu memastikan konsistensi saat operasi tulis dilakukan di seluruh blok, halaman, dan blob, keluarkan kunci tulis dengan menggunakan sewa blob.

Pertimbangan

Pemartisian data memperkenalkan beberapa tantangan dan kompleksitas yang perlu Anda pertimbangkan.

Sinkronisasi data antara partisi mungkin menjadi tantangan. Pastikan bahwa pembaruan atau perubahan pada satu partisi disebarkan ke partisi lain secara tepat waktu dan konsisten.
Proses failover dan pemulihan bencana menjadi kompleks ketika Anda perlu mengoordinasikan pencadangan dan pemulihan beberapa partisi. Masalah integritas data dapat muncul jika beberapa partisi atau cadangannya rusak atau tidak tersedia.
Pemartisian data dapat memengaruhi performa dan keandalan jika Anda perlu melakukan kueri di seluruh partisi, dan ketika Anda menyetel ulang partisi jika data tumbuh tidak merata.