Aracılığıyla paylaş

Azure Cosmos DB Java SDK v4 için performans ipuçları

  • Makale

UYGULANANLAR: NoSQL

Önemli

Bu makaledeki performans ipuçları yalnızca Azure Cosmos DB Java SDK v4 içindir. Daha fazla bilgi için lütfen Azure Cosmos DB Java SDK v4 Sürüm notlarını, Maven deposunu ve Azure Cosmos DB Java SDK v4 sorun giderme kılavuzunu görüntüleyin. Şu anda v4'ten daha eski bir sürüm kullanıyorsanız v4'e yükseltme konusunda yardım için Bkz . Azure Cosmos DB Java SDK'sı v4'e geçiş kılavuzu.

Azure Cosmos DB, garantili gecikme süresi ve aktarım hızı ile sorunsuz bir şekilde ölçeklendirilen hızlı ve esnek bir dağıtılmış veritabanıdır. Azure Cosmos DB ile veritabanınızı ölçeklendirmek için büyük mimari değişiklikleri yapmanız veya karmaşık kod yazmanız gerekmez. Ölçeği artırma ve azaltma, tek bir API çağrısı veya SDK yöntem çağrısı yapmak kadar kolaydır. Ancak Azure Cosmos DB'ye ağ çağrıları aracılığıyla erişildiğinden, Azure Cosmos DB Java SDK v4 kullanırken en yüksek performansı elde etmek için istemci tarafı iyileştirmeleri yapabilirsiniz.

Bu nedenle "Veritabanımın performansını nasıl geliştirebilirim?" sorusunu soruyorsanız aşağıdaki seçenekleri göz önünde bulundurun:

Ağ

  • Performans için aynı Azure bölgesindeki istemcileri birlikte dağıtma

Mümkün olduğunda, Azure Cosmos DB'yi çağıran tüm uygulamaları Azure Cosmos DB veritabanıyla aynı bölgeye yerleştirin. Yaklaşık bir karşılaştırma için, aynı bölge içindeki Azure Cosmos DB çağrıları 1-2 ms içinde tamamlanır, ancak ABD'nin Batı ve Doğu kıyısı arasındaki gecikme süresi 50 ms'dir >. Bu gecikme süresi, istemciden Azure veri merkezi sınırına geçerken istek tarafından alınan yola bağlı olarak istekten isteğe farklılık gösterebilir. Çağrı yapan uygulamanın sağlanan Azure Cosmos DB uç noktasıyla aynı Azure bölgesinde bulunduğundan emin olunarak mümkün olan en düşük gecikme süresi elde edilir. Kullanılabilir bölgelerin listesi için bkz . Azure Bölgeleri.

Azure Cosmos DB bağlantı ilkesinin çizimi

Çok bölgeli bir Azure Cosmos DB hesabıyla etkileşim kuran bir uygulamanın, isteklerin birlikte bulunan bir bölgeye gidildiğinden emin olmak için tercih edilen konumları yapılandırması gerekir.

Gecikme süresini ve CPU değişimlerini azaltmak için hızlandırılmış ağı etkinleştirme

Gecikme süresini ve CPU değişimlerini azaltarak performansı en üst düzeye çıkarmak için Windows'unuzda Hızlandırılmış Ağ'ı (yönergeler için seçin) veya Linux'ta (yönergeler için seçin) Azure VM'yi etkinleştirmek için yönergeleri izlemenizi kesinlikle öneririz.

Hızlandırılmış ağ olmadan, Azure VM'nizle diğer Azure kaynakları arasında geçiş yapılan GÇ, VM ile ağ kartı arasında yer alan bir konak ve sanal anahtar üzerinden yönlendirilebilir. Ana bilgisayar ve sanal anahtarın veri yolu içinde satır içinde olması yalnızca iletişim kanalındaki gecikmeyi ve değişim süresini artırmakla kalır, aynı zamanda VM'den CPU döngülerini de çalar. Hızlandırılmış ağ ile VM, aracı olmadan doğrudan NIC ile arabirim oluşturur. Tüm ağ ilkesi ayrıntıları, konak ve sanal anahtar atlayarak NIC'deki donanımda işlenir. Genellikle daha düşük gecikme süresi ve daha yüksek aktarım hızının yanı sıra hızlandırılmış ağı etkinleştirdiğinizde daha tutarlı gecikme süresi ve daha az CPU kullanımı bekleyebilirsiniz.

Sınırlamalar: Hızlandırılmış ağ VM işletim sisteminde desteklenmeli ve yalnızca VM durdurulduğunda ve serbest bırakıldığında etkinleştirilebilir. VM, Azure Resource Manager ile dağıtılamaz. App Service'in hızlandırılmış ağı yoktur.

Daha fazla bilgi için Windows ve Linux yönergelerine bakın.

Doğrudan ve ağ geçidi bağlantı yapılandırmasını ayarlama

Doğrudan ve ağ geçidi modu bağlantı yapılandırmalarını iyileştirmek için bkz . java sdk v4 için bağlantı yapılandırmalarını ayarlama.

SDK kullanımı

  • En son SDK'sını yükleme

Azure Cosmos DB SDK'ları en iyi performansı sağlayacak şekilde sürekli geliştirilmektedir. En son SDK iyileştirmelerini belirlemek için Azure Cosmos DB SDK'sını ziyaret edin.

  • Uygulamanızın ömrü boyunca tek bir Azure Cosmos DB istemcisi kullanma

Her Azure Cosmos DB istemci örneği iş parçacığı açısından güvenlidir ve verimli bağlantı yönetimi ve adres önbelleği gerçekleştirir. Azure Cosmos DB istemcisi tarafından verimli bağlantı yönetimine ve daha iyi performansa izin vermek için, uygulamanın kullanım ömrü boyunca Azure Cosmos DB istemcisinin tek bir örneğini kullanmanızı kesinlikle öneririz.

  • Uygulamanız için gereken en düşük tutarlılık düzeyini kullanın

CosmosClient oluşturduğunuzda, açıkça ayarlanmadığında kullanılan varsayılan tutarlılık Oturum'dur. Oturum tutarlılığı uygulama mantığınız tarafından gerekli değilse Tutarlılık'ı Nihai olarak ayarlayın. Not: Azure Cosmos DB Değişiklik Akışı işlemcisini kullanan uygulamalarda en azından Oturum tutarlılığı kullanılması önerilir.

  • Sağlanan aktarım hızını en üst düzeyde kullanmak için Zaman Uyumsuz API kullanma

Azure Cosmos DB Java SDK v4, iki API'yi (Zaman Uyumlu ve Zaman Uyumsuz) paketler. Kabaca konuşursak, Zaman Uyumsuz API SDK işlevselliğini uygularken Eşitleme API'si, Zaman Uyumsuz API'ye engelleme çağrıları yapan ince bir sarmalayıcıdır. Bu, yalnızca Zaman Uyumsuz olan eski Azure Cosmos DB Async Java SDK v2 ve yalnızca Eşitle olan ve ayrı bir uygulaması olan eski Azure Cosmos DB Eşitleme Java SDK'sı v2 ile karşıttır.

API seçimi, istemci başlatma sırasında belirlenir; CosmosAsyncClient , Zaman Uyumsuz API'yi desteklerken CosmosClient eşitleme API'sini destekler.

Zaman Uyumsuz API, engelleyici olmayan GÇ uygular ve Hedefiniz Azure Cosmos DB'ye istekler oluştururken aktarım hızını en üst düzeyde çıkarmaksa en iyi seçenektir.

Eşitleme API'sini kullanmak, her isteğin yanıtını engelleyen veya zaman uyumlu işlem uygulamanızda baskın paradigma olan bir API'ye ihtiyacınız varsa doğru seçim olabilir. Örneğin, bir mikro hizmetler uygulamasında Verileri Azure Cosmos DB'de kalıcı hale getirmek istediğinizde Eşitleme API'sini isteyebilirsiniz. Sağlanan aktarım hızı kritik değildir.

Not eşitleme API'si aktarım hızı istek yanıt süresinin artmasıyla azalırken, Zaman Uyumsuz API donanımınızın tüm bant genişliği özelliklerini doygunluğa taşıyabilir.

Coğrafi birlikte bulundurma, Eşitleme API'si kullanırken size daha yüksek ve daha tutarlı aktarım hızı sağlayabilir (bkz . Performans için aynı Azure bölgesindeki istemcileri birlikte yerleştirme) ancak yine de zaman uyumsuz API ulaşılabilir aktarım hızını aşması beklenmemektedir.

Bazı kullanıcılar, Azure Cosmos DB Java SDK v4 Async API'sini uygulamak için kullanılan Reaktif Akışlar çerçevesi Project Reactor'ı da tanımıyor olabilir. Bu bir sorunsa, tanıtıcı Reactor Desen Kılavuzumuzu okumanızı ve ardından kendinizi tanımak için bu Reaktif Programlamaya Giriş bölümüne göz atmanızı öneririz. Azure Cosmos DB'yi zaten zaman uyumsuz bir arabirimle kullandıysanız ve kullandığınız SDK Azure Cosmos DB Async Java SDK v2 ise ReactiveX/RxJava hakkında bilgi sahibi olabilirsiniz ancak Project Reactor'da nelerin değiştiğinden emin olmayabilirsiniz. Bu durumda, aşina olmak için Reaktör ve RxJava Kılavuzumuza göz atın.

Aşağıdaki kod parçacıkları sırasıyla Async API veya Sync API işlemi için Azure Cosmos DB istemcinizi başlatmayı gösterir:

Java SDK V4 (Maven com.azure::azure-cosmos) Async API


CosmosAsyncClient client = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .buildAsyncClient();
  • İstemci iş yükünüzün ölçeğini genişletme

Yüksek aktarım hızı düzeylerinde test ediyorsanız, makinenin CPU veya ağ kullanımına odaklanması nedeniyle istemci uygulaması performans sorununa neden olabilir. Bu noktaya ulaşırsanız istemci uygulamalarınızın ölçeğini birden çok sunucu arasında genişleterek Azure Cosmos DB hesabını daha fazla göndermeye devam edebilirsiniz.

Gecikme süresini düşük tutmak için belirli bir sunucuda %50 CPU kullanımını aşmamak >iyi bir kuraldır.

  • Uygun Zamanlayıcıyı Kullan (Olay döngüsü GÇ Netty iş parçacıklarını çalmaktan kaçının)

Azure Cosmos DB Java SDK'sının zaman uyumsuz işlevselliği, netty engelleyici olmayan GÇ'yi temel alır. SDK, GÇ işlemlerini yürütmek için sabit sayıda GÇ Netty olay döngüsü iş parçacığı (makinenizdeki CPU çekirdeklerinin sayısı kadar) kullanır. API tarafından döndürülen Flux, sonucu paylaşılan GÇ olay döngüsü Netty iş parçacıklarından birinde döndürür. Bu nedenle paylaşılan GÇ olay döngüsü Netty iş parçacıklarının engellenmemesi önemlidir. GÇ olay döngüsü netty iş parçacığında YOĞUN CPU çalışması yapmak veya engelleme işlemi yapmak kilitlenmeye neden olabilir veya SDK aktarım hızını önemli ölçüde azaltabilir.

Örneğin aşağıdaki kod, olay döngüsü GÇ netty iş parçacığında yoğun cpu kullanan bir iş yürütür: 


Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub.subscribe(
        itemResponse -> {
            //this is executed on eventloop IO netty thread.
            //the eventloop thread is shared and is meant to return back quickly.
            //
            // DON'T do this on eventloop IO netty thread.
            veryCpuIntensiveWork();
        });

Sonuç alındıktan sonra, olay döngüsü GÇ netty iş parçacığında sonuç üzerinde yoğun CPU kullanan bir çalışma yapmaktan kaçınmanız gerekir. Bunun yerine, aşağıda gösterildiği gibi çalışmanızı çalıştırmak için kendi iş parçacığınızı sağlamak üzere kendi Scheduler'ınızı sağlayabilirsiniz (gerektirir import reactor.core.scheduler.Schedulers).


Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub
        .publishOn(Schedulers.parallel())
        .subscribe(
                itemResponse -> {
                    //this is now executed on reactor scheduler's parallel thread.
                    //reactor scheduler's parallel thread is meant for CPU intensive work.
                    veryCpuIntensiveWork();
                });

Çalışmanızın türüne bağlı olarak, işiniz için uygun mevcut Reactor Scheduler'ı kullanmalısınız. Burayı Schedulersokuyun.

Project Reactor'ın iş parçacığı oluşturma ve zamanlama modelini daha fazla anlamak için Project Reactor'ın bu blog gönderisine bakın.

Azure Cosmos DB Java SDK v4 hakkında daha fazla bilgi için GitHub'da Java monorepo için Azure SDK'sının Azure Cosmos DB dizinine bakın.

  • Uygulamanızda günlük ayarlarını iyileştirme

Çeşitli nedenlerle, yüksek istek aktarım hızı oluşturan bir iş parçacığında günlüğe kaydetme eklemeniz gerekir. Hedefiniz bir kapsayıcının sağlanan aktarım hızını bu iş parçacığı tarafından oluşturulan isteklerle tamamen doyurmaksa, günlüğe kaydetme iyileştirmeleri performansı büyük ölçüde iyileştirebilir.

  • Zaman uyumsuz günlükçü yapılandırma

Zaman uyumlu günlükçü gecikme süresi, istek oluşturan iş parçacığınızın genel gecikme süresi hesaplamasına neden olabilir. Günlük ek yükünü yüksek performanslı uygulama iş parçacıklarınızdan ayırması için log4j2 gibi bir zaman uyumsuz günlükçü önerilir.

  • Netty'nin günlüğünü devre dışı bırakma

Netty kitaplığı günlük kaydı gevedektir ve ek CPU maliyetlerinden kaçınmak için kapatılması gerekir (yapılandırmada oturum açmanın gizlenmesi yeterli olmayabilir). Hata ayıklama modunda değilseniz netty'nin günlüğünü tamamen devre dışı bırakın. Bu nedenle, netty'den tahakkuk org.apache.log4j.Category.callAppenders() eden ek CPU maliyetlerini kaldırmak için Log4j kullanıyorsanız kod tabanınıza aşağıdaki satırı ekleyin:

org.apache.log4j.Logger.getLogger("io.netty").setLevel(org.apache.log4j.Level.OFF);
  • İşletim Sistemi Dosyaları aç Kaynak Sınırı

Bazı Linux sistemleri (Red Hat gibi) açık dosya sayısı ve dolayısıyla toplam bağlantı sayısı üzerinde üst sınıra sahiptir. Geçerli sınırları görüntülemek için aşağıdakileri çalıştırın:

ulimit -a

Açık dosyaların (nofile) sayısının, yapılandırılmış bağlantı havuzu boyutunuz ve işletim sistemi tarafından diğer açık dosyalar için yeterli alan olacak kadar büyük olması gerekir. Daha büyük bir bağlantı havuzu boyutuna izin verecek şekilde değiştirilebilir.

limits.conf dosyasını açın:

vim /etc/security/limits.conf

Aşağıdaki satırları ekleyin/değiştirin:

* - nofile 100000
  • Nokta yazmalarda bölüm anahtarı belirtme

Nokta yazma performansını geliştirmek için, aşağıda gösterildiği gibi nokta yazma API çağrısında öğe bölüm anahtarı belirtin:

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

asyncContainer.createItem(item,new PartitionKey(pk),new CosmosItemRequestOptions()).block();

Aşağıda gösterildiği gibi yalnızca öğe örneğini sağlamak yerine:

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

asyncContainer.createItem(item).block();

İkincisi desteklenir ancak uygulamanıza gecikme süresi ekler; SDK'nın öğeyi ayrıştırması ve bölüm anahtarını ayıklaması gerekir.

Sorgu işlemleri

Sorgu işlemleri için bkz. Sorgular için performans ipuçları.

Dizin oluşturma ilkesi

  • Daha hızlı yazma işlemleri için, kullanılmayan yolları dizin oluşturmanın dışında bırakma

Azure Cosmos DB'nin dizin oluşturma ilkesi, Dizin Oluşturma Yollarını (setIncludedPaths ve setExcludedPaths) kullanarak hangi belge yollarının dizine ekleneceğini veya dizin oluşturmanın dışında tutulacağını belirtmenize olanak tanır. Dizin oluşturma maliyetlerinin dizine alınan benzersiz yol sayısıyla doğrudan bağıntılı olması nedeniyle, dizin oluşturma yollarının kullanımı, sorgu desenlerinin önceden bilindiği senaryolar için gelişmiş yazma performansı ve daha düşük dizin depolaması sunabilir. Örneğin, aşağıdaki kodda belgelerin tüm bölümlerinin (alt ağaç olarak da bilinir) "*" joker karakteri kullanılarak dizin oluşturma işleminin nasıl dahil edilip dışlandığı gösterilmektedir.


CosmosContainerProperties containerProperties = new CosmosContainerProperties(containerName, "/lastName");

// Custom indexing policy
IndexingPolicy indexingPolicy = new IndexingPolicy();
indexingPolicy.setIndexingMode(IndexingMode.CONSISTENT);

// Included paths
List<IncludedPath> includedPaths = new ArrayList<>();
includedPaths.add(new IncludedPath("/*"));
indexingPolicy.setIncludedPaths(includedPaths);

// Excluded paths
List<ExcludedPath> excludedPaths = new ArrayList<>();
excludedPaths.add(new ExcludedPath("/name/*"));
indexingPolicy.setExcludedPaths(excludedPaths);

containerProperties.setIndexingPolicy(indexingPolicy);

ThroughputProperties throughputProperties = ThroughputProperties.createManualThroughput(400);

database.createContainerIfNotExists(containerProperties, throughputProperties);
CosmosAsyncContainer containerIfNotExists = database.getContainer(containerName);

Daha fazla bilgi için bkz . Azure Cosmos DB dizin oluşturma ilkeleri.

Aktarım hızı

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

Azure Cosmos DB, UDF'ler, saklı yordamlar ve tetikleyiciler içeren ilişkisel ve hiyerarşik sorgular da dahil olmak üzere zengin bir veritabanı işlemleri kümesi sunar. Bunların tümü bir veritabanı koleksiyonundaki belgeler üzerinde çalışır. 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, bir istek birimini (RU) çeşitli veritabanı işlemlerini gerçekleştirmek ve bir uygulama isteğine hizmet vermek için gereken kaynaklar için tek bir ölçü olarak düşünebilirsiniz.

Aktarım hızı, her kapsayıcı için ayarlanan istek birimi sayısına göre sağlanır. İstek birimi tüketimi saniye başına hız olarak değerlendirilir. Kapsayıcıları için sağlanan istek birimi hızını aşan uygulamalar, hız kapsayıcı için sağlanan düzeyin altına düşene kadar sınırlıdır. Uygulamanız daha yüksek bir aktarım hızı düzeyi gerektiriyorsa, ek istek birimleri sağlayarak aktarım hızınızı artırabilirsiniz.

Sorgunun karmaşıklığı, bir işlem için kaç istek biriminin tüketilmiş olduğunu etkiler. Koşul sayısı, koşulların yapısı, UDF sayısı ve kaynak veri kümesinin boyutu, sorgu işlemlerinin maliyetini etkiler.

Herhangi bir işlemin yükünü ölçmek için (oluşturma, güncelleştirme veya silme), x-ms-request-charge üst bilgisini inceleyerek bu işlemler tarafından kullanılan istek birimi sayısını ölçün. ResourceResponse T veya FeedResponse<<T>> içindeki eşdeğer RequestCharge özelliğine de bakabilirsiniz.

Java SDK V4 (Maven com.azure::azure-cosmos) Async API

CosmosItemResponse<CustomPOJO> response = asyncContainer.createItem(item).block();

response.getRequestCharge();

Bu üst bilgide döndürülen istek ücreti, sağlanan aktarım hızınızın bir bölümüdür. Örneğin, sağlanan 2000 RU/sn'niz varsa ve yukarıdaki sorgu 1.000 1 KB belge döndürüyorsa, 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 bkz . İstek birimleri ve istek birimi hesaplayıcısı.

  • İşleme hızı sınırlama/istek hızı çok büyük

İstemci bir hesap için ayrılmış aktarım hızını aşmaya çalıştığında, sunucuda performans düşüşü olmaz ve ayrılmış düzeyin ötesinde aktarım hızı kapasitesi kullanılamaz. Sunucu isteği RequestRateTooLarge (HTTP durum kodu 429) ile önceden sonlandıracak ve kullanıcının isteği yeniden başlatmadan önce beklemesi gereken süreyi milisaniye cinsinden belirten x-ms-retry-after-ms üst bilgisini döndürür.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

SDK'ların tümü bu yanıtı örtük olarak yakalar, sunucuda belirtilen retry-after üst bilgisine saygı gösterir ve isteği yeniden dener. Hesabınıza birden çok istemci tarafından eşzamanlı olarak erişilmediği sürece sonraki yeniden deneme başarılı olur.

İstek oranının üzerinde tutarlı bir şekilde çalışan birden fazla istemciniz varsa, varsayılan yeniden deneme sayısı şu anda istemci tarafından dahili olarak 9 olarak ayarlanmayabilir; bu durumda istemci, uygulamaya 429 durum koduna sahip bir CosmosClientException oluşturur. Varsayılan yeniden deneme sayısı, örnekte kullanılarak setMaxRetryAttemptsOnThrottledRequests() ThrottlingRetryOptions değiştirilebilir. Varsayılan olarak, istek istek hızının üzerinde çalışmaya devam ederse 30 saniyelik bir toplu bekleme süresinden sonra durum kodu 429 olan CosmosClientException döndürülür. Bu durum, geçerli yeniden deneme sayısı varsayılan olarak 9 veya kullanıcı tanımlı bir değer olması durumunda maksimum yeniden deneme sayısı'nın altında olsa bile oluşur.

Otomatik yeniden deneme davranışı çoğu uygulama için dayanıklılığı ve kullanılabilirliği artırmaya yardımcı olsa da, özellikle gecikme süresini ölçerken performans karşılaştırmaları yapılırken ortaya çıkabilir. Deneme sunucu kısıtlamasına isabet ederse ve istemci SDK'sının sessizce yeniden denemesine neden olursa istemci tarafından gözlemlenen gecikme süresi artar. Performans denemeleri sırasında gecikme süresi artışlarını önlemek için her işlem tarafından döndürülen ücreti ölçün ve isteklerin ayrılmış istek oranının altında çalıştığından emin olun. Daha fazla bilgi için bkz . İstek birimleri.

  • Daha yüksek aktarım hızı için daha küçük belgeler tasarlama

Belirli bir işlemin istek ücreti (istek işleme maliyeti), belgenin boyutuyla doğrudan ilişkilendirilir. Büyük belgelerdeki işlemler, küçük belgeler için yapılan işlemlerden daha pahalıdır. İdeal olarak, uygulamanızın ve iş akışlarınızın mimarisini, öğe boyutunuzun yaklaşık 1 KB veya benzer bir düzende veya büyüklükte olması için tasarlar. Gecikmeye duyarlı uygulamalarda büyük öğelerden kaçınılmalıdır. Çok MB'lı belgeler uygulamanızı yavaşlatır.

Sonraki adımlar

Uygulamanızı ölçeklendirme ve yüksek performans için tasarlama hakkında daha fazla bilgi edinmek için bkz . Azure Cosmos DB'de bölümleme ve ölçeklendirme.

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 çekirdekleri veya vCPU'ları 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