Bases de Datos NoSQL

Caso de Estudio:
Apache Cassandra

Alexander Carreño Cristina Miguel Teresa Tavernelli

Escuela de Computación
Licenciatura en Computación
Universidad Central de Venezuela
Caracas, Venezuela
Email: alexcristman@gmail.com
Escuela de Computación
Licenciatura en Computación
Universidad Central de Venezuela
Caracas, Venezuela
Email: cristinamiguelt@gmail.com
Escuela de Computación
Licenciatura en Computación
Universidad Central de Venezuela
Caracas, Venezuela
Email: teresa.tavernelli@gmail.com

Abstract - Apache Cassandra es una base de datos
NoSQL de código abierto, distribuida y de tipo hı́brida
(clave-valor y orientada a columnas), descentralizada
y multiplataforma que permite almacenar y gestionar
grandes volúmenes de datos de forma distribuida, siendo
su objetivo principal la escalabilidad lineal y la disponi-
bilidad.
simúltaneas. En julio del 2008 fue lanzada como un proyecto
de código abierto de Google Code. En marzo del 2009 se
transformó en un proyecto de Apache Incubator y en Febrero
del 2010 se graduó como un proyecto de alto nivel. [2]
2.1. Publicaciones después de la graduación

1. Introducción • Versión 0.6: Publicada el 12 de abril de 2010,

Cassandra fue originalmente creada por la famosa
empresa Facebook, actualmente es utilizada en los sitios
web más populares. La razón por la cual Cassandra ha
aumentado tanto su popularidad es la gran cantidad de
caracterı́sticas técnicas espectaculares que ofrece. Provee
durabilidad, escalabilidad sin inconvenientes, y consistencia
configurable. Permite realizar operaciones de escritura
implacablemente rápidas, y puede almacenar cientos de
terabytes de datos. Además de esto, ofrece un modelo
de datos ”schemaless”, es decir, sin esquema predefinido. [1]
Cassandra está desarrollada por Apache Software
Foundation en el lenguaje de programación Java. Su
infraestructura está basada en Amazon’s Dynamo y su
modelo de datos en Google’s BigTable. Es buena en lo que
se refiere a gestión de tamaño o grandes volúmenes de datos.
Las tablas se pueden crear, eliminar y alterar en tiempo
de ejecución sin necesidad de bloquear actualizaciones ni
consultas. [2]
añadieron soporte para cacheo integrado y para
Apache Hadoop.
• Versión 0.7: Publicada el 08 de enero de 2011,
agregaron ı́ndices secundarios y cambios en el
esquema de la base de datos.
• Versión 0.8: Publicada el 02 de junio de 2011,
se cambió el lenguaje Thrift por el lenguaje
CQL (Cassandra Query Language), además del
soporte para mantenerse funcionando durante
actualizaciones de versión.
• Versión 1.0: Publicada el 17 de octubre de 2011,
añaden compresión integrada, compactación por
niveles y se mejora el desempeño de lectura.
• Versión 1.1: Publicada el 23 de abril de 2012,
agregan aislamiento a nivel de fila y soporte para
desarrollo en múltiples sistemas de disco.

2. Historia • Versión 1.2: Publicada el 02 de enero de 2013,

Cassandra fue desarrollada en enero del año 2008 en
Facebook, para impulsar el rendimiento de su bandeja de
entrada, por Avinash Lakshman (uno de los autores de
Amazon’s Dynamo) y Prashant Malik. De manera más
especı́fica, debı́an manejar grandes volúmenes de datos en
forma de copias de mensajes, ı́ndices reversos de men-
sajes, y una gran cantidad de lecturas aleatorias y escrituras
añaden clustering a través de nodos virtuales,
comunicación entre nodos.
• Versión 2.0: Publicada el 04 de septiembre de
2013, agregan transacciones livianas (basadas en
el protocolo Paxos), triggers, y compactaciones
improvisadas.
 • Versión 2.0.4: Publicada el 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.
• Versión 2.1.0: Publicada el 10 de septiembre de
2014.
• Versión 2.1.5: Publicada en abril de 2015.
• Versión 2.2: Publicada en julio 2015.
• Versión 3.0: Publicada en octubre 2015.
• Versión 3.2: Publicada en febrero del 2016. [2] [3]
3. Caracterı́sticas
Para hablar sobre las caracterı́sticas de Cassandra,
primero se definirán tres conceptos muy importantes:
(a) Nodo: En la Figura 1-(a) se muestra gráficamente
un nodo, el cual es un lugar donde se almacenan los datos.
[4]
(b) Data Center: Colección de nodos relacionados en-
tre sı́. Es un centro de procesamiento de datos, como se
representa en la Figura 1-(b) [5]
(c) Cluster: Componente que contiene uno o varios
data centers. En la Figura 1-(c) podemos ver que el clúster
contiene tanto nodos como data centers. [6]
Figura 1. (a) Nodo, (b) Data Center y (c) Cluster
Ahora, teniendo claros los conceptos básicos, se
presentan las principales caracterı́sticas de Cassandra:
1) Descentralizado: Cassandra posee una estructura
descentralizada, esto significa que no existe la
estructura maestro-esclavo como en otras bases de
datos como HBase, por lo que todos los nodos
del clúster tienen el mismo rol y cada nodo puede
dar servicio a cualquier solicitud. Gracias a esta
caracterı́stica no hay un punto único de fallo, lo
cual favorece a la tolerancia a fallos. Al no tener
un punto central donde se guarda la información,
no se producen cuellos de botella.
2) Soporta replicación de múltiples data centers:
La arquitectura distribuida de Cassandra está
diseñada para desplegarse sobre múltiples data
centers. En Cassandra las estrategias de replicación
son configurables.
3) Escalabilidad: El rendimiento de leer y escribir
aumenta linealmente a medida que se añaden
nuevos nodos y Cassandra permite agregar nuevos
nodos sin necesidad de interrumpir la ejecución de
la aplicación.
4) Tolerancia a fallos: En Cassandra los datos se
replican automáticamente a múltiples nodos para
recuperarse frente a fallos. Por tanto, en caso
de que un nodo caiga, los datos que almacena
éste no se pierden ya que otros nodos del clúster
almacenan una copia de estos datos. Además, el
nodo que cae es reemplazado de forma muy rápida,
y por tanto, no se nota su ausencia al no haber
prácticamente tiempos de inactividad. Se puede
reemplazar nodos que presenten fallos sin tiempo
de inactividad o interrupción de la aplicación.
5) Consistencia: Se ofrece la elección del nivel de
consistencia para las lecturas y escrituras.
6) Soporte MapReduce: Cassandra está integrado
con Apache Hadoop para soportar MapReduce.
También existe soporte para Apache Pig y Apache
Hive.
7) Lenguaje de consulta CQL: Cassandra introduce
CQL (Cassandra Query Language) en la versión 0.8
, 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++. [7] [2]
4. Arquitectura
La arquitectura de Cassandra permite que sea un sistema
escalable, con alto rendimiento y que ofrezca un alto tiempo
de actividad. Cassandra no utiliza la estructura maestro-
esclavo caracterı́stica de algunos sistemas de bases de datos;
en cambio, tiene una estructura en anillo elegante, fácil de
configurar y de mantener.
En Cassandra, todos los nodos juegan el mismo papel;
no existe el concepto de nodo maestro, ya que todos los
nodos se comunican entre sı́ mediante un protocolo dis-
tribuido y escalable denominado protocolo ”gossip”. La
arquitectura escalable de Cassandra permite que sea capaz
de manejar grandes volúmenes de datos y miles de usuarios
concurrentes u operaciones por segundo, aún a través de
múltiples repositorios de datos. Para agregar más capacidad,
simplemente se deben agregar nuevos nodos a un clúster
existente sin tener que desactivarlo primero.
La arquitectura de Cassandra también permite que, a difer-
encia de los sistemas con estructura maestro-esclavo o con
fragmentación por sharding, no exista un punto único de
fallo por lo que es capaz de ofrecer disponibilidad y tiempo
de actividad de manera continua. [8]
4.1. Componentes
Los componentes mas básicos de la arquitectura de
Cassandra son el nodo, el data center y el clúster. Ademas
de estos tenemos:
• Log de commit: Es el mecanismo de recuperación
de Cassandra (todos las operaciones de escritura se
escriben aquı́). Aporta durabilidad a la base de datos.
• Memtable: Es una estructura de datos localizada en
memoria. Luego del log de commit, los datos se
escriben en el memtable.
• SSTable: Es un archivo de disco donde se hace el
volcado de datos del memtable cuando su contenido
alcanza un valor lı́mite. Es un concepto prestado de
Big Table de Google.
• Bloom Filter: Se utiliza como un acelerador del
rendimiento, es un conjunto de algoritmos rápidos
y no deterministas que sirven para verificar si un
elemento es parte de un set. Son no deterministas
ya que es posible obtener una lectura falso-positivo
de un bloom filter, mas no una falso-negativo. Los
filtros se almacenan en memoria y se utilizan para
mejorar el rendimiento al reducir accesos al disco en
las búsquedas de claves. Como el acceso a disco es
por lo general más lento que el acceso a memoria,
se puede ver el bloom filter como un tipo especial
de memoria caché. A la hora de hacer una consulta,
se verifica el bloom filter antes de acceder al disco.
Si el filtro indica que el elemento no existe en el
set, entonces no existe. Pero si indica que sı́ está, se
accede al disco para asegurar. [8]
Cuando se hace una operación de escritura, inmediata-
mente se escribe en el log de commit. Una escritura no
cuenta como exitosa hasta que se escribe en el log de commit
para asegurar que, aunque una operación de escritura no
se haya almacenado en la memtable, igual será posible
recuperar la data.
Luego de que se escribe en el log de commit, el valor se
almacena en la memtable. Cuando el número de objetos
almacenados en la memtable llega a un lı́mite, se hace
un volcado del contenido a disco en un archivo llamado
SSTable y se crea una nueva memtable.
Cada log de commit tiene un bit bandera interno para indicar
si necesita ser volcado. Cuando se recibe una operación de
escritura por primera vez, se escribe en el log de commit y
su bit bandera pasa a ser 1. Una vez que el contenido de la
Figura 2. Arquitectura de Cassandra [8]
memtable es volcado a disco en el SSTable, el bit bandera
del log de commit correspondiente pasa a ser 0, indicando
que el log de commit ya no tiene la data para efectos de
durabilidad. El SSTable luego pasa a ser inmutable y no
puede ser modificado por la aplicación.
Cada SSTable tiene un bloom filter asociado, que se utiliza
como un mejorador de rendimiento. Todas las escrituras son
secuenciales, que es la razón principal por la que tienen
un buen rendimiento en Cassandra. No se necesitan hacer
ni lecturas ni búsquedas para escribir un valor en Cassan-
dra ya que todas las escrituras son operaciones ”append”.
Es decir, son simplemente concatenaciones inmediatas, y
luego se compactan para estar más organizadas y dar mejor
rendimiento a la hora de una lectura futura.
En las operaciones de lectura, Cassandra verifica primero la
memtable para encontrar el valor. Las memtable se imple-
mentan mediante la clase org.apache.cassandra.db.Memtable
[8]. En la figura 2 se pueden apreciar los distintos compo-
nentes de la arquitectura de Cassandra y cómo se relacionan
entre sı́ mediante estos procesos.
4.2. Clustering
El sistema de bases de Cassandra está diseñado
especifı́camente para estar distribuido entre varias máquinas
que operan en conjunto que aparecen como una instancia
única al usuario final. La estructura que engloba todo en
Cassandra es el clúster, a veces denominado el anillo,
ya que Cassandra asigna datos a los distintos nodos en
el clúster ordenándolos en una estructura de anillo. Cada
nodo almacena una réplica para distintos rangos de datos.
Si cae el nodo primario, la réplica puede dar respuesta a
las consultas que se hagan en ese momento. El protocolo
peer-to-peer permite que los datos se repliquen a lo largo
de los nodos de forma transparente al usuario. [8] Cuando
se diseña el clúster para Apache Cassandra, un punto
importante es seleccionar la partición correcta. [2]
Existen dos tipos de partición:
• Partición Aleatoria (RP): Este tipo de 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 acceder a más nodos
para obtener un número de claves.
• Partición Preservar el Orden (OPP): Este tipo
de partición distribuye las tuplas clave-valor en una
forma bastante 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 pares clave-valor en los
distintos nodos. [2]
4.3. Protocolo Peer-to-Peer
Cassandra tiene un modelo de distribución peer-to-peer,
o punto a punto, basado en el principio de que cada nodo
es estructuralmente idéntico a los demás nodos, es decir, no
existe ningún nodo maestro que actúe distinto a un nodo
esclavo. En la figura 3 se puede apreciar la estructura del
protocolo peer-to-peer.
El objetivo del diseño de Cassandra es proveer en disponi-
bilidad y buena escalabilidad. Este diseño peer-to-peer
puede mejorar la disponibilidad de la base de datos en
general, ya que aunque cuando un nodo esté offline puede
causar un impacto potencial en el rendimiento general, de
todas formas no interrumpe el servicio. Asumiendo que se
esté utilizando una estrategia de replicación razonable, los
datos de un determinado nodo seguirán estando disponibles
para las solicitudes de lectura y escritura.
Este diseño también facilita el escalamiento al agregar
nuevos nodos. Como el comportamiento de cada nodo es
idéntico, para añadir un nuevo servidor simplemente hay
que añadirlo al clúster. Como el nuevo nodo no comienza
inmediatamente a aceptar solicitudes, le da tiempo para
aprender la topologı́a de anillo y luego aceptar los datos
de los que será responsable. Luego de esto, puede unirse
al anillo como un miembro legal y comenzar a aceptar
las solicitudes. Esto se realiza de manera automática y
requiere muy poca configuración, por lo que el diseño peer-
to-peer facilita muchı́simo más el escalamiento que en una
estructura maestro-esclavo. [8]
Figura 3. Protocolo Peer-to-Peer
4.4. Factor de Replicación
El factor de replicación se refiere al número de nodos
en los cuales se ha replicado los datos. En otras palabras,
especifica cuántas copias de cada dato serán almacenados
y distribuidos a través del clúster de Cassandra. Cassandra
ofrece un factor de replicación configurable que per-
mite establecer cuánto se quiere sacrificar en rendimiento
para ganar más consistencia. Se especifica con el ajuste
replication factor o se puede establecer en el archivo de
configuración en la API.
Con un factor de replicación de 1, los datos van a existir
en un único nodo del clúster. Perder ese nodo ocasiona que
los datos pierdan la disponibilidad. También ocasiona que
Cassandra tenga que esforzarse más para coordinar a los
nodos. Si todos los datos de una determinada clave están
en un nodo B, cada solicitud de cliente para esa clave que
entra por el nodo A, tendrá que ser reenviada.
Si el factor de replicación es 3, esto quiere decir que tres
nodos en el anillo tendrán copias de cada fila.
El factor de replicación no debe ser mayor que el número
de nodos del clúster. La consistencia se alcanza cuando el
valor de la réplica de lectura más el valor de la réplica de
escritura es mayor al factor de replicación.
Por ejemplo, si se tienen 10 nodos en el clúster, se podrı́a
establecer el factor de replicación en 10 como máximo. Pero
no es conveniente hacerlo, ya que limita las ventajas de
Cassandra y se impide la disponibilidad. Ya que si falla uno
nodo, no se tendrá un alto nivel de consistencia. [8]
4.5. Nivel de Consistencia
Es un ajuste configurable que permite especificar cuántas
réplicas en el clúster deben reconocer una operación de
escritura o responder a una operación de lectura para ser
considerada exitosa. El nivel de consistencia se establece
en base al factor de replicación, no el número total de
nodos del clúster. Hay muchos niveles de consistencia que
se pueden configurar para mejorar el rendimiento. El nivel
con mejor rendimiento tiene el menor nivel de consistencia.
Significan cosas distintas para escribir y leer. [8]
Para operaciones de escritura:
• ZERO: Las operaciones de escritura se manejan en
segundo plano de forma ası́ncrona. Es la forma más
rápida de escribir la data, y la que ofrece menos
seguridad en cuanto al éxito de las operaciones. Le
da respuesta inmediata al cliente antes de que la
escritura sea registrada.
• ANY: asegura que la operación de escritura
fue exitosa en al menos un nodo, aunque el
reconocimiento sea solo de una pista y no de una
escritura como tal. Este nivel de consistencia es
relativamente débil.
• ONE: asegura que la operación de escritura fue
hecha en al menos un nodo, incluyendo su log de
 commit y memtable. Si un solo nodo responde, la
escritura se considera exitosa.
• QUORUM: el cuórum es el número de nodos que
representa un consenso sobre una operación (que
fue reconocida por la mayorı́a de las réplicas). Se
determina por la siguiente ecuación:
QU ORU M = RF/2 + 1 (1)
Ası́ que si se tiene un factor de replicación de
10, entonces solo 6 réplicas son las que deben
reconocer la operación para obtener el cuórum
suficiente.
• DCQUORUM: es una versión de QUORUM que
prefiere elegir réplicas del mismo data center para
balancear el alto nivel de consistencia de cuórum
con la baja latencia de preferir llevar a cabo las
operaciones en réplicas del mismo data center.
• ALL: Todos los nodos (especificados en el factor
de replicación) deben reconocer de manera exitosa
la operación de escritura. Si algún nodo no la re-
conoce, la escritura falla. Este es el nivel más alto
de consistencia y el más bajo de rendimiento.
Para operaciones de lectura:
• ONE: retorna el valor del primer nodo que responda
a la consulta. Se crea un hilo en segundo plano
para comparar el registro con ese mismo registro
dentro de otras réplicas.
• QUORUM: consulta a todos los nodos y una
vez que la mayorı́a de las réplicas ha respondido,
determinado por el cuórum, retorna el valor con la
marca de tiempo más reciente.
• DCQUORUM: asegura que solo nodos del mismo
data center sean consultados.
• ALL: consulta a todos los nodos y retorna el valor
con la marca de tiempo más reciente. Este nivel
espera a que todos los nodos respondan. Si uno no
responde, falla la operación de lectura.
No existe nivel de consistencia ZERO para las operaciones
de lectura ya que no tiene sentido especificar que se quiere
leer algún dato y no se necesita ningún nodo de donde leerlo.
4.6. Estrategia de Colocación de Réplicas
Especifica la manera en que se colocan las réplicas en el
anillo. Existen distintas estrategias que trabajan con Cassan-
dra para determinar cuáles nodos obtendrán copias de cuáles
claves. Escoger la estrategia adecuada es importante ya que
determina cuáles nodos son responsables por cuáles rangos
de claves. Es decir, se determina cuáles nodos recibirán
cuáles operaciones de escritura.
La variedad de estrategias permite tener mayor flexibilidad,
ası́ que se pueda configurar Cassandra de acuerdo a nuestras
necesidades y la topologı́a de nuestra red.
• Simple Strategy: Especifica un factor de replicación
simple para el clúster. Esta estrategia coloca las
réplicas en un solo data center, de forma que
no tenga que estar pendiente de su ubicación
dentro de un grupo de data centers (clúster). La
implementacin es rápida en teorı́a, pero no si el
siguiente nodo que tenga la clave dada se encuentra
en un grupo distinto de data centers.
• Network Topology Strategy: Permite especificar
de manera más balanceada, la manera en que las
réplicas serán colocadas a través de los data centers.
Se deben especificar los parámetros indicando la
estrategia de replicación deseada para cada data
center. La implementación es bastante flexible.
• Old Network Topology Strategy: Se utiliza para
distribuir datos a través de un data center original.
En este caso, la réplica sı́ está consciente de su
ubicación en el data center. Si por ejemplo se tienen
dos data centers, DC1 y DC2, y un set de servidores
de Cassandra. Esta estrategia coloca algunas réplicas
en DC1. También se asegura de que otra réplica sea
colocada en DC2. Es ideal para cuando se tienen
nodos del mismo clúster esparcidos en dos data
centers distintos, y se usa un factor de replicación
de 3. [8]
4.7. Protocolo Gossip
Para dar soporte a la descentralización y la tolerancia
a particiones, Cassandra utiliza el protocolo Gossip para
comunicaciones dentro del anillo de forma que cada nodo
pueda tener información sobre los estados de otros nodos.
El protocolo Gossip por lo general asume que la red tiene
fallas. Se basa en el concepto del ”gossip”, o chisme, una
forma de comunicación en la cual las personas pueden
escoger con quiénes intercambian información.
El protocolo Gossip en Cassandra se implementa por
la clase org.apache.cassandra.gms.Gossiper, la cual es
responsable del manejo del ”gossip” en el nodo local.
Cuando se inicia un nodo del servidor, se registra a sı́
mismo con el Gossiper para recibir información sobre los
estados de punto final. Como este protocolo se utiliza para
la detección de fallas, la clase Gossiper mantiene una lista
de nodos ası́ estén vivos o muertos. El Gossiper, a su vez,
se ejecuta cada segundo en un timer. [8]
Ası́ funciona el Gossiper:
1) Periódicamente, de acuerdo a la configuración
del TimerTask, el Gossiper selecciona un nodo
aleatorio en el anillo e inicia una sesión Gossip con
él. Cada ronda de Gossip requiere tres mensajes.
 2) El iniciador del gossip envı́a a su ”amigo”
seleccionado un GossipDigestSynMessage.
3) Cuando el amigo recibe el mensaje, responde con
un GossipDigestAckMessage.
4) Cuando el iniciador recibe el mensaje ack del
amigo, le envı́a un GossipDigestAck2Message
para finalizar la ronda de gossip
5) Cuando el Gossiper descubre que otro punto final
murió, condena ese punto final marcándolo como
muerto en su lista local y almacenando esto en el
log. [8]
Figura 4. Protocolo Gossip en Cassandra
4.8. Hinted Handoff
Consideremos el siguiente escenario: se hace una solici-
tud de escritura a Cassandra pero el nodo no está disponible
ya sea por una partición de la red, fallas de hardware, o
alguna otra razón. Para asegurar disponibilidad general en
el anillo en una situación como esta, Cassandra implementa
el ”Hinted Handoff”. Se puede ver una ”hint”, o pista,
como una notica o post-it que contiene la información de
la solicitud de escritura. Si el nodo B al que pertenece la
escritura falla, el nodo A que recibe la solicitud de escritura,
crea una pista la cual es un pequeño recordatorio que dice
”Tengo la información de escritura para el nodo B, me voy
a quedar con esta escritura y cuando el nodo B vuelva a
estar online (mediante el protocolo Gossip), le voy a enviar
la solicitud”. Es decir, el nodo A le va a ”hand off”, o
entregar, al nodo B la pista correspondiente a la escritura.
Esto le permite a Cassandra tener siempre disponibilidad
para las escrituras, y reduce el tiempo en el que un nodo
fallido esté inconsistente antes de volver a estar online. Un
Hinted Handoff no cuenta como reconocimiento suficiente
para una operación de escritura si el nivel de consistencia es
ONE, QUORUM o ALL. La pista sı́ cuenta como escritura
si el nivel de consistencia es ANY. En pocas palabras, las
escrituras con pistas no pueden ser leı́das por ellas mismas.
En este nivel de consistencia, ası́ una sola pista haya podido
ser grabada, la escritura se cuenta como exitosa. [8]
5. Modelo de Datos
Como se menciona anteriormente, la estructura que en-
globa todo en Cassandra es el clúster. Cuando nos referimos
al modelo de datos en Cassandra, la estructura equivalente
a una base de datos de datos relacional es el keyspace,
el cual es esencialmente un contenedor lógico donde se
define el resto del modelo y algunas propiedades de con-
figuración. Dentro del clúster de Cassandra pueden existir
varios keyspaces. Como se puede apreciar en la figura 5,
el keyspace puede contener una o más familias de colum-
nas, las cuales a su vez contienen filas, que son las que
contienen las distintas columnas y/o súper columnas donde
estarán definidos los datos, estos conceptos se explicarán
más adelante en esta sección.
Figura 5. Modelo de datos de Cassandra
5.1. Columna
Una columna es la unidad más básica de estructura de
datos en el modelo de datos Cassandra. Una columna es
una tripleta de un nombre, un valor y un reloj, que se
puede considerar como un ”timestamp”, o marca de tiempo.
Aunque estamos familiarizados con el término ”columnas”
del mundo relacional, es confuso pensar en ellas de la misma
manera en Cassandra. En primer lugar, cuando se diseña
una base de datos relacional, se especifica la estructura de
las tablas desde el principio mediante la asignación de un
nombre para todas las columnas de la tabla; luego, cuando
se escriben los datos simplemente se suministran los valores
para la estructura predefinida.
Pero en Cassandra, no se definen las columnas por ade-
lantado; solo se definen las familias de columnas cuando
se quiera en el keyspace, y luego se puede comenzar la
escritura de datos, sin definir las columnas aún. Esto es
porque en Cassandra, todos los nombres de las columnas
son suministrados por el cliente.
Esto añade una gran flexibilidad a la forma en que una
aplicación trabaja con los datos.
Como se ve en la figura 6, los campos nombre y valor
son arreglos de bytes, aunque pueden pasar como simples
strings. Como estos campos son de tipo binario, pueden
ser de cualquier longitud. El tipo de dato del timestamp
es org.apache.cassandra.db.IClock. [9]
 Figura 6. Estructura de una columna en Cassandra [9]

5.2. Súper Columna

Una súper columna es un tipo especial de columna.

Ambos tipos de columnas son pares nombre/valor, pero una
columna regular almacena un arreglo de bytes, y el valor
de una súper columna es un mapa de subcolumnas (que
Figura 8. Familia de columnas en Cassandra [9]
almacenan arreglos de bytes). Se debe tomar en cuenta que
una súper columna sólo almacena un mapa de columnas
asociadas a ella; no se puede definir una súper columna que
almacene un mapa de otras súper columnas.
La estructura básica de una súper columna es su nombre,
que es un arreglo de bytes, y las columnas que almacena.
Sus columnas se almacenan como un mapa cuyas claves
son los nombres de las columnas y cuyos valores son las
columnas. Esto se puede apreciar mejor en la figura 7.
Cada familia de columnas se almacena en disco en archivos
separados. Ası́ que para optimizar el rendimiento, es impor-
tante mantener juntas en la misma familia de columnas a
las columnas que se van a consultar en conjunto. Para esto Figura 9. Familia de súper columnas en Cassandra [9]
sirven las súper columnas. [9]

definidas, las columnas no, y se puede incorporar

cualquier columna a cualquier familia de columnas
Figura 7. Estructura de una súper columna en Cassandra [9]
en cualquier momento.

2) En la tabla relacional, se definen las columnas

5.3. Familia de Columnas y luego el usuario llena las tablas con valores,
mientras que en la familia de columnas una tabla
contiene columnas, o se puede definir como una
Una familia de columnas es un contenedor para una
familia de súper columnas. Las ventajas de usar
colección ordenada de filas. Cada fila, a su vez, es una
una familia de súper columnas es que permite
colección ordenada de columnas. Cuando se escriben datos
”nesting”, o anidado de columnas.
en una familia de columnas, se especifican los valores para
una o mś columnas a la vez. Esa colecciń de valores juntos
3) La tabla relacional tiene tantos atributos como
con un identificador único se llama fila. Cada fila tiene una
columnas sean definidas en la tabla, mientras
clave única que actúa como el identificador único de clave
que la familia de columnas tiene dos atributos:
primaria para esa fila. Es decir, se puede ver la fila como
nombre y comparador. El valor del comparador
un contenedor de columnas. [9]
indica cómo se ordenarán las columnas cuando se
En Cassandra, se pueden crear tanto familias de columnas,
retornen en una consulta.
representado en la figura 8, como familias de súper colum-
nas, representado en la figura 9.
4) En una tabla relacional es transparente al usuario
A pesar de que se puede ver una familia de columna como
cómo se almacenan las tablas en disco (y no es
el equivalente a una tabla en una bases de datos relacional,
común escuchar sugerencias sobre el modelado de
a continuación se enumeran algunos puntos que diferencian
datos basado en cómo se almacenan las tablas en
a una familia de columnas de la tabla:
disco), mientras que en Cassandra las familias de
1) La tabla relacional tiene un esquema rı́gido, una columnas se almacenan en archivos separados en
vez que se define la estructura luego no se pueden disco. Es importante mantener las columnas que se
agregar columnas, mientras que en una familia de relacionen definidas juntas en la misma familia de
columnas aunque las familias de columnas estén columnas. [9]
6. Lenguajes de Definición y Manejo de Datos UUID versión 1.

6.1. Apache Thrift Funciones para usar con timeuuid [17]:

– dateof(): Esta función retorna el timestamp de
Para la comunicación con la base de datos de Cassandra
la columna timeuuid como una fecha
se utiliza Apache Thrift siendo este un framework para el
– now(): Genera un nuevo y único timeuuid en
desarrollo entre lenguajes de servicios escalables. Combina
milisegundos cuando la declaración es ejecu-
una pila de software con un motor de generación de código
tada
para construir servicios que funcionan de manera eficiente
– minTimeuuid() y maxTimeuuid(): Estas fun-
y sin problemas entre C , Java, Python, PHP, Ruby, Erlang,
ciones retornan los timeuuid según la
Perl, Haskell, C# , cacao, JavaScript, Node.js, Smalltalk,
condición dada como fecha.
OCaml y Delphi y otros lenguajes. [10]
Ejemplo haciendo uso de la funciones [11]:
Creación de una columna en Thrift bajo el lenguaje
Java [11]: 1. Creación de la tabla tweets para la creación y
muestra de tweets de un usuario. En esta tabla
Column col = new Column(ByteBuffer.wrap("key declaramos el tipo de dato timeuuid.
".getBytes()));
col.setValue(ByteBuffer.wrap("value".getBytes CREATE TABLE tweets(
())); usuario text,
col.setTimeStamp(System.currentTimeMillis()); tweetid timeuuid,
mensaje text,
ColumOrSuperColumn cosc = new PRIMARY KEY (usuario, tweetid)
ColumnOrSuperColumn(); );
cos.setColumn(col);
2. Se hace la inserción de un mensaje (tweet)
6.2. CQL INSERT INTO tweets(tweetid, usuario,
mensaje) VALUES (now(), ’Cristina’, ’Me
Este lenguaje se introdujo en la versión 0.8 de Cassandra gusta mucho la materia NoSQL :D’);
[12]. Es similar a SQL pero con menos funcionalidades
como JOIN, GROUP BY, o FOREIGN KEY [13]. 3. Por último se selecciona el/los tweet(s) de cierta
Se pueden utilizar drivers para trabajar en Java, Python, fecha
Node.JS, Go, C++ y Spark [14].
SELECT dateOf(tweetid), mensaje
from tweets
Los tipos de datos que soporta CQL son los siguientes: where username=’Cristina’ and tweetid >
[15] minTimeuuid(’2016-04-04’);

6.2.1. Strings. tweetid |mensaje

---------------------------------------
• ascii: Cadena de caracteres ASCII 2016-04-04 |Me gusta mucho la materia
• text: Cadena de caracteres con codificación UTF-8 NoSQL :D
• varchar: Cadena de caracteres con codificación 2016-05-04 |Me encanta cantar!!!
UTF-8
• inet: Dirección IP en formato IPv4 o IPv6
6.2.4. Collections.
6.2.2. Numéricos.
• list: Colección de uno o más elementos
• int: Entero de 32 bits • set: Colección de uno o más elementos ordenados
• float: Punto flotante IEEE de 32 bits • map: Arreglo de elementos al estilo:
• double: Punto flotante IEEE de 64 bits
• varint: Entero con precisin arbitraria JSON: {clave:valor, clave:valor...}
• bigint: Entero de 64 bits
• decimal: Punto flotante IEEE de 32 bits Ejemplo de cada colección [18]
• counter: Punto flotante IEEE de 64 bits
1. Se realiza la creación de la tabla usuarios donde
6.2.3. UUIDs. se declara la colección correos con set
• uuid: Identificador único universal [16] CREATE TABLE usuarios (
• timeuuid: Tiene unas pocas funciones extras que usuario_id uuid,
permiten traer la información del tiempo. Solamente nombre text,
 apellido text, WHERE usuario_id = b2e58918-fc2d-11e5-
correos set<text>, 86aa-5e5517507c55;
nacionalidad text,
PRIMARY KEY (nacionalidad, usuario_id)
); nombre |apellido |eras
---------------------------------------------
2. Luego se realizan las inserciones en la colección correos Luke |Skywalker |
{’Legado’,’La Nueva Orden Jedi’,’Alzamiento
INSERT INTO usuarios (usuario_id, nombre, del Imperio’,’La Rebelion’}
apellido, correos, nacionalidad)
VALUES(b2e58918-fc2d-11e5-86aa-5e5517507c55, 8. Se puede hacer una inserción en una posición especı́fica
’Luke’, ’Skywalker’, {’lukeskywalker@episode7 de la colección ”eras” de la siguiente manera
.com’, ’jedi_luke_skywalker@starwars.com’}, ’
Tatooine’); UPDATE usuarios
SET eras[2] = ’Otra era’
3. Se realiza la actualización agregando otro correo WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5
e5517507c55;
UPDATE usuarios SET correos = correos + {’
episode7_luke@tatooine.com’} WHERE usuario_id 9. Se puede borrar también los datos de una posición es-
= b2e58918-fc2d-11e5-86aa-5e5517507c55; pecı́fica

4. Se realiza la consulta para ver los correos del usuario DELETE eras[3]
FROM usuarios
”Luke Skywalker”
WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5
SELECT nombre, apellido, correos FROM e5517507c55;
usuarios WHERE usuario_id = b2e58918-fc2d-11
e5-86aa-5e5517507c55; 10. Ahora se agrega una nueva columna para realizar algunas
operaciones con map
nombre |apellido |correos
--------------------------------------------- ALTER TABLE usuarios ADD afiliaciones map<
Luke |Skywalker | timestamp, text>;
{’episode7_luke@tatooine.com’,
’jedi_luke_skywalker@starwars.com’, 11. Se realiza la actualización insertando valores a la
’lukeskywalker@episode7.com’} columna ”afiliaciones”

5. Ahora se agrega una nueva columna para realizar algunas UPDATE usuarios
operaciones con list SET afiliaciones =
{ ’5812-9-24 12:00’ : ’Alianza para Restaurar
ALTER TABLE usuarios ADD eras list<text>; la Republica’,
’5820-10-2 12:00’ : ’Orden Jedi’ }
UPDATE usuarios WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5
SET eras = [ ’La Nueva Orden Jedi’, e5517507c55;
’Alzamiento del Imperio’]
WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5 12. Si se quiere borrar un campo en especı́fico se puede
e5517507c55; hacer de la siguiente manera

6. Realizando inserciones al principio y al final de la DELETE afiliaciones[’5820-10-2’]

columna ”eras” FROM usuarios
WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5
UPDATE usuarios e5517507c55;
SET eras = [’Legado’] + eras
WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5 13. Realizando la consulta para observar el resultado
e5517507c55; obtenido
UPDATE usuarios SELECT nombre, apellido, afiliaciones
SET eras = eras + [’La Rebelion’] FROM usuarios
WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5 WHERE usuario_id = b2e58918-fc2d-11e5-86aa-5
e5517507c55; e5517507c55;

7. Realizando una consulta para ver las ”eras” insertadas nombre |apellido |afiliaciones
---------------------------------------------
SELECT usuario_id, nombre, apellido, eras Luke |Skywalker | {’5812-9-24 12:00’ :
FROM usuarios ’Alianza para Restaurar la Republica’}
6.2.5. Varios. calle text,
ciudad text,
• boolean: Verdadero o Falso codigo_postal int,
• blob: Bytes expresados en hexadecimal definidos telefono text
como (0[xX](hex)+) )
• timestamp: Fecha y hora, codificados en 8 bytes
2. Luego se crea la tabla usuario, declarando el tipo de dato
6.3. Índices definido direccion
CREATE TABLE usuario (
En Cassandra solo se crean los ı́ndices secundarios ya usuario_id uuid PRIMARY KEY,
que por defecto se definen los ı́ndices primarios a través de nombre text,
la(s) claves de partición y las claves primarias. [19] usuario_direccion frozen <address>
);
Ejemplo de ı́ndices haciendo uso de la tabla usuarios
de la sección 6.2.4: Se nota que para declarar el tipo de dato definido se hace
uso de la palabra frozen, ésta se usaba con el fin de que
CREATE TABLE usuarios (
usuario_id uuid,
si se querı́a insertar o actualizar algún campo se tenı́an
nombre text, que actualizar todos los campos. Esta función ya no esta
apellido text, disponible en la versión 3.0 de Cassandra pero se mantiene
correos set<text>, la palabra frozen para declarar el tipo de dato definido. [22]
nacionalidad text,
PRIMARY KEY (nacionalidad, usuario_id) 3. Se hace la inserción en la tabla usuario
);
INSERT INTO usuario (usuario_id, name,
Si se quiere realizar operaciones con alguna columna que no usuario_direccion)
forme parte de la PRIMARY KEY se puede hacer creando VALUES (000599fe-fdff-11e5-86aa-5e5517507c66,
’Mercy Ospina’, {calle: ’191 Rue St. Charles
un ı́ndice secundario de la siguiente manera (en este caso
’, ciudad: ’Paris’, codigo_postal: 75015,
se seleccionó la columna apellido) telefono: ’33 6 78 90 12 34’});
CREATE INDEX usuario_apellido ON usuarios (
apellido); 4. Por ultimo se realiza la consulta para obtener la dirección
del usuario
Ahora se pueden realizar operaciones con la columna apel-
SELECT nombre, usuario_direccion FROM usuario
lido WHERE usuario_id=000599fe-fdff-11e5-86aa-5
e5517507c66;
SELECT nombre, nacionalidad FROM usuarios
WHERE apellido=’Skywalker’;
nombre |usuario_direccion
---------------------------------------------
nombre |nacionalidad
Mercy Ospina |{calle: ’191 Rue St. Charles’,
---------------------------------------------
ciudad: ’Paris’, codigo_postal: 75015,
Luke |Tatooine
telefono: ’33 6 78 90 12 34’}

6.4. Tipos de datos definidos por el usuario

6.5. Consistencia
Un tipo de dato definido por el usuario facilita el
A través del CQL Shell se puede ver el nivel de
manejo de múltiples campos de la información relacionada
consistencia actual, o establecer un nuevo nivel. [23]
en una tabla. [20]
Para saber cuál es el nivel de consistencia actual, se
Estos se definen de la siguiente manera [21]:
realiza de la siguiente manera:
CREATE TYPE tipo_nombre
(campo, campo, ...);
cqlsh> CONSISTENCY level
Ejemplo de tipo de dato definido:
El sistema arrojará un mensaje indicado cuál es el nivel de
1. Se crea un tipo de dato definido por el usuario consistencia
que se llama direccion cqlsh> Current consistency level is ONE.
CREATE TYPE direccion (
Si se quiere cambiar el nivel de consistencia se puede 7.2. Spotify
realizar de la siguiente manera:
Spotify es una aplicación multiplataforma empleada
cqlsh> CONSISTENCY QUORUM para la reproducción de música vı́a streaming. Permite
escuchar en modo radio buscando por artista, álbum o listas
El sistema arrojará un mensaje indicado el cambio realizado de reproducción creadas por los propios usuarios.
cqlsh> Consistency level set to QUORUM.
A continuación se muestran los retos, soluciones y
resultados obtenidos:
6.6. Diferencias entre SQL y CQL Retos
• Escalamiento limitado a través de data centers
SQL CQL • El sistema relacional no puede ofrecer el 100% de
disponibilidad del servicio streaming
Soporta funciones como No soporta JOIN y • Dificultad para analizar grandes volúmenes de datos
JOIN y GROUPBY GROUPBY
Soluciones
Soporta transacciones No soporta transac-
ciones • Apache Cassandra para la persistencia de los datos
Hay soporte de subcon- No hay soporte de sub- almacenados
sultas consultas • Replicación de la data para el 100% de la disponi-
Permite ordenar resulta- No permite ordenar re- bilidad de éesta
dos en tiempo de con- sultados en tiempo de • Integración con Apache Spark para el procesamiento
sulta consulta y análisis de los datos en tiempo real
Resultados
7. Usuarios Conocidos
• Más de 1,5 millones de listas de reproducción
Algunos de los usuarios más conocidos de Cassandra creadas y gestionadas en tiempo real
son Coursera [24] y Spotify [25] [26]. • Más de 40.000 peticiones/segundo manejadas sin
latencia
7.1. Coursera • Más de 500 nodos Cassandra a través de los 4000
servidores en 4 data centers
Coursera es una plataforma educativa que se asocia con
las principales universidades y organizaciones de todo el 7.3. Otros usuarios conocidos
mundo, para ofrecer cursos en lı́nea para cualquiera, de
forma gratuita. 1) Instagram: Haciendo el cambio de Redis a Cassan-
dra obtuvieron un ahorro del 75%. [27]
A continuación se muestran los retos, soluciones y 2) Ebay: Usa Cassandra para almacenar la actividad
resultados obtenidos: de los usuarios con el fin de saber el interés que
estos tienen con los productos. [28]
Retos 3) Reddit: Usa Cassandra para el escalamiento hori-
• Inesperada inactividad de la aplicación debido a los zontal, gestionando ası́ 17.000 votos diariamente.
puntos únicos de fallo en RDBMS [29]
• Limitaciones para introducir nuevas caracterı́sticas 4) NetFlix: Para la gestión de los datos masivos esta
debido a los problemas de escalamiento empresa la está realizando a través de Cassandra.
• Rendimiento inestable con MySQL [30]
5) SoundCloud: Usa Cassandra para múltiples aplica-
Soluciones ciones; una de estas aplicaciones es la actividad del
• Arquitectura sin maestro que ofrece el 100% de la Feed. [31]
disponibilidad de las aplicaciones
• Facilidad de escala para permitir el almacenamiento 8. Conclusiones
de los datos de los usuarios que está creciendo
• Fiable rendimiento en la escritura y lectura Cassandra presenta distintas ventajas sobre las bases de
datos relacionales con las que se ha venido trabajando hasta
Resultados
ahora. Si se quiere trabajar en un ambiente distribuido,
• Disponibilidad 24/7 de los cursos para los usuarios donde los datos se encuentran almacenados en distintas
• Expansión de múltiples data centers para apoyar la máquinas, la opción adecuada es Cassandra, ya que provee
demanda siempre disponibilidad y tiempos de respuesta rápidos, ası́
alguna de las máquinas no se encuentre disponible en un
momento determinado. Además, provee robustez en cuanto
al manejo de fallos ya sea por una partición en la red,
problemas de hardware, entre otros. Cassandra también per-
mite cambiar la estructura de datos en cualquier momento
determinado para cumplir con las demandas de los usuarios.
Pero ası́ como toda base de datos tiene sus limitaciones,
una desventaja principal de Cassandra es que no provee
soporte para joins ni para subconsultas, y posee un soporte
muy limitado para las operaciones de agregación. Esto es,
por diseño, para obligar al programador a desnormalizar la
base de datos en particiones que puedan ser consultadas
fácilmente desde una sola réplica, a diferencia de tener que
recolectar los datos del otro lado del clúster. Además de esto,
no permite ordenar resultados en tiempo de consulta ya que
el ordenamiento se realiza en cada partición individual, y se
especifica a la hora de crear las tablas.
Sabiendo esto, de igual forma se puede concluir que la canti-
dad de ventajas que tiene Cassandra contrarresta sus desven-
tajas o limitaciones. Teniendo en consideración también
que, en algunos casos, estas limitaciones no presentan casi
ningún incoveniente para el usuario final. Todo depende del
ambiente donde se esté trabajando.
Referencias
[1] E. Hewitt, “Why apache cassandra?” Cassandra The Definitive Guide,
2011.
[2] V. AA, “Apache cassandra.”
[3] A. S. Foundation, “Versions of cassandra.”
[4] F. Maldonado, “Sistemas de bases de datos.”
[5] C. LTD, “qué es un data center, centro de datos o cpd?”
[6] V. Autores, “Revista unam - cluster.”
[7] S. N. Ali, “Benchmarking distributed system in the cloud: Yahoo!
ycsb.”
[8] E. Hewitt, “The cassandra architecture,” Cassandra The Definitive
Guide, 2011.
[9] ——, “The cassandra data model,” Cassandra The Definitive Guide,
2011.
[10] A. S. Foundation, “Apache thrift.”
[11] E. Evans, “Cassandra by example: Data modelling with cql3.”
[12] J. Ellis, “Whats new in cassandra 0.8, part 1: Cql, the cassandra query
language.”
[13] A. Meng, “Cassandra query language cql vs sql.”
[14] A. S. Foundation, “Apache cassandra client drivers.”
[15] DataStax, “Cql data types.”
[16] Wikipedia, “Identificador nico universal.”
[17] DataStax, “uuid and timeuuid functions.”
[18] ——, “Using collections.”
[19] Flavian, “A series on cassandra part 2: Indexes and keys.”
[20] DataStax, “User-defined type.”
[21] ——, “Using a user-defined type.”
[22] S. Lebresne, “Ability to freeze udt.”
[23] DataStax, “Consistency.”
[24] D. Chia, “Coursera migrates to the top of the class; moves their
over 9 million students to cassandra for an always on, on-demand
classroom.”
[25] wikipedia, “Spotify.”
[26] J. Mardell, “Spotify scales to the top of the charts with apache
cassandra at 40k requests/second.”
[27] R. Branson, “Facebooks instagram: Making the switch to cassandra
from redis, a 75
[28] T. Pinckney, “ebay chooses apache cassandra to power next genera-
tion recommendation engine.”
[29] J. Harvey, “Reddit upvotes apache cassandra for horizontal scaling;
managing 17,000,000 votes daily.”
[30] A. Cockcroft, “Case study — netflix.”
[31] O. Aladini, “Soundclouds activity feed and real-time stats powered
by apache cassandra.”