Azure Cosmos DB SQL SDK csatlakozási módok

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Az ügyfél Azure Cosmos DB-hez való csatlakozásának fontos teljesítménybeli következményei vannak, különösen a megfigyelt ügyféloldali késés esetén. Az Azure Cosmos DB egy egyszerű, nyílt RESTful programozási modellt kínál HTTPS-en keresztül, átjáró mód néven. Emellett hatékony TCP protokollt is kínál, amely szintén RESTful a kommunikációs modellben, és a TLS-t használja a kezdeti hitelesítéshez és a forgalom titkosításához, az ú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 adatokat olvasnak az Azure Cosmos DB-ből vagy írnak be. 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 Azure Functions használja, különösen a Használat csomagban, vegye figyelembe a kapcsolatokra vonatkozó jelenlegi korlátozásokat.

  • 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 hálózati ugrás van. 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 csatlakozási módok alapvetően azt az útvonalat kondicionálja, amelyet az adatsík kér – a dokumentum olvasása és írása – az ügyfélszámítógépről az Azure Cosmos DB háttérrendszerbeli partícióira. A legjobb teljesítmény előnyben részesített módja a közvetlen mód – lehetővé teszi, hogy az ügyfél 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ében található megfelelő partíció(k)ra küldi a kéréseket.

Szolgáltatásport-tartományok

Ha közvetlen módot használ, meg kell győződnie arról, hogy az ügyfél 10000 és 20000 közötti portokhoz fér 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álja használni a TCP protokollt, 503 Szolgáltatás nem érhető el hibaüzenet jelenhet meg.

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)
Direct TCP (TLS-en keresztül titkosítva) .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írtak szerint 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

Amikor egy Közvetlen módban futó Azure Cosmos DB SDK műveletet hajt végre, meg kell oldania, hogy melyik háttérreplikához kell csatlakoznia. Az első lépés annak ismerete, hogy a művelet melyik fizikai partícióra kerüljön, és ehhez az SDK lekérte 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ő a vezérlősík metaadatainak tekinthető. Miután az SDK beszerezte az útválasztási adatokat, 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ópontokra lesznek irányítva, míg az olvasási műveletek elsődleges vagy másodlagos csomópontokról is kiszolgálhatók.

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

Mivel a tároló és az útválasztási információk gyakran nem változnak, 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-kapcsolatokat a rendszer a műveletek között is újra felhasználja. Hacsak az SDK-k beállításai nem konfigurálják másként, a kapcsolatok véglegesen megmaradnak az SDK-példány élettartama alatt.

Mint minden elosztott architektúra esetében, a replikákat tartalmazó gépek frissítésen vagy karbantartáson eshetnek át. A szolgáltatás biztosítja, hogy a replikakészlet fenntartsa a konzisztenciát, de a replika áthelyezése miatt a meglévő TCP-címek megváltoznak. Ezekben az esetekben az SDK-knak frissíteniük kell az útválasztási adatokat, és új átjárókérésekkel újra csatlakozniuk kell 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 kombináló számítási feladatok összes replikájához megnyitják a kapcsolatokat. Az egyidejű műveletek terhelése elosztott 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 kapcsolatot fog létesíteni fizikai partíciónként. Minél nagyobb a fizikai partíciók száma egy tárolóban, 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 létrejönnek. A kapcsolatok átlagos száma ezután a fizikai partíciók négyszeres száma 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 volumene 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 esetében 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 állítani, mivel az a kapcsolatok gyakori bezárását okozhatja, és hatással lehet a teljes teljesítményre.

Nyelvspecifikus megvalósítás 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ényének optimalizálása esetén: