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

UYGULANDıĞı YER: SQL API

Önemli

Bu makaledeki performans ipuçları yalnızca Azure Cosmos DB Java SDK v4'e aittir. Daha fazla bilgi için lütfen Azure Cosmos DB Java SDK'sı v4Sürüm notları, Mavendeposu ve Azure Cosmos DB Java SDK v4 sorun giderme kılavuzuna bakın. Şu anda v4'den eski bir sürüm kullanıyorsanız v4'e yükseltme yardımı için Azure Cosmos DB Java SDK'sı v4'e geçiş kılavuzuna bakın.

Azure Cosmos DB, garantili gecikme süresi ve aktarım hızı ile sorunsuz bir şekilde ölçeklendiren hızlı ve esnek bir dağıtılmış veritabanıdır. Veritabanınızı Azure veritabanı veritabanıyla ölçeklendirmek için önemli mimari değişiklikleri yapmak veya karmaşık kod Cosmos yok. Ölçeğin ölçeğini genişletme ve genişletme, 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ı üzerinden erişile olduğundan, Azure Cosmos DB Java SDK v4 kullanırken en yüksek performansı elde etmek için gerçekleştirebilirsiniz istemci tarafı iyileştirmeleri vardır.

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

  • Bağlantı modu: Doğrudan modu kullanma

Java SDK varsayılan bağlantı modu doğrudandır. Aşağıda gösterildiği gibi, directMode() veya gatewayMode() yöntemlerini kullanarak istemci oluşturucuda bağlantı modunu yapılandırabilirsiniz. Varsayılan ayarlarla iki modu da yapılandırmak için bağımsız değişken olmadan iki yöntemi de çağırabilirsiniz. Aksi takdirde, bir yapılandırma ayarları sınıf örneğini bağımsız değişken olarak (directMode() için DirectConnectionConfig, gatewayMode() için GatewayConnectionConfig ) iletir. Farklı bağlantı seçenekleri hakkında daha fazla bilgi edinmek için bağlantı modları makalesine bakın.

Java V4 SDK

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


/* Direct mode, default settings */
CosmosAsyncClient clientDirectDefault = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .directMode()
        .buildAsyncClient();

/* Direct mode, custom settings */
DirectConnectionConfig directConnectionConfig = DirectConnectionConfig.getDefaultConfig();

// Example config, do not use these settings as defaults
directConnectionConfig.setMaxConnectionsPerEndpoint(120);
directConnectionConfig.setIdleConnectionTimeout(Duration.ofMillis(100));

CosmosAsyncClient clientDirectCustom = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .directMode(directConnectionConfig)
        .buildAsyncClient();

/* Gateway mode, default settings */
CosmosAsyncClient clientGatewayDefault = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .gatewayMode()
        .buildAsyncClient();

/* Gateway mode, custom settings */
GatewayConnectionConfig gatewayConnectionConfig = GatewayConnectionConfig.getDefaultConfig();

// Example config, do not use these settings as defaults
gatewayConnectionConfig.setProxy(new ProxyOptions(ProxyOptions.Type.HTTP, InetSocketAddress.createUnresolved("your.proxy.addr",80)));
gatewayConnectionConfig.setMaxConnectionPoolSize(150);

CosmosAsyncClient clientGatewayCustom = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .gatewayMode(gatewayConnectionConfig)
        .buildAsyncClient();

/* No connection mode, defaults to Direct mode with default settings */
CosmosAsyncClient clientDefault = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .buildAsyncClient();

DirectMode() yönteminin aşağıdaki nedenle ek bir geçersiz kılması vardır. Veritabanı ve kapsayıcı CRUD gibi denetim düzlemi işlemleri her zaman Ağ Geçidi modunu kullanır; Kullanıcı veri düzlemi işlemleri için Doğrudan modu yapılandırmışsa, denetim düzlemi işlemleri varsayılan Ağ Geçidi modu ayarlarını kullanır. Bu çoğu kullanıcıya uyar. Ancak, veri düzlemi işlemleri için Doğrudan mod ve denetim düzlemi Ağ Geçidi modu parametrelerinin ayarlanabilirliğini isteyen kullanıcılar aşağıdaki directMode() geçersiz kılmayı kullanabilir:

Java V4 SDK

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


/* Independent customization of Direct mode data plane and Gateway mode control plane */
DirectConnectionConfig directConnectionConfig = DirectConnectionConfig.getDefaultConfig();

// Example config, do not use these settings as defaults
directConnectionConfig.setMaxConnectionsPerEndpoint(120);
directConnectionConfig.setIdleConnectionTimeout(Duration.ofMillis(100));

GatewayConnectionConfig gatewayConnectionConfig = GatewayConnectionConfig.getDefaultConfig();

// Example config, do not use these settings as defaults
gatewayConnectionConfig.setProxy(new ProxyOptions(ProxyOptions.Type.HTTP, InetSocketAddress.createUnresolved("your.proxy.addr",80)));
gatewayConnectionConfig.setMaxConnectionPoolSize(150);

CosmosAsyncClient clientDirectCustom = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .directMode(directConnectionConfig,gatewayConnectionConfig)
        .buildAsyncClient();

  • Performans için istemcileri aynı Azure bölgesinde birlikte bulundurma

Mümkün olduğunda Azure veritabanıyla aynı bölgede Azure Cosmos DB'ye çağrı Cosmos. Yaklaşık bir karşılaştırma için, aynı bölgedeki Azure Cosmos DB'ye yapılan çağrılar 1-2 ms içinde tamamlanır, ancak ABD'nin Batı ve Doğu yakası arasındaki gecikme süresi 50 ms >olur. Bu gecikme süresi, istekten Azure veri merkezi sınırına geçerken istek tarafından geçen yollara bağlı olarak istekten isteke farklılık gösterebilir. Mümkün olan en düşük gecikme süresi, çağıran uygulamanın sağlanan Azure veritabanı uç noktasıyla aynı Azure bölgesinde yer Cosmos sağlanır. Kullanılabilir bölgelerin listesi için bkz. Azure Bölgeleri.

Azure Cosmos DB bağlantı ilkesi çizimi

Çok bölgeli bir Azure Cosmos DB hesabıyla etkileşimde olan bir uygulamanın, isteklerin birlikte bulundurılan bir bölgeye gidiyor olduğundan emin olmak için tercih edilen konumları yapılandırması gerekir.

  • Daha düşük gecikme süresi için Azure VM'niz üzerinde Hızlandırılmış Ağ İletişimini etkinleştirin.

Performansı en üst düzeye çıkarmak için Windows (yönergeler için tıklayın) veya Linux (yönergeler için tıklayın) Azure VM'sinde Hızlandırılmış Ağ'ı etkinleştirmek için yönergeleri izlemeniz önerilir.

Hızlandırılmış ağ olmadan, Azure VM'niz ve diğer Azure kaynakları arasında geçiş yapılan IO, sanal makine ile ağ kartı arasında bulunan bir konak ve sanal anahtar aracılığıyla gereksiz yere yönlendirildi. Ana bilgisayar ve sanal anahtarın veri yolu içinde satır içi olması, iletişim kanalında gecikme süresini ve gecikmeyi artırarak VM'den CPU döngülerini de çalar. Hızlandırılmış ağ ile, VM arabirimleri aracı olmadan doğrudan NIC ile; Konak ve sanal anahtar tarafından işlene tüm ağ ilkesi ayrıntıları artık NIC'de donanımda işlanıyor; konak ve sanal anahtar atlanır. 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ştiren daha tutarlı gecikme süresi ve daha az CPU kullanımı elde edin.

Sınırlamalar: Hızlandırılmış ağ, VM işletim sistemi üzerinde desteklenmiş olmalıdır ve yalnızca VM durdurulmuş ve bırakıldıktan sonra etkinleştirilebilir. VM, sanal makine ile Azure Resource Manager.

Diğer ayrıntılar için Windows Linux yönergelerine bakın.

SDK kullanımı

  • En son SDK'yı yükleme

Azure Cosmos DB SDK'ları, en iyi performansı sağlamak için sürekli geliştirmektedir. En son SDK'yı Cosmos geliştirmeleri gözden geçirmek için Azure Cosmos DB SDK sayfalarına bakın.

  • Tek bir Azure Cosmos DB istemcisini uygulama ömrü boyunca 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ğe alma işlemi gerçekleştirir. Azure Cosmos DB istemcisinin verimli bağlantı yönetimine ve daha iyi performansa olanak sağlamak için, uygulamanın kullanım ömrü boyunca AppDomain başına Tek bir Azure Cosmos DB istemcisi örneği kullanılması önerilir.

  • Uygulamanıza gereken en düşük tutarlılık düzeyini kullanın

Bir CosmosClient sanız, açıkça ayarlanmaması için kullanılan varsayılan tutarlılık Oturum'dır. Uygulama mantığınız oturum tutarlılığı gerektir gerekmiyorsa Tutarlılık'a Son olarak ayarlayın. Not: Azure veritabanı değişiklik akışı işlemcisini kullanan uygulamalarda en azından Oturum tutarlılığı Cosmos önerilir.

  • Sağlanan aktarım hızını en üst düzeye çıkarma için Zaman Uyumsuz API'yi kullanma

Azure Cosmos DB Java SDK v4, Sync ve Async olmak için iki API paketler. Kabaca Async API'si SDK işlevselliğini, Eşitleme API'si ise 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'nin ve yalnızca Eşitleme olan ve tamamen ayrı bir uygulamaya sahip olan eski Azure Cosmos DB Sync Java SDK v2'nin aksinedir.

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

Zaman uyumsuz API engelleyici olmayan G/B'yi kullanır ve hedefiniz Azure Cosmos DB'ye istekler sunarken aktarım hızını en üst düzeye çıkarma ise en iyi seçenektir.

Her isteğin yanıtını engelleyen bir API'ye ihtiyacınız varsa veya zaman uyumlu işlem uygulamanıza baskın olan paradigma ise Eşitleme API'sini kullanmak doğru seçim olabilir. Örneğin, verileri bir mikro hizmet uygulamasında Azure Cosmos DB'de kalıcı olarak bulundurarak aktarım hızının kritik öneme sahip olmadığını gösterirken Eşitleme API'sini kullanabilirsiniz.

Eşitleme API'si aktarım hızının istek yanıt süresi artarak düşebilirken Async API'nizin donanımınız için tam bant genişliği özelliklerini doygunluğa düşürebilir.

Coğrafi birlikte konumlandırma Eşitleme API'sini kullanırken size daha yüksek ve daha tutarlı aktarım hızı sağlar (bkz. Performans için istemcileri aynı Azurebölgesinde birlikte bulundurma) ama yine de Async API ulaşılabilir aktarım hızını aşması beklenmiyor.

Bazı kullanıcılar, Azure Cosmos DB Java SDK v4 Async API'sini uygulamak için kullanılan Reactive Akışlar çerçevesi olan Project Reactor'ıda tanımamış olabilir. Bu bir sorunsa, giriş niteliğindeki Reactor Desen Kılavuzu'mızı okumanız ve daha sonra kendinizi tanımanız için bu Reaktif Programlamaya Giriş'e göz atmanız önerilir. Azure Cosmos DB'yi zaten bir Async arabirimiyle kullandıysanız ve azure Cosmos DB Async Java SDK v2'yi kullandıysanız, ReactiveX / RxJava'yı biliyor ama Project Reactor'da nelerin değiştiğini tam olarak bile bileyelisiniz. Bu durumda, bilgi sahibi olmak için lütfen Reactor ve RxJava Kılavuzumuza göz atabilirsiniz.

Aşağıdaki kod parçacıkları, Async API veya Eşitleme API'si işlemi için Azure Cosmos DB istemcinizi başlatmayı göstermektedir:

Java V4 SDK

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


CosmosAsyncClient client = new CosmosClientBuilder()
        .endpoint(HOSTNAME)
        .key(MASTERKEY)
        .consistencyLevel(CONSISTENCY)
        .buildAsyncClient();

  • ConnectionPolicy'i ayarlama

Varsayılan olarak, Azure Cosmos DB Java SDK v4 kullanılırken DOĞRUDAN mod Cosmos DB istekleri TCP üzerinden yapılır. Dahili Doğrudan modu, ağ kaynaklarını dinamik olarak yönetmek ve en iyi performansı elde etmek için özel bir mimari kullanır.

Azure Cosmos DB Java SDK v4'te Doğrudan mod, çoğu iş yüküyle veritabanı performansını geliştirmek için en iyi seçenektir.

  • Doğrudan moda genel bakış

Doğrudan mod mimarisinin çizimi

Doğrudan modda çalışan istemci tarafı mimarisi, Azure Cosmos DB çoğaltmalarına öngörülebilir ağ kullanımı ve çok Cosmos sağlar. Yukarıdaki diyagramda, Doğrudan modun istemci isteklerini Cosmos DB arka uçta çoğaltmalara yönlendirmesi göstermektedir. Doğrudan mod mimarisi, veritabanı çoğaltması başına istemci tarafında en fazla 10 Kanal ayırır. Kanal, 30 istek derinliğinde olan istek arabelleğinin önünde bulunan bir TCP bağlantısıdır. Çoğaltmaya ait Kanallar, çoğaltmanın Hizmet Uç Noktası tarafından gerektiğinde dinamik olarak ayrılır. Kullanıcı Doğrudan modda bir istekte bulunuyorsa TransportClient, isteği bölüm anahtarına göre uygun hizmet uç noktasına yönlendirmektedir. İstek Kuyruğu, istekleri Hizmet Uç Noktası'nın önünde arabelleğe alır.

  • Doğrudan mod için yapılandırma seçenekleri

varsayılan olmayan doğrudan mod davranışı isteniyorsa, bir directconnectionconfig örneği oluşturun ve özelliklerini özelleştirin, ardından özelleştirilmiş özellik örneğini Azure Cosmos DB istemci oluşturucusunun directmode () metoduna geçirin.

Bu yapılandırma ayarları yukarıda ele alınan temeldeki doğrudan mod mimarisinin davranışını denetler.

İlk adım olarak aşağıdaki önerilen yapılandırma ayarlarını kullanın. Bu Directconnectionconfig SEÇENEKLERI, SDK performansını beklenmeyen yollarla etkileyebilecek gelişmiş yapılandırma ayarlarıdır; avantajları anlamak çok rahat ve kesinlikle gerekli olmadığı müddetçe, kullanıcıların bunları değiştirmelerini öneririz. bu konuda sorun yaşıyorsanız lütfen Azure Cosmos DB ekibine başvurun.

Yapılandırma seçeneği Varsayılan
ıdboşta ConnectionTimeout "PT0"
maxConnectionsPerEndpoint "130"
connectTimeout "PT5S"
ıdtımeendpointtimeout PT1H
maxRequestsPerConnection ila
  • Bölümlenmiş koleksiyonlar için Paralel sorguları ayarlama

Azure Cosmos DB Java SDK v4 paralel sorguları destekler ve bu, bölümlenmiş bir koleksiyonu paralel olarak sorgulamanızı sağlar. daha fazla bilgi için bkz. Azure Cosmos DB Java SDK 'sı v4 ile çalışma ile ilgili kod örnekleri . Paralel sorgular, kendi seri karşılarındaki sorgu gecikmesini ve aktarım hızını artırmak için tasarlanmıştır.

  • Setmaxdegreeofparalellik ayarlama:

Paralel sorgular birden çok bölümü paralel olarak sorgulayarak çalışır. Ancak, tek bir bölümlenmiş koleksiyondaki veriler, sorguya göre işlem içine alınır. Bu nedenle, en iyi performansı elde etmek için en yüksek performansa sahip bölüm sayısını ayarlamak için Setmaxdegreeofparalellik kullanın, diğer tüm sistem koşulları aynı kalır. Bölüm sayısını bilmiyorsanız, yüksek bir sayı ayarlamak için Setmaxdegreeofparalellik kullanabilirsiniz ve sistem en az paralellik derecesi olarak en düşük (bölüm sayısı, Kullanıcı tarafından girilen giriş) değerini seçer.

Verilerin sorguya göre tüm bölümler arasında eşit bir şekilde dağıtılması halinde paralel sorguların en iyi avantajları ürettiğine dikkat edin. Bölümlenmiş koleksiyon, bir sorgu tarafından döndürülen verilerin tümünün veya çoğunluğunun birkaç bölümde (en kötü durumda bir bölüm) yoğunlaşarak bir şekilde bölümlenmişse, sorgunun performansı bu bölümler tarafından bottlenecked olacaktır.

  • SetMaxBufferedItemCount ayarlama:

Paralel sorgu, geçerli sonuç toplu işi istemci tarafından işlendiği sırada sonuçları önceden getirmek üzere tasarlanmıştır. Önceden getirme, bir sorgunun genel gecikme artışında yardımcı olur. setMaxBufferedItemCount, önceden getirilen sonuçların sayısını sınırlar. SetMaxBufferedItemCount değeri döndürülen beklenen sonuç sayısına (veya daha yüksek bir sayıya) ayarlandığında sorgunun ön alma işleminden en fazla avantaj almasına olanak sağlar.

Önceden getirme, Maxdegreeofparalelliği ne olursa olsun aynı şekilde çalışıyor ve tüm bölümlerdeki veriler için tek bir arabellek vardır.

  • İstemcinizi genişletme-iş yükü

Yüksek aktarım hızı düzeylerinde test ediyorsanız, makine CPU veya ağ kullanımında kullanıma hazır hale geldiği için istemci uygulama performans sorunlarına neden olabilir. bu noktaya ulaştığınızda, istemci uygulamalarınızı birden çok sunucu arasında ölçeklendirerek Azure Cosmos DB hesabını daha fazla göndermeye devam edebilirsiniz.

Thumb 'in iyi bir kuralı, belirli bir sunucuda %50 CPU kullanımını aşmamak, gecikme süresini düşük tutmak için >.

  • Daha iyi performans için, sorguların/okunan akışların sayfa boyutunu ayarlayın

belgeleri oku (örneğin, readItems) kullanarak veya bir SQL sorgusu (queryıtems) verirken belge okuma işlemi gerçekleştirirken sonuçlar, sonuç kümesi çok büyükse, bölümlenmiş bir biçimde döndürülür. Varsayılan olarak, sonuçlar 100 öğe veya 1 MB Öbekle döndürülür, bu sınır ilk önce dönüştürülür.

uygulamanızın Azure Cosmos DB bir sorgu sağladığını ve uygulamanızın, görevi tamamlaması için tam sorgu sonuçları kümesi gerektirdiğini varsayalım. Tüm geçerli sonuçları almak için gereken ağ gidiş dönüşlerin sayısını azaltmak için, x-MS-Max-item-Count istek üst bilgisi alanını ayarlayarak sayfa boyutunu artırabilirsiniz.

  • Tek bölümlü sorgular için, x-MS-Max-item-Count alan değerinin-1 olarak ayarlanması (sayfa boyutunda sınır olmaması), sorgu yanıtı sayfalarının sayısını en aza indirerek gecikme süresini en üst düzeye çıkarır: tam sonuç kümesi tek bir sayfada dönecektir ya da sorgu zaman aşımı aralığından daha uzun sürerse, tam sonuç kümesi mümkün olan en az sayıda sayfaya döndürülür. Bu, istek gidiş dönüş süresinin katlarına kaydedilir.

  • Çapraz bölüm sorguları için, x-MS-Max-item-Count alanını-1 olarak ayarlamak ve sayfa boyut sınırı risklerini kaldırmak, SDK 'yı yönetilemez sayfa boyutlarına göre kaldırır. Çapraz bölüm söz konusu olduğunda, gecikme süresini azaltmak için sayfa boyutu sınırını büyük ancak büyük olasılıkla 1000 olan büyük ancak sınırlı bir değere yükseltmeyi öneririz.

Bazı uygulamalarda, sorgu sonuçlarının tam kümesini gerektirmeyebilirsiniz. Örneğin, Kullanıcı arabiriminiz veya uygulama API 'niz aynı anda yalnızca 10 sonuç döndürürse, okuma ve sorgular için tüketilen aktarım hızını azaltmak için sayfa boyutunu 10 ' a da azaltabilirsiniz.

Ayrıca, REST üst bilgi alanını doğrudan değiştirmek yerine bypage yönteminin tercih edilen sayfa boyutu bağımsız değişkenini de ayarlayabilirsiniz. X-MS-Max-item-Count veya bypage 'in tercih edilen sayfa boyutu bağımsız değişkeninin mutlak bir gereksinim değil yalnızca sayfa boyutunda bir üst sınır ayarlamadığını unutmayın; bu nedenle, tercih ettiğiniz sayfa boyutundan daha küçük olan Azure Cosmos DB geri dönüş sayfaları görebilirsiniz.

  • Uygun zamanlayıcıyı kullan (olay döngüsü GÇ ağ parçacıklarının çalınmasını önleyin)

Azure Cosmos DB Java SDK 'sının zaman uyumsuz işlevselliği, netty engellemeyen 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ığını (makinenizin sahip olduğu CPU çekirdekleri) kullanır. API tarafından döndürülen Flox, paylaşılan GÇ olay döngüsü Netty iş parçacıklarından birindeki sonucu yayar. 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ığı üzerinde CPU yoğun iş veya engelleme işlemi yapıldığında kilitlenme olabilir veya SDK verimlilik önemli ölçüde azalabilir.

Örneğin, aşağıdaki kod olay döngüsü GÇ Netty iş parçacığı üzerinde yoğun bir CPU kullanımı işi yürütür:

Java SDK v4 (Maven com. Azure:: Azure-Cosmos) zaman uyumsuz API


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, CPU yoğun işi gerçekleştirmek istiyorsanız olay döngüsü GÇ ağ parçacığında bunu yapmaktan kaçınmalısınız. Bunun yerine, aşağıda gösterildiği gibi, işinizi çalıştırmak için kendi iş parçacığını sağlamak üzere kendi Scheduler ' u sağlayabilirsiniz (gerektirir import reactor.core.scheduler.Schedulers ).

Java SDK v4 (Maven com. Azure:: Azure-Cosmos) zaman uyumsuz API


Mono<CosmosItemResponse<CustomPOJO>> createItemPub = asyncContainer.createItem(item);
createItemPub
        .subscribeOn(Schedulers.elastic())
        .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();
                });

Çalışmanızın türüne bağlı olarak, çalışmanız için uygun olan yeniden aktör zamanlayıcısını kullanmanız gerekir. Buradan okuyun Schedulers .

java sdk 'sı v4 Azure Cosmos DB hakkında daha fazla bilgi için lütfen GitHub üzerinde java monodeposunun Azure SDK 'sının Cosmos DB dizininebakın.

  • Uygulamanızdaki günlük ayarlarını iyileştirin

Çeşitli nedenlerle, yüksek istek aktarım hızı üreten bir iş parçacığında günlük kaydı eklemeniz gerekebilir. Amacınız, bu iş parçacığı tarafından oluşturulan isteklerle bir kapsayıcının sağlanmış iş verimini tamamen kısaltmak isterse, günlüğe kaydetme iyileştirmeleri performansı büyük ölçüde iyileştirebilir.

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

Zaman uyumlu bir günlükçü gecikmesi, istek oluşturma iş parçacığınız için genel gecikme süresi hesaplamasına yönelik bir etken olması halinde. Yüksek performanslı uygulama iş parçacıklarından günlüğe kaydetme ek yükünü ayırmak için log4j2 gibi bir zaman uyumsuz günlükçü önerilir.

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

Netty kitaplığı günlüğü geveze ve ek CPU maliyetlerinden kaçınmak için kapalı olması gerekir (yapılandırmada oturum açmayı gizleme yeterli olmayabilir). Hata ayıklama modunda değilseniz, netty 'ın günlüğünü tamamen devre dışı bırakın. Bu nedenle, netty 'den kaynaklanan ek CPU maliyetlerini kaldırmak için Log4J kullanıyorsanız org.apache.log4j.Category.callAppenders() , 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 açık dosyaları kaynak sınırı

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

ulimit -a

Açık dosya (nofile) sayısı, yapılandırılmış bağlantı havuzu boyutunuz ve işletim sistemi tarafından diğer açık dosyalar için yeterli yere yetecek kadar büyük olmalıdır. Daha büyük bir bağlantı havuzu boyutu için izin verecek şekilde değiştirilebilir.

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

vim /etc/security/limits.conf

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

* - nofile 100000
  • Nokta yazma işlemlerinde bölüm anahtarı belirtin

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

Java SDK v4 (Maven com. Azure:: Azure-Cosmos) zaman uyumsuz API

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

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

Java SDK v4 (Maven com. Azure:: Azure-Cosmos) zaman uyumsuz 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ıklamalıdır.

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 dizin oluşturma ilkesi, dizin oluşturma yollarını (setıncludedpaths ve setexcludedpaths) kullanarak hangi belge yollarının dizine eklenmesini veya dışlanacağını belirtmenize olanak tanır. Dizin oluşturma yollarının kullanımı, sorgu desenlerinin önceden bildiği senaryolar için gelişmiş yazma performansı ve daha düşük dizin depolaması sunabilir, dizin oluşturma maliyetleri doğrudan dizinli benzersiz yolların sayısıyla bağıntılı olur. Örneğin, aşağıdaki kod, "*" joker karakterini kullanarak, belgelerin tüm bölümlerinin (alt ağaç olarak da bilinir) nasıl ekleneceğini ve dışlanacağını gösterir.

Java SDK v4 (Maven com. Azure:: Azure-Cosmos)


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ı

  • Düşük istek birimleri/ikinci kullanım için ölçme ve ayarlama

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

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

Bir sorgunun karmaşıklığı, bir işlem için kaç istek biriminin tüketildiğini etkiler. Koşulların sayısı, koşulların doğası, UDF sayısı ve kaynak veri kümesinin boyutu, sorgu işlemlerinin maliyetini etkiler.

Herhangi bir işlemin (oluşturma, güncelleştirme veya silme) yükünü ölçmek için, bu işlemler tarafından tüketilen istek birimi sayısını ölçmek üzere x-MS-Request-şarj üst bilgisini inceleyin. Ayrıca, Resourceres, FeedResponse içindeki eşdeğer Requestücretözelliğine de bakabilirsiniz <T> <T> .

Java SDK v4 (Maven com. Azure:: Azure-Cosmos) zaman uyumsuz 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ın bir bölümü. Örneğin, sağlanan 2000 RU/sn varsa ve önceki sorgu 1000 1KB-belgeler döndürürse, işlem maliyeti 1000 ' dir. Bu nedenle, bir saniye içinde sunucu, sonraki istekleri sınırlayan orandan önce yalnızca iki istek için geçerlidir. Daha fazla bilgi için bkz. İstek birimleri ve istek birimi Hesaplayıcısı.

  • Tanıtıcı hız sınırlandırma/istek hızı çok büyük

Bir istemci bir hesap için ayrılan aktarım hızını aşmaya çalıştığında, sunucuda bir performans düşüşü olmaz ve ayrılan düzeyin ötesinde üretilen iş kapasitesi yoktur. Sunucu, isteği RequestRateTooLarge (HTTP durum kodu 429) ile sona erpreemptively ve kullanıcının isteği yeniden denemeden önce beklemesi gereken süreyi milisaniye olarak 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, sunucu tarafından belirtilen yeniden deneme üst bilgisine göre bu yanıtı dolaylı olarak yakalar ve isteği yeniden dener. Hesabınız birden çok istemci tarafından aynı anda erişilmediği takdirde, sonraki yeniden deneme başarılı olur.

İstek hızının sürekli olarak birden fazla istemciniz varsa, bu, şu anda istemci tarafından dahili olarak 9 olarak ayarlanmış olan varsayılan yeniden deneme sayısı çalışmayabilir; Bu durumda, istemci, uygulama 429 durum kodu ile Cosmosclientexception oluşturur. Varsayılan yeniden deneme sayısı, ConnectionPolicy örneğinde setRetryOptions kullanılarak değiştirilebilir. Varsayılan olarak, istek hızının üzerinde çalışmaya devam etmesi durumunda 429 durum kodu ile Cosmosclientexception , 30 saniyelik birikimli bir bekleme süresi dolduktan sonra döndürülür. Bu durum, geçerli yeniden deneme sayısı en fazla yeniden deneme sayısından az olduğunda bile, varsayılan olarak 9 veya Kullanıcı tanımlı bir değer olmalıdır.

Otomatik yeniden deneme davranışı, çoğu uygulama için esneklik ve kullanılabilirliği artırmaya yardımcı olmakla birlikte, özellikle gecikmeyi ölçirken performans kıyaslamaları yapılırken gürültü 'ye gelebilir. Deneme sunucu tarafından azaldıysanız, istemci SDK 'sının sessizce yeniden denenmesine neden olursa istemci gözlenen gecikme süresi izlenir. Performans denemeleri sırasında gecikme sürelerini önlemek için, her bir işlem tarafından döndürülen ücreti ölçün ve isteklerin ayrılan 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 dosyalar tasarlayın

Belirli bir işlemin istek ücreti (istek işleme maliyeti), belgenin boyutuyla doğrudan bağıntılı olur. Büyük belgelerle ilgili işlemler, küçük belgeler için işlemlerden daha fazla maliyetlidir. İdeal olarak, uygulamanızın ve iş akışlarının boyutunu, öğe boyutunuzu ~ 1KB veya benzer bir sıra ya da büyüklük olacak şekilde mimarın. Gecikme süresine duyarlı uygulamalar için büyük öğelerin kaçınılması gerekir, çok MB 'lık belgeler uygulamanızı yavaşlatır.

Sonraki adımlar

uygulamanızı ölçek ve yüksek performans için tasarlama hakkında daha fazla bilgi için, bkz. Azure Cosmos DB bölümleme ve ölçeklendirme.

Azure Cosmos DB bir geçişe yönelik kapasite planlaması yapılmaya çalışılıyor musunuz? Kapasite planlaması için mevcut veritabanı kümeniz hakkında bilgi kullanabilirsiniz.