Režimy připojení sady SQL SDK služby Azure Cosmos DB

  • Platí pro: ✅ NoSQL

To, jak se klient připojuje ke službě Azure Cosmos DB, má významný dopad na výkon, zejména pro pozorovanou latenci na straně klienta. Azure Cosmos DB nabízí jednoduchý a otevřený programovací model RESTful přes HTTPS označovaný jako režim brány . Kromě toho nabízí efektivní protokol TCP, který je také RESTful ve svém komunikačním modelu a používá protokol TLS pro počáteční ověřování a šifrování provozu, označovaný jako přímý režim.

Dostupné režimy připojení

Mezi dva dostupné režimy připojení patří:

  • Režim Gateway

    Režim brány se podporuje na všech platformách sady SDK. Pokud vaše aplikace běží v podnikové síti s přísnými omezeními brány firewall, je nejlepší volbou režim brány, protože používá standardní port HTTPS a jeden koncový bod DNS. Kompromis ve výkonu spočívá v tom, že režim brány zahrnuje další síťový hop při každém čtení dat nebo zápisu dat do služby Azure Cosmos DB. Režim připojení brány také doporučujeme, když spouštíte aplikace v prostředích s omezeným počtem připojení soketů.

    Při použití sady SDK ve službě Azure Functions, zejména v plánu Consumption, mějte na paměti aktuální limity připojení.

  • Přímý režim

    Přímý režim podporuje připojení prostřednictvím protokolu TCP, pomocí TLS pro počáteční autentizaci a šifrování provozu, a nabízí lepší výkon, protože existuje méně síťových skoků. Aplikace se připojuje přímo k backendovým replikám. Přímý režim je aktuálně podporován pouze na platformách .NET a Java SDK.

Diagram režimů připojení ke službě Azure Cosmos DB

Tyto režimy připojení v zásadě ovlivňují trasu, kterou požadavky na rovinu dat (čtení a zápisy dokumentů) volí z vašeho klientského počítače k partiím v systému backendu Azure Cosmos DB. Přímý režim je upřednostňovanou možností pro nejlepší výkon; umožňuje klientovi otevírat připojení TCP přímo k oddílům v back-endu služby Azure Cosmos DB a odesílat požadavky přímobez zprostředkujícího. Naproti tomu v režimu brány jsou požadavky provedené klientem směrovány na tzv. Gateway server ve front-endu Azure Cosmos DB, který následně rozděluje tyto požadavky na příslušné oddíly v back-endu Azure Cosmos DB.

Rozsahy služebních portů

Pokud používáte přímý režim, musíte zajistit, aby váš klient mohl přistupovat k portům v rozsahu 1 0000 až 20000, protože Azure Cosmos DB používá dynamické porty TCP. K portům brány je to navíc. Při použití přímého režimu na privátních koncových bodech může Azure Cosmos DB používat úplný rozsah portů TCP od 0 do 65535. Pokud tyto porty nejsou v klientovi otevřené a pokusíte se použít protokol TCP, může se zobrazit chyba 503 Služba není k dispozici.

Následující tabulka obsahuje souhrn režimů připojení dostupných pro různá rozhraní API a porty služby používané pro každé rozhraní API:

Režim připojení Podporovaný protokol Podporované sady SDK Port rozhraní API nebo služby
Gateway HTTPS Všechny sady SDK SQL (443), MongoDB (10255), tabulka (443), Cassandra (10350), graf (443)
Přímo TCP (šifrované přes TLS) Sada .NET SDK Java SDK Při použití veřejných koncových bodů nebo koncových bodů služby: porty v rozsahu od 10000 do 20000

Při použití privátních koncových bodů: porty v rozsahu od 0 do 65535

Architektura připojení s přímým režimem

Jak je podrobně popsáno v úvodu, klienti přímého režimu se připojují přímo k back-endovým uzlům prostřednictvím protokolu TCP. Každý backendový uzel představuje repliku v sadě replik, která patří do fyzického oddílu.

Směrování

Když sada SDK služby Azure Cosmos DB v přímém režimu provádí operaci, musí vyřešit, ke které back-endové replice se má připojit. Prvním krokem je znalost fyzického oddílu, na který má operace přejít, a za tímto účelem sada SDK získá informace o kontejneru, které zahrnují definici klíče oddílu z uzlu brány. Potřebuje také informace o směrování, které obsahují adresy TCP replik. Informace o směrování jsou k dispozici také z uzlů brány a obě jsou považovány za metadata řídicí roviny. Jakmile sada SDK získá informace o směrování, může pokračovat otevřením připojení TCP k replikám patřícím do cílového fyzického oddílu a spustit operace.

Každá sada replik obsahuje jednu primární repliku a tři sekundární soubory. Operace zápisu se vždy směrují na uzly primární repliky, zatímco operace čtení se dají obsluhovat z primárních nebo sekundárních uzlů.

Diagram znázorňující, jak sada SDK v přímém režimu načítá kontejner a směruje informace z brány před otevřením připojení TCP k back-endovým uzlům

Vzhledem k tomu, že se informace o kontejneru a směrování často nemění, jsou uloženy místně v mezipaměti sad SDK, aby následné operace mohly tyto informace využívat. Už vytvořená připojení TCP se také znovu používají napříč operacemi. Pokud nejsou prostřednictvím možností sad SDK nakonfigurovaná jinak, připojení se během životnosti instance sady SDK trvale udržují.

Stejně jako u jakékoli distribuované architektury můžou počítače, které uchovávají repliky, procházet upgrady nebo údržbou. Služba zajišťuje, aby sada replik zachovala konzistenci, ale všechny přesuny replik by způsobily, že se stávající adresy TCP změní. V těchto případech musí sady SDK aktualizovat informace o směrování a znovu se připojit k novým adresám prostřednictvím nových požadavků brány. Tyto události by neměly mít vliv na celkovou smlouvu SLA P99.

Objem připojení

Každý fyzický oddíl má sadu replik se čtyřmi replikami, aby poskytovaly nejlepší možný výkon, sady SDK nakonec otevírají připojení ke všem replikám pro úlohy, které kombinují operace zápisu a čtení. Souběžné operace jsou vyrovnávány mezi existujícími připojeními, aby se využila propustnost, kterou poskytuje každá replika.

Existují dva faktory, které určují počet připojení TCP, která sada SDK otevře:

  • Počet fyzických oddílů

    V stabilním stavu má sada SDK jedno připojení na repliku na fyzický oddíl. Čím větší je počet fyzických oddílů v kontejneru, tím větší bude i počet otevřených spojení. Vzhledem k tomu, že se operace směrují napříč různými oddíly, navazují se připojení na vyžádání. Průměrný počet připojení by byl počet fyzických oddílů vynásobený čtyřmi.

  • Objem souběžných požadavků

    Každé navázané připojení může obsluhovat konfigurovatelný počet souběžných operací. Pokud objem souběžných operací tuto prahovou hodnotu překročí, mohou je nová připojení obsluhovat a je možné, že pro fyzickou partition počet otevřených připojení překročí počet odpovídající stabilnímu stavu. Toto chování se očekává u úloh, které můžou mít špičky v objemu operací. Pro sadu .NET SDK je tato konfigurace nastavena maxRequestsPerTcpConnection a pro sadu Java SDK můžete přizpůsobit pomocí třídy DirectConnectionConfig.

Ve výchozím nastavení jsou připojení trvale udržována, aby těží z výkonu budoucích operací (otevření připojení má výpočetní režii). Můžou se zde vyskytovat situace, kdy možná budete chtít zavřít připojení, která se po nějakou dobu nevyužívají, abyste pochopili, že to může mít vliv na budoucí operace mírně. Pro sadu .NET SDK je tato konfigurace nastavená pomocí IdleTcpConnectionTimeout a pro sadu Java SDK můžete přizpůsobit pomocí třídy DirectConnectionConfig. Nedoporučujeme nastavit tyto konfigurace na nízké hodnoty, protože může způsobit časté zavření připojení a ovlivnit celkový výkon.

Podrobnosti implementace specifické pro konkrétní jazyk

Podrobnosti o implementaci týkající se jazyka najdete tady:

Další kroky

Pro konkrétní optimalizace výkonu platformy SDK:

Pokoušíte se naplánovat kapacitu migrace do služby Azure Cosmos DB? Informace o stávajícím databázovém clusteru můžete použít k plánování kapacity.

  • Poslední aktualizace v