Azure Cosmos DB SQL SDK-connectiviteitsmodi

  • Artikel

VAN TOEPASSING OP: NoSQL

Hoe een client verbinding maakt met Azure Cosmos DB heeft belangrijke gevolgen voor de prestaties, met name voor waargenomen latentie aan de clientzijde. Azure Cosmos DB biedt een eenvoudig, open RESTful-programmeermodel via HTTPS met de naam gatewaymodus. Daarnaast biedt het een efficiënt TCP-protocol, dat ook RESTful is in het communicatiemodel en TLS gebruikt voor initiële verificatie en versleuteling van verkeer, de zogenaamde directe modus.

Beschikbare connectiviteitsmodi

De twee beschikbare connectiviteitsmodi zijn:

  • Gatewaymodus

    De gatewaymodus wordt ondersteund op alle SDK-platforms. Als uw toepassing wordt uitgevoerd binnen een bedrijfsnetwerk met strikte firewallbeperkingen, is de gatewaymodus de beste keuze omdat deze gebruikmaakt van de standaard HTTPS-poort en één DNS-eindpunt. Het nadeel van de prestaties is echter dat de gatewaymodus een extra netwerkhop omvat telkens wanneer gegevens worden gelezen uit of geschreven naar Azure Cosmos DB. We raden ook de gatewayverbindingsmodus aan wanneer u toepassingen uitvoert in omgevingen met een beperkt aantal socketverbindingen.

    Wanneer u de SDK in Azure Functions gebruikt, met name in het verbruiksabonnement, moet u rekening houden met de huidige limieten voor verbindingen.

  • Directe modus

    De directe modus ondersteunt connectiviteit via het TCP-protocol, waarbij TLS wordt gebruikt voor initiële verificatie en het versleutelen van verkeer, en biedt betere prestaties omdat er minder netwerkhops zijn. De toepassing maakt rechtstreeks verbinding met de back-endreplica's. De directe modus wordt momenteel alleen ondersteund op .NET- en Java SDK-platforms.

De Azure Cosmos DB-connectiviteitsmodi

Deze connectiviteitsmodi vormen in wezen de voorwaarde voor de route die het gegevensvlak aanvraagt (lees- en schrijfbewerkingen van documenten) van uw clientcomputer naar partities in de Azure Cosmos DB-back-end. Directe modus is de voorkeursoptie voor de beste prestaties. Hiermee kan uw client TCP-verbindingen rechtstreeks openen naar partities in de Azure Cosmos DB-back-end en aanvragen rechtstreeksverzenden zonder tussenpersoon. In de gatewaymodus worden aanvragen van uw client daarentegen doorgestuurd naar een zogenaamde gatewayserver in de Azure Cosmos DB-front-end, die uw aanvragen vervolgens doorstuurt naar de juiste partitie(s) in de Azure Cosmos DB-back-end.

Servicepoortbereiken

Wanneer u de directe modus gebruikt, moet u ervoor zorgen dat uw client toegang heeft tot poorten tussen 10000 en 20000, omdat Azure Cosmos DB dynamische TCP-poorten gebruikt. Dit is een aanvulling op de gatewaypoorten. Wanneer u de directe modus op privé-eindpunten gebruikt, kan het volledige bereik van TCP-poorten ( van 0 tot 65535) worden gebruikt door Azure Cosmos DB. Als deze poorten niet zijn geopend op uw client en u probeert het TCP-protocol te gebruiken, wordt mogelijk de fout 503 Service niet beschikbaar weergegeven.

In de volgende tabel ziet u een overzicht van de connectiviteitsmodi die beschikbaar zijn voor verschillende API's en de servicepoorten die voor elke API worden gebruikt:

Verbindingsmodus Ondersteund protocol Ondersteunde SDK's API/servicepoort
Gateway HTTPS Alle SDK's SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct TCP (versleuteld via TLS) .NET SDK Java SDK Bij gebruik van openbare/service-eindpunten: poorten in het bereik van 10000 tot en met 20000
Bij gebruik van privé-eindpunten: poorten in het bereik van 0 tot en met 65535

Verbindingsarchitectuur voor directe modus

Zoals beschreven in de inleiding, maken clients in de directe modus rechtstreeks verbinding met de back-endknooppunten via het TCP-protocol. Elk back-endknooppunt vertegenwoordigt een replica in een replicaset die deel uitmaakt van een fysieke partitie.

Routering

Wanneer een Azure Cosmos DB SDK in de directe modus een bewerking uitvoert, moet worden opgelost met welke back-endreplica verbinding moet worden gemaakt. De eerste stap is om te weten naar welke fysieke partitie de bewerking moet gaan. Hiervoor verkrijgt de SDK de containergegevens die de definitie van de partitiesleutel bevat van een gatewayknooppunt. Het heeft ook de routeringsinformatie nodig die de TCP-adressen van de replica's bevat. De routeringsinformatie is ook beschikbaar op gatewayknooppunten en beide worden beschouwd als metagegevens van het besturingsvlak. Zodra de SDK de routeringsgegevens heeft verkregen, kan deze doorgaan met het openen van de TCP-verbindingen met de replica's die behoren tot de fysieke doelpartitie en de bewerkingen uitvoeren.

Elke replicaset bevat één primaire replica en drie secundaire databases. Schrijfbewerkingen worden altijd gerouteerd naar primaire replicaknooppunten, terwijl leesbewerkingen kunnen worden uitgevoerd vanaf primaire of secundaire knooppunten.

Diagram dat laat zien hoe S D Ks in de directe modus de container en routeringsgegevens van de gateway ophalen voordat de T C P-verbindingen met de back-endknooppunten worden geopend

Omdat de container- en routeringsgegevens niet vaak worden gewijzigd, wordt deze lokaal in de cache opgeslagen op de SDK's, zodat volgende bewerkingen van deze informatie kunnen profiteren. De TCP-verbindingen die al tot stand zijn gebracht, worden ook opnieuw gebruikt voor alle bewerkingen. Tenzij anders geconfigureerd via de SDK-opties, worden verbindingen permanent onderhouden tijdens de levensduur van het SDK-exemplaar.

Net als bij elke gedistribueerde architectuur kunnen de machines met replica's upgrades of onderhoud ondergaan. De service zorgt ervoor dat de replicaset consistentie behoudt, maar elke replicaverplaatsing zorgt ervoor dat bestaande TCP-adressen worden gewijzigd. In deze gevallen moeten de SDK's de routeringsgegevens vernieuwen en opnieuw verbinding maken met de nieuwe adressen via nieuwe gatewayaanvragen. Deze gebeurtenissen mogen geen invloed hebben op de algemene P99 SLA.

Volume van verbindingen

Elke fysieke partitie heeft een replicaset van vier replica's. Om de best mogelijke prestaties te bieden, openen SDK's uiteindelijk verbindingen met alle replica's voor workloads die schrijf- en leesbewerkingen combineren. Gelijktijdige bewerkingen worden verdeeld over bestaande verbindingen om te profiteren van de doorvoer die elke replica biedt.

Er zijn twee factoren die bepalen hoeveel TCP-verbindingen de SDK opent:

  • Aantal fysieke partities

    In een stabiele status heeft de SDK één verbinding per replica per fysieke partitie. Hoe groter het aantal fysieke partities in een container, hoe groter het aantal open verbindingen. Wanneer bewerkingen worden gerouteerd over verschillende partities, worden verbindingen op aanvraag tot stand gebracht. Het gemiddelde aantal verbindingen is dan het aantal fysieke partities maal vier.

  • Volume van gelijktijdige aanvragen

    Elke tot stand gebrachte verbinding kan een configureerbaar aantal gelijktijdige bewerkingen uitvoeren. Als het volume van gelijktijdige bewerkingen deze drempelwaarde overschrijdt, worden er nieuwe verbindingen geopend om ze te bedienen en is het mogelijk dat voor een fysieke partitie het aantal geopende verbindingen groter is dan het aantal vaste statussen. Dit gedrag wordt verwacht voor workloads die mogelijk pieken in hun operationele volume hebben. Voor de .NET SDK wordt deze configuratie ingesteld door CosmosClientOptions.MaxRequestsPerTcpConnection en voor de Java SDK kunt u deze aanpassen met DirectConnectionConfig.setMaxRequestsPerConnection.

Verbindingen worden standaard permanent onderhouden om de prestaties van toekomstige bewerkingen te verbeteren (het openen van een verbinding heeft rekenkundige overhead). Er kunnen enkele scenario's zijn waarin u verbindingen wilt sluiten die enige tijd niet worden gebruikt, omdat u weet dat dit mogelijk van invloed is op toekomstige bewerkingen. Voor de .NET SDK wordt deze configuratie ingesteld door CosmosClientOptions.IdleTcpConnectionTimeout en voor de Java SDK kunt u deze aanpassen met DirectConnectionConfig.setIdleConnectionTimeout. Het wordt niet aanbevolen om deze configuraties in te stellen op lage waarden, omdat dit ertoe kan leiden dat verbindingen vaak worden gesloten en van invloed zijn op de algehele prestaties.

Taalspecifieke implementatiedetails

Zie voor meer informatie over de implementatie van een taal:

Volgende stappen

Voor specifieke optimalisaties van sdk-platformprestaties: