Consistencia eventual en inglés simple

A menudo escucho sobre la consistencia eventual en diferentes discursos sobre NoSQL, cuadrículas de datos, etc. Parece que la definición de consistencia eventual varía en muchas fuentes (y tal vez incluso depende de un almacenamiento de datos concreto).

¿Alguien puede dar una explicación simple de lo que es la consistencia eventual en términos generales, no relacionada con ningún almacenamiento de datos concreto?

Consistencia eventual:

1. Miro el informe meteorológico y me entero de que va a llover mañana.
2. Te digo que va a llover mañana.
3. Tu vecino le dice a su esposa que mañana hará sol.
4. Le dices a tu vecino que va a llover mañana.

Eventualmente, todos los servidores (usted, yo, su vecino) saben la verdad (que lloverá mañana), pero mientras tanto el cliente (su esposa) salió pensando que iba a estar soleado, a pesar de que ella preguntó después de que uno o más de los servidores (usted y yo) tuviéramos un valor más actualizado.

A diferencia del cumplimiento estricto de consistencia / ACID:

1. Su saldo bancario es de $ 50.
2. Usted deposita $ 100.
3. Su saldo bancario, consultado desde cualquier cajero automático en cualquier lugar, es de $ 150.
4. Su hija retira $ 40 con su tarjeta de cajero automático.
5. Su saldo bancario, consultado desde cualquier cajero automático en cualquier lugar, es de $ 110.

En ningún momento su saldo puede reflejar otra cosa que no sea la suma real de todas las transacciones realizadas en su cuenta en ese momento exacto.

La razón por la que tantos sistemas NoSQL tienen una consistencia eventual es que prácticamente todos están diseñados para ser distribuidos, y con sistemas completamente distribuidos hay una sobrecarga superlineal para mantener una consistencia estricta (lo que significa que solo puede escalar hasta mucho antes de que las cosas comiencen a ralentizarse) abajo, y cuando lo hacen, necesita arrojar exponencialmente más hardware al problema para seguir escalando).

Consistencia eventual:

1. Sus datos se replican en varios servidores.
2. Sus clientes pueden acceder a cualquiera de los servidores para recuperar los datos.
3. Alguien escribe un dato en uno de los servidores, pero aún no se ha copiado al resto
4. Un cliente accede al servidor con los datos y obtiene la copia más actualizada.
5. Un cliente diferente (o incluso el mismo cliente) accede a un servidor diferente (uno que todavía no recibió la nueva copia) y obtiene la copia anterior

Básicamente, debido a que lleva tiempo replicar los datos en varios servidores, las solicitudes para leer los datos pueden ir a un servidor con una nueva copia y luego ir a un servidor con una copia antigua. El término "eventual" significa que, con el tiempo, los datos se replicarán en todos los servidores y, por lo tanto, todos tendrán la copia actualizada.

La coherencia eventual es imprescindible si desea lecturas de baja latencia, ya que el servidor que responde debe devolver su propia copia de los datos y no tiene tiempo para consultar a otros servidores y llegar a un acuerdo mutuo sobre el contenido de los datos. Escribí una publicación de blog explicando esto con más detalle.

Piensa que tiene una aplicación y su réplica. Luego debe agregar un nuevo elemento de datos a la aplicación.

Luego, la aplicación sincroniza los datos con otra réplica que se muestra a continuación

Mientras tanto, el nuevo cliente obtendrá datos de una réplica que aún no se actualiza. En ese caso, no puede obtener datos de actualización correctos. Porque la sincronización toma algo de tiempo. En ese caso no tiene finalmente consistencia

El problema es cómo podemos lograr la consistencia ?

Para eso, utilizamos la aplicación de mediador para actualizar / crear / eliminar datos y utilizamos consultas directas para leer datos. que ayudan a hacer eventual consistencia

Cuando una aplicación realiza un cambio en un elemento de datos en una máquina, ese cambio debe propagarse a las otras réplicas. Dado que la propagación del cambio no es instantánea, hay un intervalo de tiempo durante el cual algunas de las copias tendrán el cambio más reciente, pero otras no. En otras palabras, las copias serán mutuamente inconsistentes. Sin embargo, el cambio eventualmente se propagará a todas las copias, y de ahí el término "consistencia eventual". El término consistencia eventual es simplemente un reconocimiento de que hay un retraso ilimitado en la propagación de un cambio realizado en una máquina a todas las otras copias. La consistencia eventual no es significativa o relevante en los sistemas centralizados (copia única) ya que no hay necesidad de propagación.

fuente: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

En inglés simple, podemos decir: Aunque su sistema puede estar en estados inconsistentes, el objetivo siempre es alcanzar la consistencia en algún momento para cada dato.

Finalmente, la coherencia significa que los cambios tardan en propagarse y que los datos pueden no estar en el mismo estado después de cada acción, incluso para acciones o transformaciones idénticas de los datos. Esto puede hacer que sucedan cosas muy malas cuando las personas no saben lo que están haciendo al interactuar con dicho sistema.

No implemente los almacenes de datos de documentos críticos del negocio hasta que comprenda bien este concepto. Arruinar la implementación de un almacén de datos de documentos es mucho más difícil de arreglar que un modelo relacional porque las cosas fundamentales que se arruinarán simplemente no se pueden arreglar, ya que las cosas que se requieren para arreglarlo simplemente no están presentes en el ecosistema. Refactorizar los datos de una tienda en vuelo también es mucho más difícil que las simples transformaciones ETL de un RDBMS.

No todos los almacenes de documentos son iguales. Algunos de estos días (MongoDB) admiten transacciones de algún tipo, pero la migración de los almacenes de datos es probablemente comparable al costo de la reimplementación.

ADVERTENCIA: Desarrolladores e incluso arquitectos que no conocen o entienden la tecnología de un almacén de datos de documentos y tienen miedo de admitir que por miedo a perder sus trabajos pero que han recibido una formación clásica en RDBMS y que solo conocen los sistemas ACID (cuán diferente puede ser ?) y quien no conoce la tecnología o se toma el tiempo de aprenderla, perderá el diseño de un almacén de datos de documentos. También pueden intentar usarlo como RDBMS o para cosas como el almacenamiento en caché. Desglosarán lo que deberían ser transacciones atómicas que deberían operar en un documento completo en partes "relacionales", olvidando que la replicación y la latencia son cosas, o peor aún, arrastrando sistemas de terceros a una "transacción". Harán esto para que su RDBMS pueda reflejar su lago de datos, sin importar si funcionará o no, y sin pruebas, porque saben lo que están haciendo. Entonces actuarán sorprendidos cuando los objetos complejos almacenados en documentos separados como "pedidos" tengan menos "artículos de pedido" de lo esperado, o tal vez ninguno. Pero no sucederá con frecuencia, o con la frecuencia suficiente para que simplemente marchen hacia adelante. Puede que ni siquiera lleguen al problema en el desarrollo. Luego, en lugar de rediseñar las cosas, lanzarán "retrasos" y "reintentos" y "comprobaciones" para falsificar un modelo de datos relacionales, que no funcionará, pero agregarán complejidad adicional sin ningún beneficio. Pero ya es demasiado tarde: la cosa se ha implementado y ahora el negocio se está ejecutando. Eventualmente, todo el sistema será eliminado y el departamento será subcontratado y alguien más lo mantendrá. Todavía no funcionará correctamente, pero pueden fallar de manera menos costosa que la falla actual.

La consistencia eventual es más como un espectro. En un extremo tiene una fuerte consistencia y en el otro tiene una consistencia eventual. En el medio hay niveles como Instantánea, leer mis escritos, obsolescencia limitada. Doug Terry tiene una hermosa explicación en su artículo sobre la consistencia eventual a través del béisbol .

Según mi opinión, la consistencia eventual es básicamente la tolerancia a datos aleatorios en orden aleatorio cada vez que lee de un almacén de datos. Cualquier cosa mejor que eso es un modelo de consistencia más fuerte. Por ejemplo, una instantánea tiene datos obsoletos pero devolverá los mismos datos si se vuelve a leer, por lo que es predecible. A veces, la aplicación puede tolerar datos que están obsoletos durante un período de tiempo más allá del cual exige datos consistentes.

Si observa el significado de consistencia, se relaciona más con la uniformidad o la falta de desviación. Entonces, en términos de sistemas no informáticos, podría significar la tolerancia a variaciones inesperadas. Podría explicarse muy bien a través de un cajero automático. Un cajero automático podría estar fuera de línea, por lo tanto, divergente del saldo de la cuenta de los sistemas centrales. Sin embargo, existe una tolerancia para mostrar diferentes saldos durante un período de tiempo. Una vez que el cajero automático se conecta, puede sincronizarse con los sistemas centrales y reflejar el mismo equilibrio. Por lo tanto, se podría decir que un cajero automático es eventualmente consistente.