Anslutningslägen för Azure Cosmos DB SQL SDK

  • Artikel

GÄLLER FÖR: NoSQL

Hur en klient ansluter till Azure Cosmos DB har viktiga prestandakonsekvenser, särskilt för observerade svarstider på klientsidan. Azure Cosmos DB erbjuder en enkel, öppen RESTful-programmeringsmodell via HTTPS som kallas gatewayläge. Dessutom erbjuder det ett effektivt TCP-protokoll, som också är RESTful i sin kommunikationsmodell och använder TLS för inledande autentisering och kryptering av trafik, som kallas direktläge.

Tillgängliga anslutningslägen

De två tillgängliga anslutningslägena är:

  • Gateway-läge

    Gatewayläge stöds på alla SDK-plattformar. Om ditt program körs i ett företagsnätverk med strikta brandväggsbegränsningar är gatewayläget det bästa valet eftersom det använder https-standardporten och en enda DNS-slutpunkt. Prestandaavvägningen är dock att gatewayläget innebär ytterligare ett nätverkshopp varje gång data läse från eller skrivs till Azure Cosmos DB. Vi rekommenderar också gatewayanslutningsläge när du kör program i miljöer som har ett begränsat antal socketanslutningar.

    När du använder SDK i Azure Functions, särskilt i förbrukningsplanen, bör du vara medveten om de aktuella gränserna för anslutningar.

  • Direktläge

    Direktläge stöder anslutning via TCP-protokoll, med TLS för inledande autentisering och kryptering av trafik, och ger bättre prestanda eftersom det finns färre nätverkshopp. Programmet ansluter direkt till serverdelsreplikerna. Direktläge stöds för närvarande endast på .NET- och Java SDK-plattformar.

Azure Cosmos DB-anslutningslägen

Dessa anslutningslägen villkorar i princip den väg som dataplanet begär – dokumentläsningar och skrivningar – från klientdatorn till partitioner i Azure Cosmos DB-serverdelen. Direktläge är det bästa alternativet för bästa prestanda – det gör att klienten kan öppna TCP-anslutningar direkt till partitioner i Azure Cosmos DB-serverdelen och skicka begäranden direktutan mellanhand. I Gateway-läge dirigeras däremot begäranden från klienten till en så kallad "Gateway"-server i Azure Cosmos DB-klientdelen, som i sin tur skickar ut dina begäranden till lämpliga partitioner i Azure Cosmos DB-serverdelen.

Tjänstportintervall

När du använder direktläge måste du se till att klienten har åtkomst till portar mellan 10000 och 20000 eftersom Azure Cosmos DB använder dynamiska TCP-portar. Detta är utöver gatewayportarna. När du använder direktläge på privata slutpunkter kan det fullständiga intervallet med TCP-portar – från 0 till 65535 användas av Azure Cosmos DB. Om dessa portar inte är öppna på klienten och du försöker använda TCP-protokollet kan du få felet 503 Tjänsten är inte tillgänglig.

Följande tabell visar en sammanfattning av de anslutningslägen som är tillgängliga för olika API:er och tjänstportarna som används för varje API:

Anslutningsläge Protokoll som stöds SDK:er som stöds API/tjänstport
Gateway HTTPS Alla SDK:er SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direct TCP (krypterad via TLS) .NET SDK Java SDK När du använder offentliga slutpunkter/tjänstslutpunkter: portar i intervallet 10000 till och med 20000
När du använder privata slutpunkter: portar i intervallet 0 till och med 65535

Anslutningsarkitektur för direktläge

Som beskrivs i introduktionen ansluter direct mode-klienter direkt till serverdelsnoderna via TCP-protokollet. Varje serverdelsnod representerar en replik i en replikuppsättning som tillhör en fysisk partition.

Routning

När en Azure Cosmos DB SDK i direktläge utför en åtgärd måste den matcha vilken serverdelsreplik som ska anslutas till. Det första steget är att veta vilken fysisk partition som åtgärden ska gå till, och för det hämtar SDK containerinformationen som innehåller partitionsnyckeldefinitionen från en Gateway-nod. Den behöver också den routningsinformation som innehåller replikernas TCP-adresser. Routningsinformationen är också tillgänglig från gatewaynoder och båda betraktas som kontrollplansmetadata. När SDK:t hämtar routningsinformationen kan den fortsätta att öppna TCP-anslutningarna till replikerna som tillhör den fysiska målpartitionen och köra åtgärderna.

Varje replikuppsättning innehåller en primär replik och tre sekundärfiler. Skrivåtgärder dirigeras alltid till primära repliknoder medan läsåtgärder kan hanteras från primära eller sekundära noder.

Diagram som visar hur SD K i direktläge hämtar containern och routningsinformationen från gatewayen innan T C P-anslutningarna öppnas till serverdelsnoderna

Eftersom containern och routningsinformationen inte ändras ofta cachelagras den lokalt på SDK:erna så att efterföljande åtgärder kan dra nytta av den här informationen. De TCP-anslutningar som redan har upprättats återanvänds också i olika åtgärder. Om inget annat konfigureras via alternativen för SDK:er underhålls anslutningarna permanent under SDK-instansens livslängd.

Precis som med alla distribuerade arkitekturer kan datorer som innehåller repliker genomgå uppgraderingar eller underhåll. Tjänsten säkerställer att replikuppsättningen bibehåller konsekvensen, men eventuella replikförflyttningar gör att befintliga TCP-adresser ändras. I dessa fall måste SDK:erna uppdatera routningsinformationen och återansluta till de nya adresserna via nya Gateway-begäranden. Dessa händelser bör inte påverka det övergripande serviceavtalet för P99.

Volym med anslutningar

Varje fysisk partition har en replikuppsättning på fyra repliker. För att ge bästa möjliga prestanda öppnas anslutningar till alla repliker för arbetsbelastningar som blandar skriv- och läsåtgärder. Samtidiga åtgärder belastningsutjämnas mellan befintliga anslutningar för att dra nytta av det dataflöde som varje replik tillhandahåller.

Det finns två faktorer som avgör hur många TCP-anslutningar som SDK:t ska öppna:

  • Antal fysiska partitioner

    I ett stabilt tillstånd har SDK en anslutning per replik per fysisk partition. Ju större antalet fysiska partitioner i en container, desto större blir antalet öppna anslutningar. När åtgärder dirigeras mellan olika partitioner upprättas anslutningar på begäran. Det genomsnittliga antalet anslutningar skulle då vara antalet fysiska partitioner gånger fyra.

  • Volym av samtidiga begäranden

    Varje upprättad anslutning kan hantera ett konfigurerbart antal samtidiga åtgärder. Om volymen av samtidiga åtgärder överskrider det här tröskelvärdet är nya anslutningar öppna för att betjäna dem, och det är möjligt att antalet öppna anslutningar för en fysisk partition överskrider det konstanta tillståndet. Det här beteendet förväntas för arbetsbelastningar som kan ha toppar i driftvolymen. För .NET SDK anges den här konfigurationen av CosmosClientOptions.MaxRequestsPerTcpConnection och för Java SDK kan du anpassa med DirectConnectionConfig.setMaxRequestsPerConnection.

Som standard underhålls anslutningar permanent för att gynna prestandan för framtida åtgärder (att öppna en anslutning har beräkningskostnader). Det kan finnas scenarier där du kanske vill stänga anslutningar som inte används under en viss tid för att förstå att detta kan påverka framtida åtgärder något. För .NET SDK anges den här konfigurationen av CosmosClientOptions.IdleTcpConnectionTimeout och för Java SDK kan du anpassa med DirectConnectionConfig.setIdleConnectionTimeout. Vi rekommenderar inte att du ställer in dessa konfigurationer på låga värden eftersom det kan leda till att anslutningar stängs ofta och påverkar övergripande prestanda.

Information om språkspecifik implementering

Mer implementeringsinformation om ett språk finns i:

Nästa steg

För specifika prestandaoptimeringar för SDK-plattformen: