Partilhar via

Os modos de conectividade do Azure Cosmos DB SQL SDK

  • Aplica-se a: ✅ NoSQL

A forma como um cliente se liga ao Azure Cosmos DB tem importantes implicações de desempenho, especialmente para a latência observada do lado do cliente. O Azure Cosmos DB oferece um modelo simples e aberto de programação RESTful sobre HTTPS chamado modo gateway. Além disso, oferece um protocolo TCP eficiente, que também é RESTful no seu modelo de comunicação e utiliza TLS para autenticação inicial e encriptação do tráfego, chamado modo direto .

Modos de conectividade disponíveis

Os dois modos de conectividade disponíveis são:

  • Modo Gateway

    O modo gateway é suportado em todas as plataformas SDK. Se a sua aplicação correr dentro de uma rede corporativa com restrições rigorosas de firewall, o modo gateway é a melhor escolha porque utiliza a porta HTTPS padrão e um único endpoint DNS. A desvantagem de desempenho, no entanto, é que o modo gateway envolve um salto extra de rede sempre que dados são lidos ou escritos no Azure Cosmos DB. Recomendamos também o modo de ligação gateway quando executa aplicações em ambientes com um número limitado de ligações socket.

    Quando usar o SDK no Azure Functions, especialmente no plano de Consumo, esteja atento aos limites atuais nas conexões.

  • Modo direto

    O modo direto suporta conectividade através do protocolo TCP, usando TLS para autenticação inicial e encriptação do tráfego, e oferece melhor desempenho porque há menos saltos na rede. A aplicação liga-se diretamente às réplicas do backend. O modo direto é atualmente suportado apenas em plataformas .NET e Java SDK.

Diagrama dos modos de conectividade da base de dados Azure Cosmos.

Estes modos de conectividade condicionam essencialmente a rota que os pedidos de planos de dados (leituras e escritas de documentos) seguem da sua máquina cliente para as partições no backend do Azure Cosmos DB. O modo direto é a opção preferida para melhor desempenho; permite ao seu cliente abrir ligações TCP diretamente para partições no backend Azure Cosmos DB e enviar pedidos diretamentesem intermediários. Em contraste, no modo gateway, os pedidos feitos pelo seu cliente são encaminhados para um chamado servidor Gateway no frontend Azure Cosmos DB, que por sua vez dispersa os seus pedidos para as partições apropriadas no backend Azure Cosmos DB.

Intervalos de portos de serviço

Quando usas o modo direto, tens de garantir que o teu cliente pode aceder a portas que variam entre 10.000 e 20.000, porque o Azure Cosmos DB usa portas TCP dinâmicas. Isto é além das portas de gateway. Ao usar o modo direto em endpoints privados, o Azure Cosmos DB pode usar toda a gama de portas TCP de 0 a 65535. Se estas portas não estiverem abertas no seu cliente e tentar usar o protocolo TCP, pode receber um erro "503 Service Unavailable".

A tabela seguinte mostra um resumo dos modos de conectividade disponíveis para várias APIs e das portas de serviço usadas para cada API:

Modo de ligação Protocolo suportado SDKs suportados Porta do Serviço/API
Gateway HTTPS Todos os SDKs SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443)
Direto TCP (Encriptado via TLS) .NET SDK Java SDK Quando utilizar pontos finais públicos/de serviço: portas no intervalo 10 000 a 20 000

Quando utilizar pontos finais privados: portas no intervalo 0 a 65 535

Arquitetura de ligação em modo direto

Como detalhado na introdução, os clientes em modo direto ligam-se diretamente aos nós do backend através do protocolo TCP. Cada nó backend representa uma réplica num conjunto de réplicas pertencente a uma partição física.

Roteamento

Quando um SDK do Azure Cosmos DB em modo direto realiza uma operação, precisa de determinar a que réplica de backend se deve ligar. O primeiro passo é saber para qual partição física deve ir a operação e, para isso, o SDK obtém as informações do contenedor que incluem a definição da chave de partição a partir de um nó gateway. Também necessita das informações de roteamento que contêm os endereços TCP das réplicas. A informação de encaminhamento também está disponível a partir de nós de gateway, e ambos são considerados metadados do plano de controlo. Uma vez que o SDK obtém a informação de encaminhamento, pode avançar para abrir as ligações TCP às réplicas pertencentes à partição física alvo e executar as operações.

Cada conjunto de réplicas contém uma réplica primária e três secundárias. As operações de escrita são sempre encaminhadas para nós de réplica primária, enquanto as operações de leitura podem ser atendidas por nós primários ou secundários.

Diagrama que mostra como o SDK, em modo direto, recupera o contentor e a informação de encaminhamento do Gateway antes de abrir as ligações TCP aos nós do backend.

Como a informação do contentor e do encaminhamento não muda frequentemente, é armazenada em cache localmente nos SDKs para que operações subsequentes possam beneficiar desta informação. As ligações TCP já estabelecidas também são reutilizadas em todas as operações. A menos que seja configurado de outra forma através das opções do SDK, as ligações são mantidas permanentemente durante a vida útil da instância do SDK.

Como em qualquer arquitetura distribuída, as máquinas que detêm réplicas podem passar por atualizações ou manutenção. O serviço assegura que o conjunto de réplicas mantém a consistência, mas qualquer movimento da réplica faria com que os endereços TCP existentes mudassem. Nestes casos, os SDKs precisam de atualizar a informação de encaminhamento e reconectar-se aos novos endereços através de novos pedidos de gateway. Estes eventos não devem afetar o SLA geral do P99.

Volume de ligações

Cada partição física tem um conjunto réplica de quatro réplicas; para proporcionar o melhor desempenho possível, os SDKs acabam por abrir ligações a todas as réplicas para cargas de trabalho que combinam operações de escrita e leitura. As operações concorrentes são equilibradas na carga entre conexões existentes para aproveitar a largura de banda que cada réplica proporciona.

Existem dois fatores que ditam o número de ligações TCP que o SDK abre:

  • Número de partições físicas

    Num estado estacionário, o SDK tem uma ligação por réplica por partição física. Quanto maior o número de partições físicas num contentor, maior o número de ligações abertas. À medida que as operações são encaminhadas entre diferentes partições, são estabelecidas ligações sob demanda. O número médio de ligações seria então o número de partições físicas multiplicadas por quatro.

  • Volume de pedidos simultâneos

    Cada ligação estabelecida pode servir um número configurável de operações concorrentes. Se o volume de operações concorrentes ultrapassar este limiar, novas ligações ficam abertas para as servir, e é possível que, para uma partição física, o número de ligações abertas exceda o número de estado estacionário. Este comportamento é esperado para cargas de trabalho que possam apresentar picos no volume operacional. Para o .NET SDK, esta configuração é definida pelo MaxRequestsPerTcpConnection, e para o Java SDK pode personalizar usando a classe DirectConnectionConfig.

Por defeito, as ligações são mantidas permanentemente para beneficiar o desempenho das operações futuras (abrir uma ligação tem sobrecarga computacional). Pode haver alguns cenários em que queiras fechar ligações que não são utilizadas há algum tempo, percebendo que isso pode afetar ligeiramente as operações futuras. Para o SDK .NET, esta configuração é definida pelo IdleTcpConnectionTimeout, e para o SDK Java pode personalizar usando a classe DirectConnectionConfig. Não é recomendado definir estas configurações para valores baixos, pois isso pode causar o encerramento frequente das ligações e afetar o desempenho geral.

Detalhes de implementação específicos do idioma

Para obter detalhes de implementação sobre um idioma, consulte:

Próximos passos

Para otimizações específicas de desempenho da plataforma SDK:

Tentando fazer o planejamento de capacidade para uma migração para o Azure Cosmos DB? Você pode usar informações sobre seu cluster de banco de dados existente para planejamento de capacidade.

  • Last updated on