Breve presentación para conocer Apache Cassandra basada en Bases de Datos No-SQL.

1. Apache Cassandra
Bases de Datos No-SQL

2. ¿Por qué surge No-SQL?
• La mayoría de los motores de bases de datos, de la actualidad, se
basan en la arquitectura relacional, y todos ellos utilizan el
lenguaje de consultas SQL (con variaciones) para operar con los
datos.
• Las bases de datos relacionales no tienen nada de malo. Gracias a
ellas hemos conseguido:
▫ Normalizarlas: aplicar una serie de reglas que tratan de evitar que se
produzca redundancia, evitar problemas de actualización y
proteger la integridad de los datos.
▫ Y utilizarlas como sistema de persistencia: para almacenar información
orientada a objetos o desde nuestro propio lenguaje.

3. ¿Por qué surge No-SQL?
• La aparición de la web 2.0 trae consigo:
▫ La aparición de startups: Empresas que nacen con una idea innovadora y
que tratarán de ir introduciendo elementos para destacar de la posible
competencia que vaya surgiendo.
▫ Las Redes Sociales.
▫ Servicios en la Nube.
• Todos estos nuevos elementos tienen éxito a gran escala (algunos
alcanzarán millones de usuarios en poco tiempo) y esto provocará la
llegada de los problemas de alta escalabilidad.

4. ¿Por qué surge No-SQL?
• Los modelos relacionales se pueden adaptar para hacerlos
escalar incluso en los entornos más difíciles.
• Esta adaptación trae consigo:
▫ Consultas SQL complejas: con triples o cuádruples JOINS que aumentan
su complejidad de implementación, a veces poco eficientes.
▫ Sistemas de almacenamiento de resultados en cachés: para acelerar la
resolución de las peticiones y evitar ejecutar constantemente estas
operaciones.
• Los sistemas No-SQL intentarán atacar estos problemas
proponiendo una estructura más versátil.

5. Ventajas de No-SQL
• Algunas de las ventajas, y a su vez características
comunes de las BBDD No-SQL, son:
▫ Ausencia de esquema en los registros de
datos,
▫ escalabilidad horizontal sencilla,
▫ y alta velocidad (aunque esto último no siempre
es cierto, pues muchos de estos sistemas aún no
están suficientemente madurados).

6. Ausencia de Esquema
• Los datos no tienen una definición de atributos
fija. Cada registro puede contener una información con
diferente forma cada vez, pudiendo almacenar sólo los
atributos que interesen en cada uno de ellos,
facilitando el polimorfismo de datos bajo una
misma colección de información.
• También se puede almacenar estructuras de datos
complejas en un solo documento. Por ejemplo
podemos almacenar la información sobre la publicación
de un blog (título, cuerpo, autor, etc.), junto a los
comentarios y etiquetas vertidas sobre ella.

7. Alta Velocidad
• Muchos de estos sistemas realizan operaciones
directamente en memoria, y sólo vuelcan los datos a
disco cada cierto tiempo. Esto permite que las
operaciones de escritura sean realmente
rápidas.
• Trabajar de este modo puede sacrificar fácilmente la
durabilidad de los datos, y en caso de cuelgue o apagón
se podrían perder operaciones de escritura o
perder la consistencia. Normalmente, esto lo
resuelven permitiendo que una operación de escritura
haya de realizarse en más de un nodo antes de darla por
válida, o disminuyendo el tiempo entre volcado y volcado
de datos a disco. Aunque, aún así, existe ese riesgo.

8. Inconvenientes de No-SQL
• Ahora es el momento de los inconvenientes, y es que
el precio que hay que pagar por tanta rapidez y
redundancia de datos es que necesitamos perder
en consistencia.
• Y sí, es posible que dos usuarios que consulten
la misma información en un determinado
momento obtengan resultados distintos
(alguno de ellos obsoletos), pero esto puede carecer
de importancia si:
▫ Por ejemplo: el caso consiste en que un usuario no
podrá ver el tweet (si nos basamos en Twitter) de un
amigo hasta el próximo acceso.

9. Apache Cassandra
• Cassandra es una base de datos de código abierto cuya principal característica es que fusiona Dynamo,
de Amazon, con BigTable, de Google, siendo ambas implementaciones de código cerrado.
• El desarrollo de Cassandra fue iniciado por Facebook, para intentar solventar la problemática
relacionada con el rendimiento del motor de búsquedas, concretamente con las relacionadas en la
comunicación entre usuarios (“Inbox Search“). Esta funcionalidad implica un gran volumen de datos a
almacenar, con una perspectiva de crecimiento muy alta (el boom de las redes sociales se produjo
después de la implementación de Cassandra) y la necesidad de ofrecer un nivel de calidad de servicio
fijado (SLA, Acuerdo de Nivel de Servicio).
• Para poder comprobar la problemática de Facebook, y la solución:

10. Apache Cassandra
• En 2008 Cassandra fue liberada por Facebook,
pasando a ser de código abierto, y
actualmente es la gente de Apache quien la
mantiene.
• El éxito de este proyecto ha llegado hasta tal
punto que en Abril de 2010, sus dos principales
creadores se ven obligados a ofrecer soporte
comercial.

11. Características
• Primero debemos de especificar que Cassandra se trata de un
sistema NoSQL por lo tanto no podemos catalogarla como una
base de datos orientada a columnas ya que no es relacional.
• Cada familia de columnas puede contener o bien columnas o bien
súper-columnas. Las súper-columnas son la agrupación de n-
columnas.
• Cada columna contiene elementos de la forma “Clave-Valor”.
• Cada fila de una tabla puede tomar valores en columnas
distintas de una familia de columnas que otra fila, es decir,
si se dispone de una familia de 5 columnas (A, B, C, D, E), la fila R1
puede tener valores en A y B mientras que la fila R2 puede tenerlos
en A, C, D y E.

12. Características
• Gracias a lo anterior, cuando usamos Cassandra no
debemos de especificar que campos tendrá, lo que
nos permite ir añadiendo o ir eliminando
según las necesidades.
• Esto también obliga a hacer un cambio con respecto
a los sistemas relacionales ya que cuando usemos
Cassandra deberemos de pensar primero en las
consultas y luego proporcionarle los datos
que cumplan la anterior consulta.

13. Características
• Cassandra puede ejecutarse en múltiples máquinas
sin necesidad de que el usuario necesita
conocer los detalles técnicos o en que
instancia se encuentra la información que
necesita consultar.
• Fue diseñada para ser ejecutada en múltiples nodos,
y sin necesidad de que estos nodos este
geográficamente cercanos. Es decir, podemos
tener un cluster que cuente con nodos
geográficamente repartidos a millones de km sin
que esto altere la eficiencia.

14. Características
• Cassandra es un sistema descentralizado ya que
cada nodo tiene exactamente la misma
información que el resto de nodos, por lo tanto
si uno fallase se podría replicar toda la
información desde cualquier otro nodo.

15. Características
• Cassandra es escalable de forma elástica, es
decir, puede escalarse tanto horizontalmente
como verticalmente.
▫ Escalabilidad horizontal: añadir más nodos a
nuestro sistema, es decir, añadir más maquinas.
▫ Escalabilidad vertical: añadir más capacidad a
nivel de hardware a las máquinas por ejemplo
añadiendo más memoria.

16. Características
• Cassandra tiene consistencia, de forma resumida
y simple, esto significa que una lectura en
Cassandra siempre responderá con el valor más
reciente escrito.
▫ Consistencia débil: todos los datos se replicarán a
todo el sistema pero esto llevará cierto tiempo.

17. Modelado
• Cassandra es un tipo de NoSQL clave-valor, por ello el modelado de datos es distinto al
modelado de datos que conocemos para las Bases de datos relacionales.
• Para representar los datos Cassandra usa los siguientes conceptos Básicos:
▫ Column: Es el elemento más básico de la base de datos, por lo que es una unicidad atómica y
se asemeja al concepto de campo en las bases de datos relacionales. Tiene la misma estructura
que un array asociativo, que contiene tres campos que son:
 Nombre: es un array de bytes.
 Valor: es un array de bytes.
 Timestamp: guarda la última vez que la columna fue accedida
• Ejemplo visual de columna:
Columna(
Nombre->”Nombre del campo”
Valor->”Valor del campo”
Timestamp->”marca de tiempo”
)

18. Modelado
▫ SuperColumn: es un elemento compuesto por varias columnas y sus nombres:
• Ejemplo visual de supercolumna:
Supercolumna
(
“Nombre de la supercolumna” -> xxx
(
“columna1”-> xxx
(
“nombre”-> xxx
“valor”->xxx
“timestamp”->xxx
)
“columna2”-> xxx
(
“nombre”-> xxx
“valor”->xxx
“timestamp”->xxxx
)
)
)

19. Modelado
▫ ColumFamily:
 Es un contenedor de columnas que se asemeja al
concepto de tabla de las bases de datos relacionales.
 El contenido es una lista ordenada de columnas.
 Cada columfamily se guarda en un fichero ordenado
por clave de fila. El contenido de una columfamily
consta de un conjunto de filas con un conjunto de
columnas similar pero no idéntico.

20. Modelado
• Las family colum pueden ser de dos tipos:
• SupercolumnFamily: es un mapa ordenado de nombres de super-
columnas a mapas de nombres de columnas a valores de columnas.
• Simplecolumnfamily: es un mapa de nombres de columna
ordenadas a valores de columna.

21. Modelado
• Keyspace: Un espacio de claves o KeySpace es
un esquema de alto nivel que contiene familias
de columnas, y se asemeja a una base de datos
en lo que respecta al modelo relacional.

22. Modelado
• Una vez definidos todos los conceptos básicos del modelado de datos en Cassandra vamos a compararlo
con el modelo de datos relacional, esto es peligroso hacerlo ya que aún no existe una
comparación certera al cien por ciento.
• Lo primero que vamos a recordar es que elementos de un elemento pueden asimilarse con los
elementos de otro modelo, una columna del modelo de datos de Cassandra se puede asemejar a un campo
en el modelo relacional, las tablas del modelo relacional se asemejan a los columFamily de Cassandra y
por último las bases de datos del modelo relacional son los KeySpace de Cassandra.
• Una distinción de las más importantes es que en Cassandra no existe la Integridad referencial que
existe en el modelo relacional, no hay joins, pero estos se pueden emular almacenando las claves de
una Columfamily en otras filas de otro columFamily o haciendo uso de índices.
• Otra diferencia entre Cassandra y el Modelo de datos relacional es que Casandra no normaliza los
datos a la hora de genera el modelo, ya que trabaja con un mayor rendimiento con datos des-
normalizados, por ello a la hora de modelar la base de datos de Cassandra se debe pensar primero en
las consultas que se van a realizar y una vez se sepan que consultas van a hacerse a las bases de
datos se realiza el modelo de datos para satisfacer a dichas consultas, al contrario que pasa con el modelo
relacional en el que primero se piensa que datos van a ser los que se van a almacenar para luego
modelarlos de manera normalizada.

23. Modelado
• A continuación veremos dos imágenes resumen
en las que se pueden ver cada una de las
diferencias mencionadas.