Aracılığıyla paylaş


Sorgulama için tasarım

Tablo hizmeti çözümleri yoğun okuma, yazma yoğunluklu veya ikisinin bir karışımı olabilir. Bu makalede, Tablo hizmetinizi okuma işlemlerini verimli bir şekilde destekleyecek şekilde tasarlarken aklınızda bulundurmanız gerekenler ele alınmaktadır. Genellikle, okuma işlemlerini verimli bir şekilde destekleyen bir tasarım, yazma işlemleri için de verimlidir. Ancak, veri değişikliği için tasarlama makalesinde ele alınan yazma işlemlerini destekleyecek şekilde tasarlarken dikkate alınması gereken ek noktalar vardır.

Verileri verimli bir şekilde okumanızı sağlayacak Tablo hizmeti çözümünüzü tasarlamaya yönelik iyi bir başlangıç noktası, "Uygulamamın Tablo hizmetinden ihtiyaç duyduğu verileri almak için hangi sorguları yürütmesi gerekecek?" sorusunu sormaktır.

Not

Tablo hizmetiyle tasarımın daha sonra değiştirilmesi zor ve pahalı olduğundan tasarımın doğru olması önemlidir. Örneğin, ilişkisel bir veritabanında genellikle var olan bir veritabanına dizinler ekleyerek performans sorunlarını çözmek mümkündür: Bu, Tablo hizmetiyle ilgili bir seçenek değildir.

Bu bölüm, tablolarınızı sorgulama için tasarlarken çözmeniz gereken önemli sorunlara odaklanır. Bu bölümde ele alınan konular şunlardır:

PartitionKey ve RowKey seçiminiz sorgu performansını nasıl etkiler?

Aşağıdaki örneklerde, tablo hizmetinin çalışan varlıklarını aşağıdaki yapıyla depoluyor olduğu varsayılır (örneklerin çoğu netlik için Timestamp özelliğini atlar):

Sütun adı Veri türü
PartitionKey (Bölüm Adı) Dize
RowKey (Çalışan Kimliği) Dize
FirstName Dize
LastName Dize
Age Tamsayı
EmailAddress Dize

Azure Tablo depolamaya genel bakış makalesi, Azure Tablo hizmetinin sorgu tasarımı üzerinde doğrudan etkisi olan bazı önemli özelliklerini açıklar. Bu, Tablo hizmeti sorguları tasarlamaya yönelik aşağıdaki genel yönergelerle sonuçlanır. Aşağıdaki örneklerde kullanılan filtre söz diziminin Tablo hizmeti REST API'sinden alındığını unutmayın. Daha fazla bilgi için bkz. Sorgu Varlıkları.

  • Nokta Sorgusu, kullanılacak en verimli aramadır ve en düşük gecikme süresi gerektiren yüksek hacimli aramalar veya aramalar için kullanılması önerilir. Böyle bir sorgu, hem PartitionKey hem de RowKey değerlerini belirterek tek bir varlığı çok verimli bir şekilde bulmak için dizinleri kullanabilir. Örneğin: $filter=(PartitionKey eq 'Sales') ve (RowKey eq '2')
  • İkinci en iyisi, PartitionKey kullanan ve birden fazla varlık döndürmek için bir rowkey değeri aralığına filtreleyen Aralık Sorgusudur. PartitionKey değeri belirli bir bölümü, RowKey değerleri ise bu bölümdeki varlıkların bir alt kümesini tanımlar. Örneğin: $filter=PartitionKey eq 'Sales' ve RowKey ge 'S' ve RowKey lt 'T'
  • Üçüncü en iyisi, PartitionKey'i kullanan ve anahtar olmayan başka bir özellik üzerinde filtreleyen ve birden fazla varlık döndürebilen Bölüm Taramasıdır. PartitionKey değeri belirli bir bölümü tanımlar ve özellik değerleri bu bölümdeki varlıkların bir alt kümesi için seçer. Örneğin: $filter=PartitionKey eq 'Sales' ve LastName eq 'Smith'
  • Tablo TaramasıPartitionKey'i içermez ve tablonuzu oluşturan tüm bölümleri eşleşen varlıklar için sırayla arama yaptığı için çok verimsizdir. Filtrenizin RowKey kullanıp kullanmadığına bakılmaksızın bir tablo taraması gerçekleştirir. Örneğin: $filter=LastName eq 'Jones'
  • Birden çok varlık döndüren sorgular bunları PartitionKey ve RowKey sırasıyla döndürür. İstemcideki varlıklara başvurmaktan kaçınmak için en yaygın sıralama düzenini tanımlayan bir RowKey seçin.

RowKey değerlerini temel alan bir filtre belirtmek için "veya" kullanılması bölüm taramasına neden olur ve aralık sorgusu olarak değerlendirilmez. Bu nedenle, şu filtreleri kullanan sorgulardan kaçınmalısınız: $filter=PartitionKey eq 'Sales' ve (RowKey eq '121' veya RowKey eq '322')

Verimli sorgular yürütmek için Depolama İstemci Kitaplığı'nı kullanan istemci tarafı kod örnekleri için bkz:

Aynı tabloda depolanan birden çok varlık türünü işleyebilen istemci tarafı kod örnekleri için bkz:

Uygun bir PartitionKey seçme

PartitionKey seçiminiz, varlık grubu işlemlerinin kullanımını etkinleştirme gereksinimini (tutarlılığı sağlamak için) varlıklarınızı birden çok bölüme dağıtma gereksinimiyle (ölçeklenebilir bir çözüm sağlamak için) dengelemelidir.

Bir uç noktada, tüm varlıklarınızı tek bir bölümde depolayabilirsiniz, ancak bu çözümünüzün ölçeklenebilirliğini sınırlayabilir ve tablo hizmetinin isteklerin yük dengelemesini engelleyebilir. Diğer uçta ise bölüm başına bir varlık depolayabilirsiniz. Bu durum yüksek oranda ölçeklenebilir ve tablo hizmetinin isteklerin yükünü dengelemesine olanak tanır ancak bu durum varlık grubu işlemlerini kullanmanızı engeller.

İdeal bir PartitionKey , verimli sorgular kullanmanızı sağlayan ve çözümünüzün ölçeklenebilir olduğundan emin olmak için yeterli bölüme sahip olan bir anahtardır. Genellikle varlıklarınızın, varlıklarınızı yeterli bölümler arasında dağıtan uygun bir özelliği olacağını göreceksiniz.

Not

Örneğin, kullanıcılar veya çalışanlar hakkındaki bilgileri depolayan bir sistemde UserID iyi bir PartitionKey olabilir. Bölüm anahtarı olarak belirli bir UserID kullanan birkaç varlığınız olabilir. Bir kullanıcıyla ilgili verileri depolayan her varlık tek bir bölümde gruplandırılır ve bu nedenle bu varlıklara varlık grubu işlemleri aracılığıyla erişilebilirken yüksek oranda ölçeklenebilir.

PartitionKey seçiminizde varlıkları nasıl ekleyeceğinizi, güncelleştireceğinizi ve sileceğinizi belirten ek noktalar vardır. Daha fazla bilgi için bkz. Veri değişikliği için tablo tasarlama.

Tablo hizmeti için sorguları iyileştirme

Tablo hizmeti, tek bir kümelenmiş dizinde PartitionKey ve RowKey değerlerini kullanarak varlıklarınızı otomatik olarak dizine alır; bu nedenle, nokta sorgularının kullanılması en verimli nedendir. Ancak PartitionKey ve RowKey üzerindeki kümelenmiş dizinde bundan başka dizin yoktur.

Birçok tasarım, varlıkların birden çok ölçüte göre aramasını sağlamak için gereksinimleri karşılamalıdır. Örneğin, e-postaya, çalışan kimliğine veya soyadına göre çalışan varlıklarını bulma. Tablo Tasarım Desenleri'nde açıklanan desenler bu tür gereksinimleri ele alır ve Tablo hizmetinin ikincil dizinler sağlamadığı gerçeğine geçici bir çözüm bulmanın yollarını açıklar:

  • Bölüm içi ikincil dizin deseni - Farklı RowKey değerleri kullanarak hızlı ve verimli aramalar ve alternatif sıralama düzenleri sağlamak için her varlığın birden çok kopyasını farklı RowKey değerleri (aynı bölümde) kullanarak depolayın.
  • Bölümler arası ikincil dizin düzeni - Farklı RowKey değerleri kullanarak her varlığın birden çok kopyasını ayrı bölümlerde veya ayrı tablolarda depolayarak hızlı ve verimli aramalar ve farklı RowKey değerleri kullanarak alternatif sıralama düzenleri sağlayın.
  • Dizin Varlıkları Düzeni - Varlık listelerini döndüren verimli aramalar sağlamak için dizin varlıklarını koruyun.

Tablo hizmetinde verileri sıralama

Tablo hizmeti, PartitionKey'e ve ardından RowKey'e göre artan düzende sıralanmış varlıklar döndürür. Bu anahtarlar dize değerleridir ve sayısal değerlerin doğru sıralandığından emin olmak için bunları sabit bir uzunluğa dönüştürmeniz ve sıfırlarla doldurmanız gerekir. Örneğin, RowKey olarak kullandığınız çalışan kimliği değeri bir tamsayı değeriyse, 123 çalışan kimliğini 00000123 dönüştürmeniz gerekir.

Birçok uygulamanın farklı siparişlerde sıralanmış verileri kullanma gereksinimleri vardır: örneğin, çalışanları ada göre veya tarihe göre sıralama. Aşağıdaki desenler, varlıklarınız için sıralama düzenlerinin nasıl alternatif olarak sıralanacağını ele alır:

  • Bölüm içi ikincil dizin deseni - Farklı RowKey değerleri kullanarak hızlı ve verimli aramalar ve alternatif sıralama düzenleri sağlamak için her varlığın birden çok kopyasını farklı RowKey değerleri (aynı bölümde) kullanarak depolayın.
  • Bölümler arası ikincil dizin deseni - Hızlı ve verimli aramalar ve farklı RowKey değerleri kullanarak alternatif sıralama düzenleri sağlamak için farklı RowKey değerlerini kullanarak her varlığın birden çok kopyasını ayrı bölümlerde ayrı tablolarda depolayın.
  • Günlük kuyruğu deseni - Ters tarih ve saat düzeninde sıralayan bir RowKey değeri kullanarak bir bölüme en son eklenen n varlığı alın.

Sonraki adımlar