DocumentDB - Bölümleme
Veritabanınız 10 GB'ın üzerinde büyümeye başladığında, yalnızca yeni koleksiyonlar oluşturarak ve ardından verilerinizi giderek daha fazla koleksiyona dağıtarak veya bölümlere ayırarak ölçeği genişletebilirsiniz.
Er ya da geç 10GB kapasiteye sahip tek bir koleksiyon, veritabanınızı tutmaya yetmeyecektir. Şimdi 10 GB çok büyük bir sayı gibi görünmeyebilir, ancak yalnızca düz metin olan JSON belgelerini sakladığımızı ve dizinler için depolama ek yükünü düşünseniz bile 10 GB'a çok sayıda düz metin belgesini sığdırabileceğinizi unutmayın.
Ölçeklenebilirlik söz konusu olduğunda tek sorun depolama değildir. Bir koleksiyonda kullanılabilen maksimum aktarım hızı, bir S3 koleksiyonuyla elde ettiğiniz saniyede iki buçuk bin istek birimidir. Bu nedenle, daha yüksek işleme hızına ihtiyacınız varsa, birden fazla koleksiyonla bölümlere ayırarak ölçeklendirmeniz de gerekecektir. Ölçeklendirilmiş bölümleme de denirhorizontal partitioning.
Azure DocumentDB ile verileri bölümlemek için kullanılabilecek birçok yaklaşım vardır. En yaygın stratejiler şunlardır -
- Yayılma Bölümleme
- Aralık Bölümleme
- Arama Bölümleme
- Hash Partitioning
Yayılma Bölümleme
Yayılma bölümleme en basit stratejidir çünkü bölüm anahtarı yoktur. Pek çok şeyden emin olmadığınızda başlamak için genellikle iyi bir seçimdir. Tek bir koleksiyonun ötesine geçmeniz gerekip gerekmediğini veya kaç koleksiyon eklemeniz gerekebileceğini veya bunları ne kadar hızlı eklemeniz gerekebileceğini bile bilmeyebilirsiniz.
Yayılma bölümleme tek bir koleksiyonla başlar ve bölüm anahtarı yoktur.
Koleksiyon büyümeye başlar ve sonra biraz daha büyür, sonra 10 GB sınırına yaklaşana kadar biraz daha büyür.
Yüzde 90 kapasiteye ulaştığınızda, yeni bir koleksiyona geçiyorsunuz ve onu yeni belgeler için kullanmaya başlıyorsunuz.
Veritabanınız daha fazla sayıda koleksiyona ölçeklendiğinde, muhtemelen bölüm anahtarına dayalı bir stratejiye geçmek isteyeceksiniz.
Bunu yaptığınızda, geçiş yaptığınız stratejiye göre belgeleri farklı koleksiyonlara taşıyarak verilerinizi yeniden dengelemeniz gerekir.
Aralık Bölümleme
En yaygın stratejilerden biri aralık bölümlemedir. Bu yaklaşımla, bir belgenin bölüm anahtarının düşebileceği değer aralığını belirler ve belgeyi bu aralığa karşılık gelen bir koleksiyona yönlendirirsiniz.
Tarihler, tanımlanmış tarih aralığına giren belgeleri tutmak için bir koleksiyon oluşturduğunuz bu strateji ile çok tipik olarak kullanılır. Yeterince küçük aralıklar tanımladığınızda, hiçbir koleksiyonun 10 GB sınırını asla aşmayacağından emin olursunuz. Örneğin, tek bir koleksiyonun tüm bir ay boyunca belgeleri makul bir şekilde işleyebileceği bir senaryo olabilir.
Çoğu kullanıcının bu ay veya belki de geçen aya ait veriler olan mevcut verileri sorgulaması da söz konusu olabilir, ancak kullanıcılar nadiren çok daha eski verileri arıyor. Böylece, satın alabileceğiniz en pahalı koleksiyon olan ve elde edebileceğiniz en iyi verimi sunan bir S3 koleksiyonuyla Haziran ayında başlarsınız.
Temmuz ayında, Temmuz verilerini depolamak için başka bir S3 koleksiyonu satın alırsınız ve ayrıca Haziran verilerini daha ucuz bir S2 koleksiyonuna indirirsiniz. Ardından Ağustos'ta, başka bir S3 koleksiyonu elde edersiniz ve Temmuz'u S2'ye ve Haziran'ı S1'e indirirsiniz. Her ay geçerli verileri yüksek verim için her zaman hazır tuttuğunuz ve eski verilerin daha düşük üretim hızlarında tutulduğu yer.
Sorgu bir bölüm anahtarı sağladığı sürece, yalnızca sorgulanması gereken koleksiyon sorgulanacak ve yayılma bölümlemede olduğu gibi veritabanındaki tüm koleksiyonlar sorgulanmayacaktır.
Arama Bölümleme
Arama bölümleme ile, belgeleri bölüm anahtarlarına göre belirli koleksiyonlara yönlendiren bir bölüm haritası tanımlayabilirsiniz. Örneğin, bölgeye göre bölümleyebilirsiniz.
Tüm ABD belgelerini bir koleksiyonda, tüm Avrupa belgelerini başka bir koleksiyonda ve diğer bölgelerden tüm belgeleri üçüncü bir koleksiyonda saklayın.
Bu bölüm haritasını kullanın ve arama bölümü çözümleyici, her belgede bulunan bölge özelliği olan bölüm anahtarına göre hangi koleksiyonda belge oluşturulacağını ve hangi koleksiyonların sorgulanacağını belirleyebilir.
Hash Partitioning
Karma bölümlemede bölümler, karma işlevin değerine göre atanır ve bu da istekleri ve verileri bir dizi bölüme eşit olarak dağıtmanıza olanak tanır.
Bu, genellikle çok sayıda farklı istemciden üretilen veya tüketilen verileri bölümlemek için kullanılır ve kullanıcı profillerini, katalog öğelerini vb. Depolamak için kullanışlıdır.
NET SDK tarafından sağlanan RangePartitionResolver'ı kullanarak aralık bölümlemenin basit bir örneğine bakalım.
Step 1- Yeni bir DocumentClient oluşturun ve CreateCollections görevinde iki koleksiyon oluşturalım. Biri, A'dan M'ye kadar olan kullanıcı kimliklerine sahip kullanıcılar için ve diğeri N'den Z'ye kadar kullanıcı kimlikleri için dokümanları içerecektir.
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 - Veritabanı için aralık çözümleyiciyi kaydedin.
Step 3- Bölüm anahtarımızın veri türü olan yeni bir RangePartitionResolver <string> oluşturun. Yapıcı, iki parametre alır; bölüm anahtarının özellik adı ve parça eşlemesi veya bölüm eşlemesi olan bir sözlük, bu sadece çözümleyici için önceden tanımladığımız aralıkların ve karşılık gelen koleksiyonların bir listesi.
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;
}
Burada olası en büyük UTF-8 değerini kodlamak gerekir. Ya da ilk aralık, tek bir M dışında hiçbir Ms ile eşleşmez ve aynı şekilde ikinci aralıktaki Z için de aynı şekilde. Dolayısıyla, buradaki kodlanmış değeri, bölüm anahtarında eşleştirme için bir joker karakter olarak düşünebilirsiniz.
Step 4- Çözümleyiciyi oluşturduktan sonra, mevcut DocumentClient ile veritabanına kaydedin. Bunu yapmak için sadece PartitionResolver'ın sözlük özelliğine atayın.
Normalde yaptığınız gibi bir koleksiyon değil, veritabanına göre belgeler oluşturacak ve sorgulayacağız; çözümleyici, istekleri uygun koleksiyonlara yönlendirmek için bu haritayı kullanacaktır.
Şimdi bazı belgeler oluşturalım. Önce userId Kirk için bir tane ve sonra Spock için bir tane oluşturacağız.
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);
}
Buradaki ilk parametre, belirli bir koleksiyon değil, veritabanına kendi kendine bağlantıdır. Bu, bir bölüm çözücü olmadan mümkün değildir, ancak bir tanesiyle sorunsuz bir şekilde çalışır.
Her iki belge de myfirstdb veritabanına kaydedildi, ancak RangePartitionResolver'ımız düzgün çalışıyorsa Kirk'ün A'dan M'ye kadar koleksiyonda saklandığını ve Spock'ın N'den Z'ye koleksiyonda depolandığını biliyoruz.
Bunları aşağıdaki kodda gösterildiği gibi CreateDocumentClient görevinden çağıralım.
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);
}
}
Yukarıdaki kod çalıştırıldığında, aşağıdaki çıktıyı alacaksınız.
**** Create Documents Across Partitions ****
Document 1: dbs/Ic8LAA==/colls/Ic8LAO2DxAA=/docs/Ic8LAO2DxAABAAAAAAAAAA==/
Document 2: dbs/Ic8LAA==/colls/Ic8LAP12QAE=/docs/Ic8LAP12QAEBAAAAAAAAAA==/
Görüldüğü gibi, iki belgenin kendi kendine bağlantıları, iki ayrı koleksiyonda mevcut oldukları için farklı kaynak kimliklerine sahiptir.