Azure Cosmos DB’de istek maliyetlerini iyileştirme

UYGULANANLAR: SQL API Cassandra API Gremlin API Tablo API'si MongoDB için Azure Cosmos DB API'si

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ı içerir. Yazma işlemleri öğe ekleme, değiştirme, silme ve yükseltme 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. İstek Birimi'ni (RU), donanım kaynaklarını düşünmek ve yönetmek yerine, istek sunmak üzere çeşitli veritabanı işlemlerini gerçekleştirmek için gereken kaynaklar için tek bir ölçü olarak düşünebilirsiniz.

İsteğin RU ücretini ölçme

İsteklerinizin RU ücretini ölçerek gerçek maliyetlerini anlamanız ve ayrıca iyileştirmelerinizin verimliliğini değerlendirmeniz önemlidir. Azure portal kullanarak veya SDK'lardan biri aracılığıyla Azure Cosmos DB'den geri 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 filtre yan tümcesi ile sorgu.
  • Herhangi bir özellikte eşitlik veya aralık filtresi yan tümcesi olmadan sorgu.
  • Filtre olmadan sorgulama.

Tutarlılık düzeyinin rolü

Güçlü veya sınırlanmış eskimetutarlılığı düzeylerini kullanırken, herhangi bir okuma işleminin (nokta okuma veya sorgu) RU maliyeti iki katına çıkıyor.

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ğindeki 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 nokta okuma (sorgu yerine) ile getirebilirsiniz.

Sorgular

Sorgular için istek birimleri bir dizi faktöre bağlıdır. Örneğin, yüklenen/döndürülen Azure Cosmos öğelerinin sayısı, dizindeki aramaların sayısı, sorgu derleme süresi vb. ayrıntılar. Azure Cosmos DB, aynı verilerde 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 sayfalı 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. Bir sorgu yürütmenin sunucu ve istemci arasında birden çok sayfaya/gidiş dönüşe bölündiğini görebilirsiniz. Örneğin, 10.000 öğe birden çok sayfa olarak döndürülebilir ve her öğe bu sayfa için gerçekleştirilen hesaplamaya göre ücretlendirilir. Bu sayfaların toplamını aldığı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, 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ına göre 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, genellikle mevcut bir uygulamayı geçiriyorsanız ve kodda değişiklik yapmak istemediğinizden veritabanı düzeyinde aktarım hızı 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üketilmiş olduğunu etkiler. Koşul sayısı, koşul 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), istek gerçekleştirmek için gereken CPU, bellek, GÇ gibi işlem kaynakları üzerinde mantıksal bir soyutlamadır. 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 bir saniye içinde, izleyen istekleri sınırlamadan önce 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 maliyetler dizine alınmadan 1 KB'lık bir öğe ekleme. Bir öğenin değiştirilmesi, aynı öğeyi eklemek için gereken ücretin iki katı kadar maliyetlidir.

Yazmaları iyileştirme

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

  • Azure Cosmos DB'de çok büyük öğelerin depolanması yüksek RU ücretlerine neden olur ve bir anti-desen olarak düşünülebilir. Ö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 öğedeki bloba bir başvuru (veya bağlantı) depolamak en iyi yöntemdir.
  • Dizin oluşturma ilkenizi yalnızca sorgularınızın filtrelediği özelliklerin dizinini oluşturacak şekilde 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 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: