Trabajo Práctico

Bases de datos para la

Administración

Profesor: Nicolás Bocalandro

Alumnos: Escalada Luciana
Germone Pablo

2017
Contenido
Introducción ........................................................................................................................................ 3
NoSQL .................................................................................................................................................. 3
¿Por qué aparecen los sistemas NoSQL? ............................................................................................ 3
NoSQL frente a bases de datos relacionales ................................................................................... 4
Pero, ¿en qué se diferencian exactamente? ....................................................................................... 4
Consultas Map-Reduce: ...................................................................................................................... 6
Funcion map ........................................................................................................................................ 7
Funcion Reduce ................................................................................................................................... 7
Arquitectura del Map-reduce.............................................................................................................. 8
Combinador (Agregadores locales) ................................................................................................... 10
Tolerancia a Fallos ............................................................................................................................. 10
NoSQL vs SQL: Cuándo utilizar qué tipo de base de datos ............................................................... 11
Que es Cassandra? ............................................................................................................................ 12
Cassandra, la dama de las bases de datos NoSQL..................................................................... 12
Historia y orígenes............................................................................................................................. 13
Particularidades principales .............................................................................................................. 13
Arquitectura ...................................................................................................................................... 14
Replicacion de datos en Cassandra ................................................................................................... 15
Componentes de Cassandra.............................................................................................................. 15
Las operaciones de escritura ............................................................................................................. 16
las operaciones de lectura ................................................................................................................ 16
keyspace ............................................................................................................................................ 16
Familia de columna ........................................................................................................................... 17
Columna ............................................................................................................................................ 18
SuperColumn ..................................................................................................................................... 18
Ejemplo.............................................................................................................................................. 19
Conclusión ......................................................................................................................................... 20
Introducción
Dentro de los nuevos sistemas de almacenamiento que están surgiendo
dentro del universo Big Data, Cassandra es uno de los más interesantes y
reseñables. Cassandra se define como una base de datos NoSQL distribuida y
masivamente escalable, y esta es su mayor virtud desde nuestro punto de
vista, la capacidad de escalar linealmente.
Además, Cassandra introduce conceptos muy interesantes como el soporte
para multi data center o la comunicación peer-to-peer entre sus nodos. En
este artículo vamos a profundizar en estas y otras características que hacen a
Cassandra tan especial.

NoSQL

NoSQL es un término que describe las bases de datos no relacionales de alto

desempeño. Las bases de datos NoSQL utilizan varios modelos de datos,
incluidos los de documentos, gráficos, claves-valores y columnas. Las bases
de datos NoSQL son famosas por la facilidad de desarrollo, el desempeño
escalable, la alta disponibilidad y la resiliencia.

¿Por qué aparecen los sistemas NoSQL?

Las bases de datos relacionales no tienen nada de malo: Precisamente gracias
al transcurso de los años, hemos logrado aprender técnicas bastante
comunes para normalizarlas en la medida de lo posible, escalarlas según
crece la demanda, y utilizarlas como sistema de persistencia para almacenar
información desde nuestro lenguaje procedural u orientado a objetos
favorito (entre otros). La cuota de uso de software como SQLite, MySQL,
PostgreSQL u Oracle, por poner cuatro ejemplos conocidos, es muy alta,
encontrándose en la mayor parte de los desarrollos modernos.

Pero llegó la web, el software como servicio, los servicios en la nube y las
startups de éxito con millones de usuarios. Y con todo ello llegaron los
problemas de alta escalabilidad. Si bien los modelos relacionales se pueden
adaptar para hacerlos escalar incluso en los entornos más difíciles, sí que es
cierto que, a menudo, se hacen cada vez menos intuitivos a medida que
aumenta la complejidad. Triples y cuádruples JOINs en consultas SQL que
asustan al más pintado nada más verlas, a veces poco eficientes, y sistemas
de almacenamiento de resultados en cachés para acelerar la resolución de las
peticiones y evitar ejecutar cada vez estas pesadas operaciones, son el pan
de cada día en muchos de estos proyectos de software.

Los sistemas NoSQL intentan atacar este problema proponiendo una

estructura de almacenamiento más versátil, aunque sea a costa de perder
ciertas funcionalidades como las transacciones que engloban operaciones en
más de una colección de datos, o la incapacidad de ejecutar el producto
cartesiano de dos tablas (también llamado JOIN) teniendo que recurrir a la
desnormalización de datos.

Algunas implementaciones bien conocidas que podríamos como NoSQL son:

CouchDB, MongoDB, RavenDB, Neo4j, Cassandra, BigTable, Dynamo, Riak,
Hadoop, y otras muchas.

NoSQL frente a bases de datos relacionales

En la siguiente tabla se enumeran los puntos que diferencian a una base de

datos relacional de una base de datos NoSQL.

Pero, ¿en qué se diferencian exactamente?

Si tuvieramos que resumir las características comunes en estos sistemas, yo
diría que son principalmente tres: Ausencia de esquema en los registros de
datos, escalabilidad horizontal sencilla, y velocidad endiablada (aunque esto
último no siempre es cierto, pues muchos de estos sistemas aún no están
suficientemente maduros).

La primera característica significa que los datos no tienen una definición de

atributos fija, es decir: Cada registro (o documento, como se les suele llamar
en estos casos) puede contener una información con diferente forma cada
vez, pudiendo así 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 pueden almacenar estructuras de datos complejas
en un sólo documento, como por ejemplo almacenar la información sobre
una publicación de un blog (título, cuerpo de texto, autor, etc) junto a los
comentarios y etiquetas vertidos sobre el mismo, todo en un único registro.
Hacerlo así aumenta la claridad (al tener todos los datos relacionados en un
mismo bloque de información) y el rendimiento (no hay que hacer
un JOIN para obtener los datos relacionados, pues éstos se encuentran
directamente en el mismo documento).

Con escalabilidad horizontal me refiero a la posibilidad de aumentar el

rendimiento del sistema simplemente añadiendo más nodos, sin necesidad
en muchos casos de realizar ninguna otra operación más que indicar al
sistema cuáles son los nodos disponibles. Muchos sistemas NoSQL permiten
utilizar consultas del tipo Map-Reduce, las cuales pueden ejecutarse en todos
los nodos a la vez (cada uno operando sobre una porción de los datos) y
reunir luego los resultados antes de devolverlos al cliente. La gran mayoría
permiten también indicar otras cosas como el número de réplicas en que se
hará una operación de escritura, para garantizar la disponibilidad. Y gracias
al sharding y a no tener que replicar todos los datos en cada uno de los
nodos, la información que se mueve entre las distintas instancias del motor
de base de datos no tiene por qué ser demasiado intensiva. Por supuesto,
seguiremos encontrándonos con problemas de escalabilidad inherentes al
tipo de software que estemos construyendo, pero seguramente podamos
resolverlos más fácilmente con la ayuda de estas características.

Por último, 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. Por supuesto,
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. Pero claro, aún así, existe ese riesgo.
Consultas Map-Reduce:
MapReduce es una técnica de procesamiento para computación distribuida
basada en Java. El algoritmo de MapReduce consiste de dos importantes
tares, Map y Reduce. Map toma un conjunto de datos y los convierte en otro
conjunto de datos, en donde los elementos individuales son separados en
tuplas con pares clave/valor. Por otra parte, la tarea Reduce, toma los
resultados devueltos por Map y combina ese conjunto de tuplas y forma otro
conjunto de tuplas más reducido.

En general, en el área de la computación distribuida Map se utiliza para

fraccionar una operación compleja entre varios nodos y Fold/Reduce para
recoger los resultados y unificarlos.
Por su parte, los frameworks MapReduce toman la base de las operaciones
mencionadas anteriormente para crear una operación genérica y más
compleja, cuyo funcionamiento es realmente útil para las bases de datos
NoSQL: en vez de usarse sobre listas de valores unidimensionales, ésta toma
como parámetros entrantes una lista de tuplas de tipo (clave, valor) y
devuelve una lista de valores. Entre las operaciones map (distribuida) y
reduce (normalmente localizada) se genera una lista de tuplas (clave, valor)
con valores temporales, de las que reduce filtra solamente las que tengan
una determinada clave.

Funcion map

Map(k1,v1) -> list(k2,v2)

 La función map(): se encarga del mapeo y es aplicada en paralelo para

cada ítem en la entrada de datos. Esto produce una lista de pares (k2,v2)
por cada llamada. Después de eso, el framework de MAPREDUCE junta
todos los pares con la misma clave de todas las listas y los agrupa,
creando un grupo por cada una de las diferentes claves generadas. Desde
el punto de vista arquitectural el nodo master toma el input, lo divide en
pequeñas piezas o problemas de menor identidad, y los distribuye a los
denominados worker nodes. Un worker node puede volver a sub-dividir,
dando lugar a una estructura arbórea. El worker node procesa el
problema y pasa la respuesta al nodo maestro.

Funcion Reduce
La función reduce es aplicada en paralelo para cada grupo, produciendo una
colección de valores para cada dominio:
Reduce(k2, list (v2)) -> list(v3)

 La función reduce(): cada llamada a Reduce típicamente produce un valor

v3 o una llamada vacía, aunque una llamada puede retornar más de un
valor. El retorno de todas esas llamadas se recoge como la lista de
resultado deseado.
Por lo tanto, el framework MapReduce transforma una lista de pares (clave,
valor) en una lista de valores. Este comportamiento es diferente de la
combinación "map and reduce" de programación funcional, que acepta una
lista arbitraria de valores y devuelve un valor único que combina todos los
valores devueltos por mapa.

Arquitectura del Map-reduce

La función map se ejecuta de forma distribuida a lo largo de varias máquinas.
Los datos de entrada, procedentes por regla general de un gran archivo
(fichero), se dividen en un conjunto de M particiones de entrada de
generalmente 16 a 64 megabytes. Estas particiones pueden ser procesadas
en diversas máquinas. En una invocación de MapReduce suelen ocurrir varias
operaciones:

 Se procede a dividir las entradas en M particiones de tamaño aproximado

de 16 a 64 megabytes. El programa MapReduce se comienza a instanciar
en las diversas máquinas del cluster. Por regla general, el número de
instancias se configura en las aplicaciones.

 Una de las copias del programa es especial y toma el papel de "maestro".

El resto de copias se denominan como "workers" y reciben la asignación
de sus tareas desde el master. Se considera que existen una cantidad de
M map tareas y de R reduce. El "maestro" se encarga de recopilar
"workers" en reposo (es decir sin tarea asignada) y le asignará una tarea
específica de map o de reduce. Un worker sólo puede tener tres estados:
reposo, trabajando, completo.

 Un worker que tenga asignada una tarea específica de map tomará como
entrada la partición que le corresponda. Se dedicará a parsear los pares
 (clave, valor) para crear una nueva pareja de salida, tal y como se
específica en su programación. Los pares clave y valor producidos por la
función map se almacenan como buffer en la memoria.

 Periódicamente, los pares clave-valor almacenados en el buffer se

escriben en el disco local, repartidos en R regiones. Las regiones de estos
pares clave-valor son pasados al master, que es responsable de redirigir a
los "workers" que tienen tareas de reduce().

 Cuando un worker de tipo reduce es notificado por el "maestro" con la

localización de una partición, éste emplea llamadas remotas para hacer
lecturas de la información almacenada en los discos duros de los diversos
workers de tipo map(). Cuando un worker de tipo reduce() lee todos los
datos intermedios, ordena las claves de tal modo que se agrupen los
datos encontrados que poseen la misma clave. El ordenamiento es
necesario debido a que, por regla general, muchas claves de funciones
map() diversas pueden ir a una misma función reduce(). En aquellos casos
en los que la cantidad de datos intermedios sean muy grandes, se suele
emplear un ordenamiento externo.

 El worker de tipo reduce itera sobre el conjunto de valores ordenados

intermedios, y lo hace por cada una de las claves únicas encontradas.
Toma la clave y el conjunto de valores asociados a ella y se los pasa a la
función reduce. La salida de reduce se añade al archivo (fichero) de salida
de MapReduce.

 Cuando todas las tareas map y reduce se han completado, el "maestro"

levanta al programa del usuario. Llegados a este punto la llamada
MapReduce retorna el control al código de un usuario.
Se considera que ha habido un final de las tareas cuando este control se ha
devuelto al usuario. Las salidas se ditribuyen en un fichero completo, o en su
defecto se reparten en R ficheros. Estos R ficheros pueden ser la entrada de
otro MapReduce o puede ser procesado por cualquier otro programa que
necesite estos datos.
Combinador (Agregadores locales)
En un entorno de clusterización, una de las límitaciones se encuentra en
el transporte de grandes ficheros entre ordenadores debido a lo limitado de
su ancho de banda. En el framework MapReduce la función map() escribe en
una memoria intermedia de carácter local, como puede ser un disco duro. La
información que se escribe localmente es agregada y ordenada por una
función agregadora encargada de realizar esta operación. Los valores
ordenados son de la forma [k, [v1, v2, v3, ..., vn]]. De esta forma la función
reduce recibe una lista de valores asociados a una única clave procedente del
combinador. Debido a que la latencia de red de ordenadores, y de sus discos
suele ser mayor que cualquier otra de las operaciones, cualquier reducción
en la cantidad de datos intermedios incrementará la eficiencia de los
algoritmos. En MapReduce, cualquier agregación local de los resultados
intermedios causa una mejora real de la eficiencia global.
Es por esta razón por la que muchas distribuciones oficiales de MkapReduce
suelen incluir operaciones de agregación en local, mediante el uso de
funciones capaces de agregar datos localmente. Evitando, o reduciendo en la
medida de lo posible el movimiento de grandes ficheros. Bien sea añadidas a
las funciones map, o a los agregadores locales.

Tolerancia a Fallos
El mecanismo de MapReduce es tolerante a fallos cuando uno de los workers
se ve sometido a un fallo. Como MapReduce se ha diseñado para procesos en
los que se encuentran involucrados grandes tamaños de datos mediante el
empleo de cientos o miles de ordenadores. Aún siendo la probabilidad de
fallo baja, es muy posible que uno (o varios) de los workers quede
desactivado precisamente por fallo de la máquina que le daba soporte. El
"master" periódicamente hace ping a cada worker para comprobar su
estatus.
Si no existe respuesta tras un cierto instante de espera, el master interpreta
que el worker está desactivado. Cualquier tarea map() que ha sido completa
por el worker regresa de inmediato a su estado de espera, y por lo tanto
puede resultar elegible para su asignación en otros workers. De forma
similar, cualquier función map (o reduce) que se encuentre en progreso
 durante el fallo, se resetea a estado de reposo pudiendo ser elegida para su
nueva re-asignación.
Las tareas de map completados se vuelven a re-ejecutar ante un fallo debido
en parte a que su salida se almacena en los discos locales de la máquina que
falló, y por lo tanto se consideran inaccesibles. Las tareas reduce completas
no son necesarias volver a ser re-ejecutadas debido a que su salida se ha
almacenado en el sistema global. cuando la tarea de map se ejecuta por
un worker A y luego por un worker B (debido principalmente a un fallo), en
este caso todas las tareas reduce() son notificadas para que eliminen datos
procedentes del worker A y acepten las del worker B. De esta forma la
ejecución de MapReduce es resiliente.

NoSQL vs SQL: Cuándo utilizar qué tipo de base de datos

 Cuando los datos deben ser consistentes sin dar posibilidad al error utilizar
una base de datos relacional. SQL.
 Cuando nuestro presupuesto no se puede permitir grandes máquinas y debe
destinarse a máquinas de menor rendimiento. NoSQL.
 Cuando las estructuras de datos que manejamos son variables. NoSQL.
 Análisis de grandes cantidades de datos en modo lectura. NoSQL
 Captura y procesado de eventos. NoSQL
 Tiendas online con motores de inteligencia complejos. NoSQL
Es muy importante en este punto insistir en que aunque parece que en estos
momentos lo suyo es migrar a bases de datos NoSQL, debemos tener muy en
cuenta antes de tomar esta decisión si las características de nuestra base de
datos necesita una base de datos NoSQL o relacional.
Que es Cassandra?

Cassandra, la dama de las bases de datos NoSQL

Apache Cassandra es una base de datos NoSQL distribuida y basada en un
modelo de almacenamiento de «clave-valor», de código abierto que está
escrita en Java. Permite grandes volúmenes de datos en forma distribuida.
Por ejemplo, lo usa Twitter para su plataforma. Su objetivo principal es la
escalabilidad lineal y la disponibilidad. La arquitectura distribuida de
Cassandra está basada en una serie de nodos iguales que se comunican con
un protocolo P2P con lo que la redundancia es máxima. Está desarrollada
por Apache Software Foundation.
Cassandra ofrece soporte robusto para múltiples centros de datos, con la
replicación asincrónica sin necesidad de un servidor maestro, que permiten
operaciones de baja latencia para todos los clientes.
Cassandra también ofrece un gran rendimiento. En 2012, investigadores de la
Universidad de Toronto que estudian los sistemas NoSQL concluyeron que
"En términos de escalabilidad, hay un claro ganador a través de nuestros
experimentos. Cassandra logra el más alto rendimiento para el número
máximo de nodos en todos los experimentos", aunque "esto tiene como
precio una alta latencia de escritura y lectura".
El modelo de datos de Cassandra consiste en particionar las filas, que son
reorganizadas en tablas . Las claves primarias de cada tabla tiene un primer
componente que es la clave de partición. Dentro de una partición, las filas
son agrupadas por las columnas restantes de la clave. Las demás columnas
pueden ser indexadas por separado de la clave primaria.
Las tablas se pueden crear, eliminar y alterar en tiempo de ejecución sin
bloquear actualizaciones y consultas.
Cassandra no soporta joins o subqueries, sino que enfatiza en la
desnormalización a través de características como colecciones.
En las versiones iniciales utilizaba un API propia para poder acceder a la base
de datos. En los últimos tiempos están apostando por un lenguaje
denominado CQL (Cassandra Query Language, no confundir con Contextual
Query Language) que posee una sintaxis similar a SQL aunque con muchas
menos funcionalidades. Esto hace que iniciarse en el uso de la misma sea
más sencillo. Permite acceder en Java desde JDBC.
 Historia y orígenes
El desarrollo inicial de Cassandra tiene su origen en Facebook, que lo diseñó
para potenciar la funcionalidad de búsqueda en el inbox. En 2008 fue
liberado como proyecto open source y en febrero de 2010 se convirtió en un
proyecto top-level de la fundación Apache. Está inspirado e influenciado por
los papers de Amazon Dynamo de 2007 y de Google BigTable de 2006. Hoy
en día está mantenido y desarrollado por la compañía Datastax.
Su nombre está inspirado por la sacerdotisa Cassandra de la mitología griega,
que tenía el don de la profecía, y predijo el engaño del Caballo de Troya.

Las características del modelo de datos de Cassandra es el siguiente:

 Una tabla de datos por cada instancia de Cassandra.
 Cada familia de columnas puede contener o bien columnas o bien
supercolumnas. Las supercolumnas son columnas son la agrupación de n-
columnas.
 Cada columna contiene elementos de la forma “Clave-Valor-Tiempo”,
donde el valor del campo tiempo es definible por el usuario.
 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.

Particularidades principales
Cassandra se ha vuelto tan popular debido a sus excepcionales características
técnicas. A continuación se presentan algunas de las características de
Cassandra:
 Escalabilidad elástica - Cassandra es altamente escalable; que permite
añadir más hardware para dar cabida a más clientes y más datos según
el requisito.
 Siempre en la arquitectura - Cassandra no tiene ningún punto único de
fallo y es continuamente disponible para aplicaciones críticas de
negocio que no pueden permitirse un fracaso.
  Su gran rendimiento lineal de escala - Cassandra es escalable
linealmente, es decir, que aumenta su rendimiento a medida que
aumenta el número de nodos del clúster. Por lo tanto, mantiene un
tiempo de respuesta rápido.
 El almacenamiento de datos flexible - Cassandra acomoda a todos los
posibles formatos de datos, incluyendo: estructurada,
semiestructurada, y no estructurados. Puede alojar de forma dinámica
los cambios en sus estructuras de datos de acuerdo a su necesidad.
 La distribución de datos fácil - Cassandra proporciona la flexibilidad
para distribuir los datos en las que necesita mediante la replicación de
datos a través de múltiples centros de datos.
 Soporte de transacciones - Cassandra admite propiedades como
atomicidad, coherencia, aislamiento y durabilidad (ACID).
 Escrituras rápidas - Cassandra fue diseñado para ejecutarse en
hardware barato de los productos básicos. Se lleva a cabo escrituras
extraordinariamente rápido y puede almacenar cientos de terabytes
de datos, sin sacrificar la eficiencia de la lectura.

Arquitectura
El objetivo del diseño de Cassandra es manejar grandes cargas de trabajo de
datos a través de múltiples nodos sin ningún punto único de fallo. Cassandra
tiene sistema distribuido de igual a igual a través de sus nodos, y los datos se
distribuyen entre todos los nodos de un clúster.
 Todos los nodos de un clúster juegan el mismo papel. Cada nodo es
independiente y al mismo tiempo interconectados a otros nodos.
 Cada nodo de un clúster puede aceptar solicitudes de lectura y
escritura, independientemente de donde los datos se encuentra
realmente en el clúster.
 Cuando un nodo se cae, las peticiones de lectura / escritura se pueden
servir de otros nodos de la red.
Replicacion de datos en Cassandra
En Cassandra, uno o más de los nodos en un acto clúster como réplicas para
una determinada pieza de datos. Si se detecta que algunos de los nodos
respondieron con un valor fuera de fecha, Cassandra devolverá el valor más
reciente al cliente. Después de devolver el valor más reciente, Cassandra
lleva a cabo una reparación de lectura en el fondo para actualizar los valores
rancios.
La siguiente figura muestra una vista esquemática de cómo Cassandra utiliza
la replicación de datos entre los nodos de un clúster para garantizar ningún
punto único de fallo.

Nota - Cassandra utiliza el Protocolo de chismes en el fondo para permitir

que los nodos que se comunican entre sí y detectar los nodos defectuosos en
el clúster.

Componentes de Cassandra
Los componentes clave de Cassandra son los siguientes -
 Nodo - Es el lugar donde se almacenan los datos.
 Centro de datos - Se trata de una colección de nodos relacionados.
 Cluster - Un clúster es un componente que contiene uno o más centros
de datos.
  Comprometerse registro - El registro de confirmación es un mecanismo
de recuperación de accidente en Cassandra. Cada operación de
escritura se escribe en el registro de confirmación.
 Mem-mesa - Un mem-tabla es una estructura de datos residente en
memoria. Después de cometer registro, los datos se escriben en el
mem-mesa. A veces, para una familia de una sola columna, habrá
múltiples mem-mesas.
 SSTable - Es un archivo de disco en el que los datos se añade desde la
mem-mesa cuando su contenido alcanzan un valor de umbral.
 Filtro Bloom - Estos no son más que rápidos, no deterministas,
algoritmos para comprobar que es un elemento es un miembro de un
conjunto. Es un tipo especial de memoria caché. filtros Bloom se
accede después de cada consulta.

Las operaciones de escritura

Cada actividad de escritura de nodos es capturado por las cometer registros
escritos en los nodos. Posteriormente los datos se capturan y se almacenan
en la mem-mesa. Cada vez que el mem-tabla está llena, los datos se
escriben en el archivo de datos SStable. Todas las escrituras se dividen y se
replican en todo el clúster automáticamente. Cassandra consolida
periódicamente los SSTables, descartando los datos innecesarios.

las operaciones de lectura

Durante las operaciones de lectura, Cassandra obtiene los valores de la mem-
mesa y comprueba el filtro de la floración para encontrar el SSTable
adecuada que contiene los datos requeridos.

keyspace
Espacio de claves es el contenedor más externo de datos en Cassandra. Los
atributos básicos de un espacio de claves en Cassandra son -
 Factor de replicación - Es el número de máquinas del clúster que
recibirán copias de los mismos datos.
  Estrategia de colocación de réplica - No es más que la estrategia de
colocar réplicas en el anillo. Tenemos estrategias como la simple
estrategia (estrategia de cremallera en cuenta), la estrategia de la
topología de red de edad (estrategia de cremallera cuenta), y
la estrategia de la topología de red (estrategia de centro de datos
compartidos).
 Familias de columna - espacio de claves es un contenedor para una
lista de una o más familias de columna. Una familia de columna, a su
vez, es un contenedor de una colección de filas. Cada fila contiene
columnas ordenadas. familias de las columnas representan la
estructura de los datos. Cada espacio de claves tiene al menos uno y a
menudo muchas familias de columna.
 La sintaxis de la creación de un espacio de claves es el siguiente -
 CREATE KEYSPACE Keyspace name
 WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
 La siguiente ilustración muestra una vista esquemática de un espacio
de claves.

Familia de columna
Una familia de columna es un contenedor para una colección ordenada de
filas. Cada fila, a su vez, es una colección ordenada de columnas. En la
siguiente tabla se enumeran los puntos que diferencian a una familia
columna de una tabla de bases de datos relacionales.

Tabla relacional Cassandra la columna Familia

Un esquema en un modelo relacional En Cassandra, aunque se definen

es fijo. Una vez que definimos ciertas
columnas para una tabla, mientras que
la inserción de datos, en cada fila todas
las columnas deben ser llenados al
menos con un valor nulo.
las familias de las columnas, las
columnas no son. Puede
incorporar cualquier columna
para cualquier familia de
columnas en cualquier momento.

tablas relacionales definen sólo las En Cassandra, una tabla contiene

columnas y el usuario rellena la tabla columnas, o se puede definir
con los valores. como una familia súper columna.

Columna
Una columna es la estructura de datos básica de Cassandra con tres valores,
a saber tecla o la columna nombre, valor y una marca de tiempo. A
continuación se realiza la estructura de una columna.

SuperColumn
Una columna de Super es una columna especial, por lo tanto, también es un
par clave-valor. Pero una columna súper almacena un mapa de sub-
columnas.
En general, las familias de las columnas se almacenan en el disco en archivos
individuales. Por lo tanto, para optimizar el rendimiento, es importante tener
columnas que es probable para consultar juntos en la misma familia de la
columna, y una columna de súper puede ser útil.

Ejemplo
Creación de un nuevo KeySpace:

Creación de una nueva tabla o Column Family:

Carga de datos en una tabla:

Consulta de datos de una tabla:

Conclusión
Cassandra es una solución brillante para muchos casos de uso que podemos
encontrar en el mundo Big Data. Sin embargo, no es adecuada para alojar
un data warehouse convencional. Lo ideal es tener claro desde el principio el
caso de uso y el tipo de consultas que haremos para diseñar la base de datos
coherentemente, de esta manera podremos manejar grandes volúmenes de
datos y aprovecharnos de las ventajas de esta potente base de datos
jdistribuida.