Azure Cosmos DB’de istek maliyetlerini iyileştirme
ŞUNLAR IÇIN GEÇERLIDIR: 
NoSQL MongoDB Cassandra Gremlin Masa
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ı ve sorgular 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 ayrıca iyileştirmelerinizin verimliliğ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. 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 tutarlılığı düzeyleri kullanıldığında, herhangi bir okuma işleminin (nokta okuma veya sorgu) RU maliyeti iki katına alınır.
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.
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ı, dizindeki arama 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, sorguların sayfalı yürütülmesinde 200 ve 429 yanıt dizisi ve 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, 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 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ı 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ğiniz için 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 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 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 İ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), ö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. İ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 5,5 RU'lık bir dizin oluşturma maliyeti olmadan 1 KB'lık bir öğe 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 iyileştirmenin en iyi yolu öğelerinizi ve dizine alınan özelliklerin sayısını haklarına sahip olmaktır.
- Azure Cosmos DB'de çok büyük öğelerin depolanması yüksek RU ücretlerine neden olur ve desenden koruma 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 koymak ve Azure Cosmos DB'ye yazdığınız öğede bloba 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 bir 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:
- Geliştirme ve test için iyileştirme hakkında daha fazla bilgi edinin
- Azure Cosmos DB faturanızı anlama hakkında daha fazla bilgi edinin
- Aktarım hızı maliyetini iyileştirme hakkında daha fazla bilgi edinin
- Depolama maliyetini iyileştirme hakkında daha fazla bilgi edinin
- Çok bölgeli Azure Cosmos DB hesaplarının maliyetini iyileştirme hakkında daha fazla bilgi edinin
- Azure Cosmos DB ayrılmış kapasitesi hakkında daha fazla bilgi edinin
- 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ı kullanarak istek birimlerini tahmin etme hakkında bilgi edinin