UNIVERSIDAD NACIONAL JOSÉ MARÍA ARGUEDAS

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

GESTIÓN DE OPERACIONES CRUD CON

CASSANDRA UTILIZANDO PHP COMO
LENGUAJE DE INTERFAZ.

PRESENTADO POR LOS ESTUDIANTES:

Muñoz Pacheco, Rayder Alfredo
Huaman Aspur, José David

DOCENTE: M.Sc. Richar.

TALAVERA – APURÍMAC
PERÚ
Mayo, 2023.
INTRODUCCIÓN

En los últimos años, la cantidad de datos digitales generados en el mundo ha aumentado

significativamente debido al fácil acceso a Internet y el uso de redes sociales. Las bases
de datos relacionales han sido utilizadas por las empresas para cubrir sus necesidades de
almacenamiento y gestión de datos, pero han enfrentado dificultades técnicas al manejar
grandes volúmenes de datos generados. En respuesta a esto, ha surgido una tecnología
llamada NoSQL para abordar los desafíos del Big Data.

En este trabajo de investigación abordaremos Cassandra que es una base de datos

distribuida diseñada para manejar grandes volúmenes de datos en entornos escalables.
Utiliza un modelo de almacenamiento columnar y se destaca por su arquitectura
descentralizada, alta disponibilidad y tolerancia a fallos. Cassandra emplea
particionamiento y replicación para distribuir los datos y garantizar la redundancia en el
clúster.

La consulta en Cassandra se realiza mediante el lenguaje de consulta CQL, similar al

SQL, lo que facilita las operaciones CRUD y las consultas en la base de datos. También
ofrece capacidad de expansión lineal y la capacidad de gestionar múltiples centros de
datos para la distribución geográfica de los datos. Cassandra es ampliamente utilizada por
organizaciones como Facebook, Netflix y eBay debido a su capacidad para manejar
grandes volúmenes de datos con alta disponibilidad y rendimiento.
 TABLA DE CONTENIDOS
INTRODUCCIÓN ........................................................................................................................ 3
CAPÍTULO 1. DATOS DEL PROYECTO ............................................................................... 6
1.1. Título de Proyecto. ............................................................................................................ 6
1.2. Autores del Proyecto: ........................................................................................................ 6
1.3. Duración de Proyecto: ....................................................................................................... 6
1.4. Presupuesto: ...................................................................................................................... 6
CAPÍTULO 2. MARCO TEÓRICO .......................................................................................... 7
2.1. REALIDAD DE LA PROBLEMÁTICA .......................................................................... 7
2.2. OBJETIVOS ..................................................................................................................... 7
2.3. MARCO TEÓRICO .......................................................................................................... 8
2.3.1. Big Data..................................................................................................................... 8
2.3.2. Herramientas de Big Data ......................................................................................... 9
2.3.3. NoSQL ...................................................................................................................... 9
2.3.4. Base de datos NoSQL ............................................................................................... 9
2.3.5. Tipos de bases de datos NoSQL .............................................................................. 10
2.3.6. Teorema CAP .......................................................................................................... 12
2.3.7. Cassandra ................................................................................................................ 14
2.3.8. Historia Cassandra................................................................................................... 14
2.3.9. Características ......................................................................................................... 15
2.3.10. Versiones de Cassandra ........................................................................................... 16
2.3.11. ¿Quién usa Cassandra y para qué? .......................................................................... 17
2.3.12. Arquitectura de Cassandra....................................................................................... 18
2.3.13. Tareas administrativas ............................................................................................. 19
2.3.14. Modelo de Datos ..................................................................................................... 20
2.3.15. Diferencias entre Cassandra y bases de datos relacionales ..................................... 24
2.3.16. Lenguaje CQL ......................................................................................................... 24
2.3.17. Consultas CQL ........................................................................................................ 25
CAPÍTULO 3. DISEÑO DEL PROYECTO ........................................................................... 30
ÍNDICE DE FIGURAS

Ilustración 1: Principales características del Big Data https://datascience.uc.cl/ ............. 8

Ilustración 2: Herramientas del Big Data ......................................................................... 9
Ilustración 3: Tipos de base de datos (documento, gráfico, clave-valor y columna) ..... 10
Ilustración 4: Ejemplo, la clave "Name" está asociada con un valor "Joe Bloggs". ...... 10
Ilustración 5: Base de datos NoSQL basado en columnas. ............................................ 11
Ilustración 6: Base de datos NoSQL basado en documentos ......................................... 11
Ilustración 7: Base de datos NoSql de grafos. ................................................................ 12
Ilustración 8: Teorema CAP. .......................................................................................... 13
Ilustración 9: Cluster en Cassandra ................................................................................ 21
CAPÍTULO 1. DATOS DEL PROYECTO
1.1. Título de Proyecto.
Gestión de operaciones CRUD con Cassandra utilizando PHP como lenguaje de
interfaz.

1.2. Autores del Proyecto:

▪ Huamán Aspur, José David.

▪ Carrion Ccorimanya, Angelo Jesus.
▪ Gómez Alarcón, Samir Jhoner.
▪ Paiva Gutierrez, Yair Andre.

1.3. Duración de Proyecto:

El proyecto durará 16 semanas siendo avanzada de manera paralela al desarrollo del

semestre académico con el aporte de cada integrante del equipo.

1.4. Presupuesto:

En el presente proyecto también tenemos que tener en cuenta los recursos materiales,
recursos de trabajo y recursos de costo necesarios para el cumplimiento de cada tarea.

Recurso tipo cantidad

Huamán Aspur, José David.
Carrion Ccorimanya, Angelo Jesus.
Gómez Alarcón, Samir Jhoner. Trabajo
Paiva Gutierrez, Yair Andre.

Equipo informático por cada integrante Material

Memorias USB Material
Impresiones Costo
Folder Costo
CAPÍTULO 2. MARCO TEÓRICO
2.1. REALIDAD DE LA PROBLEMÁTICA

La gestión de operaciones CRUD con Cassandra y PHP presenta desafíos en el

equipo de trabajo. Algunas dificultades comunes incluyen la falta de conocimiento
técnico en Cassandra y su integración con PHP, lo cual puede retrasar el aprendizaje
y la implementación de funcionalidades. La coordinación del trabajo también puede
ser un desafío, requiriendo una comunicación clara y efectiva para mantener a todos
los miembros informados sobre tareas, plazos y avances.

Las dificultades técnicas pueden surgir en la configuración y conexión de Cassandra

con PHP, lo que puede requerir tiempo adicional para solucionar problemas. Además,
el diseño de una interfaz de usuario amigable y funcional puede ser complejo, ya que
se deben considerar aspectos de usabilidad y experiencia del usuario.

Es fundamental que el equipo trabaje de manera colaborativa, estableciendo metas

claras y dividiendo tareas equitativamente. También se recomienda buscar recursos
adicionales, como tutoriales, documentación y asesoramiento de expertos, para
superar las dificultades de manera eficiente.

2.2. OBJETIVOS

Los objetivos para abordar la realidad problemática de la gestión de operaciones

CRUD con Cassandra y PHP en el trabajo en equipo consideramos los siguientes:

• Adquirir conocimiento técnico: Todos los miembros del grupo adquieran un

conocimiento sólido sobre Cassandra y su integración con PHP.
• Establecer una comunicación efectiva: Es fundamental establecer canales de
comunicación claros y eficientes dentro del grupo para mantener a todos los
miembros informados sobre las tareas asignadas, los plazos y los avances
realizados.
• Superar dificultades técnicas: Abordar y resolver las dificultades técnicas que
puedan surgir durante la configuración y conexión de Cassandra con PHP.
 • Diseñar una interfaz de usuario: Crear una interfaz de usuario amigable y
funcional para la gestión de operaciones CRUD.
• Trabajar de manera colaborativa: Fomentar la colaboración y el trabajo en
equipo dentro del grupo, establecer metas claras, distribuir equitativamente las
tareas y apoyarse mutuamente.

2.3. MARCO TEÓRICO

2.3.1. Big Data

El análisis de datos masivos, también conocido como Big Data, se refiere al proceso de
recolección, almacenamiento y análisis de grandes volúmenes de datos que no pueden ser
gestionados de manera efectiva con herramientas tradicionales. El Big Data se caracteriza
por las siguientes características: volumen, variedad, valor, veracidad y velocidad, lo que
implica que los datos se generan en grandes cantidades, en diferentes formatos y a una
velocidad cada vez más rápida. Para abordar estos desafíos, se utilizan tecnologías como
Hadoop y MapReduce, que permiten el procesamiento distribuido de datos a gran escala.

Ilustración 1: Principales características del Big Data

https://datascience.uc.cl/
2.3.2. Herramientas de Big Data

Puesto que el Big Data no deja de crecer, las herramientas que se usan para gestionarlo
también crecen y evolucionan permanentemente. Las organizaciones utilizan
herramientas como Hadoop, Pig, Hive, Cassandra, Spark o Kafka, dependiendo de los
requisitos específicos que tengan.

Ilustración 2: Herramientas del Big Data

fuente: https://www.mailjet.com

2.3.3. NoSQL

El concepto de bases de datos NoSQL se hizo popular entre los gigantes de Internet como
Google, Facebook, Amazon, etc., que manejan grandes volúmenes de datos. El tiempo de
respuesta del sistema se vuelve lento cuando usa RDBMS para volúmenes masivos de
datos.

El término "NoSQL" (Not Only SQL) se refiere a un enfoque alternativo al modelado y

manejo de datos en bases de datos que difiere del modelo relacional tradicional utilizado
en las bases de datos SQL. Las bases de datos NoSQL están diseñadas para gestionar
grandes volúmenes de datos no estructurados o semi-estructurados de manera eficiente y
escalable.

2.3.4. Base de datos NoSQL

Las bases de datos NoSQL se han desarrollado para abordar las limitaciones de
escalabilidad y rendimiento de las bases de datos SQL en entornos con alta concurrencia
y grandes volúmenes de datos.
2.3.5. Tipos de bases de datos NoSQL

Las bases de datos NoSQL se han desarrollado para abordar las limitaciones de
escalabilidad y rendimiento de las bases de datos SQL en entornos con alta concurrencia
y grandes volúmenes de datos. Las bases de datos NoSQL se clasifican principalmente
en cuatro tipos:

Ilustración 3: Tipos de base de datos (documento, gráfico, clave-valor y columna)

fuente: https://logicmojo.com/nosql-database

2.3.5.1. Bases de datos clave-valor.

Almacenan datos en pares clave-valor simples, donde cada valor está asociado con una
clave única. Estas bases de datos son rápidas y eficientes para recuperar datos por clave.
Está diseñado de tal manera que pueda manejar muchos datos y cargas pesadas.

Las bases de datos de almacenamiento de pares clave-valor almacenan datos como una
tabla hash donde cada clave es única y el valor puede ser un JSON, BLOB (objetos
binarios grandes), una cadena, etc.

Ejemplos de bases de datos clave-valor incluyen Redis y Amazon DynamoDB.

Ilustración 4: Ejemplo, la clave "Name" está asociada con un valor "Joe Bloggs".
2.3.5.2. Bases de datos de columnas

Almacenan datos en columnas en lugar de filas, lo que permite una recuperación eficiente
de datos seleccionados y un mejor rendimiento en análisis de datos. Cada columna se trata
por separado. Los valores de las bases de datos de una sola columna se almacenan de
forma contigua.

Las bases de datos NoSQL basadas en columnas se utilizan ampliamente para administrar
almacenes de datos, inteligencia comercial, CRM, catálogos de tarjetas de biblioteca.

Ejemplos de bases de datos de columnas incluyen Apache Cassandra y Google Bigtable.

Ilustración 5: Base de datos NoSQL basado en columnas.

2.3.5.3. Bases de datos de documentos

La base de datos NoSQL orientada a documentos almacena y recupera datos como un par
de valores clave, pero la parte del valor se almacena como un documento. El documento
se almacena en formato JSON o XML. El DB entiende el valor y se puede consultar.

Amazon SimpleDB, CouchDB, MongoDB, Riak, Lotus Notes, MongoDB, son populares
sistemas DBMS originados en documentos.

Ilustración 6: Base de datos NoSQL basado en documentos

2.3.5.4. Bases de datos de grafos

Utilizan estructuras de grafos para representar y relacionar los datos. Estas bases de datos
son útiles para modelar relaciones complejas entre entidades.

Una base de datos de tipo gráfico almacena entidades, así como las relaciones entre esas
entidades. La entidad se almacena como un nodo con la relación como bordes. Un borde
da una relación entre los nodos. Cada nodo y borde tiene un identificador único.

Neo4J, Infinite Graph, OrientDB, FlockDB son algunas bases de datos populares basadas
en gráficos.

Ilustración 7: Base de datos NoSql de grafos.

2.3.6. Teorema CAP

El teorema CAP ha sido ampliamente adoptado por las grandes compañías de internet, al
igual que por la comunidad NoSQL. Las siglas CAP hacen referencia a:

a) Consistencia (Consistency): Todos los nodos en el sistema ven los mismos datos al
mismo tiempo. En otras palabras, cuando se realiza una escritura en un nodo, todas
las lecturas subsiguientes en cualquier nodo obtienen los datos más actualizados.
b) Disponibilidad (Availability): El sistema sigue funcionando y responde a las
solicitudes incluso cuando algunos nodos fallan o están inaccesibles.
c) Tolerancia a partición (Partition tolerance): El sistema continúa funcionando
correctamente incluso cuando se producen fallas en la red que provocan la partición
del sistema en múltiples segmentos que no pueden comunicarse entre sí.
 C

A P

Ilustración 8: Teorema CAP.

Podemos deducir que se puede “elegir” dos de estas 3 características par nuestro sistema
de datos compartidos. De esta manera se tiene:

o Sistemas coherentes y disponibles, pero con dificultades para funcionar en caso de

que haya muchas particiones.
o Sistemas coherentes y tolerantes a particiones, pero con ciertas carencias en temas de
disponibilidad.
o Sistemas disponibles y tolerantes a particiones, pero no estrictamente coherente.

Elección Característica Ejemplo

CA. Consistencia y Confirmaciones dobles. Relacionales
Disponibilidad (se pierde la Protocolos de validación (Oracle, Mysql, SQL
capacidad Particiones de caché. Server), Neo4J
CP. Consistencia y Particiones Bloqueos “pesimistas”.
MongoDB, HBase,
(se pierde la capacidad Ignorar las particiones más
Redis
Disponibilidad) Pequeñas.
AP. Disponibilidad y
Invalidaciones de caché DynamoDB,
Particiones (se pierde la
Resolución de conflictos CouchDB, Cassandra
capacidad consistencia)
2.3.7. Cassandra

Apache Cassandra se trata de un software NoSQL distribuido y basado en un modelo de

almacenamiento de código abierto que está escrito en Java. Permite grandes volúmenes
de datos en forma distribuida. A diferencia de las bases de datos relacionales
tradicionales, Cassandra no utiliza el modelo de esquema fijo, lo que significa que no es
necesario definir una estructura de tabla antes de almacenar los datos. Esto proporciona
flexibilidad y permite cambios en el esquema de datos sin interrupciones.

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.

Cassandra no soporta la sentencia JOIN o subqueries, sino que enfatiza en la

desnormalización a través de características como colecciones.

2.3.8. Historia Cassandra

La historia de Apache Cassandra se remonta al año 2008, cuando fue desarrollada

inicialmente por Facebook para satisfacer sus necesidades de almacenamiento y
procesamiento de grandes volúmenes de datos. Avinash Lakshman y Prashant Malik,
ingenieros de Facebook, crearon Cassandra para abordar las limitaciones de las bases de
datos tradicionales en términos de escalabilidad y disponibilidad.

La inspiración para Cassandra provino de la investigación realizada en Amazon Dynamo

y Google Bigtable, dos sistemas diseñados para manejar grandes cantidades de datos
distribuidos. Cassandra se basó en estos conceptos, pero con algunas mejoras y
características adicionales.

En 2008, Facebook abrió el código de Cassandra y lo donó a la Apache Software

Foundation, donde se convirtió en un proyecto de código abierto bajo el nombre de
"Apache Cassandra".

En 2010, Cassandra se convirtió en un proyecto de nivel superior de la Apache Software

Foundation. Desde entonces, ha lanzado varias versiones con mejoras y nuevas
características, como la capacidad de consulta mediante el lenguaje de consulta CQL
(Cassandra Query Language) y la integración con lenguajes de programación populares.

Cassandra ha sido adoptada por numerosas organizaciones de renombre, incluidas

empresas tecnológicas, como Netflix, Apple, Spotify, Twitter y Uber, que confían en
Cassandra para manejar sus enormes volúmenes de datos y proporcionar un
almacenamiento altamente escalable y tolerante a fallos.

2.3.9. Características

Apache Cassandra se caracteriza por una serie de características distintivas que lo hacen
adecuado para el manejo de grandes volúmenes de datos y entornos distribuidos. Algunas
de las principales características de Apache Cassandra son:

Escalabilidad horizontal: Cassandra está diseñado para escalar horizontalmente de

manera lineal. Puede agregar fácilmente nuevos nodos al clúster para aumentar la
capacidad de almacenamiento y el rendimiento sin tiempo de inactividad.

a) Alta disponibilidad: Cassandra proporciona alta disponibilidad de datos al replicar

los datos en múltiples nodos. Esto garantiza que los datos estén disponibles incluso
en caso de fallos en los nodos individuales.
b) Tolerancia a fallos: Debido a su enfoque distribuido, Cassandra es altamente
tolerante a fallos. Si un nodo falla, los datos pueden ser recuperados de otros nodos
en el clúster.
c) Modelo de datos flexible: A diferencia de las bases de datos relacionales
tradicionales, Cassandra no utiliza un esquema fijo. Puede agregar, eliminar o
modificar columnas sin necesidad de un esquema predefinido, lo que proporciona
flexibilidad en el manejo de datos.
d) Replicación y particionamiento automático: Cassandra distribuye
automáticamente los datos a través de múltiples nodos utilizando un algoritmo de
particionamiento.
e) Rendimiento rápido de escritura y lectura: Cassandra está optimizado para ofrecer
un alto rendimiento en operaciones de escritura y lectura. Utiliza un modelo de
escritura apoyado en registros de confirmación y un algoritmo de lectura eficiente
basado en índices.
 f) Soporte para consultas flexibles: Cassandra ofrece un lenguaje de consulta
llamado CQL (Cassandra Query Language) que permite realizar consultas y filtrar
datos de manera similar a SQL. CQL también admite operaciones de agregación y
funciones de consulta avanzadas.
g) Integración con lenguajes de programación: Cassandra proporciona
controladores y bibliotecas para varios lenguajes de programación populares, lo que
facilita su integración con aplicaciones y sistemas existentes.

2.3.10. Versiones de Cassandra

A lo largo de su desarrollo, Apache Cassandra ha lanzado varias versiones con mejoras,

correcciones de errores y nuevas características.

 Apache Cassandra 0.6: Lanzada en julio de 2010, esta fue una de las primeras
versiones estables de Cassandra que se lanzó como un proyecto de nivel superior
de la Apache Software Foundation.
 Apache Cassandra 0.7: Lanzada en enero de 2011, esta versión introdujo
importantes mejoras en el rendimiento y la escalabilidad, incluida la capacidad de
compresión de datos y mejoras en el modelo de replicación.
 Apache Cassandra 1.0: Lanzada en octubre de 2011, esta versión marcó un hito
importante al presentar CQL (Cassandra Query Language), que proporcionó una
interfaz similar a SQL para realizar consultas en Cassandra.
 Apache Cassandra 2.0: Lanzada en septiembre de 2013, esta versión trajo
importantes mejoras en la escalabilidad y el rendimiento, incluyendo el soporte
para índices secundarios, mejoras en la compresión de datos y un nuevo sistema
de almacenamiento de archivos SSTable.
 Apache Cassandra 3.0: Lanzada en noviembre de 2015, esta versión se centró
en mejorar la estabilidad y la confiabilidad, así como en la introducción de nuevas
características como la compresión de datos en tiempo real, mejoras en el
rendimiento de escritura y la capacidad de configurar la duración de la retención
de datos.
 Apache Cassandra 4.0: Lanzada en diciembre de 2020, esta es la versión más
reciente y cuenta con importantes mejoras en el rendimiento, la escalabilidad y la
administración de clústeres, incluyendo mejoras en la compresión de datos,
 soporte para operaciones atómicas y una nueva implementación de la memoria
caché de lectura.

2.3.11. ¿Quién usa Cassandra y para qué?

Cassandra es utilizado por numerosas organizaciones y empresas de renombre en

diferentes industrias.

 Netflix: Netflix utiliza Cassandra para almacenar y administrar datos relacionados

con sus servicios de transmisión en tiempo real, como información de usuarios,
preferencias, historiales de reproducción, etc. Cassandra permite a Netflix escalar
y manejar grandes volúmenes de datos generados por millones de usuarios en todo
el mundo.
 Apple: Apple utiliza Cassandra en varios servicios, como iCloud y Apple Music,
para almacenar y gestionar datos de usuarios, preferencias, listas de reproducción,
datos de dispositivos, entre otros. Cassandra proporciona la escalabilidad
necesaria para manejar el creciente número de usuarios y la alta disponibilidad
para garantizar que los datos estén siempre accesibles.
 Spotify: Spotify, el popular servicio de transmisión de música, utiliza Cassandra
para almacenar datos de reproducción, listas de reproducción personalizadas,
información del catálogo musical y datos de seguimiento de usuarios. Cassandra
permite a Spotify gestionar grandes volúmenes de datos y ofrecer una experiencia
fluida a sus millones de usuarios.
 Twitter: Twitter utiliza Cassandra para almacenar y administrar datos
relacionados con tweets, perfiles de usuarios, interacciones sociales y datos
analíticos. Cassandra permite a Twitter escalar horizontalmente y manejar la gran
cantidad de datos generados en tiempo real por los usuarios de la plataforma.
 Uber: Uber utiliza Cassandra para almacenar y gestionar datos relacionados con
viajes, usuarios, conductores, pagos y geolocalización. Cassandra proporciona la
capacidad de almacenar y acceder a grandes volúmenes de datos en tiempo real,
lo que permite a Uber operar su plataforma de servicios de transporte a nivel
mundial.
2.3.12. Arquitectura de Cassandra
Cassandra utiliza una arquitectura de espacio de claves peer-to-peer para el
almacenamiento y la gestión de datos. A diferencia de las bases de datos tradicionales que
utilizan una arquitectura cliente-servidor, Cassandra se basa en un enfoque
descentralizado y distribuido. Aquí se presenta una descripción de la arquitectura de
espacio de claves peer-to-peer de Cassandra:

2.3.12.1. Nodos

En Cassandra, cada nodo es igual y tiene las mismas responsabilidades. No hay

nodos maestros o servidores centrales. Los nodos pueden comunicarse
directamente entre sí sin depender de un nodo central.

2.3.12.2. Espacio de claves

El espacio de claves es el conjunto total de todas las particiones de datos en el

clúster. Cada partición se asigna a un nodo específico en función de una función
de hash del valor de clave primaria. El espacio de claves se divide en varias
particiones distribuidas en diferentes nodos.

2.3.12.3. Particionamiento

El particionamiento es el proceso de dividir los datos en particiones y distribuirlos

en los nodos. Cassandra utiliza una función de hash para determinar a qué nodo
se asigna cada partición. Esto permite una distribución equilibrada de los datos en
el clúster y facilita la escalabilidad horizontal.

2.3.12.4. Réplicas

Las particiones se replican en varios nodos para garantizar la alta disponibilidad

y la tolerancia a fallos. Cada partición tiene una serie de réplicas distribuidas en
diferentes nodos. Las réplicas se pueden configurar con diferentes factores de
replicación para determinar la cantidad de copias y su ubicación en el clúster.

2.3.12.5. Coordinación

Cuando se realiza una operación en una partición, el nodo responsable de esa

partición actúa como coordinador. El coordinador se encarga de coordinar la
 operación y comunicarse con los nodos réplica correspondientes para completar
la operación.

2.3.12.6. Anillo de nodos

Los nodos de Cassandra se organizan en un anillo virtual utilizando tokens

asignados a cada nodo. Cada nodo tiene un rango de tokens que representa un
segmento del espacio de claves. Los nodos se comunican entre sí en el anillo para
enrutar las solicitudes de lectura y escritura.

2.3.13. Tareas administrativas

Las tareas de administración en un sistema de gestión de bases de datos como Apache

Cassandra incluyen varias actividades importantes para garantizar la seguridad,
integridad y disponibilidad de los datos.

2.3.13.1. Seguridad

Implementar medidas de seguridad para proteger los datos almacenados en

Cassandra. Esto implica establecer políticas de autenticación y autorización para
controlar el acceso a los datos, así como implementar cifrado para proteger la
confidencialidad de la información. Opciones de encriptación tanto entre clientes
y clústeres como entre nodos.

2.3.13.2. Copias de respaldo

Realizar copias de respaldo periódicas de los datos almacenados en Cassandra.

Esto garantiza que haya una copia de los datos en caso de fallas o pérdidas
inesperadas. Las copias de respaldo también son útiles para la recuperación ante
desastres y la restauración de datos en caso de corrupción o eliminación
accidental.

2.3.13.3. Asegurar la consistencia de los datos

Cassandra ofrece opciones de consistencia flexible, lo que permite a los

administradores configurar el nivel de consistencia deseado para las operaciones
de lectura y escritura. Es importante establecer políticas de consistencia adecuadas
para garantizar que los datos sean coherentes y reflejen los cambios realizados.
2.3.14. Modelo de Datos

Cassandra es una base de datos NoSQL orientada a columnas. Su modelo de datos se basa
en una serie de column families que a su vez se contienen columnas, que pueden darse
ninguna, una o varias veces para un mismo elemento.

2.3.14.1. Clúster

Cassandra es una base de datos que está diseñada e ideada para funcionar
formando clústers de máquinas. Es decir, si se quiere aprovechar al máximo todo
el rendimiento y la funcionalidad que nos ofrece esta base de datos, no se deberá
correr en un único nodo, sino de forma distribuida en varios nodos. Y cuanto más
distribuido mejor: si es en varios racks mejor, y si además se ubican en varios
CPDs, Casandra dará un mejor rendimiento a la aplicación.
El protocolo peer-to-peer hace que los nodos se comuniquen entre ellos para
conocer su estado y repliquen los datos de forma transparente a usuario.

Ilustración 9: Cluster en Cassandra

2.3.14.2. Keyspaces

Un keyspace es un contenedor lógico que agrupa un conjunto de column families

y define los parámetros de configuración para ese conjunto de datos en particular.
Es similar al concepto de una base de datos en sistemas de bases de datos
relacionales.

Un keyspace en Cassandra se utiliza para organizar y gestionar datos relacionados

de manera lógica. Contiene información sobre la replicación, las estrategias de
almacenamiento y las opciones de configuración para las column families dentro
del keyspace.

Los atributos más importantes que se pueden configurar son:

• Factor de replicación: El factor de replicación hace referencia al número de

copias que debe guardarse de cada dato de la base de datos. El factor de
replicación indicará cuantos nodos tendrán copia de los objetos de los que ese
nodo sea responsable.
• Estrategia de localización de replicas: Este parámetro establece qué política
se seguirá para alojar las réplicas en el anillo, y para decidir qué nodos serán
los que alojen qué copias, estas políticas de localización de replicas tienen en
cuenta aspectos como la tomar en consideración el rack donde están alojados
los servidores, los centros de datos, la topología de la red, etc.
• Consistencia: Define el nivel de consistencia requerido para las operaciones
de lectura y escritura en el keyspace. Se pueden configurar diferentes niveles
de consistencia, como la consistencia fuerte (strong consistency) o la
consistencia eventual (eventual consistency), dependiendo de los requisitos
de la aplicación.
• Estrategia de eliminación: Define cómo se eliminan los datos obsoletos en
el keyspace. Se pueden configurar estrategias como la eliminación basada en
tiempo (time-based) o la eliminación basada en tamaño (size-based), según
las necesidades del sistema.

2.3.14.3. Column Families

En Apache Cassandra, una column family (familia de columnas) es una estructura

de almacenamiento que organiza los datos de manera similar a una tabla en una
base de datos relacional. Representa un conjunto de filas que contienen columnas
y sus valores asociados.

Cada column family tiene un nombre único y se define dentro de un keyspace, las
column families están compuestas por filas y columnas. Cada fila tiene una clave
de fila única y contiene una o más columnas. A su vez, cada columna tiene un
nombre único y un valor asociado. Las columnas pueden ser agrupadas en
supercolumnas, lo que proporciona una capa adicional de organización y
estructura. Además, las column families en Cassandra admiten operaciones
CRUD (create, read, update, delete) para manipular los datos almacenados.

2.3.14.4. Columns

Las columnas son las unidades mínimas que alojan información en Cassandra. La
información que contiene el valor de cada columna está conformado por un array
de bytes.

Además, en Cassandra no es necesario definir todas las columnas en el momento

de diseñar la base de datos, pero sí las column families. Una vez éstas estén
creadas, el resto de tablas se pueden crear en tiempo de ejecución, incluso aunque
previamente no existieran.
2.3.14.5. SuperColumns

Las supercolumnas son un tipo especial de columna. Ambos tipos de columnas

son pares nombre-valor, pero mientras que una columna normal almacena el valor
para esa columna, una super columna contiene un mapa de columnas, que estas
ya sí, almacenan el valor en forma de array de bytes para esa columna.

Con las superscolumnas, Cassandra pasa de ser un hash de 4 dimensiones a serlo

de 5, con la siguiente ordenación en sus dimensiones.

[Keyspace][ColumnFamily][Key][SuperColumn][Subcolumn]

Para definir una supercolumna, simplemente hay que generar una column family
como si fuera de tipo super. De esta manera, este tipo de column families se
pueden utilizar como si fueran un tipo de column family normal, únicamente
habría que indicar explícitamente el nombre de la super columna.

2.3.14.6. Filas o entradas (Rows):

En Apache Cassandra, una fila (row) se refiere a un conjunto de columnas

relacionadas que se agrupan bajo una clave de fila única. Las filas se almacenan
distribuidamente en varios nodos y se identifican mediante una clave de fila.
Puedes acceder a las filas y sus columnas utilizando la clave de fila y recuperar
tanto la fila completa como columnas individuales. La flexibilidad en la estructura
de los datos permite que las filas tengan diferentes conjuntos de columnas. Esta
capacidad de almacenamiento y recuperación eficiente de filas es fundamental en
el modelo de datos escalable y distribuido de Cassandra.
2.3.15. Diferencias entre Cassandra y bases de datos relacionales

Antes de saltar al modelado de datos con Cassandra, es útil explicar algunas diferencias
entre Cassandra y las bases de datos relacionales. Las bases de datos relacionales de alto
nivel priorizan el espacio sobre el tiempo de respuesta. Cassandra prioriza el tiempo de
respuesta sobre el espacio.

 Modelo de datos: Cassandra utiliza un modelo de datos basado en columnas,

mientras que las bases de datos relacionales utilizan un modelo basado en filas y
tablas.
 Escalabilidad horizontal: Cassandra es altamente escalable horizontalmente,
distribuyendo datos en varios nodos para manejar grandes volúmenes de datos.
Las bases de datos relacionales son más adecuadas para escalabilidad vertical,
agregando potencia a un solo servidor.
 Alta disponibilidad: Cassandra es altamente disponible y tolerante a fallos,
replicando datos en múltiples nodos. Las bases de datos relacionales también
pueden ser altamente disponibles, pero con configuraciones adicionales.
 Consistencia: Cassandra ofrece modelos de consistencia flexible, permitiendo
datos inmediatos en algunos nodos y propagándose a otros nodos. Las bases de
datos relacionales ofrecen consistencia estricta.
 Lenguaje de consulta: Cassandra utiliza CQL(Cassandra Query Language),
similar a SQL pero con algunas diferencias. Las bases de datos relacionales
utilizan SQL.
 Transacciones ACID: Las bases de datos relacionales cumplen con las
propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) en
transacciones, mientras que Cassandra ofrece un modelo de transacciones en lotes
más flexible y escalable.

2.3.16. Lenguaje CQL

Cassandra Query Language (CQL) es el lenguaje que utiliza para realizar el acceso a la
base de datos. En Cassandra los datos están desnormalizado por lo cual como hemos
comentado antes los JOIN no puede ser posible realizar como ocurre en las bases de datos
relacionales. Para poder interactuar con Cassandra mediante CQL tendremos que
introducir a través de la shell de la propia base de datos el comando cqlshell, aunque
también podemos utilizar herramientas gráficas o a través de los drivers soportados por
múltiples lenguajes de programación.

2.3.17. Consultas CQL

2.3.17.1. Crear, alterar y eliminar un Keyspace

Un keyspace es el contenedor más exterior y debería ser creado antes que cualquier cosa,
así que para poder realizar la creación de un keyspace tendremos que introducir el
siguiente comando:

CREATE KEYSPACE IF NOT EXISTS "nombre keyspace" WITH replication =

{'class': 'SimpleStrategy', 'replication_factor': '1'} AND
durable_writes = true;

El comando anterior está indicando que se realice la creación de un keyspace con el

nombre deseado en el caso que no exista (si existe, no lo creará), además de ello realizará
la replicación en un solo nodo, además de que estamos indicando la estrategia de cómo
gestionará la réplica de los datos (este apartado se explica a continuación) y utilizará la
política durable_writes.

Hay un dato a tener en cuenta y es que tenemos que definir como deseamos realizar la
réplica de los datos, dependiendo de la opción que pongamos, nos realizará un tipo de
réplica u otro, existen dos opciones de replicado que se explican a continuación.

• SimpleStrategy: se define cuando deseamos que los datos se almacenen en un

solo data center.
• NetworkTopologyStrategy: se define si se planea desplegar el cluster en
múltiples data centers.

En el caso que deseemos realizar desde fuera de la base de datos (fuera de la shell de
CQL) tendremos que realizarlo con el siguiente comando:

cqlsh -u "usuario" -p "password" localhost -e "CREATE KEYSPACE IF NOT

EXISTS "nombre keyspace" WITH replication = { 'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;"

• Modificar: Si en algún momento deseamos realizar la modificación de ese keyspace

tendremos que introducir el siguiente comando que nos permite alterar las
características del keyspace:
ALTER KEYSPACE "nombre keyspace" WITH REPLICATION = { 'class' :
'SimpleStrategy', 'replication_factor' : 3 };

Con esta modificación estamos indicando que deseamos ajustar el número de réplicas
disponibles de este keyspace, cambiando el valor de 1 a 3.

• Seleccionar. En el momento que deseemos usar este keyspace lo único que tendremos
que realizar es la introducción del siguiente comando

USE "nombre de keyspace";

• Eliminar. Si deseamos realizar el borrado de un Keyspace tendremos que

introducir el siguiente comando.

DROP KEYSPACE "nombre de keyspace";

2.3.17.2. Crear, alterar y eliminar una Tabla

El concepto más equivalente en Cassandra de una Tabla en una base de datos relacional
es una Familia de Columnas, que dichas familias de columnas almacenan una Super
Columna o Columna, las cuales almacena las filas con los datos que son introducidos en
la base de datos.

• Crear, Para poder realizar la creación de una “tabla”, tendremos que introducir el
siguiente comando en el cual estamos indicando los tipos de campos de las columnas,
además de indicar su correspondiente primary key.

CREATE TABLE nombre_tabla ( CREATE TABLE personas (

columna1 tipo_dato1, id text,
columna2 tipo_dato2, name text,
... surname text,
PRIMARY KEY (columna1) date time,
); PRIMARY KEY (id, name));

Es recomendable indicar una fecha de registro e indicar dos primary keys, para que la
primera sirva para definir la partitionkey y la segunda sea para definir el clustering key y
van en ese orden.
Aunque también podremos definir la primary key y la clustering key de forma compuesta
(que cada una está compuesta por más de uno).

• Tipos de Datos en las Tablas

En el momento de la creación de la tabla podremos definir el tipo de dato que vamos
a almacenar, por ello tendremos una amplia diversidad de opciones a elegir
dependiendo del dato a introducir en esa columna, dichos tipos de datos se clasifican
en los siguientes

Numéricos:
▪ Int: enteros de hasta 32 bits.
▪ Bigint: enteros de hasta 64 bits.
▪ Smallint: enteros de hasta 2 bytes.
▪ Tinyint: enteros de hasta 1 byte.
▪ Varint: enteros de precisión arbitraria.
▪ Decimal: decimales de precisión variable.
▪ Float: coma-flotante de 32 bits.
▪ Double: coma-flotante de 64 bits.
▪ Counter: contador de enteros de hasta 64 bits.
Texto:
▪ Ascii: strings US-ASCII.
▪ Text: strings UTF-8.
▪ Varchar: strings UTF-8 de longitud variable.
▪ Inet: strings que almacenan direcciones IPv4 o IPv6.
Identificación:
▪ UUID: tipo de dato que sigue el estándar UUID. Es único para cada fila insertada
en una tabla. Se utiliza para identificar a las filas
▪ Timeuuid: es un UUID que además sirve como timestamp único para cada fila.
Fecha
▪ Date: fechas desde el 1 de Enero de 1970 en formato yyyy-mm-dd, representada
como string.
▪ Time: hora, minutos y segundos en formato hh:mm:ss.sss, representado como
string.
▪ Timestamp: fecha y hora con precisión al milisegundo en formato yyyy-mm-dd
hh:mm:ss.sss. Puede ser representada como string.
Colección:
▪ List: colección de uno o más elementos ordenados.
▪ Map: colección con pares clave-valor.
▪ Set: colección de uno o más elementos.
Otros tipos:
▪ Blob: almacena bytes expresados en hexadecimal.
En el momento que deseemos revisar la estructura de la tabla creada, tendremos que
realizar la introducción del comando describe.

DESCRIBE "nombre tabla";

• Alterar, para alterar la tabla creada anteriormente tendremos que realizar la

introducción del siguiente comando (en el ejemplo que aparece a continuación
añadimos la columna email de tipo texto).

ALTER TABLE personas ADD email text;

A continuación, muestran cómo se realizaría la modificación del tipo de columna y la

eliminación de la misma en ese orden.

ALTER TABLE personas ALTER email TYPE varchar;

ALTER TABLE personas DROP email;

• Eliminar, para realizar la eliminación de una TABLE tendremos que realizar la

introducción del siguiente comando.

DROP TABLE "nombre tabla";

2.3.17.3. Insertar y Actualizar Datos

• Insertar, para insertar datos en una tabla concreta, tendremos que realizarlo de forma
similar como lo hacemos en los sistemas de bases de datos relacionales, tal y como
aparece a continuación.

INSERT INTO personas (id, name, surname, email) VALUES ('001',

'juan jose','lopez', '[email protected]')

• Eliminación de datos, En el caso de la eliminación de registros en una tabla concreta

se puede realizar con la cláusula DELETE, utilizándose así de la misma forma que en
los sistemas de bases de datos relacionales, pero en el caso de Cassandra puede
eliminar la fila o el contenido de una columna concreta, a continuación se ven unos
ejemplos que nos permitirá entender mejor como va todo el tema de la eliminación de
datos.

Esta opción elimina el contenido de la columna “nombre” de la fila con el “id=001”

DELETE nombre FROM personas WHERE id='001';

Esta segunda opción nos permite eliminar la fila con el “id=001”

DELETE FROM personas WHERE id='001';

CAPÍTULO 3. DISEÑO DEL PROYECTO