Modos de conectividad de SDK de SQL de Azure Cosmos DB
SE APLICA A: 
NoSQL
La forma en que un cliente se conecta a Azure Cosmos DB tiene importantes implicaciones de rendimiento, especialmente para la latencia observada en el cliente. Azure Cosmos DB ofrece un modelo de programación RESTful sencillo y abierto sobre HTTPS denominado modo de puerta de enlace. Además, ofrece un protocolo TCP eficaz, que también es RESTful en su modelo de comunicación y usa TLS para la autenticación inicial y el cifrado del tráfico, denominado modo directo.
Modos de conectividad disponibles
Los dos modos de conectividad disponibles son:
Modo de puerta de enlace
El modo de puerta de enlace se admite en todas las plataformas de SDK. Si la aplicación se ejecuta dentro de una red corporativa con restricciones de firewall estrictas, el modo de puerta de enlace es la mejor opción, ya que utiliza el puerto HTTPS estándar y un único punto de conexión DNS. La desventaja para el rendimiento, sin embargo, es que el modo de puerta de enlace implica un salto de red adicional cada vez que se leen desde o se escriben datos a Azure Cosmos DB. También se recomienda el modo de conexión de puerta de enlace cuando se ejecutan aplicaciones en entornos que tienen un número limitado de conexiones de socket.
Cuando use el SDK de Azure Functions, especialmente en el plan de consumo, tenga en cuenta los límites actuales en las conexiones.
Modo directo
El modo directo admite la conectividad mediante el protocolo TCP, y mediante TLS para la autenticación inicial y el cifrado del tráfico, y ofrece un mejor rendimiento porque hay menos saltos de red. La aplicación se conecta directamente a las réplicas de back-end. El modo directo solo se admite actualmente en plataformas SDK de .NET y Java.
En esencia, estos modos de conectividad condicionan la ruta que las solicitudes de plano de datos (lecturas y escrituras de documentos) toman desde la máquina cliente hasta las particiones en el back-end de Azure Cosmos DB. El modo directo es la opción preferida para obtener el mejor rendimiento: permite al cliente abrir conexiones TCP directamente en las particiones en el back-end de Azure Cosmos DB y enviar solicitudes directamente sin intermediarios. Por el contrario, en el modo de puerta de enlace, las solicitudes realizadas por el cliente se enrutan a un servidor denominado "puerta de enlace" en el front-end de Azure Cosmos DB que, a su vez, deriva sus solicitudes a las particiones adecuadas en el back-end de Azure Cosmos DB.
Intervalos de puertos de servicio
Al usar el modo directo, debe asegurarse de que el cliente pueda acceder a los puertos del 10 000 al 20 000, ya que Azure Cosmos DB usa puertos TCP dinámicos además los puertos de puerta de enlace. Al usar el modo directo en puntos de conexión privados, Azure Cosmos DB puede usar el intervalo completo de puertos TCP (de 0 a 65 535). Si estos puertos no están abiertos en el cliente e intenta usar el protocolo TCP, puede recibir un error 503 de servicio no disponible.
En la tabla siguiente se muestra un resumen de los modos de conectividad disponibles para varias API y los puertos de servicio que se usan para cada API:
| Modo de conexión | Protocolo admitido | SDK admitidos | API o puerto de servicio |
|---|---|---|---|
| Puerta de enlace | HTTPS | Todos los SDK | SQL (443), MongoDB (10255), Table (443), Cassandra (10350), Graph (443) |
| Directo | TCP (cifrado mediante TLS) | SDK de .NET SDK de Java | Al usar puntos de conexión de servicio o públicos: puertos en el intervalo de 10000 a 20000 Al usar puntos de conexión privados: puertos en el intervalo de 0 a 65535 |
Arquitectura de conexión en modo directo
Como se detalla en la introducción, los clientes de modo directo se conectarán directamente a los nodos de back-end mediante el protocolo TCP. Cada nodo de back-end representa una réplica de un conjunto de réplicas que pertenece a una partición física.
Enrutamiento
Cuando un SDK de Azure Cosmos DB en modo directo está realizando una operación, tiene que resolver a qué réplica de back-end se va a conectar. El primer paso es saber a qué partición física debe ir la operación y, para ello, el SDK obtiene la información del contenedor que incluye la definición de la clave de partición de un nodo de puerta de enlace. También necesita la información de enrutamiento que contiene las direcciones TCP de las réplicas. La información de enrutamiento también está disponible en los nodos de puerta de enlace y ambos se consideran metadatos de plano de control. Una vez que el SDK obtiene la información de enrutamiento, puede continuar con la apertura de las conexiones TCP a las réplicas que pertenecen a la partición física de destino y ejecutar las operaciones.
Cada conjunto de réplicas contiene una réplica principal y tres secundarias. Las operaciones de escritura siempre se enrutan a los nodos de la réplica principal mientras que las operaciones de lectura se pueden atender desde nodos principales o secundarios.
Dado que la información sobre el contenedor y el enrutamiento no suele cambiar, se copia en caché localmente en los SDK para que las operaciones posteriores puedan beneficiarse de esta información. Las conexiones TCP ya establecidas también se reutilizan entre operaciones. A menos que se configure de otro modo mediante las opciones de los SDK, las conexiones se mantienen permanentemente durante la vigencia de la instancia del SDK.
Al igual que con cualquier arquitectura distribuida, las máquinas con réplicas pueden recibir actualizaciones o mantenimiento. El servicio garantizará que el conjunto de réplicas mantenga la coherencia, pero cualquier movimiento de réplica provocaría un cambio en las direcciones TCP existentes. En estos casos, los SDK deben actualizar la información de enrutamiento y volver a conectarse a las nuevas direcciones mediante nuevas solicitudes de puerta de enlace. Estos eventos no deben afectar al Acuerdo de Nivel de Servicio general de P99.
Volumen de conexiones
Cada partición física tiene un conjunto de réplicas formado por cuatro réplicas. Para proporcionar el mejor rendimiento posible, los SDK terminarán abriendo conexiones a todas las réplicas de las cargas de trabajo que combinan operaciones de escritura y de lectura. Las operaciones simultáneas tienen equilibrio de carga entre las conexiones existentes para aprovechar el rendimiento que proporciona cada réplica.
Hay dos factores que determinan el número de conexiones TCP que abrirá el SDK:
Número de particiones físicas
En un estado estable, el SDK dispondrá de una conexión por réplica por partición física. Cuanto mayor sea el número de particiones físicas de un contenedor, mayor será el número de conexiones abiertas. A medida que las operaciones se enrutan hacia las distintas particiones, las conexiones se establecen a petición. El número medio de conexiones sería entonces cuatro veces el número de particiones físicas.
Volumen de solicitudes simultáneas
Cada conexión establecida puede atender un número configurable de operaciones simultáneas. Si el volumen de operaciones simultáneas supera este umbral, se abrirán nuevas conexiones para atenderlas y es posible que para una partición física, el número de conexiones abiertas supere el número permitido en un estado estable. Este comportamiento es previsible en las cargas de trabajo con posibles picos en su volumen de operaciones. Para el SDK de .NET, esta configuración la establece CosmosClientOptions.MaxRequestsPerTcpConnection y, para el SDK de Java, puede personalizarla mediante DirectConnectionConfig.setMaxRequestsPerConnection.
De forma predeterminada, las conexiones se mantienen permanentemente para beneficiar el rendimiento de las operaciones futuras (la apertura de una conexión conlleva sobrecarga computacional). Puede que haya algunos escenarios en los que es posible que desee cerrar las conexiones que no se han usado durante algún tiempo, ya que esto podría afectar ligeramente a las operaciones futuras. Para el SDK de .NET, esta configuración la establece CosmosClientOptions.IdleTcpConnectionTimeout y, para el SDK de Java, puede personalizarla mediante DirectConnectionConfig.setIdleConnectionTimeout. No es recomendable establecer estas configuraciones en valores bajos, ya que puede provocar que las conexiones se cierren con frecuencia y afecten al rendimiento general.
Detalles de implementación específicos del lenguaje
Para más detalles sobre la implementación de un lenguaje específico, consulte:
Pasos siguientes
Para las optimizaciones de rendimiento específico de la plataforma SDK:
¿Intenta planear la capacidad de una migración a Azure Cosmos DB? Para ello, puede usar información sobre el clúster de bases de datos existente.
- Si lo único que sabe es el número de núcleos virtuales y servidores del clúster de bases de datos existente, lea sobre el cálculo de unidades de solicitud mediante núcleos o CPU virtuales.
- Si conoce las tasas de solicitudes típicas de la carga de trabajo de la base de datos actual, obtenga información sobre el cálculo de unidades de solicitud mediante la herramienta de planeamiento de capacidad de Azure Cosmos DB.