Azure Tablo depolama için ölçeklenebilir bir bölümleme stratejisi tasarlama
Bu makalede, bir tabloyu Azure Tablo depolama alanında bölümleme ve verimli ölçeklenebilirlik sağlamak için kullanabileceğiniz stratejiler ele alınmaktadır.
Azure, yüksek oranda kullanılabilir ve yüksek oranda ölçeklenebilir bulut depolama alanı sağlar. Azure için temel alınan depolama sistemi, Azure Blob depolama, Azure Tablo depolama, Azure Kuyruk depolama ve Azure Dosyalar gibi bir dizi hizmet aracılığıyla sağlanır.
Azure Tablo depolama, yapılandırılmış verileri depolamak için tasarlanmıştır. Azure Depolama hizmeti sınırsız sayıda tabloyu destekler. Her tablo büyük düzeylere ölçeklendirilebilir ve terabaytlarlık fiziksel depolama alanı sağlayabilir. Tablolardan en iyi şekilde yararlanmak için verilerinizi en iyi şekilde bölümlemeniz gerekir. Bu makalede, Azure Tablo depolama için verileri verimli bir şekilde bölümleme stratejilerini inceler.
Tablo varlıkları
Tablo varlıkları, bir tabloda depolanan veri birimlerini temsil eder. Tablo varlıkları tipik bir ilişkisel veritabanı tablosundaki satırlara benzer. Her varlık bir özellik koleksiyonu tanımlar. Her özellik adı, değeri ve değerin veri türüne göre bir anahtar/değer çifti olarak tanımlanır. Varlıklar, özellik koleksiyonunun bir parçası olarak aşağıdaki üç sistem özelliğini tanımlamalıdır:
PartitionKey: PartitionKey özelliği, bir varlığın ait olduğu bölümü tanımlayan dize değerlerini depolar. Daha sonra değindiğimiz gibi bölümler, tablonun ölçeklenebilirliğinin ayrılmaz bir parçasıdır. Aynı PartitionKey değerine sahip varlıklar aynı bölümde depolanır.
RowKey: RowKey özelliği, her bölümdeki varlıkları benzersiz olarak tanımlayan dize değerlerini depolar. PartitionKey ve RowKey birlikte varlığın birincil anahtarını oluşturur.
Zaman damgası: Zaman damgası özelliği bir varlık için izlenebilirlik sağlar. Zaman damgası, varlığın en son ne zaman değiştirildiğini belirten bir tarih/saat değeridir. Zaman damgası bazen varlığın sürümü olarak adlandırılır. Tablo hizmeti tüm ekleme ve güncelleştirme işlemleri sırasında bu özelliğin değerini koruduğundan zaman damgalarında yapılan değişiklikler yoksayılır.
Tablo birincil anahtarı
Azure varlığının birincil anahtarı, birleştirilmiş PartitionKey ve RowKey özelliklerinden oluşur. İki özellik, tablo içinde tek bir kümelenmiş dizin oluşturur. PartitionKey ve RowKey değerlerinin boyutu en çok 1024 karakter olabilir. Boş dizelere de izin verilir; ancak null değerlere izin verilmez.
Kümelenmiş dizin , PartitionKey'e göre artan düzende ve ardından RowKey'e göre artan düzende sıralar. Sıralama düzeni tüm sorgu yanıtlarında gözlemlenir. Sıralama işlemi sırasında sözcük temelli karşılaştırmalar kullanılır. "2" dize değerinden önce "111" dize değeri görüntülenir. Bazı durumlarda sıralama düzeninin sayısal olmasını isteyebilirsiniz. Sayısal ve artan düzende sıralamak için sabit uzunlukta, sıfır tuşlu dizeler kullanmanız gerekir. Yukarıdaki örnekte, "111" öncesinde "002" görünür.
Tablo bölümleri
Bölümler, aynı PartitionKey değerlerine sahip varlık koleksiyonunu temsil eder. Bölümler her zaman bir bölüm sunucusundan sunulur. Her bölüm sunucusu bir veya daha fazla bölüme hizmet verebilir. Bölüm sunucusu, zaman içinde bir bölümden hizmet verebileceği varlık sayısının hız sınırına sahiptir. Özellikle, bir bölümün saniyede 2000 varlıklık bir ölçeklenebilirlik hedefi vardır. Depolama düğümünde en düşük yük sırasında bu aktarım hızı daha yüksek olabilir, ancak düğüm sık veya etkin hale geldiğinde azaltılır.
Bölümleme kavramını daha iyi göstermek için aşağıdaki şekilde, ayak yarışı etkinliği kayıtları için küçük bir veri alt kümesi içeren bir tablo gösterilmektedir. Şekilde PartitionKey'in üç farklı değer içerdiği bölümlemenin kavramsal bir görünümü gösterilir: olayın adı üç uzaklık (tam maraton, yarı maraton ve 10 km) ile birleştirilir. Bu örnekte iki bölüm sunucusu kullanılır. Sunucu A, yarı maraton ve 10 km mesafeler için kayıtları içerir. Sunucu B yalnızca tam maraton mesafelerini içerir. RowKey değerleri bağlam sağlamak için gösterilir, ancak bu örnek için değerler anlamlı değildir.
Üç bölümü olan bir tablo
Ölçeklenebilirlik
Bir bölüm her zaman tek bir bölüm sunucusundan sunulduğundan ve her bölüm sunucusu bir veya daha fazla bölüme hizmet ettiğinden, varlıkları sunmanın verimliliği sunucunun durumuyla ilişkilendirilir. Bölümleri için yüksek trafikle karşılaşan sunucular yüksek aktarım hızını sürdüremeyebilir. Örneğin, yukarıdaki şekilde, "2011 New York City Marathon__Half" için birçok istek alınırsa, A sunucusu çok sıcak hale gelebilir. Sunucunun aktarım hızını artırmak için depolama sistemi bölümleri diğer sunuculara yükler. Sonuç olarak trafik diğer birçok sunucuya dağıtılır. Trafiğin en iyi yük dengelemesi için, Azure Tablo depolamanın bölümleri daha fazla bölüm sunucusuna dağıtabilmesi için daha fazla bölüm kullanmanız gerekir.
Varlık grubu işlemleri
Varlık grubu işlemi, aynı PartitionKey değerine sahip varlıklara atomik olarak uygulanan bir depolama işlemleri kümesidir. Varlık grubundaki herhangi bir depolama işlemi başarısız olursa, varlıktaki tüm depolama işlemleri geri alınır. Varlık grubu işlemi en fazla 100 depolama işleminden oluşur ve boyutu en fazla 4 MiB olabilir. Varlık grubu işlemleri, Azure Tablo depolamaya ilişkisel veritabanları tarafından sağlanan sınırlı bir bölünmezlik, tutarlılık, yalıtım ve dayanıklılık (ACID) semantiği sağlar.
Varlık grubu işlemleri, Azure Tablo depolamaya gönderilmesi gereken tek tek depolama işlemlerinin sayısını azalttığı için aktarım hızını artırır. Varlık grubu işlemleri de ekonomik bir avantaj sağlar. Varlık grubu işlemi, kaç depolama işlemi içerdiğinden bağımsız olarak tek bir depolama işlemi olarak faturalandırılır. Bir varlık grubu işlemindeki tüm depolama işlemleri aynı PartitionKey değerine sahip varlıkları etkilediğinden, varlık grubu işlemlerinin kullanılması gereksinimi PartitionKey değeri seçimini yönlendirebilir.
Aralık bölümleri
Varlıklarınız için benzersiz PartitionKey değerleri kullanırsanız, her varlık kendi bölümüne aittir. Kullandığınız benzersiz değerler değeri artırır veya azaltırsa, Azure aralık bölümleri oluşturabilir. Aralık bölümleri, aralık sorgularının performansını geliştirmek için sıralı, benzersiz PartitionKey değerlerine sahip varlıkları gruplandırıyor. Aralık bölümleri olmadan, aralık sorgusu bölüm sınırlarını veya sunucu sınırlarını aşmalıdır ve bu da sorgu performansını düşürebilir. PartitionKey için artan bir sıra değerine sahip olan aşağıdaki tabloyu kullanan bir uygulamayı düşünün:
| PartitionKey | RowKey |
|---|---|
| "0001" | - |
| "0002" | - |
| "0003" | - |
| "0004" | - |
| "0005" | - |
| "0006" | - |
Azure, ilk üç varlığı bir aralık bölümünde gruplandırabilir. Ölçüt olarak PartitionKey kullanan tabloya bir aralık sorgusu uygularsanız ve "0001" ile "0003" arasındaki varlıkları isterse, varlıklar tek bir bölüm sunucusundan sunulduğundan sorgu verimli bir şekilde çalışabilir. Aralık bölümünün ne zaman ve nasıl oluşturulacağı garanti edilemez.
Artan veya azalan PartitionKey değerlerine sahip varlıklar eklerseniz, tablonuz için aralık bölümlerinin varlığı ekleme işlemlerinizin performansını etkileyebilir. Artan PartitionKey değerlerine sahip varlıkların eklenmesine yalnızca ekleme deseni denir. Azalan değerlere sahip varlıkların eklenmesine yalnızca önceden eklenen desen adı verilir. Ekleme isteklerinizin genel aktarım hızı tek bir bölüm sunucusuyla sınırlı olduğundan bu tür desenleri kullanmamayı göz önünde bulundurun. Bunun nedeni, aralık bölümleri varsa, ilk ve son (aralık) bölümleri sırasıyla en az ve en büyük PartitionKey değerlerini içerir. Bu nedenle, sıralı olarak daha düşük veya daha yüksek PartitionKey değerine sahip olan yeni bir varlığın eklenmesi, son bölümlerden birini hedefler. Aşağıdaki şekilde, önceki örneği temel alan olası bir aralık bölümleri kümesi gösterilmektedir. Bir "0007", "0008" ve "0009" varlıkları kümesi eklenmişse, bunlar son (turuncu) bölüme atanır.
Aralık bölümleri kümesi
Ekleme işlemleri daha dağınık PartitionKey değerleri kullanıyorsa performans üzerinde olumsuz bir etki olmadığını unutmayın.
Verileri çözümleme
dizinleri yönetmek için kullanabileceğiniz ilişkisel veritabanındaki bir tablodan farklı olarak, Azure Tablo depolama alanındaki tabloların yalnızca bir dizini olabilir. Azure Tablo depolamadaki bir dizin her zaman PartitionKey ve RowKey özelliklerinden oluşur.
Azure tablosunda, daha fazla dizin ekleyerek veya mevcut bir tabloyu dağıtıldıktan sonra değiştirerek tablonuzda performans ayarlaması yapma lüksünüzün yoktur. Tablonuzu tasarlarken verileri analiz etmelisiniz. En iyi ölçeklenebilirlik ve sorgu ile ekleme verimliliği için dikkate alınması gereken en önemli yönler PartitionKey ve RowKey değerleridir. Bu makalede, tabloların nasıl bölümlendiğiyle doğrudan ilişkili olduğundan PartitionKey'in nasıl seçileceği vurgulanır.
Bölüm boyutlandırma
Bölüm boyutlandırma, bir bölümün içerdiği varlık sayısını ifade eder. Ölçeklenebilirlik bölümünde ele aldığımız gibi, daha fazla bölüme sahip olmak daha iyi yük dengeleme elde ettiğiniz anlamına gelir. PartitionKey değerinin ayrıntı düzeyi, bölümlerin boyutunu etkiler. En kaba düzeyde, PartitionKey olarak tek bir değer kullanılırsa, tüm varlıklar çok büyük olan tek bir bölümde yer alır. En ince ayrıntı düzeyinde PartitionKey , her varlık için benzersiz değerler içerebilir. Sonuç olarak her varlık için bir bölüm vardır. Aşağıdaki tabloda ayrıntı düzeyi aralığının avantajları ve dezavantajları gösterilmektedir:
| PartitionKey ayrıntı düzeyi | Bölüm boyutu | Avantajlar | Dezavantajlar |
|---|---|---|---|
| Tek değer | Az sayıda varlık | Batch işlemleri herhangi bir varlıkla mümkündür. Tüm varlıklar yereldir ve aynı depolama düğümünden sunulur. |
|
| Tek değer | Çok sayıda varlık | Varlık grubu işlemleri herhangi bir varlıkla mümkün olabilir. Varlık grubu işlemlerinin sınırları hakkında daha fazla bilgi için bkz. Varlık grubu işlemlerini gerçekleştirme. | Ölçeklendirme sınırlıdır. Aktarım hızı tek bir sunucunun performansıyla sınırlıdır. |
| Birden çok değer | Birden çok bölüm Bölüm boyutları varlık dağıtımına bağlıdır. |
Batch işlemleri bazı varlıklarda mümkündür. Dinamik bölümleme mümkündür. Tek istekli sorgular mümkündür (devamlılık belirteci yoktur). Daha fazla bölüm sunucusu arasında yük dengeleme mümkündür. |
Varlıkların bölümler arasında son derece eşit olmayan bir dağıtımı, daha büyük ve daha etkin bölümlerin performansını sınırlayabilir. |
| Benzersiz değerler | Birçok küçük bölüm | Tablo yüksek oranda ölçeklenebilir. Aralık bölümleri bölümler arası aralık sorgularının performansını iyileştirebilir. |
Aralıkları içeren sorgular için birden fazla sunucuya ziyaret yapılması gerekebilir. Batch işlemleri mümkün değildir. Yalnızca ekleme veya yalnızca başına ekleme desenleri, ekleme aktarım hızını etkileyebilir. |
Tabloda ölçeklendirmenin PartitionKey değerlerinden nasıl etkilendiği gösterilmektedir. Daha iyi yük dengeleme sunduğundan daha küçük bölümleri desteklemek en iyi yöntemdir. Daha büyük bölümler bazı senaryolarda uygun olabilir ve dezavantajları olmayabilir. Örneğin, uygulamanız ölçeklenebilirlik gerektirmiyorsa tek bir büyük bölüm uygun olabilir.
Sorguları belirleme
Sorgular tablolardan veri alır. Azure Tablo depolamadaki bir tablonun verilerini analiz ettiğinizde, uygulamanın hangi sorguları kullanacağını göz önünde bulundurmanız önemlidir. Bir uygulamada çeşitli sorgular varsa, kararlarınız öznel olsa da bunların önceliğini belirlemeniz gerekebilir. Çoğu durumda, baskın sorgular diğer sorgulardan ayırt edilebilir. Performans açısından sorgular farklı kategorilere ayrılır. Bir tabloda yalnızca bir dizin olduğundan sorgu performansı genellikle PartitionKey ve RowKey özellikleriyle ilgilidir. Aşağıdaki tabloda farklı sorgu türleri ve performans derecelendirmeleri gösterilmektedir:
| Sorgu türü | PartitionKey eşleşmesi | RowKey eşleşmesi | Performans derecelendirmesi |
|---|---|---|---|
| Satır aralığı taraması | Exact | Kısmi | Daha küçük boyutlu bölümler ile daha iyi. Çok büyük bölümler ile kötü. |
| Bölüm aralığı taraması | Kısmi | Kısmi | Çok az sayıda bölüm sunucusuna dokunulması iyi. Daha fazla sunucuya dokunulduğunda daha kötü. |
| Tam tablo taraması | Kısmi, yok | Kısmi, yok | Bölümlerin bir alt kümesinin taranmasıyla daha da kötü. En kötüsü, tüm bölümlerin taranmasıdır. |
Not
Tablo, performans derecelendirmelerini birbirine göre tanımlar. Bölümlerin sayısı ve boyutu sonuçta sorgunun nasıl performans göstereceğini belirleyebilir. Örneğin, çok sayıda büyük bölümü olan bir tablo için bölüm aralığı taraması, birkaç küçük bölümü olan bir tablo için tam tablo taramasına kıyasla düşük performans gösterebilir.
Önceki tabloda listelenen sorgu türleri, performans derecelendirmelerine göre kullanılacak en iyi sorgu türlerinden en kötü türlere kadar bir ilerleme gösterir. Nokta sorguları, tablonun kümelenmiş dizinini tam olarak kullandığından, kullanılacak en iyi sorgu türleridir. Aşağıdaki nokta sorgusu, foot races kayıt tablosundaki verileri kullanır:
http://<account>.windows.core.net/registrations(PartitionKey=”2011 New York City Marathon__Full”,RowKey=”1234__John__M__55”)
Uygulama birden çok sorgu kullanıyorsa, bunların tümü nokta sorguları olamaz. Performans açısından, aralık sorguları nokta sorgularını izler. İki tür aralık sorgusu vardır: satır aralığı taraması ve bölüm aralığı taraması. Satır aralığı taraması tek bir bölüm belirtir. İşlem tek bir bölüm sunucusunda gerçekleştiğinden, satır aralığı taramaları genellikle bölüm aralığı taramalarından daha verimlidir. Ancak, satır aralığı taramalarının performansında önemli bir faktör, sorgunun ne kadar seçici olduğudur. Sorgu seçiciliği, eşleşen satırları bulmak için kaç satır yineleneceklerini belirler. Satır aralığı taramaları sırasında daha seçmeli sorgular daha verimlidir.
Sorgularınızın önceliklerini değerlendirmek için her sorgunun sıklık ve yanıt süresi gereksinimlerini göz önünde bulundurun. Sık yürütülen sorgulara öncelik daha yüksek olabilir. Ancak, önemli ancak nadiren kullanılan bir sorgunun düşük gecikme süresi gereksinimleri olabilir ve bu da sorguyu öncelik listesinde daha yüksek derecelendirebilir.
PartitionKey değerini seçin
Herhangi bir tablonun tasarımının temeli ölçeklenebilirliği, buna erişmek için kullanılan sorgular ve depolama işlemi gereksinimleridir. Seçtiğiniz PartitionKey değerleri, tablonun nasıl bölümlendiğini ve kullanabileceğiniz sorguların türünü belirler. Depolama işlemleri ve özellikle eklemeler, seçtiğiniz PartitionKey değerlerini de etkileyebilir. PartitionKey değerleri tek değerlerden benzersiz değerlere kadar değişebilir. Bunlar birden çok değer kullanılarak da oluşturulabilir. PartitionKey değerini oluşturmak için varlık özelliklerini kullanabilirsiniz. Veya uygulama değeri hesaplayabilir. Aşağıdaki bölümlerde dikkat edilmesi gereken önemli noktalar açıklanmıştır.
Varlık grubu işlemleri
Geliştiriciler önce uygulamanın varlık grubu işlemlerini (toplu güncelleştirmeler) kullanıp kullanmayacağını düşünmelidir. Varlık grubu işlemleri, varlıkların aynı PartitionKey değerine sahip olmasını gerektirir. Ayrıca toplu güncelleştirmeler grubun tamamına yönelik olduğundan PartitionKey değerlerinin seçenekleri sınırlı olabilir. Örneğin, nakit işlemlerini sürdüren bir bankacılık uygulamasının tabloya atomik olarak nakit hareketleri eklemesi gerekir. Nakit hareketleri hem borç hem de alacak taraflarını temsil eder ve net olarak sıfıra inmelidir. Bu gereksinim, işlemin her tarafı farklı hesap numaraları kullandığından hesap numarasının PartitionKey değerinin herhangi bir parçası olarak kullanılamayacağı anlamına gelir. Bunun yerine, işlem kimliği daha iyi bir seçenek olabilir.
Bölümler
Bölüm numaraları ve boyutları, yük altında olan bir tablonun ölçeklenebilirliğini etkiler. Ayrıca PartitionKey değerlerinin ne kadar ayrıntılı olduğu da denetlenir. Özellikle değerlerin dağılımını tahmin etmek zorsa bölüm boyutuna göre PartitionKey'i belirlemek zor olabilir. Birden çok, daha küçük bölüm kullanmak iyi bir kuraldır. Birçok tablo bölümü, Azure Tablo depolamanın bölümlerin sunulduğu depolama düğümlerini yönetmesini kolaylaştırır.
PartitionKey için benzersiz veya daha ince değerlerin seçilmesi daha küçük ama daha fazla bölüme neden olur. Bu genellikle uygundur çünkü sistem yükü birçok bölüme dağıtmak için birçok bölümün yükünü dengeleyebilir. Ancak, bölümler arası sorgular üzerinde birçok bölüme sahip olmanın etkisini göz önünde bulundurmalısınız. Bu sorgu türlerinin sorguyu karşılamak için birden çok bölümü ziyaret etmesi gerekir. Bölümlerin birçok bölüm sunucusuna dağıtılmış olması mümkündür. Bir sorgu bir sunucu sınırını geçerse, devamlılık belirteçleri döndürülmelidir. Devamlılık belirteçleri, sorgunun sonraki veri kümesini almak için sonraki PartitionKey veya RowKey değerlerini belirtir. Başka bir deyişle, devamlılık belirteçleri hizmete yönelik en az bir isteği daha temsil eder ve bu da sorgunun genel performansını düşürebilir.
Sorgu seçiciliği, sorgunun performansını etkileyebilecek bir diğer faktördür. Sorgu seçiciliği, her bölüm için kaç satırın yinelenmiş olması gerektiğini gösteren bir ölçüdür. Bir sorgu ne kadar seçici olursa, sorgu istediğiniz satırları döndürmede o kadar verimli olur. Aralık sorgularının genel performansı, dokunulması gereken bölüm sunucularının sayısına veya sorgunun ne kadar seçmeli olduğuna bağlı olabilir. Tablonuza veri eklerken yalnızca ekleme veya yalnızca ekleme desenlerini kullanmaktan da kaçınmanız gerekir. Bu desenleri kullanıyorsanız, küçük ve çok sayıda bölüm oluşturmanıza rağmen, ekleme işlemlerinizin aktarım hızını sınırlayabilirsiniz. Yalnızca ekleme ve yalnızca başına ekleme desenleri Aralık bölümlerinde ele alınıyor.
Sorgular
Kullanacağınız sorguları bilmek , PartitionKey değeri için dikkate alınması gereken özellikleri belirlemenize yardımcı olabilir. Sorgularda kullandığınız özellikler PartitionKey değeri için adaylardır. Aşağıdaki tabloda PartitionKey değerinin nasıl belirleneceğiyle ilgili genel bir yönerge sağlanmaktadır:
| Varlık... | Eylem |
|---|---|
| Bir anahtar özelliği vardır | PartitionKey olarak kullanın. |
| İki anahtar özelliği vardır | Birini PartitionKey , diğerini RowKey olarak kullanın. |
| İkiden fazla anahtar özelliği vardır | Birleştirilmiş değerlerin bileşik anahtarını kullanın. |
Birden fazla eşit baskın sorgu varsa, ihtiyacınız olan farklı RowKey değerlerini kullanarak bilgileri birden çok kez ekleyebilirsiniz. Uygulamanız ikincil (veya üçüncül vb.) satırları yönetir. Sorgularınızın performans gereksinimlerini karşılamak için bu tür bir desen kullanabilirsiniz. Aşağıdaki örnek, ayak yarışı kayıt örneğindeki verileri kullanır. İki baskın sorgusu vardır:
- Kaynak numarasına göre sorgulama
- Yaşa göre sorgulama
Her iki baskın sorguya da hizmet vermek için varlık grubu işlemi olarak iki satır ekleyin. Aşağıdaki tabloda bu senaryo için PartitionKey ve RowKey özellikleri gösterilmektedir. RowKey değerleri, uygulamanın iki değeri ayırt edebilmesi için kaynak ve yaş için bir ön ek sağlar.
| PartitionKey | RowKey |
|---|---|
| 2011 New York City Marathon__Full | BIB:01234__John__M__55 |
| 2011 New York City Marathon__Full | AGE:055__1234__John__M |
Bu örnekte, PartitionKey değerleri aynı olduğundan varlık grubu işlemi mümkündür. Grup işlemi ekleme işleminin bölünmezliğini sağlar. Bu düzeni farklı PartitionKey değerleriyle kullanmak mümkün olsa da, bu avantajdan yararlanmak için aynı değerleri kullanmanızı öneririz. Aksi takdirde, farklı PartitionKey değerleri kullanan atomik işlemleri sağlamak için ek mantık yazmanız gerekebilir.
Depolama işlemleri
Azure Tablo depolamadaki tablolar yalnızca sorgulardan gelen yüklemelerle karşılaşabilir. Ayrıca eklemeler, güncelleştirmeler ve silmeler gibi depolama işlemlerinden gelen yükle de karşılaşabilir. Tabloda ne tür depolama işlemleri gerçekleştirebileceğinizi ve ne hızda gerçekleştirebileceğinizi düşünün. Bu işlemleri seyrek gerçekleştiriyorsanız, bunlar hakkında endişelenmeniz gerekmeyebilir. Ancak, kısa sürede çok sayıda ekleme gerçekleştirme gibi sık gerçekleştirdiği işlemler için, bu işlemlerin seçtiğiniz PartitionKey değerlerinin bir sonucu olarak nasıl sunulduğuna dikkat etmeniz gerekir. Önemli örnekler yalnızca ekleme ve yalnızca önceden eklenen desenlerdir. Yalnızca ekleme ve yalnızca başına ekleme desenleri Aralık bölümlerinde ele alınıyor.
Yalnızca ekleme veya yalnızca başına ekleme deseni kullandığınızda, sonraki eklemelerde PartitionKey için benzersiz artan veya azalan değerler kullanırsınız. Bu düzeni sık ekleme işlemleriyle birleştirirseniz, tablonuz ekleme işlemlerine mükemmel ölçeklenebilirlikle hizmet vermez. Azure diğer bölüm sunucularına yönelik işlem isteklerinin yükünü dengeleyemediğinden tablonuzun ölçeklenebilirliği etkilenir. Bu durumda, GUID değerleri gibi rastgele değerleri kullanmayı düşünebilirsiniz. Ardından bölüm boyutlarınız küçük kalabilir ve depolama işlemleri sırasında yük dengelemeyi sürdürebilir.
Tablo bölümü stres testi
PartitionKey değeri karmaşık olduğunda veya diğer PartitionKey eşlemeleriyle karşılaştırma gerektirdiğinde, tablonun performansını test etmeniz gerekebilir. Test, bir bölümün en yüksek yükler altında ne kadar iyi performans sergileyeni incelemelidir.
Stres testi yapmak için
- Bir test tablosu İçerik Oluşturucu.
- Test tablosunu, hedeflediğiniz PartitionKey değerine sahip varlıkları içermesi için verilerle yükleyin.
- Tabloya en yoğun yükün benzetimini yapmak için uygulamayı kullanın. 2. adımdaki PartitionKey değerini kullanarak tek bir bölümü hedefleyin. Bu adım her uygulama için farklıdır, ancak simülasyon tüm gerekli sorguları ve depolama işlemlerini içermelidir. Uygulamayı tek bir bölümü hedefleyebilecek şekilde ayarlamanız gerekebilir.
- Tablodaki GET veya PUT işlemlerinin aktarım hızını inceleyin.
Aktarım hızını incelemek için gerçek değerleri tek bir sunucudaki tek bir bölümün belirtilen sınırıyla karşılaştırın. Bölümler saniyede 2000 varlıkla sınırlıdır. Aktarım hızı bir bölüm için saniyede 2000 varlığı aşarsa, sunucu üretim ayarında çok sık çalışabilir. Bu durumda PartitionKey değerleri çok kaba olabilir, böylece yeterli bölüm olmaması veya bölümlerin çok büyük olması gerekir. Bölümlerin daha fazla sunucu arasında dağıtılması için PartitionKey değerini değiştirmeniz gerekebilir.
Yük dengeleme
Bölüm katmanında yük dengeleme, bir bölüm çok sık olduğunda gerçekleşir. Bir bölüm çok sık olduğunda, bölüm, özellikle bölüm sunucusu hedef ölçeklenebilirliğinin ötesinde çalışır. Azure depolama için her bölümün saniyede 2000 varlıklık bir ölçeklenebilirlik hedefi vardır. Yük dengeleme, Dağıtılmış Dosya Sistemi (DFS) katmanında da gerçekleşir.
DFS katmanındaki yük dengeleme, G/Ç yüküyle ilgilidir ve bu makalenin kapsamı dışındadır. Bölüm katmanında yük dengeleme, ölçeklenebilirlik hedefi aşıldıktan hemen sonra gerçekleşmez. Bunun yerine, sistem yük dengeleme işlemine başlamadan önce birkaç dakika bekler. Bu, bir bölümün gerçekten sıcak hale gelmesini sağlar. Sistem görevi otomatik olarak gerçekleştirdiğinden yük dengelemeyi tetikleyen oluşturulan yüke sahip bölümlerin astarlanması gerekmez.
Bir tablo belirli bir yüke sahipse, sistem bölümleri gerçek yüke göre dengeleyebiliyor olabilir ve bu da bölümlerin önemli ölçüde farklı bir dağılımına neden olabilir. Bölümleri hazırlama yerine zaman aşımı ve Sunucu Meşgul hatalarını işleyen kod yazmayı göz önünde bulundurun. Sistem yük dengeleme yaparken hatalar döndürülür. Yeniden deneme stratejisi kullanarak bu hataları işleyerek uygulamanız en yüksek yükleri daha iyi işleyebilir. Yeniden deneme stratejileri aşağıdaki bölümde daha ayrıntılı olarak ele alınıyor.
Yük dengeleme gerçekleştiğinde, bölüm birkaç saniye çevrimdışı duruma gelir. Çevrimdışı süre boyunca sistem, bölümü farklı bir bölüm sunucusuna yeniden atayın. Verilerinizin bölüm sunucuları tarafından depolanmadığını unutmayın. Bunun yerine, bölüm sunucuları DFS katmanından varlıklara hizmet eder. Verileriniz bölüm katmanında depolanmadığından, bölümleri farklı sunuculara taşımak hızlı bir işlemdir. Bu esneklik, varsa uygulamanızın karşılaşabileceği kapalı kalma süresini büyük ölçüde sınırlar.
Yeniden deneme stratejisi
Veri güncelleştirmelerini kaybetmediğinizden emin olmak için uygulamanızın depolama işlemi hatalarını işlemesi önemlidir. Bazı hatalar için yeniden deneme stratejisi gerekmez. Örneğin, 401 Yetkisiz hatası döndüren güncelleştirmeler, uygulama durumunun 401 hatasını çözen yeniden denemeler arasında değişmeme olasılığı olduğundan işlemi yeniden deneme avantajından yararlanamaz. Ancak Sunucu Meşgul veya Zaman Aşımı gibi hatalar, Azure'ın tablo ölçeklenebilirliği sağlayan yük dengeleme özellikleriyle ilgilidir. Varlıklarınıza hizmet veren depolama düğümleri sık olduğunda Azure, bölümleri diğer düğümlere taşıyarak yükü dengeler. Bu süre boyunca bölüme erişilemez olabilir ve bu da Sunucu Meşgul veya Zaman Aşımı hatalarıyla sonuçlanabilir. Sonunda bölüm yeniden kullanılabilir hale gelir ve güncelleştirmeler devam eder.
Yeniden deneme stratejisi Sunucu Meşgul veya Zaman Aşımı hataları için uygundur. Çoğu durumda, 400 düzeyindeki hataları ve 500 düzeyindeki hataları yeniden deneme mantığının dışında tutabilirsiniz. Dışlanabilir hatalar arasında 501 Uygulanmadı ve 505 HTTP Sürümü Desteklenmiyor sayılabilir. Ardından, Sunucu Meşgul (503) ve Zaman Aşımı (504) gibi 500 düzeyine kadar hata için yeniden deneme stratejisi uygulayabilirsiniz.
Uygulamanız için üç yaygın yeniden deneme stratejisi arasından seçim yapabilirsiniz:
- Yeniden Deneme Yok: Yeniden deneme girişimi yapılmaz.
- Geri Alma düzeltildi: İşlem, sabit geri alma değeriyle N kez yeniden denendi.
- Üstel Geri Alma: İşlem, üstel geri alma değeriyle N kez yeniden denendi.
Yeniden Deneme Yok stratejisi, işlem hatalarını işlemenin basit (ve kaçamak) bir yoludur. Ancak Yeniden Deneme Yok stratejisi çok yararlı değildir. Herhangi bir yeniden deneme girişimi uygulamama, başarısız işlemlerden sonra verilerin doğru depolanmamasıyla ilgili belirgin riskler oluşturur. Sabit Geri Alma stratejisini kullanmak daha iyi bir stratejidir. bu, işlemleri aynı geri alma süresiyle yeniden deneme olanağı sağlar.
Ancak strateji, yüksek oranda ölçeklenebilir tabloları işlemek için iyileştirilmemiştir. Birçok iş parçacığı veya işlem aynı süre için bekliyorsa, çakışmalar oluşabilir. Önerilen yeniden deneme stratejisi, her yeniden deneme denemesinin son denemeden daha uzun olduğu üstel geri alma kullanan stratejidir. Ethernet gibi bilgisayar ağlarında kullanılan çarpışma önleme algoritmasına benzer. Üstel geri alma, sonuçta elde edilen araya ek bir varyans sağlamak için rastgele bir faktör kullanır. Geri alma değeri daha sonra minimum ve maksimum sınırlara kısıtlanır. Üstel algoritma kullanarak sonraki geri alma değerini hesaplamak için aşağıdaki formül kullanılabilir:
y = Rand(0,8z, 1,2z)(2x-1
y = Min(zmin + y, zmax
Konum:
z = milisaniye cinsinden varsayılan geri alma
zmin = milisaniye cinsinden varsayılan minimum geri alma
zmax = milisaniye cinsinden varsayılan maksimum geri alma
x = yeniden deneme sayısı
y = milisaniye cinsinden geri alma değeri
Rand (rastgele) işlevinde kullanılan 0,8 ve 1,2 çarpanları, özgün değerin %±20'si içinde varsayılan geri çekilmenin rastgele bir varyansını üretir. %±20 aralığı çoğu yeniden deneme stratejisi için kabul edilebilir ve daha fazla çakışmayı önler. Formül aşağıdaki kod kullanılarak uygulanabilir:
int retries = 1;
// Initialize variables with default values
var defaultBackoff = TimeSpan.FromSeconds(30);
var backoffMin = TimeSpan.FromSeconds(3);
var backoffMax = TimeSpan.FromSeconds(90);
var random = new Random();
double backoff = random.Next(
(int)(0.8D * defaultBackoff.TotalMilliseconds),
(int)(1.2D * defaultBackoff.TotalMilliseconds));
backoff *= (Math.Pow(2, retries) - 1);
backoff = Math.Min(
backoffMin.TotalMilliseconds + backoff,
backoffMax.TotalMilliseconds);
Özet
Tablo depolama birçok depolama düğümünde bölümleri yönettiği ve yeniden atadığı için Azure Tablo depolamadaki bir uygulama çok büyük miktarda veri depolayabilir. Tablonun ölçeklenebilirliğini denetlemek için veri bölümleme özelliğini kullanabilirsiniz. Verimli bölümleme stratejileri uyguladığınızdan emin olmak için bir tablo şeması tanımlarken önceden plan yapın. Özellikle PartitionKey değerlerini seçmeden önce uygulamanın gereksinimlerini, verilerini ve sorgularını analiz edin. Sistem trafiğe yanıt verdikçe her bölüm farklı depolama düğümlerine yeniden atanabilir. Tablonun doğru PartitionKey değerlerine sahip olduğundan emin olmak için bölüm stres testi kullanın. Bu test, bölümlerin ne zaman çok sıcak olduğunu belirlemenize yardımcı olur ve gerekli bölüm ayarlamalarını yapmanıza yardımcı olur.
Uygulamanızın aralıklı hataları işlemesini ve verilerinizin kalıcı olmasını sağlamak için geri alma ile bir yeniden deneme stratejisi kullanın. Azure Depolama İstemci Kitaplığı'nın kullandığı varsayılan yeniden deneme ilkesi, çakışmaları önleyen ve uygulamanızın aktarım hızını en üst düzeye çıkaran üstel bir geri çekilmeye sahiptir.