Jegyzet
Az oldalhoz való hozzáférés engedélyezést igényel. Próbálhatod be jelentkezni vagy könyvtárat váltani.
Az oldalhoz való hozzáférés engedélyezést igényel. Megpróbálhatod a könyvtár váltását.
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ó mó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 egy 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.
Ezek a csatlakozási módok lényegében azt az útvonalat konfigurálják, amelyet az adatsík-kérések (a dokumentumok olvasása és írása) az ügyfélszámítógépről az Azure Cosmos DB háttérrendszer partícióira visznek. 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 az Azure Cosmos DB előtér egy úgynevezett átjárókiszolgálójához lesznek irányítva, amely az Azure Cosmos DB háttérrendszerének megfelelő partícióira küldi a kéréseket.
Porttartományok a szolgáltatásokhoz
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 a 0 és 65535 közötti TCP-portok teljes tartományát használhatja. 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 |
|---|---|---|---|
| Gateway | 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í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.
Routing
Amikor egy közvetlen módban futó Azure Cosmos DB SDK végrehajt egy műveletet, 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 történjen, é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ő vezérlősík metaadatainak tekinthető. 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.
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 biztosítja, hogy a replikakészlet konzisztenciát tartson fenn, de a replika áthelyezése a meglévő TCP-címek változását okozhatja. Ezekben az esetekben az SDK-knak frissíteniük kell az útválasztási információkat, és új átjárókérésekkel ú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 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, új kapcsolatok nyílnak meg 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 esetében ezt a konfigurációt a MaxRequestsPerTcpConnection állítja be, és a Java SDK-hoz testre szabhatja a DirectConnectionConfig osztályt.
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 az IdleTcpConnectionTimeout állítja be, a Java SDK-hoz pedig testre szabhatja a DirectConnectionConfig osztályt. 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 nyelv implementálásával kapcsolatos részletekért lásd:
Következő lépések
Adott SDK-platform teljesítményoptimalizálásához:
Kapacitástervezést szeretne végezni az Azure Cosmos DB-be való migráláshoz? A kapacitástervezéshez használhatja a meglévő adatbázisfürt adatait.
- Ha csak a meglévő adatbázisfürtben lévő virtuális magok és kiszolgálók számát ismeri, olvassa el a kérelemegységek becslését virtuális magok vagy vCPU-k használatával.
- Ha ismeri az aktuális adatbázis számítási feladataira vonatkozó tipikus kérelmek arányát, olvassa el a kérelemegységek becslését az Azure Cosmos DB kapacitástervezővel.