1

UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

OPTIMIZACION DEL RENDIMIENTO DEL

DEPOSITO DE DATOS EN UN SISTEMA WEB A
TRAVES DEL USO DE CASSANDRA

POSTULANTE : Boris Gonzalo Medrano Guzmán

TUTOR : Msg. Juan Marcelo Claure Salinas

Cochabamba – Bolivia
2018
 2

DEDICATORIA

A todos los que aportan el conocimiento

y el saber permitiendo que otros puedan mejorar y

fortalecer sus habilidades que a corto, medio o largo

plazo son demostrados en resultados

que son dignos de admiración.

_ Boris Gonzalo Medrano Guzmán_

 3

AGRADECIMIENTOS

Es difícil dejar de mencionar a las personas que día a día

fortalecen el conocimiento y la sabiduría de los demás.

Me faltaría líneas en este trabajo mencionar a todos,

pero quiero agradecer en primer lugar a Dios y mi familia

que siempre están presentes en todos los pasos de mi vida.

_ Boris Gonzalo Medrano Guzmán _

 4

Tabla de contenido
Tabla de Figuras ................................................................................................................................. 6

Capítulo 1 Introducción
1. Introducción................................................................................................................................. 7

1.1 Antecedentes................................................................................................................................ 8

1.2 Definición del problema................................................................................................................ 9

1.3 Objetivos ...................................................................................................................................... 9

1.3.1 Objetivo General.............................................................................................................................. 9

1.3.2 Objetivos especifico ......................................................................................................................... 9
1.4 Alcance ....................................................................................................................................... 10

1.5 Justificación ................................................................................................................................ 10

Capítulo 2 Marco Teórico

2. Definición....................................................................................................................................11

2.1 Características............................................................................................................................. 13

2.1.1 Teorema CAP .................................................................................................................................13

2.1.2 Base de datos distribuida ..............................................................................................................15
2.2.1 Componentes principales de Cassandra ....................................................................................19
2.2.2 Componentes principales para la configuration de Cassandra..............................................19
2.3 Peticiones de escritura de datos en Cassandra ........................................................................... 20

2.4 Peticion de borrado de datos en Cassandra ................................................................................ 22

2.5 Peticion de lectura de datos en Cassandra.................................................................................. 22

2.6 Tareas de Administración ......................................................................................................... 23

2.6.1 Seguridad ........................................................................................................................................23

2.6.2 Copias de respaldo .........................................................................................................................23
2.6.3 Asegurar la consistencia de los datos..........................................................................................23
 5

2.7 Modelo de datos Cassandra ........................................................................................................ 24

2.8 CQL ............................................................................................................................................. 25

2.9 Cuadro Comparativo ................................................................................................................... 26

Capítulo 3 Área de Aplicación

3. Definición....................................................................................................................................27

3.1. Antecedentes......................................................................................................................... 28

3.1.1 Antecedentes Generales ................................................................................................................28

3.1.2 Antecedentes Especificos ..............................................................................................................29
3.1.3 Lienzo del modelo de negocio ......................................................................................................30
3.1.4 Arbol de Problema.........................................................................................................................30
3.1.5 Modelo ER ......................................................................................................................................31
Capítulo 4 Marco Práctico
4. Objetivo ......................................................................................................................................32

4.1 Análisis y Validación ................................................................................................................... 34

4.2 Ejemplos ..................................................................................................................................... 35

4.2.1 Personal ...........................................................................................................................................35

4.2.2 Usuario ............................................................................................................................................37
Conclusiones ......................................................................................................................................41

Recomendaciones ..............................................................................................................................42

Bibliografía ........................................................................................................................................43
 6

Tabla de Figuras
Figura 1. Versiones de Cassandra........................................................................................…… 12
Figura 2. Teorema CAP y Cassandra ..................................................................................…… 14
Figura 3. Clúster d nodos Cassandra en diferentes hosts de red........................................ …… 16
Figura 4. Cantidad de operaciones por segundo ................................................................. …… 17
Figura 5. Arquitectura de nodos ..........................................................................................…… 18
Figura 6. Escritura de datos en Cassandra .......................................................................... …… 21
Figura 7. Keyspace Cassandra .............................................................................................…… 25
Figura 8. Cuadro comparativo .............................................................................................…… 26
Figura 9. Lienzo de Negocio................................................................................................…… 30
Figura 10. Arbol de Problema..............................................................................................…… 30
Figura 11. Modelo Entidad Relación ..................................................................................…… 31
Figura 12. Tabla Personal .................................................................................................... …… 35
Figura 13. Selección de datos Personal ............................................................................... …… 36
Figura 14. Validación de Tabla ...........................................................................................…… 36
Figura 15. Creación de tabla personal con Cassandra ........................................................…… 37
Figura 16. Tabla usuario ...................................................................................................... …… 38
Figura 17. Selección de datos usuario .................................................................................…… 38
Figura 18. Validación de tabla .............................................................................................…… 39
Figura 19. Creación de tabla usuario con Cassandra..........................................................…… 39
Figura 20. Batch ...................................................................................................................…… 40
 7

Capítulo I – Introducción

1. Introducción

En la actualidad, las bases de datos relacionales se han proyectado a ser una de las herramientas

más difundidas en nuestra sociedad de la informática, las cuales permiten almacenar, manipular y

recuperar información de diversos campos. No obstante han tenido que pasar algunos años para

que las bases de datos puedan alcanzar el desarrollo que hoy conocemos, comenzando con el

almacenamiento de información con tarjetas perforadas y cintas magnéticas, uso de discos que

dieron inicio a las bases de datos, bases de datos en red y bases de datos jerárquicos de ahí surge

las bases de datos relaciones que en un principio consistió en una serie de reglas para la evaluación

de administradores de sistemas, siendo un repositorio compartido de datos que permiten establecer

interconexiones (relaciones) entre los datos (que están guardados en tablas), y a través de dichas

conexiones relacionar los datos de ambas tablas, de ahí proviene su nombre Modelo Relacional

este tipo de base de datos son llamados SGBDR (Sistema de Gestión de Bases de Datos Relacional)

que tienen como lenguaje principal SQL (Lenguaje de Consulta Estructurada).

Para poder optimizar los tiempos de respuesta en las diferentes consultas se implementa bases de

datos NoSQL (a veces llamado “no solo SQL”), se refiere a un grupo de sistemas de bases de

datos no relacionales; cuya característica principal, es que no se encuentran construidas en tablas

y generalmente no se usa lenguajes comunes del SQL para manipular los datos. Los sistemas de

bases de datos en NoSQL por su naturaleza tienen la utilidad en la facilidad de trabajar con grandes

cantidades de datos ya que se encuentran diseñados para el almacenamiento de datos en gran escala

y procesamiento de datos en paralelo a través de varios servidores. Los sistemas NoSQL pueden

soportar múltiples actividades de consulta y análisis de tipo predictivo como exploratorio. Es

 8

diversa la aplicabilidad de las bases de datos, en este documento se considera las bases de datos

NoSQL Cassandra para las consultas o solicitudes de datos, indicando las principales

características de almacenamiento y recuperación de datos en un servidor cassandra.

1.1 Antecedentes

De los diferentes modelos de datos, el modelo relacional ha sido popular desde los años 80s con

la implementación SQL (Lenguaje de Consulta Estructurada), el SQL es un leguaje basado en

consultas de acceso a bases de datos relacionales, que permite efectuar consultas con el fin de

recuperar información de interés de una base de datos, como hacer cambios o borrados de forma

sencilla con implementaciones de Oracle, MySQL y los servidores SQL Microsoft. En la época de

los 90s y 2000 fueron herramientas estándar para una gran cantidad de industrias. La escalabilidad

en varios servidores con grandes cantidades de datos esta tendencia se debe a dos razones

principales

 El crecimiento exponencial en el volumen de datos generados por los usuarios sistemas y

sensores, acelerado aún más por la concentración de este volumen por sistemas distribuidos

como Amazon, Google y varios servicios en la nube.

 La creciente independencia y complejidad de los datos acelerados por la internet, la Web

2.0, las redes sociales y la necesidad de un acceso estandarizado a fuentes de datos de varios

sistemas distintos.

El termino NoSQL que fue acuñado en 1998, originalmente se refería a una base de datos

relacional de código abierto, que no usaba un lenguaje de consultas SQL, al principio fue un

concepto el cual no lo tomaron en cuenta, pero conforme al paso del tiempo en el año 2009 un

empleado de Racksp ace Rick Evans, reintrodujo el término en un evento el cual se discutía las

bases de datos de código abierto. En la actualidad, con las organizaciones que recolectan grandes
 9

cantidades de datos sin estructurar se encuentran migrando hacia el uso de bases de datos no

relacionales, también conocidos como bases de datos NoSQL, las bases de datos NoSQL se

enfocan en los procesos analíticos de datasets, alarga escalan ofreciendo escalabilidad en campos

como la analítica en Big Data, Inteligencia de negocios y Redes Sociales.

1.2 Definición del problema

Como optimizar el rendimiento del depósito de datos de un sistema transaccional de forma que

pueda mejorar la velocidad de respuesta en las consultas utilizando base de datos NoSQL

Cassandra.

1.3 Objetivos

1.3.1 Objetivo General

Diseñar las tablas principales para la optimización de depósito de datos utilizando Cassandra

NoSQL.

1.3.2 Objetivos especifico

 Estudiar el modelo ER del Sistema de Seguridad Industrial

 Diseñar un marco conceptual del uso de base de datos Cassandra

 Identificar entidades para la creación de tablas con Cassandra

 Verificar el cumplimiento de reglas de optimización con Cassandra

 Analizar tipos de solicitudes del depósito de datos en Cassandra

 10

1.4 Alcance

El proyecto se centra en el modelo relacional que se tiene del Sistema de Seguridad Industrial, en

el cual identificaremos las tablas del modelo a ser manipuladas para el depósito de datos con

cassandra, ya que no todas cumplen con los requisitos en la valoración de datos.

1.5 Justificación

La obtención de datos en tiempos de ejecución más cortos nos ayuda a garantizar que los datos se

encuentren actualizados y disponibles para la toma de decisiones. Como también tener réplicas de

información en servidores y nodos distribuidos.

 11

Capítulo II – Marco Teórico

2. Definición

Apache Cassandra fue inicialmente desarrollada en Facebook, para impulsar las búsqueda en la

bandeja de entrada .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 tienen 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.

 12

Las tablas se pueden crear, eliminar y alterar en tiempo de ejecución sin bloquear actualizaciones

y consultas.

Cassandra no soporta joins (unir) o subqueries (sub consultas), 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 (Lenguaje de Consultas

Cassandra) 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.

Figura1. Versiones Cassandra

Fuente: https://es.wikipedia.org/wiki/Apache_Cassandra
 13

2.1 Características

2.1.1 Teorema CAP

CAP significa "consistencia, disponibilidad y tolerancia a la partición". El teorema CAP, que fue

formulado por primera vez por Eric Brewer en 2000, establece que como mucho, sólo se pueden

obtener dos de esas propiedades en cualquier sistema de datos compartidos. Así que debe elegir

dos; no puede tenerlas todas. Para saber más acerca del teorema, vea a continuación "Temas

relacionados", aunque le voy a dar una visión general.

Es importante que entienda el teorema CAP ya que está relacionado con Cassandra. Según el

teorema, para cualquier sistema distribuido se debería elegir las dos garantías más importantes

para el sistema. En Cassandra es posible tener las tres garantías, pero no al mismo tiempo. Por lo

tanto, cuando se quiere una base de datos altamente disponible y sin tiempo de inactividad, y no

se quiere ser pillado por fallos ocasionales del hardware, Cassandra es la mejor opción para las

soluciones que se enfocan en la disponibilidad y en la tolerancia a particiones.

Esto contrasta con las propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad) de

un sistema de gestión de bases de datos relacionales SGBDR (Sistema de Gestión de Bases de

Datos Relacional) tradicional, como MySQL, DB2®, Oracle y Sybase. No quiero sugerir que en

Cassandra no se tengan las operaciones atómicas, ni que los datos en Cassandra no estén aislados

ni sean duraderos. Simplemente quiero decir que esas no son las principales preocupaciones de

Cassandra. La base de datos nació para ser distribuida de forma nativa y para escalar fácilmente a

medida que crecen los datos y las transacciones de las aplicaciones.

Es imposible para un sistema distribuido garantizar simultáneamente las siguientes tres

características:
 14

 Consistencia: un conjunto de operaciones se deben ejecutar al mismo tiempo, o dicho de

otra forma, un sistema es consistente si una modificación se aplica a todos los nodos en el

mismo tiempo lógico y, por tanto, cuando se recupera la información, todos los nodos

devuelven el mismo resultado.

 Disponibilidad: una garantía de que todos los requerimientos recibirán una respuesta de

que el requerimiento fue exitoso o fallido.

 Tolerancia a la Partición: una petición debe ser procesada por el sistema incluso si se

pierden de forma arbitraria mensajes entre alguno o todos los nodos del sistema, es decir,

si un nodo se separa de la red (porque pierde conectividad), el sistema seguirá disponible.

Figura 2. Teorema CAP y Cassandra

Fuente: https://www.swapbytes.com/teorema-cap-base-datos/ (Strappazzon Nicola 2016)

 15

Siguiendo el teorema, un sistema distribuido solamente podrá asegurarnos lo siguiente:

 CP: el sistema ejecutará las operaciones de forma consistente, aunque se pierda la

comunicación entre nodos (partición del sistema), pero no se asegura que el sistema

responda (disponibilidad).

 AP: el sistema siempre responderá a las peticiones, aunque se pierda la comunicación entre

nodos (partición del sistema). Los datos procesados pueden no ser consistentes. Ejemplo

bases de datos como Cassandra operan bajo esta modalidad, un ejemplo funcional sería

la red social Facebook.

 CA: el sistema siempre responderá a las peticiones y los datos procesados serán

consistentes. En este caso no se permite una pérdida de comunicación entre nodos

(partición del sistema). Todos los gestores relacionales aplican bajo este concepto.

2.1.2 Base de datos distribuida

Por naturaleza, Cassandra es una base de datos distribuida. Eso significa que fue diseñada para

ejecutarse en una red de nodos de computadoras, funcionando como un servidor que tiene

diferentes partes que se ejecutan en diferentes máquinas sin ningún hardware o software específico

para gestionar o coordinar. Toda la coordinación de los nodos y la distribución de los datos están

dentro de su propia arquitectura. Esta es una de las razones por las que una red de Cassandra es

más barata y más fácil de escalar de forma horizontal que otros sistemas de bases de datos

relacionales comunes. La topología típica de la red de Cassandra, está compuesta por un clúster de

nodos, también llamado anillo de Cassandra, que se ejecuta en diferentes direcciones de red que

están ubicadas en servidores físicos diferentes.

 16

Figura3. Clúster de nodos de Cassandra en diferentes hosts de la red

Fuente: datastax.com

Esta función incrementa la disponibilidad de la red en caso de fallo de un nodo. Cada nodo puede

coordinar la solicitud de un cliente sin un nodo maestro, para que no haya un punto único de fallo.

También le permite establecer diferentes estrategias de configuración para que los datos sean

conscientes de las diferentes ubicaciones de los nodos, lo que, por lo tanto, incrementa aún más la

disponibilidad del sistema.

El factor de replicación es un aspecto importante de la configuración del clúster. Se define por un

espacio de claves o por la configuración del esquema. Toda la información acerca de los datos del

clúster, de la topología, de la disponibilidad de nodos, y del rendimiento es intercambiada entre

los nodos a través del gossip protocol (protocolo de chisme), un tipo de protocolo peer-to-peer (de

igual a igual). Esta información es importante para avisar a las condiciones del cliente acerca de

qué nodo es el mejor para leer o escribir datos en un momento dado.

 17

2.2 Arquitectura

Cassandra nos proporciona tolerancia a particiones y disponibilidad, pero a cambio de ser

eventualmente consistente, tal y como define el teorema CAP. El nivel de consistencia puede ser

configurado, según nos interese, incluso a nivel de consulta.

Es distribuida, lo que quiere decir que la información está repartida a lo largo de los nodos del

clúster. Además ofrece alta disponibilidad, de manera que si alguno de los nodos se cae el servicio

no se degradará.

Escala linealmente, lo que quiere decir que el rendimiento de forma lineal respecto al número de

nodos que añadamos. Por ejemplo, si con 2 nodos soportamos 100.000 operaciones por segundo,

con 4 nodos soportaremos 200.000. Esto da mucha predictibilidad a nuestros sistemas.

Escala de forma horizontal, lo que quiere decir que podemos escalar nuestro sistema añadiendo

nuevos nodos basados en hardware commodity de bajo coste.

Figura 4. Cantidad de operaciones por segundo

Fuente: datastax.com
 18

Los nodos se reparten equitativamente el rango de tokens que van de -263 a 2 63, esto define el nodo

primario. Internamente Cassandra replicará los datos entre los nodos con la política que le

definamos.

 Varios nodos independientes comunicados mediante un protocolo P2P (peer-to-peer).

 Todos los nodos intercambian información con el resto de forma continua

 No hay nodos “principales”. Los clientes pueden conectarse a cualquiera de los nodos para

realizar las operaciones de lectura y escritura.

 El nodo al que se conecta el cliente actúa como coordinador entre éste y el resto de nodos

en dónde se encuentran los datos afectados por la consulta.

 El coordinador determina qué nodos deben responder a la consulta.

Figura 5. Arquitectura de nodos

Fuente: Gestores NoSQL Cassandra (García Diego 2017)
 19

2.2.1 Componentes principales de Cassandra

 Clúster: contiene uno o varios centros de datos.

 Centro de datos (datacenter): colección de nodos, que puede ser virtual o físico.

 Nodo: componente básico de la infraestructura de Cassandra en donde se almacenan los

datos como ser: Commit log que es el fichero en donde se almacena la información sobre

cambios en los datos. Sirve para recuperar los datos en caso de un fallo en el sistema,

MemTable la estructura de almacenamiento en memoria contiene los datos que aún no han

sido escritos en un SSTable y SSTable el fichero que almacenan los datos escritos en disco

cada fichero SSTable es inmutable una vez creado.

2.2.2 Componentes principales para la configuración de Cassandra

 Comunicaciones entre nodos: Protocolo de comunicación peer-to-peer para descubrir y

compartir información sobre la localización y estado de los nodos en un clúster de

Cassandra.

 Particionado: Determina cómo se distribuyen los datos entre los nodos (primera copia,

resto de copias).

 Estrategia de réplicas: Define la estrategia a seguir para almacenar copias de los mismos

datos en diferentes nodos, de forma que aseguren la accesibilidad y la tolerancia a fallos.

Se pueden definir diferentes estrategias, no hay copia principal ni copias secundarias de los

datos, todas las copias incluida la primera son replicas.

 Snitch: Define la topología que utilizan las estrategias de replicación para colocar las

réplicas y dirigir las consultas de forma eficiente.

 20

2.3 Peticiones de escritura de datos en Cassandra

 Escritura en MemTable: almacena las escrituras de cada familia de columnas de forma

temporal en memoria. Por ello, en Cassandra, las escrituras son “baratas”. Si existe un dato

con la misma llave primaria se procede a reescribirlo.

 Escritura en Commit log: en cada nodo, el Commit log almacena toda la actividad de

escritura para garantizar la durabilidad de los datos. Si el sistema se apaga, se pueden

recuperar las escrituras desde el Commit log. Por lo que habrá tantos logs como escrituras

se hagan (no se sobrescriben, si tienen la misma llave primaria)

 Flush de la MemTable: cuando se llena, se libera la memoria, realizando un borrado de

los datos.

 Escritura en SSTable: los datos borrados en la fase de Flush de la MemTable se escriben

en disco, en ficheros llamados SSTable.

Los ficheros SSTable son inmutables, no se vuelve a escribir en ellos después de volcar los

datos de la MemTable. Por ello, los datos de una misma partición pueden estar repartidos

en varias SSTable.

Este es el motivo por el que las lecturas son más “caras” que las escrituras en Cassandra,

ya que una lectura suele requerir el acceso y búsqueda en varias SSTable.

 Compactación: En esta fase, ejecutada periódicamente por Cassandra, se trata de reducir

el número de ficheros SSTable, eliminando aquellos obsoletos (datos antiguos).

El objetivo es hacer más eficientes las lecturas.

 21

Figura 6. Escritura de datos en Cassandra

Fuente: Gestores NoSQL Cassandra (García Diego 2017)

 22

2.4 Peticion de borrado de datos en Cassandra

Cuando una fila es eliminada, no se borra del disco (SSTables inmutables), sino que se marca

como eliminada (tombstone). Durante la compactación, las filas marcadas son eliminadas

definitivamente del disco. También cuenta con un tiempo de gracia si un nodo que contiene la fila

a ser eliminada se encuentra caído en ese momento, aún tiene la posibilidad de recibir la orden de

eliminación si se recupera en un intervalo de tiempo predefinido. Si no se recupera en ese tiempo,

la fila no será marcada como eliminada, por lo que pueden existir inconsistencias en las réplicas.

Por ello, se recomienda que los administradores realicen cada cierto tiempo tareas de

mantenimiento en Cassandra.

2.5 Peticion de lectura de datos en Cassandra

En cada nodo que recibe la lectura, se accede mediante key a la MemTable para recuperar los datos

requeridos. Si los datos (o parte de ellos) no se encuentran en la MemTable, se accede a las

SSTable. En caso de presentarse lentitud se debe a que no se realizó la tarea de compactación

recientemente es probable que se deba leer en varias SSTables para recuperar todos los datos

solicitados.

En cassandra existen 3 tipos diferentes de lectura que son:

 Direct read request (Solicitud de lectura directa): el nodo coordinador contacta con un

nodo que contenga la réplica requerida

 Digest request (solicitud de resumen): contacta con tantos nodos con réplicas como se

determine en el nivel de consistencia. Se comprueba la consistencia de los datos retornados

por el nodo contactado en el Direct read request. Se envía la consulta aquellos nodos que

estén respondiendo “más rápido”. Si existen inconsistencias, se consideran como válidos

las réplicas con una marca de tiempo más reciente. Estos son los retornados al cliente. Una
 23

vez contactados los nodos determinados por el nivel de consistencia, se envía una solicitud

al resto de réplicas, para determinar si son también consistentes.

 Background read repair request (Solicitud de reparación de lectura de fondo): En caso

de existir inconsistencias en las réplicas, las réplicas con una marca de tiempo más antiguo

son sobrescritas con los datos de la réplica “más actual”.

2.6 Tareas de Administración

2.6.1 Seguridad

Seguridad a nivel de usuarios: usuario con contraseña y permisos de gestión y administración vía

GRANT/REVOKE.

Opciones de encriptación tanto entre clientes y clústeres como entre nodos.

DataStax Enterprise ofrece opciones avanzadas de seguridad, como autentificación externa,

encriptación de tablas, y auditoría de datos.

2.6.2 Copias de respaldo

Ofrece varias opciones de respaldo recomendado hacerlos de forma regular ante errores como los

borrados accidentales.

DataStax OpsCenter provee de una interfaz de visualización para el mantenimiento de respaldos y

para su restauración

2.6.3 Asegurar la consistencia de los datos

Como existe el riesgo de encontrar datos inconsistentes en los nodos, a pesar de los mecanismos

suministrados por Cassandra, se recomienda realizar tareas rutinarias de mantenimiento.

 24

Un nodo caído recibe una petición de borrado que no puede ejecutar. El nodo se recupera tiempo

después de que el “tiempo de gracia” de esa orden haya caducado, por lo que tiene datos

inconsistentes (que deberían ser borrados). No se realiza ninguna consulta sobre esos datos, por lo

que no hay posibilidad de recibir un Read Repair Request. Cassandra ofrece una operación,

llamada repair, que puede utilizarse por parte del usuario para asegurar que todos los nodos son

consistentes (no hay réplicas con diferentes valores).

2.7 Modelo de datos Cassandra

Como ya hemos comentado las bases de datos NoSQL no existe un modelo de datos fijo, sino que

es flexible y dinámico, y cómo no iba a ser de otra forma, ocurre lo mismo con Apache Cassandra.

Conlleva que la estructura creada para una base de datos depende del tipo de consultas que se

vayan a realizar. También hemos comentado en el apartado 1.1.3.2 que

Apache Cassandra podemos catalogarla como una base de datos Clave-valor; por ello utiliza los

siguientes conceptos:

 Column: Es el nivel más bajo que hay, se trata de una estructura con 3 campos, que son: el

nombre de la columna, el valor que tiene y el timestamp. El timestamp contiene el momento

(fecha, hora en milisegundos) en la cual se ha realizado la inserción.

 supercolumn: es un conjunto de Columns.

 ColumnFamily: se trata de un conjunto de Columns ordenadas, de tal manera que cada fila

contiene una clave. Las ColumnFamily se pueden definir como las tablas de las bases de

datos relacionales.

 Keyspace: es el nivel más alto en el modelo de datos. La keyspace contiene todas las

familias de columnas. Para que nos resulte más sencillo de entender, podemos compararlo

con la base de datos en el modelo relacional.

 25

Figura 7. Keyspace Cassandra

Fuente: Cassandra The Definitive Guide (Eben Hewitt 2010)

Como podemos observar en la figura las keyspace están formadas por ColumnFamily y estas a su

vez por Column.

2.8 CQL

CQL (Cassandra Query Language) es el lenguaje de comunicación con la base de datos Apache

Cassandra. Para poder interactuar con él accedemos al terminal (shell) CQL que recibe el nombre

cqlsh, y que se encuentra en la carpeta bin de la carpeta de Cassandra.

Con este lenguaje podemos realizar diferentes operaciones como insertar datos en una

ColumnFamily, crear una Keyspace o ColumnFamily con sus diferentes Column. También

podemos modificar datos, borrarlos o consultarlos. Aunque es un lenguaje bastante parecido a SQL

en sintaxis, la ejecución de las consultas no se parece en nada.

 26

2.9 Cuadro Comparativo

En el siguiente cuadro se observara un ejemplo que se realizó en un estudio meteorológico donde

se depositan datos de los distintos cambios del clima. En base el grafico muestra puntos donde se

utilizan bases de datos tradicionales y el tiempo que tarda en el depósito de datos. Se realizó una

prueba con bases de datos Cassandra NoSQL que lo llamaron Arbol R, en el cual el depósito de

datos tardo un menor tiempo al realizar la consulta en comparación a las bases de datos

tradicionales.

Figura 8. Cuadro comparativo

Fuente: Almacenamiento NoSQL de datos Meteorológicos (Universidad de Extremadura 2016)
 27

Capítulo III – Área de Aplicación

3. Definición

En el mundo cada año ocurren 330 millones de accidentes laborales, al igual que se diagnostican

160 millones de enfermedades por causa del trabajo, incluso se registran más de dos millones de

muertes por este mismo motivo. Un dato que también preocupa es que el 90% de estos suceden en

América Latina, sentenció la Organización Panamericana de la Salud (OPS). (Universia,2014)

La empresa constructora “G & D” es una empresa legalmente establecida, especializada en el rubro

de la construcción de viviendas y edificios multifamiliares con más de 20 años de experiencia en

el área. En la actualidad cuenta con un aproximado de 150 a 200 trabajadores entre personal

especializado: Ingenieros de control de calidad, Ingenieros civiles, Arquitectos, Administradores,

y mano de obra. La empresa cuenta con certificaciones ISO 9001 Gestión de la calidad, ISO 14001

Sistemas de Gestión ambiental, ISO 14006 Gestión ambiental del proceso de diseño y desarrollo,

que avalan los proyectos que realizan.

La empresa constructora “G & D” ha sufrido un incremento en los costos relacionados a

indemnizaciones y accidentes, así como una relativa baja en la producción, se realizó una auditoría

interna y se descubrió que el personal de la empresa trabaja con condiciones mínimas en cuanto a

normas y procedimientos de Seguridad e Higiene Industrial. Se detectó deficiencias en la ropa de

trabajo y equipo de protección personal, falta de conocimiento acerca de las reglas, normas y

procedimientos que precautelan un eficiente Programa de Seguridad. Por lo cual, esto causa un

malestar dentro de la empresa, existe el constante riesgo de sufrir algún tipo de accidente,

reduciendo la productividad de los trabajadores en sus respectivas áreas.

 28

3.1. Antecedentes

3.1.1 Antecedentes Generales

La finalidad del Programa de la Organización Internacional del Trabajo (OIT) intenta mejorar la

calidad de la vida laboral en todos sus aspectos mediante, la prevención de los accidentes del

trabajo y las enfermedades profesionales, la difusión y aplicación de los principios de la

ergonomía, el ordenamiento del tiempo de trabajo, el mejoramiento del contenido, la organización

de las tareas y de las condiciones de trabajo en general.

Enrique Núñez presidente de la sociedad Boliviana de Seguridad y Salud Ocupacional (SBSO)

informó, con datos del INE que de 2010 a 2012 el Ministerio de Trabajo registro 22.847 accidentes

laborales y 967 enfermedades ocupacionales, y considerando que cada uno tuvo al menos un día

de baja, las empresas gastaron más de 430.000 Bs al año por sus accidentados. (Eju, 2012).

El bajo conocimiento y capacitación del personal, falta del manejo adecuado de los riesgos

presentes en los ambientes laborales de sus empresas, sumado a la baja inversión de recursos

financieros, humanos para el control y mitigación de dichos riesgos. Un correcto manejo de estos

factores de riesgos dentro de la empresa permitirá tener un mejor ambiente de trabajo lo que se

traducirá en mayor eficiencia en los procesos y una reducción significativa de los costos.

(APONTE Benavides Diaz Medina, 2013)

La existencia de normas internacionales como las OHSAS va dirigida a la seguridad y salud de los

trabajadores define requerimientos para identificar, implementar y controlar un sistema de gestión

en seguridad y salud ocupacional basada en procesos y políticas que ayuden a mejorar la situación

de los trabajadores.

La seguridad e higiene industrial se construye en un medio ambiente de trabajo adecuado, con

condiciones de trabajo justas, donde los trabajadores y trabajadoras puedan desarrollar una
 29

actividad con seguridad y donde sea posible su participación para la mejora de las condiciones de

salud y seguridad.

Las diferentes entidades gubernamentales en nuestro país intentan aplicar procedimientos de

prevención y control de accidentes laborales proveyendo variedad de material informativo y de

registro de los mismos.

3.1.2 Antecedentes Especificos

La alta recurrencia de accidentes en el área de la construcción en nuestro país es debido a la falta

de información y del poco seguimiento de estos, conlleva una gran cantidad de accidentes desde

los más leves hasta fatales en el peor escenario.

El estudio de los accidentes en este sector de la construcción indica que no tienen origen en una

sola causa, por regla general cada accidente es el resultado de la concurrencia de varias causas

primarias. Entre ellas, podemos mencionar la permanencia del trabajador dentro de una zona

peligrosa, la ausencia o deficiencia de equipos de protección individual, el incumplimiento de

procedimientos e instrucciones de trabajo, además de la falta de control del cumplimiento del plan

de seguridad, falta de señalización en las diferentes áreas de trabajo, entre otros motivos.

Sin embargo, se ha tenido que pagar un alto precio por este crecimiento y actividades constantes.

Aunque resulta difícil obtener estadísticas exactas en una industria en la que muchos accidentes

pasan desapercibidos y no se denuncian, en nuestro país las fatalidades registradas y los accidentes

que causan pérdidas de tiempo trabajado, con frecuencia superan a los de cualquier otra industria
 30

3.1.3 Lienzo del modelo de negocio

Figura 9. Lienzo de Negocio

Fuente: Elaboración propia muestra los puntos que se toman en cuenta en un negocio
3.1.4 Arbol de Problema

Figura 10 Arbol de Problema

Fuente: Elaboración propia muestra las causas y efectos de un problema
 31

3.1.5 Modelo ER

Figura 11 Modelo Entidad Relación

Fuente: Elaboración propia modelo relacional de la empresa constructora G&D

 32

Capítulo IV – Marco Práctico

4. Objetivo

Este capítulo explica cómo utilizar el modelado de datos basado en consultas en cassandra. El

modelado de datos NoSQL es un proceso que identifica entidades así como las relaciones entre

ellas. Se puede usar para determinar patrones al acceder a los datos, así como a los tipos de

consultas que se realizarán. Al hacerlo, revela cómo se organizan y estructuran los datos junto con

la forma en que se diseñan y crean las tablas de las bases de datos. Es importante tener en cuenta

que la indexación de los datos puede degradar el rendimiento de las consultas. Por lo tanto,

entender la indexación es esencial en el proceso de modelado de datos.

El modelado de datos en Cassandra se centra en el enfoque basado en consultas mediante el cual

las consultas específicas son la clave para organizar los datos. Permítanme primero explicar

rápidamente estos términos: las consultas recuperan datos de tablas y el esquema define cómo se

organizan los datos en la tabla. Por lo tanto, un diseño de base de datos basado en consultas facilita

una lectura y escritura de datos más rápida, es decir, cuanto mejor sea el diseño del modelo, más

rápido se escribirán y leerán los datos.

Ahora, primero, debemos crear un modelo conceptual de datos que definirá todas las entidades

conocidas, relaciones, tipos de atributos, claves, cardinalidad y otras restricciones. Este modelo de

datos debe crearse en colaboración con las partes interesadas y los analistas de negocios. Por

ejemplo, un modelo conceptual de datos podría presentarse como diagrama ER.

El siguiente paso es el modelado de datos lógicos. Aquí, el modelo conceptual de datos se asigna a

un modelo de datos lógico basado en consultas que se definen en un flujo de trabajo de la

aplicación. El modelo de datos lógicos corresponde a un espacio de claves donde los esquemas de

tablas definen las columnas, así como las claves primarias, de partición y de agrupamiento. Por lo
 33

tanto, el enfoque basado en consultas proporciona un modelo de datos lógicos utilizando principios

de modelado de datos, reglas de mapeo y patrones de mapeo.

Aquí hay algunas reglas para los predicados de consulta que aseguran estabilidad y eficiencia:

 Solo las columnas de clave principal se deben usar en el predicado de consulta

 Todas las columnas de clave de partición en el predicado de consulta deben tener valores

distintos

 Las columnas de clustering pueden omitirse en el predicado de consulta

 Todas las claves de partición deben usarse en el predicado

Además de estas reglas de predicado de consulta, existen principios de modelado de datos

adicionales para mapear a modelos de datos lógicos. Es importante tener en cuenta que la violación

de estos principios y reglas afectará la capacidad de admitir los requisitos de consulta y puede

conducir a la pérdida de datos y la degradación del rendimiento.

Aquí están los principios fundamentales del modelado de datos lógicos:

 Conozca sus datos, en particular las claves del tipo entidad y relación que se deben

preservar y utilizar para organizar los datos correctamente.

 Conozca sus consultas de modo que todas las columnas se conserven en el nivel lógico.

 Habilite la anidación de datos para fusionar varias entidades juntas según un criterio

conocido.

 Minimice la duplicación de datos para garantizar la eficiencia de espacio y tiempo.

 Utilice atributos de búsqueda de igualdad para correlacionar con las columnas de prefijo

de la clave principal

 Utilice atributos de búsqueda de desigualdad para correlacionar con la columna clave de

clústeres de tabla.
 34

 Utilice atributos de ordenación para correlacionar columnas de clave de clúster con orden

de agrupamiento ascendente o descendente.

 Utilice los tipos de atributos clave para correlacionar con columnas de clave principal e

identificar de manera única las filas de la tabla.

Finalmente, debemos analizar y optimizar este modelo de datos lógico para crear el modelo de

datos físicos. Los principios de modelado, las reglas de mapeo y los patrones de mapeo

mencionados anteriormente aseguran un esquema lógico correcto y eficiente. Sin embargo, la

eficiencia aún se puede ver afectada por las limitaciones del motor de base de datos o los recursos

de clúster finitos, como los tamaños de partición de tabla típicos y los factores de duplicación de

datos. Hay algunas técnicas de optimización estándar que se pueden usar, incluida la división de

particiones, los índices invertidos, la agregación de datos y la optimización de acceso a datos

simultáneos. Estos métodos se pueden utilizar para optimizar el modelo de datos físicos, aunque

no cubriremos este tema en detalle.

Este es el camino a seguir para habilitar el modelado de datos basados en consultas en Apache

Cassandra.

4.1 Análisis y Validación

En este punto se toman 5 principales procedimientos a tomar en cuenta para crear el depósito o

lectura de datos en Cassandra los cuales son.

 Las lecturas atacan a una sola partición.

 La escritura o sobre escritura.

 Tamaño de particiones la cual se calcula según la fórmula: Nº=Nºfilas

X (Nºcol – Nºpk – Nºestatico) + Nºestatico < 1billon

 Duplicación de datos (batches).

 35

 Se presentan casos de join para los cuales se crean nuevas tablas.

4.2 Ejemplos

4.2.1 Personal

Encuéntrame el personal por su id, de la empresa S&D, para lo cual primero se tiene la tabla

Personal del modelo ER.

Figura 12. Tabla Personal

Fuente: Elaboración propia con datos del personal

Una vez se tiene la tabla se procede a identificar la llave primaria el cual no solo nos sirve para

identificar al usuario si no también nos servirá como identificador de partición. Es decir que el

dato personal_id representa la llave primaria y clave de partición, los demás datos son

almacenados como datos simples.

 36

Figura 13. Selección de datos Personal

Fuente: Elaboración propia

El siguiente paso es realizar las 5 validaciones correspondientes mencionadas anteriormente.

Figura 14. Validación de tabla

Fuente: Elaboración propia

 37

Luego se pasa a la implementación física del modelo donde se muestra la creación de la tabla la

consulta a realizar la búsqueda.

Figura 15. Creación de tabla personal con Cassandra

Fuente: Elaboración propia

4.2.2 Usuario

En este ejemplo se toma que los usuarios se identifican en el sistema de forma única con su usuario

y contraseña una vez dentro el sistema se usa el id usuario.

Para ello tomaremos el ejemplo anterior y agregaremos la tabla User

 38

Figura 16. Tabla usuario

Fuente: Elaboración propia

Una vez que se tiene la tabla se procede a identificar la llave primaria la cual no solo nos sirve para

identificar al usuario si no también nos servirá como identificador de partición. Es decir que el

dato user_name y user_password representa la llave primaria y clave de partición, los demás

datos son almacenados como datos simples.

Figura 17. Selección de datos tabla usuario

Fuente: Elaboración propia

 39

El siguiente paso es realizar las 5 validaciones correspondientes mencionadas anteriormente.

Para el caso de Q1 ya se lo analizo en el anterior ejemplo es por ello que solo se realiza la validación

del Q2.

Figura 18. Validación de tabla

Fuente: Elaboración propia

Luego se pasa a la implementación física del modelo donde se muestra la creación de la tabla la

consulta. Para Q1 ya se explicó en el anterior ejemplo solo se mostrara para Q2.

Figura 19. Creación de tabla usuario con Cassandra

Fuente: Elaboración propia

 40

Adicionalmente se debe crear el batch ya que cada que se realice esta solicitud se debe escribir en

dos tablas la de personal, user_by_login, ello se realiza de la siguiente manera.

BEGIN BATCH

INSERT INTO personal (personal_id, …………) VALUES (……………) IF NOT EXITS;

INSERT INTO user_by_login (user_name, user_password, personal_id ….,) VALUES (…….)

APPLY BATCH

Figura 20. Batch

Fuente: Elaboración propia

Solo se ejecutara todo solo si no existe el usuario o personal identificado por el personal_id, con

ello garantizamos la integridad de los datos.

De esa forma se realizan la creación de tablas con Cassandra para el caso del sistema de seguridad

industrial.
 41

CONCLUSIONES

 El estudio realizado con la bases de datos NoSQL, en concreto con Cassandra, aplicando

a nuestro Sistema de Seguridad Industrial, ha sido muy importante, ya que se presenta

como una solución a la problemática de los grandes bancos de datos y tiempos de

respuesta, ya que al sistema siempre se ingresan una cantidad de datos considerable y los

tiempos de escritura con cassandra optimizan los recursos, aún cuando la forma de modelar

dista bastante del modelo clásico relacional que todos conocemos.

 Las herramientas para administrar nuestros Keyspaces, clúster y nodos nos ayudan a

mantener un orden al momento de desarrollar y utilizar nuestra aplicación.

 El lenguaje CQL nos provee funciones bastante parecidas a lo que estamos acostumbrados

con el SQL, haciendo más fácil el acostumbrarse a utilizar las diversas funcionalidades de

esta tecnología.

 Cassandra, debido a sus cualidades se puede usar en muchos aspectos fuera del Big Data.

Lo ideal es tener claro su uso para saber sacarle el máximo partido, contemplando así las

consultas, el tipo de diseño de la base de datos ya que dependiendo de cómo se realice el

diseño podrá aprovechar mejor las ventajas de esta potente base de datos distribuida.
 42

RECOMENDACIONES

Si la intención es realizar muchos joins (uniones) entre diferentes entidades quizás Cassandra no

es la tecnología NoSQL que se recomienda. Ya que entre sus principales desventajas que se puede

tener es que no se tienen join a cambio se tiene mayor velocidad.

Como también no permite ordenar en tiempo de consulta. No recomendable en proyectos o

sistemas donde la información de columnas es constantemente cambiadas es decir son editadas en

tiempos cortos (minutos, segundos). Esto se debe a la replicación y sobre escritura de datos en los

distintos servidores o nodos.

 43

BIBLIOGRAFÍA

R. Cattell, (2010) "Scalable SQL and NoSQL Data Stores," ACM SIGMODRecord, vol. 39.

Leavitt, N. (2010). Will NoSQL databases live up to their promise? Computer.

Ros, A. (2017). Primeros pasos con Cassandra. Fecha de consulta: 10 de Agosto 2018. Recuperado

de: https://geekytheory.com/primeros-pasos-con-apache-cassandra/

Ramírez, F. (2017). Que es base de datos Cassandra Big Data. Fecha de consulta: 11 de Agosto

2018. Recuperado de: https://fireosoft.com.co/blogs/que-es-la-base-de-datos-apache-cassandra/

Gracia, L. (2012). Un poco de Cassandra. Fecha de consulta: 11 de Agosto 2018. Recuperado de:

https://unpocodejava.com/2012/07/12/un-poco-de-cassandra/

Hendrix, G. (2015). Modelo de datos Cassandra. Fecha de consulta: 17 de Agosto 2018.

Recuperado de: https://elmanadelainformatica.wordpress.com/2015/06/09/apache-cassandra-

modelo-de-datos/

Zaforas, M. (2016). Cassandra la dama de las bases de datos NoSQL. Fecha de consulta: 18 de

Agosto 2018. Recuperado de: https://www.paradigmadigital.com/dev/cassandra-la-dama-de-las-

bases-de-datos-nosql/

Gilmore, E. (2011). Clúster de dos Data Center. Fecha de consulta: 18 de Agosto 2018. Recuperado

de: https://www.datastax.com/dev/blog/deploying-cassandra-across-multiple-data-centers

Pablo, J. (2018). Definición claves clúster y partición Cassandra. Fecha de consulta: 18 de Agosto

2018. Recuperado de:https://www.elconspirador.com/2018/01/29/definicion-claves-cluster-y-

particion-apache-cassandra-parte-1
44