Azure Cosmos DB’de istek maliyetlerini iyileştirme

  • Şunlara uygulanır: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Bu makalede, okuma ve yazma isteklerinin İstek Birimlerine (RU) nasıl çevrildiği ve bu isteklerin maliyetinin nasıl iyileştirileceği açıklanmaktadır. Okuma işlemleri nokta okumaları ve sorgular içerir. Yazma işlemleri, öğe ekleme, değiştirme, silme ve ekleme/güncelleme ("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. Ru değerini 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 hesaplama

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

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 içeren sorgu
  • Herhangi bir özellikte eşitlik veya aralık filtresi yan tümcesi olmadan sorgulama
  • Filtre olmadan sorgulama

Tutarlılık düzeyinin rolü

Güçlü veya sınırlandırılmış gecikmelitutarlılık düzeyleri kullanıldığında, herhangi bir okuma işlemi veya sorgunun RU maliyeti iki katına çıkar.

Belirli nokta okumaları

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

Note

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.

Queries

Sorgular için istek birimleri, yüklenen veya döndürülen Azure Cosmos DB öğelerinin sayısı, dizinde yapılan arama sayısı ve sorgu derleme süresi gibi birçok faktöre bağlıdır. Azure Cosmos DB, aynı sorgunun aynı verilerde yürütülürken yinelenen yürütmelerle bile her zaman aynı sayıda istek birimi 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, kullanılabilir RU'ları temel alan sorgular mümkün olduğunca hızlı çalıştığından, sorguların sayfalı yürütülmesinde 200 ve 429 yanıt dizisi ve değişken istek birimleri görebilirsiniz. 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, her biri o sayfa için gerçekleştirilen hesaplamaya göre ücretlendirilen 10.000 öğe birden çok sayfa olarak döndürülebilir. Bu sayfaları topladığınızda, sorgunun tamamı için elde edeceğiniz RU sayısıyla aynı sayıda RU elde etmelisiniz.

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  

Sorgu maliyetini 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

    Çok sayıda varlık türünü tek veya daha az sayıdaki kapsayıcıda bir araya getirmeyi 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ı olarak belirlenmiştir. 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 kod değişikliği yapmak istemediğinizden veritabanı düzeyinde aktarım hızı sağlamayı düşünmelisiniz.

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

    Sorgunun karmaşıklığı, bir işlem için tüketilen RU sayısını 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 bir aktarım hızı modeli kullanarak aktarım hızı ve gecikme süresi açısından tahmin edilebilir performans sağlar. Sağlanan aktarım hızı, saniye başına RU veya RU/sn cinsinden temsil edilir. 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), ö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 her ölçekte tahmin edilebilir ve tutarlı performans, garantili düşük gecikme süresi ve yüksek kullanılabilirlik sağlamasına olanak tanır. RU'lar, 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 bin kb öğe döndürürse işlemin maliyeti 1000'dir. Bu nedenle, sunucu bir saniye içinde yalnızca iki isteği kabul eder ve daha sonraki istekleri hız sınırlandırmasına tabi tutar. Daha fazla bilgi için bkz. Azure Cosmos DB'de İstek Birimleri ve istek birimi hesaplayıcısı.

Veri yazma

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

Dizinleme yapılmadan 1 KB'lık bir öğe eklemek yaklaşık 5,5 RU tutar. Bir öğenin değiştirilmesi, aynı öğeyi eklemek için gereken ücretin iki katıdır.

Yazma işlemlerini optimize etme

Yazma işlemlerinin RU maliyetini optimize etmenin en iyi yolu, öğelerinizi doğru boyutlandırmak ve dizine alınan özelliklerin sayısını ayarlamaktır.

  • Azure Cosmos DB'de çok büyük öğelerin depolanması, yüksek RU ücretlerine neden olur ve bir antipattern olarak kabul edilebilir. Özellikle, sorgulamanız gerekmeyen ikili içeriği veya büyük metin öbeklerini depolamayın. En iyi yöntem, bu tür verileri Azure Blob Depolama içine koymak ve Azure Cosmos DB'ye yazdığınız öğede blob için bir başvuru (veya bağlantı) depolamaktır.
  • 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 değer 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'yi de kullanabilirsiniz.

Sonraki Adımlar

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

Azure Cosmos DB'ye geçiş için kapasite planlaması yapmaya mı çalışıyorsunuz? Kapasite planlaması için mevcut veritabanı kümeniz hakkındaki bilgileri kullanabilirsiniz.

  • Tek bildiğiniz mevcut veritabanı kümenizdeki sanal çekirdek ve sunucu sayısıysa, sanal çekirdek veya vCPU kullanarak istek birimlerini tahmin etme hakkında bilgi edinin
  • Geçerli veritabanı iş yükünüz için tipik istek oranlarını biliyorsanız, Azure Cosmos DB kapasite planlayıcısını kullanarak istek birimlerini tahmin etme hakkında bilgi edinin.
  • Last updated on