Tablo depolama için performans ve ölçeklenebilirlik denetim listesi
Microsoft, Tablo depolama ile yüksek performanslı uygulamalar geliştirmeye yönelik birçok kanıtlanmış uygulama geliştirmiştir. Bu denetim listesi, geliştiricilerin performansı iyileştirmek için izleyebilecekleri temel uygulamaları tanımlar. Uygulamanızı tasarlarken ve süreç boyunca bu uygulamaları göz önünde bulundurun.
Azure Depolama kapasite, işlem hızı ve bant genişliği için ölçeklenebilirlik ve performans hedefleri vardır. Azure Depolama ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz. Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri ve Tablo depolama için ölçeklenebilirlik ve performans hedefleri.
Denetim listesi
Bu makalede, performans için kanıtlanmış yöntemler, Tablo depolama uygulamanızı geliştirirken izleyebileceğiniz bir denetim listesi halinde düzenlenir.
Ölçeklenebilirlik hedefleri
Uygulamanız ölçeklenebilirlik hedeflerinden herhangi birine yaklaşır veya aşarsa, işlem gecikme sürelerinin artması veya azaltma ile karşılaşabilir. Azure Depolama uygulamanızı kısıtladığında, hizmet 503 (Sunucu meşgul) veya 500 (İşlem zaman aşımı) hata kodları döndürmeye başlar. Ölçeklenebilirlik hedeflerinin sınırları içinde kalarak bu hatalardan kaçınmak, uygulamanızın performansını geliştirmenin önemli bir parçasıdır.
Tablo hizmeti için ölçeklenebilirlik hedefleri hakkında daha fazla bilgi için bkz . Tablo depolama için ölçeklenebilirlik ve performans hedefleri.
En fazla depolama hesabı sayısı
Belirli bir abonelik/bölge bileşimi için izin verilen en fazla depolama hesabı sayısına yaklaşıyorsanız, giriş, çıkış, G/Ç işlemlerini saniyede (IOPS) veya kapasiteyi artırmak için parçalama için birden çok depolama hesabı mı kullanıyorsunuz? Bu senaryoda Microsoft, mümkünse iş yükünüz için gereken depolama hesabı sayısını azaltmak için depolama hesaplarının artan sınırlarından yararlanmanızı önerir. Depolama hesabınız için daha fazla sınır istemek için Azure Desteği'ne başvurun.
Kapasite ve işlem hedefleri
Uygulamanız tek bir depolama hesabı için ölçeklenebilirlik hedeflerine yaklaşıyorsa aşağıdaki yaklaşımlardan birini benimsemeyi göz önünde bulundurun:
- Uygulamanızın ölçeklenebilirlik hedefine yaklaşmasına veya aşmasına neden olan iş yükünü yeniden düşünün. Daha az bant genişliği veya kapasite ya da daha az işlem kullanmak için bunu farklı bir şekilde tasarlayabilir misiniz?
- Uygulamanızın ölçeklenebilirlik hedeflerinden birini aşması gerekiyorsa, birden çok depolama hesabı oluşturun ve uygulama verilerinizi bu birden çok depolama hesabında bölümleyin. Bu düzeni kullanıyorsanız, gelecekte yük dengeleme için daha fazla depolama hesabı ekleyebilmek için uygulamanızı tasarladığınızdan emin olun. Depolama hesapların depolanan veriler, yapılan işlemler veya aktarılan veriler açısından kullanımınızdan başka bir maliyeti yoktur.
- Uygulamanız bant genişliği hedeflerine yaklaşıyorsa verileri Azure Depolama göndermek için gereken bant genişliğini azaltmak için verileri istemci tarafında sıkıştırmayı göz önünde bulundurun. Verileri sıkıştırmak bant genişliğinden tasarruf edebilir ve ağ performansını geliştirebilir ancak performans üzerinde olumsuz etkileri de olabilir. İstemci tarafında veri sıkıştırma ve sıkıştırmayı açma için ek işleme gereksinimlerinin performans etkisini değerlendirin. Sıkıştırılmış verilerin depolanmasının, standart araçları kullanarak verileri görüntülemek daha zor olabileceğinden sorun gidermeyi daha zor hale getirebileceğini unutmayın.
- Uygulamanız ölçeklenebilirlik hedeflerine yaklaşıyorsa, yeniden denemeler için üstel geri alma kullandığınızdan emin olun. Bu makalede açıklanan önerileri uygulayarak ölçeklenebilirlik hedeflerine ulaşmayı önlemeye çalışmak en iyisidir. Ancak, yeniden denemeler için üstel geri alma kullanmak uygulamanızın hızlı bir şekilde yeniden denemesini engeller ve bu da azaltmayı daha kötü hale getirir. Daha fazla bilgi için Zaman Aşımı ve Sunucu Meşgul hataları başlıklı bölüme bakın.
Veri işlemleri için hedefler
Depolama hesabınıza gelen trafik arttıkça Azure Depolama yük dengelemesi sağlar, ancak trafik ani ani artışlar gösterirse bu aktarım hızını hemen elde edemeyebilirsiniz. Azure Depolama tablonuzun yükünü otomatik olarak dengelediğinden, veri bloğu sırasında azaltma ve/veya zaman aşımları görmeyi bekleyin. Sistemin yük dengelemesi için uygun zamanı olduğundan yavaş artış genellikle daha iyi sonuçlar sağlar.
Saniye başına varlıklar (depolama hesabı)
Tablolara erişmek için ölçeklenebilirlik sınırı, bir hesap için saniyede 20.000 varliğe (her biri 1 KB) kadardır. Genel olarak, eklenen, güncelleştirilen, silinen veya taranan her varlık bu hedefe doğru sayılır. Bu nedenle, 100 varlık içeren bir toplu ekleme 100 varlık olarak sayılır. 1000 varlığı tarar ve 5 döndürür bir sorgu 1000 varlık olarak sayılır.
Saniye başına varlıklar (bölüm)
Tek bir bölümde, tablolara erişmek için ölçeklenebilirlik hedefi, önceki bölümde açıklandığı gibi sayma kullanılarak saniyede 2.000 varlıktır (her biri 1 KB).
Ağ
Uygulamanın fiziksel ağ kısıtlamalarının performans üzerinde önemli bir etkisi olabilir. Aşağıdaki bölümlerde kullanıcıların karşılaşabileceği bazı sınırlamalar açıklanmaktadır.
İstemci ağ özelliği
Bant genişliği ve ağ bağlantısının kalitesi, aşağıdaki bölümlerde açıklandığı gibi uygulama performansında önemli roller oynar.
Aktarım hızı
Bant genişliği için sorun genellikle istemcinin özellikleridir. Daha büyük Azure örneklerinde daha fazla kapasiteye sahip NIC'ler olduğundan, tek bir makineden daha yüksek ağ sınırlarına ihtiyacınız varsa daha büyük bir örnek veya daha fazla VM kullanmayı düşünmelisiniz. Şirket içi bir uygulamadan Azure Depolama erişiyorsanız, aynı kural geçerlidir: istemci cihazının ağ özelliklerini ve Azure Depolama konumuna ağ bağlantısını anlayın ve gerektiğinde bunları geliştirin veya uygulamanızı kendi özellikleri içinde çalışacak şekilde tasarlayın.
Bağlantı kalitesi
Tüm ağ kullanımlarında olduğu gibi, hatalara ve paket kaybına neden olan ağ koşullarının etkili aktarım hızını yavaşlattığını unutmayın. WireShark veya NetMon kullanmak bu sorunun tanısında yardımcı olabilir.
Konum
Herhangi bir dağıtılmış ortamda istemcinin sunucuya yakın yerleştirilmesi en iyi performansı sunar. Azure Depolama en düşük gecikme süresiyle erişmek için istemciniz için en iyi konum aynı Azure bölgesindedir. Örneğin, Azure Depolama kullanan bir Azure web uygulamanız varsa her ikisini de ABD Batı veya Asya Güneydoğu gibi tek bir bölgede bulun. Tek bir bölgedeki bant genişliği kullanımı ücretsiz olduğundan kaynakların birlikte bulunması gecikme süresini ve maliyeti azaltır.
İstemci uygulamaları Azure Depolama erişecekse ancak mobil cihaz uygulamaları veya şirket içi kurumsal hizmetler gibi Azure'da barındırılmadıysa depolama hesabını bu istemcilere yakın bir bölgede bulmak gecikme süresini azaltabilir. İstemcileriniz geniş ölçekte dağıtılmışsa (örneğin, bazıları Kuzey Amerika ve bazıları Avrupa'da), bölge başına bir depolama hesabı kullanmayı düşünün. Uygulamanın depodığı veriler tek tek kullanıcılara özgüyse ve depolama hesapları arasında veri çoğaltılması gerekmiyorsa bu yaklaşımı uygulamak daha kolaydır.
SAS ve CORS
Azure Depolama'daki verilere erişmek için kullanıcının web tarayıcısında veya cep telefonu uygulamasında çalışan JavaScript gibi bir kodu yetkilendirmeniz gerektiğini varsayalım. Bir yaklaşım, ara sunucu işlevi gören bir hizmet uygulaması oluşturmaktır. Kullanıcının cihazı hizmette kimlik doğrulaması yapar ve bu da Azure Depolama kaynaklarına erişim yetkisine sahip olur. Bu şekilde, depolama hesabı anahtarlarınızı güvenli olmayan cihazlarda açığa çıkarmaktan kaçınabilirsiniz. Ancak, kullanıcının cihazı ile Azure Depolama arasında aktarılan tüm verilerin hizmet uygulamasından geçmesi gerektiğinden, bu yaklaşım hizmet uygulamasına önemli bir yük getirir.
Paylaşılan erişim imzaları (SAS) kullanarak Azure Depolama için ara sunucu olarak hizmet uygulamasını kullanmaktan kaçınabilirsiniz. SAS kullanarak, sınırlı erişim belirteci kullanarak kullanıcı cihazınızın doğrudan Azure Depolama istekte bulunmasını sağlayabilirsiniz. Örneğin, bir kullanıcı uygulamanıza fotoğraf yüklemek isterse hizmet uygulamanız bir SAS oluşturabilir ve bunu kullanıcının cihazına gönderebilir. SAS belirteci, belirli bir süre boyunca bir Azure Depolama kaynağına yazma izni verebilir ve bundan sonra SAS belirtecinin süresi dolar. SAS hakkında daha fazla bilgi için bkz. Paylaşılan erişim imzalarını (SAS) kullanarak Azure Depolama kaynaklarına sınırlı erişim verme.
Genellikle, bir web tarayıcısı bir etki alanındaki web sitesi tarafından barındırılan bir sayfada JavaScript'in başka bir etki alanına yazma işlemleri gibi belirli işlemleri gerçekleştirmesine izin vermez. Aynı kaynak ilkesi olarak bilinen bu ilke, bir sayfadaki kötü amaçlı betiğin başka bir web sayfasındaki verilere erişmesini engeller. Ancak, bulutta çözüm oluştururken aynı kaynak ilkesi bir sınırlama olabilir. Çıkış noktaları arası kaynak paylaşımı (CORS), hedef etki alanının kaynak etki alanındaki isteklere güvendiği tarayıcıyla iletişim kurmasını sağlayan bir tarayıcı özelliğidir.
Örneğin, Azure'da çalışan bir web uygulamasının Azure Depolama hesabına bir kaynak isteğinde bulunadığını varsayalım. Web uygulaması kaynak etki alanı, depolama hesabı ise hedef etki alanıdır. Kaynak etki alanından gelen isteklerin Azure Depolama tarafından güvenilen web tarayıcısıyla iletişim kurması için Azure Depolama hizmetlerinden herhangi biri için CORS'yi yapılandırabilirsiniz. CORS hakkında daha fazla bilgi için bkz. Azure Depolama için çıkış noktaları arası kaynak paylaşımı (CORS) desteği.
Hem SAS hem de CORS, web uygulamanızda gereksiz yüklemelerden kaçınmanıza yardımcı olabilir.
Toplu işlemler
Tablo hizmeti, aynı tabloda yer alan ve aynı bölüm grubuna ait varlıklar üzerinde toplu işlemleri destekler. Daha fazla bilgi için bkz . Varlık grubu işlemleri gerçekleştirme.
.NET yapılandırması
.NET Framework kullanan projeler için bu bölümde, önemli performans geliştirmeleri yapmak için kullanabileceğiniz bazı hızlı yapılandırma ayarları listelenmektedir. .NET dışında bir dil kullanıyorsanız, seçtiğiniz dilde benzer kavramların geçerli olup olmadığını denetleyin.
Varsayılan bağlantı sınırını artırma
Dekont
Bağlantı havuzu ServicePointManager sınıfı tarafından denetlendiği için bu bölüm .NET Framework kullanan projeler için geçerlidir. .NET Core, bağlantı havuzu yönetimiyle ilgili önemli bir değişiklik yaptı. Burada bağlantı havuzu HttpClient düzeyinde gerçekleşir ve havuz boyutu varsayılan olarak sınırlı değildir. Bu, HTTP bağlantılarının iş yükünüzü karşılamak için otomatik olarak ölçeklendirildiğini gösterir. Performans geliştirmelerinden yararlanmak için mümkün olduğunda .NET'in en son sürümünü kullanmanız önerilir.
.NET Framework kullanan projelerde, varsayılan bağlantı sınırını (genellikle istemci ortamında 2 veya sunucu ortamında 10) 100'e yükseltmek için aşağıdaki kodu kullanabilirsiniz. Genellikle, değerini yaklaşık olarak uygulamanız tarafından kullanılan iş parçacığı sayısına ayarlamanız gerekir. Herhangi bir bağlantı açmadan önce bağlantı sınırını ayarlayın.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
.NET Framework'teki bağlantı havuzu sınırları hakkında daha fazla bilgi edinmek için bkz. .NET Framework Bağlan ion Havuzu Sınırları ve .NET için yeni Azure SDK.
Diğer programlama dilleri için bağlantı sınırının nasıl ayarlandığını belirlemek için belgelere bakın.
En az iş parçacığı sayısını artırma
Zaman uyumlu çağrıları zaman uyumsuz görevlerle birlikte kullanıyorsanız, iş parçacığı havuzundaki iş parçacığı sayısını artırmak isteyebilirsiniz:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Daha fazla bilgi için bkz . ThreadPool.SetMinThreads yöntemi.
Sınırsız paralellik
Paralellik performans için harika olsa da, iş parçacığı veya paralel istek sayısı için zorunlu bir sınır olmadığı anlamına gelen, ilişkisiz paralellik kullanma konusunda dikkatli olun. Verileri karşıya yüklemek veya indirmek, aynı depolama hesabındaki birden çok bölüme erişmek veya aynı bölümdeki birden çok öğeye erişmek için paralel istekleri sınırlandırmaya dikkat edin. Paralellik ilişkisizse uygulamanız istemci cihazının özelliklerini veya depolama hesabının ölçeklenebilirlik hedeflerini aşarak daha uzun gecikme sürelerine ve azaltmaya neden olabilir.
İstemci kitaplıkları ve araçları
En iyi performans için her zaman Microsoft tarafından sağlanan en son istemci kitaplıklarını ve araçlarını kullanın. Azure Depolama istemci kitaplıkları çeşitli diller için kullanılabilir. Azure Depolama, PowerShell ve Azure CLI'ı da destekler. Microsoft, performans göz önünde bulundurularak bu istemci kitaplıklarını ve araçlarını etkin bir şekilde geliştirir, en son hizmet sürümleriyle güncel kalmasını sağlar ve kanıtlanmış performans uygulamalarının birçoğunun dahili olarak işlenmesini sağlar.
Hizmet hatalarını işleme
Azure Depolama, hizmet bir isteği işleyemediğinde bir hata döndürür. Belirli bir senaryoda Azure Depolama tarafından döndürülen hataları anlamak performansı iyileştirmeye yardımcı olur.
Zaman aşımı ve Sunucu Meşgul hataları
Azure Depolama, ölçeklenebilirlik sınırlarına yaklaşırsa uygulamanızı kısıtlayabilir. Bazı durumlarda Azure Depolama geçici bir koşul nedeniyle bir isteği işleyemeyebilir. Her iki durumda da hizmet bir 503 (Sunucu Meşgul) veya 500 (Zaman Aşımı) hatası döndürebilir. Bu hatalar, hizmetin daha yüksek aktarım hızı sağlamak için veri bölümlerini yeniden dengelemesi durumunda da oluşabilir. İstemci uygulaması genellikle bu hatalardan birine neden olan işlemi yeniden denemelidir. Ancak Azure Depolama ölçeklenebilirlik hedeflerini aştığı için uygulamanızı daraltıyorsa veya hizmet başka bir nedenle isteğe hizmet veremese bile agresif yeniden denemeler sorunu daha da kötü hale getirebilir. Üstel geri alma yeniden deneme ilkesi kullanılması önerilir ve istemci kitaplıkları varsayılan olarak bu davranışa ayarlanır. Örneğin, uygulamanız 2 saniye, sonra 4 saniye, 10 saniye, sonra 30 saniye sonra yeniden deneyebilir ve sonra tamamen vazgeçebilir. Bu şekilde, uygulamanız hizmet üzerindeki yükünü azaltmaya yol açabilecek davranışı daha da azaltmak yerine önemli ölçüde azaltır.
Bağlan üretkenlik hataları, azaltmanın sonucu olmadığından ve geçici olması beklendiğinden hemen yeniden denenebilir.
Yeniden denenemeyen hatalar
İstemci kitaplıkları yeniden denemeleri, hangi hataların yeniden denenebileceğini ve hangilerinin denenemiyebileceğinin farkında olarak işler. Ancak Azure Depolama REST API'sini doğrudan çağırıyorsanız yeniden denememeniz gereken bazı hatalar vardır. Örneğin, 400 (Hatalı İstek) hatası, istemci uygulamasının beklenen biçimde olmadığı için işlenemeyen bir istek gönderdiğini gösterir. Bu isteği yeniden gönderme işlemi her seferinde aynı yanıta neden olduğundan yeniden denemenin bir anlamı yoktur. Azure Depolama REST API'sini doğrudan çağırıyorsanız olası hataları ve bunların yeniden denenip denenmeyeceğini unutmayın.
Azure Depolama hata kodları hakkında daha fazla bilgi için bkz. Durum ve hata kodları.
Yapılandırma
Bu bölümde, Tablo hizmetinde önemli performans iyileştirmeleri yapmak için kullanabileceğiniz çeşitli hızlı yapılandırma ayarları listelenir:
JSON kullan
Tablo hizmeti, depolama hizmeti sürüm 2013-08-15'den başlayarak tablo verilerini aktarmak için XML tabanlı AtomPub biçimi yerine JSON kullanılmasını destekler. JSON kullanmak yük boyutlarını %75'e kadar azaltabilir ve uygulamanızın performansını önemli ölçüde artırabilir.
Daha fazla bilgi için Microsoft Azure Tabloları: Tablo Hizmeti İşlemleri için JSON ve Yük Biçimi tanıtımı gönderisine bakın.
Nagle'ı devre dışı bırak
Nagle algoritması, ağ performansını iyileştirmenin bir aracı olarak TCP/IP ağları arasında yaygın olarak uygulanır. Ancak, her koşulda (yüksek oranda etkileşimli ortamlar gibi) en uygun seçenek değildir. Nagle algoritmasıNın Azure Tablo hizmetine yönelik isteklerin performansı üzerinde olumsuz bir etkisi vardır ve mümkünse bunu devre dışı bırakmanız gerekir.
Şema
Verilerinizi nasıl temsil ettiğiniz ve sorguladığınız Tablo hizmetinin performansını etkileyen en büyük tek faktördür. Her uygulama farklı olsa da, bu bölümde aşağıdakilerle ilgili bazı genel olarak kanıtlanmış uygulamalar özetlenmektedir:
- Tablo tasarımı
- Verimli sorgular
- Verimli veri güncelleştirmeleri
Tablolar ve bölümler
Tablolar bölümlere ayrılır. Bir bölümde depolanan her varlık aynı bölüm anahtarını paylaşır ve bu bölümün içinde tanımlamak için benzersiz bir satır anahtarına sahiptir. Bölümler avantajlar sağlar ancak ölçeklenebilirlik sınırları da getirir.
- Avantajlar: Aynı bölümdeki varlıkları, en fazla 100 ayrı depolama işlemi (toplam boyut sınırı 4 MB) içeren tek, atomik bir toplu işlemde güncelleştirebilirsiniz. Alınacak varlık sayısının aynı olduğunu varsayarsak, tek bir bölümdeki verileri bölümlere yayılan verilerden daha verimli bir şekilde sorgulayabilirsiniz (ancak tablo verilerini sorgulama hakkında daha fazla öneri için okumaya devam edebilirsiniz).
- Ölçeklenebilirlik sınırı: Bölümler atomik toplu işlemleri desteklediği için tek bir bölümde depolanan varlıklara erişim yük dengelemesi yapılamaz. Bu nedenle, tek bir tablo bölümü için ölçeklenebilirlik hedefi Tablo hizmetinin bütün olarak değerinden daha düşüktür.
Tabloların ve bölümlerin bu özellikleri nedeniyle aşağıdaki tasarım ilkelerini benimsemeniz gerekir:
- İstemci uygulamanızın sık sık güncelleştirdiğini veya aynı bölümdeki aynı mantıksal iş biriminde sorgular yaptığı verileri bulun. Örneğin, uygulamanız yazma işlemlerini toplanıyorsa veya atomik toplu işlem gerçekleştiriyorsanız, aynı bölümdeki verileri bulun. Ayrıca, tek bir bölümdeki veriler tek bir sorguda bölümler arasındaki verilerden daha verimli bir şekilde sorgulanabilir.
- İstemci uygulamanızın eklemediği, güncelleştirmediği veya sorgulamadığı verileri aynı mantıksal iş birimine (tek bir sorguda veya toplu güncelleştirmede) ayrı bölümlere yerleştirin. Tek bir tablodaki bölüm anahtarlarının sayısıyla ilgili bir sınır olmadığını, dolayısıyla milyonlarca bölüm anahtarına sahip olmanın sorun oluşturmadığını ve performansı etkilemeyeceğinden unutmayın. Örneğin, uygulamanız kullanıcı oturum açma özelliğine sahip popüler bir web sitesiyse bölüm anahtarı olarak Kullanıcı Kimliğini kullanmak iyi bir seçim olabilir.
Sık erişimli bölümler
Sık erişimli bölüm, bir hesaba yönelik trafiğin orantısız yüzdesini alan ve tek bir bölüm olduğundan yük dengelemesi gerçekleştirilemediği bölümdür. Genel olarak, sık erişimli bölümler iki yoldan biri oluşturulur:
Yalnızca Ekle ve Yalnızca Önceden Ekle desenleri
"Yalnızca Ekle" deseni, belirli bir bölüm anahtarına gelen trafiğin tümünün (veya neredeyse tümünün) geçerli zamana göre arttığı ve azaldığı bir desendir. Örneğin, uygulamanızın günlük verileri için bölüm anahtarı olarak geçerli tarihi kullandığını varsayalım. Bu tasarım, tüm eklemelerin tablonuzdaki son bölüme gitmesine neden olur ve sistem düzgün yük dengelemesi yapamaz. Bu bölüme gelen trafik hacmi bölüm düzeyi ölçeklenebilirlik hedefini aşarsa azaltmaya neden olur. Tablonuzdaki isteklerin yük dengelemesini sağlamak için trafiğin birden çok bölüme gönderilmesini sağlamak daha iyidir.
Yüksek trafik verileri
Bölümleme düzeniniz yalnızca diğer bölümlerden çok daha fazla kullanılan verilere sahip tek bir bölümle sonuçlanırsa, bölüm tek bir bölüm için ölçeklenebilirlik hedefini yaklaştığında azaltmayı da görebilirsiniz. Bölüm düzeninizin ölçeklenebilirlik hedeflerine yaklaşan tek bir bölüm olmadığından emin olmak daha iyidir.
Sorgulama
Bu bölümde Tablo hizmetini sorgulamaya yönelik kanıtlanmış yöntemler açıklanmaktadır.
Sorgu kapsamı
Sorguya eklenecek varlık aralığını belirtmenin çeşitli yolları vardır. Aşağıdaki listede sorgu kapsamına yönelik her seçenek açıklanmaktadır.
- Nokta sorguları:- Nokta sorgusu, alınacak varlığın hem bölüm anahtarını hem de satır anahtarını belirterek tam olarak bir varlık alır. Bu sorgular verimlidir ve bunları mümkün olan her yerde kullanmanız gerekir.
- Bölüm sorguları: Bölüm sorgusu, ortak bir bölüm anahtarını paylaşan bir veri kümesini alan bir sorgudur. Genellikle sorgu, bölüm anahtarına ek olarak bir satır anahtarı değeri aralığını veya bazı varlık özellikleri için bir değer aralığı belirtir. Bu sorgular nokta sorgularından daha az verimlidir ve tedbirli kullanılmalıdır.
- Tablo sorguları: Tablo sorgusu, ortak bölüm anahtarını paylaşmayan bir varlık kümesini alan bir sorgudur. Bu sorgular verimli değildir ve mümkünse bu sorgulardan kaçınmalısınız.
Genel olarak, taramalardan kaçının (tek bir varlıktan daha büyük sorgular), ancak tarama yapmanız gerekiyorsa, taramalarınızın ihtiyacınız olan verileri taramadan veya ihtiyacınız olmayan önemli miktarda varlık döndürmeden almasını sağlamak için verilerinizi düzenlemeyi deneyin.
Sorgu yoğunluğu
Sorgu verimliliğindeki bir diğer önemli faktör, döndürülen kümeyi bulmak için taranan varlık sayısıyla karşılaştırıldığında döndürülen varlık sayısıdır. Uygulamanız veri paylaşımlarının yalnızca %1'ini oluşturan bir özellik değeri için filtre içeren bir tablo sorgusu gerçekleştiriyorsa, sorgu döndürdüğü her varlık için 100 varlığı tarar. Daha önce ele alınan tablo ölçeklenebilirlik hedeflerinin tümü taranan varlıkların sayısıyla ilgilidir ve döndürülen varlık sayısıyla ilgili değildir: Düşük sorgu yoğunluğu, tablo hizmetinin aradığınız varlığı almak için çok fazla varlığı taraması gerektiğinden uygulamanızı kısıtlamasına kolayca neden olabilir. Azaltmayı önleme hakkında daha fazla bilgi için Normal dışı bırakma başlıklı bölüme bakın.
Döndürülen veri miktarını sınırlama
Bir sorgunun istemci uygulamasında ihtiyacınız olmayan varlıkları döndürdüğünü bildiğinizde, döndürülen kümenin boyutunu küçültmek için bir filtre kullanmayı göz önünde bulundurun. İstemciye döndürülmeyen varlıklar ölçeklenebilirlik sınırlarına doğru sayılmaya devam etse de, ağ yükü boyutunun azalması ve istemci uygulamanızın işlemesi gereken varlık sayısının azalması nedeniyle uygulama performansınız artar. Ölçeklenebilirlik hedeflerinin taranan varlık sayısıyla ilişkili olduğunu, dolayısıyla çok sayıda varlığı filtreleyen bir sorgunun, az sayıda varlık döndürülse bile azaltmaya neden olabileceğini unutmayın. Sorguları verimli hale getirme hakkında daha fazla bilgi için Sorgu yoğunluğu başlıklı bölüme bakın.
İstemci uygulamanızın tablonuzdaki varlıklardan yalnızca sınırlı bir özellik kümesine ihtiyacı varsa, döndürülen veri kümesinin boyutunu sınırlamak için projeksiyonu kullanabilirsiniz. Filtrelemede olduğu gibi projeksiyon da ağ yükünü ve istemci işlemeyi azaltmaya yardımcı olur.
Normal dışıleştirme
İlişkisel veritabanlarıyla çalışmaktan farklı olarak, tablo verilerini verimli bir şekilde sorgulamaya yönelik kanıtlanmış uygulamalar verilerinizin normal dışı olmasını sağlar. Başka bir deyişle, uygulamanızın ihtiyaç duyduğu verileri bulmak için çok sayıda varlığı taramak yerine, bir sorgunun istemcinin ihtiyaç duyduğu verileri bulmak için taraması gereken varlık sayısını en aza indirmek için aynı verileri birden çok varlıkta (verileri bulmak için kullanabileceğiniz her anahtar için bir tane) çoğaltın. Örneğin, bir e-ticaret web sitesinde, hem müşteri kimliğine (bu müşterinin siparişlerini verin) hem de tarihe göre (bir tarihte bana sipariş ver) bir sipariş bulmak isteyebilirsiniz. Tablo Depolama'da varlığı (veya ona başvuruyu) iki kez depolamak en iyisidir: Müşteri kimliğine göre bulmayı kolaylaştırmak için tablo adı, PK ve RK ile bir kez, bir kez de tarihe göre bulmayı kolaylaştırmak için.
Ekleme, güncelleştirme ve silme
Bu bölümde, Tablo hizmetinde depolanan varlıkları değiştirmeye yönelik kanıtlanmış yöntemler açıklanmaktadır.
İşlem grubu oluşturma
Toplu işlemler, Azure Depolama varlık grubu işlemleri olarak bilinir. Varlık grubu işlemi içindeki tüm işlemler tek bir tablodaki tek bir bölümde olmalıdır. Mümkün olduğunda, toplu olarak ekleme, güncelleştirme ve silme işlemleri gerçekleştirmek için varlık grubu işlemlerini kullanın. Varlık grubu işlemlerinin kullanılması, istemci uygulamanızdan sunucuya gidiş dönüş sayısını azaltır, faturalanabilir işlem sayısını azaltır (varlık grubu işlem, faturalama amacıyla tek bir işlem olarak sayılır ve en fazla 100 depolama işlemi içerebilir) ve atomik güncelleştirmeleri etkinleştirir (tüm işlemler bir varlık grubu işlemi içinde başarılı veya başarısız olur). Mobil cihazlar gibi yüksek gecikme süresine sahip ortamlar, varlık grubu işlemlerinin kullanılmasından büyük fayda sağlar.
Upsert
Tablo Upsert işlemlerini mümkün olan her yerde kullanın. her ikisi de geleneksel Insert ve Update işlemlerinden daha verimli olabilecek iki tür Upsert vardır:
- InsertOrMerge: Varlığın özelliklerinin bir alt kümesini karşıya yüklemek istediğinizde ancak varlığın zaten var olup olmadığından emin değilseniz bu işlemi kullanın. Varlık varsa, bu çağrı Upsert işlemine dahil edilen özellikleri güncelleştirir ve varlık yoksa, var olan tüm özellikleri olduğu gibi bırakır, yeni varlığı ekler. Bu, yalnızca değişen özellikleri karşıya yüklemeniz gerektiğinden sorguda projeksiyon kullanmaya benzer.
- InsertOrReplace: Tamamen yeni bir varlığı karşıya yüklemek istediğinizde, ancak varlığın zaten var olup olmadığından emin değilseniz bu işlemi kullanın. Yeni yüklenen varlığın eski varlığın üzerine tamamen yazıldığından tamamen doğru olduğunu bildiğinizde bu işlemi kullanın. Örneğin, uygulamanın kullanıcı için daha önce konum verilerini depolayıp depolamadığına bakılmaksızın kullanıcının geçerli konumunu depolayan varlığı güncelleştirmek istiyorsunuz; yeni konum varlığı tamamlandı ve önceki herhangi bir varlıktan herhangi bir bilgiye ihtiyacınız yok.
Veri serisini tek bir varlıkta depolama
Bazen, bir uygulama sık sık tümünü bir kerede alması gereken bir dizi veri depolar: Örneğin, bir uygulama son 24 saat içindeki verilerin sıralı bir grafiğini çizmek için zaman içinde CPU kullanımını izleyebilir. Bir yaklaşım, her varlığın belirli bir saati temsil eden ve o saat için CPU kullanımını depolayan bir tablo varlığı olmasıdır. Bu verileri çizmek için uygulamanın en son 24 saatteki verileri tutan varlıkları alması gerekir.
Alternatif olarak, uygulamanız her saatin CPU kullanımını tek bir varlığın ayrı bir özelliği olarak depolayabilir: her saati güncelleştirmek için uygulamanız en son saatin değerini güncelleştirmek için tek bir InsertOrMerge Upsert çağrısı kullanabilir. Verilerin çizilmesi için uygulamanın 24 yerine yalnızca tek bir varlığı alması gerekir ve bu da verimli bir sorgu sağlar. Sorgu verimliliği hakkında daha fazla bilgi için Sorgu kapsamı başlıklı bölüme bakın.
Yapılandırılmış verileri bloblarda depolama
Toplu eklemeler gerçekleştiriyor ve sonra varlık aralıklarını birlikte alıyorsanız, tablolar yerine blobları kullanmayı göz önünde bulundurun. Günlük dosyası iyi bir örnektir. Birkaç dakikalık günlükleri toplu işleyip ekleyebilir ve ardından bir kerede birkaç dakikalık günlükleri alabilirsiniz. Bu durumda, tablolar yerine bloblar kullandığınızda performans daha iyidir, çünkü yazılan veya okunan nesne sayısını ve büyük olasılıkla yapılması gereken istek sayısını önemli ölçüde azaltabilirsiniz.