Bu makalede, çeşitli Azure veri depolarındaki verileri bölümlemeye yönelik bazı stratejiler açıklanmaktadır. Verilerin ne zaman bölümlenmesi ve en iyi yöntemler hakkında genel yönergeler için bkz . Veri bölümleme.
Bölümleme Azure SQL Veritabanı
Tek bir SQL veritabanının içerebileceği veri miktarı sınırlıdır. Aktarım hızı mimari faktörler ve desteklediği eş zamanlı bağlantı sayısıyla sınırlandırılmıştır.
Elastik havuzlar , SQL veritabanı için yatay ölçeklendirmeyi destekler. Elastik havuzları kullanarak verilerinizi birden çok SQL veritabanına yayılmış parçalar halinde bölümleyebilirsiniz. Ayrıca işlemeniz gereken veriler arttıkça ve azaldıkça parçalar ekleyebilir ve kaldırabilirsiniz. Elastik havuzlar, yükü veritabanları arasında dağıtarak çekişmelerin azaltılmasına da yardımcı olabilir.
Her parça bir SQL veritabanı olarak uygulanır. Bir parça birden fazla veri kümesini (parçacık olarak adlandırılır) barındırabilir. Her veritabanında, içerdiği parçacıkları açıklayan meta veriler bulunur. Parçacık tek bir veri öğesi veya aynı parçalı anahtarı paylaşan bir öğe grubu olabilir. Örneğin, çok kiracılı bir uygulamada, parçacık anahtarı kiracı kimliği olabilir ve bir kiracının tüm verileri aynı parçalı içinde tutulabilir.
İstemci uygulamaları, bir veri kümesini bir parçacık anahtarıyla ilişkilendirmekle sorumludur. Ayrı bir SQL Veritabanı genel parça eşleme yöneticisi olarak görev yapar. Bu veritabanında sistemdeki tüm parçaların ve parçaçıkların listesi bulunur. Uygulama, parça eşlemesinin bir kopyasını almak için parça eşleme yöneticisi veritabanına bağlanır. Parça eşlemesini yerel olarak önbelleğe alır ve eşlemeyi kullanarak veri isteklerini uygun parçaya yönlendirir. Bu işlevsellik, Java ve .NET için kullanılabilen Elastik Veritabanı istemci kitaplığında bulunan bir dizi API'nin arkasına gizlenir.
Elastik havuzlar hakkında daha fazla bilgi için bkz. Azure SQL Veritabanı ile ölçeği genişletme.
Gecikme süresini azaltmak ve kullanılabilirliği geliştirmek için genel parça eşleme yöneticisi veritabanını çoğaltabilirsiniz. Premium fiyatlandırma katmanlarıyla, verileri farklı bölgelerdeki veritabanlarına sürekli olarak kopyalamak için etkin coğrafi çoğaltmayı yapılandırabilirsiniz.
Alternatif olarak, parça eşleme yöneticisi veritabanını bölgeler arasında çoğaltmak için Azure SQL Data Sync veya Azure Data Factory kullanın. Bu çoğaltma biçimi düzenli aralıklarla çalışır ve parça eşlemesi seyrek değişirse ve Premium katmanı gerektirmezse daha uygundur.
Elastik Veritabanı verileri parçacıklara eşlemek ve bunları parçalarda depolamak için iki düzen sağlar:
Liste parça eşlemesi tek bir anahtarı bir parçacıkla ilişkilendirir. Örneğin, çok kiracılı bir sistemde her kiracının verileri benzersiz bir anahtarla ilişkilendirilebilir ve kendi parçacığında depolanabilir. Yalıtımı garanti etmek için her parça kendi parçası içinde tutulabilir.
Bu diyagramın Visio dosyasını indirin.
Aralık parça eşlemesi , bir dizi bitişik anahtar değerini bir parçacıkla ilişkilendirir. Örneğin, bir kiracı kümesinin (her biri kendi anahtarı olan) verilerini aynı parça içinde gruplandırabilirsiniz. Kiracılar veri depolama alanını paylaştığından ancak daha az yalıtıma sahip olduğundan bu düzen ilkinden daha ucuzdur.
Bu diyagramın Visio dosyasını indirin
Tek bir parça, birkaç parçanın verilerini içerebilir. Örneğin, liste parçacıklarını kullanarak bitişik olmayan farklı kiracıların verilerini aynı parçada depolayabilirsiniz. Ayrıca, farklı haritalar aracılığıyla ele alınsa da, aralık parçacıklarını ve liste parçacıklarını aynı parçada karıştırabilirsiniz. Aşağıdaki diyagramda bu yaklaşım gösterilmektedir:
Bu diyagramın Visio dosyasını indirin.
Elastik havuzlar, veri hacmi küçülür ve büyüdükçe parçaların eklenmesini ve kaldırılmasını mümkün hale getirir. İstemci uygulamaları parçaları dinamik olarak oluşturup silebilir ve parça eşleme yöneticisini saydam bir şekilde güncelleştirebilir. Bununla birlikte, parçanın kaldırılması bu parçadaki tüm verilerin de silinmesini gerektiren zararlı bir işlemdir.
Bir uygulamanın bir parçanın iki ayrı parçaya bölünmesi veya parçaların birleştirilmesi gerekiyorsa, bölme birleştirme aracını kullanın. Bu araç bir Azure web hizmeti olarak çalışır ve verileri parçalar arasında güvenli bir şekilde geçirir.
Bölümleme düzeni sisteminizin performansını önemli ölçüde etkileyebilir. Ayrıca parçaların eklenmesi veya kaldırılması ya da verilerin parçalar arasında yeniden bölümlenmesi gereken hızı da etkileyebilir. Aşağıdaki noktalara bir göz atın:
Aynı parçada birlikte kullanılan verileri gruplandırın ve birden çok parçadan verilere erişen işlemlerden kaçının. Parça, kendi başına bir SQL veritabanıdır ve veritabanları arası birleşimler istemci tarafında gerçekleştirilmelidir.
SQL Veritabanı veritabanları arası birleştirmeleri desteklemese de, çok parçalı sorgular gerçekleştirmek için Elastik Veritabanı araçlarını kullanabilirsiniz. Çok parçalı sorgu her veritabanına tek tek sorgular gönderir ve sonuçları birleştirir.
Parçalar arasında bağımlılıkları olan bir sistem tasarlamayın. Bir veritabanındaki bilgi tutarlılığı kısıtlamaları, tetikleyicileri ve saklı yordamları diğer veritabanındaki nesnelere başvuramaz.
Sorgular tarafından sık kullanılan başvuru verileriniz varsa, bu verileri parçalar arasında çoğaltmayı göz önünde bulundurun. Bu yaklaşım, veritabanları arasında veri birleştirme gereksinimini ortadan kaldırabilir. İdeal olarak, çoğaltma çabasını en aza indirmek ve eskime olasılığını azaltmak için bu tür verilerin statik veya yavaş hareket etmesi gerekir.
Aynı parça eşlemesine ait parçacıklar aynı şemaya sahip olmalıdır. Bu kural SQL Veritabanı tarafından uygulanmaz, ancak her parçanın farklı bir şeması varsa veri yönetimi ve sorgulama çok karmaşık hale gelir. Bunun yerine, her şema için ayrı parça eşlemeleri oluşturun. Farklı parçacıklara ait verilerin aynı parçada depolanabileceğini unutmayın.
İşlem işlemleri yalnızca parça içindeki veriler için desteklenir, parçalar arasında desteklenmez. İşlemler, aynı parçaya ait olmak koşuluyla parçacıklar arasında yayılabilir. Bu nedenle, iş mantığınızın işlem gerçekleştirmesi gerekiyorsa verileri aynı parçada depolayın veya nihai tutarlılığı uygulayın.
Parçaları, bu parçalardaki verilere erişen kullanıcıların yakınlarına yerleştirin. Bu strateji gecikmeyi azaltmaya yardımcı olur.
Son derece aktif ve nispeten etkin olmayan parçaların karışımına sahip olmaktan kaçının. Yükü parçalar arasında eşit yaymayı deneyin. Bunun için parçalama anahtarlarının karması gerekebilir. Parçaları coğrafi olarak konumlandırıyorsanız, parçacıklara eşlenen karma anahtarların bu verilere erişen kullanıcıların yakınındaki parçalarda depolandığından emin olun.
Azure Tablo depolamayı bölümleme
Azure Tablo depolama, bölümleme için tasarlanmış bir anahtar-değer deposudur. Tüm varlıklar bir bölümde depolanır ve bölümler Azure Tablo depolaması tarafından dahili olarak yönetilir. Bir tabloda depolanan her varlık aşağıdakileri içeren iki parçalı bir anahtar sağlamalıdır:
Bölüm anahtarı. Bu, Azure Tablo depolamanın varlığı yerleştireceği bölümü belirleyen bir dize değeridir. Aynı bölüm anahtarına sahip tüm varlıklar aynı bölümde depolanır.
Satır anahtarı. Bu, bölümün içindeki varlığı tanımlayan bir dize değeridir. Bölüm içindeki tüm varlıklar bu anahtara göre sözcük temelinde artan düzende sıralanır. Her varlığın bölüm anahtarı/satır anahtarı bileşimi benzersiz olmalıdır ve uzunluğu 1 KB'yi aşmamalıdır.
Daha önce kullanılmayan bölüm anahtarına sahip bir tabloya varlık eklenirse, Azure Tablo depolama alanı bu varlık için yeni bir bölüm oluşturur. Aynı bölüm anahtarına sahip olan diğer varlıklar aynı bölümde depolanır.
Bu mekanizma otomatik ölçek genişletme stratejisini etkili bir şekilde uygular. Her bölüm, tek bir bölümden veri alan sorguların hızla çalıştığından emin olmak için bir Azure veri merkezinde aynı sunucuda depolanır.
Microsoft, Azure Depolama için ölçeklenebilirlik hedefleri yayımlamıştır. Sisteminiz bu sınırları aşma olasılığı yüksekse varlıkları birden çok tabloya bölmeyi göz önünde bulundurun. Dikey bölümleme kullanarak birlikte erişilme olasılıkları en yüksek olan alanları gruplara ayırın.
Aşağıdaki diyagramda örnek bir depolama hesabının mantıksal yapısı gösterilmektedir. Depolama hesabı üç tablo içerir: Müşteri Bilgileri, Ürün bilgileri ve Sipariş Bilgileri.
Her tablonun birden çok bölümü vardır.
- Müşteri Bilgileri tablosunda veriler, müşterinin bulunduğu şehre göre bölümlenmiştir. Satır anahtarı müşteri kimliğini içerir.
- Ürün Bilgileri tablosunda, ürünler ürün kategorisine göre bölümlenir ve satır anahtarı ürün numarasını içerir.
- Sipariş Bilgileri tablosunda siparişler sipariş tarihine göre bölümlenir ve satır anahtarı siparişin alındığı saati belirtir. Tüm veriler her bölümdeki satır anahtarına göre sıralanır.
Varlıklarınızı Azure Tablo depolama için tasarlarken aşağıdaki noktaları göz önünde bulundurun:
Verilere nasıl erişildiğinden bir bölüm anahtarı ve satır anahtarı seçin. Sorgularınızın çoğunluğunu destekleyen bir bölüm anahtarı/satır anahtarı bileşimi seçin. En verimli sorgular bölüm anahtarını ve satır anahtarını belirterek verileri alır. Bir bölüm anahtarı ve bir dizi satır anahtarı belirten sorgular tek bölümü tarayarak tamamlanabilir. Veriler satır anahtarı sırasına göre tutulduğunda bu görece hızlı çalışır. Sorgular hangi bölümün taranacağını belirtmezse, her bölümün taranması gerekir.
Varlığın tek bir doğal anahtarı varsa, bölüm anahtarı olarak onu kullanın ve satır anahtarı olarak boş bir dize belirtin. Bir varlığın iki özellik içeren bileşik anahtarı varsa, bölüm anahtarı olarak en yavaş değişen özelliği ve satır anahtarı olarak diğerini seçin. Varlığın ikiden fazla anahtar özelliği varsa, bölüm ve satır anahtarlarını oluşturmak için birleştirilmiş özellikleri kullanın.
Bölüm ve satır anahtarları dışındaki alanları kullanarak düzenli aralıklarla veri arayan sorgular gerçekleştiriyorsanız, Dizin Tablosu düzenini uygulamayı veya Azure Cosmos DB gibi dizin oluşturmayı destekleyen farklı bir veri deposu kullanmayı göz önünde bulundurun.
Monoton bir dizi kullanarak bölüm anahtarları oluşturursanız ("0001", "0002", "0003") ve her bölüm yalnızca sınırlı miktarda veri içeriyorsa, Azure Tablo depolaması bu bölümleri aynı sunucuda fiziksel olarak gruplandırabilir. Azure Depolama, uygulamanın büyük olasılıkla bitişik bir bölüm aralığında (aralık sorguları) sorgu gerçekleştirme olasılığının yüksek olduğunu varsayar ve bu durum için en iyi duruma getirilmiştir. Ancak bu yaklaşım etkin noktalara yol açabilir, çünkü yeni varlıkların tüm eklemeleri bitişik aralığın bir ucunda yoğunlaşabilir. Ayrıca ölçeklenebilirliği de azaltabilir. Yükü daha eşit bir şekilde yaymak için bölüm anahtarını karma olarak kullanmayı göz önünde bulundurun.
Azure Tablo depolama, aynı bölüme ait varlıklar için işlem işlemlerini destekler. İşlem 100'den fazla varlık içermediği ve isteğin yükü 4 MB'ı aşmadığı sürece bir uygulama atomik birim olarak birden çok ekleme, güncelleştirme, silme, değiştirme veya birleştirme işlemi gerçekleştirebilir. Birden çok bölüme yayılan işlemler işlemsel değildir ve nihai tutarlılığı uygulamanızı gerektirebilir. Tablo depolama ve işlemler hakkında daha fazla bilgi için bkz . Varlık grubu işlemleri gerçekleştirme.
Bölüm anahtarının ayrıntı düzeyini göz önünde bulundurun:
Her varlık için aynı bölüm anahtarının kullanılması, tek bir sunucuda tutulan tek bir bölüme neden olur. Bu, bölümün ölçeği genişletmesini engeller ve yükü tek bir sunucuya odaklar. Sonuç olarak, bu yaklaşım yalnızca az sayıda varlığı depolamak için uygundur. Ancak, tüm varlıkların varlık grubu işlemlerine katılabilmesini sağlar.
Her varlık için benzersiz bir bölüm anahtarı kullanmak, tablo depolama hizmetinin her varlık için ayrı bir bölüm oluşturmasına neden olur ve bu da büyük olasılıkla çok sayıda küçük bölüme neden olur. Bu yaklaşım tek bölüm anahtarı kullanmaktan daha iyi ölçeklenebilir ama varlık grubu işlemleri yapmak mümkün olmaz. Ayrıca, birden fazla varlık getiren sorguların birden çok sunucudan okuması gerekebilir. Ancak, uygulama aralık sorguları gerçekleştiriyorsa, bölüm anahtarları için monoton bir dizi kullanmak bu sorguları iyileştirmeye yardımcı olabilir.
Bölüm anahtarını varlıkların bir alt kümesi arasında paylaşmak, aynı bölümdeki ilgili varlıkları gruplandırma işlemini mümkün kılar. İlgili varlıkları içeren işlemler varlık grubu işlemleri kullanılarak gerçekleştirilebilir ve bir dizi ilgili varlığı getiren sorgular tek sunucuya erişerek bunu yapabilirler.
Daha fazla bilgi için bkz . Azure Depolama tablosu tasarım kılavuzu ve Ölçeklenebilir bölümleme stratejisi.
Bölümleme Azure Blob Depolama
Azure Blob Depolama, büyük ikili nesnelerin tutulmasını mümkün kılar. Büyük hacimli verileri hızla karşıya yüklemeniz veya indirmeniz gerektiğinde senaryolarda blok bloblarını kullanın. Verilerin bölümlerine seri yerine rastgele erişim gerektiren uygulamalar için sayfa bloblarını kullanın.
Her blob (blok veya sayfa) azure depolama hesabındaki bir kapsayıcıda tutulur. Aynı güvenlik gereksinimleri olan birbiriyle ilgili blobları gruplandırmak için kapsayıcıları kullanabilirsiniz. Bu gruplandırma fiziksel değil mantıksaldır. Kapsayıcının içinde, her blobun benzersiz bir adı vardır.
Blobun bölüm anahtarı hesap adı + kapsayıcı adı + blob adı şeklindedir. Bölüm anahtarı, verileri aralıklara bölmek için kullanılır ve bu aralıklar sistem genelinde yük dengelemesi yapılır. Bloblar, bunlara yönelik erişimin ölçeğini genişletmek için birden çok sunucuya dağıtılabilir, ama tek bir blob tek bir sunucudan hizmet alabilir.
Adlandırma şemanız zaman damgaları veya sayısal tanımlayıcılar kullanıyorsa, sistemin etkin yük dengelemesini sınırlayarak bir bölüme giden aşırı trafiğe yol açabilir. Örneğin, yyyy-mm-dd gibi bir zaman damgasına sahip bir blob nesnesi kullanan günlük işlemleriniz varsa, bu işlemin tüm trafiği tek bir bölüm sunucusuna gider. Bunun yerine, adın önüne üç basamaklı karma eklemeyi göz önünde bulundurun. Daha fazla bilgi için bkz . Bölüm Adlandırma Kuralı.
Tek bir blok veya sayfa yazma eylemleri atomiktir, ancak bloklara, sayfalara veya bloblara yayılan işlemler değildir. Bloklar, sayfalar ve bloblar arasında yazma işlemleri gerçekleştirirken tutarlılığı güvence altına almanız gerekiyorsa, bir blob kiralaması kullanarak yazma kilidi alın.
Azure Depolama kuyruklarını bölümleme
Azure Depolama kuyrukları, işlemler arasında zaman uyumsuz mesajlaşma gerçekleştirmenizi sağlar. Azure Depolama hesabı herhangi bir sayıda kuyruk içerebilir ve her kuyruk istediğiniz sayıda ileti içerebilir. Tek sınırlama depolama hesabında kullanılabilen alan miktarıdır. Tek bir iletinin boyut üst sınırı 64 KB'dir. Bundan daha büyük iletilere ihtiyacınız varsa, bunun yerine Azure Service Bus kuyruklarını kullanmayı düşünün.
Her depolama kuyruğunun bunu içeren depolama hesabı içinde benzersiz bir adı vardır. Azure kuyrukları ada göre bölümler. Aynı kuyruğun tüm iletileri aynı bölümde depolanır ve bu bölüm tek bir sunucu tarafından denetlenir. Yükü dengelemeye yardımcı olmak için farklı kuyruklar farklı sunucular tarafından yönetilebilir. Kuyrukların sunuculara ayrılması, uygulamalar ve kullanıcılar açısından saydam bir işlemdir.
Büyük ölçekli bir uygulamada, uygulamanın tüm örnekleri için aynı depolama kuyruğu kullanmayın çünkü bu yaklaşım kuyruğu barındıran sunucunun sık erişimli bir nokta haline gelmesine neden olabilir. Bunun yerine, uygulamanın farklı işlevsel alanları için farklı kuyruklar kullanın. Azure Depolama kuyrukları işlemleri desteklemez, bu nedenle iletileri farklı kuyruklara yönlendirmenin mesajlaşma tutarlılığı üzerinde çok az etkisi olmalıdır.
Azure Depolama kuyruğu saniyede en fazla 2.000 ileti işleyebilir. İletileri bundan daha yüksek bir hızda işlemeniz gerekiyorsa, birden çok kuyruk oluşturmayı göz önünde bulundurun. Örneğin, global bir uygulamada her bölgede çalıştırılan uygulama örneklerini işlemek üzere ayrı depolama hesaplarında ayrı depolama kuyrukları oluşturun.
Azure Service Bus'ın bölümlenmesi
Azure Service Bus, Service Bus kuyruğuna veya konusuna gönderilen iletileri işlemek için bir ileti aracısı kullanır. Varsayılan olarak, kuyruğa veya konuya gönderilen iletiler aynı ileti aracısı işlemiyle işlenir. Bu mimari ileti kuyruğunun genel aktarım hızına bir sınırlama getirebilir. Öte yandan, kuyruğu veya konuyu oluşturulduktan sonra da bölümleyebilirsiniz. Bunu yapmak için kuyruk veya konu açıklamasının EnablePartitioning özelliğini true olarak ayarlarsınız.
Bölümlenmiş bir kuyruk veya konu birden çok parçaya bölünür ve bunların her biri ayrı ileti deposu ve ileti aracısı tarafından desteklenir. Service Bus bu parçaları oluşturma ve yönetme sorumluluğunu üstlenir. Uygulama bölümlenmiş bir sorgu veya konuya ileti gönderdiğinde, Service Bus iletiyi söz konusu kuyruk veya konunun bir parçasına atar. Uygulama bir kuyruk veya abonelikten ileti aldığında, Service Bus kullanılabilir bir sonraki ileti için her parçayı denetler ve ardından bunu işlenmek üzere uygulamaya geçirir.
Bu yapı ileti aracıları ve ileti depoları arasında yükü dağıtmaya yardımcı olarak ölçeklenebilirliği artırır ve kullanılabilirliği geliştirir. Bir parçanın ileti aracısı veya ileti deposu geçici olarak kullanılamaz durumdaysa, Service Bus iletileri diğer kullanılabilir parçaların birinden alabilir.
Service Bus iletiyi bir parçaya şu şekilde atar:
İleti bir oturuma aitse, SessionId özelliği için aynı değere sahip tüm iletiler aynı parçaya gönderilir.
İleti bir oturuma ait değilse ama gönderen PartitionKey özelliği için bir değer belirtmişse, PartitionKey değeri aynı olan tüm iletiler aynı parçaya gönderilir.
Not
SessionId ve PartitionKey özelliklerinin her ikisi de belirtilmişse, bunların aynı değere ayarlanmış olması gerekir yoksa ileti reddedilir.
İletinin SessionId ve PartitionKey özellikleri belirtilmemişse ama yinelenen öğe algılaması etkinleştirilmişse, MessageId özelliği kullanılır. Aynı MessageId değerine sahip tüm iletiler aynı parçaya yönlendirilir.
İletilerin SessionId, PartitionKey veya MessageId özelliği yoksa, Service Bus iletileri parçalara sıralı olarak atar. Bir parça kullanılamaz durumdaysa Service Bus bir sonraki parçaya geçer. Başka bir deyişle, ileti altyapısındaki geçici bir hata ileti gönderme işleminin başarısız olmasına neden olmaz.
Service Bus ileti kuyruğu veya konusunun bölümlenip bölümlenmeyeceğine veya nasıl bölümleneceğine karar verirken aşağıdaki noktaları göz önünde bulundurun:
Service Bus kuyrukları ve konuları Service Bus ad alanı kapsamında oluşturulur. Service Bus şu anda ad alanı başına en çok 100 bölümlenmiş kuyruğa veya konuya izin vermektedir.
Her Service Bus ad alanı kullanılabilir kaynaklarla ilgili olarak, konu başına abonelik sayısı, saniyede eş zamanlı gönderme ve alma isteklerinin sayısı ve kurulabilecek eş zamanlı bağlantı sayısı üst sınırı gibi kotalar belirler. Bu kotalar Service Bus kotalarında belgelenmiştir. Bu değerleri aşacağınızı tahmin ediyorsanız, kendi kuyrukları ve konularıyla ek ad alanları oluşturun ve çalışmayı bu ad alanlarına yayın. Örneğin, global bir uygulamada her bölgede ayrı ad alanları oluşturun ve uygulama örneklerini en yakın ad alanındaki kuyrukları ve konuları kullanacak şekilde yapılandırın.
Bir işlem kapsamında gönderilen iletilerin bölüm anahtarını belirtmesi gerekir. Bu anahtar SessionId, PartitionKey veya MessageId özelliği olabilir. Aynı işlem kapsamında gönderilen tüm iletiler aynı bölüm anahtarını belirtmelidir çünkü bunların aynı ileti aracısı işlemi tarafından işlenmesi gerekir. Aynı işlem içinde farklı kuyruklara veya konulara ileti gönderemezsiniz.
Bölümlenmiş kuyruklar ve konular, boşta kaldıklarında otomatik olarak silinecek şekilde yapılandırılamaz.
Platformlar arası veya karma çözümler oluşturuyorsanız, bölümlenmiş kuyruklar ve konular şu anda Gelişmiş İleti Sıraya Alma Protokolü (AMQP) ile kullanılamaz.
Azure Cosmos DB'yi bölümleme
NoSQL için Azure Cosmos DB, JSON belgelerini depolamaya yönelik bir NoSQL veritabanıdır. Azure Cosmos DB veritabanındaki bir belge, bir nesnenin veya başka bir veri parçasının JSON serileştirilmiş bir gösterimidir. Her belgenin benzersiz bir kimlik içermesi gereksinimi dışında, zorunlu tutulan sabit şemalar yoktur.
Belgeler, koleksiyonlar halinde düzenlenir. İlgili belgeleri bir koleksiyonda bir arada gruplandırabilirsiniz. Örneğin, blog gönderilerinin tutulduğu bir sistemde her blog gönderisinin içeriğini koleksiyonda bir belge olarak depolayabilirsiniz. Ayrıca her konu türü için de koleksiyonlar oluşturabilirsiniz. Alternatif olarak, farklı yazarların kendi blog gönderilerini denetledikleri ve yönettikleri bir sistem gibi çok kiracılı bir uygulamada, blogları yazara göre bölümleyebilir ve her yazar için ayrı koleksiyonlar oluşturabilirsiniz. Koleksiyonlara ayrılan depolama alanı esnektir ve gerektiğinde küçültülebilir veya büyütülebilir.
Azure Cosmos DB, uygulama tanımlı bölüm anahtarına göre verilerin otomatik olarak bölümlenmesine destek sağlar. Mantıksal bölüm, tek bir bölüm anahtarı değerinin tüm verilerinin depolandığı bölümdür. Bölüm anahtarı olarak aynı değeri paylaşan tüm belgeler aynı mantıksal birim içine yerleştirilir. Azure Cosmos DB, değerleri bölüm anahtarının karması doğrultusunda dağıtır. Mantıksal bölümün boyutu en fazla 20 GB'tır. Dolayısıyla, tasarım zamanında bölüm anahtarı seçimi önemli bir karardır. Geniş bir değer aralığı ve hatta erişim desenleri olan bir özellik seçin. Daha fazla bilgi için bkz. Azure Cosmos DB'de bölüm ve ölçek.
Not
Her Azure Cosmos DB veritabanı, aldığı kaynak miktarını belirleyen bir performans düzeyine sahiptir. Performans düzeyi bir istek birimi (RU) hız sınırıyla ilişkilendirilmiştir. RU hız sınırı ayrılan ve bu koleksiyonun özel kullanımına sunulan kaynakların miktarını belirtir. Koleksiyonun maliyeti o koleksiyon için seçilen performans düzeyine bağlıdır. Performans düzeyi (ve RU hız sınırı) ne kadar yüksekse ücreti de o kadar yüksek olur. Azure Portal'ı kullanarak koleksiyonun performans düzeyini ayarlayabilirsiniz. Daha fazla bilgi için bkz. Azure Cosmos DB'de İstek Birimleri.
Azure Cosmos DB'nin sağladığı bölümleme mekanizması yeterli değilse, verileri uygulama düzeyinde parçalamanız gerekebilir. Belge koleksiyonları, tek bir veritabanı içinde verileri bölümlemek için doğal bir mekanizma sağlar. Parçalama yöntemini uygulamanın en basit yolu, her parça için bir koleksiyon oluşturmaktır. Kapsayıcılar mantıksal kaynaklardır ve bir veya birden çok sunucuya yayılabilir. Sabit boyutlu kapsayıcıların maksimum sınırı 20 GB ve 10.000 RU/sn aktarım hızıdır. Sınırsız kapsayıcıların depolama boyutu üst sınırı yoktur, ancak bir bölüm anahtarı belirtmelidir. Uygulama parçalama yöntemiyle, istemci uygulamasının genellikle verilerin parça anahtarını tanımlayan bazı özniteliklerini temel alıp kendi eşleme mekanizmasını uygulayarak, istekleri uygun parçaya yönlendirmesi gerekir.
Tüm veritabanları bir Azure Cosmos DB veritabanı hesabı bağlamında oluşturulur. Tek bir hesap çeşitli veritabanları içerebilir ve veritabanlarının hangi bölgelerde oluşturulduğunu belirtir. Her hesap ayrıca kendi erişim denetimini de zorlar. Azure Cosmos DB hesaplarını kullanarak parçalara erişmesi gereken kullanıcılara yakın parçaları (veritabanlarındaki koleksiyonlar) coğrafi olarak bulabilir ve yalnızca bu kullanıcıların bunlara bağlanabilmesi için kısıtlamalar uygulayabilirsiniz.
NoSQL için Azure Cosmos DB ile verilerin nasıl bölümlenmesine karar verirken aşağıdaki noktaları göz önünde bulundurun:
Azure Cosmos DB veritabanı için kullanılabilen kaynaklar hesabın kota sınırlamalarına tabidir. Her veritabanı bir dizi koleksiyon barındırabilir ve her koleksiyon, o koleksiyonun RU hız sınırını (ayrılmış aktarım hızı) belirleyen bir performans düzeyiyle ilişkilendirilmiştir. Daha fazla bilgi için bkz. Azure aboneliği ile hizmet limitleri, kotalar ve kısıtlamalar.
Her belgenin içinde bulunduğu koleksiyonda onu benzersiz olarak tanımlamak için kullanılabilecek bir özniteliği olmalıdır. Bu öznitelik, belgenin hangi koleksiyonda tutulduğunu tanımlayan parça anahtarından farklıdır. Koleksiyon çok fazla sayıda belge içerebilir. Teorik olarak, bunu sınırlayan tek öğe belge kimliğinin uzunluk üst sınırıdır. Belge kimliği en çok 255 karakter olabilir.
Belge üzerindeki tüm işlemler, bir işlemin bağlamı içinde gerçekleştirilir. İşlemlerin kapsamı belgeyi içeren koleksiyon olarak belirlenir. İşlem başarısız olursa, gerçekleştirdiği çalışma geri alınır. Belge üzerinde bir işlem yapılırken, tüm değişiklikler anlık görüntü düzeyi yalıtıma tabidir. Bu mekanizma, örneğin bir yeni belge oluşturma isteği başarısız olursa aynı anda veritabanını sorgulayan başka bir kullanıcı daha sonra kaldırılacak olan kısmi belgeyi görmez.
Veritabanı sorgularının kapsamı da koleksiyon düzeyinde belirlenir. Tek bir sorgu tek bir koleksiyondan veri alabilir. Birden çok koleksiyondan veri almanız gerekiyorsa, her koleksiyonu tek tek sorgulamalı ve sonuçları uygulama kodunuzda birleştirmelisiniz.
Azure Cosmos DB, belgelerin yanı sıra bir koleksiyonda depolanabilen programlanabilir öğeleri destekler. Bunlar saklı yordamlar, kullanıcı tanımlı işlevler ve tetikleyicilerdir (JavaScript'te yazılmış). Bu öğeler aynı koleksiyon içindeki tüm belgelere erişebilir. Üstelik, bu öğeler çevreleyen işlemin kapsamı içinde (belge üzerinde gerçekleştirilen bir oluşturma, silme veya değiştirme işleminin sonucu olarak çalıştırılan bir tetikleyici söz konusu olduğunda) veya yeni bir işlem başlatılarak çalıştırılır (açık bir istemci isteğinin sonucu olarak çalıştırılan bir saklı yordam söz konusu olduğunda). Programlanabilir öğenin kodu bir özel durum oluşturursa, işlem geri alınır. Belgeler arasındaki bütünlüğü ve tutarlılığı korumak için saklı yordamları ve tetikleyicileri kullanabilirsiniz, ama söz konusu belgelerin aynı koleksiyonun parçası olması gerekir.
Veritabanlarında tutmak istediğiniz koleksiyonlar, koleksiyonların performans düzeyi tarafından tanımlanan aktarım hızı sınırlarını aşmayacak gibi olmalıdır. Daha fazla bilgi için bkz. Azure Cosmos DB'de İstek Birimleri. Bu sınırlara ulaşılacağını düşünüyorsanız, koleksiyon başına düşen yükü azaltmak için koleksiyonları farklı hesaplardaki veritabanları arasında bölmeyi göz önünde bulundurun.
Azure Search'i bölümleme
Veriler için arama yapabilme özelliği çoğunlukla birçok web uygulamasının sağladığı birincil gezinme ve keşif yöntemidir. Kullanıcıların arama ölçütü bileşimleri temelinde kaynakları (örneğin, e-ticaret uygulamasında ürünleri) hızla bulabilmesine yardımcı olur. Azure Search hizmeti web içeriği üzerinde tam metin araması özellikleri sağlar ve yazarken tamamlama, yakın eşleşmeler temelinde önerilen sorgular ve çok yönlü gezinme gibi özellikler içerir. Daha fazla bilgi için bkz . Azure Search nedir?.
Azure Search aranabilir içeriği bir veritabanında JSON belgeleri olarak depolar. Bu belgelerdeki aranabilir alanları belirten dizinleri siz tanımlar ve bu tanımları Azure Search'e sağlarsınız. Kullanıcı arama isteği gönderdiğinde, Azure Search eşleşen öğeleri bulmak için uygun dizinleri kullanır.
Çekişmeyi azaltmak için, Azure Search tarafından kullanılan depolama 1, 2, 3, 4, 6 veya 12 bölüme ayrılabilir ve her bölüm en çok 6 kez çoğaltılabilir. Bölüm sayısının çoğaltma sayısıyla çarpımından elde edilen sayı arama birimi (SU) olarak adlandırılır. Tek bir Azure Search örneği en çok 36 SU içerebilir (12 bölümün bulunduğu bir veritabanı yalnızca en çok 3 çoğaltmayı destekler).
Hizmetinize ayrılmış her SU için faturalandırılırsınız. Aranabilir içeriğin miktarı veya arama isteklerinin hızı arttıkça, fazla yükü işlemek için Azure Search'ün mevcut örneğine SU ekleyebilirsiniz. Azure Search belgeleri bölümler arasında kendisi eşit olarak dağıtır. Şu anda el ile bölümleme stratejileri desteklenmemektedir.
Her bölüm en çok 15 milyon belge içerebilir veya 300 GB depolama alanı kaplayabilir (hangisi daha küçükse). En çok 50 dizin oluşturabilirsiniz. Hizmetin performansı değişiklik gösterir ve belgelerin karmaşıklığına, kullanılabilir dizinlere ve ağ gecikmesinin etkilerine bağlıdır. Ortalama olarak, tek bir çoğaltmanın (1 SU) saniyede 15 sorguyu (QPS) işleyebilmesi gerekir; ancak daha kesin bir aktarım hızı ölçümü elde etmek için kendi verilerinizle karşılaştırmalı testler yapmanızı öneririz. Daha fazla bilgi için bkz . Azure Search'te hizmet sınırları.
Not
Aranabilir belgelerde dizeler, Boole, sayısal veriler, tarih saat verileri ve bazı coğrafi veriler gibi sınırlı bir veri türü kümesini depolayabilirsiniz. Daha fazla bilgi için Microsoft web sitesindeki Desteklenen veri türleri (Azure Search) sayfasına bakın.
Azure Search'ün hizmetin her örneği için verileri bölümleme şekli üzerinde sınırlı bir denetiminiz vardır. Bununla birlikte, genel bir ortamda aşağıdaki stratejilerden birini kullanıp hizmetin kendisini bölümleyerek performansı daha fazla geliştirebilir, gecikmeyi ve çekişmeyi daha da azaltabilirsiniz:
Her coğrafi bölgede bir Azure Search örneği oluşturun ve istemci uygulamalarının kullanılabilir en yakın örneğe yönlendirildiğinden emin olun. Bu strateji aranabilir içerikte yapılan tüm güncelleştirmelerin zaman geçirmeden hizmetin tüm örneklerine çoğaltılmasını gerektirir.
Azure Search'ün iki katmanını oluşturun:
- Bölgedeki kullanıcılar tarafından en sık erişilen verilerin bulunduğu her bölgede yerel bir hizmet. Kullanıcılar hızlı ancak sınırlı sonuçlar almak için istekleri buraya yönlendirebilir.
- Tüm verileri kapsayan genel bir hizmet. Kullanıcılar daha yavaş ancak daha eksiksiz sonuçlar almak için istekleri buraya yönlendirebilir.
Bu yaklaşım, aranan verilerde önemli bölgesel değişikliklerin olduğu durumlara çok uygundur.
Bölümleme Redis için Azure Cache
Redis için Azure Cache, bulutta Redis anahtar-değer veri deposunu temel alan bir paylaşılan önbelleğe alma hizmeti sağlar. Adından da anlaşılacağı gibi, Redis için Azure Cache bir önbelleğe alma çözümü olarak tasarlanmıştır. Bunu kalıcı bir veri deposu olarak değil yalnızca geçici verileri tutmak için kullanın. önbellek kullanılamıyorsa, Redis için Azure Cache kullanan uygulamaların çalışmaya devam edebilmesi gerekir. Redis için Azure Cache yüksek kullanılabilirlik sağlamak için birincil/ikincil çoğaltmayı destekler, ancak şu anda en büyük önbellek boyutunu 53 GB ile sınırlar. Bundan daha fazla alana ihtiyacınız varsa, ek önbellekler oluşturmalısınız. Daha fazla bilgi için bkz. Redis için Azure Cache.
Redis veri deposunu bölümleme işlemi verileri Redis hizmetinin örnekleri arasında bölmeyi içerir. Her örnek tek bir bölüm oluşturur. Redis için Azure Cache, Redis hizmetlerini bir cephenin arkasında özetler ve bunları doğrudan kullanıma sunmaz. Bölümleme uygulamanın en basit yolu, birden çok Redis için Azure Cache örneği oluşturmak ve verileri bunlara yaymaktır.
Her veri öğesini, bu veri öğesinin depolandığı önbelleği belirten bir tanımlayıcıyla (bölüm anahtarı) ilişkilendirebilirsiniz. İstemci uygulama mantığı da bu tanımlayıcıyı kullanarak istekleri uygun bölüme yönlendirebilir. Bu düzen çok basittir, ancak bölümleme düzeni değişirse (örneğin, ek Redis için Azure Cache örnekleri oluşturulursa), istemci uygulamalarının yeniden yapılandırılması gerekebilir.
Yerel Redis (Redis için Azure Cache değil), Redis kümelemesi temelinde sunucu tarafı bölümlemesi destekler. Bu yaklaşımda, karma mekanizmasını kullanarak verileri sunucular arasında eşit bölebilirsiniz. Her Redis sunucusu bölümde tutulan karma anahtar aralığını açıklayan meta verileri depolar ve aynı zamanda diğer sunuculardaki bölümlerde hangi karma anahtarların bulunduğu hakkında da bilgi içerir.
İstemci uygulamaları istekleri doğrudan herhangi bir katılımcı Redis sunucusuna (büyük olasılıkla en yakındakine) gönderir. Redis sunucusu, istemci isteğini inceler. Yerel olarak çözülebiliyorsa, istenen işlemi gerçekleştirir. Aksi takdirde isteği uygun sunucuya iletir.
Bu model Redis kümeleme özelliği kullanılarak gerçekleştirilir ve Redis web sitesinin Redis kümesi öğreticisi sayfasında daha ayrıntılı olarak açıklanır. Redis kümeleme özelliği istemci uygulamaları için saydamdır. İstemcileri yeniden yapılandırmanıza gerek kalmadan kümeye ek Redis sunucuları eklenebilir (ve veriler yeniden bölümlenebilir).
Önemli
Redis için Azure Cache şu anda yalnızca Premium katmanda Redis kümelemsini desteklemektedir.
Redis web sitesinin Bölümleme: verileri birden çok Redis örneği arasında bölme sayfasında, Redis ile bölümlemeyi gerçekleştirme hakkında daha fazla bilgi sağlanır. Bu bölümün kalanında, istemci tarafı veya ara sunucu destekli bölümleme gerçekleştirdiğiniz varsayılmıştır.
Redis için Azure Cache ile verilerin nasıl bölümlenmesine karar verirken aşağıdaki noktaları göz önünde bulundurun:
Redis için Azure Cache kalıcı bir veri deposu görevi görmesi amaçlanmadığından uygulama kodunuzun önbellek olmayan bir konumdan veri alabilmesi gerekir.
Sık sık birlikte erişilen veriler aynı bölümde tutulmalıdır. Redis verileri yapılandırmak için son derece iyileştirilmiş çeşitli mekanizmalar sağlayan güçlü bir anahtar-değer deposudur. Bu mekanizmalar aşağıdakilerden biri olabilir:
- Basit dizeler (uzunluğu en çok 512 MB olan basit dizeler)
- Listeler gibi toplam değerler (kuyruk veya yığın işlevi görebilir)
- Kümeler (sıralanmış veya sıralanmamış)
- Karmalar (bir nesnedeki alanları temsil eden öğeler gibi, ilgili alanları birlikte gruplandırabilir)
Toplam değer türleri birçok ilgili değeri aynı anahtarla ilişkilendirmenize olanak tanır. Redis anahtarı bir listeyi, kümeyi veya karmayı tanımlar; içerdiği veri öğelerini tanımlamaz. Bu türlerin tümü Redis için Azure Cache kullanılabilir ve Redis web sitesindeki Veri türleri sayfasında açıklanmıştır. Örneğin, bir e-ticaret sisteminin müşterilerin verdiği siparişleri izleyen bölümünde her müşterinin ayrıntıları müşteri kimliği kullanılarak anahtarlanan bir Redis karmasında depolanabilir. Her karma müşteri için bir sipariş kimlikleri koleksiyonu barındırabilir. Siparişler, yine karma olarak yapılandırılmış ve sipariş kimliği kullanılarak anahtarlanmış ayrı bir Redis kümesinde tutulabilir. Şekil 8'de bu yapı gösterilmiştir. Redis'in herhangi bir biçimde başvurusal bütünlük gerçekleştirmediğine, dolayısıyla müşterilerle siparişler arasındaki ilişkileri korumanın geliştiricinin sorumluluğunda olduğuna dikkat edin.
Şekil 8. Müşteri siparişlerini ve ayrıntılarını kaydetmek için Redis depolamada önerilen yapı.
Not
Redis'de, tüm anahtarlar ikili veri değerleridir (Redis dizeleri gibi) ve en çok 512 MB veri içerebilir. Teorik olarak, bir anahtar hemen her bilgiyi içerebilir. Bununla birlikte, anahtarlar için verilerin türünü açıklayan ve varlığı tanımlayan (ama aşırı uzun olmayan), tutarlı bir adlandırma kuralı benimsenmesini öneririz. Yaygın bir yaklaşım "varlık_türü:kimlik" biçiminde anahtarlar kullanmaktır. Örneğin, kimliği 99 olan bir müşterinin anahtarını belirtmek için "müşteri:99" kullanabilirsiniz.
İlgili bilgileri aynı veritabanının farklı toplamalarında depolayarak dikey bölümleme gerçekleştirebilirsiniz. Örneğin bir e-ticaret uygulamasında, ürünler hakkında sık erişilen bilgileri bir Redis karmasında ve daha seyrek erişilen ayrıntılı bilgileri bir diğerinde depolayabilirsiniz. Her iki karma da anahtarın bir parçası olarak aynı ürün kimliğini kullanabilir. Örneğin, ürün bilgileri için "product: nn" (burada nn, ürün kimliğidir) ve ayrıntılı veriler için "product_details: nn" kullanabilirsiniz. Bu strateji çoğu sorgunun alma olasılığı yüksek olan verilerin hacmini azaltmanıza yardımcı olabilir.
Redis veri deposunu yeniden bölümleyebilirsiniz, ama bunun karmaşık ve zaman alan bir görev olduğunu unutmayın. Redis kümelemesi verileri otomatik olarak yeniden bölümleyebilir, ancak bu özellik Redis için Azure Cache ile kullanılamaz. Dolayısıyla, bölümleme düzeninizi tasarlarken zamanla beklenen veri artışına yer sağlamak için her bölümde yeterli boş alan bırakmayı deneyin. Ancak, Redis için Azure Cache verileri geçici olarak önbelleğe almak üzere tasarlandığını ve önbellekte tutulan verilerin yaşam süresi (TTL) değeri olarak belirtilen sınırlı bir ömrü olabileceğini unutmayın. Daha geçici olan verilerde TTL kısa olabilir ama statik veriler için TTL çok uzun olabilir. Yaşam süresi uzun olan verilerin önbelleği doldurma olasılığı varsa, önbellekte böyle verilerden çok büyük miktarda depolamayın. Alan premium olduğunda Redis için Azure Cache verileri kaldırmasına neden olan bir çıkarma ilkesi belirtebilirsiniz.
Not
Redis için Azure Cache kullandığınızda, uygun fiyatlandırma katmanını seçerek önbelleğin en büyük boyutunu (250 MB ile 53 GB arası) belirtirsiniz. Ancak, bir Redis için Azure Cache oluşturulduktan sonra boyutunu artıramaz (veya azaltamazsınız).
Redis toplu işleri ve işlemleri birden çok bağlantıya yayılamaz, dolayısıyla bir toplu işin veya işlemin etkilediği tüm verilerin aynı veritabanında (parçada) tutulması gerekir.
Not
Redis işlemi kapsamındaki bir işlem dizisinin atomik olması gerekmez. İşlemi oluşturan komutlar çalıştırılmadan önce doğrulanır ve kuyruğa alınır. Bu aşamada bir hata oluşursa, kuyruğun tamamı atılır. Bununla birlikte, işlem başarıyla gönderildikten sonra kuyruğa alınmış komutlar sırayla çalıştırılır. Komutlardan herhangi biri başarısız olursa, yalnızca o komutun çalıştırılması durdurulur. Kuyrukta ondan önceki ve sonraki tüm komutlar gerçekleştirilir. Daha fazla bilgi için Redis web sitesinin İşlemler sayfasına gidin.
Redis sınırlı sayıda atomik işlemi destekler. Bu tür işlemler arasında birden çok anahtar ve değeri desteleyen yalnızca MGET ve MSET işlemleridir. MGET işlemleri belirtilen bir anahtar listesi için değer koleksiyonunu döndürür ve MSET işlemleri de belirtilen anahtar listesi için değer koleksiyonunu depolar. Bu işlemleri kullanmanız gerekirse, MSET ve MGET komutlarının başvurduğu anahtar-değer çiftlerinin aynı veritabanının içinde depolanmış olması gerekir.
Azure Service Fabric'i bölümleme
Azure Service Fabric bulutta dağıtılmış uygulamalar için çalışma zamanı sağlayan bir mikro hizmet platformudur. Service Fabric .NET konuk yürütülebilir dosyaları, durum bilgisi olan ve durum bilgisi olmayan hizmetleri ve kapsayıcıları destekler. Durum bilgisi olan hizmetler, verileri Service Fabric kümesi içindeki bir anahtar-değer koleksiyonunda kalıcı olarak depolamak için güvenilir bir koleksiyon sağlar. Anahtarları güvenilir bir koleksiyonda bölümleme stratejileri hakkında daha fazla bilgi için bkz . Azure Service Fabric'te güvenilir koleksiyonlar için yönergeler ve öneriler.
Sonraki adımlar
Azure Service Fabric'e genel bakış, Azure Service Fabric'e giriş bilgileri sağlar.
Partition Service Fabric güvenilir hizmetleri, Azure Service Fabric'teki güvenilir hizmetler hakkında daha fazla bilgi sağlar.
Azure Event Hubs'ı bölümleme
Azure Event Hubs çok büyük ölçeklerde veri akışı için tasarlanmıştır ve yatay ölçeklendirmeye olanak tanımak için bölümleme özelliği hizmette yerleşik olarak bulunur. Her tüketici ileti akışının yalnızca belirli bir bölümünü okur.
Olay yayımcısı yalnızca bölüm anahtarını bilir, olayların yayımlandığı bölümü bilmez. Anahtar ile bölümün bu şekilde ayrılması göndereni aşağı akış işleme hakkında çok fazla bilgi sahibi olma gereksiniminden kurtarır. (Olayları doğrudan belirli bir bölüme göndermek de mümkündür ama genel olarak önerilmez.)
Bölüm sayısını seçerken uzun vadeli ölçeği göz önünde bulundurun. Olay hub'ı oluşturulduktan sonra, bölümlerin sayısını değiştiremezsiniz.
Sonraki adımlar
Event Hubs'da bölümleri kullanma hakkında daha fazla bilgi için bkz. Event Hubs nedir?.
Kullanılabilirlik ile tutarlılık arasındaki denge hakkında dikkate alınacak noktalar için bkz. Event Hubs'da kullanılabilirlik ve tutarlılık.