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 alta también puede verse afectada por una disponibilidad reducida (durante los 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.
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. En 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. A medida que cambie la coherencia de nivel de cuenta, asegúrese de volver a implementar las aplicaciones y realizar las modificaciones de código necesarias para aplicar estos cambios. 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:
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, el retraso de los datos entre dos regiones siempre es menor que una cantidad especificada. La cantidad puede ser de "K" versiones (es decir, "actualizaciones") de un elemento o de "T" intervalos de tiempo, 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 obsolescencia configurado, las escrituras en esa partición se limitarán hasta que la obsolescencia vuelva a estar dentro del límite superior configurado.
En el caso de una cuenta de una sola región, la obsolescencia limitada proporciona las mismas garantías de coherencia de escritura que la coherencia posible y de sesión. Con la obsolescencia limitada, los datos se replican en una mayoría local (tres réplicas de un conjunto de cuatro) de 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, cuando se usa la obsolescencia limitada, devuelven los datos más recientes disponibles en esa región al leer de dos réplicas disponibles en ella. Como las escrituras dentro de una región siempre se replican en una mayoría local (tres de cuatro réplicas), la consulta de dos réplicas devuelve 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. La obsolescencia limitada en una cuenta de escritura múltiple es un antipatrón. Este nivel requeriría una dependencia del retraso de la replicación entre regiones, lo que no debería importar si los datos se leen en la misma región en la que se escribieron.
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:
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. Esta garantía da por hecho una sola sesión de "escritor" o el uso compartido del token de sesión entre 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é los 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 reintenta la solicitud en otra réplica de la región. Si es necesario, el cliente reintenta la lectura en las regiones disponibles adicionales hasta que se recuperan 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.
Los tokens de sesión en Azure Cosmos DB están ligados a particiones, lo que significa que cada uno está exclusivamente asociado con una única partición. Para asegurarse de que puede leer las escrituras, use el token de sesión que se ha generado por última vez para los elementos pertinentes.
Si el cliente no inició una escritura en una partición física, el cliente no contiene un token de sesión en su caché y las lecturas de esa partición física se comportan como lecturas con coherencia posible. Del mismo modo, si se vuelve a crear el cliente, también se vuelve a crear su caché de tokens de sesión. Aquí también, las operaciones de lectura siguen el mismo comportamiento que en la coherencia posible hasta que las operaciones de escritura subsiguientes recompilen la 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 sesión es el nivel de coherencia más ampliamente usado para regiones únicas, así como para aplicaciones distribuidas globalmente. Proporciona latencias de escritura, disponibilidad y rendimiento de lectura comparables a los de la coherencia posible. La coherencia de sesión también proporciona las garantías de coherencia que satisfacen las necesidades de las 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.
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 de cualquier réplica, el usuario ve "Doc1 v1 y Doc2 v1" o " Doc1 v2 y Doc2 v2" o ningún documento si la réplica lleva 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:
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 posible, el cliente emite solicitudes de lectura para 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 posible 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 ideal 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.
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 su cuenta 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. Para averiguar esta probabilidad, examine la métrica Obsolescencia limitada probabilísticamente (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).
Probabilísticamente, la obsolescencia limitada 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 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. Para usar Azure Portal, vaya a la sección "Métricas" y seleccione la opción "Coherencia". Con Azure Portal, puede 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 coste de rendimiento 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.
Nota:
El coste de rendimiento de RU/s de las lecturas para los niveles de coherencia de obsolescencia fuerte y limitada consume aproximadamente dos veces más RU al realizar operaciones de lectura en comparación con otros niveles de coherencia relajados.
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 si 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 en caso de 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 = el número de versiones de "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. Este valor define el RPO mínimo de 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 alta, ya que no es posible que un sistema distribuido proporcione un RPO 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. Este escenario produce la misma latencia de escritura que una cuenta con una sola región de escritura.
Más lectura
Para más información sobre los conceptos de coherencia, lea los artículos siguientes:
- High-level TLA+ specifications for the five consistency levels offered by Azure Cosmos DB (Especificaciones TLA+ de alto nivel de los cinco niveles de coherencia que ofrece Azure Cosmos DB)
- Replicated Data Consistency Explained Through Baseball (video) (Vídeo sobre Coherencia de datos replicados explicada mediante el béisbol), por Doug Terry
- Replicated Data Consistency Explained Through Baseball (whitepaper) (Coherencia de datos replicados explicada mediante el béisbol [notas del producto]), por Doug Terry
- Session guarantees for weakly consistent replicated data (Garantías de sesión para datos replicados con coherencia débil)
- Consistency Tradeoffs in Modern Distributed Database Systems Design: CAP is Only Part of the Story (Compromisos de coherencia en el diseño de sistemas modernos de bases de datos distribuidas: CAP es solo parte de la historia)
- Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums [Obsolescencia limitada probabilística (PBS) para cuórums parciales prácticos].
- Eventual Consistent - Revisited (Coherencia posible: revisión)
Pasos siguientes
Para más información sobre los niveles de coherencia de Azure Cosmos DB, lea los artículos siguientes: