Pola sharding

Membagi penyimpanan data menjadi sekumpulan pecahan atau partisi horizontal. Hal ini dapat meningkatkan skalabilitas saat menyimpan dan mengakses data dengan volume yang besar.

Konteks dan masalah

Data yang disimpan oleh satu server memiliki keterbatasan sebagai berikut:

• Ruang penyimpanan. Penyimpanan data untuk aplikasi cloud skala besar diperkirakan berisi sejumlah data yang terus meningkat secara signifikan dari waktu ke waktu. Server biasanya hanya menyediakan ruang kapasitas penyimpanan yang terbatas, tetapi Anda dapat mengganti ruang yang ada dengan yang lebih besar, atau menambahkan kapasitas ruang saat volume data terus bertambah. Namun, sistem pada akhirnya akan mencapai batas di mana tidak mungkin lagi untuk meningkatkan kapasitas penyimpanan pada server.

• Sumber daya komputasi . Aplikasi cloud diperlukan untuk mendukung penggunaan secara bersamaan, dimana masing-masing menjalankan kueri yang informasinya ditelusur dari penyimpanan data. Satu server yang menyimpan data tidak memiliki daya komputasi yang cukup untuk mendukung beban, Keberhasilan untuk merespons memerlukan waktu lebih panjang bagi pengguna dan sering terjadi kehabisan waktu pada saat mencoba menyimpan dan mengambil data. Hal ini dapat diatasi dengan menambahkan memori atau meningkatkan prosesor, tetapi sistem akan mencapai batas ketika tidak mungkin lagi untuk meningkatkan sumber daya komputasi lebih jauh.

• Bandwidth jaringan. Pada akhirnya, performa penyimpanan data pada server diatur oleh kecepatan server dapat menerima permintaan dan mengirim balasan. Ada kemungkinan juga volume lalu lintas jaringan yang melebihi kapasitas jaringan yang digunakan untuk terhubung ke server, sehingga permintaan gagal.

• Geografi . Mungkin perlu menyimpan data yang dihasilkan oleh pengguna tertentu di wilayah yang sama dengan pengguna lain karena alasan hukum, kepatuhan, atau kinerja, atau untuk mengurangi terpendamnya akses data. Jika pengguna tersebar di berbagai negara atau wilayah, tidak mungkin menyimpan seluruh data aplikasi dalam satu penyimpanan data.

Penskalaan secara vertikal dengan menambahkan kapasitas ruang penyimpanan, daya pemrosesan, memori, dan koneksi jaringan dapat menunda efek dari beberapa keterbatasan ini, tetapi hal ini hanya menjadi solusi sementara. Aplikasi cloud komersial yang mampu mendukung pengguna yang banyak dan volume data yang tinggi harus dapat mendukung tanpa batas waktu, sehingga penskalaan vertikal belum tentu merupakan solusi terbaik.

Solusi

Bagi ruang penyimpanan data menjadi partisi horizontal atau pecahan. Setiap pecahan memiliki skema yang sama, tetapi dengan subset data yang berbeda. Pecahan adalah penyimpanan data yang dengan sendirinya (dapat berisi data untuk berbagai jenis entitas), berjalan pada server yang berfungsi sebagai simpul penyimpanan.

Pola ini memiliki manfaat sebagai berikut:

• Anda dapat menskalakan sistem dengan menambahkan pecahan lebih lanjut pada simpul penyimpanan tambahan.

• Sebuah sistem dapat menggunakan set perangkat keras berupa rak 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 secara fisik dekat dengan pengguna yang akan mengakses data.

Saat membagi penyimpanan data menjadi pecahan, putuskan data mana yang harus ditempatkan di setiap pecahan.Saat membagi penyimpanan data menjadi pecahan, putuskan data mana yang harus ditempatkan di setiap pecahan. Pecahan biasanya berisi item yang masuk dalam rentang tertentu yang ditentukan oleh satu atau lebih atribut data. Atribut ini membentuk pecahan kunci (kadang-kadang disebut sebagai kunci partisi). Kunci pecahan harus statis. Tidak didasarkan pada data yang berubah.

Pecahan secara fisik berfungsi mengatur data. Ketika sebuah aplikasi menyimpan dan mengambil data, logika pecahan mengarahkan aplikasi ke pecahan yang sesuai. Logika pecahan ini dapat diimplementasikan sebagai bagian dari kode akses data dalam aplikasi, atau dapat diimplementasikan oleh sistem penyimpanan data jika secara transparan mendukung pecahan.

Abstrak lokasi fisik data dalam logika pecahan memberikan tingkat kontrol yang tinggi atas pecahan yang mengandung data. Ini juga memungkinkan untuk migrasi data di antara pecahan tanpa mengerjakan ulang logika bisnis aplikasi jika data dalam pecahan perlu didistribusikan kembali (misalnya, jika pecahan tidak seimbang). Pertukaran adalah akses data tambahan yang diperlukan dalam menentukan lokasi setiap item data saat diambil.

Untuk memastikan performa dan skalabilitas yang optimal, penting untuk membagi data yang sesuai dengan jenis kueri yang pada aplikasi. Dalam banyak kasus, tidak mungkin skema pecahan akan persis sesuai dengan persyaratan kueri. Misalnya, dalam sistem multipenyewa, aplikasi mungkin perlu mengambil data penyewa menggunakan ID penyewa, tetapi mungkin juga perlu mencari data ini berdasarkan beberapa atribut lain seperti nama atau lokasi penyewa. Untuk menangani situasi ini, terapkan strategi pecahan dengan kunci pecahan pendukung kueri yang paling umum dilakukan.

Jika kueri secara teratur mengambil data menggunakan kombinasi nilai atribut, Anda mungkin dapat menentukan gabungan kunci pecahan dengan menautkan atribut bersama-sama. Atau, gunakan pola seperti pada Tabel Indeks untuk pencarian cepat ke data berdasarkan atribut yang tidak tercakup dalam kunci pecahan.

Strategi Pemecahan

Tiga strategi yang umum digunakan ketika memilih kunci pecahan dan memutuskan bagaimana mendistribusikan data di seluruh bagian. Perhatikan bahwa tidak harus ada korespondensi antara satu-ke-satu antar pecahan dan server yang menyimpannya — satu server dapat menyimpan beberapa pecahan. Strateginya adalah:

Strategi pencarian. Dalam strategi ini logika pecahan mengimplementasikan peta yang memiliki rute permintaan data ke pecahan yang berisi data menggunakan kunci pecahan. Dalam aplikasi multipenyewa semua data untuk penyewa mungkin disimpan bersama-sama dalam shard menggunakan ID penyewa sebagai kunci shard. Jumlah penyewa yang banyak bisa saja memiliki pecahan yang sama, tetapi data penyewa tunggal tidak akan tersebar di beberapa pecahan. Gambar berikut mengilustrasikan pecahan data penyewa berdasarkan ID penyewa.

Pemetaan antara nilai kunci shard dan penyimpanan fisik tempat data ada dapat didasarkan pada pecahan fisik di mana setiap nilai kunci shard dipetakan ke partisi fisik. Atau, teknik yang lebih fleksibel untuk menyeimbangkan kembali pecahan adalah partisi virtual, di mana kunci shard memetakan ke jumlah pecahan virtual yang sama, yang pada gilirannya memetakan ke lebih sedikit partisi fisik. Dalam pendekatan ini, aplikasi menemukan data 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 mengharuskan kode aplikasi dimodifikasi untuk menggunakan serangkaian nilai kunci shard yang berbeda.

Strategi Rentang. Strategi ini mengelompokkan item dalam pecahan yang sama, dan memerintahkannya dengan kunci pecahan — kunci pecahan saling berurutan. Ini berguna untuk aplikasi yang secara rutin mengambil item menggunakan kueri rentang (kueri yang mengembalikan satu item data untuk kunci pecahan yang berada dalam rentang tertentu). Misalnya, jika aplikasi secara teratur perlu mendata semua pesanan pada bulan tertentu, data dapat diambil lebih cepat jika semua pesanan selama sebulan disimpan dalam urutan tanggal dan waktu dalam pecahan yang sama. Jika setiap pesanan disimpan dalam pecahan yang berbeda, maka data harus diambil secara individual dengan melakukan berbagai perintah kueri (kueri yang mengembalikan satu item data). Gambar berikut mengilustrasikan set penyimpanan berurutan (rentang) data dalam pecahan.

Dalam contoh ini, kunci pecahan adalah gabungan kunci yang berisi bulan pemesanan sebagai elemen paling signifikan, diikuti oleh hari pemesanan dan waktu. Data untuk pemesanan secara alami diurutkan ketika pesanan baru dibuat dan ditambahkan ke pecahan. Beberapa penyimpanan data mendukung kunci pecahan dua bagian yang berisi elemen partisi yang mengidentifikasi pecahan dan baris yang secara unik mengidentifikasi item dalam pecahan. Data yang disimpan dalam pecahan biasanya berupa urutan baris. Item yang ada pada kueri rentang dan perlu dikelompokkan dapat menggunakan pecahan yang memiliki nilai yang sama untuk partisi tetapi nilai unik tetap pada baris.

Strategi penguraian. Tujuan dari strategi ini adalah untuk mengurangi beban berlebihan pada titik tertentu (pecahan dengan jumlah beban yang tidak proporsional). Ini mendistribusikan data ke seluruh pecahan dengan cara seimbang antara ukuran setiap pecahan dan beban rata-rata yang akan dihadapi setiap pecahan. Logika pecahan menghitung pecahan untuk menyimpan item berdasarkan simbol pada satu atau lebih atribut data. Fungsi penguraian dipilih agar dapat mendistribusikan data secara merata ke seluruh pecahan, bisa dengan memperkenalkan beberapa elemen acak ke dalam perhitungan. Gambar berikut mengilustrasikan data berdasarkan simbol 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 menggunakan strategi rentang, data penyewa 1 hingga penyewa ke n semuanya disimpan dalam pecahan A, data penyewa n +1 hingga m semuanya disimpan dalam pecahan B, dan seterusnya. Jika penyewa yang baru terdaftar akan menjadi paling aktif, sehingga sebagian besar aktivitas data akan terjadi di beberapa pecahan, hal ini dapat menyebabkan beban berlebih pada data tertentu. Sebaliknya, strategi penguraian mengalokasikan penyewa untuk berdasarkan simbol ID penyewa. Ini artinya setiap penyewa secara berurutan akan dialokasikan ke pecahan yang berbeda, yang akan mendistribusikan beban di seluruh aplikasi. Gambar sebelumnya menunjukkan data penyewa 55 dan 56.

Ketiga strategi pemecahan memiliki kelebihan dengan beberapa pertimbangan sebagai berikut:

• Lookup/Pencarian. Ini menawarkan kendali lebih besar terhadap cara konfigurasi pecahan yang digunakan. Penggunaan pecahan virtual mengurangi dampak saat menyeimbangkan data karena partisi baru dapat ditambahkan pada saat beban kerja berlebih. Pemetaan antara pecahan virtual dan partisi fisik yang mengimplementasikan pecahan dapat dimodifikasi tanpa mempengaruhi kode aplikasi yang menggunakan kunci pecahan untuk menyimpan dan mengambil data. Pencarian lokasi pecahan dapat menyebabkan beban tambahan pada sistem.

• Rentang. Cara ini mudah diimplementasikan dan bekerja dengan baik pada berbagai kueri karena dapat mengambil beberapa item data dari satu pecahan dalam satu operasi. Strategi ini membuat manajemen data menjadi lebih mudah. Misalnya, jika pengguna di wilayah yang sama berada dalam pecahan yang sama, pembaharuan dapat dijadwalkan di setiap zona waktu berdasarkan beban dan permintaan lokal. Namun, strategi ini tidak memberikan keseimbangan optimal antar pecahan yang ada. Menyeimbangkan kembali pecahan akan sulit dan tidak menyelesaikan masalah beban yang tidak merata jika sebagian besar aktivitas hanya untuk pecahan yang saling berdekatan.

• Hash. Strategi ini menawarkan peluang yang lebih baik untuk data yang lebih banyak dan distribusi beban. Permintaan rute dapat dilakukan secara langsung dengan menggunakan simbol/hash. Tidak perlu membuat peta. Perhatikan bahwa menghitung simbol/hash bisa mengakibatkan beban tambahan. Selain itu, sulit untuk menyeimbangkan pecahan.

Sistem pecahan umumnya menerapkan salah satu pendekatan yang dijelaskan di atas, tetapi Anda juga harus mempertimbangkan persyaratan bisnis aplikasi Anda dan pola penggunaan datanya. Misalnya, dalam aplikasi multipenyewa:

• Anda dapat memecah data berdasarkan beban kerja. Anda dapat memisahkan data penyewa yang tidak tentu dalam pecahan terpisah. Kecepatan akses data untuk penyewa lain dapat ditingkatkan hasilnya.

• Anda dapat memecah data berdasarkan lokasi penyewa. Anda dapat mengambil data penyewa di wilayah geografis tertentu secara offline untuk cadangan dan pemeliharaan pada saat jam sibuk di wilayah tersebut, sementara data untuk penyewa di wilayah lain tetap online dan dapat diakses selama jam kerja.

• Penyewa bernilai tinggi dapat ditetapkan shard privat, berkinerja tinggi, dan dimuat dengan ringan, sedangkan penyewa bernilai lebih rendah mungkin diharapkan untuk berbagi pecahan yang lebih padat dan sibuk.

• Untuk penyewa yang membutuhkan isolasi data dan privasi yang tinggi dapat disimpan di server yang benar-benar terpisah.

Operasi pergerakan dan pengukuran data

Masing-masing strategi pemecahan menyiratkan kemampuan dan tingkat kompleksitas yang berbeda untuk pengelolaan skala masuk, skala keluar, pergerakan data, dan pemeliharaan.

Strategi pencarian memungkinkan operasi pergerakan dan pengukuran data dilakukan di tingkat pengguna, baik secara online maupun offline. Teknik ini dapat menangguhkan beberapa atau semua aktivitas pengguna (selama periode jam sibuk), memindahkan data ke partisi virtual baru atau pecahan fisik, mengubah pemetaan, membatalkan atau menyegarkan cache yang tersimpan pada data, dan memungkinkan pengguna untuk melanjutkan aktivitas. Jenis operasi ini dapat dikelola secara terpusat. Strategi Pencarian membuat status data menjadi sangat mudah disimpan dan ditemukan kembali dengan cache dan dapat direplika.

Strategi rentang memiliki beberapa batasan pada operasi pergerakan dan pengukuran data, yang biasanya dilakukan ketika sebagian atau semua penyimpanan data luring karena data harus dibagi dan digabungkan di seluruh pecahan. Memindahkan data ke pecahan penyeimbangan kembali mungkin tidak menyelesaikan masalah beban yang tidak merata jika sebagian besar aktivitas adalah untuk kunci pecahan yang berdekatan atau pengidentifikasi data yang berada dalam kisaran yang sama. Strategi Range mungkin juga memerlukan beberapa keadaan untuk dipertahankan untuk memetakan rentang ke partisi fisik.

Strategi Hash membuat operasi penskalaan dan pergerakan data lebih kompleks karena kunci partisi adalah hash dari kunci pecahan atau pengenal data. Lokasi baru setiap pecahan harus ditentukan dari fungsi hash, atau fungsi yang dimodifikasi untuk memberikan pemetaan yang benar. Namun, strategi Hash tidak memerlukan pemeliharaan.

Masalah dan pertimbangan

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

• Sharding saling melengkapi dengan bentuk partisi lainnya, seperti partisi vertikal dan partisi fungsional. Misalnya, sebuah pecahan dapat berisi entitas yang telah di partisi secara vertikal, dan partisi fungsional dapat diimplementasikan sebagai beberapa pecahan. Untuk informasi lengkap tentang partisi, lihat panduan partisi data.

• Jaga agar pecahan tetap seimbang sehingga dapat menangani volume I / O yang sama. Ketika data dimasukkan dan dihapus, secara berkala perlu untuk menyeimbangkan kembali pecahan untuk menjamin distribusi yang merata dan untuk mengurangi kemungkinan hotspot. Penyeimbangan kembali dapat menjadi operasi yang mahal. Untuk mengurangi penyeimbangan, rencanakan pertumbuhan dengan memastikan bahwa setiap pecahan memiliki ruang kosong yang cukup untuk menangani volume perubahan yang dilaksanakan. Anda harus mengembangkan strategi dan skrip yang dapat di gunakan untuk menyeimbangkan kembali pecahan dengan cepat jika diperlukan.

• Gunakan data yang stabil sebagai kunci pecahan. Jika kunci pecahan berubah, item data yang sesuai bisa saja berpindah di antara pecahan, sehingga meningkatkan jumlah pekerjaan yang dilakukan oleh operasi pembaruan. Untuk alasan ini, hindari menjadikan kunci pecahan sebagai dasar informasi yang berpotensi tidak stabil. Sebaliknya, cari atribut yang tidak berubah-ubah atau yang 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 meningkat secara otomatis tidak dapat dikoordinasikan di seluruh pecahan, karena kemungkinan akan menghasilkan item pecahan yang berbeda tapi memiliki kunci pecahan yang sama.

  Nilai peningkatan otomatis di bidang lain yang bukan kunci pecahan dapat menyebabkan masalah. Misalnya, jika Anda menggunakan bidang kredit otomatis untuk menghasilkan ID unik, maka dua item berbeda yang terletak di pecahan yang berbeda bisa diberi ID yang sama.

• Tidak mungkin untuk merancang kunci pecahan yang memenuhi semua persyaratan setiap pertanyaan tentang data. Data pecahan digunakan untuk mendukung kueri yang paling sering dilakukan, dan jika perlu dibuatkan tabel indeks sekunder yang mendukung kueri untuk pengambilan data menggunakan kriteria berdasarkan atribut yang bukan bagian dari kunci pecahan. Untuk informasi selengkapnya, lihat pola Tabel Indeks.

• Kueri yang hanya mengakses satu pecahan lebih efisien daripada yang menelusur data dari beberapa pecahan, hindari menerapkan aplikasi sistem sharding yang melakukan sejumlah besar kueri untuk menggabungkan data yang disimpan dalam pecahan yang berbeda. Ingatlah bahwa satu pecahan dapat berisi data dari beberapa jenis entitas. Pertimbangkan untuk mendenormalisasi data Anda untuk menjaga entitas terkait yang biasanya ditanyakan bersamaan (seperti detail pelanggan dan pesanan yang telah mereka lakukan) dalam pecahan yang sama untuk mengurangi jumlah pembacaan terpisah yang dilakukan aplikasi.

  Jika entitas dalam satu pecahan mereferensikan entitas yang disimpan dalam pecahan lain, sertakan kunci pecahan untuk entitas kedua sebagai bagian dari skema untuk entitas pertama. Hal ini dapat membantu meningkatkan kinerja kueri yang mereferensikan data terkait pada pecahan.

• Jika aplikasi harus melakukan kueri dengan mengambil data dari beberapa pecahan, kegiatan ini bisa dilakukan data ini dengan menggunakan perintah tugas paralel. Contohnya kueri yang tersebar luas, di mana data dari beberapa pecahan diambil secara paralel dan dikumpulkan menjadi satu hasil. Namun, pendekatan ini menambah beberapa kompleksitas pada solusi logika akses data.

• Untuk sebagian besar aplikasi, membuat banyak pecahan kecil bisa lebih efisien daripada membuat sedikit pecahan besar karena pecahan kecil dapat meningkatkan peluang untuk penyeimbangan beban. Ini juga dapat berguna jika Anda akan mengantisipasi kebutuhan bermigrasi pecahan dari satu lokasi ke lokasi lain. Memindahkan pecahan kecil lebih cepat daripada memindahkan yang besar.

• Pastikan sumber daya yang tersedia untuk setiap simpul penyimpanan pecahan cukup untuk menangani persyaratan skalabilitas ukuran data dan keluaran. Untuk informasi selengkapnya, lihat bagian "Merancang Partisi untuk Skalabilitas" di Panduan Partisi Data.

• Pertimbangkan untuk mereplikasi data referensi ke semua pecahan. Jika operasi pengambilan data dari pecahan juga mereferensikan data statis atau data yang sifatnya lambat sebagai bagian dari kueri yang sama, tambahkan data ini ke pecahan. Aplikasi dapat mengambil semua data kueri dengan mudah, tanpa harus melakukan kegiatan bolak balik tambahan ke penyimpanan data terpisah.

  Jika data referensi yang disimpan dalam beberapa pecahan berubah, sistem harus mensinkronisasikan perubahan pada semua pecahan. Sistem bisa saja mengalami inkonsistensi saat sinkronisasi data terjadi. Jika Anda melakukan ini, Anda harus merancang aplikasi Anda agar dapat menangani inkonsistensi tersebut.

• Hal yang sulit adalah mempertahankan integritas referensial dan konsistensi antar pecahan, jadi Anda harus meminimalkan operasi yang mempengaruhi data pada beberapa pecahan. Jika aplikasi harus memodifikasi data di seluruh pecahan, lakukan evaluasi apakah konsistensi data keseluruhan benar-benar diperlukan. Sebaliknya, pendekatan di cloud diperlukan untuk menerapkan konsistensi akhir. Data di setiap partisi diperbarui secara terpisah, dan logika aplikasi harus dapat memastikan bahwa semua pembaruan berhasil diselesaikan, serta dapat menangani inkonsistensi yang dapat timbul dari kueri data saat melakukan operasi konsistensi data. Untuk informasi selengkapnya tentang menerapkan konsistensi akhir, lihat Data Consistency Primer.

• Konfigurasi dan pengelolaan jumlah pecahan yang besar merupakan suatu tantangan. Tugas-tugas seperti pemantauan data, pembuatan cadangan data, pemeriksaan konsistensi, dan pencatatan atau audit harus dilakukan pada beberapa pecahan dan server, bisa juga dilakukan di beberapa lokasi. Tugas-tugas berikut akan diimplementasikan menggunakan skrip atau solusi otomatis lainnya, tetapi hal itu tidak sepenuhnya menghilangkan persyaratan administrasi tambahan.

• Pecahan dapat dislokasi sehingga data yang dikandungnya sesuai dengan aplikasi yang digunakannya. Pendekatan ini dapat meningkatkan kinerja, tetapi memerlukan pertimbangan tambahan untuk tugas-tugas yang mengharuskan mengakses beberapa pecahan di lokasi yang berbeda.

Kapan menggunakan pola ini

Gunakan pola ini ketika penyimpanan data cenderung perlu menskalakan di luar sumber yang tersedia untuk satu simpul penyimpanan, atau untuk meningkatkan kinerja dengan mengurangi ketidaksesuaian pada penyimpanan data.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Sharding dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

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 pola kueri/penggunaan umum bertentangan menunjukkan penggunaan database relasional tunggal untuk menyimpan informasi buku. Arsitek beban kerja memutuskan untuk memecah data di beberapa instans database, menggunakan Nomor Buku Standar Internasional (ISBN) statis buku untuk kunci shard. Secara khusus, mereka menggunakan cek digit (0 - 10) ISBN karena memberikan 11 kemungkinan pecahan logis dan data akan cukup seimbang di setiap shard. Untuk memulainya, mereka memutuskan untuk mengkolokasikan 11 pecahan logis ke dalam tiga database shard fisik. Mereka menggunakan pendekatan sharding pencarian dan menyimpan informasi pemetaan kunci-ke-server dalam database peta shard.

Peta shard pencarian

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 jumlah database shard fisik (tiga dalam hal ini) atau logika yang memetakan kunci shard ke instans database, tetapi situs web tidak tahu bahwa cek digit ISBN buku harus dianggap sebagai kunci shard. Situs web ini memiliki akses baca-saja ke database peta shard dan akses baca-tulis ke semua database shard. Dalam contoh ini, situs web menggunakan identitas terkelola sistem Azure App Service yang menghosting situs web untuk otorisasi guna menjaga rahasia keluar dari string koneksi.

Situs web dikonfigurasi dengan string koneksi berikut, baik dalam appsettings.json file, seperti dalam contoh ini, atau melalui pengaturan aplikasi 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"
  },
  ...
}

Dengan informasi koneksi ke database peta shard yang tersedia, contoh kueri pembaruan yang dijalankan oleh situs web ke kumpulan shard database beban kerja akan terlihat mirip dengan kode berikut.

...

// 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 ke OpenShardConnectionForKeyAsync(6) biasanya akan diimplementasikan dengan pendekatan cache-aside. Ini meminta database peta shard yang diidentifikasi dengan string koneksi ShardMapDb jika tidak memiliki informasi shard yang di-cache untuk kunci shard 6. Baik dari cache aplikasi atau dari database shard, nilai bookdbshard2 menggantikan SHARD di BookDbFragment string koneksi. Koneksi yang dikumpulkan dibuat (ulang) untuk bookdbshard2.database.windows.net, dibuka, dan dikembalikan ke kode panggilan. Kode kemudian memperbarui rekaman yang ada pada instans database tersebut.

Contoh kode situs web - beberapa akses shard

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

...

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

// Execute 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))
    {
      // Read the results in to a thread-safe data structure.
    }

    reader.Close();
  }
});

...

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

Menambahkan instans shard

Tim beban kerja menyadari bahwa jika katalog data atau penggunaannya secara bersamaan tumbuh secara signifikan lebih dari tiga instans database mungkin diperlukan. Tim beban kerja tidak berharap untuk menambahkan server database secara dinamis dan akan menanggung waktu henti beban kerja jika pecahan baru perlu online. Membawa instans shard baru secara online memerlukan pemindahan data dari pecahan yang ada ke dalam shard baru bersama dengan pembaruan ke tabel peta shard. Pendekatan yang cukup statis ini memungkinkan beban kerja untuk dengan percaya diri menyimpan pemetaan database kunci shard dalam kode situs web.

Logika kunci shard dalam contoh ini memiliki batas atas keras 11 pecahan fisik maksimum. Jika tim beban kerja melakukan pengujian estimasi beban dan mengevaluasi bahwa lebih dari 11 instans database pada akhirnya akan diperlukan, perubahan invasif pada logika kunci shard perlu dilakukan. 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 Azure SQL Database, evaluasi pustaka klien Elastic Database. Pustaka ini mendukung manajemen peta shard, perutean kueri yang bergantung pada data, dan kueri lintas pecahan di C# dan Java.

Langkah berikutnya

Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:

• Data Consistency Primer. Perlu untuk menjaga konsistensi data yang didistribusikan ke berbagai pecahan. Merangkum isu-isu seputar menjaga konsistensi data terdistribusi, dan menggambarkan manfaat dan pertukaran model konsistensi yang berbeda.
• Panduan Pemartisian Data. Pemecahan penyimpanan data dapat menimbulkan berbagai masalah tambahan. Masalah ini berkaitan dengan partisi penyimpanan data di cloud yang berfungsi untuk meningkatkan skalabilitas, mengurangi ketidaksesuaian, dan mengoptimalkan kinerja.

Sumber daya terkait

Pola berikut mungkin juga relevan saat menerapkan pola ini:

• Pola Tabel Indeks. Terkadang tidak mungkin sepenuhnya mendukung kueri hanya melalui desain kunci pecahan saja. Terapkan aplikasi yang dapat dengan cepat mengambil data dari penyimpanan data besar dengan menentukan kunci selain kunci pecahan.
• Pola Tampilan Terwujud. Kegiatan ini dilakukan untuk mempertahankan kinerja beberapa operasi kueri, berguna untuk membuat menggabungkan tampilan dan meringkas data, terutama jika data ringkasan ini berdasarkan pada informasi yang didistribusikan di seluruh pecahan. Jelaskan cara mengisi dan menghasilkan tampilan.