DocumentDB - Partisi

Saat database Anda mulai berkembang melebihi 10 GB, Anda dapat menskalakannya hanya dengan membuat koleksi baru, lalu menyebarkan atau mempartisi data Anda di lebih banyak koleksi.

Cepat atau lambat, satu koleksi, yang memiliki kapasitas 10 GB, tidak akan cukup untuk menampung database Anda. Sekarang 10GB mungkin tidak terdengar seperti angka yang sangat besar, tetapi ingat bahwa kami menyimpan dokumen JSON, yang hanya berupa teks biasa dan Anda dapat memasukkan banyak dokumen teks biasa dalam 10GB, bahkan ketika Anda mempertimbangkan overhead penyimpanan untuk indeks.

Penyimpanan bukanlah satu-satunya perhatian dalam hal skalabilitas. Throughput maksimum yang tersedia pada sebuah koleksi adalah dua setengah ribu unit permintaan per detik yang Anda dapatkan dengan koleksi S3. Karenanya, jika Anda membutuhkan throughput yang lebih tinggi, Anda juga perlu melakukan penskalaan dengan mempartisi dengan beberapa koleksi. Skala keluar partisi juga disebuthorizontal partitioning.

Ada banyak pendekatan yang dapat digunakan untuk mempartisi data dengan Azure DocumentDB. Berikut adalah strategi yang paling umum -

Partisi Spillover
Rentang Partisi
Lookup Partitioning
Partisi Hash

Partisi Spillover

Partisi spillover adalah strategi paling sederhana karena tidak ada kunci partisi. Ini sering kali merupakan pilihan yang baik untuk memulai ketika Anda tidak yakin tentang banyak hal. Anda mungkin tidak tahu apakah Anda bahkan perlu memperbesar lebih dari satu koleksi atau berapa banyak koleksi yang mungkin perlu Anda tambahkan atau seberapa cepat Anda mungkin perlu menambahkannya.

Partisi spillover dimulai dengan satu koleksi dan tidak ada kunci partisi.
Koleksinya mulai bertambah dan kemudian bertambah lagi, dan kemudian bertambah lagi, sampai Anda mendekati batas 10GB.
Saat Anda mencapai kapasitas 90 persen, Anda beralih ke koleksi baru dan mulai menggunakannya untuk dokumen baru.
Setelah database Anda berkembang ke lebih banyak koleksi, Anda mungkin ingin beralih ke strategi yang didasarkan pada kunci partisi.
Ketika Anda melakukannya, Anda perlu menyeimbangkan kembali data Anda dengan memindahkan dokumen ke koleksi yang berbeda berdasarkan strategi apa pun yang Anda gunakan untuk bermigrasi.

Rentang Partisi

Salah satu strategi yang paling umum adalah pembagian jarak. Dengan pendekatan ini Anda menentukan rentang nilai yang mungkin termasuk dalam kunci partisi dokumen dan mengarahkan dokumen ke koleksi yang sesuai dengan rentang itu.

Tanggal biasanya digunakan dengan strategi ini di mana Anda membuat koleksi untuk menyimpan dokumen yang termasuk dalam rentang tanggal yang ditentukan. Saat Anda menentukan rentang yang cukup kecil, Anda yakin bahwa tidak ada koleksi yang akan melebihi batas 10 GB-nya. Misalnya, mungkin ada skenario di mana satu koleksi dapat menangani dokumen secara wajar selama sebulan penuh.
Mungkin juga sebagian besar pengguna menanyakan data saat ini, yang akan menjadi data untuk bulan ini atau mungkin bulan lalu, tetapi pengguna jarang mencari data yang jauh lebih lama. Jadi Anda memulai pada bulan Juni dengan koleksi S3, yang merupakan koleksi termahal yang dapat Anda beli dan memberikan hasil terbaik yang dapat Anda peroleh.
Pada bulan Juli Anda membeli koleksi S3 lainnya untuk menyimpan data Juli dan Anda juga menurunkan skala data bulan Juni menjadi koleksi S2 yang lebih murah. Kemudian pada bulan Agustus, Anda mendapatkan koleksi S3 lainnya dan menurunkan skala Juli menjadi S2 dan Juni hingga S1. Ini berjalan, bulan demi bulan, di mana Anda selalu menjaga data saat ini tersedia untuk throughput tinggi dan data lama tetap tersedia pada throughput yang lebih rendah.
Selama kueri menyediakan kunci partisi, hanya koleksi yang perlu dikueri yang akan ditanyakan dan tidak semua koleksi dalam database seperti yang terjadi dengan partisi spillover.

Lookup Partitioning

Dengan pemartisian pencarian, Anda dapat menentukan peta partisi yang merutekan dokumen ke koleksi tertentu berdasarkan kunci partisi mereka. Misalnya, Anda dapat mempartisi menurut wilayah.

Simpan semua dokumen AS dalam satu koleksi, semua dokumen Eropa di koleksi lain, dan semua dokumen dari kawasan lain mana pun di koleksi ketiga.
Gunakan peta partisi ini dan resolver partisi pencarian dapat mengetahui koleksi mana yang akan digunakan untuk membuat dokumen dan koleksi mana yang akan ditanyakan, berdasarkan kunci partisi, yang merupakan properti kawasan yang terdapat dalam setiap dokumen.

Partisi Hash

Dalam partisi hash, partisi ditetapkan berdasarkan nilai fungsi hash, memungkinkan Anda mendistribusikan permintaan dan data secara merata ke sejumlah partisi.

Ini biasanya digunakan untuk mempartisi data yang dihasilkan atau dikonsumsi dari sejumlah besar klien berbeda, dan berguna untuk menyimpan profil pengguna, item katalog, dll.

Mari kita lihat contoh sederhana pemartisian jarak menggunakan RangePartitionResolver yang disediakan oleh .NET SDK.

Step 1- Buat DocumentClient baru dan kami akan membuat dua koleksi di tugas CreateCollections. Satu akan berisi dokumen untuk pengguna yang memiliki ID pengguna yang dimulai dengan A hingga M dan yang lainnya untuk ID pengguna N hingga Z.

private static async Task CreateCollections(DocumentClient client) {
   await client.CreateDocumentCollectionAsync(“dbs/myfirstdb”, new DocumentCollection {
      Id = “CollectionAM” }); 
		
   await client.CreateDocumentCollectionAsync(“dbs/myfirstdb”, new DocumentCollection {
      Id = “CollectionNZ” }); 
}

Step 2 - Daftarkan resolver jangkauan untuk database.

Step 3- Buat RangePartitionResolver <string> baru, yang merupakan tipe data dari kunci partisi kami. Konstruktor mengambil dua parameter, nama properti kunci partisi dan kamus yang merupakan peta pecahan atau peta partisi, yang hanya merupakan daftar rentang dan koleksi terkait yang telah kami tentukan sebelumnya untuk resolver.

private static void RegisterRangeResolver(DocumentClient client) {

   //Note: \uffff is the largest UTF8 value, so M\ufff includes all strings that start with M.
		
   var resolver = new RangePartitionResolver<string>(
      "userId", new Dictionary<Range<string>, string>() {
      { new Range<string>("A", "M\uffff"), "dbs/myfirstdb/colls/CollectionAM" },
      { new Range<string>("N", "Z\uffff"), "dbs/myfirstdb/colls/CollectionNZ" },
   });
	
   client.PartitionResolvers["dbs/myfirstdb"] = resolver;
 }

Anda perlu mengenkode nilai UTF-8 terbesar di sini. Jika tidak, rentang pertama tidak akan cocok pada Ms mana pun kecuali satu M, dan juga untuk Z di rentang kedua. Jadi, anggap saja nilai yang dikodekan ini di sini sebagai karakter pengganti untuk pencocokan pada kunci partisi.

Step 4- Setelah membuat resolver, daftarkan ke database dengan DocumentClient saat ini. Untuk melakukan itu, tetapkan saja ke properti kamus PartitionResolver.

Kami akan membuat dan meminta dokumen terhadap database, bukan koleksi seperti yang biasa Anda lakukan, resolver akan menggunakan peta ini untuk mengarahkan permintaan ke koleksi yang sesuai.

Sekarang mari kita buat beberapa dokumen. Pertama kita akan membuat satu untuk userId Kirk, dan kemudian satu untuk Spock.

private static async Task CreateDocumentsAcrossPartitions(DocumentClient client) { 
   Console.WriteLine(); 
   Console.WriteLine("**** Create Documents Across Partitions ****");
	
   var kirkDocument = await client.CreateDocumentAsync("dbs/myfirstdb", new { userId =
      "Kirk", title = "Captain" }); 
   Console.WriteLine("Document 1: {0}", kirkDocument.Resource.SelfLink);
	
   var spockDocument = await client.CreateDocumentAsync("dbs/myfirstdb", new { userId =
      "Spock", title = "Science Officer" });		
   Console.WriteLine("Document 2: {0}", spockDocument.Resource.SelfLink); 
}

Parameter pertama di sini adalah tautan mandiri ke database, bukan koleksi khusus. Ini tidak mungkin tanpa resolver partisi, tetapi dengan resolver partisi ini berfungsi dengan mulus.

Kedua dokumen disimpan ke database myfirstdb, tetapi kita tahu bahwa Kirk disimpan dalam koleksi untuk A hingga M dan Spock disimpan dalam koleksi untuk N hingga Z, jika RangePartitionResolver kami berfungsi dengan baik.

Mari kita panggil ini dari tugas CreateDocumentClient seperti yang ditunjukkan pada kode berikut.

private static async Task CreateDocumentClient() {
   // Create a new instance of the DocumentClient 
   using (var client = new DocumentClient(new Uri(EndpointUrl), AuthorizationKey)) {
      await CreateCollections(client);  
      RegisterRangeResolver(client);  
      await CreateDocumentsAcrossPartitions(client); 
   } 
}

Ketika kode di atas dijalankan, Anda akan menerima output berikut.

**** Create Documents Across Partitions **** 
Document 1: dbs/Ic8LAA==/colls/Ic8LAO2DxAA=/docs/Ic8LAO2DxAABAAAAAAAAAA==/ 
Document 2: dbs/Ic8LAA==/colls/Ic8LAP12QAE=/docs/Ic8LAP12QAEBAAAAAAAAAA==/

Seperti yang terlihat, tautan mandiri dari kedua dokumen memiliki ID sumber daya yang berbeda karena keduanya ada dalam dua koleksi terpisah.