Primero hablemos de ACID. Imagine que tiene un almacén de datos ACID independiente, tal vez una buena y costosa base de datos Oracle, que no se ha configurado con ningún tipo de replicación. Le escribes algunos datos. Entonces BAM un meteorito vaporiza el disco. No tiene más remedio que recuperarse de una copia de seguridad que tomó la semana pasada y las escrituras que realizó recientemente se pierden.
¿Podemos quejarnos de que Oracle falló la D en Durable? Bueno … era tan duradero como podía ser. ¿Qué tal la C en coherente? No, C ni siquiera juega con eso.
Así que ahora recuperamos nuestra base de datos Oracle, pero esta vez hemos aprendido nuestra lección. En lugar de retroceder una vez a la semana, hacemos una copia de seguridad diariamente. No por hora No cada minuto Tal vez podría argumentar que la Durabilidad está mejorando, tal vez, pero no puede decir que la Consistencia está disminuyendo.
- ¿Las computadoras cuánticas son realmente reales ahora? ¿Cuándo lo usarán para calcular el significado de la vida? ¿Cuándo resolverá las otras preguntas filosóficas?
- ¿Cuál sería el lenguaje óptimo que utilizarían los informáticos?
- ¿Qué es la normalización de contraste local en la visión por computadora?
- ¿Cuál es la explicación laica del problema de la satisfacción booleana?
- ¿Qué es lo que impide que la humanidad logre una IA fuerte, la velocidad de procesamiento o un algoritmo desconocido?
Pero espere, en lugar de hacer una copia de seguridad todo el tiempo para hacer una copia de seguridad de los archivos, ¿qué pasa si hacemos nuestras copias de seguridad en una réplica de Oracle DB para que si tenemos que recuperarnos no tengamos que hacer girar una nueva DB, simplemente nos dirigimos a esa? en lugar. Hemos mejorado nuestro tiempo de respuesta a los desastres. No hemos hecho nada para dañar nuestras garantías de ACID.
Ahora regrese y reemplace la palabra Oracle con Neo4J.
TL; DR siempre que TODAS las solicitudes vayan a un almacén de datos ACID, agregando la replicación asíncrona no daña ACID, solo reduce la pérdida de datos y mejora el tiempo de recuperación en caso de desastre.
Ahora cambiemos nuestro sistema para que pueda leer desde la base de datos de respaldo. Habrá algún tiempo entre el momento en que una escritura va al maestro y cuando un esclavo pone a disposición esos datos. Ese sistema, en su conjunto, ya no es ACID.
Ahora CAP. CAP trata sobre múltiples nodos todas las solicitudes de servicio. Maestro / esclavo no exhibe eso, por lo que podemos argumentar que CAP no se aplica. Excepto … bueno … lo hace. Porque si tenemos una réplica maestro / esclavo y rompemos la red entre ellos, es muy posible que el esclavo decida que es un maestro (o que el personal de operaciones active el interruptor manualmente). Y si enrutamos algunas solicitudes a un “maestro” y otras solicitudes a otro “maestro”, nuestro sistema se desviará rápidamente.
¿Es Neo4J eventualmente consistente? Bueno, vamos a sanar esa partición entre los dos “maestros” que son inconsistentes entre sí. ¿Lo que pasa? Sinceramente, no lo sé con Neo4J. Idealmente, desea alcanzar un estado coherente, no solo donde todos los maestros y esclavos estén de acuerdo con los datos, sino donde si todos los clientes se reunieran y hablaran sobre todas las escrituras que se reconocieron como exitosas, podrían inventar algunos pedidos de esas escrituras que es consistente con el estado de la base de datos. Estoy dispuesto a apostar que Neo4J no puede hacer eso de forma automática.
TL; DR maestro / esclavo asíncrono generalmente no es finalmente consistente a menos que esté cuidadosamente diseñado para serlo. Y en términos de CAP, está disponible y es tolerante a la partición pero no es consistente.
Lo que solo demuestra que lo consistente en ACID significa algo diferente de lo consistente en CAP.
