Modalità di connettività di Azure Cosmos DB SQL SDK
SI APPLICA A: 
NoSQL
La modalità di connessione di un client ad Azure Cosmos DB influisce significativamente sulle prestazioni, in particolare in termini di latenza lato client osservata. Azure Cosmos DB offre un modello di programmazione RESTful semplice e aperto tramite HTTPS denominato modalità gateway. Inoltre, offre un protocollo TCP efficiente, che è anche RESTful nel modello di comunicazione e usa TLS per l'autenticazione iniziale e la crittografia del traffico, denominata modalità diretta.
Modalità di connettività disponibili
Le due modalità di connettività disponibili sono:
Modalità gateway
La modalità gateway è supportata in tutte le piattaforme SDK. Se l'applicazione viene eseguita all'interno di una rete aziendale con restrizioni del firewall rigorose, la modalità gateway è la scelta migliore perché usa la porta HTTPS standard e un singolo endpoint DNS. A livello di prestazioni, tuttavia, la modalità Gateway prevede un hop di rete aggiuntivo ogni volta che i dati vengono letti o scritti in Azure Cosmos DB. È anche consigliabile usare la modalità di connessione gateway quando si eseguono applicazioni in ambienti con un numero limitato di connessioni socket.
Quando si usa l'SDK in Funzioni di Azure, in particolare nel piano a consumo, tenere presente i limiti correnti sulle connessioni.
Modalità diretta
La modalità diretta supporta la connettività tramite protocollo TCP, l'uso di TLS per l'autenticazione iniziale e la crittografia del traffico e offre prestazioni migliori perché sono presenti meno hop di rete. L'applicazione si connette direttamente alle repliche back-end. La modalità diretta è attualmente supportata solo nelle piattaforme .NET e Java SDK.
Queste modalità di connettività in pratica condizionano la route richiesta dal piano dati, ovvero le letture e le scritture, dal computer client alle partizioni nel back-end di Azure Cosmos DB. La modalità diretta è la soluzione preferita per ottenere prestazioni ottimali. Consente al client di aprire connessioni TCP dirette alle partizioni nel back-end di Azure Cosmos DB e inviare richieste direttamente, senza intermediari. Al contrario, in modalità Gateway, le richieste effettuate dal client vengono instradate a un cosiddetto server "Gateway" nel front-end di Azure Cosmos DB, che a sua volta esegue il fan out delle richieste a una o più partizioni appropriate nel back-end di Azure Cosmos DB.
Intervalli di porte del servizio
Quando si usa la modalità diretta, è necessario assicurarsi che il client possa accedere alle porte comprese tra 10000 e 20000 perché Azure Cosmos DB usa porte TCP dinamiche. Oltre alle porte del gateway. Quando si usa la modalità diretta su endpoint privati, l'intera gamma di porte TCP, da 0 a 65535 può essere usata da Azure Cosmos DB. Se queste porte non sono aperte nel client e si tenta di usare il protocollo TCP, è possibile che venga visualizzato un errore 503 Servizio non disponibile.
La tabella seguente mostra un riepilogo delle modalità di connettività disponibili per varie API e le porte del servizio usate per ogni API:
| Modalità di connessione | Protocollo supportato | SDK supportati | API/porta servizio |
|---|---|---|---|
| Gateway | HTTPS | Tutti gli SDK | SQL (443), MongoDB (10255), Tabella (443), Cassandra (10350), Grafo (443) |
| Diretto | TCP (crittografato tramite TLS) | .NET SDK Java SDK | Quando si usano endpoint pubblici/di servizio: porte nell'intervallo compreso tra 10000 e 20000 Quando si usano endpoint privati: porte nell'intervallo compreso tra 0 e 65535 |
Architettura di connessione in modalità diretta
Come descritto in dettaglio nell'introduzione, i client in modalità diretta si connetteranno direttamente ai nodi back-end tramite il protocollo TCP. Ogni nodo back-end rappresenta una replica in un set di repliche appartenente a una partizione fisica.
Definizione dei percorsi di trasferimento
Quando un SDK di Azure Cosmos DB in modalità diretta esegue un'operazione, deve risolvere la replica back-end a cui connettersi. Il primo passaggio consiste nel sapere quale partizione fisica deve passare all'operazione e, per tale motivo, l'SDK ottiene le informazioni sul contenitore che includono la definizione della chiave di partizione da un nodo gateway. Sono necessarie anche le informazioni di routing che contengono gli indirizzi TCP delle repliche. Le informazioni di routing sono disponibili anche dai nodi del gateway ed entrambi sono considerati metadati del piano di controllo. Dopo aver ottenuto le informazioni di routing, l'SDK può procedere all'apertura delle connessioni TCP alle repliche appartenenti alla partizione fisica di destinazione ed eseguire le operazioni.
Ogni set di repliche contiene una replica primaria e tre repliche secondarie. Le operazioni di scrittura vengono sempre instradate ai nodi di replica primaria, mentre le operazioni di lettura possono essere gestite da nodi primari o secondari.
Poiché le informazioni sul contenitore e sul routing non cambiano spesso, vengono memorizzate nella cache localmente negli SDK, in modo che le operazioni successive possano trarre vantaggio da queste informazioni. Le connessioni TCP già stabilite vengono riutilizzate anche tra le operazioni. Se non diversamente configurato tramite le opzioni degli SDK, le connessioni vengono mantenute in modo permanente durante la durata dell'istanza dell'SDK.
Come per qualsiasi architettura distribuita, i computer che contengono repliche potrebbero subire aggiornamenti o manutenzione. Il servizio garantirà che il set di repliche mantenga la coerenza, ma qualsiasi spostamento di replica causerebbe la modifica degli indirizzi TCP esistenti. In questi casi, gli SDK devono aggiornare le informazioni di routing e riconnettersi ai nuovi indirizzi tramite nuove richieste di gateway. Questi eventi non devono influire sul contratto di servizio P99 complessivo.
Volume di connessioni
Ogni partizione fisica ha un set di quattro repliche, per garantire prestazioni ottimali; gli SDK aprono connessioni a tutte le repliche per i carichi di lavoro che combinano operazioni di scrittura e lettura. Le operazioni simultanee vengono bilanciate tra le connessioni esistenti per sfruttare la velocità effettiva fornita da ogni replica.
Esistono due fattori che determinano il numero di connessioni TCP che verranno aperte dall'SDK:
Numero di partizioni fisiche
In uno stato stabile, l'SDK avrà una connessione per ogni replica per partizione fisica. Maggiore è il numero di partizioni fisiche in un contenitore, maggiore sarà il numero di connessioni aperte. Poiché le operazioni vengono instradate tra partizioni diverse, le connessioni vengono stabilite su richiesta. Il numero medio di connessioni sarà dato quindi dal numero di partizioni fisiche moltiplicato per quattro.
Volume di richieste simultanee
Ogni connessione stabilita può gestire un numero configurabile di operazioni simultanee. Se il volume delle operazioni simultanee supera questa soglia, le nuove connessioni saranno aperte per gestirle ed è possibile che per una partizione fisica il numero di connessioni aperte superi il numero di stato stabile. Questo comportamento è previsto per i carichi di lavoro che potrebbero avere picchi nel volume operativo. Per l'SDK .NET questa configurazione è impostata da CosmosClientOptions.MaxRequestsPerTcpConnection mentre l'SDK Java può essere personalizzato usando DirectConnectionConfig.setMaxRequestsPerConnection.
Per impostazione predefinita, le connessioni vengono mantenute in modo permanente per migliorare le prestazioni delle operazioni future (l'apertura di una connessione comporta un sovraccarico di calcolo). Potrebbero verificarsi alcuni scenari in cui potrebbe essere necessario chiudere le connessioni inutilizzate per un certo periodo di tempo comprendendo che ciò potrebbe influire leggermente sulle operazioni future. Per l'SDK .NET questa configurazione è impostata da CosmosClientOptions.IdleTcpConnectionTimeout mentre l'SDK Java può essere personalizzato usando DirectConnectionConfig.setIdleConnectionTimeout. Non è consigliabile impostare queste configurazioni su valori bassi perché potrebbero causare la chiusura frequente delle connessioni e influire sulle prestazioni complessive.
Dettagli di implementazione specifici per lingua
Per ottenere maggiori informazioni sui dettagli di implementazione relativi a una lingua, vedere:
Passaggi successivi
Per ottimizzazioni specifiche delle prestazioni della piattaforma SDK:
Suggerimenti per incrementare le prestazioni dell'SDK .NET V2
Si sta tentando di pianificare la capacità per una migrazione ad Azure Cosmos DB? È possibile usare le informazioni del cluster di database esistente per la pianificazione della capacità.
- Se si conosce solo il numero di vcore e server nel cluster di database esistente, leggere le informazioni sulla stima delle unità richieste usando vCore o vCPU
- Se si conosce la frequenza delle richieste tipiche per il carico di lavoro corrente del database, leggere le informazioni sulla stima delle unità richieste con lo strumento di pianificazione della capacità di Azure Cosmos DB