Cassandra, la dama de las bases de datos NoSQL.

Dentro de los nuevos sistemas de almacenamiento que están surgiendo dentro del universo Big Data, Cassandra es uno de los más interesantes y reseñables. Cassandra se define como una base de datos NoSQL distribuida y masivamente escalable, y esta es su mayor virtud desde nuestro punto de vista, la capacidad de escalar linealmente.

Además, Cassandra introduce conceptos muy interesantes como el soporte para multi data center o la comunicación peer-to-peer entre sus nodos. En este artículo vamos a profundizar en estas y otras características que hacen a Cassandra tan especial.

Historia y orígenes

El desarrollo inicial de Cassandra tiene su origen en Facebook, que lo diseñó para potenciar la funcionalidad de búsqueda en el inbox. En 2008 fue liberado como proyecto open source y en febrero de 2010 se convirtió en un proyecto top-level de la fundación Apache.

Está inspirado e influenciado por los papers de Amazon Dynamo de 2007 y de Google BigTable de 2006. Hoy en día está mantenido y desarrollado por la compañía Datastax.

Su nombre está inspirado por la sacerdotisa Cassandra de la mitología griega, que tenía el don de la profecía, y predijo el engaño del Caballo de Troya.

Arquitectura y características

Cassandra nos proporciona tolerancia a particiones y disponibilidad, pero a cambio de ser eventualmente consistente, tal y como define el teorema CAP. El nivel de consistencia puede ser configurado, según nos interese, incluso a nivel de query.

Es distribuida, lo quiere decir que la información está repartida a lo largo de los nodos del cluster. Además ofrece alta disponibilidad, de manera que si alguno de los nodos se cae el servicio no se degradará.

Escala linealmente, lo que quiere decir que el rendimiento de forma lineal respecto al número de nodos que añadamos. Por ejemplo, si con 2 nodos soportamos 100.000 operaciones por segundo, con 4 nodos soportaremos 200.000. Esto da mucha predictibilidad a nuestros sistemas.

Escala de forma horizontal, lo que quiere decir que podemos escalar nuestro sistema añadiendo nuevos nodos basados en hardware commodity de bajo coste.

Implementa una arquitectura Peer-to-Peer, lo que elimina los puntos de fallo único y no sigue patrones maestro-esclavo como otros sistemas de almacenamiento.

De esta manera cualquiera de los nodos puede tomar el rol de coordinador de una query. Será el driver el que decida qué nodo quiere que sea el coordinador.
Los datos son repartidos a lo largo del cluster en base a un token único calculado para cada fila por una función hash.

Los nodos se reparten equitativamente el rango de tokens que va de -263 a 263, esto define el nodo primario. Internamente Cassandra replicará los datos entre los nodos con la política que le definamos, por ejemplo definiendo el factor de replicación.

Además soporta el concepto de data center para agrupar los nodos lógicamente y tener los datos más cerca del usuario.

Lenguaje CQL

Cassandra Query Language (CQL) es el lenguaje de acceso a datos en Cassandra, es un derivado reducido de SQL. En Cassandra los datos están desnormalizados de manera que el concepto de joins o subqueries no existe.

Podemos interactuar con Cassandra mediante CQL a través de la shell. de CQL, cqlshell. También podemos usar herramientas gráficas como DevCenter o a través de los drivers soportados para múltiples lenguajes de programación.

Modelado de datos

También combina propiedades de una base de datos clave-valor y una orientada a columnas. Como podemos ver en el siguiente diagrama la información se organiza de manera que toda fila tiene una clave única y una serie de pares de clave, valor de columna. Es importante tener en mente estas características a la hora de diseñar nuestro modelo de datos.

Cuando diseñemos nuestro modelo debemos de guiarnos por el patrón de acceso a los datos, hay que hacer un análisis de las queries que pretendemos ejecutar contra nuestro sistema y de esta forma podremos diseñar un modelo eficiente que pueda sacar partido de las ventajas de Cassandra.

Es importante también definir adecuadamente la clave de partición de nuestro datos, ya que Cassandra se basará en esta clave para distribuir los datos a lo largo del cluster. Si queremos aprovechar nuestro cluster debemos pensar en distribuir los datos para evitar cuellos de botella.

También es recomendable, dado nuestro patrón de consulta, intentar minimizar el número de particiones a las que hay que acceder durante una lectura.

Conclusión

Cassandra es una solución brillante para muchos casos de uso que podemos encontrar en el mundo Big Data. Sin embargo, no es adecuada para alojar un data warehouse convencional.

Lo ideal es tener claro desde el principio el caso de uso y el tipo de consultas que haremos para diseñar la base de datos coherentemente, de esta manera podremos manejar grandes volúmenes de datos y aprovecharnos de las ventajas de esta potente base de datos distribuida.