Sharez+: Cassandra la mejor alternativa del NoSQL

Cassandra se perfila como “la reina” del NoSQL

Ya han escuchado hablar del movimiento NoSQL, que es un movimiento realmente interesante, y lógico teniendo en cuenta lo drásticamente que han cambiado las necesidades en cuanto a bases de datos con el auge de los medios sociales. Dentro de las bases de datos encasilladas dentro del movimiento NoSQL, existen varios acercamientos:

Orientadas a documento como CouchDB o MongoDB
Orientadas a grafos como Neo4j
Clave/valor, como SimpleDB o Voldemort
Orientadas a objetos como Db4o
Tabulares como Cassandra o Hypertable
Otros acercamientos como GT.M

Uno de los aspectos más positivos del movimiento NoSQL es que al no estar amparadas bajo un mismo funcionamiento (relacional) y un lenguaje de acceso a los datos (SQL), existe una mayor diversidad de acercamientos y, con ello, distintas soluciones, cada cual más adaptada a un problema o situación concreto. Por lo que no acaba de tener sentido el decir cuál es el mejor acercamiento hablando desde una perspectiva genérica, ya que, por ejemplo, para situaciones en las que necesitemos trabajar de forma intensiva con grafos, nos vendrá mejor utilizar un acercamiento como el de Neo4j, pero en otras situaciones preferiremos otras bases de datos que nos permitan realizar otro tipo de tareas de una forma más eficiente y/o efectiva.

Teniendo claro el comentario anterior, si que merece la pena estudiar el posicionamiento de las grandes empresas de Internet, al menos aquellas que manejan más cantidad de datos, para estudiar sus elecciones. A este respecto, estos días se habla mucho de que Twitter abandona MySQL para empezar a utilizar Cassandra como base de datos, y no es el único que se ha decidido por Cassandra, ya que tanto Facebook (quien desarrollo Cassandra inicialmente), Digg, Cisco, y muhos otros grandes en cuanto a gestión de datos, se han decidido por esta opción.

¿Qué nos ofrece Cassandra?

Algunas de las características más importantes de Cassandra son:

Tolerante a fallos, ya que los datos se replican de forma automática en distintos nodos, o incluso en distintos centros de datos.
Descentralizada, ya que cada nodo del cluster de datos es idéntico a otros (y se evitan cuellos de botella).
Eventualmente consistente.
Modelo de datos ricos, más allá del mero par de clave/valor.
Elástica, ya que el rendimiento de lectura y escritura crece linealmente al ir añadiendo máquinas.
Alta disponibilidad.

¿Por qué la desarrolló Facebook?

El por qué Facebook usa Cassandra es una cuestión simple de responder, ya que ellos son los desarrolladores iniciales y lo han desarrollado de acuerdo con sus necesidades. Aún así, merece la pena leerse algunos de los posts que ingenieros de Facebook han escrito con respecto a Casandra para hacerse una idea de los conceptos e ideas que hay detrás de Cassandra. Avinash Lakshman, uno de los ingenieros de Facebook, comentaba en su día la motivación para el desarrollo inicial de Cassandra:

Prashant Malik, del equipo de búsqueda, estaba pensando cómo resolver el problema de la ‘bandeja de entrada’. El desafío se centraba en cómo almacenar índices inversos de los mensajes que los usuarios de Facebook envían y reciben entre ellos. La gran cantidad de datos almacenados, su ratio de crecimiento y los requerimientos para servir la información, hacían aparente la necesidad de una nueva solución de almacenamiento, que fuera capaz de escalar incrementalmente. Las soluciones de almacenamiento de datos tradicionales símplemente no encajaban, así que tuvimos que diseñar una solución que fuera capaz de resolver el problema de la ‘bandeja de entrada’, pero que también proporcionaran una infraestructura de almacenamiento para muchos otros problemas de la misma naturaleza. Y con esto nació Cassandra.

El modelo de datos de Cassandra es simple pero muy flexible. Cada fila se identifica con una clave única, que es un string que no tiene un tamaño límite. Una instancia de Cassandra tiene una tabla que se constituye de una o más familias de columnas definidas por el usuario. Cada familia de columnas puede contener una o dos estructuras: supercolumnas o columnas. Las dos se crean de forma dinámica y no hay límite en cuanto al número que pueden ser almacenados en una familia de columnas.

Las columnas son construcciones que tienen un nombre, un valor y un ‘timestamp’ asociado a las mismas. Se pueden almacenar tantas columnas como se quieran en una familia de columnas. Por otro lado, las supercolumnas son una construcción que tiene un nombre y un número infinito de columnas asociadas a la misma.

¿Por qué la han elegido sitios como Digg/Twitter?

En Septiembre de 2009, Digg ya comentaba el inicio de su migración desde MySQL a Cassandra. Según palabras de Ian Eure:

Después de considerar HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort y Dynomite, nos quedamos con Cassandra. Cada sistema tiene sus puntos fuertes y sus debilidades, pero Cassandra es una buena mezcla de todo. Ofrece almacenamiento orientado a columnas, por lo que tienes algo más de estructura que los acercamientos de clave/valor. Opera en un cluster distribuido, de alto rendimiento y peer-to-peer. Y aunque le faltan algunas características necesarias, nos deja más cerca de dónde queremos llegar que otras soluciones.

[...] El problema fundamental es algo endémico a la mentalidad de bases de datos relacionales, que establecen un mayor peso de computación en las lecturas en lugar de en las escrituras. Esto es algo totalmente equívoco cuando estamos hablando de aplicaciones web a gran escala, donde el tiempo de respuesta es crítico. Cada componente de la página bloquea las lecturas del almacén de datos. [...] Las bases de datos no relacionales le dan la vuelta a este modelo, ya que no ejecutan operaciones complejas de lectura mediante SQL. El modelo te fuerza a cambiar el esfuerzo de computación a las escrituras, mientras que las lecturas se reducen a las operaciones más simples posibles.

Por su parte, Ryan King de Twitter, comentaba algunas de las razones por las que Twitter migra a Cassandra:

Tenemos una gran cantidad de datos, y con un factor de crecimiento muy elevado y encima acelerándose. Tenemos un sistema con mysql + memcache pero se está convirtiendo en algo costosamente prohibitivo en términos de esfuerzo (personal trabajando para el sistema). Necesitamos un sistema que pueda crecer de una forma más automatizada y que presente alta disponibilidad.

[...] Las principales razones por las que migramos a Cassandra se resumen en: 1) No tiene puntos de fallo, 2) las escrituras son áltamente escalables y 3) una comunidad open source saludable y productiva.

Y la verdad que además de sus características técnicas, el tema de la comunidad es algo muy favorable para Cassandra, porque ya de por si con Facebook, Digg, Twitter y muchas otras empresas interesadas en el desarrollo de Cassandra (y con gente dedicada a integrar, mejorar, etc.), esto asegura una cierta continuación y una cierta garantía de que a corto/medio plazo Cassandra será una solución más que completa.

Personalmente creo que es muy saludable el prolífico panorama de bases de datos NoSQL que disponemos a día de hoy, que ofrecen soluciones adaptadas a diversos problemas que no son fácilmente abordables desde la perspectiva relacional. Y más aún cuando una de las soluciones de bases de datos relacionales más utilizada en aplicaciones web a gran escala, como es MySQL, ha sido comprada por un gigante como Oracle, dejando su futuro un tanto negro.