Azure Cosmos DB'de bölümleme ve yatay ölçeklendirme

Azure Cosmos DB, uygulamanızın performans gereksinimlerini karşılamak üzere bir veritabanındaki kapsayıcıları ölçeklendirmek için bölümleme kullanır. Kapsayıcıdaki öğeler mantıksal bölümler olarak adlandırılan ayrı alt kümelere ayrılır. Mantıksal bölümler, kapsayıcıdaki her öğeyle ilişkili bölüm anahtarının değerine göre oluşur. Mantıksal bölümdeki tüm öğeler aynı bölüm anahtarı değerine sahiptir.

Örneğin, kapsayıcı öğeleri barındırır. Her öğenin özelliği için UserID benzersiz bir değeri vardır. UserID Kapsayıcıdaki öğeler için bölüm anahtarı olarak hizmet verirse ve 1.000 benzersiz UserID değer varsa, kapsayıcı için 1.000 mantıksal bölüm oluşturulur.

Kapsayıcıdaki her öğenin mantıksal bölümünü belirleyen bir bölüm anahtarı ve bu bölümde benzersiz bir öğe kimliği vardır. Bölüm anahtarı ve öğe kimliği birleştirilerek öğenin dizini oluşturulur ve bu dizin öğeyi benzersiz olarak tanımlar. Bölüm anahtarı seçmek, uygulamanızın performansını etkileyen önemli bir karardır.

Uyarı

Bazı dağıtılmış veritabanı sistemlerinde ve öğrenme malzemelerinde, verilerin parçalar arasında nasıl dağıtıldığını belirleyen özelliği tanımlamak için parça anahtarı terimi kullanılır. Azure Cosmos DB'de bu kavram bölüm anahtarı olarak adlandırılır.

Her iki terim de verileri dağıtmak ve bulmak için kullanılan değere başvurur, ancak bölüm anahtarı , Azure Cosmos DB belgeleri ve API'leri genelinde kullanılan resmi ve doğru terimdir.

Bu makalede mantıksal ve fiziksel bölümler arasındaki ilişki açıklanır, bölümleme için en iyi yöntemler açıklanır ve Azure Cosmos DB'de yatay ölçeklendirmenin nasıl çalıştığına ilişkin ayrıntılı bir görünüm sağlanır. Bölüm anahtarınızı seçmek için bu iç ayrıntıları anlamanız gerekmez, ancak Azure Cosmos DB'nin nasıl çalıştığını netleştirmek için bu makale bunları kapsar.

Mantıksal bölümler

Mantıksal bölüm, aynı bölüm anahtarını paylaşan bir öğe kümesidir. Örneğin, gıda beslenmesi hakkındaki verileri içeren bir kapsayıcıda, tüm öğeler bir foodGroup özellik içerir. Kapsayıcı için bölüm anahtarı olarak kullanın foodGroup . , ve foodGroupgibi Beef ProductsBaked Productsiçin Sausages and Luncheon Meatsbelirli değerleri olan öğe grupları ayrı mantıksal bölümler oluşturur.

Mantıksal bölüm, veritabanı işlemlerinin kapsamını da tanımlar. Anlık görüntü yalıtımına sahip bir işlem kullanarak mantıksal bölüm içindeki öğeleri güncelleştirebilirsiniz. Kapsayıcıya yeni öğeler eklendiğinde, sistem saydam bir şekilde yeni mantıksal bölümler oluşturur. Temel alınan veriler silindiğinde mantıksal bölümü silme konusunda endişelenmeniz gerekmez.

Kapsayıcıdaki mantıksal bölüm sayısıyla ilgili bir sınır yoktur. Her mantıksal bölüm en fazla 20 GB veri depolayabilir. Etkili bölüm anahtarları çok çeşitli olası değerlere sahiptir. Örneğin, tüm öğelerin bir foodGroup özellik içerdiği bir kapsayıcıda, mantıksal bölüm içindeki Beef Products veriler 20 GB'a kadar büyüyebilir. Çok çeşitli olası değerlere sahip bir bölüm anahtarı seçmek, kapsayıcının ölçeklenebilmesini sağlar.

Mantıksal bölümün boyutunun 20 GB'a yaklaşıp yaklaşmadığını izlemek için Azure İzleyici Uyarılarını kullanın.

Fiziksel bölümler

Kapsayıcı, verileri ve aktarım hızını fiziksel bölümler arasında dağıtarak ölçeklendirilir. Dahili olarak, bir veya daha fazla mantıksal bölüm tek bir fiziksel bölümle eşler. Genellikle, küçük kapsayıcılar birçok mantıksal bölüme sahiptir, ancak yalnızca tek bir fiziksel bölüm gerektirir. Mantıksal bölümlerden farklı olarak, fiziksel bölümler bir iç sistem uygulamasıdır ve Azure Cosmos DB bunları tam olarak yönetir.

Kapsayıcıdaki fiziksel bölümlerin sayısı şu özelliklere bağlıdır:

• Sağlanan aktarım hızı miktarı (her fiziksel bölüm saniyede 10.000 istek birimine kadar aktarım hızı sağlayabilir). Fiziksel bölümler için 10.000 RU/sn sınırı, mantıksal bölümlerin de 10.000 RU/sn sınırına sahip olduğunu gösterir çünkü her mantıksal bölüm yalnızca bir fiziksel bölüme eşlenir.

• Toplam veri depolama alanı (her fiziksel bölüm en fazla 50 gigabayt veri depolayabilir).

Uyarı

Fiziksel bölümler, tamamen Azure Cosmos DB tarafından yönetilen bir iç sistem uygulamasıdır. Çözümlerinizi geliştirirken fiziksel bölümlere odaklanmayın çünkü bunları denetleyemezsiniz. Bunun yerine bölüm anahtarlarına odaklanın. Aktarım hızı tüketimini mantıksal bölümler arasında eşit olarak dağıtan bir bölüm anahtarı seçmek, fiziksel bölümler arasında dengeli aktarım hızı tüketimi sağlar.

Kapsayıcıdaki toplam fiziksel bölüm sayısıyla ilgili bir sınır yoktur. Sağlanan aktarım hızınız veya veri boyutunuz arttıkça Azure Cosmos DB, mevcut bölümleri bölerek otomatik olarak yeni fiziksel bölümler oluşturur. Fiziksel bölüm bölmeleri uygulamanızın kullanılabilirliğini etkilemez. Fiziksel bölüm bölündükten sonra, tek bir mantıksal bölüm içindeki tüm veriler aynı fiziksel bölümde depolanmaya devam eder. Fiziksel bölüm bölme, mantıksal bölümlerin fiziksel bölümlere yeni bir eşlemesini oluşturur.

Kapsayıcı için sağlanan aktarım hızı fiziksel bölümler arasında eşit olarak bölünür. İstekleri eşit olarak dağıtmayan bir bölüm anahtarı tasarımı, "sık erişimli" olan bölümlerin küçük bir alt kümesine çok fazla istek yönlendirilmesine neden olabilir. Sık erişimli bölümler sağlanan aktarım hızının verimsiz kullanımına neden olur ve bu da hız sınırlamasına ve daha yüksek maliyetlere neden olabilir.

Örneğin, bölüm anahtarı olarak belirtilen yola /foodGroup sahip bir kapsayıcı düşünün. Kapsayıcıda herhangi bir sayıda fiziksel bölüm olabilir, ancak bu örnekte üç tane olduğunu varsayarız. Tek bir fiziksel bölüm birden çok bölüm anahtarı içerebilir. Örneğin, en büyük fiziksel bölüm en önemli en büyük üç boyut mantıksal bölümünü içerebilir: Beef Products, Vegetable and Vegetable Productsve Soups, Sauces, and Gravies.

Saniyede 18.000 istek birimi (RU/sn) aktarım hızı atarsanız, üç fiziksel bölümden her biri sağlanan toplam aktarım hızının üçte birini kullanır. Seçili fiziksel bölüm içinde mantıksal bölüm anahtarları Beef Products, Vegetable and Vegetable Productsve Soups, Sauces, and Gravies toplu olarak fiziksel bölümün sağlanan 6.000 RU/sn değerini kullanabilir. Sağlanan aktarım hızı kapsayıcınızın fiziksel bölümleri arasında eşit olarak bölündüğü için, aktarım hızı tüketimini eşit olarak dağıtan bir bölüm anahtarı seçmek önemlidir. Daha fazla bilgi için bkz. Doğru mantıksal bölüm anahtarını seçme.

Mantıksal bölümleri yönetme

Azure Cosmos DB, kapsayıcının ölçeklenebilirlik ve performans gereksinimlerini karşılamak için fiziksel bölümlere mantıksal bölümlerin yerleştirilmesini otomatik olarak yönetir. Bir uygulamanın aktarım hızı ve depolama gereksinimleri arttığında Azure Cosmos DB, yükü daha fazla fiziksel bölüme yaymak için mantıksal bölümleri taşır. Fiziksel bölümler hakkında daha fazla bilgi edinin.

Azure Cosmos DB, mantıksal bölümleri fiziksel bölümler arasında dağıtmak için karma tabanlı bölümleme kullanır. Azure Cosmos DB, bir öğenin bölüm anahtarı değerini karma olarak kullanır. Karma sonuç mantıksal bölümü belirler. Ardından Azure Cosmos DB, bölüm anahtarı karmalarının anahtar alanını fiziksel bölümler arasında eşit olarak ayırır.

Saklı yordamlardaki veya tetikleyicilerdeki işlemlere yalnızca tek bir mantıksal bölümdeki öğeler için izin verilir.

Replika setleri

Her fiziksel bölüm, çoğaltma kümesi olarak da adlandırılan bir çoğaltma kümesinden oluşur. Her çoğaltma, veritabanı altyapısının bir örneğini barındırıyor. Çoğaltma kümesi, fiziksel bölümdeki veri depolarını dayanıklı, yüksek oranda kullanılabilir ve tutarlı hale getirir. Fiziksel bölümdeki her çoğaltma, bölümün depolama kotasını devralır. Fiziksel bölümün tüm çoğaltmaları, bu fiziksel bölüme ayrılan aktarım hızını topluca destekler. Azure Cosmos DB, çoğaltma kümelerini otomatik olarak yönetir.

Daha küçük kapsayıcılar genellikle tek bir fiziksel bölüm gerektirir, ancak yine de en az dört çoğaltmaları vardır.

Bu görüntüde mantıksal bölümlerin genel olarak dağıtılan fiziksel bölümlere nasıl eşlenmiş olduğu gösterilir. Görüntüdeki bölüm kümesi , birden çok bölgede aynı mantıksal bölüm anahtarlarını yöneten bir grup fiziksel bölüme başvurur:

Bölüm anahtarı seçme

Bölüm anahtarının iki bileşeni vardır: bölüm anahtarı yolu ve bölüm anahtarı değeri. Örneğin, { "userId" : "Andrew", "worksFor": "Microsoft" } bölüm anahtarı olarak "userId" öğesini seçerseniz, iki bölüm anahtarı bileşeni aşağıda verilmiştir:

• Bölüm anahtarı yolu (örneğin: "/userId"). Bölüm anahtarı yolu alfasayısal ve alt çizgi (_) karakterleri kabul eder. Standart yol gösterimini(/) kullanarak iç içe nesneler de kullanabilirsiniz.

• Bölüm anahtarı değeri (örneğin: "Andrew"). Bölüm anahtarı değeri dize veya sayısal türlerde olabilir.

Azure Cosmos DB hizmet kotaları makalesinde aktarım hızı, depolama ve bölüm anahtarı uzunluğu sınırları hakkında bilgi edinin.

Bölüm anahtarınızı seçmek, Azure Cosmos DB'de basit ama önemli bir tasarım seçimidir. Bölüm anahtarınızı seçtikten sonra yerinde değiştiremezsiniz. Bölüm anahtarınızı değiştirmeniz gerekiyorsa, verilerinizi istediğiniz bölüm anahtarıyla yeni bir kapsayıcıya taşıyın. Kapsayıcı kopyalama işleri bu sürece yardımcı olur. Alternatif olarak, verilerinizin belirli sorgu desenleri için iyileştirilmiş farklı bölüm anahtarlarıyla kopyalarını oluşturmak için genel ikincil dizinler (önizleme) ekleyebilirsiniz.

Tüm kapsayıcılar için bölüm anahtarı şunları yapmalıdır:

• Değişmeyen bir değere sahip bir özellik olun. Bölüm anahtarınız bir özellikse, bu özelliğin değerini güncelleştiremezsiniz.

• Yalnızca String değerleri içerir veya String göre çift duyarlıklı sayıların sınırlarını aşabileceklerse sayıları a'ya dönüştürün. Json belirtimi, birlikte çalışabilirlik sorunları nedeniyle bu sınırın dışındaki sayıları kullanmanın neden kötü bir uygulama olduğunu açıklar. Bu sorunlar özellikle bölüm anahtarı sütunu için geçerlidir çünkü sabittir ve daha sonra veri geçişinin değiştirilmesini gerektirir.

• Yüksek bir kardinaliteye sahip olma. Başka bir deyişle, özelliği çok çeşitli olası değerlere sahip olmalıdır.

• İstek birimi (RU) tüketimini ve veri depolamayı tüm mantıksal bölümlere eşit olarak yayma. Bu dağılım, fiziksel bölümlerinizde RU tüketimi ve depolama dağıtımının eşit şekilde olmasını sağlar.

• Genellikle 2048 bayttan büyük olmayan değerlere veya büyük bölüm anahtarları etkinleştirilmediyse 101 bayt'a sahip olun. Daha fazla bilgi için bkz. büyük bölüm anahtarları

Azure Cosmos DB'de çok öğeli ACID işlemlerine ihtiyacınız varsa saklı yordamları veya tetikleyicileri kullanmanız gerekir. Tüm JavaScript tabanlı saklı yordamların ve tetikleyicilerin kapsamı tek bir mantıksal bölüme göre belirlenir.

Uyarı

Yalnızca bir fiziksel bölümünüz varsa, tüm sorgular aynı fiziksel bölümü hedeflediğinden bölüm anahtarının değeri ilgili olmayabilir.

Bölüm anahtarı türleri

Bölümleme stratejisi	Kullanılması gereken durumlar	Artıları	Eksileri
Normal Bölüm Anahtarı (örneğin, CustomerId, OrderId)	Bölüm anahtarı yüksek kardinaliteye sahip olduğunda ve sorgu desenleriyle (örneğin, CustomerId'ye göre filtreleme) hizalandığında kullanın. Sorguların çoğunlukla tek bir müşterinin verilerini (örneğin, bir müşterinin tüm siparişlerini alma) hedeflediği iş yükleri için uygundur.	Yönetimi kolaydır. Erişim deseni bölüm anahtarıyla eşleştiğinde verimli sorgular (örneğin, tüm siparişleri CustomerId ile sorgulama). Erişim desenleri tutarlıysa bölümler arası sorguları engeller.	Bazı değerler (örneğin, birkaç yüksek trafikli müşteri) diğerlerinden daha fazla veri oluşturursa sık erişimli bölüm riski. Belirli bir anahtar için veri hacmi hızla artarsa mantıksal bölüm başına 20 GB sınırına isabet edebilir.
Yapay Bölüm Anahtarı (örneğin, CustomerId + OrderDate)	Tek bir alan hem yüksek kardinaliteye sahip olduğunda hem de sorgu desenleri ile eşleştiğinde kullanın. Verilerin fiziksel bölümler arasında eşit bir şekilde dağıtılması gereken yoğun yazma iş yükleri (örneğin, aynı tarihte verilen birçok sipariş) için iyidir.	Sık erişimli bölümleri azaltarak verileri bölümler arasında eşit şekilde dağıtmaya yardımcı olur (örneğin, siparişleri hem CustomerId hem de OrderDate ile dağıtma). Yazmaları birden çok bölüme yayar ve aktarım hızını artırır.	Yalnızca bir alana göre filtreleyen sorgular (örneğin, yalnızca CustomerId) bölümler arası sorgulara neden olabilir. Bölümler arası sorgular daha yüksek RU tüketimine (var olan her fiziksel bölüm için 2-3 RU/sn ek ücret) ve gecikme süresine yol açabilir.
Hiyerarşik Bölüm Anahtarı (HPK) ( örneğin, CustomerId/OrderId, StoreId/ProductId)	Büyük ölçekli veri kümelerini desteklemek için çok düzeyli bölümlemeye ihtiyacınız olduğunda kullanın. Sorgular hiyerarşinin birinci ve ikinci düzeylerine göre filtrelendiğinde idealdir.	Birden çok bölümleme düzeyi oluşturarak 20 GB sınırını önlemeye yardımcı olur. Her iki hiyerarşik düzeyde de verimli sorgulama (örneğin, önce CustomerID, ardından OrderID ile filtreleme). En üst düzeyi hedefleyen sorgular için bölümler arası sorguları en aza indirir (örneğin, belirli bir CustomerID'den tüm verileri alma).	birinci düzey anahtarın yüksek kardinaliteye sahip olduğundan ve çoğu sorguya dahil edildiğinden emin olmak için dikkatli bir planlama gerektirir. Yönetmesi normal bir bölüm anahtarından daha karmaşıktır. Sorgular hiyerarşiyle uyumlu değilse (örneğin, yalnızca CustomerID ilk düzey olduğunda OrderID'ye göre filtreleme), sorgu performansı olumsuz etkilenebilir.
Genel İkincil Dizin (GSI) - önizleme (örneğin, kaynak CustomerId kullanır, GSI OrderId kullanır)	Tüm sorgu desenleri için çalışan tek bir bölüm anahtarı bulamadıysanız kullanın. Birden çok bağımsız özelliği verimli bir şekilde sorgulaması gereken ve çok sayıda fiziksel bölüme sahip iş yükleri için idealdir.	GSI bölüm anahtarı kullanılırken bölümler arası sorguları ortadan kaldırır. Kaynak kapsayıcıdan otomatik eşitleme ile aynı verilerde birden çok sorgu deseni sağlar. İş yükleri arasında performans yalıtımı.	Her GSI'nin ek depolama alanı ve RU maliyetleri vardır. GSI'daki veriler sonunda kaynak kapsayıcıyla tutarlıdır.

Yoğun okuma özellikli kapsayıcılar için bölüm anahtarları

Çoğu kapsayıcı için, bölüm anahtarı seçerken dikkate almanız gereken tek şey bu ölçütlerdir. Ancak büyük okuma ağırlıklı kapsayıcılar için, sorgularınızda sık sık filtre olarak görünen bir bölüm anahtarı seçmek isteyebilirsiniz. Bölüm anahtarını filtre koşuluna dahil etmek, sorguların yalnızca ilgili fiziksel bölümlere verimli bir şekilde yönlendirilmesine olanak tanır.

İş yükünüzün isteklerinin çoğu sorguysa ve sorgularınızın çoğu aynı özellik üzerinde eşitlik filtresi kullanıyorsa, bu özellik iyi bir bölüm anahtarı seçimidir. Örneğin, üzerinde UserIDfiltreleyen bir sorguyu sık sık çalıştırıyorsanız bölüm anahtarı olarak seçmek UserID bölümler arası sorgu sayısını azaltır.

Kapsayıcınız küçükse, bölümler arası sorguların performansı konusunda endişelenmek için büyük olasılıkla yeterli fiziksel bölüme sahip değilsinizdir. Azure Cosmos DB'deki küçük kapsayıcıların çoğu yalnızca bir veya iki fiziksel bölüm gerektirir.

Kapsayıcınız birkaç fiziksel bölüme kadar büyüyebilirse, bölümler arası sorguları en aza indiren bir bölüm anahtarı seçtiğinizden emin olmanız gerekir. Aşağıdaki senaryolardan biri doğruysa kapsayıcınızın birkaçtan fazla fiziksel bölüme ihtiyacı vardır:

• Kapsayıcınızda 30.000'den fazla istek birimi sağlandı

• Kapsayıcınız 100 GB'ın üzerinde veri depolar

Bölümler arası sorgular için genel ikincil dizinler

Uygulamanızın birden çok farklı özelliği verimli bir şekilde kullanarak verileri sorgulaması gerekiyorsa, genel ikincil dizinler (önizleme), veri kümesi için bir bölüm anahtarı stratejisi kullanmaya alternatif sağlar. Genel ikincil dizinler, farklı bölüm anahtarlarına sahip ek kapsayıcılardır ve kaynak kapsayıcınızdaki verilerle otomatik olarak eşitlenir.

Aşağıdaki durumlarda genel ikincil dizinleri göz önünde bulundurun:

• Tek bir bölüm anahtarı stratejisi tarafından karşılanamıyor birden çok sorgu deseni var
• Mevcut bölüm anahtarınızı değiştirmek kesintiye neden olabilir
• Analiz veya arama iş yüklerini işlem işlemlerinden yalıtmalısınız

Genel ikincil dizinler, belirli sorgu desenleri için iyileştirilmiş farklı bölüm anahtarlarıyla aynı verileri depolayarak bölümler arası sorguları önlemeye yardımcı olur. Bu yaklaşım, yalnızca bölüm anahtarı iyileştirmenin yeterli olmadığı senaryolarda RU tüketimini önemli ölçüde azaltabilir ve sorgu performansını iyileştirebilir.

Bölüm anahtarı olarak öğe kimliğini kullanma

Uyarı

Bu bölüm öncelikli olarak NoSQL IÇIN API için geçerlidir. Gremlin API'si gibi diğer API'ler, bölüm anahtarı olarak benzersiz tanımlayıcıyı desteklemez.

Kapsayıcınızın çok çeşitli olası değerlere sahip bir özelliği varsa, büyük olasılıkla harika bir bölüm anahtarı seçimidir. Bu tür bir özelliğe örnek olarak öğe kimliği yer alır. Herhangi bir boyuttaki küçük okuma ağırlıklı kapsayıcılar veya yoğun yazma içeren kapsayıcılar için öğe kimliği (/id) doğal olarak bölüm anahtarı için harika bir seçimdir.

Sistem özellik öğesi kimliği kapsayıcınızdaki her öğede bulunur. Öğenizin mantıksal kimliğini temsil eden başka özellikleriniz de olabilir. Çoğu durumda, bu benzersiz tanımlayıcılar da öğe kimliğiyle aynı nedenlerle harika bölüm anahtarı seçimleridir.

Öğe kimliği, aşağıdaki nedenlerle harika bir bölüm anahtarı seçimidir:

• Çok çeşitli olası değerler vardır (öğe başına bir benzersiz öğe kimliği ).
• Öğe başına benzersiz bir öğe kimliği olduğundan, öğe kimliği RU tüketimini ve veri depolama alanını eşit şekilde dengeleme konusunda harika bir iş yapar.
• Öğe kimliğini biliyorsanız bir öğenin bölüm anahtarını her zaman bildiğinizden, verimli nokta okumalarını kolayca yapabilirsiniz.

Bölüm anahtarı olarak öğe kimliğini seçerken aşağıdaki uyarıları göz önünde bulundurun:

• Öğe kimliği bölüm anahtarıysa, kapsayıcınızın tamamı için benzersiz bir tanımlayıcıya dönüşür. Yinelenen tanımlayıcılara sahip öğeler oluşturamazsınız.
• Birçok fiziksel bölüme sahip yoğun okuma içeren bir kapsayıcınız varsa, öğe kimliğine sahip bir eşitlik filtresine sahip olan sorgular daha verimlidir.
• Saklı yordamlar veya tetikleyiciler birden çok mantıksal bölümü hedefleyemez.

İlgili içerik

• Azure Cosmos DB'de sağlanan aktarım hızı
• Azure Cosmos DB'de genel dağıtım
• Eğitim: Azure Cosmos DB'de verilerinizi modelleme ve bölümleme