Informe cassandra

CONTENIDO
INTRODUCCIÓN
OBJETIVOS
2.1 Objetivo Generales
2.2 Objetivo Específicos
DESARROLLO
3.1 Apache Cassandra
3.1.1 Ventajas de Apache Cassandra
3.2 DataStax OpsCenter
3.2.1 Característica Principales de OpsCenter
3.2.2 OpsCenter Architecture
3.2.3 Data Modeling with Cassandra
3.2.1.1 Ejemplo de Modelo de Datos
3.2.4 Requerimiento para DataStax OpsCenter.
3.3 Ejemplo de una BD con Cassandra
CONCLUSIÓ
REFERENCIAS BIBLIOGRÁFICAS

I. INTRODUCCIÓN
Según estadísticas, el hombre ha generado más información en los últimos años que en el
resto de su existencia en la tierra, esto y el avance en las comunicaciones y las tecnologías
basadas en la web han hecho que nos veamos en la necesidad de generar nuevas formas de
guardar, organizar y distribuir nuestra información. Es por tal motivo que diversas empresas
comenzaron a desarrollar nuevas tecnologías, es así como la famosa red social Facebook
desarrollo Cassandra con el fin de dar soporte a los requerimientos de los usuarios los cuales
no podían ser satisfacidos con el modelo clásico relacional de las bases de datos SQL.
En el siguiente informe presentamos a un sistema gestor de base de datos no relacional
Casssandra, sus características, sus ventajas como desventajas, su modelo de datos, su
gestor y monitoreo visual y finalmente las conclusiones a las que se llegaron tras la
investigación.
II. OBJETIVOS
2.1 Objetivo Generales
Desarrollar a través de un ejemplo teorico, la aplicación del
concepto base de datos NoSQL mediante la utilización de
Cassandra.
2.2 Objetivo Específicos
❏ Conocer el concepto de NoSQL.
❏ Conocer y entender la terminología propia de Cassandra.
❏ Conocer las distintas formas de acceder al contenido de la BD
❏ Conocer cuáles son las formas de estructurar la información en Cassandra.

III. DESARROLLO
3.1 Apache Cassandra
Apache Cassandra es una base de datos NoSQL distribuida y basada en un modelo de
almacenamiento de «clave-valor», escrita en Java. Permite grandes volúmenes de datos de
forma distribuida. Por ejemplo, Twitter usa Cassandra como base de datos para su
plataforma.
El objetivo principal de Cassandra 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 (Peer to Peer) y la redundancia de los datos es máxima.
Cassandra está desarrollada por Apache Software Foundation.
En las versiones iniciales de Cassandra utilizaba 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) que posee una sintaxis similar a SQL, aunque con menos funcionalidades.
Esto hace que sea más fácil usar Cassandra y también Cassandra permite acceder en Java
desde JDBC.
3.1.1 Ventajas de Apache Cassandra
Figura 1: Ventajsa de Cassandra

Open Source:
Cassandra es un proyecto de código abierto de Apache, esto significa que está disponible de
forma libre. Puede descargar la aplicación y darle el uso que desee. Esto ha permitido que
nazca una gran comunidad de Cassandra en donde personas puedan dar sus ideas y
compartan sus opiniones, consultas, sugerencias relacionadas con Big Data.
Arquitectura Peer to Peer:
Cassandra sigue una arquitectura de Peer to Peer, en vez, de la arquitectura maestro-esclavo.
Por lo tanto, no hay ningún punto de Tolerancia a Fallo en Cassandra. Además, Cassandra
soporta cualquier cantidad de servidores o nodos que se quiera agregar a un Cluster en
cualquiera de los Data Center. Como todas las máquinas están en el mismo nivel, cualquier
servidor puede atender a las peticiones de cualquier cliente. Sin lugar a dudas, con es una
arquitectura robusta y con características excepcionales, Cassandra ha levantado un listón
sobre otras bases de datos.

Elastic Scalability:
Una de las mayores ventajas del uso de Cassandra es su Elastic Scalability. Cassandra Cluster
puede escalar o bajar durante la ejecución del Cluster con facilidad. Curiosamente, cualquier
número de nodos puede ser añadido o eliminado en el Cassandra Cluster sin mucho alboroto.
Usted no tiene que reiniciar el Cluster o realizar consultas a la aplicación Cassandra mientra
escala arriba o hacia abajo. Esta es la razón por la cual Cassandra es popular de tener un muy
alto rendimiento para el mayor número de nodos. Como ocurre en el escalamiento, leer y
escribir procesamiento tanto al aumentar simultáneamente con tiempo de inactividad en cero o
alguna pausa en las aplicaciones.
Alta Disponibilidad y Tolerancia a Fallos:
Otra característica notable de Cassandra es la replicación de datos que hace Cassandra gracia
a la Alta Disponibilidad y Tolerancia a Fallos que posee. La Replicación significa que cada dato
se almacena en más de una ubicación. Esto es porque, si un nodo falla, el usuario debe ser
capaz de recuperar los datos con facilidad desde otro lugar. En un Cluster Cassandra, cada fila
se replica en base a la clave de fila. Puede establecer el número de réplicas que desea crear.
Al igual que la escala, la replicación de datos también puede ocurrir a través de múltiples Data
Centres. Esto además conduce a un alto nivel de respaldo y recuperación de competencias en
Cassandra.

Alto Rendimiento:
La idea básica detrás de desarrollar Cassandra era aprovechar las capacidades ocultas de
varias máquinas multinúcleo. Cassandra ha hecho de este sueño una realidad! Cassandra ha
demostrado un rendimiento brillante debajo de grandes conjuntos de datos. Por lo tanto,
Cassandra es amado por las organizaciones que se ocupan de la enorme cantidad de datos de
todos los días y al mismo tiempo no puede permitirse el lujo de perder estos datos.
Columna Oriented:
Cassandra tiene un modelo de datos de muy alto nivel llamada Orientada a Columnas. Esto
significa que Cassandra almacena columnas basadas en los nombres de las columnas, lo que
lleva a corte muy rápido. A diferencia de las Bases de Datos Tradicionales, donde los nombres
de columna sólo consisten en metadatos, en Cassandra los nombres de las columnas puede
constar de los datos reales. Por lo tanto, las filas en Cassandra pueden consistir en varias
columnas, en contraste con una Base de Datos Relacional que consiste en un escaso número
de columnas. Cassandra está dotado de un modelo de ricos datos.
Tunable Consistency:
Características como Tunable Consistency, hace que Cassandra sea una base de datos
incomparable.

En Cassandra, Consistency puede ser de dos tipos - Consistency Eventual y Consistency
Fuerte. Usted puede adoptar cualquiera de ellos, en función de sus necesidades. Consistencia
eventual se asegura de que el cliente esté aprobado, en cuanto el grupo acepta la escritura.
Considerando que, la Consistency Fuerte significa que cualquier actualización se transmite a
todas las máquinas o todos los nodos, en donde el dato en particular esté situado. Usted
también tiene la libertad para mezclar tanto la Consistency Eventual y Fuerte. Por ejemplo,
usted puede ir para la Consistency Eventual en el caso de los Data Centers Remotos donde la
latencia es bastante alta, e ir a por la Consistency Fuerte para Data Centers Local donde la
latencia es baja.
Esquema Gratuito:
Desde su creación, Cassandra es famosa por ser una base de datos de Schema-less/schema-
free en su column family. En Cassandra, las columnas se pueden crear a su voluntad dentro de
las filas. Modelo de datos Cassandra también es famosa como modelo de datos de esquema
opcional. En contraste con una base de datos tradicional, en Cassandra no hay necesidad de
mostrar todas las columnas que necesita su aplicación en la superficie como cada fila no se
espera que tenga el mismo conjunto de columnas.

3.2 DataStax OpsCenter
DataStax OpsCenter es una solución de gestión y monitoreo visual para Apache Cassandra y
DataStax Enterprise. OpsCenter provee architect, DBA’s, de modo que el personal de
operaciones pueda contar con las capacidades de asegurar de forma inteligente y proactiva
sus grupos de base de datos, que estén funcionando bien y que las tareas de administración
sean simplificadas.
Los agentes DataStax están instalados en los nodos de Cassandra y DSE (DataStax Enterprise).
Ellos usan Java Management Extensions (JMX) para supervisar y gestionar cada nodo.
Cassandra expone una serie de estadísticas y de las operaciones de gestión a través de JMX.
Utilizando JMX, OpsCenter obtiene métricas de un clúster y emite varios comandos de
administración de nodo, como el lavado SSTables o hacer una reparación.
Figura 2: Gestion y monitoreo visual para Cassandra

3.2.1 Característica Principales de OpsCenter
OpsCenter ofrece una serie de características para ayudar a gestionar las agrupaciones tanto
DataStax Enterprise y Apache Cassandra y hacer su vida más fácil.
Las características principales de OpsCenter incluyen:
Dashboard
❏ Un "Dashboard" que muestra una visión general de las métricas de desempeño
comúnmente vistos.
❏ Adición de sus gráficos favoritos para el Dashboard.
❏ Una visión general que muestra las alertas y condensa los Dashboards de varios
clústeres.
Configuración y administración
❏ Básico de configuración del Cluster
❏ Las tareas de administración, como la adición de un cluster.
❏ Creación Visual del Clusters
❏ Gestión de múltiples Clusters desde una sola máquina con OpsCenter por medio
de un agentes.
❏ Gestión de múltiples nodos.
❏ Reequilibrio de datos a través de un Cluster cuando se añadan nuevos nodos.
❏ Descargable informe de Report del clúster en PDF.
Alertas y métricas de rendimiento
❏ Construido en capacidades de notificación externos.
❏ Avisos de alerta de problemas inminentes.
❏ Las métricas son recogidos en cada minuto en Cassandra.

Las operaciones de copia de seguridad y restauración de copias de seguridad
❏ Las operaciones Automáticas de copia de seguridad, incluyen la programación y
la eliminación de copias de seguridad antiguas.
❏ Restauración de copias de seguridad.
Funcionalidad solo para DataStax Enterprise.
Funcionalidad empresarial en OpsCenter sólo está habilitado en racimos DataStax Enterprise.
La siguiente es una lista de características que incluye:
❏ Seguridad , la capacidad de definir los roles de usuario.
❏ DataStax Enterprise Management Services.
❏ Alertas.
❏ Copia de seguridad y restauración de datos.
❏ Gestión en Masa.
❏ Ver las medidas históricas más de una semana.
❏ Reequilibrar.
❏ Diagnóstico tarball.
❏ Hadoop JobTracker Integration.
3.2.2 OpsCenter Architecture
Hay tres componentes principales de OpsCenter:
 The User Interface.
 The OpsCenter Daemon.
 The OpsCenter Agent.

Figura n°3: Diagrama de los componentes de OPSCenter
User Interface.
Este es el principal punto de entrada para interactuar con OpsCenter. La interfaz de usuario
de OpsCenter es completamente independiente al navegador del usuario. Cuando este se
carga, desde ese momento el javascript interactúa con la API expuesta por el OpsCenter
Daemon.
OpsCenter Daemon
Este es el proceso principal de OpsCenter. Es responsable de:
• Prestar servicio a la interfaz de usuario OpsCenter.
• Poner nueva información a la interfaz de usuario OpsCenter.
• Exponer una API de gestión.
• Gestionar Agentes de OpsCenter.
• Interactuar con el Cluster Cassandra a través de la vía thrift.

Las primeras responsabilidades del OpsCenter daemon, se refieren a la interacción con la
interfaz de usuario. OpsCenter ejecuta un servidor HTTP con el fin de servir a la componente
de interfaz de usuario de OpsCenter. Una vez que la interfaz de usuario se ha servido, el resto
de la interacción con el daemon se producirá a través de la API REST o vía STOMP. La única
interacción adicional entre la interfaz de usuario y el demonio es a través de STOMP. Esto se
utiliza para permitir que el demonio actualice la interfaz de usuario sin necesidad de
especificar una solicitud de HTTP. Esto es útil para las cosas que necesitan ser actualizados
con mucha frecuencia. Por ejemplo, la carga del servidor en la interfaz de usuario se
actualiza cada 5 segundos.
Las otras responsabilidades de OpsCenter en la actualidad se refiere a las
managing/monitoring del Cassandra Cluster. El demonio es el punto central para la
información del Cluster agregado, de modo que pueda ser expuesto a la interfaz de usuario.
Algo de esto se puede hacer de forma independiente por el demonio (sin los agentes) a través
de thrift. La información recogida sobre el thrift incluye cosas como la información básica de
clúster (nodo/token list, partitioner, snich), información de esquema y los datos de la familia
de la columna. Para obtener información adicional, el daemon se basa en el Agente OpsCenter
para ser instalado en los propios nodos Cassandra. La interacción entre el demonio y los
agentes es bastante similar a la forma en la interfaz de usuario interactúa con el demonio.
Agentes dispone de una API REST por el demonio para consultar, así como el pushing de datos
actualizados con frecuencia (como carga del servidor) para el demonio.
OpsCenter Agent
El OpsCenter Agent es el proceso que OpsCenter ejecuta en cada servidor del Cluster
Cassandra Cluster y es responsable de:
● Disponer de una interfaz para el OpsCenter Daemon para gestionar ese nodo.
● El envío de información sobre ese nodo al OpsCenter Daemon.
● Recogida de métricas sobre ese nodo.
● La escritura de datos métricos para Cassandra a través de thrift.

La principal responsabilidad del agente es recoger información sobre el nodo que está
monitoreando. Mucha de la información es usada por el OpsCenter Daemon, ya sea desde el
agente pushing datos para el Daemon a través de STOMP, o desde el Daemon querying la API
REST que el agente posee. Además, el agente recoge la información métrica y el rendimiento
del nodo para que los usuarios puedan visualizar gráficos de rendimiento en la interfaz de
usuario. La información de rendimiento que el agente recoge se almacena en el Cluster
Cassandra usando thrift. El agente se conectará al nodo Cassandra, este esta monitoreando a
través de thrift.
El otro principal responsabilidad del agente es exponer una interfaz de gestión para el nodo
Cassandra que está supervisando. Cassandra expone un buen número de operaciones de
gestión de nodos cassandra a través de un protocolo conocido como JMX. Hay algunas
razones que es difícil para el OpsCenter Daemon interactuar con la interfaz. Principalmente que
el Daemon está escrito en Python y existe preocupación de firewall/Networking. Por esta razón,
el agente actúa como un proxy para interactuar con las funciones de gestión para que el
OpsCenter Daemon puede acceder a ellos.
3.2.3 Data Modeling with Cassandra
Se detallarán brevemente los distintos elementos que componen el Modelo de Datos de
Cassandra.
Los conceptos básicos de este modelo de datos son:
Column:
Es la unidad más básica en el modelo de datos de Cassandra. Una column es un triplete de un
key (un nombre) un value (un valor) y un timestamp. Los valores son todos suministrados por el
cliente. El tipo de dato del key y el value son matrices de bytes de Java, el tipo de dato del
timestamp es un long primitive.
❖ Las column son inmutables para evitar problemas de multithreading.
❖ Las column se organizan dentro de las columns families.
❖ Las column se ordenan por un tipo, que pueden ser uno de los siguientes:
 AsciiType
 BytesType

 LongType
 TimeUUIDType
 UTF8Type
SuperColumn:
Es una column cuyos values son una o más columns, que en este contexto se llamarán
subcolumns. Las subcolumns están ordenadas, y el número de columnas que se puede definir
es ilimitada. Las Super columns, a diferencias de las columns, no tienen un timestamp definido.
Column Family:
Es más o menos análogo a una tabla en un modelo relacional. Se trata de un contenedor para
una colección ordenada de columns. Cada column family se almacena en un archivo separado.
SuperColumnFamily:

Así cómo las ColumnFamilies contienen filas, y éstas contienen claves y arreglos de columnas,
las SuperColumnFamilies también contienen filas, y éstas contienen claves. La diferencia es
que las claves no tienen arreglos de columnas, sino que tienen arreglos de SuperColumns.
Keyspace: Es el contenedor para las column family. Es más o menos análogo a una base de
datos en un modelo relacional, usado en Cassandra para separar aplicaciones. Un keyspace es
una colección ordenada de columns family.
Clúster: Conjunto de máquinas que dan soporte a Cassandra y son vistas por los clientes
como una única máquina.
Tabla comparativa de Modelo Relacional y el Modelo de Cassandra
3.2.1.1 Ejemplo de Modelo de Datos
Tabla de Tweets
Se agrega la columna user_id.

Se forma familias de Columna.
3.2.4 Requerimiento para DataStax OpsCenter.
Los requisitos mínimos de hardware para la máquina, en la que se ejecutará OpsCenter:
● 2 núcleos de CPU.
● 2 GB de RAM disponible para OpsCenter.
3.3 Ejemplo de una BD con Cassandra
Entorno de Trabajo: Se trabajará de forma local.
Hardware: PC Samsung, procesador intel i3, 4 GB RAM, tarjeta de video Nvidia 520 mx, HHDD
500 GB.
Sistema Operativo: Ubuntu Linux 14.04
Lo primero es crear el keyspace lo cual es equivalente a una base de datos, esto lo hacemos
con el comando:
CREATE KEYSPACE entradas WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
Luego seleccionamos el Keyspace con el comando:
USE entradas;
La manera más sencilla de crear una tabla es la siguiente:

CREATE TABLE usuario(
usrid int PRIMARY KEY,
nombre text,
ape1 text
);
Con esta sentencia generamos una tabla como las que conocemos en el modelo sql tradicional
usrid nombre apel
sin embargo, esto nos obliga a que cuando queramos buscar un usuario sepamos de antemano
el usrid, ya que no podemos buscar por nombre o apellido. Para solucionar esto vamos a
utilizar una estructura un poco más compleja donde además del usuario agregaremos las
entradas que ha posteado en su perfil.
usrid int,
nombre text,
ape1 text,
idpost int,
cuerpo text,
primary key (usrid, idpost)
);
Al crear la tabla con esta estructura y ejecutar varios insert se nos creará una estructura
como la que sigue:
idpost1 idpost2 idpostN nombre ape1
usrid1 cuerpo1 cuerpo2 cuerpoN

Es aqui donde comenzamos a utilizar una de las principales características de Cassandra que
es la desnormalización, ya que tendremos tantas columnas como posteos tenga el usuario,
cabe destacar que el la cantidad de columnas a utilizar teóricamente alcanza el numero no
menor de 2.000.000.000, sin embargo en la práctica al llegar a las 100.000 columnas
comienza a bajar el rendimiento.
Una manera de solucionar esto es crear un primary key compuesto, de tal manera de separar
los posteos o entradas por año, esto se logra de la siguiente manera:
usrid int,
nombre text,
ape1 text,
idpost int,
año int,
cuerpo text,
primary key ((usrid,año), idpost)
);
Lo cual nos daria un resultado como el siguiente:
nombre ape1 idpost1 idpost2 idpost3 idpostN
usrid:
anio
nom ape1 cuerpo1 cuerpo2 cuerpo3 cuerpoN

Dentro del modelo de datos de Cassandra también podemos encontrar los set, los cuales nos
permiten agregar varias entradas para una misma columna, por ejemplo:
CREATE TABLE users (
user_id text PRIMARY KEY,
first_name text,
last_name text,
emails set<text>
);
Luego para insertar datos usamos lo siguiente:
INSERT INTO users (user_id, first_name, last_name, emails)
VALUES('frodo', 'Frodo', 'Baggins', {'f@baggins.com', 'baggins@gmail.com'});
Si queremos agregar una nueva entrada ejecutamos la siguiente CQL
UPDATE users
SET emails = emails + {'fb@friendsofmordor.org'} WHERE user_id = 'frodo';
Entonces al realizar un select la respuesta sera la siguiente:
user_id | emails
---------+-------------------------------------------------------------------
frodo | {"baggins@caramail.com","f@baggins.com","fb@friendsofmordor.org"}
Para nuestro ejemplo simularemos una red social, en la cual existen usuarios y relaciones
entre ellos (amistad), además de esto los usuarios pueden publicar entradas dentro de su
perfil.
En el modelo relacional esto seria mas o menos así
En SQL esto implicaba crear la tabla intermedia ‘amistad’ para poder soportar la relación de
muchos a muchos, sin embargo para Cassandra esto es más sencillo, simplemente basta con
definir un list para los usuarios y una familia de columnas para las entradas, de la siguiente
manera:

CREATE TABLE users (
user_id text PRIMARY KEY,
first_name text,
last_name text,
email text,
amigos list<text>
);
CREATE TABLE entradas(
user_id text,
id_entrada text,
cuerpo text,
primary KEY (user_id,id_entrada)
);
esto me genera familias de columnas con la siguiente estructura:
usuarios
first_name last_name email amigos
juan Juan Rojas j@mail {‘jose’}
jose Jose j2@mail {‘juan’,’beto’}
entradas
id_entrada:1 id_entrada:2 ... ... id_entrada:N
juan cuerpo1 cuerpo2 cuerpoN

IV. CONCLUSIÓN
Cassandra se presenta como una gran solución a la problemática de los grandes bancos de
datos, aun cuando la forma de modelar dista bastante de el modelo clásico relacional que
todos conocemos, además, las herramientas para administrar nuestros Keyspaces, cluster y
nodos nos ayudan a mantener un orden al momento de desarrollar y utilizar nuestras
aplicaciones.
El lenguaje CQL nos provee funciones bastante parecidas a lo que estábamos acostumbrados
con SQL, haciendo más fácil el acostumbrarse a utilizar las diversas funcionalidades de esta
tecnología.
V. REFERENCIAS BIBLIOGRÁFICAS
❏ http://www.datastax.com/documentation/opscenter/5.0/opsc/about_c.html
❏ http://www.datastax.com/dev/blog/opscenter-an-architecture-overview
❏ http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet/

Informe cassandra

Más contenido relacionado

La actualidad más candente

Similar a Informe cassandra

Más de Helenio Corvacho

Informe cassandra