La consistencia eventual es un modelo de consistencia utilizado en la computación distribuida para lograr una alta disponibilidad que garantiza informalmente que, si no se realizan nuevas actualizaciones a un elemento de datos dado, eventualmente todos los accesos a ese elemento devolverán el último valor actualizado. [1] La consistencia eventual, también llamada replicación optimista , [2] se implementa ampliamente en sistemas distribuidos y tiene sus orígenes en los primeros proyectos de computación móvil. [3] A menudo se dice que un sistema que ha logrado una consistencia final ha convergido o logrado una convergencia de réplica . [4]La consistencia eventual es una garantía débil: la mayoría de los modelos más sólidos, como la linealización , son trivialmente consistentes con el tiempo, pero un sistema que simplemente es finalmente consistente no suele cumplir con estas restricciones más fuertes.
Los servicios eventualmente consistentes a menudo se clasifican como que brindan semántica BASE (básicamente disponible, estado suave, consistencia eventual), en contraste con las garantías tradicionales ACID (atomicidad, consistencia, aislamiento, durabilidad) . [5] [6] En química, BASE es opuesto a ACID, lo que ayuda a recordar el acrónimo. [7] Según el mismo recurso, estas son las definiciones aproximadas de cada término en BASE:
- Básicamente disponible: las operaciones básicas de lectura y escritura están disponibles tanto como sea posible (utilizando todos los nodos de un clúster de base de datos), pero sin ningún tipo de garantía de coherencia (la escritura puede no persistir después de que se concilian los conflictos, la lectura puede no obtener la última escritura )
- Estado suave: sin garantías de consistencia, después de un tiempo, solo tenemos alguna probabilidad de conocer el estado, ya que puede que aún no haya convergido.
- Eventualmente consistente: si el sistema está funcionando y esperamos lo suficiente después de cualquier conjunto de entradas, eventualmente podremos saber cuál es el estado de la base de datos, por lo que cualquier lectura adicional será consistente con nuestras expectativas.
A veces se critica la coherencia final [8] por aumentar la complejidad de las aplicaciones de software distribuidas. Esto es en parte debido a la consistencia eventual es puramente una vida de la conexión de garantía (lee finalmente devolver el mismo valor) y no tiene seguridad garantías: un sistema coherente con el tiempo puede devolver ningún valor antes de que converge.
La resolución de conflictos
Para garantizar la convergencia de réplicas, un sistema debe conciliar las diferencias entre varias copias de datos distribuidos. Este consta de dos partes:
- intercambiar versiones o actualizaciones de datos entre servidores (a menudo conocido como anti-entropía ); [9] y
- elegir un estado final apropiado cuando se hayan producido actualizaciones simultáneas, lo que se denomina reconciliación .
El enfoque más apropiado para la reconciliación depende de la aplicación. Un enfoque generalizado es "el último escritor gana" . [1] Otro es invocar un manejador de conflictos especificado por el usuario. [4] Las marcas de tiempo y los relojes vectoriales se utilizan a menudo para detectar la concurrencia entre actualizaciones. Algunas personas usan "el primer escritor gana" en situaciones en las que "el último escritor gana" es inaceptable. [10]
La reconciliación de escrituras simultáneas debe ocurrir en algún momento antes de la siguiente lectura y se puede programar en diferentes instantes: [3] [11]
- Reparación de lectura: la corrección se realiza cuando una lectura encuentra una inconsistencia. Esto ralentiza la operación de lectura.
- Reparación de escritura: la corrección tiene lugar durante una operación de escritura, si se encuentra una inconsistencia, lo que ralentiza la operación de escritura.
- Reparación asincrónica: la corrección no forma parte de una operación de lectura o escritura.
Fuerte consistencia eventual
Mientras que la consistencia eventual es sólo una vida de la conexión de garantía (se observaron cambios con el tiempo), una fuerte consistencia eventual (SEC) añade la seguridad garantía de que cualquier par de nodos que han recibido el mismo conjunto (no ordenado) de cambios estarán en el mismo estado. Si, además, el sistema es monótono , la aplicación nunca sufrirá retrocesos. Los tipos de datos replicados libres de conflictos son un enfoque común para garantizar la SEC. [12]
Ver también
Referencias
- ↑ a b Vogels, W. (2009). "Eventualmente consistente" . Comunicaciones de la ACM . 52 : 40–44. doi : 10.1145 / 1435417.1435432 .
- ^ Vogels, W. (2008). "Eventualmente consistente" . Cola . 6 (6): 14-19. doi : 10.1145 / 1466443.1466448 .
- ^ a b Terry, DB; Theimer, MM; Petersen, K .; Demers, AJ; Spreitzer, MJ; Hauser, CH (1995). "Gestión de conflictos de actualización en Bayou, un sistema de almacenamiento replicado débilmente conectado". Actas del decimoquinto simposio de ACM sobre principios de sistemas operativos - SOSP '95 . pag. 172. CiteSeerX 10.1.1.12.7323 . doi : 10.1145 / 224056.224070 . ISBN 978-0897917155. S2CID 7834967 .
- ^ a b Petersen, K .; Spreitzer, MJ; Terry, DB; Theimer, MM; Demers, AJ (1997). "Propagación de actualización flexible para una replicación débilmente consistente". Revisión de sistemas operativos ACM SIGOPS . 31 (5): 288. CiteSeerX 10.1.1.17.555 . doi : 10.1145 / 269005.266711 .
- ^ Pritchett, D. (2008). "Base: una alternativa ácida" . Cola . 6 (3): 48–55. doi : 10.1145 / 1394127.1394128 .
- ^ Bailis, P .; Ghodsi, A. (2013). "Coherencia eventual hoy: limitaciones, extensiones y más allá" . Cola . 11 (3): 20. doi : 10.1145 / 2460276.2462076 .
- ^ Roe, Charles (marzo de 2012). "ACID vs BASE: el pH cambiante del procesamiento de transacciones de base de datos" . VERSIDAD DE DATOS . Educación de DATAVERSITY, LLC . Consultado el 29 de agosto de 2019 .
- ^ HYaniv Pessach (2013), Distributed Storage (Distributed Storage: Concepts, Algorithms, and Implementations ed.), Amazon, OL 25423189M , Los
sistemas que utilizan la consistencia eventual dan como resultado una menor carga del sistema y una mayor disponibilidad del sistema, pero dan como resultado una mayor complejidad cognitiva para los usuarios y desarrolladores
- ^ Demers, A .; Greene, D .; Hauser, C .; Irlandés, W .; Larson, J. (1987). "Algoritmos epidémicos para el mantenimiento de bases de datos replicadas". Actas del sexto simposio anual ACM sobre principios de computación distribuida - PODC '87 . pag. 1. doi : 10.1145 / 41840.41841 . ISBN 978-0-89791-239-6. S2CID 1889203 .
- ^ Rockford Lhotka. "Técnicas de concurrencia" . 2003.
- ^ Olivier Mallassi (9 de junio de 2010). "Juguemos con Cassandra ... (Parte 1/3)" . http://blog.octo.com/en/ : OCTO Talks! . Consultado el 23 de marzo de 2011 .
Por supuesto, en un momento dado, es muy probable que cada nodo tenga su propia versión de los datos. La resolución de conflictos se realiza durante las solicitudes de lectura (llamadas lectura-reparación) y la versión actual de Cassandra no proporciona un mecanismo de resolución de conflictos de reloj vectorial [sic] (debería estar disponible en la versión 0.7). La resolución de conflictos se basa en la marca de tiempo (la que se establece cuando inserta la fila o la columna): la marca de tiempo más alta gana [s] y el nodo del que está leyendo los datos [de] es responsable de eso. Este es un punto importante porque la marca de tiempo la especifica el cliente en el momento en que se inserta la columna. Por lo tanto, todos los clientes de Cassandra [sic] deben estar sincronizados ...
- ^ Shapiro, Marc; Preguiça, Nuno; Baquero, Carlos; Zawirski, Marek (10 de octubre de 2011). "Tipos de datos replicados libres de conflictos". SSS'11 Proceedings of the 13th International Conference on Stabilization, Safety, and the Security of Distributed Systems . Springer-Verlag Berlín, Heidelberg: 386–400.