Apache Cassandra es una base de datos de código abierto, distribuida, descentralizada, elásticamente escalable, de alta disponibilidad, tolerante a fallas, tuneablemente consistente y orientada a filas que basa su diseño en Dynamo de Amazon y su modelo de datos en Bigtable de Google.
Creado en Facebook, ahora se usa en algunos de los sitios más populares en la Web.
Algo que talvez no se entiende es el termino tuneablemente consistente, es decir que podemos decirle que tan consistente queremos que sea, por medio de configuración. En realidad el clinte de la base le indica el nivel de consistencia.
Antes que nada definamos consistencia: la consistencia es la capacidad que tiene una base de retornar el mismo valor si es consultado 2 o más veces y este no ha sido modificado. Esta característica es innata en base de datos relacionales pero en bases distribuidas esto se vuelve más complejo. Tal vez no se entienda bien el problema, al ser una base distribuida pueden cambiar un dato y esto se debe sincronizar en todos los servidores haciendo que el guardado de datos algo lento.
La consistencia en una base de datos distribuida no es un tema fácil de abordar. Una técnica es aplicar los cambios por medio de tiempos o relojes, se lo puede ver como los cambios de GIT. De esta manera cada cambio es a un tiempo determinado y si alguien modifica un dato que fue modificado ese dato esta en conflicto y debemos solucionar el conflicto para poder aplicar el cambio.
Muchas veces hemos escuchado que Apache cassandra es "eventualmente consistente" eso significa que en algún momento puede ser consistente. Y esto en realidad no es tan así, dado que lo podemos configurar el nivel de concistencia.
La consistencia eventual es uno de varios modelos de consistencia disponibles para utilizar. Echemos un vistazo a estos modelos para que podamos entender las ventajas y desventajas:
- Consistencia Estricta: Esto a veces se llama coherencia secuencial y es el nivel de consistencia más estricto. Requiere que cualquier lectura siempre devuelva el valor escrito más reciente. Pero como desventaja tenemos que coordinar los servidores para que todos tengan el mismo valor. La unica forma es tener un reloj global
- Consistencia Casual: Esta es una forma ligeramente más débil de consistencia estricta. Elimina la fantasía del reloj global único que puede sincronizar mágicamente todas las operaciones sin crear un cuello de botella insoportable. En lugar de confiar en las marcas de tiempo, la coherencia causal toma un enfoque más semántico, intentando determinar la causa de los eventos para crear cierta consistencia en su orden. Significa que las escrituras potencialmente relacionadas deben leerse en secuencia. Si dos operaciones diferentes, no relacionadas, repentinamente escriben en el mismo campo, entonces se deduce que las escrituras no están causalmente relacionadas. Pero si una escritura ocurre después de otra, podríamos inferir que están causalmente relacionadas. La coherencia causal dicta que las escrituras causales deben leerse en secuencia.
- Consistencia Eventual: La consistencia eventual significa que todas las actualizaciones se propagarán a través de todas las réplicas en un sistema distribuido, pero esto puede llevar algo de tiempo. Eventualmente, todas las réplicas serán consistentes.
