Procedimientos recomendados para el SDK de Java de Azure Cosmos DB
SE APLICA A: NoSQL
En este artículo encontrará los procedimientos recomendados para usar el SDK de Java de Azure Cosmos DB. Seguir estos procedimientos le ayudará a mejorar su latencia, disponibilidad y mejorar el rendimiento general.
Lista de comprobación
Activada | Tema | Detalles o vínculos |
---|---|---|
Versión del SDK | Use siempre la versión más reciente del SDK de Azure Cosmos DB disponible para obtener un rendimiento óptimo. | |
Cliente singleton | Use una sola instancia de CosmosClient durante la vigencia de la aplicación para mejorar el rendimiento. |
|
Regions | Asegúrese de ejecutar la aplicación en la misma región de Azure que su cuenta de Azure Cosmos DB, siempre que sea posible, para reducir la latencia. Habilite de 2 a 4 regiones y replique las cuentas en varias regiones para obtener la máxima disponibilidad. Para cargas de trabajo de producción, habilite la conmutación por error administrada por el servicio. En ausencia de esta configuración, la cuenta experimentará la pérdida de la disponibilidad de escritura durante todo el tiempo que dure la interrupción de la región de escritura, ya que la conmutación por error manual no se realizará correctamente debido a la falta de conectividad con la región. Para aprender a agregar varias regiones mediante el SDK de Java, visite este vínculo. | |
Disponibilidad y conmutaciones por error | Establezca preferredRegions en SDK v4. Durante las conmutaciones por error, las operaciones de escritura se envían a la región de escritura actual y todas las lecturas se envían a la primera región de la lista de regiones preferidas. Para más información sobre la mecánica de conmutación por error regional, consulte la guía de solución de problemas de disponibilidad. | |
CPU | Es posible que experimente problemas de conectividad o disponibilidad debido a falta de recursos en el equipo cliente. Supervise el uso de la CPU en los nodos que ejecutan el cliente de Azure Cosmos DB y escale vertical u horizontalmente si el uso es muy alto. | |
Hosting | En los casos más comunes de cargas de trabajo de producción, se recomienda encarecidamente usar máquinas virtuales de al menos 4 núcleos y 8 GB de memoria siempre que sea posible. | |
Modos de conectividad | Use el modo Directo para obtener el mejor rendimiento. Para obtener instrucciones sobre cómo hacerlo, consulte la documentación del SDK V4. | |
Redes | Si usa una máquina virtual para ejecutar la aplicación, habilite las redes aceleradas en la VM para ayudar con los cuellos de botella debidos al tráfico elevado y reducir la latencia o la inestabilidad de la CPU. También puede considerar la posibilidad de usar una máquina virtual de un extremo superior en la que el uso máximo de CPU sea inferior al 70 %. | |
Agotamiento de puertos efímeros | En el caso de conexiones dispersas o esporádicas, se recomienda establecer idleEndpointTimeout en un valor superior. La propiedad idleEndpointTimeout de DirectConnectionConfig ayuda a controlar el tiempo que se cierran las conexiones sin usar. Esto reducirá el número de conexiones no utilizadas. De forma predeterminada, las conexiones inactivas a un punto de conexión se mantienen abiertas durante una hora. Si no hay solicitudes a un punto de conexión concreto durante todo el tiempo de espera del punto de conexión inactivo, el cliente directo cierra todas las conexiones a ese punto de conexión para ahorrar recursos y costos de E/S. |
|
Use el programador adecuado (evite el robo de subprocesos de E/S Eventloop de Netty) | Evite bloquear llamadas: .block() . Toda la pila de llamadas es asincrónica para beneficiarse de los patrones de API asincrónica y el uso de los subprocesos y programadores adecuados |
|
Tiempos de espera de un extremo a otro | Para obtener tiempos de espera de un extremo a otro, implemente directiva de tiempo de espera de un extremo a otro en el SDK de Java. Para más información sobre los tiempos de espera con Azure Cosmos DB visite este vínculo. | |
Lógica de reintento | Un error transitorio es un error que tiene una causa subyacente que pronto se resuelve por él mismo. Las aplicaciones que se conectan a la base de datos deberían crearse de modo que contemplen esos errores transitorios. Para controlarlos, implemente una lógica de reintento en el código en lugar de mostrarlas a los usuarios como errores de aplicación. El SDK tiene lógica integrada para controlar estos errores transitorios en solicitudes que se pueden reintentar, como operaciones de lectura o consulta. El SDK no reintentará las escrituras en caso de errores transitorios, ya que las escrituras no son idempotentes. El SDK permite a los usuarios configurar la lógica de reintento para las limitaciones. Para más información sobre qué errores se deben reintentar, visite este vínculo. | |
Almacenamiento en caché de nombres de base de datos o colección | Durante el inicio, recupere los nombres de las bases de datos y los contenedores de la configuración o almacénelos en memoria caché. Las llamadas como CosmosAsyncDatabase#read() o CosmosAsyncContainer#read() darán lugar a llamadas de metadatos al servicio, que consumen del límite de unidades de solicitud reservadas para el sistema. createDatabaseIfNotExists() también debe usarse solo una vez para configurar la base de datos. En general, estas operaciones rara vez deben realizarse. |
|
Consultas en paralelo | El SDK de Azure Cosmos DB admite la ejecución de consultas en paralelo para mejorar la latencia y el rendimiento de las consultas. Se recomienda establecer la propiedad maxDegreeOfParallelism dentro de CosmosQueryRequestsOptions en el número de particiones que tiene. Si no conoce el número de particiones, establezca el valor en -1 , ya que obtendrá la mejor latencia. Además, establezca maxBufferedItemCount en el número esperado de resultados devueltos para limitar el número de resultados capturados previamente. |
|
Retrocesos de pruebas de rendimiento | Al realizar pruebas en la aplicación, debe implementar los retrocesos a intervalos de RetryAfter . Respetar el retroceso ayuda a garantizar una cantidad mínima de tiempo en espera entre reintentos. |
|
Indización | La directiva de indexación de Azure Cosmos DB también permite especificar las rutas de acceso de documentos que se incluyen o excluyen de la indexación mediante las rutas de acceso de indexación IndexingPolicy#getIncludedPaths() y IndexingPolicy#getExcludedPaths() . Asegúrese de excluir las rutas de acceso sin utilizar de la indexación para acelerar las escrituras. Aquí encontrará un ejemplo de cómo crear índices mediante el SDK. |
|
Tamaño del documento | El cargo de la solicitud de una operación determinada se correlaciona directamente con el tamaño del documento. Se recomienda reducir el tamaño de los documentos, ya que las operaciones en documentos grandes cuestan más que las operaciones en documentos más pequeños. | |
Tamaño de página | De forma predeterminada, los resultados se devuelven en fragmentos de 4 MB o de 100 elementos, el límite que se alcance primero. Si una consulta va a devolver más de 100 elementos, aumente el tamaño de página para reducir el número de recorridos de ida y vuelta necesarios. El consumo de memoria aumentará a medida que aumente el tamaño de página. | |
Habilitación de métricas de consulta | Para obtener un registro adicional de las ejecuciones de consultas de back-end, siga las instrucciones sobre cómo capturar métricas de consulta SQL mediante el SDK de Java. | |
Registro del SDK | Use el registro del SDK para capturar información de diagnóstico adicional y solucionar problemas de latencia. Registre CosmosDiagnostics en el SDK de Java para obtener información sobre el diagnóstico de Azure Cosmos DB más detallada de la solicitud actual al servicio. Como ejemplo de caso de uso, capture diagnósticos en cualquier excepción y en las operaciones completadas si CosmosDiagnostics#getDuration() es mayor que un valor de umbral designado (es decir, si tiene un Acuerdo de Nivel de Servicio de 10 segundos, capture los diagnósticos cuando getDuration() es superior a 10 segundos). Se recomienda usar solo estos diagnósticos durante las pruebas de rendimiento. Para más información, consulte la sección sobre la captura de diagnósticos en el SDK de Java. |
|
Evite utilizar caracteres especiales en los identificadores | Algunos caracteres están restringidos y no pueden utilizarse en algunos identificadores: '/', '\', '?', '#'. La recomendación general es no utilizar ningún carácter especial en identificadores como el nombre de la base de datos, el nombre de la colección, el id de elemento o la clave de partición para evitar cualquier comportamiento inesperado. |
Procedimientos recomendados al usar el modo de puerta de enlace
Las solicitudes de Azure Cosmos DB se realizan mediante HTTPS o REST cuando se usa el modo de puerta de enlace. Están sujetas al límite de conexiones predeterminado por nombre de host o dirección IP. Es posible que tenga que ajustar maxConnectionPoolSize a otro valor (entre 100 y 1000) para que la biblioteca cliente pueda utilizar varias conexiones simultáneas con Azure Cosmos DB. En el SDK de Java v4, el valor predeterminado de GatewayConnectionConfig#maxConnectionPoolSize
es 1000. Para cambiarlo, puede establecer GatewayConnectionConfig#maxConnectionPoolSize
en un valor superior.
Prácticas recomendadas para cargas de trabajo de escritura intensiva
En el caso de cargas de trabajo con cargas útiles de operaciones de creación intensivas, establezca la opción de solicitud CosmosClientBuilder#contentResponseOnWriteEnabled()
en false
. El servicio ya no devolverá al SDK el recurso creado o actualizado. Normalmente, dado que la aplicación tiene el objeto que se crea, no necesita que el servicio lo devuelva. Todavía se puede acceder a los valores de encabezado, como un cargo de solicitud. Deshabilitar el contenido de la respuesta puede ayudar a mejorar el rendimiento, porque el SDK ya no tendrá que asignar memoria ni serializar el cuerpo de la respuesta. También reduce el uso de ancho de banda de red para mejorar más el rendimiento.
Pasos siguientes
Para más información sobre las sugerencias de rendimiento para el SDK de Java, consulte Sugerencias de rendimiento para el SDK de Java v4 de Azure Cosmos DB.
Para más información sobre cómo diseñar la aplicación para escalarla y obtener un alto rendimiento, consulte Partición y escalado en Azure Cosmos DB.
¿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, consulte la información sobre el cálculo de unidades de solicitud mediante núcleos virtuales 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.