Las transacciones de una base de datos relacional, como MySQL, deben cumplir con cuatro propiedades básicas, definidas por el gran Jim Gray como Atomicidad, Consistencia, Aislamiento y Durabilidad. Nombradas en la práctica como ACID (siglas en inglés), el cumplimiento de esas propiedades es una garantía de la correcta operación del DBM. Sin embargo, lograrlo es costoso, más aún cuando el sistema intenta escalar, y ya no digamos la velocidad a la que lo intenta: el sistema puede llegar a ser insostenible.
¿Por qué Cassandra? Básicamente, porque es descentralizado, tolerante a fallas, elástico (termino heradado de Amazon EC2; es la nueva manera de decir “escalable”), con alta disponibilidad y probado en el campo de batalla por Facebook (su gran impulsor a través de la Apache Software Foundation), Digg y (gradualmente) Twitter. Parte de su éxito se debe a que no intenta cumplir con todo rigor las propiedades ACID.
En entrevista realizada por el blog MyNoSQL a Ryan KIng (@rk), éste menciona detalles interesantísimos sobre el proceso de migración que están viviendo. King cuenta minuciosamente sobre las posibles soluciones iniciales, las pruebas a pasar por cada una de ellas y hasta bosqueja el plan de migración. Cuando es interrogado sobre las principales razones del cambio, King responde (en relación con Cassandra):
* No hay puntos únicos de falla.
* Escrituras altamente escalables […]
* Una rica y productiva comunidad open source.
La teoría detrás de Cassandra (no debe sorprendernos), pertenece a Google. Hace unas semanas patentó dicho sistema, no sin controversia de por medio por la cantidad de proyectos y empresas que utilizan esos principios en sus propios sistemas. Como quiera que sea, NoSQL como nuevo paradigma para el tratamientro de gran cantidad de datos, llegó para quedarse (aunque también hay controversia sobre si son DBM, estrictamente hablando…).
