Megosztás a következőn keresztül:

Azure Cosmos DB SQL SDK csatlakozási módok

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az ügyfél Azure Cosmos DB-hez való kapcsolódásának fontos teljesítménybeli következményei vannak, különösen az ügyféloldali késések megfigyelése szempontjából. Az Azure Cosmos DB egy egyszerű, nyílt RESTful programozási modellt kínál HTTPS-en keresztül, átjáró módban. Emellett hatékony TCP protokollt is kínál, amely szintén RESTful a kommunikációs modellben, és TLS-t használ a kezdeti hitelesítéshez és a forgalom titkosításához, úgynevezett közvetlen módhoz.

Elérhető csatlakozási módok

A két elérhető kapcsolati mód a következő:

  • Átjáró üzemmód

    Az átjáró mód minden SDK-platformon támogatott. Ha az alkalmazás szigorú tűzfalkorlátozásokkal rendelkező vállalati hálózaton fut, az átjáró mód a legjobb választás, mert a szabványos HTTPS-portot és egyetlen DNS-végpontot használja. A teljesítménybeli kompromisszum azonban az, hogy az átjáró mód további hálózati ugrást foglal magában minden alkalommal, amikor az adatok az Azure Cosmos DB-ből olvasnak vagy írnak. Azt is javasoljuk, hogy átjárókapcsolati módot használjon, ha korlátozott számú szoftvercsatorna-kapcsolattal rendelkező környezetben futtat alkalmazásokat.

    Ha az SDK-t az Azure Functionsben használja, különösen a Használati csomagban, vegye figyelembe a kapcsolatokra vonatkozó jelenlegi korlátokat.

  • Közvetlen mód

    A közvetlen mód támogatja a TCP protokollon keresztüli kapcsolatot, a TLS-t használva a kezdeti hitelesítéshez és a forgalom titkosításához, és jobb teljesítményt nyújt, mivel kevesebb a hálózati ugrás. Az alkalmazás közvetlenül a háttérreplikákhoz csatlakozik. A közvetlen mód jelenleg csak .NET- és Java SDK-platformokon támogatott.

Az Azure Cosmos DB csatlakozási módjai

Ezek a kapcsolódási módok lényegében az adatsík által kért útvonalat – a dokumentum olvasását és írását – az ügyfélgépről az Azure Cosmos DB háttérrendszerbeli partícióira irányítják. A legjobb teljesítmény érdekében a közvetlen mód az előnyben részesített beállítás – lehetővé teszi az ügyfél számára, hogy közvetlenül nyissa meg a TCP-kapcsolatokat az Azure Cosmos DB háttérrendszerében lévő partíciókhoz, és közvetlenül, közvetítő nélkül küldjön kéréseket. Ezzel szemben átjáró módban az ügyfél által küldött kérések egy úgynevezett "Átjáró" kiszolgálóra vannak irányítva az Azure Cosmos DB előtérrendszerében, amely viszont az Azure Cosmos DB háttérrendszerének megfelelő partícióira küldi a kéréseket.

Szolgáltatásport-tartományok

Közvetlen mód használata esetén gondoskodnia kell arról, hogy az ügyfél 10000 és 20000 közötti portokhoz férhessen hozzá, mivel az Azure Cosmos DB dinamikus TCP-portokat használ. Ez az átjáróportokon kívül van. Ha közvetlen módot használ privát végpontokon, az Azure Cosmos DB használhatja a TCP-portok teljes tartományát – 0 és 65535 között. Ha ezek a portok nem nyílnak meg az ügyfélen, és megpróbálják használni a TCP protokollt, előfordulhat, hogy 503 szolgáltatás nem érhető el hibaüzenetet kap.

Az alábbi táblázat a különböző API-khoz elérhető csatlakozási módok és az egyes API-khoz használt szolgáltatásportok összegzését mutatja be:

Kapcsolat módja Támogatott protokoll Támogatott SDK-k API-/szolgáltatásport
Átjáró HTTPS Minden SDK SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Közvetlen TCP (TLS-en keresztül titkosított) .NET SDK Java SDK Nyilvános/szolgáltatásvégpontok használata esetén: a 10000 és 20000 közötti tartományban található portok
Privát végpontok használata esetén: a 0 és 65535 közötti tartományban található portok

Közvetlen módú kapcsolatarchitektúra

A bevezetésben leírtaknak megfelelően a közvetlen módú ügyfelek tcp protokollon keresztül közvetlenül csatlakoznak a háttércsomópontokhoz. Minden háttércsomópont egy replikát jelöl egy fizikai partícióhoz tartozó replikakészletben.

Útválasztás

Ha egy Közvetlen módban futó Azure Cosmos DB SDK műveletet hajt végre, meg kell oldania, hogy melyik háttérreplikához szeretne csatlakozni. Az első lépés annak ismerete, hogy a művelet melyik fizikai partícióra menjen, és ehhez az SDK beolvassa az átjárócsomópont partíciókulcs-definícióját tartalmazó tárolóadatokat. Szüksége van a replikák TCP-címeit tartalmazó útválasztási adatokra is. Az útválasztási információk az átjárócsomópontokról is elérhetők, és mindkettő vezérlősík metaadatainak minősül. Miután az SDK beszerezte az útválasztási információkat, megnyithatja a TCP-kapcsolatokat a cél fizikai partícióhoz tartozó replikákkal, és végrehajthatja a műveleteket.

Minden replikakészlet egy elsődleges replikát és három másodpéldányt tartalmaz. Az írási műveletek mindig elsődleges replikacsomópontokhoz lesznek irányítva, míg az olvasási műveletek az elsődleges vagy másodlagos csomópontokról kézbesíthetők.

Diagram, amely bemutatja, hogy a közvetlen módban lévő S D K-k hogyan kapják le a tárolót és az útválasztási információkat az átjáróról, mielőtt megnyitnák a T C P-kapcsolatokat a háttércsomópontok felé

Mivel a tároló és az útválasztási információk nem változnak gyakran, az SDK-k helyileg gyorsítótárazva lesznek, hogy a későbbi műveletek kihasználhassák ezeket az információkat. A már létrehozott TCP-kapcsolatok is újra felhasználhatók a műveletek között. Ha másként nem konfigurálja az SDK-beállításokon keresztül, a kapcsolatok az SDK-példány élettartama alatt véglegesen megmaradnak.

Az elosztott architektúrákhoz hasonlóan a replikákat tartalmazó gépek is frissítésen vagy karbantartáson eshetnek át. A szolgáltatás gondoskodik arról, hogy a replikakészlet konzisztenciát tartson fenn, de a replika áthelyezése esetén a meglévő TCP-címek megváltoznak. Ezekben az esetekben az SDK-knak frissíteniük kell az útválasztási információkat, és új átjárókéréseken keresztül újra kell csatlakozniuk az új címekhez. Ezek az események nem befolyásolhatják a teljes P99 SLA-t.

Kapcsolatok mennyisége

Minden fizikai partíció négy replikakészlettel rendelkezik, így a lehető legjobb teljesítmény érdekében az SDK-k az írási és olvasási műveleteket vegyes számítási feladatok összes replikájához megnyitják a kapcsolatokat. Az egyidejű műveletek terhelése ki van osztva a meglévő kapcsolatok között, hogy kihasználhassa az egyes replikák által biztosított átviteli sebességet.

Az SDK által megnyíló TCP-kapcsolatok számát két tényező határozza meg:

  • Fizikai partíciók száma

    Állandó állapotban az SDK replikánként egy kapcsolattal rendelkezik fizikai partíciónként. Minél nagyobb a tárolóban lévő fizikai partíciók száma, annál nagyobb lesz a nyitott kapcsolatok száma. Mivel a műveletek különböző partíciókra vannak irányítva, a kapcsolatok igény szerint jönnek létre. A kapcsolatok átlagos száma ezután a fizikai partíciók számának négyszerese lesz.

  • Egyidejű kérések mennyisége

    Minden létrehozott kapcsolat konfigurálható számú egyidejű műveletet képes kiszolgálni. Ha az egyidejű műveletek mennyisége meghaladja ezt a küszöbértéket, az új kapcsolatok nyitva lesznek a kiszolgálásukhoz, és lehetséges, hogy egy fizikai partíció esetében a nyitott kapcsolatok száma meghaladja az állandó állapot számát. Ez a viselkedés olyan számítási feladatok esetében várható, amelyek működési mennyisége kiugróan magas lehet. A .NET SDK-hoz ezt a konfigurációt a CosmosClientOptions.MaxRequestsPerTcpConnection állítja be, a Java SDK-hoz pedig testre szabhatja a DirectConnectionConfig.setMaxRequestsPerConnection parancsot.

Alapértelmezés szerint a kapcsolatok tartósan megmaradnak, hogy kihasználják a jövőbeli műveletek teljesítményét (a kapcsolat megnyitása számítási többletterheléssel jár). Előfordulhatnak olyan forgatókönyvek, amikor egy ideig nem használt kapcsolatokat szeretne bezárni, és ez kis mértékben befolyásolhatja a jövőbeli műveleteket. A .NET SDK-hoz ezt a konfigurációt a CosmosClientOptions.IdleTcpConnectionTimeout állítja be, a Java SDK-hoz pedig testre szabhatja a DirectConnectionConfig.setIdleConnectionTimeout parancsot. Ezeket a konfigurációkat nem ajánlott alacsony értékekre beállítani, mivel ez a kapcsolatok gyakori lezárását okozhatja, és hatással lehet az általános teljesítményre.

Nyelvspecifikus implementáció részletei

A nyelvvel kapcsolatos további megvalósítási részletekért lásd:

Következő lépések

Adott SDK-platform teljesítményoptimalizálásához: