Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Önemli
Bu makaledeki performans ipuçları yalnızca Azure Cosmos DB Java SDK v4 içindir. Daha fazla bilgi için Azure Cosmos DB Java SDK v4 Sürüm notları, Maven deposu 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ükseltmeyle ilgili yardım için Bkz. Azure Cosmos DB Java SDK 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çeklendirmeyi artırmak veya azaltmak, 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ğ Kurma
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.
Ç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'niz ile diğer Azure kaynakları arasında geçen GÇ, VM ile ağ kartı arasında yer alan bir ana bilgisayar ve sanal anahtar üzerinden yönlendirilebilir. Ana bilgisayar ve sanal anahtarın veri yolu boyunca aynı anda bulunması, yalnızca iletişim kanalındaki gecikmeyi ve zaman aralığı dalgalanmasını artırmakla kalmaz, 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'de hızlandırılmış ağ etkinleştirilmedi.
Daha fazla bilgi için Windows ve Linux yönergelerine bakın.
Yüksek ulaşılabilirlik
Azure Cosmos DB'de yüksek kullanılabilirliği yapılandırma hakkında genel yönergeler için bkz . Azure Cosmos DB'de yüksek kullanılabilirlik.
Veritabanı platformunda iyi bir temel kurulumun yanı sıra, Java SDK'sının kendisinde uygulanabilen ve kesinti senaryolarında yardımcı olabilecek belirli teknikler vardır. Eşik tabanlı kullanılabilirlik stratejisi ve bölüm düzeyi devre kesici iki önemli stratejidir.
Bu teknikler, varsayılan olarak SDK'da yerleşik olarak bulunan bölgeler arası yeniden deneme özelliklerinin üzerine ve ötesine geçerek belirli gecikme süresi ve kullanılabilirlik güçlükleriyle başa çıkmak için gelişmiş mekanizmalar sağlar. bu stratejiler, istek ve bölüm düzeylerindeki olası sorunları proaktif olarak yöneterek, özellikle yüksek yük veya düşük koşullar altında uygulamanızın dayanıklılığını ve performansını önemli ölçüde geliştirebilir.
Eşik tabanlı kullanılabilirlik stratejisi
Eşik tabanlı kullanılabilirlik stratejisi, ikincil bölgelere paralel okuma istekleri göndererek (içinde preferredRegionstanımlandığı gibi) ve en hızlı yanıtı kabul ederek kuyruk gecikme süresini ve kullanılabilirliğini geliştirebilir. Bu yaklaşım, bölgesel kesintilerin veya yüksek gecikme süresi koşullarının uygulama performansı üzerindeki etkisini önemli ölçüde azaltabilir. Ayrıca, hem geçerli okuma bölgesinde hem de tercih edilen uzak bölgelerde bağlantıları ve önbellekleri ısıtarak performansı daha da artırmak için proaktif bağlantı yönetimi kullanılabilir.
Örnek yapılandırma:
// Proactive Connection Management
CosmosContainerIdentity containerIdentity = new CosmosContainerIdentity("sample_db_id", "sample_container_id");
int proactiveConnectionRegionsCount = 2;
Duration aggressiveWarmupDuration = Duration.ofSeconds(1);
CosmosAsyncClient clientWithOpenConnections = new CosmosClientBuilder()
.endpoint("<account URL goes here")
.key("<account key goes here>")
.endpointDiscoveryEnabled(true)
.preferredRegions(Arrays.asList("East US", "East US 2", "West US"))
.openConnectionsAndInitCaches(new CosmosContainerProactiveInitConfigBuilder(Arrays.asList(containerIdentity))
.setProactiveConnectionRegionsCount(proactiveConnectionRegionsCount)
//setting aggressive warmup duration helps in cases where there is a high no. of partitions
.setAggressiveWarmupDuration(aggressiveWarmupDuration)
.build())
.directMode()
.buildAsyncClient();
CosmosAsyncContainer container = clientWithOpenConnections.getDatabase("sample_db_id").getContainer("sample_container_id");
int threshold = 500;
int thresholdStep = 100;
CosmosEndToEndOperationLatencyPolicyConfig config = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(3))
.availabilityStrategy(new ThresholdBasedAvailabilityStrategy(Duration.ofMillis(threshold), Duration.ofMillis(thresholdStep)))
.build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(config);
container.readItem("id", new PartitionKey("pk"), options, JsonNode.class).block();
// Write operations can benefit from threshold-based availability strategy if opted into non-idempotent write retry policy
// and the account is configured for multi-region writes.
options.setNonIdempotentWriteRetryPolicy(true, true);
container.createItem("id", new PartitionKey("pk"), options, JsonNode.class).block();
Nasıl çalışır:
İlk İstek: T1 zamanında, birincil bölgeye (örneğin, Doğu ABD) bir okuma isteği yapılır. SDK, 500 milisaniyeye (
thresholddeğer) kadar yanıt bekler.İkinci İstek: Birincil bölgeden 500 milisaniye içinde yanıt alınmazsa, bir sonraki tercih edilen bölgeye paralel istek gönderilir (örneğin, Doğu ABD 2).
Üçüncü İstek: Birincil bölge veya ikincil bölge 600 milisaniye (500 ms + 100 ms,
thresholdStepdeğer) içinde yanıt vermezse, SDK tercih edilen üçüncü bölgeye (örneğin, Batı ABD) başka bir paralel istek gönderir.En Hızlı Yanıt Kazanır: İlk olarak hangi bölge yanıt verirse yanıt kabul edilir ve diğer paralel istekler yoksayılır.
Proaktif bağlantı yönetimi, öncelikli bölgelerdeki kapsayıcıların bağlantılarını ve önbelleklerini ısıtarak, çok bölgeli kurulumlardaki yük devretme senaryoları veya yazma işlemleri için soğuk başlangıç gecikmesini azaltmaya yardımcı olur.
Bu strateji, belirli bir bölgenin yavaş olduğu veya geçici olarak kullanılamadığı senaryolarda gecikme süresini önemli ölçüde artırabilir, ancak paralel bölgeler arası istekler gerektiğinde istek birimleri açısından daha fazla maliyete neden olabilir.
Uyarı
İlk tercih edilen bölge geçici olmayan bir hata durum kodu (örneğin, belge bulunamadı, yetkilendirme hatası, çakışma vb.) döndürürse, kullanılabilirlik stratejisinin bu senaryoda herhangi bir avantajı olmayacağından işlemin kendisi hızlı başarısız olur.
Bölüm düzeyi devre kesici
Bölüm düzeyi devre kesici, iyi durumda olmayan fiziksel bölümlere yönelik istekleri izleyerek ve kısa devre yaparak kuyruk gecikme süresini ve yazma kullanılabilirliğini geliştirir. Bilinen sorunlu bölümlerden kaçınarak ve istekleri daha sağlıklı bölgelere yönlendirerek performansı artırır.
Örnek yapılandırma:
Bölüm düzeyi devre kesiciyi etkinleştirmek için:
System.setProperty(
"COSMOS.PARTITION_LEVEL_CIRCUIT_BREAKER_CONFIG",
"{\"isPartitionLevelCircuitBreakerEnabled\": true, "
+ "\"circuitBreakerType\": \"CONSECUTIVE_EXCEPTION_COUNT_BASED\","
+ "\"consecutiveExceptionCountToleratedForReads\": 10,"
+ "\"consecutiveExceptionCountToleratedForWrites\": 5,"
+ "}");
Kullanılamayan bölgeleri denetlemeye yönelik arka plan işlemi sıklığını ayarlamak için:
System.setProperty("COSMOS.STALE_PARTITION_UNAVAILABILITY_REFRESH_INTERVAL_IN_SECONDS", "60");
Bir bölümün kullanılamaz durumda kalabileceği süreyi ayarlamak için:
System.setProperty("COSMOS.ALLOWED_PARTITION_UNAVAILABILITY_DURATION_IN_SECONDS", "30");
Nasıl çalışır:
İzleme Hataları: SDK, belirli bölgelerdeki tek tek bölümler için terminal hatalarını (örneğin, 503'ler, 500'ler, zaman aşımları) izler.
Kullanılamıyor Olarak İşaretleme: Bölgedeki bir bölüm yapılandırılmış hata eşiğini aşarsa , "Kullanılamıyor" olarak işaretlenir. Bu bölüme yönelik sonraki istekler kısa devredir ve diğer daha sağlıklı bölgelere yönlendirilir.
Otomatik Kurtarma: Arka plan iş parçacığı, kullanılamayan bölümleri düzenli aralıklarla denetler. Belirli bir süre sonra, bu bölümler belirsiz bir şekilde "HealthyTentative" olarak işaretlenir ve kurtarmayı doğrulamak için test isteklerine tabi tutulur.
Sistem Durumu Yükseltme/İndirgeme: Bu test isteklerinin başarısına veya başarısızlığına bağlı olarak, bölümün durumu "Sağlıklı" olarak yükseltilir veya bir kez daha "Kullanılamıyor" durumuna indirilir.
Bu mekanizma, bölüm durumunu sürekli izlemeye yardımcı olur ve sorunlu bölümler tarafından tıkanmadan isteklerin en düşük gecikme süresi ve en yüksek kullanılabilirlik ile sunulduğunu güvence altına alır.
Uyarı
Devre kesici yalnızca çok bölgeli yazma hesapları için geçerlidir; çünkü bir bölüm Unavailable olarak işaretlendiğinde, hem okuma hem de yazma işlemleri tercih edilen bir sonraki bölgeye taşınır. Bu, aynı istemci örneğinden farklı bölgelerden okuma ve yazma işlemleri yapılmasını önlemektir; bu yanlış bir uygulamadır.
Önemli
Bölüm Düzeyi Devre Kesici'yi etkinleştirmek için Java SDK'sının 4.63.0 veya üzeri bir sürümünü kullanıyor olmanız gerekir.
Kullanılabilirlik iyileştirmelerini karşılaştırma
Eşik tabanlı kullanılabilirlik stratejisi:
- Avantaj: İkincil bölgelere paralel okuma istekleri göndererek kuyruk gecikme süresini azaltır ve ağ zaman aşımlarına neden olan istekleri önceden başlatarak kullanılabilirliği artırır.
- Dengelenme: Diğer bölgeler arası paralel isteklerin varlığı nedeniyle devre kesiciye kıyasla, yalnızca eşiklerin aşıldığı dönemlerde ek RU (İstek Birimleri) maliyetlerine neden olur.
- Kullanım Örneği: Gecikme süresini azaltmanın kritik öneme sahip olduğu ve bazı ek maliyetlerin (HEM RU ücreti hem de istemci CPU baskısı açısından) kabul edilebilir olduğu okuma yoğunluklu iş yükleri için idealdir. İdempotent olmayan yazma yeniden deneme politikası tercih edilirse ve hesapta çok bölgeli yazmalar varsa, yazma işlemleri de yararlı olabilir.
Bölüm düzeyi devre kesici:
- Avantaj: İyi durumda olmayan bölümlerden kaçınarak isteklerin daha sağlıklı bölgelere yönlendirilmesini sağlayarak kullanılabilirliği ve gecikme süresini artırır.
- Takas: Daha fazla RU maliyetine neden olmaz, ancak yine de ağ zaman aşımlarına yol açacak istekler için bazı başlangıç kullanılabilirlik kayıplarına izin verebilir.
- Kullanım Örneği: Özellikle aralıklı olarak iyi durumda olmayan bölümlerle ilgilenirken tutarlı performansın önemli olduğu yoğun yazma veya karma iş yükleri için idealdir.
Okuma ve yazma kullanılabilirliğini geliştirmek ve kuyruk gecikme süresini azaltmak için her iki strateji de birlikte kullanılabilir. Bölüm Düzeyi Devre Kesici, paralel istekler gerçekleştirmeye gerek kalmadan çoğaltmaların yavaş gerçekleştirilmesine neden olabilecekler de dahil olmak üzere çeşitli geçici hata senaryolarını işleyebilir. Ek olarak, Ek RU maliyeti kabul edilebilirse Eşik Tabanlı Kullanılabilirlik Stratejisi eklemek kuyruk gecikme süresini daha da en aza indirir ve kullanılabilirlik kaybını ortadan kaldırır.
Geliştiriciler bu stratejileri uygulayarak uygulamalarının dayanıklı kalmasını, yüksek performansı korumasını ve bölgesel kesintiler veya yüksek gecikme süresi koşulları sırasında bile daha iyi bir kullanıcı deneyimi sunmasını sağlayabilir.
Bölge kapsamlı oturum tutarlılığı
Genel Bakış
Genel olarak tutarlılık ayarları hakkında daha fazla bilgi için bkz . Azure Cosmos DB'de tutarlılık düzeyleri. Java SDK'si, çok bölgeli yazma hesaplarında oturum tutarlılığını bölgeye göre kapsamlandırarak bir optimizasyon sağlar. Bu, istemci tarafı yeniden denemelerini en aza indirerek bölgeler arası çoğaltma gecikme süresini azaltarak performansı artırır. Bu, oturum belirteçlerini genel olarak değil bölge düzeyinde yöneterek elde edilir. Uygulamanızın yalnızca birkaç bölgede tutarlılık gerekiyorsa, bölge kapsamlı oturum tutarlılığını kullanmak, bölgeler arası çoğaltma gecikmelerini ve yeniden denemeleri azaltarak çoklu yazma hesaplarındaki okuma ve yazma işlemleri için performansı ve güvenilirliği artırabilir.
Fayda -ları
- Azaltılmış Gecikme Süresi: Oturum belirteci doğrulamasını bölge düzeyine göre yerelleştirerek, yüksek maliyetli bölgeler arası yeniden deneme olasılığı azalır.
- Gelişmiş Performans: Daha yüksek okuma/yazma tutarlılığı ve daha düşük CPU kullanımı sunarak bölgesel yük devretme ve çoğaltma gecikmesinin etkisini en aza indirir.
- İyileştirilmiş Kaynak Kullanımı: Yeniden deneme ve bölgeler arası çağrı gereksinimini sınırlayarak istemci uygulamalarındaki CPU ve ağ ek yükünü azaltır, böylece kaynak kullanımını iyileştirilir.
- Yüksek Kullanılabilirlik: Bölge kapsamlı oturum belirteçlerini koruyarak, bazı bölgelerde daha yüksek gecikme süresi veya geçici hatalar yaşansa bile uygulamalar sorunsuz çalışmaya devam edebilir.
- Tutarlılık Garantileri: Oturum tutarlılığı (yazdığını oku, monoton okuma) garantilerinin gereksiz yeniden denemeler olmadan daha güvenilir bir şekilde karşılanmasını sağlar.
- Maliyet Verimliliği: Bölgeler arası çağrı sayısını azaltarak bölgeler arasındaki veri aktarımlarıyla ilişkili maliyetleri düşürme olasılığı vardır.
- Ölçeklenebilirlik: Özellikle çok bölgeli kurulumlarda genel oturum belirtecinin korunmasıyla ilgili çekişme ve ek yükü azaltarak uygulamaların daha verimli bir şekilde ölçeklendirilmesini sağlar.
Takaslar
- Artan Bellek Kullanımı: Bloom filtresi ve bölgeye özgü oturum belirteci depolama alanı daha fazla bellek gerektirir ve bu da kaynakları sınırlı olan uygulamalar için dikkat edilmesi gereken bir konu olabilir.
- Yapılandırma Karmaşıklığı: Bloom filtresi için beklenen ekleme sayısına ve hatalı pozitif oranına ince ayar yapmak, yapılandırma işlemine bir karmaşıklık katmanı ekler.
- Hatalı PozitifLer Olasılığı: Bloom filtresi bölgeler arası yeniden denemeleri en aza indirgese de, oran denetlenebilir olsa da oturum belirteci doğrulamasını etkileyen hatalı pozitiflerin küçük bir olasılığı vardır. Hatalı pozitif sonuç, genel oturum belirtecinin çözümlenmesi anlamına gelir ve böylece yerel bölge bu genel oturuma yetişmezse bölgeler arası yeniden deneme olasılığını artırır. Hatalı pozitifler bulunsa dahi oturum garantileri sağlanır.
- Uygulanabilirlik: Bu özellik, mantıksal bölümlerin ve düzenli yeniden başlatmaların yüksek kardinalitesine sahip uygulamalar için en faydalıdır. Daha az mantıksal bölüme veya seyrek yeniden başlatmaya sahip uygulamalar önemli avantajlar göremeyebilir.
Nasıl çalışır?
Oturum belirtecini ayarlama
- İstek Tamamlama: İstek tamamlandıktan sonra SDK, oturum belirtecini yakalar ve bölge ve bölüm anahtarıyla ilişkilendirir.
-
Bölge Düzeyinde Depolama: Oturum belirteçleri, bölüm anahtarı aralıkları ile bölge düzeyinde ilerleme arasındaki eşlemeleri koruyan iç içe
ConcurrentHashMapyerleştirilmiş bir depoda depolanır. - Bloom Filtresi: Bloom filtresi, her mantıksal bölüm tarafından hangi bölgelere erişildiğini izler ve oturum belirteci doğrulamasını yerelleştirmeye yardımcı olur.
Oturum belirtecini çözümleme
- İstek Başlatma: bir istek gönderilmeden önce SDK, uygun bölge için oturum belirtecini çözümlemeye çalışır.
- Belirteç Denetimi: İsteğin en güncel çoğaltmaya yönlendirildiğinden emin olmak için belirteç bölgeye özgü verilerle denetlenır.
- Yeniden Deneme Mantığı: Oturum belirteci geçerli bölge içinde doğrulanmıyorsa, SDK diğer bölgelerle yeniden denenir, ancak yerelleştirilmiş depolama göz önüne alındığında bu daha az sıktır.
SDK'yi kullanma
İşte CosmosClient'ı bölgeye özgü oturum tutarlılığıyla başlatmanın yolu:
CosmosClient client = new CosmosClientBuilder()
.endpoint("<your-endpoint>")
.key("<your-key>")
.consistencyLevel(ConsistencyLevel.SESSION)
.buildClient();
// Your operations here
Bölge kapsamlı oturum tutarlılığını etkinleştirme
Uygulamanızda bölge kapsamlı oturum yakalamayı etkinleştirmek için aşağıdaki sistem özelliğini ayarlayın:
System.setProperty("COSMOS.SESSION_CAPTURING_TYPE", "REGION_SCOPED");
Bloom filtresini yapılandır
Bloom filtresi için beklenen eklemeleri ve yanlış pozitif oranını yapılandırarak performansı iyileştirin.
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_INSERTION_COUNT", "5000000"); // adjust as needed
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_FFP_RATE", "0.001"); // adjust as needed
System.setProperty("COSMOS.SESSION_CAPTURING_TYPE", "REGION_SCOPED");
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_INSERTION_COUNT", "1000000");
System.setProperty("COSMOS.PK_BASED_BLOOM_FILTER_EXPECTED_FFP_RATE", "0.01");
Bellek etkileri
Aşağıda, iç oturum kapsayıcısının (SDK tarafından yönetilen) bloom filtresine beklenen eklemeler ile korunmuş boyutu (nesnenin boyutu ve bağımlı olduğu her şey) gösterilmektedir.
| Beklenen Eklemeler | Yanlış Pozitif Oranı | Tutulan Boyut |
|---|---|---|
| 10, 000 | 0.001 | 21 KB |
| 100, 000 | 0.001 | 183 KB |
| 1 milyon | 0.001 | 1,8 MB |
| 10 milyon | 0.001 | 17,9 MB |
| 100 milyon | 0.001 | 179 MB |
| 1 milyar | 0.001 | 1,8 GB |
Önemli
Bölge kapsamlı oturum tutarlılığını etkinleştirmek için Java SDK'sının 4.60.0 veya üzeri bir sürümünü kullanıyor olmanız gerekir.
Hariç tutulan bölgeler
Hariç tutulan bölgeler özelliği, istek başına belirli bölgeleri tercih ettiğiniz konumların dışında tutmanıza olanak tanıyarak istek yönlendirmesi üzerinde ayrıntılı denetim sağlar. Bu özellik Azure Cosmos DB Java SDK sürüm 4.47.0 ve üzeri sürümlerde kullanılabilir.
Başlıca avantajlar:
- İşleme hızı sınırlama: 429 (Çok Fazla İstek) yanıtıyla karşılaştığınızda, istekleri otomatik olarak kullanılabilir aktarım hızına sahip alternatif bölgelere yönlendirin
- Hedeflenen yönlendirme: Diğer tüm bölgeleri dışlayarak isteklerin belirli bölgelerden sunulduğundan emin olun
- Tercih edilen sırayı atla: Ayrı istemciler oluşturmadan tek tek istekler için varsayılan tercih edilen bölgeler listesini geçersiz kıl
Configuration:
Dışlanan bölgeler hem istemci düzeyinde hem de istek düzeyinde yapılandırılabilir:
CosmosExcludedRegions excludedRegions = new CosmosExcludedRegions(Set.of("East US"));
// Using AtomicReference to simulate dynamic changes to excluded regions. Excluded regions can be set at the
// client level
AtomicReference<CosmosExcludedRegions> excludedRegionsAtomicReference = new AtomicReference<>(excludedRegions);
CosmosAsyncClient client = new CosmosClientBuilder()
.endpoint("")
.key("")
.preferredRegions(List.of(new String[]{"West US", "East US"}))
.excludedRegionsSupplier(excludedRegionsAtomicReference::get)
.buildAsyncClient();
CosmosAsyncDatabase cosmosAsyncDatabase = client.getDatabase("Test");
CosmosAsyncContainer cosmosAsyncContainer = cosmosAsyncDatabase.getContainer("TestItems");
// Excluded regions can also be set at the request level
CosmosItemRequestOptions cosmosItemRequestOptions = new CosmosItemRequestOptions().setExcludedRegions(List.of("East US"));
TestObject testItem = TestObject.create("mypkValue");
cosmosAsyncContainer.createItem(testItem, cosmosItemRequestOptions).block();
Tutarlılık ve kullanılabilirlik arasında ince ayar
Dışlanan bölgeler özelliği, uygulamanızda tutarlılık ve kullanılabilirlik dengelemesi için ek bir mekanizma sağlar. Bu özellik, gereksinimlerin işletim koşullarına göre değiştirildiği dinamik senaryolarda değerlidir:
Dinamik kesinti işleme: Birincil bölgede kesinti yaşandığında ve bölüm düzeyinde devre kesici eşikleri yetersiz olduğunda, hariç tutulan bölgeler kod değişikliği veya uygulama yeniden başlatması olmadan anında yük devretmeye olanak tanır. Bu, bölgesel sorunlara otomatik devre kesici etkinleştirmesi beklemeye kıyasla daha hızlı yanıt sağlar.
Koşullu tutarlılık tercihleri: Uygulamalar, işletim durumuna göre farklı tutarlılık stratejileri uygulayabilir:
- Kararlı durum: Birincil bölge dışındaki tüm bölgeleri hariç tutarak tutarlı okumaların önceliğini belirleme ve olası kullanılabilirlik maliyetinde veri tutarlılığı sağlama
- Kesinti senaryoları: Bölgeler arası yönlendirmeye izin vererek, sürekli hizmet kullanılabilirliği karşılığında olası veri gecikmesini kabul ederek katı tutarlılık yerine kullanılabilirliği destekleyin
Bu yaklaşım, dış mekanizmaların (trafik yöneticileri veya yük dengeleyiciler gibi) yük devretme kararlarını düzenlemesine olanak tanırken uygulama, bölge dışlama desenleri aracılığıyla tutarlılık gereksinimleri üzerinde denetim sahibi olur.
Tüm bölgeler dışlandığında istekler birincil/hub bölgesine yönlendirilir. Bu özellik sorgular da dahil olmak üzere tüm istek türleriyle çalışır ve esnek yönlendirme davranışı elde ederken tek istemci örneklerini korumak için kullanışlıdır.
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, Java SDK v4 için bağlantı yapılandırmalarını yapılandırmayı nasıl yapıldığını görün.
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.
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.
CosmosClient oluşturduğunuzda, açıkça ayarlanmadıysa varsayılan olarak kullanılan tutarlılık oturum tutarlılığıdır. 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üzeye çıkarmak için Asenkron API'yi kullanın
Azure Cosmos DB Java SDK sürüm 4, Senkron ve Asenkron olmak üzere iki API'yi paketler. Kabaca konuşursak, Asenkron API SDK işlevselliğini uygularken, Senkron API Asenkron API'ye engelleyici çağrılar yapan ince bir sarmalayıcıdır. Bu, yalnızca Asenkron olan eski Azure Cosmos DB Async Java SDK v2 ile sadece Senkron olan ve farklı bir uygulamaya sahip olan eski Azure Cosmos DB Senkron Java SDK'sı v2'nin zıttıdır.
API seçimi, istemci başlatma sırasında belirlenir; CosmosAsyncClient Asenkron API'yi desteklerken CosmosClient Senkron API'yi destekler.
Async API, engellemesiz IO uygular ve amacınız Azure Cosmos DB'ye istek gönderirken verimliliği en üst düzeye çı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 senkronizasyon API'sinin aktarım hızı, istek yanıt süresi arttıkça azalırken, Zaman Uyumsuz API donanımınızın tüm bant genişliği olanaklarını doyum noktasına kadar kullanabilir.
Coğrafi yerleştirme, Senkron API kullanırken size daha yüksek ve daha tutarlı aktarım hızı sağlayabilir (bkz Aynı Azure bölgesindeki istemcileri birlikte yerleştirme performans) fakat, yine de Async API'nin ulaşılabilir aktarım hızını aşması beklenmez.
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ının sınırlarını zorlaması nedeniyle istemci uygulaması darboğaz haline gelebilir. Bu noktaya ulaşırsanız, istemci uygulamalarınızı birden çok sunucuya yayarak Azure Cosmos DB hesabınızı daha da genişletebilirsiniz.
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'sinin zaman uyumsuz işlevselliği, netty engelleyici olmayan GÇ'ye dayanır. SDK, Girdi/Çıktı işlemlerini yürütmek için, makinenizdeki CPU çekirdeklerinin sayısı kadar sabit sayıda Netty olay döngüsü iş parçacığı 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 Girdi/Çıktı olay döngüsündeki 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'nin veri 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ü IO netty iş parçacığında sonuç üzerinde CPU yoğun işlemler yapmaktan kaçınmalısınız. 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ı optimize etme
Çeşitli nedenlerden ötürü, yüksek istek aktarım hızı üreten bir iş parçacığına günlük kaydı 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, kayıt optimizasyonları performansı büyük ölçüde artırabilir.
- Zaman uyumsuz bir loglayıcı yapılandır
Senkron bir günlükçünün gecikme süresi, istek oluşturan iş parçacığınızın genel gecikme süresi hesaplamasına dahil edilir. Yüksek performanslı uygulama iş parçacıklarınızdan günlük kaydının yükünü ayırmak için log4j2 gibi bir asenkron logger önerilir.
- Netty'nin günlüğünü devre dışı bırakın
Netty kitaplığı günlük kaydı aşırı ayrıntılıdır ve ek CPU maliyetlerinden kaçınmak için kapatılması gerekir (yapılandırmada günlük kaydını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 kaynaklanan 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);
- OS Açık Dosya Kaynak Limiti
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
- Bölüm anahtarını nokta yazımında 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.
Throughput
- 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 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 yukarıdaki sorgu 1.000 1 KB 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ı.
- 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 toplu olarak tutarlı bir şekilde çalışan birden fazla istemciniz varsa, istemci tarafından şu anda dahili olarak 9'a ayarlanan varsayılan yeniden deneme sayısı yeterli olmayabilir; bu durumda istemci, uygulamaya 429 durum koduna sahip bir CosmosClientException fırlatır. 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, 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.
- 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