ACID, CAP y PACELC: los teoremas que explican cómo funcionan las bases de datos

Learn ACID, CAP, and PACELC: the three theorems that explain how databases work. ACID guarantees reliable transactions. CAP describes the tradeoff between consistency, availability, and partition tolerance in distributed systems. PACELC adds latency into the equation when there's no partition.
Chapters
Debido a la extensión del capítulo de NoSQL, vamos a contar aquí estos conceptos, por lo que ahora sí, Chip pregunta: ¿Qué es eso de ACID?
La promesa hecha por las bases de datos relacionales, Chip.
Y esas son: Atomicidad, Consistencia, Aislamiento y Durabilidad.
¿Eso no es ACAD?
Es porque ACID está en inglés y Y aislamiento es isolation.
Vale, entonces, ¿qué significa cada uno?
Pues la atomicidad quiere decir que cada acción a la base de datos, como insertar, modificar o eliminar un dato, debe tomarse como atómica. Se hace o no se hace, no puede quedar a medias.
Exacto. La consistencia es que si se hace una inserción, modificación o eliminación, la siguiente toma de información Debe reflejar ese cambio. Debe ser consistente.
¿Y no consistente eventualmente?
No, para nada. La consistencia eventual es un intento de otorgar consistencia a una base de datos que carece de ella. La consistencia se tiene o no se tiene. No puede ser eventual.
Hombre, pro, yo creo que si es consistente pasado un tiempo de propagación de cambios es válido.
Díselo a los bancos.
Vale, no todos los diseños de bases de datos soportan la eventualidad de la consistencia.
Si hago una operación de modificación no incremental sobre una versión de datos desfasada, los cambios resultantes no son consistentes.
Ciertamente, pro. Pero hay modelos de datos que soportan no ser consistentes eventualmente. Ya sabes, más que nada para poder cumplir con las otras dos partes del triángulo del CAP.
¿CAP? Vayamos por partes. Hemos hablado de consistencia. ¿Qué hay del aislamiento?
Fácil. Que cada operación no interfiera con las otras.
Es importante para que la atomicidad se cumpla.
No solo eso, bro, también cuando hacemos transacciones. Que las modificaciones de una transacción no interfieran en las operaciones de otras hasta que estén completas.
¡Exacto! Ya solo nos queda la durabilidad. Básicamente, que no se pierdan los datos.
Si una transacción u operación se da como válida, se queda.
Ahora me asalta la curiosidad, has dicho CAP. ¿Qué es CAP?
Pues se dice que cuando tienes datos distribuidos y quieres realizar un cambio, la propagación de los datos solo puede tener 2 de estas 3 características: consistencia, disponibilidad por availability, que te veo venir, y tolerancia a la partición por partition tolerance.
¿Solo podemos elegir 2?
¡Solo 2!
Entiendo la consistencia y la disponibilidad, pero ¿qué significa tolerancia a la partición?
En verdad es una pequeña trampa. La partición se sucede cuando dos sistemas distribuidos pierden comunicación. ¿Qué deberían hacer? Obviamente deben poder operar aunque sean con limitaciones y una vez que recuperen la comunicación resolver cualquier posible conflicto.
¿Podríamos elegir consistencia y disponibilidad?
Sí, pero entonces en el momento en el que los sistemas dejan de comunicarse el sistema se rompe parcial o completamente.
Vale, entonces la tolerancia a fallos debe entrar sí o sí, por lo que Solo podemos decidir, en verdad, entre consistencia o disponibilidad. ¿Qué implica cada uno?
Si elegimos consistencia y una de las partes cae, todo el sistema cae. Al arriesgar la disponibilidad, no dejamos que el sistema funcione si falta algún elemento para evitar inconsistencias. Este es un claro ejemplo de los sistemas bancarios: prefieren estar fuera de servicio antes que arriesgar la consistencia.
Entonces, si elegimos disponibilidad, no obtenemos consistencia.
No, al menos no completa. No obstante, si el sistema vuelve a estar completo y se pueden resolver los conflictos, tendremos la consistencia eventual. Esto pasa con la facturación en las operadoras de telecomunicaciones. Normalmente las facturas se emiten mensualmente, por lo que no les importa que eventualmente en un momento dado los datos no sean correctos, se pueden corregir un poco más adelante.
Pero CAP está desactualizado.
¿Qué? No, es el CAP Pro.
Exacto, pero está tan desactualizado como el piedra papel tijera.
¿Desfasado porque ahora está el piedra papel tijera lagarto Spock?
Exacto. En el caso del CAP lo reemplaza PASAOK.
Pues no había oído hablar de PASAOK. ¿Qué es PASAOK?
Como hemos dicho, CAP es el modelo que dice que hay que elegir 2 de 3 elementos. Siempre arriesgamos uno. Pero PACELC nos dice algo mucho más completo.
Supongo que PAC son las letras ordenadas de otra forma de CAP, por lo que comenzaría con tolerancia a particiones.
En verdad las siglas forman una sentencia condicional.
Esto es nuevo. Venga, pues ilústranos.
Viene a decir: en caso de una partición elegimos entre disponibilidad o consistencia. Si no hay partición, entonces entre latencia y consistencia.
Entonces, en este modelo condicionan si estamos o no en una partición y agregan la latencia.
Sí, la falta de disponibilidad en verdad puede deberse a una falta de servicio o un retraso tan elevado que se equipara a una falta de disponibilidad.
Interesante. Entonces, en estos sistemas, si elegimos disponibilidad cuando hay partición, También se puede elegir consistencia en caso de no haber partición.
Exacto, puedes elegir y construir el sistema en base a tus necesidades. ¿Quedan claros los conceptos?
More from Manuel

Historia de los Lenguajes de Programación: años 1960-1969 #basic #apl #simula #lisp #logo

¿Compilador o intérprete? La historia de una rivalidad que comenzó en los años 40








