Azure Cosmos DB’de istek maliyetlerini iyileştirme

  • Makale

ŞUNLAR IÇIN GEÇERLIDIR: Nosql MongoDB Cassandra Gremlin Tablo

Bu makalede, okuma ve yazma isteklerinin İstek Birimlerine nasıl çevrildiği ve bu isteklerin maliyetinin nasıl iyileştirileceği açıklanmaktadır. Okuma işlemleri nokta okumalarını ve sorgularını içerir. Yazma işlemleri öğe ekleme, değiştirme, silme ve upsert işlemlerini içerir.

Azure Cosmos DB, kapsayıcı içindeki öğeler üzerinde çalışan zengin bir veritabanı işlemleri kümesi sunar. Bu işlemlerden her biriyle ilişkilendirilmiş maliyet, işlemi tamamlamak için gereken CPU, GÇ ve belleğe göre değişiklik gösterir. Donanım kaynaklarını düşünmek ve yönetmek yerine, istekte bulunmak için çeşitli veritabanı işlemlerini gerçekleştirmek için gereken kaynaklar için tek bir ölçü olarak bir İstek Birimi (RU) düşünebilirsiniz.

İsteğin RU ücretini ölçme

İsteklerinizin RU ücretini ölçerek gerçek maliyetlerini anlamanız ve iyileştirmelerinizin etkinliğini değerlendirmeniz önemlidir. Azure portal kullanarak veya SDK'lardan biri aracılığıyla Azure Cosmos DB'den gönderilen yanıtı inceleyerek bu maliyeti getirebilirsiniz. Bunun nasıl sağlandığına ilişkin ayrıntılı yönergeler için bkz. Azure Cosmos DB'de istek birimi ücretini bulma .

Verileri okuma: nokta okumaları ve sorgular

Azure Cosmos DB'deki okuma işlemleri genellikle RU tüketimi açısından en hızlı/en verimliden daha yavaş/daha az verimliye sıralanır:

  • Nokta okumaları (tek bir öğe kimliğinde ve bölüm anahtarında anahtar/değer araması).
  • Tek bir bölüm anahtarı içinde bir filtre yan tümcesi ile sorgu.
  • Herhangi bir özellikte eşitlik veya aralık filtresi yan tümcesi olmadan sorgu yapın.
  • Filtre olmadan sorgulama.

Tutarlılık düzeyinin rolü

Güçlü veya sınırlanmış eskime durumututarlılık düzeyleri kullanılırken, herhangi bir okuma işleminin (nokta okuma veya sorgu) RU maliyeti ikiye katlanır.

Nokta okumaları

Okunan noktanın RU ücretini etkileyen tek faktör (kullanılan tutarlılık düzeyinin yanı sıra) alınan öğenin boyutudur. Aşağıdaki tabloda, boyutu 1 KB ve 100 KB olan öğeler için nokta okumalarının RU maliyeti gösterilmektedir.

Öğe Boyutu Bir nokta okuma maliyeti
1 KB 1 RU
100 KB 10 RU

Nokta okumaları (öğe kimliği ve bölüm anahtarındaki anahtar/değer aramaları) en verimli okuma türü olduğundan, öğe kimliğinizin anlamlı bir değere sahip olduğundan emin olmanız gerekir; böylece mümkün olduğunda öğelerinizi bir nokta okuma (sorgu yerine) ile getirebilirsiniz.

Not

NoSQL API'sinde nokta okuma işlemleri yalnızca REST API veya SDK'lar kullanılarak yapılabilir. Bir öğenin kimliğine ve bölüm anahtarına göre filtreleyen sorgular nokta okuma olarak kabul edilmez. .NET SDK'sını kullanan bir örneği görmek için bkz . NoSQL için Azure Cosmos DB'de bir öğeyi okuma.

Sorgular

Sorgular için istek birimleri bir dizi faktöre bağlıdır. Örneğin, yüklenen/döndürülen Azure Cosmos DB öğelerinin sayısı, dizinde yapılan arama sayısı, sorgu derleme süresi vb. Şey. Azure Cosmos DB, aynı veriler üzerinde yürütülürken aynı sorgunun yinelenen yürütmelerde bile her zaman aynı sayıda istek birimini tüketmesini garanti eder. Sorgu yürütme ölçümlerini kullanan sorgu profili, istek birimlerinin nasıl harcandığınız hakkında size iyi bir fikir verir.

Bazı durumlarda 200 ve 429 yanıtlarından oluşan bir dizi ve sorguların sayfalanmış yürütmesinde değişken istek birimleri görebilirsiniz; bunun nedeni sorguların kullanılabilir RU'lara göre mümkün olan en hızlı şekilde çalışmasıdır. Sunucu ve istemci arasında birden çok sayfaya/gidiş dönüşe bir sorgu yürütmesi sonu görebilirsiniz. Örneğin, 10.000 öğe birden çok sayfa olarak döndürülebilir ve her bir öğe bu sayfa için gerçekleştirilen hesaplamaya göre ücretlendirilir. Bu sayfaları topladığınızda, sorgunun tamamı için elde ettiğiniz RU sayısıyla aynı sayıda RU almanız gerekir.

Sorun giderme sorguları için ölçümler

Sorgular tarafından tüketilen performans ve aktarım hızı (kullanıcı tanımlı işlevler dahil) çoğunlukla işlev gövdesine bağlıdır. Sorgu yürütmenin UDF'de ne kadar zaman harcadığını ve tüketilen RU sayısını öğrenmenin en kolay yolu, sorgu ölçümlerini etkinleştirmektir. .NET SDK'sını kullanıyorsanız SDK tarafından döndürülen örnek sorgu ölçümleri şunlardır:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Sorguları maliyet iyileştirmeye yönelik en iyi yöntemler

Sorguları maliyet için iyileştirirken aşağıdaki en iyi yöntemleri göz önünde bulundurun:

  • Birden çok varlık türünü birlikte birleştirme

    Tek veya daha az sayıda kapsayıcı içinde birden çok varlık türünü birlikte kullanmayı deneyin. Bu yöntem yalnızca fiyatlandırma açısından değil, aynı zamanda sorgu yürütme ve işlemler için de avantaj sağlar. Sorguların kapsamı tek bir kapsayıcıdır; ve saklı yordamlar/tetikleyiciler aracılığıyla birden çok kayıt üzerindeki atomik işlemlerin kapsamı tek bir kapsayıcı içindeki bölüm anahtarı olarak belirlenir. Varlıkların aynı kapsayıcı içinde birlikte bulunması, kayıtlar arasındaki ilişkileri çözümlemek için ağ gidiş dönüşlerinin sayısını azaltabilir. Böylece uçtan uca performansı artırır, daha büyük bir veri kümesi için birden çok kayıt üzerinde atomik işlemlere olanak tanır ve sonuç olarak maliyetleri düşürür. Birden çok varlık türünü tek veya daha az sayıda kapsayıcı içinde birlikte bulundurmak senaryonuz için zorsa, bunun nedeni genellikle mevcut bir uygulamayı geçirmeniz ve kod değişikliği yapmak istemenizdir. Daha sonra aktarım hızını veritabanı düzeyinde sağlamayı düşünmelisiniz.

  • Daha düşük istek birimleri/ikinci kullanım için ölçme ve ayarlama

    Sorgunun karmaşıklığı, bir işlem için kaç istek biriminin (RU) tükettiğini etkiler. Koşul sayısı, koşulların yapısı, UDF sayısı ve kaynak veri kümesinin boyutu. Tüm bu faktörler sorgu işlemlerinin maliyetini etkiler.

Azure Cosmos DB, sağlanan aktarım hızı modelini kullanarak aktarım hızı ve gecikme süresi açısından öngörülebilir performans sağlar. Sağlanan aktarım hızı, saniye başına İstek Birimleri veya RU/sn cinsinden temsil edilir. İstek Birimi (RU), CPU, bellek, GÇ gibi işlem kaynakları üzerinde mantıksal bir soyutlamadır. bir istek gerçekleştirmek için gereklidir. Sağlanan aktarım hızı (RU) ayrılmıştır ve öngörülebilir aktarım hızı ve gecikme süresi sağlamak için kapsayıcınıza veya veritabanınıza ayrılmıştır. Sağlanan aktarım hızı, Azure Cosmos DB'nin öngörülebilir ve tutarlı performans, garantili düşük gecikme süresi ve her ölçekte yüksek kullanılabilirlik sağlamasına olanak tanır. İstek birimleri, bir uygulamanın kaç kaynağa ihtiyaç duyduğuna ilişkin mantığı basitleştiren normalleştirilmiş para birimini temsil eder.

İstek üst bilgisinde döndürülen istek ücreti, belirli bir sorgunun maliyetini gösterir. Örneğin, bir sorgu 1000 1 KB öğe döndürürse, işlemin maliyeti 1000'dir. Bu nedenle, sunucu sonraki istekleri sınırlamadan önce bir saniye içinde bu tür iki isteği kabul eder. Daha fazla bilgi için istek birimleri makalesine ve istek birimi hesaplayıcısına bakın.

Veri yazma

Öğe yazmanın RU maliyeti aşağıdakilere bağlıdır:

Yaklaşık yaklaşık 5,5 RU'lık bir dizin oluşturma maliyeti olmadan 1 KB'lık bir öğe ekleme. Bir öğeyi değiştirmek, aynı öğeyi eklemek için gereken ücretin iki katına mal olur.

Yazmaları iyileştirme

Yazma işlemlerinin RU maliyetini iyileştirmenin en iyi yolu, öğelerinizi ve dizine alınan özelliklerin sayısını haklarına ayırmaktır.

  • Azure Cosmos DB'de çok büyük öğelerin depolanması yüksek RU ücretlerine neden olur ve bir anti-desen olarak kabul edilebilir. Özellikle, sorgulamanız gerekmeyen ikili içeriği veya büyük metin öbeklerini depolamayın. Bu tür verileri Azure Blob Depolama koymak ve Azure Cosmos DB'ye yazdığınız öğede bloba başvuru (veya bağlantı) depolamak en iyi uygulamadır.
  • Dizin oluşturma ilkenizi yalnızca sorgularınızın filtrelediği özellikleri dizine almak için en iyi duruma getirmek, yazma işlemleriniz tarafından kullanılan RU'larda büyük bir fark oluşturabilir. Yeni bir kapsayıcı oluştururken, varsayılan dizin oluşturma ilkesi öğelerinizde bulunan her özelliğin dizinini oluşturur. Bu, geliştirme etkinlikleri için iyi bir varsayılan olsa da, üretime giderken veya iş yükünüz önemli miktarda trafik almaya başladığında dizin oluşturma ilkenizi yeniden değerlendirmeniz ve özelleştirmeniz kesinlikle önerilir.

Verilerin toplu alımı yapılırken, bu tür işlemlerin RU tüketimini iyileştirmek için tasarlandığından Azure Cosmos DB toplu yürütücü kitaplığının kullanılması da önerilir. İsteğe bağlı olarak, aynı kitaplık üzerinde oluşturulan Azure Data Factory de kullanabilirsiniz.

Sonraki adımlar

Daha sonra aşağıdaki makalelerle Azure Cosmos DB'de maliyet iyileştirme hakkında daha fazla bilgi edinebilirsiniz: