Apache Cassandra

Apache Cassandra se trata de un software NoSQL distribuido y basado en un modelo de almacenamiento «tabular», de código abierto que está escrito en Java. Permite grandes volúmenes de datos en forma distribuida. Por ejemplo, lo usa Twitter para su plataforma. Su objetivo principal es la escalabilidad lineal y la disponibilidad. La arquitectura distribudores de Cassandra está basada en una serie de nodos iguales que se comunican con un protocolo P2P con lo que la redundancia es máxima. Esta soportada por la Apache Software Fundation.

Apache Cassandra
Parte de software libre
Información general
Tipo de programa	sistema de gestión de bases de datos
Autor	Avinash Lakshman, Prashant Malik
Desarrollador	Apache Software Foundation
Lanzamiento inicial	2008
Licencia	Apache License 2.0
Estado actual	Activo
Información técnica
Programado en	Java
Versiones
Última versión estable	3.11.7 (25 de julio de 2020) ()
Última versión en pruebas	5.0-beta15 de diciembre de 2023
Enlaces
Repositorio de código Seguimiento de errores

Cassandra se basa en una arquitectura distribuida que permite replicar los datos en múltiples nodos, proporcionando tolerancia a fallos y garantizando que los datos permanezcan disponibles incluso en caso de fallos de hardware o de red. Está diseñado para manejar datos estructurados y semi-estructurados, con soporte para una amplia gama de tipos de datos, incluyendo cadenas, enteros, flotantes, marcas de tiempo y UUID.

Cassandra ofrece soporte robusto para múltiples Centros de datos,​ con replicación asincrónica sin necesidad de un servidor maestro, lo que permiten operaciones de baja latencia para todos los clientes.

Debido a que es una base de datos distribuida, Cassandra funciona con múltiples nodos, en donde cada uno representa una instancia de Cassandra. Estos nodos se comunican los unos con los otros mediante un protocolo llamado gossip (chisme), el cual es un proceso de comunicación de tipo peer-to-peer. A su vez funciona como una malla de tipo anillo, en donde no hay maestro y trabajadores, es decir cada nodo tiene la misma funcionalidad y capacidades que los demás, lo cual contribuye a que Cassandra sea más robusta y tenga mejor resiliencia.

Otro beneficio en cuanto al uso de Cassandra es su capacidad de escalabilidad, ya que permite que los desarrolladores escalen o incluso encojan su base de datos de forma dinámica sin necesidad de interrumpir el sistema.

Cassandra también ofrece un gran rendimiento. En 2012, investigadores de la Universidad de Toronto que estudian los sistemas NoSQL concluyeron que "En términos de escalabilidad, hay un claro ganador a través de nuestros experimentos. Cassandra logra el más alto rendimiento para el número máximo de nodos en todos los experimentos", aunque "esto tiene como precio una alta latencia de escritura y lectura".​

El modelo de datos de Cassandra consiste en particionar las filas, que son reorganizadas en tablas .​ Las claves primarias de cada tabla tiene un primer componente que es la clave de partición. Dentro de una partición, las filas son agrupadas por las columnas restantes de la clave.​ Las demás columnas pueden ser indexadas por separado de la clave primaria.​

Las tablas se pueden crear, eliminar y alterar en tiempo de ejecución sin bloquear actualizaciones y consultas.​

Cassandra no soporta la sentencia JOIN o subqueries, sino que enfatiza en la desnormalización a través de características como colecciones.​

En las versiones iniciales utilizaba un API propia para poder acceder a la base de datos. En los últimos tiempos están apostando por un lenguaje denominado CQL (Cassandra Query Language, no confundir con Contextual Query Language) que posee una sintaxis similar a SQL aunque con muchas menos funcionalidades. Esto hace que iniciarse en el uso de la misma sea más sencillo. Permite acceder en Java desde JDBC.

Historia

Apache Cassandra fue inicialmente desarrollada en Facebook para impulsar las búsqueda en la bandeja de entrada por Avinash Lakshman (uno de los autores de Amazon's Dynamo) y Prashant Malik. Fue lanzada como un proyecto open source de Google code en julio de 2008.​ En marzo de 2009, se transformó en un proyecto de Apache Incubator.​ El 17 de febrero de 2010 se graduó como un proyecto de alto nivel.​

Publicaciones después de la graduación:

• 0.6, 12 de abril de 2010, añaden soporte para cacheo integrado y para Apache Hadoop MapReduce​
• 0.7, 8 de enero de 2011, añaden índices secundarios y cambios en línea en el "scheme" de la base de datos​
• 0.8, 2 de junio de 2011, añaden el Cassandra Query Language (CQL), "self-tuning memtables", y soporte para mantenerse funcionando durante actualizaciones de versión​
• 1.0, 17 de octubre de 2011, añaden compresión integrada, compactación por niveles y se mejora el desempeño de lectura​
• 1.1, 23 de abril de 2012, añaden caché "self-tuning", aislamiento a nivel de fila y soporte para desarrollo en múltiples sistemas de disco​
• 1.2, 2 de enero de 2013, añaden clustering a través de nodos virtuales, comunicación entre nodos, procesos "batch" atómicos y traza de solicitudes​
• 2.0, 4 de septiembre de 2013, añaden transacciones livianas (basadas en el protocolo Paxos), triggers, y compactaciones improvisadas.
• 2.0.4, 30 de diciembre de 2013, añaden la especificación de los centros de datos para participar en una reparación, soporte de encriptación del cliente para el "sstableloader" y remover snapshots que no existen más.​
• 2.1.0 10 de septiembre de 2014​
• 2.1.5 29 de abril de 2015​
• 2.1.6 nueva versión 8 de junio de 2015
• 2.1.7 nueva versión 22 de junio de 2015
• 2.2.0 nueva versión 20 de julio de 2015
• 2.2.2 nueva versión 5 de octubre de 2015
• 3.0 nueva versión y luego se comienzan a realizar liberaciones mensualmente usando el tick-tock model.​
• 3.2.2 nueva versión 18 de enero de 2016
• 3.7 nueva versión 13 de junio de 2016
• 3.11.1 nueva versión 10 de octubre de 2017

Versión	Fecha liberación original	Última versión	Fecha liberación	Estado​
0.6	2010-04-12	0.6.13	2011-04-18	Ya no tiene soporte
0.7	2011-01-10	0.7.10	2011-10-31	Ya no tiene soporte
0.8	2011-06-03	0.8.10	2012-02-13	Ya no tiene soporte
1.0	2011-10-18	1.0.12	2012-10-04	Ya no tiene soporte
1.1	2012-04-24	1.1.12	2013-05-27	Ya no tiene soporte
1.2	2013-01-02	1.2.19	2014-09-18	Ya no tiene soporte
2.0	2013-09-03	2.0.17	2015-09-21	Ya no tiene soporte
2.1	2014-09-16	2.1.13	2016-02-08	Tiene soporte
2.2	2015-07-20	2.2.5	2016-02-08	Tiene soporte
3.0	2015-11-09	3.0.5	2016-04-11	Tiene soporte
3.2	2015-11-09	3.2.1	2016-01-18	Ya no tiene soporte
3.7	2016-06-13	3.7	2016-06-13	Ya no tiene soporte
3.11	2017-06-23	3.11.7	2020-07-25	Última liberación

Características principales

Descentralizado

Todos los nodos del clúster tiene el mismo rol. No hay un único punto de fallo. Los datos se distribuyen a través del clúster (por lo que cada nodo contiene datos diferentes). No existe un nodo maestro por lo que cada nodo puede dar servicio a cualquier solicitud.

Soporta replicación y replicación de múltiples data center

Las estrategias de replicación son configurables .​ Cassandra está diseñado como un sistema distribuido, para el despliegue de un gran número de nodos a través de múltiples centros de datos. La arquitectura distribuida de Cassandra está diseñado para desplegarse sobre múltiples data center, tener redundancia y recuperarse ante desastres.

Escalabilidad

El rendimiento de leer y escribir aumenta linealmente a medida que se añaden nuevos nodos. Se pueden agregar nuevos nodos sin necesidad de interrumpir la ejecución de la aplicación.

Tolerancia a fallos

Los datos se replican automáticamente a múltiples nodos para recuperarse frente a fallos. Cassandra soporta replicación a través de múltiples datacenter. Se puede reemplazar nodos que presenten fallos sin tiempo de inactividad o interrupción de la aplicación.

Consistencia

Se ofrece la elección del nivel de consistencia para las lecturas y escrituras.

Un ejemplo posible de consulta utilizando consistencia es el siguiente: SELECT * FROM users WHERE state='TX' USING CONSISTENCY QUORUM;

Lectura

Nivel	Descripción
ONE	Retorna una respuesta de la réplica más cercana.
QUORUM	Retorna la grabación con la fecha de creación más reciente en el quorum de réplicas de respuesta.
LOCAL_QUORUM	Retorna la grabación con la fecha de creación más reciente en el quorum de réplicas que se encuentran en el mismo nodo que el nodo coordinador solicitante.  Evita el retardo de comunicación entre data-centers.
EACH_QUORUM	Retorna la grabación con la fecha de creación más reciente en el quorum de réplicas de cada data-cetner del clúster que responda.
ALL	Retorna la grabación con la fecha de creación más reciente de todas las réplicas que respondan. Fallará si alguna réplica no responde.

Escritura

Nivel	Descripción
ANY	Una escritura debe ser realizada en al menos un nodo.
ONE	Una escritura debe ser escrita en el Commit Log y MemTable de al menos un nodo de replicación.
QUORUM	Una escritura debe ser escrita en el Commit Log y MemTable en un quorum de nodos de réplica
LOCAL_QUORUM	Una escritura debe ser escrita en el Commit Log y MemTable en un quorum de nodos de réplica en el mismo data-center que el nodo coordinador. Evita el retardo de comunicación entre data-centers.
EACH_QUORUM	Una escritura debe ser escrita en el Commit Log y MemTable en un quorum de nodos de réplica en todos los data-centers.
ALL	Una escritura debe ser escrita en el Commit Log y MemTable en todos las réplicas de nodos en el clúster para esa clave de fila.

Soporte MapReduce

Cassandra está integrado con Apache Hadoop para soportar MapReduce. También existe soporte para Apache Pig y Apache Hive.​

Lenguaje de consulta

Cassandra introduce CQL (Cassandra Query Language), una alternativa similar a SQL para la interfaz RPC tradicional. Existen drivers disponibles para Java (JDBC), Python (DBAPI2), Node.JS (Helenus), Go (gocql) y C++.​

Ejemplo de creación de un keyspace, incluyendo una columna en CQL 3.0:​

CREATE KEYSPACE MiEspacioClaves
  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

USE MiEspacioClaves;

CREATE COLUMNFAMILY MisColumnas (id text, Apellido text, Nombre text, PRIMARY KEY(id));

INSERT INTO MisColumnas (id, Apellido, Nombre) VALUES ('1', 'Perez', 'Juan');

SELECT * FROM MisColumnas;

Resultado:

 id | nombre | apellido
----+--------+---------
  1 |  Juan  |  Perez

(1 fila)

Sistema de archivos En la actualidad, Cassandra es compatible con HDFS (Hadoop Distributed File System), sin embargo, DataStax que es la compañía que da soporte y distribuye a Apache Cassandra a través de contribuciones abiertas, creó Cassandra File System (CFS) que tiene como objetivo ser el reemplazo de HDFS. Las principales diferencias se encuentran en los daemons llamados "Nombre de Nodo", "Nombre de Nodo Secundario" y "Nodo de Datos". El motivo de este cambio es hacer más fácil el manejo de archivos en Cassandra.

Las principales ventajas de CFS son:

• Maneja una arquitectura distribuida.

• Ideal para volúmenes masivos de información, separados en conjuntos de tamaño reducido.

• Los archivos que se manejen en Cassandra, se almacenarán en varios nodos para prevenir posibles fallas o pérdidas de información.

• Es compatible con otras herramientas, como MapReduce, Apache Spark que permiten trabajar el Big Data.

• Dentro del teorema de CAP, ofrece disponibilidad (A) y tolerancia a particiones (P).

Entonces, en general, Cassandra File System no es ideal para manejar grandes volúmenes de información en conjuntos grandes, sino en conjuntos pequeños. Y por otro lado, es excelente para datos almacenados de manera estructurada.

CFS Read Path

Cuando la lectura se necesita para un archivo o parte de un archivo, es necesario que se lea la información del inode para encontrar el bloque y el sub bloque que debe de leer. Entonces luego se ejecuta una llamada personalizada que retorna los datos del sub bloque o, en caso de que la llamada haya sido en un nodo con los datos locales, el archivo y la información de compensación de la tabla “SSTable” de Cassandra y el sub bloque respectivo. Esto es necesario debido a que durante una tarea de tipo “Mapreduce”, el rastreador de trabajos intenta colocar cada cálculo que se ha realizado en el nodo con la información actual. La razón por la que CFS comprime los subbloques y no usa la compresión que tiene Cassandra es porque al comprimir y descomprimir, el tráfico de red entre los nodos se disminuye.

CFS Write Path

En el caso de Hadoop, se tiene un parámetro que se llama “dfs.block.size” que nos indica precisamente el tamaño que tan grande debería de ser un bloque de archivo por cada archivo de escritura. Una vez que un archivo llega, en él se escriben los atributos estáticos en la columna familia del “inode”. Posteriormente, un nuevo bloque de objeto y se ejecuta “dfs.block.size” por cada dato. Mientras se hace la lectura de los datos, se van dividiendo en varios sub bloques con un tamaño que se obtiene de la función “cfs.local.subblock.size”, dichos sub bloques se comprimen para que cada que se termine un bloque, su ID se escriba en la fila del “inode”, mientras que los bloques secundarios se escriben en Cassandra con su respectivo ID, donde la llave de la fila será el ID del bloque y los ID de los subbloques como llaves de columna. La razón por la que CFS divide los bloques en sub bloques es porque trata de ahorrar el mayor espacio posible, de modo que, CFS debe asegurarse de no dejar sin memoria al nodo mediante el envío de varios datos a la vez. La ventaja de hacer esto es que Hadoop lo toma como un único bloque, provocando que no haya ningún cambio en la lógica de división de tareas.

Modelo de Datos

Cassandra es esencialmente un híbrido entre un modelo Clave-Valor y una base de datos Tabular (Orientado a columnas).

La familia de columnas (llamada “Tabla” desde CQL3) se asemeja a una tabla en un RDBMS. Estas contienen filas y columnas. Cada fila tiene múltiples columnas, cada una de estas tiene a su vez un nombre, un valor y un timestamp. A diferencia de una tabla en un RDBMS, diferentes filas en una misma familia de columnas, no tiene por qué compartir el mismo conjunto de columnas, y además, una columna puede ser añadida a una o a múltiples filas en cualquier momento. Cada clave en Cassandra, corresponde a un valor que es a su vez un objeto. Cada clave tiene valores como columnas, y las columnas son agrupadas en sets que son llamados familias de columnas. Así, cada clave identifica una fila con un número variable de elementos. Estas familias de columnas, pueden ser consideradas como tablas. Una tabla en Cassandra es un mapa multi-dimensional distribuido, indexado por una clave. Además, las aplicaciones pueden especificar el orden de las columnas dentro de una Súper Columna, o una Familia de Columnas Simples.

Clustering

Cuando se diseña el clúster para Apache Cassandra, un punto importante es seleccionar la partición correcta. Existen dos tipos de partición:

• 1. Partición Aleatoria (RP): Esta partición distribuye los pares Clave-Valor de una forma aleatoria sobre la red, resultando en un buen balanceo de la carga. Si lo comparamos con OPP, en este modelo (RP) se debe accede a más nodos para obtener un número de claves.
• 2. Partición con Preservación del Orden (OPP): Este tipo de partición distribuye las tuplas Clave-Valor en una forma natural, donde las claves similares no se separan demasiado. La ventaja es que solo se debe acceder a unos pocos nodos. La desventaja es la distribución irregular de claves-valor en los distintos nodos.

Licenciamiento y Soporte

Apache Cassandra es un proyecto de Apache Software Foundation, por lo que tiene una Apache License (versión 2.0).

Administración y Monitoreo

Cassandra en un sistema a base de Java que puede ser administrado y monitoreado con Java Management Extensions (JMX). Nodetool, por ejemplo, puede ser usado para administrar un clúster de Cassandra (agregando nodos a un aro, etc.).​ Nodetool también ofrece varias comandos para conseguir métricas de Casandra perteneciente a uso de disco, estado latente, compactación, recolección de basura, entre otras.​

Apache Cassandra, al ser un sistema de base de datos distribuida, ofrece varias herramientas y opciones para su administración y monitoreo. A continuación, se mencionan algunas de las principales herramientas utilizadas en el contexto de Apache Cassandra:

nodetool: Esta es una herramienta de línea de comandos incluida en Apache Cassandra que permite realizar operaciones de administración en el clúster. Con nodetool, puedes realizar tareas como agregar y eliminar nodos del clúster, ver el estado de los nodos individuales, realizar copias de seguridad y restauraciones, monitorear el rendimiento y obtener información sobre la topología del clúster. Cassandra Query Language (CQL): CQL es un lenguaje de consulta similar a SQL que se utiliza para interactuar con Apache Cassandra. A través de CQL, puedes ejecutar consultas y realizar operaciones de administración, como crear y modificar esquemas, administrar tablas y columnas, y realizar consultas de datos. CQL proporciona una interfaz flexible para administrar y manipular datos en Apache Cassandra. DataStax OpsCenter: OpsCenter es una herramienta de administración y monitoreo gráfico para Apache Cassandra proporcionada por DataStax. Permite monitorear el rendimiento y la salud del clúster, realizar ajustes de configuración, automatizar tareas de administración, realizar copias de seguridad y restauraciones, y recibir alertas en caso de problemas. OpsCenter proporciona una interfaz intuitiva y fácil de usar para administrar y monitorear clústeres de Apache Cassandra. Prometheus y Grafana: Estas son herramientas populares utilizadas para el monitoreo y la visualización de métricas en sistemas distribuidos, incluyendo Apache Cassandra. Prometheus es un sistema de monitoreo y alerta que recopila y almacena métricas, mientras que Grafana es una plataforma de visualización de datos. Juntas, permiten recopilar métricas de Apache Cassandra y crear paneles de control personalizados para monitorear el rendimiento del clúster y visualizar tendencias y patrones.

Usuarios Conocidos

• WalmartLabs​ (anteriormente Kosmix) usa Cassandra con SSD
• Apple usa 75,000 nodos de Cassandra, como se reveló en el Cassandra Summit San Francisco 2014.​
• AppScale usa Cassandra como back-end para aplicaciones de Google App Engine​
• CERN usa un prototipo basado en Cassandra para el experimento ATLAS para archivar su sistema de monitoreo en línea.​
• Cisco WebEx usa Cassandra para almacenar la retroalimentación y actividades de los usuarios en tiempo real.​
• Cloudkick usa Cassandra para almacenar métricas de los servidores de sus usuarios.​
• Constant Contact usa Cassandra en sus aplicaciones de correo electrónico y redes sociales.​
• Digg, un gran sitio web de noticias, anunció el 9 de septiembre de 2009 que empezó a usar Cassandra​
• Facebook usa Cassandra para su sistema de búsquedas en la bandeja de entrada, con una implemetanción de más de 200 nodos.​
• Formspring usa Cassandra para contar respuestas, así como para almacenar datos como seguidores, usuarios bloqueados, etc.​
• IBM realizó investigaciones para desarrollar un sistema de correo electrónico basado en Cassandra.​
• Mahalo.com usa Cassandra para guardar la actividad de sus usuarios y temas para su sitio Q&A​​
• Netflix usa Cassandra como base de datos de back-end para su servicio de streaming​​
• Nutanix usa Cassandra para almacenar metadatos y estadísticas.​
• Openwave usa Cassandra como base de datos distribuida y como mecanismo de almacenamiento para su plataforma de mensajes de próxima generación​
• OpenX tiene más de 130 nodos de Cassandra para OpenX Enterprise, donde almacena y replica anuncios y datos para propaganda​
• PostRank usa Cassandra como base de datos de backend​
• Rackspace usa Cassandra internamente.​
• Reddit se cambió a Cassandra de memcacheDB el 12 de marzo de 2010​ y experimentó algunos problemas en mayo por comenzar con pocos nodos.​
• RockYou usa Cassandra para grabar cada canción​
• SoundCloud usa Cassandra para almacenar el dashboard de sus usuarios​
• Talentica Software usa Cassandra como back-end para hacer análisis de datos, con más de 30 nodos insertando alrededor de 200GB de datos diariamente.​
• Twitter anunció que está planificando cambiar MySQL por Cassandra​​
• Urban Airship usa Cassandra con el servicio de almacenamiento movie, con más de 160 millones de aplicaciones instaladas en más de 80 millones de dispositivos​
• Wikimedia usa Cassandra como base de datos de backend.​
• Zoho usa Cassandra para una pre-visualización de su bandeja de entrada de Zoho Mail.

Facebook cambió su desarrollo de la versión preliminar de Apache Cassandra a finales de 2010, cuando reemplazaron la búsqueda en la bandeja de entrada por su plataforma de mensajería. En 2012, Facebook comenzó a usar Apache Cassandra en Instagram.​

Véase también

Uso académico

• BigTable
• Distributed database
• Distributed hash table (DHT)
• Dynamo (storage system) - Cassandra toma muchos elementos de Dynamo
• NoSQL

Alternativas populares

• Aerospike
• HyperDex
• Apache HBase - Apache Hadoop Basada en bases de datos distribuidas. Similar a BigTable
• MongoDB

Otras alternativas

• Apache Accumulo - Secure Apache Hadoop Basada en bases de datos distribuidas.
• Berkeley DB
• Druid (open-source data store)
• Hypertable - Apache Hadoop Basada en bases de datos distribuidas. Similar a BigTable
• Riak

Alternativas comerciales

• DataStax
• Impetus Technologies

Bibliografía

• Hewitt, Eben (15 de diciembre de 2010). Cassandra: The Definitive Guide (1st edición). O'Reilly Media. p. 300. ISBN 978-1-4493-9041-9. 
• Capriolo, Edward (15 de julio de 2011). Cassandra High Performance Cookbook (1st edición). Packt Publishing. p. 324. ISBN 1-84951-512-3. 
• Wolf, G. et al. (2015). Fundamentos de sistemas operativos (1st ed.). Universidad Nacional Autónoma de México, Instituto de Investigaciones Económicas: Facultad de Ingeniería. http://sistop.org/pdf/sistemas_operativos.pdf

Enlaces externos

• Sitio web del proyecto
• Arquitectura de Cassandra
• Proyecto Apache
• Lakshman, Avinash (25 de agosto de 2008). «Cassandra - A structured storage system on a P2P Network». Engineering @ Facebook's Notes. Consultado el 17 de junio de 2014. 
• «The Apache Cassandra Project». Forest Hill, MD, USA: The Apache Software Foundation. Consultado el 17 de junio de 2014. 
• «Project Wiki». Forest Hill, MD, USA: The Apache Software Foundation. Archivado desde el original el 14 de junio de 2014. Consultado el 17 de junio de 2014. 
• Hewitt, Eben (1 de diciembre de 2010). «Adopting Apache Cassandra». infoq.com. InfoQ, C4Media Inc. Consultado el 17 de junio de 2014. 
• Lakshman, Avinash; Malik, Prashant (15 de agosto de 2009). «Cassandra - A Decentralized Structured Storage System». cs.cornell.edu. The authors are from Facebook. Consultado el 17 de junio de 2014. 
• Ellis, Jonathan (29 de julio de 2009). «What Every Developer Should Know About Database Scalability». slideshare.net. Consultado el 17 de junio de 2014.  From the OSCON 2009 talk on RDBMS vs. Dynamo, BigTable, and Cassandra.
• «Cassandra-RPM - Red Hat Package Manager (RPM) build for the Apache Cassandra project». code.google.com. Menlo Park, CA, USA: Google Project Hosting. Consultado el 17 de junio de 2014. 
• Roth, Gregor (14 de octubre de 2012). «Cassandra by example - the path of read and write requests». slideshare.net. Consultado el 17 de junio de 2014. 
• Mansoor, Umer (4 de noviembre de 2012). «A collection of Cassandra tutorials». Consultado el 8 de febrero de 2015. 
• Bushik, Sergey (22 de octubre de 2012). «A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak». NetworkWorld. Framingham, MA, USA and Staines, Middlesex, UK: IDG. Archivado desde el original el 28 de mayo de 2014. Consultado el 17 de junio de 2014. 

• Datos: Q616639
• Multimedia: Apache Cassandra / Q616639