PFC

PROYECTO FIN DE CARRERA
Herramienta de análisis para Big Data aplicada a
fuentes de datos masivos
REALIZADO POR:
Carlos Jesús Fernández Basso
DIRIGIDO POR:
María José Martín Bautista
Manolo Pegalajar Cuéllar
DEPARTAMENTO:
Departamento de Ciencias de la Computación
e Inteligencia Artificial

Índice
CARLOS JESÚS FERNÁNDEZ BASSO 1
Índice
Índice.................................................................................................................. 1
Índice de ilustraciones........................................................................................ 5
1 Figuras...................................................................................................................5
2 Ecuaciones.............................................................................................................6
3 Tablas ....................................................................................................................6
4 Gráficas..................................................................................................................6
Resumen............................................................................................................ 8
Capítulo I: Introducción ................................................................................. 11
1 Justificación..........................................................................................................12
2 El problema del Big Data......................................................................................13
3 Cómo podemos tratar estos datos........................................................................15
3.1 Optimizando el almacenamiento de Big Data: Hadoop ..................................16
Capítulo II: Bases de Datos: SQL versus NoSQL ........................................ 19
1 Antecedentes .......................................................................................................19
1.1 Un poco de historia........................................................................................20
1.2 Algunas características importantes sobre las bases de datos ......................21
2 Bases de datos relacionales (SQL) ......................................................................23
2.1 Problemática..................................................................................................24
2.2 Ejemplos de Bases de Datos Relacionales....................................................25
3 Bases de datos NoSQL........................................................................................26
3.1 ¿Por qué aparecen los sistemas NoSQL? .....................................................26
3.2 Historia ..........................................................................................................27
3.3 Modelo de datos ............................................................................................28
3.4 Gestores de Bases de Datos NoSQL.............................................................30
3.5 Otros SGBD NoSQL ......................................................................................32
3.6 Comparación entre Bases de Datos NoSQL..................................................36
3.7 Discusión sobre la elección de la base de datos............................................39
4 MongoDB .............................................................................................................39

Índice
4.1 Map Reduce ..................................................................................................39
4.2 Auto sharding.................................................................................................40
4.3 Herramientas .................................................................................................40
4.4 Conclusiones sobre las herramientas de gestión de MongoDB.....................45
Capítulo III: Herramienta de análisis de eficiencia de BD SQL versus BD
NoSQL ............................................................................................................. 47
1 Casos de uso de la aplicación..............................................................................48
1.1 Caso de uso: Conectar Bases de datos.........................................................49
1.2 Caso de uso:Análisis de insert.......................................................................50
1.3 Caso de uso:Análisis de insert y delete..........................................................51
1.4 Caso de uso:Análisis de Query......................................................................52
1.5 Caso de uso:Análisis de Update ....................................................................53
2 Arquitectura de la herramienta .............................................................................54
3 Diseño de la herramienta .....................................................................................55
4 Análisis de eficiencia entre MySQL y MongoDB...................................................56
4.1 Inserciones ....................................................................................................56
4.2 Consultas.......................................................................................................57
4.3 Índices ...........................................................................................................61
4.4 Borrados........................................................................................................61
4.5 Actualizaciones..............................................................................................62
5 Discusión sobre los resultados obtenidos.............................................................62
Capítulo IV: Migración MySQL to MongoDB................................................ 65
1 Diseño de los esquemas ¿Cómo es el cambio de diseño?...................................65
2 Traducción de elementos .....................................................................................66
3 Claves externas ...................................................................................................70
3.1 Referencias....................................................................................................70
3.2 Documentos embebidos ................................................................................71
3.3 Diferentes objetivos de diseño .......................................................................72
4 Herramientas migración .......................................................................................72
4.1 Integración Pentaho.......................................................................................72
4.2 Aplicación de administración..........................................................................73

Índice
Capítulo V: Análisis de eficiencia de gestión de BigData en una aplicación
de reconocimiento gestual............................................................................ 75
1 Herramienta de análisis de eficiencia de procesos de análisis de BigData...........75
2 Aplicación de reconocimiento gestual...................................................................76
3 Casos de uso de la aplicación..............................................................................78
3.1 Caso de uso: Conectar bases de datos .........................................................79
3.2 Caso de uso: Importar datos..........................................................................80
3.3 Caso de uso: Extraer datos............................................................................81
3.4 Caso de uso: Realizar análisis mediante DTW ..............................................82
3.5 Caso de uso: Consultar estadísticas..............................................................83
4 Arquitectura de la aplicación ................................................................................84
5 Diseño de la aplicación.........................................................................................84
6 Estructuras de las bases de datos utilizadas........................................................85
7 Sensor, fuente de información..............................................................................88
8 Procesamiento de los archivos .mat.....................................................................90
9 Pre-procesamiento de los datos...........................................................................92
10 Alineación de series en el tiempo con DTW .......................................................93
11 Distancias utilizadas...........................................................................................95
12 Estructura completa de la aplicación ..................................................................96
13 Análisis de los resultados...................................................................................96
13.1 Velocidad.....................................................................................................96
13.2 Tamaño .......................................................................................................98
14 Análisis de bondad de las medidas de distancia y dimensionalidad ...................99
Conclusiones................................................................................................ 107
Bibliografía ..................................................................................................... 109
Anexo 1: Glosario de términos ....................................................................... 113
Anexo 2: Comparación bases de datos NoSQL............................................. 117
Anexo 3: Instalación Bases de datos ............................................................. 123
1 Instalación de las bases de datos.......................................................................125
1.1 MySQL.........................................................................................................125

Índice
1.2 MongoDB.....................................................................................................126
2 Instalación de Gestores de Base de datos .........................................................127
2.1 MongoVUE ..................................................................................................127
Anexo 4: Manuales de usuario....................................................................... 133
1 Herramienta de Análisis de eficiencia de BD SQL versus BD NoSQL ................137
1.1 Objetivos de la herramienta .........................................................................137
1.2 Utilización de la herramienta........................................................................138
2 Herramienta de análisis de eficiencia de gestión de BigData con aplicación de
reconocimiento gestual .........................................................................................136
2.1 Objetivos de la Herramienta.........................................................................143
2.2 Utilización de la Herramienta .......................................................................144

Índice
Índice de ilustraciones
1 Figuras
Figura 1 Evolución del coste por GB..........................................................................13
Figura 2 Características Big Data ..............................................................................14
Figura 3 Aplicaciones Big Data..................................................................................16
Figura 4 historia modelos de datos ............................................................................20
Figura 5 Teorema CAP..............................................................................................21
Figura 6 Historia bases de datos NoSQL...................................................................27
Figura 7 Tipos de modelos NoSQL............................................................................28
Figura 8 Ejemplo modelo orientado a columnas ........................................................30
Figura 9 Interfaz de h. de análisis de eficiencia..........................................................47
Figura 10 diagrama de casos de uso H. análisis de eficiencia ...................................48
Figura 11 Arquitectura aplicación análisis de eficiencia .............................................54
Figura 12 Diagrama de clases h. análisis de eficiencia..............................................55
Figura 13 Esquema MongoDB...................................................................................66
Figura 14 Esquema relacional ...................................................................................66
Figura 15 Equivalencia entre operadores de consulta................................................68
Figura 16 Esquema migración MySQL MongoDB......................................................70
Figura 17 Modelo de documentos orientado a referencias.........................................71
Figura 18 Modelo de documentos orientado a subdocumentos .................................71
Figura 19 Arquitectura básica de la herramienta del análisis de eficiencia de procesos
de análisis para BigData.............................................................................................76
Figura 20 Arquitectura detallada de la herramienta del análisis de eficiencia de
procesos de análisis para BigData..............................................................................77
Figura 21 Diagrama de casos de uso h. minería de datos .........................................78
Figura 22 Arquitectura aplicación reconocimiento de gestos......................................84
Figura 23 Diagrama de clases h. reconocimiento gestual..........................................85
Figura 24 Diagrama E/R para el almacenamiento de gestos .....................................86
Figura 25 Estructura MongoDB Subdocumentos .......................................................87
Figura 26 Estructura MongoDB referencias ...............................................................87
Figura 27 Sensor kinect.............................................................................................88
Figura 28 Datos del skeleton .....................................................................................90
Figura 29 Ejemplo de archivo de datos para la aplicación .........................................91
Figura 30 Ejemplo jerarquía puntos skeleton .............................................................92
Figura 31 Jerarquía de los puntos del skeleton..........................................................92
Figura 32 Diferencia entre Distancia euclídea y alineamiento temporal .....................93
Figura 33 Funcionamiento del DTW...........................................................................94
Figura 34 Matriz funcionamiento DTW.......................................................................94
Figura 35 Web descarga MySQL.............................................................................125

Índice
Figura 36 Web descarga MongoDB.........................................................................126
Figura 37 Descarga MongoVUE ..............................................................................128
Figura 38 Conectar MongoVUE ...............................................................................128
Figura 39 Formulario conexión mongoVUE .............................................................129
Figura 40 Visor de colecciones MongoVUE .............................................................130
Figura 41 visión de una colección en MongoVUE ...................................................131
Figura 42 Añadir colección MongoVUE....................................................................131
Figura 43 Interfaz principal reconocimiento gestual .................................................143
Figura 44 Señalización botones de control ..............................................................144
Figura 45 Interfaz de conexión.................................................................................144
Figura 46 Interfaz de insertar...................................................................................145
Figura 47 Interfaz de búsqueda de archivos ............................................................145
Figura 48 Visión de estadísticas ..............................................................................146
2 Ecuaciones
Ecuación 1 Ecuación DTW .........................................................................................94
Ecuación 2 Distancia de chebyshev............................................................................95
Ecuación 3 Distancia euclídea....................................................................................95
3 Tablas
Tabla 1 Tabla de características técnicas de BD NoSQL............................................38
Tabla 2 Equivalencia Relacional MongoDB ................................................................66
Tabla 3 Comparativa análisis de bondad ..................................................................102
Tabla 4 Matriz de confusión d. euclídea....................................................................103
Tabla 5 Matriz de confusión d. chebyshev ................................................................104
Tabla 6 Matriz de confusión d. chebyshev reducción de dimensionalidad.................105
Tabla 7 Matriz de confusión d. euclidea reducción de dimensionalidad ....................106
Tabla 8 Comparativa BD NoSQL (1).........................................................................119
Tabla 9 Comparativa BD NoSQL (2).........................................................................120
Tabla 10 Comparativa BD NoSQL (3).......................................................................122
4 Gráficas
Gráfica 1 Tiempo inserciones en las bases de datos ..................................................56
Gráfica 2 Espacio ocupado en las bases de datos......................................................57
Gráfica 3 Tiempos test 1............................................................................................58

Índice
Gráfica 6 tiempos test 4.............................................................................................59
Gráfica 8 tiempo de creación de indices ....................................................................61
Gráfica 9 Tiempos Delete ...........................................................................................61
Gráfica 10 Tiempos Update .......................................................................................62
Gráfica 11 Tiempo de extracción de datos.................................................................97
Gráfica 12 Tiempo de Inserción de datos...................................................................97
Gráfica 13 Comparativa de tamaños de las bases de datos .......................................98
Gráfica 14 Comparación de la reducción de dimensionalidad en la d. euclídea.......100
Gráfica 15 Comparación de la reducción de dimensionalidad en la d. de chebyshev
.................................................................................................................................100

Resumen
Resumen
La cantidad de datos masivos estructurados y no estructurados en los
sistemas de información actuales ha tenido un crecimiento vertiginoso en
estos últimos años. Uno de los grandes objetivos de las empresas hoy día
es poder almacenar, gestionar y explotar dichos datos con el objetivo de
maximizar los beneficios y ser más eficientes.
Por ello, los avances de la tecnología abren las puertas hacia un nuevo
enfoque de entendimiento y toma de decisiones obtenidos a partir de estas
enormes cantidades de datos. Uno de los principales problemas de esta
gestión de los datos es que su almacenamiento suele ser en bases de datos
SQL (normalmente basadas en el paradigma relacional), cuya eficiencia en
el manejo de datos masivos suele ser bastante deficiente.
Un ejemplo de este tipo de problemas es el procesamiento de datos masivos
provenientes de sensores. Estos dispositivos captan diferentes tipos de
datos del entorno en tiempo real, por lo que generan grandes cantidades de
datos desestructurados. Para poder procesar y analizar estos datos,
necesitamos nuevos modelos de base de datos que nos permitan
almacenarlos y manejarlos de manera más rápida y eficiente.
Para este procesamiento de datos masivos surge un nuevo paradigma en
las bases de datos denominado NoSQL (“not only SQL”). Estas bases de
datos se basan en la pérdida de algunas características de las bases de
datos relacionales por ejemplo la atomicidad, consistencia, aislamiento y
durabilidad, con el objetivo de poder tener otras prestaciones como la no
estructuración de sus datos, altas capacidades de escalabilidad,
procesamiento paralelo… Gracias a la mejora de estas características estas
bases de datos soportan mejor el almacenamiento de los datos masivos
además de su procesamiento y análisis.

Resumen
Es por esto que, en el presente trabajo, estudiaremos estas nuevas
posibilidades de almacenamiento y gestión de datos, analizando las bases
de datos NoSQL más relevantes en la actualidad y comparándolas con los
sistemas de datos relacionales.
Basándonos en la herramienta más eficiente obtenida de la comparativa,
hemos implementado una aplicación de análisis de datos masivos (Big
Data). Dicha herramienta explotará los datos provenientes del
reconocimiento gestual a partir del dispositivo multi-sensor Kinect.
Para dicho reconocimiento gestual, utilizaremos el algoritmo DTW (Dynamic
Time Warping), implementando y comparando dos distancias diferentes: la
Euclidea y la de Chebyshev. Dicho algoritmo se probará con diferentes
dimensionalidades de los datos para comparar su bondad.
Además, haremos un estudio complementario de comportamiento de los dos
tipos de bases de datos (SQL y NoSQL) para el procesamiento de dichos
datos para demostrar qué paradigma tiene mejor comportamiento en el
procesamiento de datos masivos.
Las aplicaciones desarrolladas, tanto la de análisis de Big Data como la de
la comparativa en la eficiencia de las bases de datos son abiertas y flexibles,
pudiéndose integrar y extender a otros sistemas gestores de bases de datos
diferentes y datos masivos procedentes de otras fuentes de datos.

Resumen

Capítulo I: Introducción
Introducción
Los seres humanos estamos creando y almacenando información
constantemente y, cada vez más, en cantidades astronómicas. Además del
gran volumen de información, existe una enorme variedad de datos que pueden ser
presentados a través de diversos medios, por ejemplo, audio, video, sistemas GPS,
dispositivos móviles, Web 3.0, redes sociales, sensores etc. A estos problemas se une
que las aplicaciones para el uso y explotación de estos datos de sensores requieren una
capacidad de respuesta que no siempre está disponible.
Los nuevos avances de la tecnología abren las puertas hacia un nuevo enfoque
de entendimiento y toma de decisiones. No obstante, para describir la enorme cantidad
de datos (no estructurados y semi-estructurados) de la que hablamos, se requeriría
demasiado tiempo y sería muy costoso cargarlos a una base de datos relacional para
su análisis. De manera que, el concepto de Big Data, se aplica para toda aquella
información que no puede ser procesada o analizada utilizando procesos o herramientas
tradicionales.

Como posibles opciones de almacenamiento encontramos diferentes
paradigmas: el tradicional y asentado modelo relacional y el nuevo paradigma NoSQL,
en el que perdemos el teorema ACID para poder almacenar datos no estructurados y
poder tratarlos de manera más eficiente. Compararemos en este proyecto el rendimiento
de ambas bases de datos con el fin de comprender qué mejoras nos proporciona el
nuevo paradigma. Dichas mejoras se centrarán en la posibilidad de procesar grandes
cantidades de datos no estructurados eficientemente con la principal idea del
procesamiento en paralelo.
Uno de los ejemplos más claros de este tipo de problemas es el análisis de datos
de sensores digitales como pueden ser: sensores de automóviles, medidores eléctricos,
veletas, anemómetros, dispositivos de movimiento, etc. los cuales nos ofrecen la
posibilidad de extraer información de nuestro entorno y de nosotros mismos. Por ello,
ofrecen un gran interés para extraer información y así poder mejorar, por ejemplo,
nuestra vida o la eficiencia de una fábrica en la industria. Para ello, necesitaremos poder
guardar datos no estructurados y, además, poder analizarlos y extraer información de
forma eficiente.
1 Justificación
El objetivo de este proyecto es el estudio de la eficiencia del paradigma relacional
y del nuevo paradigma de bases de datos NoSQL. Este estudio estará centrado en el
uso de estas bases de datos en relación con el BigData y, en concreto, datos masivos
de sensores.
De esta forma, cabe señalar que, dentro de nuestro estudio, veremos las
alternativas relacionales que tenemos, así como el NoSQL, en el cual nos centraremos
más, comentando lo tipos de bases de datos existentes en este paradigma y
comparándolas entre sí.
Además, se realizará una herramienta de minería de datos con el objetivo de
extraer información para el reconocimiento gestual. En esta aplicación compararemos
la implementación realizada mediante MongoDB y MySQL.

2 El problema del Big Data
Cada día generamos indigentes volúmenes de datos, tan enormes que las bases
de datos actuales se quedan obsoletas, y no solo por la cantidad de datos, sino porque
estos datos generados no tienen una estructura que bases de datos actuales nos
permitan almacenar.
La digitalización de nuestros días ha acelerado el crecimiento de los datos dentro
de las empresas u organizaciones. Podemos ver cómo en Facebook o Twitter se
escriben comentarios cada día, o cómo se suben videos a YouTube. Pero, no solo en
las redes sociales se generan datos, también podemos ver en los sensores de las
fábricas, en las imágenes de los satélites de la NASA, en los GPS de los coches, móviles
y dispositivos electrónicos, etc. El mundo está cambiando, así como que todo lo que nos
rodea recoge información de manera constante.
A medida que los formatos digitales avanzan, volviéndose más complejos y
sofisticados, se crean más datos. Por ejemplo, un video de alta definición ocupa 2000
veces más bytes que una página de texto. La creación de esta información nueva
propone un nuevo impulso para el almacenamiento de datos. Podemos ver a
continuación cómo han cambiado los costes de un Gb de datos:
Figura 1 Evolución del coste por GB
1981 1987 1990 1994 1997 2000 2004 2010
Precio 300000 50000 10000 1000 100 10 1 0,1
0
50000
100000
150000
200000
250000
300000
350000
Precio$
Coste por GB

Gracias a la enorme reducción de los precios de los costes del almacenamiento
de datos podemos almacenar cada día más datos a un coste menor. Sin embargo, no
es solo la capacidad de almacenamiento lo que define al fenómeno del BigData, también
se plantean retos a la hora de usar e interpretar los grandes conjuntos de datos.
Para entender este concepto analizaremos sus principales características:
 Volumen: el crecimiento exponencial
de los volúmenes de datos es una
cuestión fundamental, estando
impulsado por el crecimiento de
internet y las redes de
comunicaciones entre dispositivos.
 Variedad: describe el número de los
diferentes tipos de datos. Además,
cabe señalar que el hecho de
interpretar y analizar diferentes tipos de datos puede generar grandes ventajas.
Por ejemplo, Facebook almacena grandes cantidades de datos sobre sus
usuarios, siendo estos de diferente tipo (sexo, edad, libros favoritos…). Además,
el hecho de marcar “me gusta”, supone la interpretación de los gustos de sus
usuarios de cara a la obtención de información relevante.
 Velocidad: se refiere a la vida útil de los datos. Como podemos entender, no
tiene mucho sentido guardar datos desactualizados, de los cuales no podamos
extraer información útil.
Se espera que este fenómeno impulse toda una generación de empresas
informáticas, partiendo del hecho de que es el sector que más crece en el mundo.
Así mismo, cabe señalas que empresas como IBM, Microsoft, ORACLE o SAP
han invertido mucho en centros de procesamiento de datos para interpretar Big Data.
Es por ello que la capacidad tecnológica con la que cuentan estas empresas es
impresionante, siendo capaces de generar resultados beneficiosos para las empresas
Figura 2 Características Big Data

que contratan sus servicios. Los datos extraídos de sensores en motores de avión o
centrales eléctricas, podrían, por ejemplo, estudiarse para consumir menos combustible,
en el caso de los aviones, o generar de manera más eficiente electricidad, en el caso de
las centrales. Por todo lo dicho estas empresas están muy bien posicionadas para
desarrollar lucrativos negocios de consultoría basados en la capacidad de analizar
grandes conjuntos de datos.
Las empresas de estudios de mercado también se quieren hacer un hueco en
esta área. Así, internet ha incrementado el número de métodos para llegar a la audiencia
y comercializar productos, ya que en cada página web se queda guardado cada clic que
se hace. Es por ello, que muchas empresas de marketing están aprovechando las
indigentes cantidades de datos disponibles a través de líderes en búsquedas de internet
y redes sociales como son Google o Facebook. En la Figura 3 Aplicaciones Big Data
se recogen aquellos aspectos de los que salen todos los datos nuevos y masivos:
3 Cómo podemos tratar estos datos
En este apartado vamos a hacer un pequeño apunte sobre cómo tratar grandes
cantidades de datos, comentando de qué forma optimizar el procesamiento y
tratamiento de dichos datos de forma eficiente.
“Hay gran cantidad de datos disponibles. Lo que escasea
es la capacidad de extraer conocimiento de ellos”
HARIAN, V. economista jefe de Google

Figura 3 Aplicaciones Big Data
3.1 Optimizando el almacenamiento de Big Data: Hadoop
Hadoop [1] es un proyecto de código abierto administrado por la Fundación
Apache Software; un framework open source para el proceso en batch de datos a gran
escala.
Hadoop, fue diseñado para resolver el análisis rápido y fiable tanto de los datos
estructurados como de los datos complejos. Como resultado, muchas empresas
implementan Hadoop junto con sus bases de datos relacionales y sistemas OLAP, lo
que les permite combinar conjuntos de datos antiguos y nuevos de forma potente.
Técnicamente, Hadoop consta de dos servicios principales: almacenamiento de
datos fiable, utilizando el Sistema de Archivos Distribuidos de Hadoop (HDFS) y un
procesamiento de datos en paralelo de alto rendimiento, que usa una técnica llamada
MapReduce.
•Clics
•Post en redes sociales
•Twits
Web y redes sociales
•Reconocimiento facial
•Genética
Biometrics
•Señales GPS
•Sensores plataformas petroleso electricas
•RFID
Máquina -Máquina
•Llamadas telefónicas
•Email
•Informes médicos
Humanos
•Registros facturación
•Registros médicos
Grandes transacciones de datos

Hadoop se ejecuta en una colección de productos básicos y servidores no
compartidos. De esta forma, podemos añadir o eliminar servidores en un cluster Hadoop
a voluntad, detectando y compensando los problemas de hardware o del sistema en
cualquier servidor. Así mismo, puede ejecutar procesos a gran escala y de alto
rendimiento, a pesar de los fallos o cambios de sistema.
Originalmente, fue desarrollado por las empresas dominantes en Web, como
Yahoo y Facebook, siendo actualmente utilizado en numerosos campos, desde las
finanzas y la tecnología, hasta el gobierno, instituciones de investigación y otros
mercados con datos significativos. Por último, hemos de señalar que con Hadoop, las
empresas pueden explorar datos complejos por medio de análisis personalizados a la
medida de su información y sus necesidades.

Capítulo II: Bases de Datos: SQL versus NoSQL
Bases de Datos: SQL versus NoSQL
1 Antecedentes
Las bases de datos surgen de la problemática de almacenar datos y utilizar estos
de forma eficiente. En este apartado comentaremos los modelos de datos que han
surgido, así como los sistemas de gestión de bases de datos más usados.
Definición de Base de datos [2]:
“Fondo común de información almacenada en una
computadora para que cualquier persona o programa autorizado
pueda acceder a ella, independientemente se du procedencia y
del uso que haga”.
Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos
interrelacionados y un conjunto de programas para acceder a dichos datos. La colección
de datos, normalmente denominada base de datos, contiene información relevante para
una empresa.

El objetivo principal de un SGBD es proporcionar una forma de almacenar y
recuperar la información de una base de datos, de manera que sea tanto práctica como
eficiente. Los sistemas de bases de datos se diseñan para gestionar grandes cantidades
de información. La gestión de los datos implica tanto la definición de estructuras para
almacenar la información, como la provisión de mecanismos para la manipulación de la
información. Además, los sistemas de bases de datos deben proporcionar la fiabilidad
de la información almacenada, a pesar de las caídas del sistema o de los intentos de
acceso sin autorización.
1.1 Un poco de historia
En este apartado se hace un breve repaso histórico sobre los modelos de datos
con el objetivo de ver la evolución que dichos modelos han sufrido a lo largo de la
historia.
Figura 4 historia modelos de datos
Además, cabe señalar que podemos encontrar diferentes tipos de datos
dependiendo de su estructura:
Jerárquico(IMS):finales de la década 1960 y década 1970
Red (CODASYL): década 1970
Relacional: década 1970 y principios de 1980
Entidad Relación: década 1970
Relacional extendido: década 1980
Semántico: finales década 1970 y década 1980
Orientado a objetos: finales década 1980 y principios de la década de
1990
Objeto relacional: fínales de la década 1980 y principios década 1990
Semiestructurado: finales década 1990

 Estructurados: cuentan con una distribución concreta y están organizados
siguiendo unas pautas determinadas y rígidas.
 Semi-estructurados: siguen una distribución pero sin pautas completamente
determinadas ni rígidas.
 No estructurados: no siguen ninguna distribución.
1.2 Algunas características importantes sobre las bases de datos
A lo largo del siguiente apartado se recogen los diferentes rasgos que podemos
encontrar en las Bases de Datos, con el fin de comprender mejor éstas así como la
comparación entre ellas.
1.2.1 Teorema CAP
Este teorema CAP [3] nos dice que es imposible para un sistema computacional
distribuido ofrecer simultáneamente las 3 características siguientes:
 Consistencia (Consistency): todos
los nodos tienen siempre la misma
versión de los datos.
 Disponibilidad (Availability): todos los
nodos tienen siempre consistencia
de sus lectura/escrituras, es decir, la
garantía de que cada petición a un
nodo reciba una confirmación de si
ha sido o no resuelta
satisfactoriamente.
 La tolerancia a fallos (Partition
Tolerance): el sistema sigue
funcionando aunque haya fallos en
algunos nodos.
Figura 5 Teorema CAP

De tal forma que:
o Los sistemas relacionales se sitúan entre C y A: generalmente el sistema en
entornos distribuidos (clústeres) cuando se de una actualización los datos
estarán bloqueados (no disponibles) mientras no se den los cambios en todos
los nodos de trabajo.
o Los sistemas que se ubican entre A y P: su principal objetivo es tener siempre
los datos disponibles a pesar de fallos en los sistemas; así como aceptar que los
datos no estén actualizados por milisegundos.
o Los sistemas que se ubican entre C y P: garantizan consistencia y tolerancia a
particiones. Para lograr la consistencia y replicar los datos a través de los nodos,
sacrifican la disponibilidad.
Podemos observar la distribución de las diferentes bases de datos según sus
prestaciones en la Figura 5 Teorema CAP.
1.2.2 BASE
En las bases de datos NoSQL tendremos en cuenta estas características:
 Disponibilidad básica (Basically Available): garantiza disponibilidad, en los
términos de CAP.
 Soft state: el estado del sistema puede cambiar con el tiempo, incluso sin
entradas de datos.
 Consistencia eventual (Eventual consistency): será consistente en el tiempo
mientras no reciba datos de entrada en ese tiempo.
1.2.3 Transacciones ACID
En las Bases de Datos relacionales encontramos las siguientes características:
o Atomicidad (Atomicity): el sistema permite operaciones atómicas; siendo
aquellas que, si está formada por operaciones más pequeñas, se consideran
como un paquete indivisible. Deben ejecutarse todas correctamente, o, en el
caso de que alguna de ellas no pueda hacerlo, el efecto de las que ya se han

ejecutado no debe hacerse notar, debe deshacerse, como si el conjunto de las
operaciones no se hubieran realizado.
o Consistencia (Consistency): integridad. Esta propiedad asegura que sólo se
empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas
operaciones que no van a romper las reglas y directrices de integridad de la base
de datos. Así mismo, sostiene que cualquier transacción llevará a la base de
datos desde un estado válido a otro también válido.
o Aislamiento (Isolation): propiedad que defiende que una operación no puede
afectar a otras. Esto asegura que la realización de dos transacciones sobre la
misma información sea independiente y no genere ningún tipo de error.
o Durabilidad (Durability): ésta propiedad asegura que, una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
2 Bases de datos relacionales (SQL)
Se trata de una base de datos que cumple con el modelo relacional, siendo este
el más utilizado en la actualidad para implementar bases de datos. 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.
En relación a ellas, podemos decir que mantienen las características ACID en
las transacciones; así como que el lenguaje de consulta para interactuar con este tipo
de bases de datos es SQL, tratándose de un lenguaje declarativo orientado a un
conjunto de registros.
Así mismo, cabe señalar que las bases de datos relaciones pueden resultar muy
adecuadas para los datos estructurados y los sistemas transaccionales, es por ello que
la mayoría de datos gestionados por las empresas diariamente es de este tipo. Es
curioso que, después de 30 años, siga siendo necesario procesar este tipo de datos,
pues continua representando un gran porcentaje de la actividad empresarial, siendo
críticos para ellas.

Otro aspecto a señalar es que, conforme avanza la tecnología, las bases de
datos también han ido avanzando y modernizándose para poder seguir siendo
competitivas. Con este objetivo se adaptaron nuevas características a los datos:
 Objeto-relacionales
 Semiestructurados
Así mismo, también es necesario consultar grandes cantidades de datos de
forma más eficiente. Por ello, se adaptaron a diferentes entornos con el objetivo de
ampliar sus capacidades analíticas:
 Data warehouse:
o Datos para toma de decisiones
o Grandes volúmenes de datos
2.1 Problemática
A pesar de todos los avances y continuas mejoras ya citados, las bases de datos
relaciones siguen teniendo algunas necesidades que no se satisfacen con su modelo
actual.
Necesitan
de:
Diseño adecuado (lógico y físico)
Administración
Generan
esquemas
relacionales:
Uniformes: que suponen dificultades para representar
relaciones jerárquicas.
Complejos: que conllevan gran número de tablas y
necesidad de realizar operaciones de join.
No resuelven
bien:
Datos semiestructurados (de forma nativa)
Datos no estructurados

2.2 Ejemplos de Bases de Datos Relacionales
o SQL Server: es el motor de base de datos de Microsoft. Se trata de un sistema
para la administración y la gestión de base de datos basado en el modelo
relacional. Su función principal es almacenar y consultar datos solicitados por
otras aplicaciones, sin importar si están en el mismo sistema o conectados a una
red local o a internet.
o Oracle: tuvo su origen en 1979, en la empresa SDL, convirtiéndose con el tiempo
en la base de datos más usada a nivel empresarial. Oracle ofrece el conjunto de
herramientas más completo, que va desde la base de datos y aplicaciones
comerciales, hasta herramientas de desarrollo, herramientas de soporte de
decisiones o business intelligence. Además, con la adquisición de SUN también
ofrece soluciones de hardware especializados para explotar al máximo su base
de datos. Por último, cabe señalar que es multiplataforma, pudiendo funcionar
en distintos sistemas operativos y arquitectura de procesadores.
o MySQL: es la más utilizada para sistemas de contenido web, servicios web, etc.
así como una de las más instaladas, aunque a nivel empresarial no ha tenido
tanta aceptación. Cabe señalar que esta base de datos puede ejecutarse en
Linux, Windows, Solaris, Mac OS X. Además, la versión “Comunity Server” se
distribuye de forma gratuita, aunque hay productos comerciales como
“Enterprise Server”, “MySQL Cluster”, entre otros.
o PostgreSQL: se trata de una base de datos multiplataforma (Linux, Solaris,
Windows, Mac OS X), así como de código libre. Algunas empresas lo usan como
alternativa a Oracle.

3 Bases de datos NoSQL
Las bases de datos NoSQL han sido creadas con un enfoque diferente a las
bases de datos relacionales tradicionales. Mientras que las relacionales buscan mejorar
temas como transaccionalidad, características ACID, soporte para Triggers, etc.;las
NoSQL persiguen altas velocidades, simplicidad, escalabilidad, etc. a costa de algunas
características comunes a las bases de datos relacionales.
3.1 ¿Por qué aparecen los sistemas NoSQL?
Los sistemas NoSQL surgen como una nueva alternativa (basada en tecnología
ya existente: bases de datos clave/valor y documentales) para solventar problemas
como la presencia de datos no estructurados, masivos, etc. Para ello propone 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.
Una vez mencionado lo anterior, podemos ver que las bases de datos NoSQL
tienen su mayor potencial en los siguientes ámbitos:
o Datos masivos: data streams, datos científicos, procesos industriales, tráfico de
redes…
o Web 2.0: enfocado a lo social
o Software como Servicio: relacionado con los servicios en la nube o “cloud
computing”
Por este motivo, grandes empresas como Facebook, Google y Amazon han
creado proyectos utilizando tecnologías de base de datos alternativas a las relacionales.
Podemos destacar que, principalmente, utilizan bases de datos documentales y
clave/valor; y, basándose en ellas, han creado su soporte de almacenamiento como, por
ejemplo, Google creó BigTable [4], Facebook creó Cassandra [5], Amazon creó Dynamo
[6], etc.

Cabe señalar que las bases de datos NoSQL no pretenden reemplazar a las
bases de datos tradicionales; es más, podemos ver que la mayor parte de las empresas
que usan NoSQL han desarrollado aplicaciones híbridas que utilizan en conjunto bases
de datos tradicionales y NoSQL en un mismo ecosistema.
De esta forma, podemos concluir que, en función de nuestras necesidades,
haremos uso de una implementación NoSQL o relacional.
3.2 Historia
En este apartado veremos la evolución de los diferentes sistemas de base de
datos NoSQL:
Figura 6 Historia bases de datos NoSQL
2000
•Neo4j: base de datos orientada a grafos
2005
•Infogrid: base de datosorientada a grafos
•CouchDB: base de datos orientada a documentos
•Big Table (Google): sistema de almacenamiento estructurado, no denso
y distribuido
2007
•Dynamo (Amazon): base de datos clave–valor,
•MongoDB: base de datos orientada a documentos
•Cassandra (Facebook, Apache): base de datos clave–valor
2009
•Redis: base de datos clave–valor

3.3 Modelo de datos
Las bases de datos NoSQL se diferencian principalmente de las relacionales en
el modelo de datos. De esta forma, podemos clasificarlas según su modelo en diferentes
categorías [7]:
3.3.1 Documentos
Mientras que los datos de las bases de datos relacionales son guardados en filas
y columnas, las bases de datos documentales guardan sus datos en documentos. Estos
documentos suelen utilizar una estructura que es como JSON (JavaScript Object
Notation), tratándose de un formato muy popular entre los desarrolladores. Así mismo,
los documentos proporcionan una forma intuitiva y natural para modelar datos de
manera similar a la programación orientada a objetos. De esta forma, podemos ver que
cada documento es un objeto.
Cabe señalar, que los documentos contienen uno o más campos, donde cada
campo contiene un tipo de valor (cadena, fecha, binario o array). En lugar de difundir un
registro a través de múltiples columnas y tablas, cada registro, así como sus datos
Figura 7 Tipos de modelos NoSQL

asociados, son normalmente almacenados en un mismo documento. Esto simplifica el
acceso a datos y reduce o, incluso, elimina la necesidad joins y complejas
transacciones.
En una base de datos documental, la noción de un esquema es dinámica, es
decir, cada documento puede contener diferentes campos. Esta flexibilidad puede ser
particularmente útil para el modelado de datos no estructurados.
3.3.2 Grafos
Las bases de datos con este modelo utilizan estructuras de grafos con nodos,
conexiones y propiedades para representar datos; así como que los datos se modelan
como una red de relaciones entre los elementos específicos. Su atractivo principal es
que hace que sea más fácil modelar relaciones entre entidades en una aplicación.
Finalmente, cabe señalar que su uso más extenso es en las redes sociales.
3.3.3 Clave-Valor
Desde una perspectiva de modelo de datos, almacenes de claves y valores son
el tipo más básico de la base de datos NoSQL. Cada elemento de la base de datos se
almacena como un nombre de atributo o la clave, junto con su valor. El valor, sin
embargo, es totalmente opaco al sistema; los datos sólo pueden ser solicitados por la
clave. Este modelo puede ser útil para la representación de datos polimórficos y no
estructurados, puesto que la base de datos no impone un esquema.
3.3.4 Orientadas a columnas
Guardan los valores en columnas en lugar de filas. Cada registro puede variar
en el número de columnas que se almacenan, y las columnas se pueden anidar dentro
de otras columnas denominadas súper columnas, podemos observar esta estructura en
la Figura 8 Ejemplo modelo orientado a columnas.

3.3.5 Comparativa y discusión
- Todos estos modelos de datos proporcionan la flexibilidad del esquema.
- El modelo de datos clave-valor y de columna es opaco en el sistema - sólo la
clave principal se puede consultar.
- El modelo de datos de documentos tiene la aplicabilidad más amplia.
- El modelo de datos de documentos es el más natural e intuitivo.
- El modelo orientado a columnas proporciona un acceso más controlado a los
datos que el modelo del clave- valor, pero menos flexibilidad que el modelo de
datos de documentos.
3.4 Gestores de Bases de Datos NoSQL
A continuación hablaremos sobre algunas Bases de Datos NoSql, viendo sus
características y comparando algunas de ellas con el objetivo de ver cuál es la que más
nos interesa utilizar.
Figura 8 Ejemplo modelo orientado a columnas

3.4.1 Cassandra
Se trata de una base de datos NoSQL y open-source, multiplataforma,
distribuida, altamente escalable y eventualmente consistente, basada en BigTable y
Dynamo (de Amazon), publicada por Facebook en 2008.
Sumodelo de datos es una réplica del de BigTable.Implementa un modelo de
replicación “sin puntos de falla” muy parecido al de Dynamo.
Cabe señalar que hay muchas APIs de acceso para Cassandra, siendo algunas
de ellas las siguientes: Java (Hector), Python (Pycassa), PHP (PHPcassa), siendo estas
librerías son las mejores que hay hoy por hoy. También puede usarse, desde las últimas
versiones de Cassandra, Cassandra CLI y CQL (Cassandra Query Language).
Algunas empresas como Digg, Twiter, Rackspace vieron el potencial de
Cassandra y decidieron colaborar con el proyecto, participando en su desarrollo.
3.4.2 COUCHDB
Se trata de un sistema de base de datos documental orientado a documentos y
multiplataforma, que se distribuye bajo licencia Open Source. Couch DB almacena los
datos como documentos y se diseñó con el objetivo de ser altamente escalable y de
bajo costo.
Esta base de datos está, especialmente, diseñada para la WEB, dando facilidad
de uso en este campo. Cabe señalar que es mucho menos especializada que MongoDB
pudiendo tener, por lo tanto, un mayor abanico de uso. Por ejemplo, al poder tener el
uso de transacciones podremos utilizarlo para aplicaciones contables.
3.4.3 MongoDB
Se trata de un sistema de base de datos NoSQL orientado a documentos y
desarrollado bajo el concepto de código abierto.
Cabe señalar que, para almacenar los documentos, MongoDB utiliza una
serialización binaria de JSON, llamada BSON, que es una lista ordenada de elementos

simples. El núcleo de la base de datos es capaz de interpretar su contenido, de modo
que, lo que a simple vista parece un contenido binario, realmente es un documento que
contiene varios elementos. Estos datos están limitados a un tamaño máximo de 4 MB,
requiriéndose para tamaños superiores el uso de GridFS [8].
Hemos de señalar que una de sus características principales es la del
Autosharding, mediante la cual una base de datos puede ser fraccionada, siendo vista
por el programador como una base de datos única, aumentando de esta forma su
facilidad de uso y su escalabilidad.
Plataformas:
- Linux
- Windows
- Mac OS X
3.5 Otros SGBD NoSQL
En los siguientes apartados se recogen otros Sistemas de Gestión de Base de
Datos, los cuales han sido comparados con los anteriormente mencionados. No
obstante, hemos decidido no incluirlos en la comparación más exhaustiva por el hecho
de que sean privativos, así como por aspectos relacionados con su precio y
prestaciones, puesto que éstas son inferiores.
3.5.1 BigTable
Se trata de un sistema de base de datos desarrollado por Google que se basa,
principalmente, en el uso del sistema de archivos GFS. Así mismo, no utiliza un modelo
relacional, sino que más bien la podemos definir como un mapa ordenado y
multidimensional de datos.

Cabe señalar que fue desarrollado con el objetivo de permitir alta escalabilidad
y manejar datos en la dimensión de peta bytes, pudiendo distribuir la carga de trabajo
entre cientos, e incluso, miles de servidores.
3.5.2 HBase
HBase es una base de datos noSQL, de código abierto, distribuida y
multiplataforma, cuyo modelo de datos es una réplica del modelo de BigTable.
Cabe señalar que puede ser accedido a través de APIs de diferentes lenguajes
como Java, Python, Groovy, Scala y JRuby (utilizados por la JVM), y REST y Thrift (no
utilizados por la JVM). Así mismo, también puede utilizarse con Hadoop MapReduce,
implementación open-source de MapReduce, para el procesamiento de datos en
paralelo.
En cuanto a la infraestructura, hemos de decir que se apoya en Hadoop,
proporcionando HDFS (Hadoop Distributed File System), como sistema de ficheros.
En relación a la implementación de HBase, hay que contar con caché de bloques
y Bloom filters para la optimización de las consultas sobre grandes volúmenes de datos
y autosharding.
3.5.3 LevelDB
LevelDB es una base de datos, NoSQL y de código abierto, quesoporta multitud
de sistemas operativos. Se trata de un almacenamiento para sistemas embebidos que
se utiliza como una librería,basado en BigTable desarrollado por Google; pudiéndose
acceder y trabajar con los datos a través de un API escrita en C++.
En lo que se refiere al modelo de datos, cabe señalar que es una réplica del de
BigTable.
En relación a la infraestructura en la que se apoya, hemos de decir que puede
ser tan variada como el sistema operativo donde se instale el software (sistemas UNIX,

Mac OS X, Windows y Android). Además, utiliza la librería Snappy, desarrollada por
Google, para la compresión de los datos, así como el formato SSTable para guardar los
datos en los archivos.
En cuanto a implementación, cabe mencionar que es similar a la representación
de tablet de BigTable, componiéndose cada base de datos de un directorio con una
serie de ficheros:
 Log. Guarda las actualizaciones recientes y, cuando se alcanza un
tamaño,la memoria se vuelca en un archivo *.sst., guardándose en
memtable.
 SSTable. Guarda los datos ordenados por clave.
 Manifest.Contiene información sobre qué SSTables componen todos los
niveles de datos con sus correspondientes rangos de claves, así como
otra información importante. Es importante mencionar que se crea uno
cada vez que se abre la base de datos.
 Current. Guarda cuál ha sido el último manifest creado.
En lo que respecta a la compresión, se van compactando archivos por niveles
cuando estos superan el límite de tamaño para ese nivel N, dando lugar a archivos de
nivel N+1. De esta forma, cada vez que se compactan archivos, el Garbage Collector
elimina los archivos log que no son el actual, así como las tablas que no son
referenciadas por el manifest y no son la salida de la actual compresión.
3.5.4 Hypertable
Hypertable es un proyecto, NoSQL y open-source. Se trata de una base de datos
distribuida, de alto rendimiento y altamente escalable, que cuenta con un modelo de
datos replicadodel de BigTable. Cabe señalar que puede ser accedido a través de 2
APIs diferentes: HQL (Hypertable Query Language) y Thrift API; así comoutilizado
también con Hadoop MapReduce, permitiendo, además, ejecutar scripts con los
lenguajes Hive and Pig.

Su infraestructura se apoya sobre Hadoop, utilizando HDFS como sistema de
ficheros y pudiéndose usar también sobre otros DFS o incluso FS. Además, como
servidor de alta disponibilidad de cerrojos, utiliza Hyperspace.
En cuanto a su implementación, cabe señalar que es casi idéntica a la de
BigTable. La única diferencia reside en que, por encima del DFS, se encuentra una capa
que abstrae el sistema de ficheros para que pueda utilizarse cualquiera de los
siguientes: HDFS, MapR, Ceph, KFS o el sistema de ficheros local.
3.5.5 DynamoDB
Dynamo es una base de datos NoSQL, multiplataforma, propietaria y de código
cerrado, por lo que su uso es exclusivo de la empresa que la implementó: Amazon.
En octubre de 2007 se publicó un paper con el diseño y la especificación, a
grandes rasgos, de Dynamo, rompiendo con conceptos como la consistencia o modelo
relacional. Su objetivo se definió claramente: escalabilidad y disponibilidad.
DynamoDB puede ser gestionada en unos pocos clics desde la consola de
administración de AWS. De esta forma, si lo requerimos, podemos iniciar una nueva
tabla de DynamoDB, aumentar o disminuir los recursos, según las necesidades,
consultando las estadísticas de rendimiento.
En cuanto a su infraestructura es Dynamo (storage system), almacenándose
todos los datos en discos de estado sólido (SSD) para asegurar que el acceso a los
datos sea más rápido.
DynamoDB integra Amazon Elastic MapReduce, lo que permite realizar análisis
complejos de grandes cantidades de información usando Hadoop sobre AWS.
Un aspecto interesante de Dynamo es el garantizar, en el 99.9% de los accesos,
un tiempo de respuesta menor a 300ms, lo cual provee a los clientes una experiencia
“siempre en línea”, sin caídas ni restricciones del servicio.

3.6 Comparación entre Bases de Datos NoSQL
En este apartado vamos a comparar las tres bases de datos NoSQL más
importantes de libre distribución, con el objetivo de que esto nos ayude a decidir cuál
sería la mejor Base de Datos para utilizarla en nuestro proyecto.
CARACTERÍSTICAS TÉCNICAS
A) Modelo de datos y almacenamiento
Cassandra
 Llave valor
 Almacenamiento en forma de tablas hash
CouchDB
 Guarda datos de forma documental apoyada en el modelo
llave/valor
 Utiliza JSON
 Capacidad de almacenamiento de Subdocumentos
MongoDB
 Grabación de datos de forma documental, apoyado en el
modelo llave/valor
 Utiliza versión binaria de JSON llamada BSON
B) Interfaces
Cassandra
 Utiliza su propio protocolo de comunicación llamado Thrift
CouchDB
 Para conectarnos a ella utilizaremos una API RESTful HTTP
que funciona como servicio web.
MongoDB
 Dispone de gran variedad de drivers nativos oficiales, para
usarse con varios lenguajes de programación.

C) Drivers oficiales para lenguajes de programación
Cassandra
 Java
 Python
CouchDB
 Soporta todos los lenguajes de programación que puedan
trabajar con servicios web via su API RESTful usando JSON
MongoDB
 C
 C++
 Erlang
 Haskell
 Java
 JavaScript
 .NET
 Perl
 PHP
 Python
 Ruby
 Scala
D) Escalabilidad horizontal
Cassandra
 Basada en replicación
 Alta tolerancia a fallos
 Permite agregar y quitar nodos “en caliente” sin reiniciar los
servicios
CouchDB
 Para la replicación utiliza su API RESTful HTTP
 Permite resumir la sincronización de los datos entre los
nodos si existiera algún error de hardware o conectividad
MongoDB
 Permite escalar usando su función de Auto sharding o de
auto segmentar los datos en sus diferentes nodos de trabajo
E) Replicación
Cassandra
 Basada en replicación
 Alta tolerancia a fallos
 Permite agregar y quitar nodos “en caliente” sin reiniciar los
servicios
CouchDB
 Replicación Maestro/Maestro, pero los desarrolladores
deben proveer las sentencias para resolver los conflictos
que puedan darse en este tipo de replicación

MongoDB
 Replicación Maestro/Esclavo MongoDB usa su sistema de
replicación solo para alta disponibilidad
F) Soporte para archivos de gran tamaño
Cassandra
 No nos proporciona soporte para archivos de gran tamaño,
por lo que debemos dividir los archivos para poder
almacenarlos.
CouchDB
 Podemos guardar archivos de gran tamaño mediante
“adjuntos”.
MongoDB
 Podemos almacenar archivos de gran tamaño mediante
GridFS
G) Consultas dinámicas
Cassandra
 Soporta consultas dinámicas
CouchDB
 No soporta consultas dinámicas, las consultas deben ser
programadas y luego utilizadas
MongoDB
 Soporta consultas dinámicas
H) Control de cambios y consistencia
Cassandra
 Soporta el MVCC, esta característica permite asegurar que
las operaciones sobre los datos se reflejen en todos los
nodos de trabajo de un entorno distribuid (clúster).
 Cassandra nos permite configurar el nivel de consistencia.
CouchDB
 Soporta MVCC, versionando los cambios y sincronizándolos
a los demás nodos de trabajo.
MongoDB
 No versiona, las actualizaciones se realizan sobre los datos
como tal para distribuirlos a los demás nodos de trabajo.
Tabla 1 Tabla de características técnicas de BD NoSQL

3.7 Discusión sobre la elección de la base de datos
A través de la comparación que hemos hecho de las tres bases de datos NoSQL
más importantes de libre distribución, concluimos que, para nuestro la realización de
nuestro proyecto, la mejor Base de datos sería MongoDB.
Esto es así, puesto que MongoDB cuenta con numerosos aspectos que le
favorecen en dicha comparación, suponiendo ventajas de cara a nuestro proyecto. De
esta forma, encontramos que:
o Por su modelo de datos orientado a documentos proporciona flexibilidad,
es intuitivo para el desarrollador es de amplio uso.
o Su API es la más extensa y variada.
o Cuenta con una documentación muy rica.
o Cuenta con la capacidad de replicación maestro-esclavo y, además,
facilidad de replicación, alta disponibilidad y auto sharding.
4 MongoDB
En este apartado comentaremos ampliamente algunas de las principales
características de MongoDB que anteriormente ya habíamos citado, así como otras
nuevas.
4.1 Map Reduce
MapReduce es un modelo de programación diseñado para procesar grandes
volúmenes de datos en paralelo, dividiendo el trabajo en un conjunto de tareas
independientes.

4.2 Auto sharding
MongoDB provee de escalabilidad horizontal en bases de datos utilizando una
técnica llamada sharding , la cual es transparente a las aplicaciones. Su funcionamiento
se basa en distribuir los datos en múltiples particiones físicas llamados fragmentos,
permitiéndonos escalar a muy alto nivel. Así mismo, cabe señalar que sharding permite
hacer frente a las limitaciones de hardware de un único servidor, tales como cuellos de
botella en la memoria RAM o en el disco I/O, sin incrementar la complejidad de la
aplicación.
De esta forma, podemos mencionar que MongoDB soporta tres tipos de
sharding:
 Range-based Sharding.: los documentos se dividen a través de
fragmentos de acuerdo con el valor de clave de fragmento. Este enfoque
es muy adecuado para aplicaciones que necesitan para optimizar las
consultas rangebased.
 Hash-based Sharding: los documentos se distribuyen de manera
uniforme de acuerdo con un hash MD5 del valor de clave fragmento.
 Tag-aware Sharding: los documentos se dividen de acuerdo a una
configuración especificada por el usuario. Los usuarios pueden optimizar
la ubicación física de los documentos para los requisitos de aplicación,
tales como la localización de datos en los centros de datos específicos.
4.3 Herramientas
Generalmente, podemos administrar nuestra instancia de MongoDB desde la
consola de comandos, pero no se trata de una alternativa muy atractiva. Por este
antecedente, y debido a la gran popularidad que goza MongoDB, existen numerosas
herramientas de administración con interfaz de usuario de escritorio, orientado a la
web, etc. Por ello, a largo de este apartado hablaremos acerca de las diferentes
herramientas para administrar MongoDB.

4.3.1 Umongo
Esta herramienta cuenta con una interfaz gráfica sencilla y cercana,
incorporando un constructor de documentos visual (GUI Document builder). Además,
aporta la visión de árboles de documentos, así como la facilidad en cuanto a la visión
de colecciones y documentos.
Por otro lado, dicha interfaz nos permite la conexión a un servidor, a un conjunto
de réplicas o a una instancia Mongo, así como la utilización de operaciones de Sharding:
enable sharding, add shard, shard collection.
Así mismo, Umongo nos aporta toda la información citada en tiempo real y nos
permite realizar distintas operaciones, como son:
o Bases de datos: crear, eliminar, modificar, command, eval
o Colecciones: crear, renombrar, eliminar, find, insert, save
o Documentos: update, duplicate, remove
o Índices: create, drop
En relación a la funcionalidad de creación de un nuevo documento, contamos
con diferentes opciones. De esta forma, podemos crear un nuevo documento mediante
la interfaz gráfica ya mencionada anteriormente, o importarlo de archivos como JSON,
BSON, CVS. A su vez, estos archivos pueden haber sido exportados de bases de datos
como MySQL.
Entre las posibilidades de esta herramienta también hemos de mencionar la
facilidad para realizar consultas y obtener estadísticas sobre la base de datos (server
status, db stats, replication info, etc.), así como la variedad de plataformas en las que
se puede ejecutar (Windows, Linux y Mac OSX).

4.3.2 MongoVision
Esta herramienta de administración cuenta con pestañas e interfaz paginado, lo
que le permite trabajar con muchas colecciones al mismo tiempo. Además, cuenta con
la posibilidad de exportar e importar en formatos JSON y CSV, así como de realizar
diferentes funciones. Estas se pueden llevar a cabo a través de:
o Administración de bases de datos. En ella podemos crear bases de datos,
así como eliminarlas y observar diferentes estadísticas (conexiones,
tamaño, etc.)
o Administración de los índices de las colecciones, pudiendo añadírselos a
la colección, determinando el tipo más correcto para nuestros propósitos.
o Un ayudante para realizar consultas, la posibilidad de administrar los
usuarios, así como de observar estadísticas del servidor.
En relación a la creación de nuevos documentos, hemos de citar que ésta se
puede llevar a cabo a través de dos formas diferentes: mediante plantillas o
herramientas JSON para ayudar a la inserción de documentos en este formato.
Por último, entre otras características reseñables de MongoVision, se encuentra
la posibilidad de conectar con varios servidores con soporte para los servidores de
usuario / contraseña. Además, tiene una completa Gestión del sistema de archivos
GridFS, donde destacan las funciones de: listar, cargar, descargar archivos…
4.3.3 PHPMoAdmin
La herramienta PHPMoAdmin presenta diferentes características en torno a
numerosos aspectos. Así, en cuanto a la Gestión de Base de datos, cabe señalar que
podemos crear y eliminar Bases de Datos, además de obtener información sobre las
éstas (tamaño, estadísticas, etc.).
En torno a las funcionalidades de las colecciones, hemos de citar que existen
diferentes posibilidades, como son la capacidad de crear y eliminar colecciones, así

como de visualizarlas en forma de lista con subelementos (documentos) dentro de ella.
Por último, también podemos mencionar la diversidad de funciones que encontramos
en la gestión de índices. Así, podemos listarlos e insertarlos utilizando una gran variedad
de tipos.
En relación a las consultas, contamos con la opción de realizarlas mediante
JSON o una matriz PHP. En esta interfaz tenemos tres posibles visiones: completa,
compacta y uniforme. Dentro de estas tres encontramos herramientas que nos facilitan
la visualización y búsqueda en las consultas, como son:
o Cuadro de búsqueda rápida. Mediante esta ayuda podemos realizar
búsquedas utilizando el texto exacto de búsqueda, un valor determinado
y, sobre todo, expresiones regulares y JSON (con operadores MongoDB
habilitados).
o Diferentes opcionalidades de la interfaz. Entre ellas encontramos la
facilidad de ordenar por cualquier llave, incluso subclaves anidadas, lo
cual es una gran ayuda para movernos por grandes conjuntos de datos.
Además, contamos con la posibilidad de limitar los resultados de la
búsqueda por un número o todos los resultados posibles. Por último,
encontramos la opción de poder editar y eliminar documentos dentro de
la consulta, aspecto que resulta interesante para facilitar al usuario la
utilización de la base de datos.
Otro aspecto a mencionar es que esta herramienta cuenta con otras funciones
que debemos reseñar. Así, tenemos la posibilidad de visionar los archivos que contiene
el GridFS, aspecto que es muy interesante si tenemos una base de datos con archivos
tipo audio video, etc y necesitamos administrarlos. Por último, cabe señalar que esta
aplicación permite una sencilla configuración con PHP y es excelente para administrar
una web mediante este lenguaje y MongoDB.

4.3.4 RockMongo
RockMongo es una aplicación de gestión de fácil uso y sencilla, que cuenta con
una gran variedad de idiomas (inglés, chino, francés, japonés, inglés, español,
alemán…). Ésta aplicación está orientada a gestión de bases de datos para la Web, por
lo que incorpora diferentes complementos como son: información sobre el servidor
(servido web, PHP, directivas en php.ini…), información de estado y estado de las
réplicas de la base de datos.
Además de todo esto, podemos gestionar MongoDB con funciones de creación,
consulta y eliminación de base de datos; colecciones y documentos; además de la
creación y gestión de índices de la base de datos. En relación a la inserción de
documentos, cabe señalar que podemos importar desde archivos CVS y JSON. Por
último en cuanto a la gestión, cabe señalar que esta herramienta nos permite consultar
estadísticas sobre las bases de datos, tales como número de conexiones, tamaño de
las colecciones, etc.
Como aspecto particular, hemos de mencionar que esta herramienta nos permite
la ejecución de código javascript, además de la visión y descarga de archivos alojados
en el sistema de archivos de MongoDB (GridFS).
4.3.5 MongoVUE
MongoVUE cuenta con una versión de pago y otra gratuita, y es una de las
herramientas más completas, sencillas y útiles que podemos encontrar.
En cuanto a sus principales características podemos mencionar que nos
encontramos con una interfaz que facilita la sencilla gestión de diferentes servidores y
bases de datos de MongoDB. Esto se debe a la visión en árbol de estas bases de datos
y sus colecciones, pudiendo navegar por ellas de forma familiar.
Con respecto a las funcionalidades de las colecciones, podemos gestionarlas
(crear, eliminar, observar diferentes estadísticas, etc.). Por otra parte, cabe mencionar
que la visión que tenemos de los documentos dentro de las colecciones puede ser de

tres formas diferentes: en forma de árbol, de tabla o en documentos JSON. Además,
cabe señalar que, para poder insertar documentos, contamos con dos opciones: un
editor que interpreta JSON, el cual nos ayuda a escribir los documentos, advirtiendo
errores; y poder insertar el JSON desde archivo. Por último, podemos insertar índices,
eliminarlos y gestionarlos dentro de esta interfaz.
Un aspecto muy relevantea comentar de estaaplicación, es que nos permite
migrar de MySQL a MongoDB, pero teniendo en cuenta que no respeta claves externas.
En cuanto a la realización de consultas, contamos con varias opciones para
realizarlas: con JSON o con un asistente que facilita las consultas en JSON. En
cualquiera de estas opciones podemos realizar consultas complejas mediante
map&reduce.
Por último, hemos de mencionar que, en la versión de pago, contamos con
diferentes extras, como son: monitorización de servidores, administración de GridFS y
migración desde PostgreSQL.
4.4 Conclusiones sobre las herramientas de gestión de MongoDB
Como hemos visto, MongoDB se puede administrar desde muchas
herramientas. Después del análisis realizado, podemos observar que parte de ellas
están orientadas a la gestión Web, y otras al fácil visionado de las colecciones y
documentos.
Para la administración de MongoDB he elegido MongoVUE, ya que es una
de las herramientas más completas, sencillas y útiles. Además, frente a las otras,
presenta aplicaciones ventajas como:
 Posibilidad de migración de esquemas sencillos de MySQL a MongoDB
 Facilidad de realización de consultas mediante un asistente.
 Facilidad de uso.
 Visionado de documentos muy sencillo e intuitivo.

Capítulo III: Herramienta de análisis de eficiencia de BD SQL versus BD NoSQL
Herramienta de análisis de eficiencia de BD
SQL versus BD NoSQL
Para la realización de este proyecto, hemos elaborado una aplicación con el
objetivo de facilitar el análisis de las bases de datos a estudiar, en concreto, MySQL y
MongoDB. Así, dicha herramienta nos aporta la posibilidad de realizar pruebas con el
objetivo de ver las diferencias en cuanto a tiempo y tamaño entre ambas bases de datos.
Figura 9 Interfaz de h. de análisis de eficiencia

1 Casos de uso de la aplicación
A continuación, se recoge el diagrama de casos de uso de la herramienta y, en
los siguientes apartados, un desarrollo más detallado de cada caso de uso en cuestión.
En ellos tendremos la posibilidad de conectar la base de datos y realizar los test sobre
las diferentes funcionalidades.
Figura 10 diagrama de casos de uso H. análisis de eficiencia

1.1 Caso de uso: Conectar Bases de datos
Nombre del CU Conectar Bases de datos
Resumen El usuario crea las conexiones a MySQL y MongoDB
Dependencias
Actores Usuario.
Precondiciones Las bases de datos estén activas
Postcondición Las bases de datos están conectadas con la aplicación
Curso normal 1.-El usuario elige las bases de datos para realizar la
conexión.
2.-El sistema realiza las conexiones y lo notifica al usuario.
Cursos alternativos 2a.- Hay algún error al conectar, el sistema notifica que
alguna conexión no ha podido realizarse.
Observaciones

1.2 Caso de uso: Análisis de insert
Nombre del CU Análisis de insert
Resumen El usuario puede realizar un análisis sobre cómo cada base
de datos realiza insert e el sistema , analiza en tiempo que
tarda y el tamaño que ocupa
Dependencias
Actores Usuario.
Precondiciones Debemos haber realizado la conexión con las bases de
datos.
Postcondición
Curso normal 1.-El usuario elige la bases de datos para realizar el test..
2.-El sistema realiza inserciones aleatorias guardando el
tiempo que tardan, mostrándolo al acabar este proceso
Cursos alternativos 2a.- Si el usuario no ha elegido ninguna base de datos, se
le remite un mensaje para qué elija al menos una.
Observaciones

1.3 Caso de uso: Análisis de insert y delete
Nombre del CU Análisis de insert y delete
Resumen El usuario puede realizar un análisis sobre cómo cada base
de datos realiza insert en el sistema y después los elimina,
analiza en tiempo que tarda y el tamaño que ocupa(insert)
Dependencias
Actores Usuario.
datos.
Postcondición
Curso normal 1.-El usuario elige las bases de datos para realizar el test.
2.-El sistema realiza inserciones aleatorias guardando el
tiempo que tardan, mostrándolo al acabar este proceso
3.-Luego elimina uno por uno lo registros de la base de
datos contabilizando el tiempo que tarda.
Observaciones

1.4 Caso de uso: Análisis de Query
Nombre del CU Análisis de Query
Resumen El usuario puede elegir entre varios test para realizar
análisis sobre las bases de datos.
Dependencias
Actores Usuario.
datos.
Postcondición
Curso normal 1.-El usuario elige las bases de datos para realizar el test.
Además de elegir el test y el número de consultas a realizar
en el test
2.-El sistema realiza el test y muestra en pantalla el tiempo
que ha tardado cada base de datos.
Observaciones

1.5 Caso de uso: Análisis de Update
Nombre del CU Análisis de Update
Resumen El usuario puede elegir un número de update a realizar
sobre las bases de datos.
Dependencias
Actores Usuario.
datos.
Postcondición
Curso normal 1.-El usuario elige la bases de datos para realizar los update
y el número de consultas a realizar en el test
2.-El sistema realiza el test y muestra en pantalla el tiempo
que ha tardado cada base de datos.
Observaciones

2 Arquitectura de la herramienta
Aquí, podemos ver la arquitectura de la herramienta en la que contamos con la
conexión con las bases de datos para realizar los test. Mediante los resultados de estos
test, obtendremos las estadísticas para realizar las comparaciones entre las dos bases
de datos.
Figura 11 Arquitectura aplicación análisis de eficiencia

3 Diseño de la herramienta
En este apartado se recoge el diagrama de clases de la herramienta para el
análisis de eficiencia. Como podemos observar, tenemos tres paquetes, dos de ellos
(MongoDB, MySQL) los utilizaremos para la conexión y utilización de las dos bases de
datos; mientras que en el paquete GUI tendremos la interfaz gráfica y una clase
Utilidades con funciones que nos facilitan la programación.
Figura 12 Diagrama de clases h. análisis de eficiencia

4 Análisis de eficiencia entre MySQL y MongoDB
En este apartado, realizaremos una serie de pruebas y operaciones con estas
dos bases de datos con el fin de encontrar sus puntos fuertes así como débiles a través
de una comparación entre ambas.
De esta forma, llevaremos a cabo dichas pruebas haciendo uso de varias
operaciones comunes entre bases de datos, comentando los resultados obtenidos así
como las diferencias observadas.
4.1 Inserciones
Una de las funciones más utilizadas en una base de datos es la de insertar un
registro. Por ello, en este análisis hemos realizado inserciones contabilizando el tiempo
que han consumido, así como el espacio utilizado.
En la siguiente gráfica, la cual se refiere al tiempo, podemos observar que
MySQL requiere mucho más tiempo que MongoDB. Para ser exactos, si queremos
realizar un millón de inserciones, MongoDB tarda 176 veces más que MySQL.
0,01
0,1
1
10
100
1000
10000
100000
1000000
100 1000 10000 100000 1000000
Tiempoenseg.enescalalogarítmica
Nº de inserciones (log)
Tiempos de inserciones
MySQL MongoDB
Gráfica 1 Tiempo inserciones en las bases de datos

A continuación, se recoge la gráfica referida al espacio ocupado por los registros
en la base de datos. A través de ella, podemos observar que los registros ocupan menos
espacio en MySQL que en MongoDB. No obstante, esta diferencia no es tan notable
como la que existe en la gráfica referida al tiempo.
4.2 Consultas
En el siguiente apartado se recogen los análisis realizados sobre consultas a
bases de datos. Dichos análisis los hemos dividido en test, en los que cada uno se
centra en diferentes características. De esta forma:
0
10
20
30
40
50
60
70
80
100 1000 10000 100000 1000000
TamañoenMB
Nº de inserciones (Log)
Inserciones espacio ocupado
MySQL MongoDB
Gráfica 2 Espacio ocupado en las bases de datos

- El test uno realiza un número de count sobre las bases de datos. En estos
resultados vemos cómo MongoDB realiza el recuento de los registros
mucho más rápido.
Gráfica 3 Tiempos test 1
- El test dos realiza un número determinado de consultas sobre los
nombres. Aquí podemos observas grandes diferencias entre las dos
bases de datos.
1 2 10
MySQL 25,05 48,45 237,52
MongoDB 0 0,0001 0,094
0
50
100
150
200
250
Test 1
MySQL MongoDB
1 5 10
MySQL 105,64 585,87 958,22
MongoDB 0 0 0,001
0
100
200
300
400
500
600
700
800
900
1000
Test 2
MySQL MongoDB

- El test tres realiza un número determinado de consultas sobre el campo
edad.
- El test cuatro realiza un número determinado de consultas sobre los
teléfonos que están indexados. Puesto que los resultados con una
consulta no se pueden observar de manera clara, hemos realizado este
test ejecutando 500 consultas.
Gráfica 6 tiempos test 4
Consulta sin indexar
MySQL 245,37
MongoDB 0,016
0
50
100
150
200
250
Test 3
MySQL MongoDB
Consulta con indices(500 consultas)
MySQL 8,49
MongoDB 0,03
0
1
2
3
4
5
6
7
8
9
Test 4
MySQL MongoDB

- El test cinco realiza un número determinado de consultas sobre las
bases de datos realizando la media (avg) del campo edad agrupando
por el campo nombres.
100000000
MySQL 241,57
MongoDB 1113,42
0
200
400
600
800
1000
1200
Tiempo(s)
Registros en las bases de datos
Test 5
MySQL MongoDB

4.3 Índices
En este apartado se recoge el gasto de tiempo para realizar la creación de un
índice sobre un campo de la base de datos.
Gráfica 8 tiempo de creación de indices
4.4 Borrados
En relación a la eliminación de registros, podemos observar que la diferencia en
cuanto al tiempo que necesita MongoDB frente a MySQL es mucho menor, aumentando
conforme al tiempo según el número de registros.
2700
2800
2900
3000
3100
3200
3300
3400
Telefono
Creación de índice sobre 100.240.100
registros
MySQL MongoDB
0
50
100
150
200
250
300
0 1000 2000 3000 4000 5000 6000
Tiempoensegundos
Registros/documentos eliminados
Delete tiempo
MySQL MongoDBGráfica 9 Tiempos Delete

4.5 Actualizaciones
En esta sección, estudiaremos la eficiencia en cuanto a la realización de
actualizaciones. En este ámbito, MongoDB también es más eficiente, por lo tanto, para
sistemas donde, por ejemplo, se necesite la actualización de muchos datos esta base
de datos será mucho mejor.
Gráfica 10 Tiempos Update
5 Discusión sobre los resultados obtenidos
Como hemos podido observar, en casi todos los ámbitos estudiados MongoDB
supera a MySQL. Puesto que nuestro objetivo es saber qué base de datos dará mejores
resultados en cuanto a la eficiencia con grandes conjuntos de datos, podemos ver cómo,
en la escalabilidad, MongoDB supera ampliamente a MySQL. Por ello, podemos concluir
que será mejor para tratar este tipo de conjuntos de datos.
Más concretamente, en los datos obtenidos de sensores, las inserciones son muy
relevantes, puesto que los datos que recogen son en tiempo real. Por ello,
10 50 100 1200 2000
MongoDB 0,407 1,012 3,049 30,814 52,101
MySQL 1,28 6,644 13,748 137,613 193,613
0
50
100
150
200
250
Update con 100.240.106 registros
MongoDB MySQL

necesitaremos inserciones más rápidas, por lo que nuestra opción sería nuevamente
MongoDB.
También cabe destacar que en MongoDB los datos ocupan más espacio, siendo
esta diferencia poco notable. Esto podremos comentarlo con más interés en el análisis
de los datos almacenados mediante listas, índices, y tablas relacionales, que
realizaremos en el análisis de la aplicación de reconocimiento gestual.

Capítulo IV: Migración MySQL to MongoDB
Migración MySQL to MongoDB
En la actualidad, la mayoría de los datos de las empresas están almacenados en
bases de datos SQL. Esto nos supone un problema a la hora de utilizar esquemas
NoSQL con el objetivo de mejorar nuestras prestaciones y poder almacenar datos
masivos. Es por ello, que en este capítulo veremos las equivalencias entre MySQL
(SQL) y MongoDB (NoSQL tipo documental) con el propósito de observar cómo una
empresa podría migrar sus datos.
1 Diseño de los esquemas ¿Cómo es el cambio de diseño?
El cambio más importante en la migración de una base de datos relacional a
MongoDB es la manera en la que los datos se modelan. Como con cualquier cambio
modelado de datos, cada caso de uso será diferente, pero hay algunas consideraciones
generales que se aplican a la mayoría de los proyectos de migración de esquemas. Para
poder comprender estas consideraciones, así como la manera en que se puede realizar
este cambio de esquema vamos a explicar a continuación las posibilidades y cómo
podemos realizar lo antes descrito.

Veremos, pues a continuación cómo es la traducción directa de los elementos
de SQL a MongoDB,
2 Traducción de elementos
Podemos tener una traducción “directa” de una base de datos relacional a
MongoDB, contando cada elemento con su correspondencia. En algunos casos, dicha
correspondencia tiene varias opciones debiendo elegir, en función de nuestro propósito,
la más adecuada.
RDBMS MongoDB
Base de datos Base de datos
Tabla Colección
Fila Documento
Índice Índice
Join (FK) Documentos embebidos /References
Tabla 2 Equivalencia Relacional MongoDB
2.1.1 Create
Como equivalencia a la creación de una tabla en SQL, en MongoDB tenemos
dos opciones:
Figura 13 Esquema MongoDB Figura 14 Esquema relacional

 Opción 1: podemos insertar un documento, siendo lo equivalente a insert en
SQL. Esto sería así, puesto que, al insertarlo, como no necesitamos una
estructura previa, no hace falta un método create que nos la definiera.
 Opción 2: podemos crear una colección con el nombre de la tabla y realizar las
inserciones de los documentos.
CREATE TABLEnombre (
ClavePrimaria MEDIUMINT NOT NULL
AUTO_INCREMENT,
ClavePrimaria Varchar(30),
Variable1 tipo1,
PRIMARY KEY (ClavePrimaria) )
Opción 1
db.nombre.insert( {
ClavePrimaria: valor,
Variable1: valor,
} )
Opción 2
db.createCollection("nombre")
MongoDB nos insertará, por defecto, su clave primaria para el documento, a no
ser que se la especifiquemos (darle un valor al elemento _id).
2.1.2 Alter
Como equivalencia a la alteración de una tabla en SQL, en MongoDB tenemos
que comentar que:
 Las colecciones no restringen a los documentos a tener una estructura
determinada. Por lo tanto, no tendría sentido alterar la estructura de un
documento, pues ésta es libre.
 Sin embargo, podemos eliminar campos de un documento o añadirlos
mediante update()
o $set para añadir campo
o $unset para eliminar campo

ALTERTABLEtabla
ADDvariabletipo
DROP COLUMN variable2
db.tabla.update(
{ },
{ $set: { variable: “” } },
{$unset: { variable2: "" }
{ multi: true })
2.1.3 Insert
Para insertar utilizamos la sentencia insert() de MongoDB, que tiene un gran
parecido a la de SQL como podemos ver a continuación.
INSERT INTO tabla(_id,Campo1, Campo2)
VALUES ("X",1,"A")
db.tabla.insert(
{ _id: "X", Campo1: 1, Campo2: "A" })
2.1.4 Select
Para realizar consultas contamos con una traducción de los operadores de éstas
a MongoDB [9]. No obstante, existe una diferencia ya que MongoDB no tiene Join, por
lo que deberemos tenerlo en cuenta a la hora de realizar consultas.
MySql MongoDB
WHERE $match
GROUP BY $group
HAVING $match
SELECT $project
ORDER BY $sort
LIMIT $limit
SUM() $sum
COUNT() $sum
Figura 15 Equivalencia entre operadores de consulta

Para realizar una consulta, utilizaremos el operador find() con la siguiente
sintaxis:
SELECT*
FROMtabla
db.tabla.find()
SELECTcampo1,campo2
FROM users WHERE campo3=3
db.users.find(
{campo3=3 },
{ campo1: 1, campo2: 1 }
)
2.1.5 Update
Para realizar una actualización en la base datos utilizaremos update() que es el
mismo del que hemos hablado en el apartado para la alteración de tablas:
UPDATEtabla
SETcampo2 = "C"
WHEREcampo1> 25
db.tabla.update(
{ campo1: { $gt: 25 } },
{ $set: { campo2: "C" } },
{ multi: true })
2.1.6 Delete
La equivalencia para el borrado de registros de SQL en MongoDB es:
DELETEFROMtabla
WHEREcampo1 = "D"
db.tabla.remove( { campo1: "D" } )

3 Claves externas
El diseño del esquema requiere un cambio de perspectiva para los arquitectos
de datos, desarrolladores y administradores de bases de datos:
Figura 16 Esquema migración MySQL MongoDB
Gracias a la facilidad y a lo intuitiva que es MongoDB, nuestros esquemas son
mucho más parecidos al mundo real. Así, para la conexión de las tablas por claves
externas, tenemos dos posibles soluciones [10]: mediante referencias o mediante
documentos contenidos. Cada una de estas posibilidades cuenta con una serie de
ventajas, así como de inconvenientes. Además, para algunos esquemas necesitaremos
una implementación entre las dos posibilidades. Veamos a continuación cuándo es la
mejor situación para utilizar cada una de ellas:
3.1 Referencias
La realización de conexiones mediante referencia permite la normalización de
datos, y puede dar más flexibilidad que la incrustación. No obstante, la aplicación emitirá
consultas para resolver las referencias, requiriendo un cómputo adicional al servidor.
Modelo de datos relacional con 2
dimensiones de estructuras de
filas y columnas
Modelo de datos de
documentos rico y
dinámico con
subdocumentos y
arrays de referencias

La utilización de referencias se debe realizar:
 Cuando la incrustación no
proporcionara ventajas sobre la
eficiencia de las lecturas para
compensar las implicaciones de la
duplicación de datos.
 Cuando se hace referencia al
documento desde un número
grande de diferentes documentos.
 Cuando exista una representación
compleja de relaciones de muchos
a muchos para modelar grandes conjuntos de datos jerárquicos
3.2 Documentos embebidos
Cuando encontramos datos con relaciones 1:1 o 1: Muchos (donde el "muchos"
es visto como relación padre-hijo) cabe señalar que estos son candidatos naturales para
la incorporación dentro de un solo documento. De esta forma, el concepto de propiedad
de los datos también ser modelado con documentos embebidos.
Sin embargo, no todas las relaciones 1:1 deben integrarse en un documento
único. Las referencias a otros documentos en diferentes colecciones deben ser
utilizadas cuando:
 Un documento se lee con frecuencia,
pero contiene un documento incrustado
al que rara vez se accede.
 Una parte de un documento se actualiza
con frecuencia y crece constante en
tamaño, mientras que el resto del
documento es relativamente estático.
Figura 17 Modelo de documentos orientado a
referencias
Figura 18 Modelo de documentos orientado a
subdocumentos

 El tamaño del documento excede el máximo para un documento en MongoDB
(el límite de tamaño de documentos es de 16 MB).
3.3 Diferentes objetivos de diseño
La comparación de estas dos opciones de diseño (incrustación subdocumentos
contra referencia entre documentos) pone de relieve una diferencia fundamentalmente
las bases de datos relacionales y documentos:
 El RDBMS optimiza la eficacia del almacenamiento de datos.
 El modelo de documento de MongoDB está optimizado para saber cómoda
aplicación tiene acceso a datos y así optimizar la velocidad del procesamiento
de estos.
4 Herramientas migración
Para la importación de los datos a MongoDB tenemos la posibilidad de utilizar
diferentes herramientas. A continuación vamos a ver varias posibilidades para pasar
nuestros datos a MongoDB:
4.1 Integración Pentaho
Esta herramienta (ETL) es comúnmente utilizada para migrar bases de datos
relacionales. Además, incluye conectores para MongoDB, así como para gran variedad
de bases de datos SQL y NoSQL como, por ejemplo MySQL, Oracle, Cassandra,
HBase…
Mediante su interfaz gráfica, podemos crear un proceso de transformación [11]
que extraiga los datos de nuestras tablas en MySQL y las exporte a MongoDB con la
posibilidad de editar la estructura de estos datos mediante documentos embebidos o
referencias.

También contamos con la opción de integrar datos desde ficheros CVS o XML,
lo que nos proporciona versatilidad para extraer nuestros datos e importarlos a
MongoDB.
Además de todo esto, la versión de pago de pentaho nos permite realizar análisis
de datos sobre MongoDB [12] con, incluso, la posibilidad de crear cubos OLAP.
4.2 Aplicación de administración
Otra de las opciones de migración de SQL a MongoDB es la de utilizar la
herramienta de migración de MongoDB (mongoimport) o la funcionalidad de MongoVUE
para pasar la base de datos a MongoDB.
Esta transformación solo copiaría la estructura de tablas en colecciones y las
filas en documentos. Por lo tanto, nosotros como administradores de la base de datos
tendríamos que sustentar a nuestra aplicación de una semántica que permitiera respetar
las restricciones de integridad que tenía la base de datos relacional.

Capítulo V
Análisis de eficiencia de gestión de BigData en una aplicación de reconocimiento gestual
Análisis de eficiencia de gestión de BigData en
una aplicación de reconocimiento gestual
1 Herramienta de análisis de eficiencia de procesos de
análisis de BigData
Para poder analizar las prestaciones de las bases de datos en procesos de
análisis de BigData, he creado una herramienta que permitirá utilizar un proceso de
análisis y evaluar las prestaciones que tienen MySQL y MongoDB en cuanto a velocidad
y tamaño ( Figura 19 ). Como podemos observar en la Figura 20, para realizar la
experimentación hemos utilizado una aplicación de reconocimiento gestual sobre datos
generados por un sensor (Kinect).
Mediante esta experimentación podemos observar el funcionamiento de la
herramienta, así como extraer conclusiones sobre la inserción y exportación de datos
masivos en las dos bases de datos previamente citadas.

Capítulo V
Análisis de eficiencia de gestión de BigData en una aplicación de reconocimiento gestual
Figura 19 Arquitectura básica de la herramienta del análisis de eficiencia de
procesos de análisis para BigData
2 Aplicación de reconocimiento gestual
Hoy día existen múltiples escenarios equipados con una gran cantidad de
sensores para captar información de un ambiente concreto, como por ejemplo las
cámaras de un banco, las alarmas de las casas, dispositivos de videojuegos,
aplicaciones medioambientales, etc. El tratamiento y procesamiento, mediante técnicas
de inteligencia artificial, de los sensores y actuadores de estos entornos, se lleva a cabo
dentro del área de la Inteligencia Ambiental (AmI) [13].
Un tema de gran interés en los últimos años, en materia del aprendizaje y
reconocimiento de datos de sensores en AmI, consiste en la extracción de información
de patrones de comportamiento humano. Esta aplicación tiene una gran variedad de
usos, gracias a que, con esta tecnología, un computador podría, en cierto modo,
conseguir comunicarse con la persona mediante sus expresiones.

PFC

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

PFC