Aracılığıyla paylaş

Azure Cosmos DB SQL SDK bağlantı modları

  • Şunlara uygulanır: ✅ 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 bir ödün olarak, ağ geçidi modu, veriler Azure Cosmos DB'den okunurken veya Azure Cosmos DB'ye yazılırken her seferinde ek bir ağ atlaması içerir. 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'nde, özellikle Tüketim planında kullandığınızda , bağlantılardaki geçerli sınırların farkında olun.

  • 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 backend replikalarına bağlanır. Doğrudan mod şu anda yalnızca .NET ve Java SDK platformlarında desteklenmektedir.

Azure Cosmos DB bağlantı modlarının diyagramı.

Bu bağlantı modları temelde veri düzlemi isteklerinin (belge okuma ve yazma işlemleri) istemci makinenizden Azure Cosmos DB arka uçtaki bölümlere giden yolu koşullar. Doğrudan mod, en iyi performans için tercih edilen seçenektir; istemcinizin Azure Cosmos DB arka uçtaki bölümlere tcp bağlantılarını doğrudan açmasını ve aracı olmadan doğrudanistek göndermesini sağlar. Buna karşılık, ağ geçidi modunda istemciniz tarafından yapılan istekler Azure Cosmos DB ön uçtaki ağ geçidi sunucusu olarak adlandırılan bir sunucuya yönlendirilir ve bu da isteklerinizi Azure Cosmos DB arka uçtaki 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. Azure Cosmos DB, özel uç noktalarda doğrudan modu kullanırken 0 ile 65535 arasında tüm TCP bağlantı noktalarını kullanabilir. 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ı
Gateway HTTPS Tüm SDK'lar SQL (443), MongoDB (10255), Tablo (443), Cassandra (10350), Graph (443)
Doğrudan 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ş bölümünde ayrıntılı olarak açıklandığı gibi, doğrudan mod istemcileri TCP protokolü aracılığıyla doğrudan arka uç düğümlerine bağlanır. Her arka uç düğümü, fiziksel bölüme ait bir çoğaltma kümesindeki bir çoğaltmayı temsil eder.

Routing

Doğrudan modda bir Azure Cosmos DB SDK'si bir işlem gerçekleştirdiğinde, hangi arka uç replikasına bağlanılması gerektiğini belirlemesi 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 kopya ve üç ikincil kopya içerir. Yazma işlemleri her zaman birincil çoğaltma düğümlerine yönlendirilirken, okuma işlemleri birincil veya ikincil düğümlerden sunulabilir.

Arka uç düğümlerine TCP bağlantılarını açmadan önce SDK'nın doğrudan modda kapsayıcıyı ve yönlendirme bilgilerini Ağ Geçidi'nden nasıl getirdiğ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, kopyaları tutan makineler yükseltme veya bakımdan geçebilir. Hizmet, çoğaltma kümesinin tutarlılığı korumasını sağlar, 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, dört kopyadan oluşan bir kopya kümesine sahiptir. En iyi performansı sağlamak için, yazma ve okuma işlemlerini karıştıran iş yüklerinde SDK'lar, tüm kopyalara bağlantı açmak zorunda kalır. Eşzamanlı işlemler, her çoğaltmanın sağladığı performansın avantajlarından yararlanmak için mevcut bağlantılar arasında yük dengelenir.

SDK'nın açtığı 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 her fiziksel bölüm ve her çoğaltma için bir bağlantısı vardır. Bir kapsayıcıdaki fiziksel bölüm sayısı ne kadar büyükse, açık bağlantı sayısı da o kadar fazladır. İş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ı talep 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 numarasını aşması mümkündür. Bu davranış, işletimsel hacimlerinde ani artışlar olabilecek iş yükleri için beklenir. .NET SDK'sı için bu yapılandırma MaxRequestsPerTcpConnection tarafından ayarlanır ve Java SDK'sı için DirectConnectionConfig sınıfını 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). Bağlantıların bir süre kullanılmamış olması durumunda, gelecekteki işlemleri biraz etkileyebileceğini anlayarak, belirli senaryolarda bağlantıları kapatmak isteyebilirsiniz. .NET SDK'sı için bu yapılandırma IdleTcpConnectionTimeout tarafından ayarlanır ve Java SDK'sı için DirectConnectionConfig Sınıfını 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 uygulama ayrıntıları için bkz:

Sonraki Adımlar

Belirli SDK platformu performans iyileştirmeleri için:

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.

  • Last updated on