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

  • Makale

UYGULANANLAR: NoSQL

Ö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çeği artırma ve azaltma, 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ğ

  1. Bağlan ion modu: DirectHttps kullanma

    İstemcinin Azure Cosmos DB'ye nasıl bağlandığının performans üzerinde, özellikle de gözlemlenen istemci tarafı gecikme süresi olarak önemli etkileri olur. İstemci Bağlan ionPolicy'yi (Bağlan ionMode) yapılandırmak için kullanılabilen bir anahtar yapılandırma ayarı vardır. Kullanılabilir iki Bağlan ionModes şunlardır:

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

    2. DoğrudanHttps

      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 dezavantajı, Ağ Geçidi modunun veriler her okunduğu veya Azure Cosmos DB'ye yazıldığının ek bir ağ atlamasını içermesidir. 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.

      Bağlan ionMode, DocumentClient örneğinin oluşturulması sırasında Bağlan ionPolicy parametresiyle 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);

    Diyagramda Azure Cosmos DB bağlantı ilkesi gösterilir.

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

    Diyagram, bilgisayarların orta katman hizmetler aracılığıyla Azure Cosmos DB Hesabına bağlandığı iki bölgede istekleri ve yanıtları gösterir.

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 konak başına 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, Bağlan ionPolicy.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üm) yoğunlaşacağı şekilde bölümlenmişse, sorgunun performansı bu bölümler tarafından performans sorununa neden olur.

    (b) Ayarlama kümesiMaxBufferedItemCount: Paralel sorgu, geçerli sonuç toplu işlemi istemci tarafından işlenirken sonuçları önceden işlemek 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.

    Önceden oluşturma, 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 istek azaltılana kadar yükü artırmanız gerekir. Azaltılırsa, istemci uygulamanın sunucu tarafından belirtilen yeniden deneme aralığı için azaltmada geri çekilmesi gerekir. Geri alma işlemine saygı duymanız, yeniden denemeler arasında beklemeye 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, 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.

  7. Ad tabanlı adresleme kullanma

    Bağlantıların, bağlantıyı oluşturmak için kullanılan tüm kaynakların ResourceId'lerini almaktan kaçınma biçimine dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIdsahip SelfLinks (_self) yerine biçiminde dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> olduğu ad tabanlı adresleme kullanın. Ayrıca, bu kaynaklar yeniden oluşturulurken (büyük olasılıkla aynı ada sahip), önbelleğe almak yararlı olmayabilir.

  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 İlkesi

  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.

Aktarım hızı

  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 ü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 ö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, 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ı.

  2. İş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, 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ı, Bağlan ionPolicy ö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, ö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.

  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.