Azure Cosmos DB Eşitleme Java SDK'sı v2 için performans ipuçları

• Java SDK v4
• Async Java SDK v2
• Java SDK v2'yi eşitleme
• .NET SDK v3
• .NET SDK v2
• Python SDK'sı

Önemli

Bu, Azure Cosmos DB için en son Java SDK'sı değildir ! Projenizi Azure Cosmos DB Java SDK v4'e yükseltmeniz ve ardından Azure Cosmos DB Java SDK v4 performans ipuçları kılavuzunu okumanız gerekir. Yükseltmek için Azure Cosmos DB Java SDK v4'e geçiş kılavuzu ve Reactor vs RxJava kılavuzundaki yönergeleri izleyin.

Bu performans ipuçları yalnızca Azure Cosmos DB Sync Java SDK v2 için geçerlidir. Daha fazla bilgi için lütfen Maven deposunu görüntüleyin.

Önemli

29 Şubat 2024'te Azure Cosmos DB Eşitleme Java SDK'sı v2.x kullanımdan kaldırılacak; SDK ve SDK kullanan tüm uygulamalar çalışmaya devam eder; Azure Cosmos DB, bu SDK için daha fazla bakım ve destek sağlamayı durduracaktır. Azure Cosmos DB Java SDK v4'e geçiş yapmak için yukarıdaki yönergelerin izlenmesini öneririz.

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çek büyütme ve küçültme, tek bir API çağrısı yapmak kadar kolaydır. Daha fazla bilgi edinmek için bkz. Kapsayıcı aktarım hızını sağlama veya veritabanı aktarım hızı sağlama. Ancak Azure Cosmos DB'ye ağ çağrıları aracılığıyla erişildiğinden, Azure Cosmos DB Sync Java SDK v2 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ğ Kurma

1. Bağlantı modu: DirectHttps kullanma

   İstemcinin Azure Cosmos DB'ye nasıl bağlandığı, özellikle de gözlemlenen istemci tarafı gecikme süresi açısından performans üzerinde önemli etkilere sahiptir. ConnectionPolicy istemcisini yapılandırmak için kullanılabilecek bir anahtar yapılandırma ayarı vardır: ConnectionMode. Kullanılabilir iki Bağlantı Modu şunlardır:

   1. Ağ geçidi (varsayılan)

   2. DirectHttps

      Ağ geçidi modu tüm SDK platformlarında desteklenir ve yapılandırılan varsayılan moddur. Uygulamanız katı güvenlik duvarı kısıtlamalarına sahip bir şirket ağı içinde çalışıyorsa ağ geçidi, standart HTTPS bağlantı noktasını ve tek uç noktayı kullandığından en iyi seçenektir. Ancak, performans açısından ödün, Ağ Geçidi modunun her seferinde veriler Azure Cosmos DB'ye okunduğunda veya yazıldığında ek bir ağ geçişi gerektirmesidir. Bu nedenle, DirectHttps modu daha az ağ atlaması nedeniyle daha iyi performans sunar.

      Azure Cosmos DB Sync Java SDK v2, aktarım protokolü olarak HTTPS kullanır. HTTPS, ilk kimlik doğrulaması ve trafiği şifrelemek için TLS kullanır. Azure Cosmos DB Sync Java SDK v2 kullanırken yalnızca HTTPS bağlantı noktası 443'in açık olması gerekir.

      ConnectionMode, ConnectionPolicy parametresiyle DocumentClient örneğinin oluşturulması sırasında yapılandırılır.

   Java SDK V2'yi eşitleme (Maven com.microsoft.azure::azure-documentdb)

   public ConnectionPolicy getConnectionPolicy() {
     ConnectionPolicy policy = new ConnectionPolicy();
     policy.setConnectionMode(ConnectionMode.DirectHttps);
     policy.setMaxPoolSize(1000);
     return policy;
   }
   
   ConnectionPolicy connectionPolicy = new ConnectionPolicy();
   DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);
   

   

2. 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 talebin izlediği güzergaha bağlı olarak bir talepten diğerine 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.

   

SDK Kullanımı

1. 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.

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

   Her DocumentClient örneği iş parçacığı açısından güvenlidir ve Doğrudan Modda çalışırken verimli bağlantı yönetimi ve adres önbelleğe alma işlemi gerçekleştirir. DocumentClient tarafından verimli bağlantı yönetimine ve daha iyi performansa izin vermek için uygulama ömrü boyunca AppDomain başına tek bir DocumentClient örneği kullanılması önerilir.

3. Ağ Geçidi modunu kullanırken her bir sunucu için MaxPoolSize'ı artırma

   Azure Cosmos DB istekleri, Ağ Geçidi modu kullanılırken HTTPS/REST üzerinden yapılır ve ana bilgisayar adı veya IP adresi başına varsayılan bağlantı sınırına tabidir. İstemci kitaplığının Azure Cosmos DB'ye birden çok eşzamanlı bağlantı kullanabilmesi için MaxPoolSize değerini daha yüksek bir değere (200-1000) ayarlamanız gerekebilir. Azure Cosmos DB Sync Java SDK v2'de ConnectionPolicy.getMaxPoolSize için varsayılan değer 100'dür. Değeri değiştirmek için setMaxPoolSize komutunu kullanın.

4. Bölümlenmiş koleksiyonlar için paralel sorguları ayarlama

   Azure Cosmos DB Sync Java SDK sürüm 1.9.0 ve üzeri, bölümlenmiş bir koleksiyonu paralel olarak sorgulamanızı sağlayan paralel sorguları destekler. Daha fazla bilgi için bkz. SDK'larla çalışmayla ilgili kod örnekleri . Paralel sorgular, seri karşıtlarına göre sorgu gecikme süresini ve aktarım hızını geliştirmek için tasarlanmıştır.

   (a) Ayarlama kümesiMaxDegreeOfParallelism: Paralel sorgular, birden çok bölümü paralel olarak sorgulayarak çalışır. Ancak, tek bir bölümlenmiş koleksiyondaki veriler sorguya göre seri olarak getirilir. Bu nedenle, setMaxDegreeOfParallelism kullanarak diğer tüm sistem koşullarının aynı kalması koşuluyla en yüksek performansa sahip sorguya ulaşma şansı en yüksek olan bölüm sayısını ayarlayın. Bölüm sayısını bilmiyorsanız, setMaxDegreeOfParallelism kullanarak yüksek bir sayı ayarlayabilirsiniz ve sistem en düşük (bölüm sayısı, kullanıcı tarafından sağlanan giriş) paralellik en yüksek derecesi olarak seçer.

   Veriler sorguya göre tüm bölümlere eşit olarak dağıtılıyorsa, paralel sorguların en iyi avantajları sağladığını unutmayın. Bölümlenmiş koleksiyon, sorgu tarafından döndürülen verilerin tümünün veya çoğunun birkaç bölümde (en kötü durumda bir bölümde) yoğunlaşacak şekilde bölümlenmişse, sorgunun performansı bu bölümler tarafından sınırlanır.

   (b) setMaxBufferedItemCount Ayarının Yapılandırılması: Paralel sorgu, mevcut sonuç kümesi istemci tarafından işlenirken sonuçları önceden getirmek için tasarlanmıştır. Ön işlem, bir sorgunun genel gecikme süresi iyileştirmesine yardımcı olur. setMaxBufferedItemCount, önceden oluşturulmuş sonuçların sayısını sınırlar. setMaxBufferedItemCount değerini beklenen sonuç sayısına (veya daha yüksek bir sayıya) ayarlayarak, sorgunun ön işlemden en yüksek avantajı almasını sağlar.

   Ön yükleme, MaxDegreeOfParallelism'den bağımsız olarak aynı şekilde çalışır ve tüm bölümlerdeki veriler için tek bir arabellek vardır.

5. getRetryAfterInMilliseconds aralıklarında geri alma uygulama

   Performans testi sırasında, az sayıda isteğin kısıtlanmasına kadar yükü artırmalısınız. Azaltılırsa, istemci uygulama sunucunun belirttiği yeniden deneme aralığı için yük azaltması yapmalıdır. Geri çekilme stratejisine uyum sağlamak, yeniden denemeler arasında beklemek için en az zamanı harcamanızı sağlar. Yeniden deneme ilkesi desteği , Azure Cosmos DB Eşitleme Java SDK'sının 1.8.0 ve üzeri sürümlerine dahildir. Daha fazla bilgi için bkz . getRetryAfterInMilliseconds.

6. İstemci iş yükünüzün ölçeğini genişletme

   Yüksek aktarım hızı düzeylerinde (>50.000 RU/sn) test ediyorsanız, istemci uygulaması, makinenin CPU veya ağ kullanım limitine ulaşması nedeniyle darboğaz oluşturabilir. Bu noktaya ulaşırsanız, istemci uygulamalarınızı birden çok sunucuya yayarak Azure Cosmos DB hesabınızı daha da genişletebilirsiniz.

7. Ad tabanlı adresleme kullanma

   Ad tabanlı adreslemeyi kullanarak, bağlantıları oluşturmak için kullanılan tüm kaynakların ResourceId'lerini almaktan kaçınmak amacıyla dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId formatındaki bağlantılar yerine dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> formatındaki SelfLinks (_self) bağlantılarını kullanmayın. Ayrıca, bu kaynaklar yeniden oluşturulduklarında (muhtemelen aynı adla), önbelleğe almak işe yaramayabilir.

8. Daha iyi performans için sorgular/okuma akışları için sayfa boyutunu ayarlama

   Okuma akışı işlevselliğini kullanarak (örneğin, readDocuments) belgelerin toplu okumasını gerçekleştirirken veya bir SQL sorgusu gönderirken, sonuç kümesi çok büyükse sonuçlar kesimli bir şekilde döndürülür. Varsayılan olarak, sonuçlar 100 öğe veya 1 MB'lık öbekler halinde döndürülür(hangisi önce sınıra isabet edilirse).

   Geçerli tüm sonuçları almak için gereken ağ gidiş dönüşlerinin sayısını azaltmak için , x-ms-max-item-count istek üst bilgisini kullanarak sayfa boyutunu 1000'e kadar artırabilirsiniz. Yalnızca birkaç sonuç görüntülemeniz gereken durumlarda, örneğin kullanıcı arabiriminiz veya uygulama API'niz bir kerede yalnızca 10 sonuç döndürüyorsa, okumalar ve sorgular için kullanılan aktarım hızını azaltmak için sayfa boyutunu da 10'a düşürebilirsiniz.

   Sayfa boyutunu setPageSize yöntemini kullanarak da ayarlayabilirsiniz.

Dizin oluşturma ilkesi

1. 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 kod, "*" joker karakteri kullanılarak belgelerin bir bölümünün tamamının (alt ağaç) dizin oluşturmadan nasıl dışlandığını gösterir.

   Java SDK V2'yi eşitleme (Maven com.microsoft.azure::azure-documentdb)

   Index numberIndex = Index.Range(DataType.Number);
   numberIndex.set("precision", -1);
   indexes.add(numberIndex);
   includedPath.setIndexes(indexes);
   includedPaths.add(includedPath);
   indexingPolicy.setIncludedPaths(includedPaths);
   collectionDefinition.setIndexingPolicy(indexingPolicy);
   

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

Throughput

1. 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 (veya ResourceResponse T< veya FeedResponse><T'deki> eşdeğer RequestCharge özelliğini) inceleyerek bu işlemler tarafından kullanılan istek birimi sayısını ölçün.

   Java SDK V2'yi eşitleme (Maven com.microsoft.azure::azure-documentdb)

   ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);
   
   response.getRequestCharge();
   

   Bu başlıkta döndürülen talep ü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 önceki sorgu 1.000 1 KB'lık belge döndürüyorsa, 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 . İstek birimleri ve istek birimi hesaplayıcısı.

2. Hız sınırlamasını yönet/istek hızı çok yüksek

   İ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, istemci tarafından şu anda dahili olarak 9 olarak ayarlanmış varsayılan yeniden deneme sayısı yeterli olmayabilir; bu durumda istemci, uygulamaya 429 durum koduna sahip bir DocumentClientException oluşturur. Varsayılan yeniden deneme sayısı ConnectionPolicy örneğinde setRetryOptions kullanılarak 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 DocumentClientException 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, performans değerlendirme testleri sırasında, özellikle de gecikme süresini ölçerken, bazen çelişkilere yol açabilir. 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ürelerinde ani artışları önlemek için her işlemin döndürdüğü yükü ölçün ve isteklerin ayrılmış istek oranının altında çalıştığından emin olun. Daha fazla bilgi için İstek birimleri bölümüne bakın.

3. 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.

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.