Rekomendasi untuk pemartisian data

Artikel
11/15/2023

Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:

RE:06	Terapkan strategi penskalakan yang tepat waktu dan andal di tingkat aplikasi, data, dan infrastruktur.

Panduan terkait: Penskalakan

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.

Strategi desain utama

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.

Catatan

Dalam artikel ini, istilah pemartisian berarti proses membagi data secara fisik ke dalam penyimpanan data yang terpisah. Ini berbeda dari partisi tabel SQL Server.

Mengapa data partisi?

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.
Mencocokan 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 di partisi tersebut yang tidak tersedia. Operasi berlanjut di partisi lain. Pertimbangan ini kurang relevan untuk penyimpanan data platform as a service (PaaS) terkelola karena memiliki redundansi bawaan.

Partisi desain

Ada tiga strategi khas untuk pemartisian data:

Pemartisian horizontal (sering disebut sharding). Dalam strategi ini, setiap partisi adalah penyimpanan data yang 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 di satu partisi vertikal dan bidang yang lebih jarang diakses di partisi lain.
Pemartisian fungsional. Dalam strategi ini, data dikumpulkan sesuai dengan bagaimana setiap konteks terikat dalam sistem menggunakan data. Misalnya, sistem e-niaga mungkin menyimpan data faktur di satu partisi dan data inventaris produk di partisi lain.

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

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 pecahan menyimpan data untuk rentang kunci pecahan yang berdekatan (A-G dan H-Z), yang diatur menurut abjad. Saat Anda melakukan sharding, itu menyebarkan beban ke lebih banyak komputer, yang mengurangi ketidakcocokan dan meningkatkan performa.

Faktor terpenting adalah kunci sharding yang Anda pilih. Mungkin sulit untuk mengubah kunci setelah sistem beroperasi. Kuncinya harus memastikan bahwa data dipartisi untuk menyebarkan beban kerja secara merata di seluruh pecahan.

Pecahan tidak harus berukuran sama. Lebih penting untuk menyeimbangkan jumlah permintaan. Beberapa pecahan mungkin besar, tetapi setiap item dalam shard memiliki jumlah operasi akses yang rendah. Pecahan lain mungkin lebih kecil, tetapi setiap item dalam pecahan diakses lebih sering. Penting juga untuk memastikan bahwa satu shard tidak melebihi batas skala, dalam hal kapasitas dan sumber daya pemrosesan, dari 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.

Partisi 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 di 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.

Partisi vertikal beroperasi pada tingkat entitas dalam penyimpanan data, menormalkan sebagian entitas untuk memecahnya dari item lebar ke set 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 fungsional adalah untuk 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 pemartisian ini dapat membantu mengurangi ketidaksesuaian akses data di berbagai bagian sistem.

Partisi desain 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. Lalu distribusikan data ke 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 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. Pecahan yang sibuk mungkin memerlukan lebih banyak sumber daya daripada yang dapat ditangani oleh satu partisi. Anda mungkin perlu mempartisi ulang shard untuk menyebarkan beban. 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 dijalankan dengan cepat.
- Pantau sistem untuk mengidentifikasi kueri yang berkinerja lambat.
- Tentukan kueri yang paling sering berkinerja. 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 sesuai 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.

Partisi desain 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 pengelogan 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 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.

Pertimbangan desain aplikasi

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 mengatasi pemartisian sebagai setelahnya, itu menantang karena Anda sudah memiliki sistem langsung 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 mendesain skema partisi data:

Meminimalkan 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 melakukan kueri di seluruh partisi, minimalkan waktu kueri dengan menjalankan kueri paralel dan menggabungkan hasilnya dalam aplikasi. Dalam beberapa kasus, Anda tidak dapat menggunakan pendekatan ini, misalnya jika hasil dari satu kueri digunakan dalam kueri berikutnya.

Replikasi 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 menjadi himpunan data panas dengan lalu lintas yang berat 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 menjaga 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 penggabungan lintas partisi diperlukan, jalankan kueri paralel di atas partisi dan gabungkan data dalam aplikasi.

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

Mempertimbangkan bagaimana kueri menemukan partisi yang benar. 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 pecahan 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 di beberapa database. Jika partisi sudah berada di tingkat database, dan ada batasan fisik, Anda mungkin perlu menemukan atau mereplikasi partisi di beberapa akun hosting.

Menghindari transaksi yang mengakses data dalam banyak 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 termasuk 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.

Partisi penyeimbangan ulang

Ketika sistem matang, Anda mungkin harus menyesuaikan skema partisi. Misalnya, partisi individual mungkin mulai menerima volume lalu lintas yang tidak proporsional dan menjadi panas, yang menyebabkan ketidakcocokan 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 pemartisian 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.
Memisahkan-menggabungkan dan memindahkan data ke partisi baru.
Memverifikasi data.
Membawa partisi baru secara online.
Menghapus 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 item menurut item versus pecahan menurut shard, kode akses data di aplikasi klien mungkin harus membaca dan menulis data yang ada di dua lokasi, partisi asli dan partisi baru.

Fasilitasi Azure

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

Partisi di Azure SQL Database

Database SQL tunggal memiliki batas volume data yang ada di dalamnya. 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 ketidaksesuaian 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 shard global. Database ini memiliki daftar semua shard dan shardlet dalam sistem. Aplikasi ini terhubung ke database manajer 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 dengan SQL Database.

Untuk mengurangi latensi dan meningkatkan ketersediaan, Anda dapat mereplikasi database pengelola 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 cocok jika peta shard jarang berubah dan tidak memerlukan tingkat premium.

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

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

Unduh file Visio dari diagram ini.
Peta shard rentang mengaitkan 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 shard daftar karena penyewa berbagi penyimpanan data, tetapi menyediakan lebih sedikit isolasi.

Mengunduh file Visio dari diagram ini

Satu shard dapat berisi data untuk beberapa shardlet. Misalnya, Anda dapat menggunakan shardlet daftar untuk menyimpan data untuk penyewa yang tidak berdekatan yang berbeda dalam shard yang sama. Anda juga dapat mencampur shardlet rentang dan mencantumkan shardlet dalam shard yang sama, tetapi kemudian ditangani 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 transparan memperbarui manajer peta shard. Namun, menghapus shard adalah operasi destruktif yang juga membutuhkan penghapusan semua data dalam shard tersebut.

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

Skema pemartisian dapat secara signifikan memengaruhi performa sistem Anda. Hal ini juga dapat memengaruhi tingkat letak shard harus ditambahkan atau dihapus, atau data yang harus repartisi di shard. 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 di kanannya sendiri, dan gabungan 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-shard 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 termasuk 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 pecahan yang sama.
Simpan data dalam pecahan yang sama atau terapkan konsistensi akhir jika logika bisnis Anda perlu melakukan transaksi. Operasi transaksi hanya didukung untuk data yang berada dalam pecahan, dan bukan di seluruh pecahan. Transaksi dapat mencakup shardlet jika mereka adalah bagian dari shard yang sama.
Tempatkan shard dekat dengan pengguna yang mengakses data di shard tersebut. Strategi ini membantu mengurangi latensi.
Hindari memiliki kombinasi pecahan yang sangat aktif dan relatif tidak aktif. Cobalah untuk menyebarkan beban secara merata di shard. Anda mungkin harus hash kunci sharding. Jika Anda menemukan pecahan secara geografis, pastikan bahwa kunci yang di-hash memetakan ke shardlet yang disimpan dalam pecahan yang disimpan dekat dengan pengguna yang mengakses data tersebut.

Partisi 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 blob blok atau blob halaman disimpan dalam kontainer di akun penyimpanan Azure. Gunakan kontainer untuk mengelompokkan blob terkait yang memiliki persyaratan keamanan yang sama. Pengelompokan ini bersifat logis dan bukan fisik. Di dalam kontainer, setiap blob memiliki nama unik.

Kunci partisi untuk blob adalah nama akun, nama kontainer, dan nama blob. Kunci partisi digunakan untuk mempartisi data ke dalam rentang. Rentang ini diseimbangkan beban 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 server partisi tunggal. 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 mencakup blok, halaman, atau blob tidak. 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 mengkueri di seluruh partisi, dan ketika Anda menyeimbangkan kembali partisi jika data tumbuh tidak merata.

Daftar periksa keandalan

Lihat kumpulan rekomendasi lengkap.

Daftar periksa keandalan

Bagikan melalui

Rekomendasi untuk pemartisian data