Ölçeklenebilir ve performansa yönelik tablolar tasarlama
İpucu
Bu makaledeki içerikler, özgün Azure Tablo depolama için geçerlidir. Ancak aynı kavramlar daha yüksek performans ve kullanılabilirlik, genel dağıtım ve otomatik ikincil dizinler sunan yeni Tablo için Azure Cosmos DB için de geçerlidir. Tüketim tabanlı sunucusuz modda da kullanılabilir. Azure Cosmos DB'deki Tablo API'si ile Azure Tablo depolama arasında bazı özellik farklılıkları vardır. Daha fazla bilgi için bkz . Tablo için Azure Cosmos DB. Geliştirme kolaylığı için şimdi hem Azure Tablo depolamayı hem de Tablo için Azure Cosmos DB'yi hedeflemek için kullanılabilecek birleşik bir Azure Tabloları SDK'sı sunuyoruz.
Ölçeklenebilir ve performanslı tablolar tasarlamak için performans, ölçeklenebilirlik ve maliyet gibi faktörleri göz önünde bulundurmanız gerekir. daha önce ilişkisel veritabanları için şemalar tasarladıysanız, bu önemli noktalar tanıdıktır, ancak Azure Tablo hizmeti depolama modeli ile ilişkisel modeller arasında bazı benzerlikler olsa da, önemli farklılıklar da vardır. Bu farklılıklar genellikle ilişkisel veritabanları hakkında bilgi sahibi olan kişiler için sezgisel olmayan veya yanlış görünen farklı tasarımlara yol açar, ancak Azure Tablo hizmeti gibi bir NoSQL anahtar/değer deposu tasarlarsanız mantıklı olur. Tasarım farklılıklarınızın birçoğu, Tablo hizmetinin milyarlarca varlık (veya ilişkisel veritabanı terminolojisindeki satırlar) içerebilen bulut ölçeğindeki uygulamaları veya yüksek işlem hacimlerini desteklemesi gereken veri kümelerini destekleyecek şekilde tasarlandığını yansıtır. Bu nedenle, verilerinizi nasıl depoladığınız hakkında farklı düşünmeniz ve Tablo hizmetinin nasıl çalıştığını anlamanız gerekir. İyi tasarlanmış bir NoSQL veri deposu, çözümünüzün ilişkisel veritabanı kullanan bir çözümden çok daha fazla ve daha düşük maliyetle ölçeklendirilmesini sağlayabilir. Bu kılavuz, bu konularda size yardımcı olur.
Azure Tablo hizmeti hakkında
Bu bölümde, Tablo hizmetinin özellikle performans ve ölçeklenebilirlik tasarımıyla ilgili bazı temel özellikleri vurgulanır. Azure Depolama ve Tablo hizmetini kullanmaya yeni başladıysanız, bu makalenin geri kalanını okumadan önce .NET kullanarak Azure Tablo Depolama'yı kullanmaya başlama makalesini okuyun. Bu kılavuzun odak noktası Tablo hizmeti olsa da, Azure Kuyruğu ve Blob hizmetlerini ve bunları Tablo hizmetiyle nasıl kullanabileceğinizi tartışmayı içerir.
Tablo hizmeti nedir? Adından bekleyebileceğiniz gibi, Tablo hizmeti verileri depolamak için tablosal bir biçim kullanır. Standart terminolojide, tablonun her satırı bir varlığı temsil eder ve sütunlar bu varlığın çeşitli özelliklerini depolar. Her varlığın benzersiz olarak tanımlamak için bir çift anahtarı ve Tablo hizmetinin varlığın en son ne zaman güncelleştirildiğini izlemek için kullandığı bir zaman damgası sütunu vardır. Zaman damgası otomatik olarak uygulanır ve zaman damgasının üzerine rastgele bir değerle el ile yazamazsınız. Tablo hizmeti, iyimser eşzamanlılığı yönetmek için bu son değiştirilen zaman damgasını (LMT) kullanır.
Not
Tablo hizmeti REST API işlemleri de LMT'den türetilen bir ETag değeri döndürür. Bu belgede ETag ve LMT terimleri birbirinin yerine kullanılır çünkü bunlar aynı temel alınan verilere başvurur.
Aşağıdaki örnekte, çalışan ve departman varlıklarını depolamak için basit bir tablo tasarımı gösterilmektedir. Bu kılavuzun devamında gösterilen örneklerin çoğu bu basit tasarımı temel alır.
| PartitionKey | RowKey | Zaman damgası | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Pazarlama | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Pazarlama | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Pazarlama | Bölüm | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Şimdiye kadar bu veriler, temel farklılıklar zorunlu sütunlar ve birden çok varlık türünü aynı tabloda depolama özelliğiyle ilişkisel veritabanındaki bir tabloya benzer. Ayrıca, FirstName veya Age gibi kullanıcı tanımlı özelliklerin her biri, ilişkisel veritabanındaki bir sütun gibi tamsayı veya dize gibi bir veri türüne sahiptir. İlişkisel veritabanından farklı olarak Tablo hizmetinin şemasız yapısı, bir özelliğin her varlıkta aynı veri türüne sahip olmaması gerektiği anlamına gelir. Karmaşık veri türlerini tek bir özellikte depolamak için JSON veya XML gibi serileştirilmiş bir biçim kullanmanız gerekir. Desteklenen veri türleri, desteklenen tarih aralıkları, adlandırma kuralları ve boyut kısıtlamaları gibi tablo hizmeti hakkında daha fazla bilgi için bkz . Tablo Hizmeti Veri Modelini Anlama.
PartitionKey ve RowKey seçiminiz, iyi bir tablo tasarımı için temeldir. Bir tabloda depolanan her varlığın benzersiz bir PartitionKey ve RowKey bileşimi olmalıdır. İlişkisel veritabanı tablosundaki anahtarlarda olduğu gibi PartitionKey ve RowKey değerleri de dizine eklenip hızlı aramalar için kümelenmiş dizin oluşturulur. Ancak Tablo hizmeti ikincil dizin oluşturmaz, bu nedenle yalnızca PartitionKey ve RowKey dizine alınan özelliklerdir. Tablo tasarım desenleri bölümünde açıklanan desenlerden bazıları, bu belirgin sınırlamaya nasıl çözüm getirebileceğinizi göstermektedir.
Bir tablo bir veya daha fazla bölümden oluşur ve yaptığınız tasarım kararlarının çoğu, çözümünüzü iyileştirmek için uygun bir PartitionKey ve RowKey seçmekle ilgili olacaktır. Çözüm, bölümler halinde düzenlenmiş tüm varlıklarınızı içeren tek bir tablodan oluşabilir, ancak genellikle bir çözümün birden çok tablosu vardır. Tablolar varlıklarınızı mantıksal olarak düzenlemenize, erişim denetimi listelerini kullanarak verilere erişimi yönetmenize yardımcı olur ve tek bir depolama işlemi kullanarak tablonun tamamını bırakabilirsiniz.
Tablo bölümleri
Hesap adı, tablo adı ve PartitionKey birlikte, tablo hizmetinin varlığı depoladığı depolama hizmeti içindeki bölümü tanımlar. Bölümler, varlıklar için adresleme düzeninin bir parçası olmanın yanı sıra işlemler için bir kapsam tanımlar (aşağıdaki Varlık Grubu İşlemleri bölümüne bakın) ve tablo hizmetinin ölçeklendirilme şeklinin temelini oluşturur. Bölümler hakkında daha fazla bilgi için bkz . Tablo depolama için Performans ve ölçeklenebilirlik denetim listesi.
Tablo hizmetinde, tek bir düğüm bir veya daha fazla tam bölüm sunar ve hizmet, düğümler arasında bölümleri dinamik olarak yük dengeleme yoluyla ölçeklendirir. Bir düğüm yük altındaysa, tablo hizmeti söz konusu düğüm tarafından hizmet edilen bölüm aralığını farklı düğümlere bölebilir; trafik kesildiğinde, hizmet sessiz düğümlerden bölüm aralıklarını tek bir düğüme geri birleştirebilir.
Tablo hizmetinin iç ayrıntıları ve özellikle de hizmetin bölümleri nasıl yönettiği hakkında daha fazla bilgi için bkz. Microsoft Azure Depolama: Güçlü Tutarlılık ile Yüksek Oranda Kullanılabilir Bulut Depolama Hizmeti.
Varlık Grubu İşlemleri
Tablo hizmetinde Varlık Grubu İşlemleri (EGT) birden çok varlık arasında atomik güncelleştirmeler gerçekleştirmek için tek yerleşik mekanizmadır. EGT'ler bazen toplu işlemler olarak da adlandırılır. EGT'ler yalnızca aynı bölümde depolanan varlıklar üzerinde çalışabilir (yani, belirli bir tabloda aynı bölüm anahtarını paylaşır). Bu nedenle, birden çok varlık arasında atomik işlem davranışına ihtiyaç duyarsanız, bu varlıkların aynı bölümde olduğundan emin olmanız gerekir. Bu genellikle birden çok varlık türünü aynı tabloda (ve bölümde) tutmanın ve farklı varlık türleri için birden çok tablo kullanmamanın bir nedenidir. Tek bir EGT en fazla 100 varlık üzerinde çalışabilir. İşleme için birden çok eşzamanlı EGT gönderirseniz, bu EGT'lerin EGT'ler arasında ortak olan varlıklar üzerinde çalışmadığından emin olmak önemlidir; aksi takdirde işleme gecikebilir.
EGT'ler ayrıca tasarımınızda değerlendirmeniz için olası bir dengeyi de ortaya çıkarır. Başka bir ifadeyle, Azure'ın düğümler arasında yük dengeleme istekleri için daha fazla fırsatı olduğundan, daha fazla bölüm kullanmak uygulamanızın ölçeklenebilirliğini artırır. Ancak daha fazla bölüm kullanmak, uygulamanızın atomik işlemler gerçekleştirme ve verileriniz için güçlü tutarlılık sağlama becerisini sınırlayabilir. Ayrıca, bölüm düzeyinde tek bir düğüm için bekleyebileceğiniz işlemlerin aktarım hızını sınırlayan belirli ölçeklenebilirlik hedefleri vardır. Azure standart depolama hesapları için ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz . Standart depolama hesapları için ölçeklenebilirlik hedefleri. Tablo hizmeti için ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz . Tablo depolama için ölçeklenebilirlik ve performans hedefleri.
Kapasiteye ilişkin önemli noktalar
Aşağıdaki tabloda Tablo depolaması için kapasite, ölçeklenebilirlik ve performans hedefleri açıklanmaktadır.
| Kaynak | Hedef |
|---|---|
| Bir Azure depolama hesabındaki tablo sayısı | Yalnızca depolama hesabının kapasitesine göre sınırlandırılır |
| Tablodaki bölüm sayısı | Yalnızca depolama hesabının kapasitesine göre sınırlandırılır |
| Bölümdeki varlık sayısı | Yalnızca depolama hesabının kapasitesine göre sınırlandırılır |
| Tek tablo için maksimum boyut | 500 TiB |
| Tüm özellik değerleri dahil olmak üzere tek bir varlığın en büyük boyutu | 1 MiB |
| Bir tablo varlığındaki en fazla özellik sayısı | 255 (PartitionKey, RowKey ve Timestamp adli üç sistem özelliği de dahil olmak üzere) |
| Bir varlıktaki tek bir özelliğin en büyük toplam boyutu | Özellik türüne göre farklılık gösterir. Daha fazla bilgi için bkz. Tablo Hizmeti Veri Modelini anlama içindeki Özellik Türleri. |
| PartitionKey boyutu | Boyutu 1024 karaktere kadar olan bir dize |
| RowKey boyutu | Boyutu 1024 karaktere kadar olan bir dize |
| Bir varlık grubu işleminin boyutu | Bir işlem en fazla 100 varlığı içerebilir ve yük boyutunun 4 MiB’den az olması gerekir. Bir varlık grubu işlemi, bir varlığa yalnızca bir kez güncelleştirme içerebilir. |
| Tablo başına en fazla depolanan erişim ilkesi sayısı | 5 |
| Depolama hesabı başına istek hızı üst sınırı | Saniyede 20.000 işlem, 1 KiB varlık boyutu varsayılır |
| Tek bir tablo bölümü için hedef aktarım hızı (1 KiB varlıklar) | Saniyede 2.000 adede kadar varlık |
Maliyetle ilgili konular
Tablo depolama nispeten ucuzdur, ancak herhangi bir Tablo hizmeti çözümünü değerlendirmenizin bir parçası olarak hem kapasite kullanımı hem de işlem miktarı için maliyet tahminleri eklemeniz gerekir. Ancak birçok senaryoda çözümünüzün performansını veya ölçeklenebilirliğini geliştirmek için normalleştirilmiş veya yinelenen verileri depolamak geçerli bir yaklaşımdır. Fiyatlandırma hakkında daha fazla bilgi için bkz . Azure Depolama Fiyatlandırması.