Niveles de coherencia en Azure Cosmos DB

SE APLICA A: NoSQL MongoDB Cassandra Gremlin Table

Las bases de datos distribuidas que dependen de la replicación para alta disponibilidad, baja latencia o ambas, deben equilibrar la coherencia de lectura, la disponibilidad, la latencia y el rendimiento, tal como se define en el teorema de PACELC. La linearización del modelo de coherencia fuerte es el estándar de oro de la programación de datos, pero agrega un precio excesivo a las latencias de escritura mayores debido a que los datos tienen que replicarse y confirmarse entre grandes distancias. Una coherencia fuerte también puede verse afectada por una disponibilidad reducida (durante errores) porque los datos no se puedan replicar y confirmar en cada región. La coherencia posible ofrece una mayor disponibilidad y un mejor rendimiento, pero es más difícil programar aplicaciones porque es posible que los datos no sean totalmente coherentes en todas las regiones.

La mayoría de las bases de datos NoSQL distribuidas disponibles comercialmente en el mercado hoy en día solo ofrecen coherencia fuerte y posible. Azure Cosmos DB ofrece cinco niveles bien definidos. De más fuerte a más débil, los niveles son:

Para más información sobre el nivel de coherencia predeterminado, consulte Configuración del nivel de coherencia predeterminado o Invalidación del nivel de coherencia predeterminado.

Cada nivel proporciona equilibrio entre la disponibilidad y el rendimiento. En la imagen siguiente se muestran los distintos niveles de coherencia como un espectro.

Coherencia como espectro

Niveles de coherencia y API de Azure Cosmos DB

Azure Cosmos DB también proporciona compatibilidad nativa con las API compatibles con el protocolo de conexión para bases de datos populares. Entre ellas se incluyen MongoDB, Apache Cassandra, Apache Gremlin y Azure Table Storage. Al usar la API para Gremlin o Table, se usa el nivel de coherencia predeterminado configurado en la cuenta de Azure Cosmos DB. Para más detalles sobre la asignación del nivel de coherencia entre Apache Cassandra y Azure Cosmos DB, consulte Asignación de coherencia de la API para Cassandra. Para más detalles sobre la asignación del nivel de coherencia entre MongoDB y Azure Cosmos DB, consulte Asignación de coherencia de la API para MongoDB.

Ámbito de la coherencia de lectura

La coherencia de lectura se aplica a una sola operación de lectura limitada a una partición lógica. Un cliente remoto o un procedimiento almacenado pueden emitir la operación de lectura.

Configuración del nivel de coherencia predeterminado

Puede configurar el nivel de coherencia predeterminado de su cuenta de Azure Cosmos DB en cualquier momento. El nivel de coherencia predeterminado configurado en su cuenta se aplica a todas las bases de datos y contenedores de Azure Cosmos DB de esa cuenta. Todas las operaciones de lectura y consulta que se emitan con arreglo a un contenedor o una base de datos usan el nivel de coherencia especificado de forma predeterminada. Para más información, consulte cómo configurar el nivel de coherencia predeterminado. También puede invalidar el nivel de coherencia predeterminado para una solicitud específica. Para obtener más información, consulte el artículo Invalidación del nivel de coherencia predeterminado.

Sugerencia

La invalidación del nivel de coherencia predeterminado solo se aplica a las lecturas dentro del cliente del SDK. Una cuenta configurada para una coherencia fuerte, de manera predeterminada sigue escribiendo y replicando datos de forma sincrónica en todas las regiones de la cuenta. Cuando la instancia o solicitud del cliente del SDK invalida esta configuración con el valor De sesión o uno más débil, las lecturas se realizan con una única réplica. Para más información, consulte Rendimiento y niveles de coherencia.

Importante

Es necesario volver a crear cualquier instancia de SDK después de cambiar el nivel de coherencia predeterminado. Para ello, reinicie la aplicación. Esto garantiza que el SDK usa el nuevo nivel de coherencia predeterminado.

Garantías asociadas a los niveles de coherencia

Azure Cosmos DB garantiza que el 100 por ciento de las solicitudes de lectura cumplan con la garantía de coherencia del nivel de coherencia que elija. Las definiciones precisas de los cinco niveles de coherencia de Azure Cosmos DB que usan el lenguaje de especificación TLA+ se proporcionan en el repositorio azure-cosmos-tla de GitHub.

En las secciones siguientes se describe la semántica de los cinco niveles de coherencia.

Coherencia fuerte

La coherencia fuerte ofrece una garantía de linearización. La linearización hace referencia a la capacidad de servir solicitudes simultáneamente. Se garantiza que las lecturas devuelven la versión más reciente de un elemento. Un cliente nunca ve una escritura no confirmada ni parcial. Se garantiza que los usuarios siempre leerán la escritura confirmada más reciente.

En el gráfico siguiente se ilustra la coherencia fuerte con notas musicales. Una vez que los datos se han escrito en la región "Oeste de EE. UU. 2", al leer los datos de otras regiones, obtiene el valor más reciente:

Ilustración del nivel de coherencia fuerte

Coherencia de obsolescencia limitada

Para las cuentas de escritura de una sola región con dos o más regiones, los datos se replican desde la región primaria a todas las regiones secundarias (solo lectura). En el caso de las cuentas de escritura de varias regiones con dos o más regiones, los datos se replican desde la región en la que se escribió originalmente en todas las demás regiones grabables. En ambos escenarios, aunque no es habitual, puede haber ocasionalmente un retraso de replicación de una región a otra.

En la coherencia de obsolescencia limitada, los datos entre dos regiones no tardarán más de "K" versiones (es decir, "actualizaciones") de un elemento o por intervalos de tiempo "T", lo que se alcance primero. En otras palabras, cuando se elige la obsolescencia limitada, la "caducidad" máxima de los datos en cualquier región puede configurarse de dos maneras:

  • El número de versiones (K) del elemento
  • El intervalo de tiempo (T) que las lecturas pueden retrasarse con respecto a las escrituras

La obsolescencia limitada es beneficiosa principalmente para las cuentas de escritura de una sola región con dos o más regiones. Si el retraso de datos en una región (determinado por partición física) excede el valor de estancamiento configurado, las escrituras para esa partición serán estranguladas hasta que el estancamiento vuelva a estar dentro del límite superior configurado.

En el caso de una cuenta de una sola región, a obsolescencia limitada proporciona las mismas garantías de coherencia de escritura que la coherencia final y la coherencia final con los datos que se replican en una mayoría local (tres réplicas en un conjunto de cuatro réplicas) en la única región.

Importante

Con la coherencia de obsolescencia limitada, las comprobaciones de obsolescencia solo se realizan entre regiones y no dentro de una región. Dentro de una región determinada, los datos siempre se replican en una mayoría local (tres réplicas en un conjunto de cuatro réplicas) independientemente del nivel de coherencia.

Las lecturas al usar obsolescencia limitada devolverán los datos más recientes disponibles en esa región mediante la lectura de dos réplicas disponibles en esa región. Como las escrituras dentro de una región siempre se replican a una mayoría local (3 de 4 réplicas), la consulta de dos réplicas devolverá los datos más actualizados disponibles en esa región.

Importante

Con la coherencia de obsolescencia limitada, es posible que las lecturas emitidas en una región no primaria no devuelvan necesariamente la versión más reciente de los datos globalmente, pero se garantiza que devuelvan la versión más reciente de los datos de esa región, que estará dentro del límite máximo de obsolescencia globalmente.

La obsolescencia limitada funciona mejor para las aplicaciones distribuidas globalmente mediante cuentas de escritura de una sola región con dos o más regiones, donde se desea una coherencia casi sólida entre regiones. En el caso de las cuentas de escritura en varias regiones con dos o más regiones, los servidores de aplicaciones deben dirigir las lecturas y escrituras a la misma región en la que se hospedan los servidores de aplicaciones. Por lo tanto, la obsolescencia limitada en una cuenta de varias escrituras es un antipatrón, ya que requeriría una dependencia del retraso de replicación entre regiones, lo que no debe importar si los datos se leen de la misma región en la que se escribió.

En el gráfico siguiente se ilustra la coherencia de obsolescencia limitada con notas musicales. Una vez que los datos se han escrito en la región "Oeste de EE. UU. 2", las regiones "Este de EE. UU. 2" y "Este de Australia" leen el valor escrito según el tiempo de retardo máximo configurado o las operaciones máximas:

Ilustración del nivel de coherencia de obsolescencia limitada

Coherencia de sesión

En la coherencia de sesión, en una sesión de cliente individual, se garantiza que las lecturas respeten las garantías de lectura de las escrituras y escritura tras las lecturas. Aquí se da por hecho una sesión de "escritor" individual o el uso compartido del token de sesión para varios escritores.

Al igual que todos los niveles de coherencia más débiles que los seguros, las escrituras se replican en un mínimo de tres réplicas (en un conjunto de cuatro réplicas) en la región local, con replicación asincrónica en todas las demás regiones.

Después de cada operación de escritura, el cliente recibe un token de sesión actualizado del servidor. El cliente almacena en caché estos tokens y los envía al servidor para las operaciones de lectura en una región especificada. Si la réplica en la que se emite la operación de lectura contiene datos para el token especificado (o un token más reciente), se devuelven los datos solicitados. Si la réplica no contiene datos para esa sesión, el cliente reintentará la solicitud en otra réplica de la región. Si es necesario, el cliente reintentará la lectura en las regiones disponibles adicionales hasta que se recuperen los datos del token de sesión especificado.

Importante

En la coherencia de sesión, el uso por parte del cliente de un token de sesión garantiza que nunca se leerán los datos correspondientes a una sesión anterior. Sin embargo, si el cliente usa un token de sesión anterior y se han realizado actualizaciones más recientes en la base de datos, se devolverá la versión más reciente de los datos a pesar de que se use un token de sesión anterior. El token de sesión se usa como una barrera de versión mínima, pero no como una versión específica (posiblemente histórica) de los datos que se van a recuperar de la base de datos.

Si el cliente no inició una escritura en una partición física, no contendrá un token de sesión en su caché y las lecturas de esa partición física se comportarán como lecturas con coherencia final. Del mismo modo, si se vuelve a crear el cliente, también se volverá a crear su caché de tokens de sesión. Aquí también, las operaciones de lectura seguirán el mismo comportamiento que en la coherencia final hasta que las operaciones de escritura posteriores vuelvan a crear la memoria caché de tokens de sesión del cliente.

Importante

Si los tokens de sesión se pasan de una instancia del cliente a otra, no se debe modificar el contenido del token.

La coherencia de la sesión es el nivel de coherencia más usado para regiones únicas, así como para aplicaciones distribuidas globalmente. Proporciona latencias de escritura, disponibilidad y rendimiento de lectura equiparables a los de la coherencia final, pero también proporciona las garantías de coherencia que satisfacen las necesidades de aplicaciones escritas para funcionar en el contexto de un usuario. En el gráfico siguiente se ilustra la coherencia de la sesión con notas musicales. El "escritor de Oeste de EE. UU. 2" y el "lector de Este de EE. UU. 2" usan la misma sesión (sesión A), por lo que ambos leen los mismos datos al mismo tiempo. Sin embargo, la región "Este de Australia" usa la "sesión B", por lo que recibe los datos más tarde pero en el mismo orden en que se escriben.

Ilustración del nivel de coherencia de sesión

Coherencia de prefijo coherente

Al igual que todos los niveles de coherencia más débiles que los seguros, las escrituras se replican en un mínimo de tres réplicas (en un conjunto de cuatro réplicas) en la región local, con replicación asincrónica en todas las demás regiones.

En prefijo coherente, las actualizaciones hechas como escrituras de documentos únicos ven la coherencia final. Novedades hechas como un lote dentro de una transacción, se devuelven coherentes con la transacción en la que se confirmaron. Las operaciones de escritura dentro de una transacción de varios documentos siempre están visibles juntas.

Supongamos que dos operaciones de escritura se realizan transaccionalmente (operaciones todo o nada) en el documento Doc1 seguido del documento Doc2, dentro de las transacciones T1 y T2. Cuando el cliente hace una lectura en cualquier réplica, el usuario verá "Doc1 v1 y Doc2 v1" o " Doc1 v2 y Doc2 v2" o ningún documento si la réplica lleva un retraso, pero nunca "Doc1 v1 y Doc2 v2" ni "Doc1 v2 y Doc2 v1" en la misma operación de lectura o consulta.

En el gráfico siguiente se ilustra la coherencia del prefijo de coherencia con notas musicales. En todas las regiones, las lecturas nunca ven escrituras desordenadas para un lote transaccional de escrituras:

Ilustración de prefijo coherente

Coherencia final

Al igual que todos los niveles de coherencia más débiles que los seguros, las escrituras se replican en un mínimo de tres réplicas (en un conjunto de cuatro réplicas) en la región local, con replicación asincrónica en todas las demás regiones.

En la coherencia final, el cliente emitirá solicitudes de lectura en cualquiera de las cuatro réplicas de la región especificada. Esta réplica puede llevar un retraso y podría devolver datos obsoletos o ningún dato.

La coherencia final es la forma más débil de coherencia, ya que un cliente puede leer los valores que son más antiguos que los que había leído antes. La coherencia final es adecuada cuando la aplicación no requiere ninguna garantía de ordenación. Entre los ejemplos se incluye el recuento de retweets, Me gusta o comentarios no encadenados. En el gráfico siguiente se ilustra la coherencia final con notas musicales.

Ilustración de coherencia final

Garantías de coherencia en la práctica

En la práctica, es posible que obtenga mayores garantías de coherencia. Las garantías de coherencia para una operación de lectura se corresponden con la actualización y el orden del estado de la base de datos que solicita. La coherencia de lectura está asociada con la ordenación y la propagación de las operaciones de escritura/actualización.

Si no hay ninguna operación de escritura en la base de datos, una operación de lectura con los niveles de coherencia posible, sesión o prefijo coherente es probable que produzca los mismos resultados que una operación de lectura con el nivel de coherencia alto.

Si la cuenta de Azure Cosmos DB está configurada con un nivel de coherencia que no es el de coherencia alta, puede averiguar la probabilidad de que los clientes obtengan lecturas de coherencia alta para sus cargas de trabajo consultando la métrica de obsolescencia limitada de manera probabilística (PBS). Esta métrica se expone en Azure Portal; para obtener más información, consulte Supervisión de la métrica de obsolescencia limitada de manera probabilística (PBS).

La obsolescencia limitada de probabilidad muestra cómo de posible es la coherencia final. Esta métrica proporciona una visión general de la frecuencia con la que puede obtener una coherencia mayor que el nivel de coherencia que tiene configurado actualmente en su cuenta de Azure Cosmos DB. En otras palabras, puede ver la probabilidad (en milisegundos) de obtener lecturas con coherencia alta para una combinación de regiones de escritura y lectura.

Latencia y niveles de coherencia

Se garantiza que la latencia de lectura de todos los niveles de coherencia siempre es inferior a 10 milisegundos en el percentil 99. La latencia media de lectura (en el percentil 50) es normalmente de cuatro milisegundos o menos.

Se garantiza que la latencia de escritura de todos los niveles de coherencia siempre sea inferior a 10 milisegundos en el percentil 99. La latencia media de escritura (en el percentil 50) es normalmente de cinco milisegundos o menos. Las cuentas de Azure Cosmos DB que abarcan varias regiones y están configuradas con una coherencia alta son una excepción a esta garantía.

Latencia de escritura y coherencia fuerte

Para las cuentas de Azure Cosmos DB configuradas con coherencia sólida con más de una región, la latencia de escritura es igual al doble del tiempo de ida y vuelta (RTT) entre cualquiera de las dos regiones más alejadas, más de diez milisegundos en el percentil 99. El RTT de red alto entre las regiones se traducirá a una latencia mayor para solicitudes de Azure Cosmos DB, ya que la coherencia fuerte completa una operación solo después de asegurarse de que se ha confirmado en todas las regiones de una cuenta.

La latencia de RTT exacta depende de la distancia a la velocidad de la luz y la topología de red de Azure. La red de Azure no proporciona ningún SLA de latencia para el RTT entre dos regiones de Azure, pero publica las estadísticas de latencia de recorrido de ida y vuelta de red de Azure. Para la cuenta de Azure Cosmos DB, las latencias de replicación se muestran en Azure Portal. Puede usar Azure Portal (vaya a la hoja Métrica, seleccione la pestaña Coherencia) para supervisar las latencias de replicación entre diversas regiones asociadas con su cuenta de Azure Cosmos DB.

Importante

La coherencia fuerte para las cuentas con regiones que abarcan más de 5000 millas (8000 kilómetros) se bloquea de forma predeterminada debido a una elevada latencia de escritura. Para habilitar esta funcionalidad, póngase en contacto con el soporte técnico.

Rendimiento y niveles de coherencia

  • En el caso de la obsolescencia fuerte y limitada, las lecturas se realizan en dos réplicas en un conjunto de cuatro réplicas (cuórum minoritario) para proporcionar garantías de coherencia. Los niveles de sesión, prefijo coherente y posible realizan lecturas de réplica única. El resultado es que, para el mismo número de unidades de solicitud, el rendimiento de lectura para la obsolescencia fuerte y limitada es la mitad de los demás niveles de coherencia.

  • Para un tipo determinado de operación de escritura (por ejemplo, Insert, Replace, Upsert o Delete), el rendimiento de escritura de las unidades de solicitud es idéntico para todos los niveles de coherencia. Para una coherencia fuerte, los cambios deben estar confirmados en todas las regiones (mayoría global), mientras que para todos los demás niveles de coherencia, se usa la mayoría local (tres réplicas en un conjunto de cuatro réplicas).

Nivel de coherencia Lecturas de cuórum Escrituras de cuórum
Fuerte Minoría local Mayoría global
Obsolescencia limitada Minoría local Mayoría local
De sesión Réplica única (con token de sesión) Mayoría local
De prefijo coherente Réplica única Mayoría local
Posible Réplica única Mayoría local

Nota

El costo de RU/s para lecturas minoritarias locales es el doble que el de los niveles de coherencia más débiles porque las lecturas se realizan en dos réplicas para proporcionar garantías de coherencia para la obsolescencia alta y limitada.

Durabilidad de los datos y niveles de coherencia

En un entorno de base de datos distribuida de forma global, existe una relación directa entre el nivel de coherencia y la durabilidad de los datos se produce una interrupción en toda la región. A medida que desarrolla el plan de continuidad empresarial, debe conocer el período máximo de actualizaciones de datos recientes que la aplicación puede tolerar perder al recuperarse después de un evento de interrupción. El período de tiempo de las actualizaciones que se puede permitir perder se conoce como objetivo de punto de recuperación (RPO).

En la tabla siguiente se define la relación entre el modelo de coherencia y la durabilidad de los datos si se produce una interrupción en toda la región.

Regiones Modo de replicación Nivel de coherencia RPO
1 Una o varias regiones de escritura Cualquier nivel de coherencia <240 minutos
>1 Región de escritura única Sesión, prefijo coherente, eventual <15 minutos
>1 Una región de escritura De obsolescencia entrelazada K&T
>1 Una región de escritura Alta 0
>1 Varias regiones de escritura Sesión, prefijo coherente, eventual <15 minutos
>1 Varias regiones de escritura De obsolescencia entrelazada K&T

K = número de versiones "K" (es decir, actualizaciones) de un elemento.

T = intervalo de tiempo "T" desde la última actualización.

En el caso de una cuenta de una sola región, el valor mínimo de K y T es de 10 operaciones de escritura o de 5 segundos. En el caso de cuentas de varias regiones, el valor mínimo de K y T es de 100 000 operaciones de escritura o de 300 segundos. Esto define el RPO mínimo para los datos cuando se usa la obsolescencia limitada.

Coherencia fuerte y varias regiones de escritura

Las cuentas de Azure Cosmos DB configuradas con varias regiones de escritura no se pueden configurar para lograr una coherencia fuerte, ya que no es posible que un sistema distribuido proporcione un RPO de cero y un RTO de cero. Además, no existe ninguna ventaja en la latencia de escritura por usar la coherencia fuerte con varias regiones de escritura porque una escritura en cualquier región debe replicarse y confirmarse en todas las regiones configuradas dentro de la cuenta. Esto produce la misma latencia de escritura que una cuenta con una sola región de escritura.

Lecturas adicionales

Para más información sobre los conceptos de coherencia, lea los artículos siguientes:

Pasos siguientes

Para más información sobre los niveles de coherencia de Azure Cosmos DB, lea los artículos siguientes: