Panduan pemartisian data

Dalam banyak solusi berskala besar, data dibagi menjadi partisi yang dapat dikelola dan diakses secara terpisah. Partisi dapat meningkatkan skalabilitas, mengurangi ketidakcocokan, dan mengoptimalkan performa. Partisi juga dapat memberikan mekanisme untuk pembagian data menurut pola penggunaan. Misalnya, Anda dapat mengarsipkan data yang lebih lama dalam penyimpanan data yang lebih murah.

Namun, strategi partisi harus dipilih dengan hati-hati untuk memaksimalkan keuntungan sambil meminimalkan efek samping.

Mengapa data partisi?

• Meningkatkan skalabilitas. Ketika Anda meningkatkan sistem database tunggal, pada akhirnya akan mencapai batas perangkat keras fisik. Jika Anda membagi data di beberapa partisi, masing-masing dihosting di server terpisah, Anda dapat meluaskan skala sistem hampir tanpa batas.

• Meningkatkan performa. Operasi akses data pada setiap partisi berlangsung pada volume data yang lebih kecil. Jika dilakukan dengan benar, pemartisian dapat 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. Pemartisian menawarkan banyak peluang untuk operasi fine-tuning, memaksimalkan efisiensi administrasi, dan meminimalkan biaya. Misalnya, Anda dapat menentukan strategi yang berbeda untuk manajemen, pemantauan, pencadangan dan pemulihan, dan tugas administratif lainnya berdasarkan pentingnya data di setiap partisi.

• Mencocokan penyimpanan data dengan pola penggunaan. Pemartisian memungkinkan setiap partisi untuk disebarkan pada jenis penyimpanan data yang berbeda, berdasarkan biaya dan fitur bawaan yang ditawarkan oleh penyimpanan data. Misalnya, data biner yang besar dapat disimpan dalam penyimpanan blob, sedangkan data yang lebih terstruktur dapat disimpan dalam database dokumen. Lihat Memilih penyimpanan data yang tepat.

• Meningkatkan ketersediaan. Memisahkan data di beberapa server menghindari satu titik kegagalan. Jika satu instans gagal, hanya data di partisi tersebut yang tidak tersedia. Operasi pada partisi lain dapat berlanjut. Untuk penyimpanan data PaaS terkelola, pertimbangan ini kurang relevan, karena layanan tersebut dirancang dengan redundansi bawaan.

Merancang partisi

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 pecahan dan menyimpan subset data tertentu, seperti semua pesanan untuk kumpulan pelanggan tertentu.

• 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 diagregasi sesuai dengan bagaimana data tersebut digunakan oleh setiap konteks yang dibatasi dalam sistem. Misalnya, sistem e-niaga mungkin menyimpan data faktur di satu partisi dan data inventaris produk di partisi lain.

Strategi-strategi ini dapat digabungkan, dan kami sarankan Anda mempertimbangkan semuanya 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 1 menunjukkan pemartisian horizontal atau sharding. Dalam contoh ini, data inventaris produk dibagi menjadi pecahan berdasarkan kunci produk. Setiap pecahan menyimpan data untuk rentang kunci pecahan yang berdekatan (A-G dan H-Z), yang diatur menurut abjad. Sharding menyebarkan beban ke lebih banyak komputer, yang mengurangi ketidaksesuaian dan meningkatkan performa.

Gambar 1 - Mempartisi data (sharding) secara horizontal berdasarkan kunci partisi.

Faktor yang paling penting adalah pilihan kunci sharding. 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 sangat besar, tetapi setiap item memiliki jumlah operasi akses yang rendah. Pecahan lain mungkin lebih kecil, tetapi setiap item diakses lebih sering. Penting juga untuk memastikan bahwa satu pecahan tidak melebihi batas skala (dalam hal kapasitas dan sumber daya pemrosesan) penyimpanan data.

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

Pilih kunci sharding yang meminimalkan persyaratan di masa mendatang untuk membagi pecahan besar, menggabungkan pecahan kecil menjadi partisi yang lebih besar, atau mengubah skema. Operasi ini bisa sangat memakan waktu, dan mungkin memerlukan satu atau beberapa pecahan offline saat dilakukan.

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

Untuk informasi selengkapnya tentang pemartisian horizontal, lihat pola sharding.

Partisi vertikal

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

Gambar 2 - Mempartisi data secara vertikal dengan pola penggunaannya.

Dalam contoh ini, aplikasi secara teratur menanyakan nama produk, deskripsi, dan harga saat menampilkan detail produk kepada pelanggan. Jumlah stok dan tanggal pemesanan terakhir disimpan di partisi terpisah karena kedua item ini biasanya digunakan bersama.

Keuntungan lain dari pemartisian vertikal:

• Data yang relatif lambat (nama produk, deskripsi, dan harga) dapat dipisahkan dari data yang lebih dinamis (tingkat stok dan tanggal pemesanan terakhir). Data yang bergerak lambat adalah kandidat yang baik untuk aplikasi ke cache dalam memori.

• Data sensitif dapat disimpan di 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, Anda juga dapat mempertimbangkan untuk menggunakan penyimpanan kolom di SQL Server.

Pemartisian fungsional

Jika memungkinkan untuk mengidentifikasi konteks terbatas untuk setiap area bisnis yang berbeda dalam aplikasi, pemartisian fungsional adalah cara untuk meningkatkan isolasi dan performa akses data. Penggunaan umum lainnya untuk pemartisian fungsional adalah untuk memisahkan data baca-tulis dari data baca-saja. Gambar 3 menunjukkan ringkasan pemartisian fungsional di mana data inventaris dipisahkan dari data pelanggan.

Gambar 3 - Mempartisi data secara fungsional dengan konteks atau subdomain yang dibatasi.

Strategi pemartisian ini dapat membantu mengurangi ketidaksesuaian akses data di berbagai bagian sistem.

Merancang partisi untuk skalabilitas

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

Ikuti langkah-langkah ini saat mendesain partisi untuk skalabilitas:

1. Analisis aplikasi untuk memahami pola akses data, seperti ukuran kumpulan hasil yang ditampilkan oleh setiap kueri, frekuensi akses, latensi bawaan, dan persyaratan pemrosesan komputasi sisi server. Dalam banyak kasus, beberapa entitas utama akan menuntut sebagian besar sumber daya pemrosesan.
2. 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, memilih kunci pecahan yang tepat penting untuk memastikan distribusi merata. Untuk informasi selengkapnya, lihat pola sharding.
3. Pastikan setiap partisi memiliki sumber daya yang cukup untuk menangani persyaratan skalabilitas, dalam hal ukuran data dan throughput. Tergantung penyimpanan data, mungkin ada batasan jumlah ruang penyimpanan, daya pemrosesan, atau bandwidth jaringan per partisi. Jika persyaratan cenderung melebihi batas ini, Anda mungkin perlu memperbaiki strategi partisi atau membagi data lebih lanjut, mungkin menggabungkan dua strategi atau lebih.
4. Pantau sistem untuk memverifikasi bahwa data didistribusikan seperti yang diharapkan dan partisi dapat menangani beban. Penggunaan aktual tidak selalu sesuai dengan prediksi analisis. Jika demikian, dimungkinkan untuk menyeimbangkan kembali partisi, atau mendesain ulang beberapa bagian sistem untuk mendapatkan keseimbangan yang diperlukan.

Beberapa lingkungan cloud mengalokasikan sumber daya dalam batasan infrastruktur. Pastikan bahwa batas pembatasan yang Anda pilih memberikan ruang yang cukup untuk setiap pertumbuhan volume data yang diantisipasi, dalam hal penyimpanan data, kekuatan pemrosesan, dan bandwidth.

Misalnya, jika Anda menggunakan penyimpanan tabel Azure, ada batas volume permintaan yang dapat ditangani oleh satu partisi dalam jangka waktu tertentu. (Untuk informasi selengkapnya, lihat Skalabilitas penyimpanan Azure dan target performa.) Shard yang sibuk mungkin memerlukan lebih banyak sumber daya daripada yang dapat ditangani oleh satu partisi. Jika demikian, pecahan mungkin perlu dipartisi ulang untuk menyebarkan beban. Jika ukuran total atau throughput tabel ini melebihi kapasitas akun penyimpanan, Anda mungkin perlu membuat akun penyimpanan tambahan dan menyebarkan tabel ke seluruh akun ini.

Merancang partisi untuk performa kueri

Performa kueri sering kali dapat ditingkatkan menggunakan kumpulan data yang lebih kecil dan dengan menjalankan kueri paralel. Setiap partisi harus berisi sebagian kecil dari seluruh himpunan data. Pengurangan volume ini dapat meningkatkan performa kueri. Namun, partisi bukanlah alternatif untuk merancang dan mengonfigurasi database dengan tepat. Misalnya, pastikan Anda memiliki indeks yang diperlukan.

Ikuti langkah-langkah ini saat mendesain partisi untuk performa kueri:

1. Periksa persyaratan dan performa aplikasi:

   • Gunakan persyaratan bisnis untuk menentukan kueri penting yang harus selalu dijalankan dengan cepat.
   • Pantau sistem untuk mengidentifikasi setiap kueri yang berperforma lambat.
   • Temukan kueri mana yang paling sering dilakukan. Bahkan jika satu kueri memiliki biaya minimal, konsumsi sumber daya kumulatif dapat menjadi signifikan.

2. Partisi data yang menyebabkan performa lambat:

   • Batasi ukuran setiap partisi sehingga waktu respons kueri sesuai target.
   • Jika Anda menggunakan pemartisian horizontal, rancang kunci pecahan agar aplikasi dapat dengan mudah memilih partisi yang tepat. Ini mencegah kueri dari keharusan memindai setiap partisi.
   • Pertimbangkan lokasi partisi. Jika memungkinkan, cobalah untuk menyimpan data di partisi yang secara geografis dekat dengan aplikasi dan pengguna yang mengaksesnya.

3. Jika entitas memiliki persyaratan performa throughput dan kueri, gunakan pemartisian fungsional berdasarkan entitas tersebut. Jika ini masih tidak memenuhi persyaratan, terapkan juga pemartisian horizontal. Dalam kebanyakan kasus, strategi pemartisian tunggal sudah cukup, tetapi dalam beberapa kasus lebih efisien untuk menggabungkan kedua strategi.

4. Pertimbangkan untuk menjalankan kueri secara paralel di seluruh partisi untuk meningkatkan performa.

Merancang partisi untuk ketersediaan

Mempartisi data dapat meningkatkan ketersediaan aplikasi dengan memastikan bahwa seluruh himpunan data tidak merupakan satu titik kegagalan dan bahwa subset individu dari himpunan data dapat dikelola secara independen.

Pertimbangkan faktor-faktor berikut yang memengaruhi ketersediaan:

Seberapa penting data untuk operasi bisnis. Identifikasi data mana yang merupakan informasi bisnis penting, seperti transaksi, dan data mana yang kurang penting sebagai data operasional, seperti file log.

• Pertimbangkan untuk menyimpan data penting di partisi yang sangat tersedia dengan 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 bersama pada frekuensi yang sesuai. Misalnya, partisi yang menyimpan data transaksi mungkin perlu dicadangkan lebih sering daripada partisi yang menyimpan informasi pengelogan atau pelacakan.

Bagaimana partisi individu dapat dikelola. Merancang partisi untuk mendukung manajemen dan pemeliharaan independen memberikan beberapa keuntungan. Contohnya:

• Jika partisi gagal, partisi dapat dipulihkan secara independen tanpa aplikasi yang mengakses data di partisi lain.

• Mempartisi data berdasarkan area geografis memungkinkan tugas pemeliharaan terjadwal terjadi di luar jam sibuk untuk setiap lokasi. Pastikan bahwa partisi tidak terlalu besar untuk mencegah penyelesaian pemeliharaan terencana selama periode ini.

Apakah akan mereplikasi data penting di seluruh partisi. Strategi ini dapat meningkatkan ketersediaan dan performa, tetapi juga dapat menimbulkan masalah konsistensi. Dibutuhkan waktu untuk menyinkronkan perubahan dengan setiap replika. Selama periode ini, partisi yang berbeda akan berisi nilai data yang berbeda.

Pertimbangan desain aplikasi

Pemartisian menambah kompleksitas pada desain dan pengembangan sistem Anda. Pertimbangkan pemartisian sebagai bagian mendasar dari desain sistem bahkan jika sistem awalnya hanya berisi satu partisi. Jika Anda mengatasi pemartisian sebagai spekulasi, maka akan lebih menantang karena Anda sudah memiliki sistem langsung untuk dipertahankan:

• Logika akses data perlu dimodifikasi.
• Sejumlah besar data yang ada mungkin perlu dimigrasikan, untuk mendistribusikannya di seluruh partisi.
• Pengguna berharap dapat terus menggunakan sistem selama migrasi.

Dalam beberapa kasus, partisi tidak dianggap penting karena himpunan data awal kecil dan dapat dengan mudah ditangani oleh satu server. Ini mungkin berlaku untuk beberapa beban kerja, tetapi banyak sistem komersial perlu diperluas seiring dengan meningkatnya jumlah pengguna.

Selain itu, bukan hanya penyimpanan data besar yang mendapat keuntungan dari partisi. Misalnya, penyimpanan data kecil mungkin banyak diakses oleh ratusan klien secara bersamaan. Mempartisi data dalam situasi ini dapat membantu mengurangi ketidaksesuaian dan meningkatkan throughput.

Pertimbangkan poin-poin berikut saat Anda mendesain skema partisi data:

Meminimalkan operasi akses data lintas partisi. Jika memungkinkan, simpan data untuk operasi database yang paling umum bersama-sama di setiap partisi untuk meminimalkan operasi akses data lintas partisi. Membuat kueri di seluruh partisi bisa lebih memakan waktu daripada membuat kueri dalam satu partisi, tetapi mengoptimalkan partisi untuk satu set kueri mungkin berdampak buruk pada set kueri lainnya. Jika Anda harus melakukan kueri di seluruh partisi, minimalkan waktu kueri dengan menjalankan kueri paralel dan menggabungkan hasilnya dalam aplikasi. (Pendekatan ini mungkin tidak dapat dilakukan dalam beberapa kasus, seperti ketika hasil dari satu kueri digunakan dalam kueri berikutnya.)

Pertimbangkan untuk mereplikasi 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 padat dari seluruh sistem. Namun, ada biaya tambahan yang terkait dengan sinkronisasi setiap 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 perlu melakukan kueri berurutan berdasarkan kunci lalu 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. Evaluasi apakah konsistensi yang kuat sebenarnya merupakan persyaratan. Pendekatan umum dalam sistem terdistribusi adalah untuk menerapkan konsistensi akhir. Data di setiap partisi diperbarui secara terpisah, dan logika aplikasi memastikan bahwa semua pembaruan berhasil diselesaikan. Ini juga menangani inkonsistensi yang dapat timbul dari kueri data saat operasi yang pada akhirnya konsisten berjalan.

Mempertimbangkan bagaimana kueri menemukan partisi yang benar. Jika kueri harus memindai semua partisi untuk menemukan data yang diperlukan, ada dampak signifikan pada performa, bahkan ketika beberapa kueri paralel sedang berjalan. Dengan pemartisian vertikal dan fungsional, kueri secara alami dapat menentukan partisi. Sebaliknya, pemartisian horizontal dapat mempersulit pencarian item, karena setiap pecahan memiliki skema yang sama. Solusi khas untuk mempertahankan peta yang digunakan untuk mencari lokasi pecahan untuk item tertentu. Peta ini dapat diterapkan dalam logika sharding aplikasi, atau dikelola oleh penyimpanan data jika mendukung sharding transparan.

Mempertimbangkan untuk menyeimbangkan kembali pecahan secara berkala. Dengan partisi horizontal, penyeimbangan ulang pecahan dapat membantu mendistribusikan data secara merata menurut ukuran dan beban kerja untuk meminimalkan hotspot, memaksimalkan performa kueri, dan mengatasi keterbatasan penyimpanan fisik. Namun, ini adalah tugas kompleks yang sering kali memerlukan penggunaan alat atau proses kustom.

Mereplikasi partisi. Jika Anda mereplikasi setiap partisi, langkah ini memberikan perlindungan tambahan terhadap kegagalan. Jika satu replika gagal, kueri dapat diarahkan ke salinan yang berfungsi.

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 pada tingkat database, dan keterbatasan fisik menjadi masalah, itu mungkin berarti Anda perlu menemukan atau mereplikasi partisi di beberapa akun hosting.

Menghindari transaksi yang mengakses data dalam banyak partisi. Beberapa penyimpanan data menerapkan konsistensi dan integritas transaksional untuk operasi yang mengubah data, tetapi hanya jika data tersebut terletak di satu partisi. Jika Anda memerlukan dukungan transaksional di beberapa partisi, Anda mungkin perlu menerapkan ini sebagai bagian dari logika aplikasi Anda karena sebagian besar sistem pemartisian tidak menyediakan dukungan asli.

Semua penyimpanan data memerlukan beberapa manajemen operasional dan aktivitas pemantauan. Tugas dapat berkisar dari memuat data, mencadangkan dan memulihkan data, mengatur ulang data, dan memastikan bahwa sistem bekerja dengan benar dan efisien.

Pertimbangkan faktor-faktor berikut yang memengaruhi manajemen operasional:

• Cara menerapkan 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, menjaga konsistensi logis selama operasi pencadangan dan pemulihan bisa menjadi tantangan.

• Cara memuat data ke dalam beberapa partisi dan menambahkan data baru yang berasal dari sumber lain. Beberapa alat dan utilitas mungkin tidak mendukung operasi data sharding seperti memuat data ke dalam partisi yang benar.

• Cara mengarsipkan dan menghapus data secara teratur. Untuk mencegah pertumbuhan partisi yang berlebihan, Anda perlu mengarsipkan dan menghapus data secara teratur (seperti bulanan). Mungkin perlu mengubah data agar sesuai dengan skema arsip yang berbeda.

• Cara menemukan masalah integritas data. Pertimbangkan untuk menjalankan proses berkala untuk menemukan masalah integritas data, seperti data di satu partisi yang mereferensikan informasi yang hilang di partisi lain. Proses ini dapat mencoba memperbaiki masalah ini secara otomatis atau membuat laporan untuk peninjauan manual.

Menyeimbangkan kembali partisi

Ketika sistem matang, Anda mungkin harus menyesuaikan skema partisi. Misalnya, partisi individu mungkin mulai mendapatkan volume lalu lintas yang tidak proporsional dan menjadi panas, yang mengarah ke ketidaksesuaian yang berlebihan. Atau Anda mungkin meremehkan volume data di beberapa partisi, menyebabkan beberapa partisi mendekati batas kapasitas.

Beberapa penyimpanan data, seperti Azure Cosmos DB, dapat menyeimbangkan ulang partisi secara otomatis. Dalam kasus lain, penyeimbangan kembali adalah tugas administratif yang terdiri dari dua tahap:

1. Tentukan strategi pemartisian baru.

   • Partisi mana yang perlu dibagi (atau mungkin digabungkan)?
   • Apa yang dimaksud dengan kunci partisi baru?

2. Migrasikan data dari skema partisi lama ke set partisi baru.

Bergantung pada penyimpanan data, Anda mungkin dapat memigrasikan data antar partisi saat sedang digunakan. Ini disebut migrasi online. Jika tidak memungkinkan, Anda mungkin perlu membuat partisi tidak tersedia saat data dipindahkan (migrasi offline).

Migrasi offline

Migrasi offline biasanya lebih sederhana karena mengurangi kemungkinan terjadinya ketidaksesuaian. Secara konseptual, migrasi offline berfungsi sebagai berikut:

1. Menandai partisi secara offline.
2. Memisahkan-menggabungkan dan memindahkan data ke partisi baru.
3. Memverifikasi data.
4. Membawa partisi baru secara online.
5. Menghapus partisi lama.

Secara opsional, Anda dapat menandai partisi sebagai baca-saja di langkah 1, sehingga aplikasi masih dapat membaca data saat sedang dipindahkan.

Migrasi online

Migrasi online lebih rumit untuk dilakukan tetapi tidak terlalu mengganggu. Prosesnya mirip dengan migrasi offline, kecuali partisi asli tidak ditandai offline. Bergantung pada granuralitas proses migrasi (misalnya, item demi item versus pecahan demi pecahan), kode akses data di aplikasi klien mungkin harus menangani membaca dan menulis data yang disimpan di dua lokasi, partisi asli dan partisi baru.

Langkah berikutnya

• Pelajari tentang strategi pemartisian untuk layanan Azure tertentu. Lihat Strategi pemartisian data.
• Skalabilitas penyimpanan dan target performa Azure

Sumber daya terkait

• Memilih tempat penyimpanan data yang tepat

Pola desain berikut mungkin relevan dengan skenario Anda:

• Pola sharding menjelaskan beberapa strategi umum untuk sharding data.

• Pola tabel indeks menunjukkan cara membuat indeks sekunder pada data. Aplikasi dapat dengan cepat mengambil data dengan pendekatan ini, menggunakan kueri yang tidak mereferensikan kunci primer dari suatu kumpulan.

• Pola tampilan terwujud menjelaskan cara menghasilkan tampilan yang telah terisi sebelumnya yang merangkum data untuk mendukung operasi kueri cepat. Pendekatan ini dapat berguna dalam penyimpanan data yang dipartisi jika partisi yang berisi data yang diringkas didistribusikan di beberapa situs.