Sdílet prostřednictvím

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

  • Článek

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 brány

    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. Nevýhodou výkonu je ale to, že režim brány zahrnuje další segment směrování sítě při každém čtení 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, použití protokolu TLS pro počáteční ověřování a šifrování provozu a nabízí lepší výkon, protože existuje méně segmentů směrování sítě. Aplikace se připojí přímo k back-endovým replikám. Přímý režim je aktuálně podporován pouze na platformách .NET a Java SDK.

Režimy připojení ke službě Azure Cosmos DB

Tyto režimy připojení v podstatě podmíní trasu, kterou požadavky roviny dat – čtení a zápisy dokumentů – přebírají z vašeho klientského počítače do oddílů v back-endu služby Azure Cosmos DB. Přímý režim je upřednostňovanou možností pro dosažení nejlepšího výkonu – 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í. Naproti tomu v režimu brány se požadavky provedené vaším klientem směrují na tzv. server "Gateway" ve front-endu Služby Azure Cosmos DB, který zase fandí vaše požadavky na příslušné oddíly v back-endu služby Azure Cosmos DB.

Rozsahy portů služby

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. To je navíc k portům brány. 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 Nedostupná.

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
Brána HTTPS Všechny sady SDK SQL (443), MongoDB (10255), tabulka (443), Cassandra (10350), graf (443)
Direct 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 režimu Direct se budou přímo připojovat k back-endovým uzlům prostřednictvím protokolu TCP. Každý back-endový 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 režimu Direct provádí operaci, musí přelož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 S D Ks v přímém režimu načítá kontejner a směrovací informace z brány před otevřením připojení T C P 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 zajistí, aby sada replik zachovala konzistenci, ale všechny přesuny replik by způsobily změnu existujících adres TCP. 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řou připojení ke všem replikám pro úlohy, které kombinují operace zápisu a čtení. Souběžné operace jsou vyrovnávají zatížení mezi existujícími připojeními, aby se využila propustnost, která každá replika poskytuje.

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 bude mít 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 počet otevřených připojení. 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 pak byl počet fyzických oddílů krát čtyři.

  • 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í překročí tuto prahovou hodnotu, budou otevřená nová připojení, která budou sloužit a je možné, že počet otevřených připojení překročí číslo stabilního stavu. Toto chování se očekává u úloh, které můžou mít špičky v provozním objemu. Pro sadu .NET SDK tuto konfiguraci nastaví CosmosClientOptions.MaxRequestsPerTcpConnection a sadu Java SDK můžete přizpůsobit pomocí DirectConnectionConfig.setMaxRequestsPerConnection.

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 tuto konfiguraci nastaví CosmosClientOptions.IdleTcpConnectionTimeout a pro sadu Java SDK můžete přizpůsobit pomocí DirectConnectionConfig.setIdleConnectionTimeout. 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 jazyk

Další podrobnosti implementace týkající se jazyka najdete tady:

Další kroky

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