Azure Cosmos DB SQL SDK bağlantı modları

UYGULANANLAR: NoSQL

Bir istemcinin Azure Cosmos DB'ye nasıl bağlandığı, özellikle de gözlemlenen istemci tarafı gecikme süresi için önemli performans etkilerine sahiptir. Azure Cosmos DB, HTTPS üzerinden ağ geçidi modu olarak adlandırılan basit ve açık bir RESTful programlama modeli sunar. Ayrıca, iletişim modelinde de RESTful olan ve doğrudan mod olarak adlandırılan ilk kimlik doğrulaması ve şifreleme trafiği için TLS kullanan verimli bir TCP protokolü sunar.

Kullanılabilir bağlantı modları

Kullanılabilir iki bağlantı modu şunlardır:

  • Ağ geçidi modu

    Ağ geçidi modu tüm SDK platformlarında desteklenir. Uygulamanız katı güvenlik duvarı kısıtlamalarına sahip bir şirket ağı içinde çalışıyorsa, standart HTTPS bağlantı noktasını ve tek bir DNS uç noktasını kullandığından ağ geçidi modu en iyi seçenektir. Ancak performans açısından dezavantaj, ağ geçidi modunun Azure Cosmos DB'den her veri okunduğu veya Azure Cosmos DB'ye yazıldığını her seferinde ek bir ağ atlamasını içermesidir. Ayrıca, sınırlı sayıda yuva bağlantısına sahip ortamlarda uygulamaları çalıştırdığınızda ağ geçidi bağlantı modunu öneririz.

    SDK'yı Azure İşlevleri,özellikle de Tüketim planında kullandığınızda, bağlantılardaki geçerli sınırlara dikkat edin.

  • Doğrudan mod

    Doğrudan mod TCP protokolü aracılığıyla bağlantıyı destekler, ilk kimlik doğrulaması ve trafiği şifrelemek için TLS kullanır ve daha az ağ atlaması olduğundan daha iyi performans sunar. Uygulama doğrudan arka uç çoğaltmalarına bağlanır. Doğrudan mod şu anda yalnızca .NET ve Java SDK platformlarında desteklenmektedir.

Azure Cosmos DB bağlantı modları

Bu bağlantı modları temelde veri düzleminin istediği yolu (belge okuma ve yazma işlemleri) istemci makinenizden Azure Cosmos DB arka ucundaki bölümlere yönlendirir. Doğrudan mod, en iyi performans için tercih edilen seçenektir. İstemcinizin TCP bağlantılarını doğrudan Azure Cosmos DB arka ucundaki bölümlere açmasına ve istekleri doğrudan aracı olmadan doğrudangöndermesine olanak tanır. Buna karşılık, Ağ Geçidi modunda istemciniz tarafından yapılan istekler Azure Cosmos DB ön ucundaki "Ağ Geçidi" adlı bir sunucuya yönlendirilir ve bu da isteklerinizi Azure Cosmos DB arka ucundaki uygun bölümlere yönlendirir.

Hizmet bağlantı noktası aralıkları

Doğrudan modu kullandığınızda, Azure Cosmos DB dinamik TCP bağlantı noktaları kullandığından istemcinizin 10000 ile 20000 arasında değişen bağlantı noktalarına erişebildiğinden emin olmanız gerekir. Bu, ağ geçidi bağlantı noktalarına ek olarak kullanılır. Özel uç noktalarda doğrudan mod kullanılırken, Azure Cosmos DB tarafından 0 ile 65535 arasında tüm TCP bağlantı noktaları aralığı kullanılabilir. bu bağlantı noktaları istemcinizde açık değilse ve TCP protokolunu kullanmayı denerseniz 503 Hizmet Kullanılamıyor hatası alabilirsiniz.

Aşağıdaki tabloda, çeşitli API'ler için kullanılabilen bağlantı modlarının ve her API için kullanılan hizmet bağlantı noktalarının özeti gösterilmektedir:

Bağlantı modu Desteklenen protokol Desteklenen SDK’lar API/Hizmet bağlantı noktası
Ağ geçidi HTTPS Tüm SDK'lar SQL (443), MongoDB (10255), Tablo (443), Cassandra (10350), Graph (443)
Direct TCP (TLS ile şifrelenir) .NET SDK Java SDK'sı Genel/Hizmet uç noktaları kullanılırken: 10000 - 20000 aralığındaki bağlantı noktaları
Özel uç noktalar kullanılırken: 0 - 65535 aralığındaki bağlantı noktaları

Doğrudan mod bağlantı mimarisi

Girişte ayrıntılı olarak açıklandığı gibi, Doğrudan mod istemcileri TCP protokolü aracılığıyla arka uç düğümlerine doğrudan bağlanır. Her arka uç düğümü, fiziksel bölüme ait bir çoğaltma kümesindeki bir çoğaltmayı temsil eder.

Yönlendirme

Doğrudan modda bir Azure Cosmos DB SDK'sı bir işlem gerçekleştirdiğinde, hangi arka uç çoğaltmasına bağlanılması gerektiğini çözümlemesi gerekir. İlk adım, işlemin hangi fiziksel bölüme gitmesi gerektiğini bilmektir ve bunun için SDK, bölüm anahtarı tanımını içeren kapsayıcı bilgilerini bir Ağ Geçidi düğümünden alır. Ayrıca çoğaltmaların TCP adreslerini içeren yönlendirme bilgilerine de ihtiyaç duyar. Yönlendirme bilgileri ağ geçidi düğümlerinden de kullanılabilir ve her ikisi de Denetim Düzlemi meta verileri olarak kabul edilir. SDK yönlendirme bilgilerini aldıktan sonra hedef fiziksel bölüme ait çoğaltmalara yönelik TCP bağlantılarını açmaya ve işlemleri yürütmeye devam edebilir.

Her çoğaltma kümesi bir birincil çoğaltma ve üç ikincil içerir. Yazma işlemleri her zaman birincil çoğaltma düğümlerine yönlendirilirken, okuma işlemleri birincil veya ikincil düğümlerden sunulabilir.

Doğrudan modda S D K'lerinin arka uç düğümlerine T C P bağlantılarını açmadan önce kapsayıcıyı ve yönlendirme bilgilerini Ağ Geçidi'nden nasıl getireceğini gösteren diyagram

Kapsayıcı ve yönlendirme bilgileri sık değişmediğinden, sonraki işlemlerin bu bilgilerden yararlanabilmesi için SDK'larda yerel olarak önbelleğe alınır. Önceden kurulan TCP bağlantıları da işlemler arasında yeniden kullanılır. SDK'lar seçenekleri aracılığıyla aksi yapılandırılmadığı sürece, SDK örneğinin ömrü boyunca bağlantılar kalıcı olarak korunur.

Tüm dağıtılmış mimarilerde olduğu gibi, çoğaltmaları tutan makineler yükseltme veya bakımdan geçebilir. Hizmet, çoğaltma kümesinin tutarlılığını koruduğundan emin olur, ancak tüm çoğaltma hareketleri mevcut TCP adreslerinin değişmesine neden olabilir. Bu durumlarda SDK'ların yönlendirme bilgilerini yenilemesi ve yeni Ağ Geçidi istekleri aracılığıyla yeni adreslere yeniden bağlanması gerekir. Bu olaylar genel P99 SLA'yı etkilememelidir.

Bağlantı hacmi

Her fiziksel bölümün dört çoğaltmadan oluşan bir çoğaltma kümesi vardır ve mümkün olan en iyi performansı sağlamak için SDK'lar yazma ve okuma işlemlerini karıştıran iş yükleri için tüm çoğaltmalara bağlantılar açar. Eşzamanlı işlemler, her çoğaltmanın sağladığı aktarım hızının avantajlarından yararlanmak için mevcut bağlantılar arasında yük dengelemesi yapılır.

SDK'nın açacağı TCP bağlantılarının sayısını belirleyen iki faktör vardır:

  • Fiziksel bölüm sayısı

    Sabit bir durumda, SDK'nın fiziksel bölüm başına çoğaltma başına bir bağlantısı olur. Bir kapsayıcıdaki fiziksel bölüm sayısı ne kadar büyük olursa, açık bağlantı sayısı o kadar fazla olur. İşlemler farklı bölümler arasında yönlendirildiğinden, isteğe bağlı olarak bağlantılar kurulur. Daha sonra ortalama bağlantı sayısı, fiziksel bölümlerin dört katıdır.

  • Eşzamanlı istek hacmi

    Kurulan her bağlantı, yapılandırılabilir sayıda eşzamanlı işlem sağlayabilir. Eşzamanlı işlemlerin hacmi bu eşiği aşarsa, bunlara hizmet vermek için yeni bağlantılar açılır ve fiziksel bir bölüm için açık bağlantı sayısının sabit durum sayısını aşması mümkündür. Bu davranış, işletimsel hacimlerinde ani artışlar olabilecek iş yükleri için beklenir. .NET SDK için bu yapılandırma CosmosClientOptions.MaxRequestsPerTcpConnection tarafından ayarlanır ve Java SDK'sı için DirectConnectionConfig.setMaxRequestsPerConnection kullanarak özelleştirebilirsiniz.

Varsayılan olarak, bağlantılar gelecekteki işlemlerin performansından yararlanacak şekilde kalıcı olarak korunur (bir bağlantının açılması işlem yüküne sahiptir). Bunun gelecekteki işlemleri biraz etkileyebileceğini anlamak için kullanılmayan bağlantıları kapatmak isteyebileceğiniz bazı senaryolar olabilir. .NET SDK için bu yapılandırma CosmosClientOptions.IdleTcpConnectionTimeout tarafından ayarlanır ve Java SDK'sı için DirectConnectionConfig.setIdleConnectionTimeout kullanarak özelleştirebilirsiniz. Bağlantıların sık sık kapatılmasına ve genel performansı etkilemesine neden olabileceği için bu yapılandırmaların düşük değerlere ayarlanması önerilmez.

Dile özgü uygulama ayrıntıları

Bir dille ilgili daha fazla uygulama ayrıntısı için bkz:

Sonraki adımlar

Belirli SDK platformu performans iyileştirmeleri için:

  • .NET V2 SDK performans ipuçları

  • .NET V3 SDK performans ipuçları

  • Java V4 SDK performans ipuçları

  • 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 çekirdek veya vCPU 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