Azure Cosmos DB'de istek Cosmos iyileştirme

UYGULAMANIN UYGULAMASI: SQL API Api Api Gremlin API Tablo API'si Azure Cosmos DB API'si (MongoDB için)

Bu makalede, okuma ve yazma isteklerinin İstek Birimleri'ne nasıl çevril olduğu ve bu isteklerin maliyetinin nasıl en iyi duruma getirmekte olduğu açıklanmıştır. Okuma işlemleri nokta okuma ve sorguları içerir. Yazma işlemleri öğe ekleme, değiştirme, silme ve ekleme 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şlemlerin her biri ile ilişkili maliyet, işlemi tamamlamak için gereken CPU, IO ve belleğe göre değişir. Donanım kaynaklarını düşünmek ve yönetmek yerine, bir İstek Birimi'nin (RU) bir istekte yer alan çeşitli veritabanı işlemlerini gerçekleştirmesi için gereken kaynakların tek ölçümü olduğunu düşünebilirsiniz.

İsteğin RU ücretlerini ölçme

gerçek maliyetlerini anlamak ve ayrıca iyileştirmelerinizin ne kadar etkili olduğunu değerlendirmek için isteklerinizin RU ücretlerini ölçmeniz önemlidir. Azure portalını kullanarak veya Azure Cosmos DB'den SDK'lerden biri aracılığıyla geri gönderilen yanıtı inceleerek bu maliyeti getirebilirsiniz. Bunu nasıl başarmayla ilgili ayrıntılı yönergeler için bkz. Azure Cosmos DB'de istek birimi ücretlerini bulma.

Veri okuma: nokta okuma ve sorguları

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

  • Nokta okur (tek bir öğe kimliği veya 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şittir veya aralık filtresi yan tümcesi olmadan sorgu.
  • Filtre olmadan sorgu.

Tutarlılık düzeyinin rolü

Güçlü veya bağlı eski tutarlılık düzeyleri kullanılarakherhangibir okunma işlemi (nokta okuma veya sorgu) RU maliyeti iki katına çıkar.

Nokta okumaları

Okunan bir noktanın RU şarjını etkileyen tek faktör (kullanılan tutarlılık düzeyinin yanı sıra) alınan öğenin boyutudur. Aşağıdaki tabloda, 1 KB ve 100 KB boyutunda olan öğelerin RU okuma noktası maliyeti gösterir.

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

Nokta okuması (öğe kimliğindeki anahtar/değer aramaları) en verimli okuma türü olduğundan, mümkün olduğunda öğelerinizi bir nokta okuma noktasıyla (sorgu yerine) getirebilirsiniz ve böylece öğe kimliğiniz anlamlı bir değere sahip olduğundan emin olun.

Sorgular

Sorgular için istek birimleri bir dizi faktöre bağlıdır. Örneğin, yüklenen/döndürülen Azure Cosmos sayısı, dizine yapılan aramaların sayısı, sorgu derleme süresi vb. ayrıntıları. Azure Cosmos DB aynı verilerde yürütülürken aynı sorgunun yineleme yürütmeleri olduğunda bile her zaman aynı sayıda istek birimini tüketeceklerini garanti eder. Sorgu yürütme ölçülerini kullanan sorgu profili, istek birimlerinin nasıl harcanıyor olduğu konusunda iyi bir fikir sağlar.

Bazı durumlarda, sorguların sayfalı yürütülmesinde 200 ve 429 yanıt sırasını ve değişken istek birimleri görebilirsiniz, çünkü sorgular kullanılabilir RU'lara dayalı olarak mümkün olduğunca hızlı çalıştırılmalıdır. Sorgu yürütmenin sunucu ve istemci arasında birden çok sayfa/gidiş dönüş olarak olduğunu farkebilirsiniz. Örneğin, her biri bu sayfa için gerçekleştirilen hesaplamaya göre ücret alınan birden çok sayfa olarak 10.000 öğe döndürülebilirsiniz. Bu sayfaların toplamını hesaplarken, tüm sorguda elde olacağınız RÜ sayısı kadar RÜ'leri elde edinebilirsiniz.

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

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

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  

En iyi maliyet iyileştirme sorguları için en iyi yöntemler

Sorguları maliyet için en iyi duruma getirme konusunda aşağıdaki en iyi yöntemleri göz önünde bulundurarak:

  • Birden çok varlık türü birlikte bulma

    Birden çok varlık türüyle tek veya daha az sayıda kapsayıcıyı bir başka kapsayıcılar arasında bir yer anlamaya çalışabilirsiniz. Bu yöntem, hem fiyatlandırma açısından hem de sorgu yürütme ve işlemler açısından avantajlar sağlar. Sorgular tek bir kapsayıcı kapsamındadır; ve depolanmış yordamlar/tetikleyiciler aracılığıyla yapılan birden çok kayıt üzerinde bölünmez işlemler, tek bir kapsayıcı içinde bir bölüm anahtarı kapsamındadır. Aynı kapsayıcı içinde varlıkları birlikte bulmak, kayıtlar arasındaki ilişkileri çözümlemek için ağ gidiş dönüş sayısını azaltabilirsiniz. Bu nedenle uç uç performansı artırır, daha büyük bir veri kümesi için birden fazla kayıt üzerinde bölünmez işlemlere olanak sağlar ve bunun sonucunda maliyetleri düşürer. Senaryo olarak bir veya daha az sayıda kapsayıcı içinde birden çok varlık türü bulmak zorsa, genellikle var olan bir uygulamayı taşıyor ve herhangi bir kod değişikliği yapmak istemiyorsanız, aktarım hızını veritabanı düzeyinde sağlamayı göz önünde bulundurabilirsiniz.

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

    Sorgunun karmaşıklığı, bir işlem için kaç istek biriminin (RU) tüketilmelerini etkiler. Yüklemlerin sayısı, yüklemlerin doğası, PDF sayısı ve kaynak veri kümesi boyutu. Tüm bu etmenler sorgu işlemlerinin maliyetini etkiler.

Azure Cosmos DB, sağlanan bir aktarım hızı modeli kullanarak performans ve gecikme süresi açısından öngörülebilir performans sağlar. Sağlanan performans, saniye başına İstek Birimleri veya RU/sn'ler açısından temsil edilmektedir. İstek Birimi (RU), istek gerçekleştirmek için gereken CPU, bellek, IO gibi bilgi işlem kaynakları üzerinden yapılan mantıksal bir özettir. Sağlanan aktarım hızı (RU'lar) ayrılmıştır ve öngörülebilir performans ve gecikme süresi sağlamak için kapsayıcınıza veya veritabanınıza ayrılmıştır. Sağlanan üretilen iş, Azure Cosmos DB'in öngörülebilir ve tutarlı performans, garantili düşük gecikme süresi ve her ölçekte yüksek kullanılabilirlik sağlamalarını sağlar. İstek birimleri, bir uygulamaya gereken kaynak sayısına neden olan sebepleri basitleştiren normalleştirilmiş para birimini temsil ediyor.

İ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şlem maliyeti 1000 olur. Bu nedenle, sunucu bir saniye içinde, sonraki istekleri oranla sınırlamadan önce bu tür yalnızca iki isteği karşılar. Daha fazla bilgi için, istek birimleri makalesine ve istek birimi hesaplayıcısına bakın.

Veri yazma

Bir öğeyi yazmanın RU maliyeti aşağıdakilere bağlıdır:

~5,5 RUS'a göre dizin oluşturma maliyeti olmadan 1 KB öğesi ekleme. Bir öğenin değiştirilmesi, aynı öğeyi eklemek için gereken ücretin iki katıdır.

Yazmaları iyileştirme

Yazma işlemlerinin RU maliyetini en iyi duruma getirmenin en iyi yolu, öğelerinizi ve dizine alan özellik sayısını hak etmektir.

  • Azure Cosmos DB'de çok büyük ögelerin depolanması yüksek RU ücretlerine neden olur ve bir anti-desen olarak kabul edilir. Özellikle, ikili içeriği veya sorgulamaya gerek olmadığınız büyük metin öbeklerini depolamayın. En iyi yöntem, Azure Blob'a bu tür veriler Depolama Azure Cosmos DB'ye yazmakta olduğunuz öğede bloba başvuru (veya bağlantı) depolamaktır.
  • Dizin oluşturma ilkenizi en iyi duruma getirerek, yalnızca sorgularınızı filtrelenin özelliklerinde dizin oluşturmanın, yazma işlemleriniz tarafından tüketilen RUS'larda büyük bir fark yaratabilir. Yeni kapsayıcı oluştururken, varsayılan dizin oluşturma ilkesi öğelerinizin her bir özelliğinin dizinini olur. Bu, geliştirme etkinlikleri için iyi bir varsayılan değerken dizin oluşturma ilkenizi üretime alırken veya iş yükünün önemli trafik almaya başladığı zaman yeniden değerlendirmeniz ve özelleştirmeniz kesinlikle önerilir.

Veriler toplu olarak satın alma yaparken, bu tür işlemlerin RU tüketimini en iyi duruma getirmek için tasarlanmıştırken Azure Cosmos DB toplu yürütme kitaplığını kullanılması da önerilir. İsteğe bağlı olarak, aynı kitaplıkta yerleşik olarak bulunan Azure Veri Fabrikası'nın yanı sıra kullanabilirsiniz.

Sonraki adımlar

Ardından, aşağıdaki makalelerle Azure Cosmos DB'de maliyet iyileştirme hakkında daha fazla bilgi edinmek için işleme devam edebilirsiniz: