Niveles de coherencia en Azure Cosmos DB

Las bases de datos distribuidas que dependen de la replicación para lograr 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 PACELC. La linealización del modelo de coherencia fuerte es el estándar para la programación de datos. Sin embargo, aumenta las latencias de escritura porque los datos deben replicarse y confirmarse en grandes distancias. La coherencia fuerte también reduce la disponibilidad durante los errores porque los datos no se pueden replicar y confirmar en cada región. La coherencia final ofrece una mayor disponibilidad y un mejor rendimiento, pero es más difícil programar aplicaciones, ya que es posible que los datos no sean coherentes en todas las regiones.

La mayoría de las bases de datos NoSQL distribuidas en el mercado actualmente proporcionan una coherencia sólida y eventual. Azure Cosmos DB ofrece cinco niveles bien definidos. De más fuerte a más débil, los niveles son:

• Fuerte
• Caducidad limitada
• Sesión
• Prefijo coherente
• Eventual

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 equilibra la disponibilidad y el rendimiento. En la imagen siguiente se muestran los niveles de coherencia como un espectro.

Niveles de coherencia y API de Azure Cosmos DB

Azure Cosmos DB admite API compatibles con el protocolo de conexión para bases de datos populares, como MongoDB, Apache Cassandra, Apache Gremlin y Azure Table Storage. Para la API para Gremlin o Table, Azure Cosmos DB usa el nivel de coherencia predeterminado configurado en la cuenta. Para más información sobre la asignación de nivel de coherencia, consulte API para la asignación de coherencia de Cassandra para Apache Cassandra y API para la asignación de coherencia de MongoDB para MongoDB.

Ámbito de coherencia de lectura

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

Configuración del nivel de coherencia predeterminado

Configure el nivel de coherencia predeterminado en la 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. Al cambiar la coherencia de nivel de cuenta, vuelva a implementar las aplicaciones y realice las modificaciones de código necesarias para aplicar estos cambios. Obtenga más información sobre cómo configurar el nivel de coherencia predeterminado. También puede invalidar el nivel de coherencia predeterminado para una solicitud específica. Obtenga más información en el artículo sobre la invalidación del nivel de coherencia predeterminado .

Garantías asociadas a los niveles de coherencia

Azure Cosmos DB garantiza que 100% de solicitudes de lectura cumplan la garantía de coherencia para el nivel de coherencia elegido. Las definiciones precisas de los cinco niveles de coherencia de Azure Cosmos DB mediante el lenguaje de especificación TLA - Lógica temporal de acciones se proporcionan en el repositorio de GitHub azure/azure-cosmos-tla .

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 linealización significa atender solicitudes simultáneamente. Se garantiza que las lecturas devuelven la versión confirmada 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 muestra una fuerte coherencia 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:

Cuórum dinámico

En circunstancias normales, para una cuenta con coherencia fuerte, se considera que se confirma una escritura cuando todas las regiones reconocen la replicación del registro. Si la cuenta tiene tres o más regiones, el sistema puede reducir el número de regiones necesarias para un cuórum cuando algunas regiones son lentas o no responden. Esto ayuda a mantener una coherencia fuerte incluso si algunas regiones tienen problemas. En ese momento, las regiones que no responden se sacan del conjunto de regiones con cuórum para preservar la coherencia fuerte. Solo se agregan cuando se vuelven coherentes con otras regiones y funcionan según lo previsto. El número de regiones que se pueden sacar del conjunto de cuórum depende del número total de regiones. Por ejemplo, en una cuenta de tres o cuatro regiones, la mayoría es dos o tres regiones respectivamente, por lo que solo se puede quitar una región en cualquier caso. Para una cuenta de cinco regiones, la mayoría es tres, por lo que se pueden quitar hasta dos regiones que no responden. Esta funcionalidad se conoce como "cuórum dinámico" y puede mejorar la disponibilidad de escritura y la latencia de replicación para las cuentas con tres o más regiones.

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 múltiple de varias regiones con dos o más regiones, los datos se replican desde la región en la que se escribieron originalmente hacia todas las otras regiones con capacidad de escritura. En ambos escenarios, aunque no es habitual, en ocasiones podría haber 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 estar limitada por "K" versiones (es decir, "actualizaciones") de un elemento o por "T" intervalos de tiempo, lo que sea alcanzado 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) en que las lecturas pueden quedarse atrás respecto a las escrituras

La obsolescencia limitada es principalmente beneficiosa 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 ancianidad limitada proporciona las mismas garantías de coherencia de escritura que la consistencia eventual y de sesión. Con Bounded Staleness, los datos se replican en una mayoría local (tres réplicas de un conjunto de cuatro) dentro de una sola región.

Las lecturas que utilizan el modelo de consistencia "Bounded Staleness" devuelven los datos más recientes disponibles en esa región al leer de dos réplicas disponibles allí. 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.

La consistencia limitada funciona mejor para aplicaciones distribuidas globalmente utilizando cuentas de escritura en una sola región con dos o más regiones, donde se desea una consistencia casi fuerte 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 asume una sola sesión de "escritor" o el uso compartido del token de sesión para varios escritores.

Al igual que todos los niveles de consistencia más débiles que el nivel fuerte, 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.

Los tokens de sesión de Azure Cosmos DB están enlazados a particiones, lo que significa que se asocian exclusivamente a una partición. Para asegurarse de que puede leer las escrituras, use el token de sesión que se generó 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 Consistencia Eventual hasta que las operaciones de escritura posteriores vuelvan a compilar la caché de los tokens de sesión del cliente.

La coherencia de sesión es el nivel de coherencia más usado para aplicaciones distribuidas globalmente y de una sola región. Proporciona latencias de escritura, disponibilidad y rendimiento de lectura comparables a los de la consistencia eventual. 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 el nivel Fuerte, 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 a todas las demás regiones.

En un prefijo consistente, las actualizaciones realizadas como escrituras de documento individual ven la consistencia eventual.

Actualizaciones realizadas como un lote dentro de una transacción, se devuelven de manera coherente 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 realiza una lectura en cualquier réplica, el usuario ve "Doc1 v1 y Doc2 v1" o "Doc1 v2 y Doc2 v2" o ninguno de los documentos si la réplica está retrasada, pero nunca "Doc1 v1 y Doc2 v2" o "Doc1 v2 y Doc2 v1" para la misma operación de lectura o consulta.

En el gráfico siguiente se ilustra el prefijo de coherencia con notas musicales. En todas las regiones, las lecturas nunca encuentran escrituras desordenadas en un lote transaccional de escrituras.

Coherencia final

Al igual que todos los niveles de consistencia más débiles que el nivel fuerte, 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 podría estar retrasada y podría devolver datos obsoletos o ningún dato.

La coherencia final es la forma más débil de coherencia porque un cliente podría leer valores anteriores a esos valores que leyó en el pasado. La coherencia final es ideal cuando la aplicación no requiere ninguna garantía de ordenación. Algunos ejemplos incluyen el recuento de Retuits, Me gusta o comentarios sin hilo. 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 a menudo obtenga garantías de coherencia más fuertes. 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á vinculada a la ordenación y propagación de las operaciones de escritura y actualización.

Si no hay operaciones de escritura en la base de datos, una operación de lectura con niveles de consistencia de eventual, sesión o prefijo consistente podría arrojar los mismos resultados que una operación de lectura con el nivel de consistencia fuerte.

Si la cuenta está configurada con un nivel de coherencia distinto de la coherencia fuerte, puede determinar la probabilidad de que los clientes obtengan lecturas fuertes y coherentes para las 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 más información, consulte la métrica Monitor Probabilistically Bounded Staleness (PBS).

El estancamiento probabilísticamente acotado muestra cuán eventual es tu consistencia eventual. Esta métrica proporciona información sobre la frecuencia con la que se obtiene una mayor coherencia que el nivel de coherencia configurado actualmente en la cuenta de Azure Cosmos DB. En otras palabras, puede ver la probabilidad (medida en milisegundos) de obtener lecturas coherentes para una combinación de regiones de escritura y lectura.

Latencia y niveles de coherencia

Se garantiza que la latencia de lectura para todos los niveles de coherencia sea inferior a 10 milisegundos en el percentil 99. La latencia media de lectura, en el percentil 50, suele ser de 4 milisegundos o menos.

Se garantiza que la latencia de escritura para todos los niveles de coherencia sea inferior a 10 milisegundos en el percentil 99. La latencia media de escritura, en el percentil 50, suele ser de 5 milisegundos o menos. Las cuentas de Azure Cosmos DB que abarcan varias regiones con coherencia fuerte 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 elevado entre regiones aumenta la latencia de solicitudes de Azure Cosmos DB porque la coherencia fuerte completa una operación solo después de asegurarse de que la operación se haya confirmado en todas las regiones de la cuenta.

La latencia de RTT exacta depende de la velocidad de distancia de luz y de la topología de red de Azure. Las redes de Azure no proporcionan acuerdos de nivel de servicio (SLA) de latencia para RTT entre regiones de Azure, pero publica estadísticas de latencia 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. Use Azure Portal; para ello, 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.

Niveles de coherencia y rendimiento

• Para la obsolescencia fuerte y limitada, las lecturas se realizan en dos réplicas de un conjunto de cuatro réplicas (cuórum de minorías) para garantizar las garantías de coherencia. La sesión, el prefijo coherente y la coherencia final usan lecturas de réplica única. Como resultado, para el mismo número de unidades de solicitud, el rendimiento de lectura para obsolescencia fuerte y limitada es la mitad de los demás niveles de coherencia.

• Para un tipo determinado de operación de escritura, como insertar, reemplazar, upsert o eliminar, el rendimiento de escritura de las unidades de solicitud es idéntico en todos los niveles de coherencia. Para lograr una coherencia fuerte, los cambios deben confirmarse en cada región (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).

Durabilidad de los datos y niveles de coherencia

En un entorno de base de datos distribuido globalmente, el nivel de coherencia afecta directamente a la durabilidad de los datos durante una interrupción en toda la región. Al desarrollar un plan de continuidad empresarial, es importante entender cuál es el período máximo de actualizaciones de datos recientes que la aplicación puede permitirse perder al recuperarse de un evento disruptivo. El período de tiempo de las actualizaciones que se pueden perder se conoce como objetivo de punto de recuperación (RPO).

En esta tabla se muestra la relación entre los modelos de coherencia y la durabilidad de los datos durante una interrupción en toda la región.

K = Número de versiones K (actualizaciones) de un elemento.

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

Para una cuenta de una sola región, el valor mínimo de K y T es de 10 operaciones de escritura o 5 segundos. Para las cuentas de varias regiones, el valor mínimo de K y T es 100 000 operaciones de escritura o 300 segundos. Este valor define el objetivo de punto de recuperación mínimo (RPO) para los datos al usar consistencia limitada.

Coherencia fuerte y múltiples regiones de escritura

Las cuentas de Azure Cosmos DB con varias regiones de escritura no pueden usar una coherencia fuerte porque un sistema distribuido no puede proporcionar un objetivo de punto de recuperación (RPO) de cero y un objetivo de tiempo de recuperación (RTO) de cero. Además, la coherencia fuerte con varias regiones de escritura no mejora la latencia de escritura porque las escrituras deben replicarse y confirmarse en todas las regiones de la cuenta. Esta configuración da como resultado la misma latencia de escritura que una cuenta de región de escritura única.

Más lectura

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

• Especificaciones de TLA de alto nivel⁺ para los cinco niveles de coherencia ofrecidos por Azure Cosmos DB
• Coherencia de datos replicados explicada mediante el béisbol (vídeo) de Doug Terry
• Coherencia de datos replicada explicada a través del béisbol (documento técnico) por Doug Terry
• Session guarantees for weakly consistent replicated data (Garantías de sesión para datos replicados con coherencia débil)
• Desventajas de coherencia en el diseño moderno de sistemas de bases de datos distribuidas: CAP es solo parte de la historia
• Obsolescencia limitada probabilística (PBS) para cuórums parciales prácticos
• Finalmente coherente: revisado

Contenido relacionado

• Configuración del nivel de coherencia predeterminado
• Invalidación del nivel de coherencia predeterminado
• Obtenga más información sobre el Acuerdo de Nivel de Servicio de Azure Cosmos DB.