Bagikan melalui

Sharding untuk skalabilitas horizontal di Azure DocumentDB

Azure DocumentDB mendukung sharding untuk mendistribusikan data dan lalu lintas secara horizontal. Dokumen dalam koleksi dibagi menjadi potongan yang disebut pecahan logis.

Sharding didefinisikan secara individual untuk setiap koleksi menggunakan kunci shard yang ditunjuk dari struktur dokumen koleksi. Data kemudian dibagi ke dalam bagian dengan setiap bagian yang sesuai dengan partisi logis. Dokumen untuk setiap nilai unik dari properti kunci shard berada pada shard logis yang sama.

Untuk setiap dokumen yang dimasukkan ke dalam koleksi terpecah, nilai properti kunci shard diolah dengan hash untuk menentukan shard logis yang ditunjuk. Tanggung jawab menempatkan pecahan logis dan mendistribusikan semua pecahan logis dalam kluster dihilangkan dari pengguna dan sepenuhnya dikelola oleh layanan.

Pecahan logis

Semua dokumen yang berisi nilai yang sama untuk kunci shard termasuk dalam shard logis yang sama.

Misalnya, mari kita pertimbangkan koleksi yang disebut Karyawan dengan struktur dokumen di bawah ini.

Tabel ini memperlihatkan pemetaan nilai kunci shard ke partisi logis.

ID Dokumen Nilai Kunci Shard Sekat Logis
"12345" "Steve Smith" Shard 1
"23456" "Jane Doe" Shard 2
"34567" "Steve Smith" Pecahan 1
"45678" "Michael Smith" Shard 3
"56789" "Jane Doe" Shard 2

  • Tidak ada batasan jumlah pecahan logis untuk koleksi. Koleksi dapat memiliki sejumlah pecahan logis yang sama banyaknya dengan jumlah dokumen yang masing-masing memiliki nilai unik untuk properti kunci shard di setiap dokumen.

  • Juga tidak ada batasan ukuran pecahan logis tunggal.

  • Selain itu, layanan ini tidak membatasi transaksi dalam cakupan shard logis. Azure DocumentDB mendukung transaksi baca dan tulis yang berlaku di beberapa pecahan logis dan di beberapa pecahan fisik dalam kluster.

Pecahan fisik

Pecahan fisik adalah mesin dan disk yang mendasari dan bertanggung jawab untuk mempertahankan data serta memenuhi transaksi database. Tidak seperti pecahan logis, layanan mengelola pecahan fisik di bawah sampul.

Jumlah pecahan fisik ditentukan ketika kluster dibuat dan dapat ditingkatkan jika ukuran database tumbuh dari waktu ke waktu. Kluster shard tunggal memiliki satu shard fisik (node) yang sepenuhnya bertanggung jawab atas penyimpanan kluster dan transaksi database. Kluster multishard mendistribusikan data dan volume transaksi di seluruh pecahan fisik dalam kluster.

Memetakan pecahan logis ke pecahan fisik

Ketika pecahan logis baru ditambahkan, kluster dengan mulus memperbarui pemetaan logis ke pecahan fisik. Demikian pula, pembagian ruang alamat ke setiap pecahan fisik diubah ketika pecahan fisik baru ditambahkan ke kluster dan setelah itu, pecahan logis diseimbangkan kembali di seluruh kluster.

Rentang hash yang digunakan untuk memetakan pecahan logis dan fisik didistribusikan secara merata di seluruh pecahan fisik dalam kluster. Setiap pecahan fisik memiliki wadah berukuran merata dari rentang hash. Untuk setiap dokumen yang ditulis, nilai properti kunci shard di-hash dan nilai hash menentukan pemetaan dokumen ke shard fisik yang mendasarinya. Secara internal, beberapa pecahan logis dipetakan ke satu pecahan fisik. Selain itu, pecahan logis tidak pernah dibagi menjadi beberapa pecahan fisik dan semua dokumen untuk pecahan logis hanya dipetakan ke satu pecahan fisik.

Melanjutkan contoh sebelumnya yang menggunakan kluster dengan dua pecahan fisik, tabel ini menunjukkan contoh pemetaan dokumen ke pecahan fisik.

ID Dokumen Nilai Kunci Shard Sekat Logis Shard Fisik
"12345" "Steve Smith" Shard 1 Shard Fisik 1
"23456" "Jane Doe" Shard 2 Shard Fisik 2
"34567" "Steve Smith" Shard 1 Shard Fisik 1
"45678" "Michael Smith" Shard 3 Shard Fisik 1
"56789" "Jane Doe" Shard 2 Shard Fisik 2

Kapasitas partisi fisik

Tingkat kluster yang dipilih ketika kluster disediakan menentukan kapasitas CPU dan memori shard fisik. Demikian pula SKU penyimpanan menentukan kapasitas penyimpanan dan IOPS shard fisik. Tingkat kluster yang lebih besar memberikan daya komputasi yang lebih besar dan memori yang lebih besar sementara disk penyimpanan yang lebih besar menyediakan lebih banyak penyimpanan dan IOPS. Beban kerja yang banyak membaca akan mendapat manfaat dari tier kluster yang lebih besar, sementara beban kerja yang banyak menulis akan mendapat manfaat dari SKU penyimpanan yang lebih besar. Tingkat kluster dapat ditingkatkan dan diturunkan setelah kluster dibuat berdasarkan kebutuhan aplikasi yang berubah.

Dalam kluster multishard, kapasitas setiap shard fisik sama. Meningkatkan tingkat kluster atau SKU penyimpanan tidak mengubah penempatan pecahan logis pada pecahan fisik. Setelah operasi peningkatan skala, jumlah pecahan fisik tetap sama sehingga menghindari kebutuhan untuk menyeimbangkan kembali data dalam kluster.

Kapasitas komputasi, memori, penyimpanan, dan IOPS dari shard fisik menentukan jumlah sumber daya yang tersedia untuk shard logis. Kunci shard yang tidak memiliki distribusi penyimpanan yang merata dan volume permintaan dapat menyebabkan konsumsi penyimpanan dan throughput yang tidak merata dalam kluster. Partisi panas dapat menyebabkan pemanfaatan pecahan fisik menjadi tidak merata, yang mengakibatkan throughput dan performa tidak dapat diprediksi. Dengan demikian, kluster yang dipecah memerlukan perencanaan yang cermat di muka untuk memastikan performa tetap konsisten karena persyaratan aplikasi berubah dari waktu ke waktu.

Set replika

Setiap pecahan fisik terdiri dari satu set replika, juga disebut sebagai set replika. Setiap replika meng-hosting satu instans mesin database. Set replika membuat penyimpanan data dalam pecahan fisik menjadi lebih tahan lama, sangat tersedia, dan konsisten. Setiap replika yang membentuk pecahan fisik mewarisi penyimpanan dan kapasitas komputasi pecahan fisik. Azure DocumentDB secara otomatis mengelola set replika.

Praktik Terbaik untuk Pemecahan Data

  • Sharding di Azure DocumentDB tidak diperlukan kecuali penyimpanan koleksi dan volume transaksi dapat melebihi kapasitas satu shard fisik. Misalnya, layanan ini menyediakan disk 32 TB per shard. Jika koleksi membutuhkan lebih dari 32 TB, koleksi harus dipecah.

  • Tidak perlu memecah setiap koleksi dalam kluster dengan beberapa pecahan fisik. Koleksi yang terbagi dan tidak terbagi dapat bersanding dalam klaster yang sama. Layanan ini secara optimal mendistribusikan koleksi dalam kluster untuk memanfaatkan sumber daya komputasi dan penyimpanan kluster secara merata.

  • Untuk aplikasi dengan operasi baca berat, kunci shard harus dipilih berdasarkan pola kueri yang paling sering digunakan. Filter kueri yang paling umum digunakan untuk koleksi harus dipilih sebagai kunci shard untuk mengoptimalkan persentase transaksi database tertinggi dengan melokalisasi pencarian ke satu shard fisik.

  • Untuk aplikasi yang memiliki beban penulisan tinggi dan lebih mengutamakan performa penulisan dibandingkan dengan pembacaan, kunci pecahan (shard) harus dipilih untuk mendistribusikan data secara merata di seluruh pecahan fisik. Kunci pembagi dengan kardinalitas tertinggi memberikan kesempatan terbaik untuk mendistribusikan data secara merata.

  • Untuk performa optimal, ukuran penyimpanan shard logis harus kurang dari 4 TB.

  • Untuk performa optimal, pecahan logis harus didistribusikan secara merata dalam hal penyimpanan dan volume permintaan di seluruh pecahan fisik kluster.

Cara memecah koleksi

Pertimbangkan dokumen berikut dalam database 'cosmicworks' dan pengumpulan data 'karyawan'

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Sampel berikut membagi koleksi karyawan dalam database cosmicworks berdasarkan properti firstName.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

Koleksi juga dapat dipecah menggunakan perintah admin:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Meskipun tidak ideal untuk mengubah kunci shard setelah kumpulan data tumbuh secara signifikan dalam volume penyimpanan, perintah reshardCollection dapat digunakan untuk mengubah kunci shard.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

Koleksi dapat di-reshard kembali menggunakan perintah admin.

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

Sebagai praktik terbaik, indeks harus dibuat pada properti kunci shard.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Langkah selanjutnya

Opsi migrasi untuk Azure DocumentDB

  • Last updated on