Post on 07-Feb-2020
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
Estudio del rendimiento de una base de datos columnar en el análisis de datos
Trabajo de titulación, modalidad proyecto de investigación previo a la obtención del
título de ingeniero informático
AUTORES: Tandazo Gaona Eduardo Javier
Durán Cazar Jhonatan Wilson
TUTOR: Ing. Mario Raúl Morales Morales
Quito, 2018
ii
DERECHOS DE AUTOR
Nosotros, Tandazo Gaona Eduardo Javier y Durán Cazar Jhonatan Wilson en calidad de
autores y titulares de los derechos morales y patrimoniales del trabajo de titulación
“ESTUDIO DEL RENDIMIENTO DE UNA BASE DE DATOS COLUMNAR EN EL
ANÁLISIS DE DATOS”, modalidad Proyecto de Investigación, de conformidad con el
Art. 114 del CÓDIGO ORGÁNICO DE LA ECONOMÍA SOCIAL DE LOS
CONOCIMIENTOS, CREATIVIDAD E INNOVACIÓN, concedemos a favor de la
Universidad Central del Ecuador una licencia gratuita, intransferible y no exclusiva para
el uso no comercial de la obra, con fines estrictamente académicos. Conservamos a
nuestro favor todos los derechos de autor sobre la obra, establecidos en la normativa
citada.
Así mismo, autorizamos a la Universidad Central del Ecuador para que realice la
digitalización y publicación de este trabajo de titulación en el repositorio virtual, de
conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior.
Los autores declaran que la obra objeto de la presente autorización es original en su forma
de expresión y no infringe el derecho de autor de terceros, asumiendo la responsabilidad
por cualquier reclamación que pudiera presentarse por esta causa y liberando a la
Universidad de toda responsabilidad.
Firma: _____________________ Firma: _____________________
Tandazo Gaona Eduardo Javier Duran Cazar Jhonatan Wilson
C.C.: 0802255851 C.C.: 1724433048
edujvvr.k15@gmail.com jhona_usa16@hotmail.com
iii
APROBACIÓN DEL TUTOR
En mi calidad de Tutor del Trabajo de Titulación, presentado POR JHONATAN
WILSON DURÁN CAZAR y EDUARDO JAVIER TANDAZO GAONA, para optar
por el Grado de Ingeniero en Informática; cuyo título es: ESTUDIO DEL
RENDIMIENTO DE UNA BASE DE DATOS COLUMNAR EN EL ANÁLISIS
DE DATOS, considero que dicho trabajo reúne los requisitos y méritos suficientes para
ser sometido a la presentación pública y evaluación por parte del tribunal examinador
que se designe.
En la ciudad de Quito, a los 14 días del mes de junio de 2018.
---------------------------------------------
Ing. Mario Raúl Morales Morales
DOCENTE-TUTOR
C.C.: 1709026577
iv
DEDICATORIA
A Dios.
A mis padres: Wilson Durán y Zandra Cazar.
A mis hermanos: Bryan, Vanessa y Jessica.
A mí enamorada Giovanella por su apoyo incondicional.
Por su ayuda, esfuerzo y apoyo que me
han brindado durante toda mi vida.
Jhonatan Durán
Dedico este trabajo a Dios
Por haberme permitido llegar a este punto
Y haberme dado salud para lograr mis objetivos, además
De su infinita bondad y amor.
A mis padres Judith Gaona, Eduardo Tandazo
Por ser el pilar fundamental en todo lo que soy,
En toda mi educación, tanto académica como de la vida.
A mis hermanos Diana y Cristian por estar conmigo y apoyarme siempre.
A mí enamorada Mónica que durante estos años de carrera
Ha sabido brindarme su apoyo incondicional.
Eduardo Tandazo
v
AGRADECIMIENTOS
Los autores expresan sus agradecimientos a:
A nuestras familias por su gran apoyo, esfuerzo y sacrificio en todos los aspectos de
nuestras vidas.
Nuestro tutor, Ing. Mario Raúl Morales Morales por su valiosa orientación, por ser un
gran docente y más aún un gran amigo, por brindarnos su confianza y valiosa amistad en
el trascurso de la carrera y en el desarrollo del presente proyecto.
A nuestras novias por estar siempre apoyándonos y ser una luz en nuestras vidas.
A nuestros amigos y compañeros por su apoyo, cariño y experiencias compartidas durante
esta gran etapa de nuestras vidas. Ya que sin ellos nos hubiéramos graduado antes.
vi
CONTENIDO
pág.
DERECHOS DE AUTOR ................................................................................................ ii
CERTIFICACIÓN DEL TUTOR .................................................................................... iii
DEDICATORIA .............................................................................................................. iv
AGRADECIMIENTOS .................................................................................................... v
CONTENIDO .................................................................................................................. vi
LISTA DE TABLAS ....................................................................................................... ix
LISTA DE FIGURAS ...................................................................................................... x
GLOSARIO ..................................................................................................................... xi
RESUMEN .................................................................................................................... xiii
ABSTRACT .............................................................. ¡Error! Marcador no definido.xiv
INTRODUCCION ............................................................................................................ 1
1. DEFINICION DEL PROBLEMA ............................................................................ 3
1.1. Estado del arte .................................................................................................... 3
1.2. Planteamiento del problema ............................................................................... 4
1.3. Justificación ....................................................................................................... 4
1.4. Hipótesis ............................................................................................................ 5
1.5. Objetivos ............................................................................................................ 5
1.5.1. Objetivo general ......................................................................................... 5
1.5.2. Objetivos específicos .................................................................................. 5
2. MARCO TEORICO .................................................................................................. 6
2.1. Antecedentes ...................................................................................................... 6
2.2. Base de datos SQL ............................................................................................. 7
2.3. Big data .............................................................................................................. 8
2.4. Plataforma tecnológica ...................................................................................... 9
vii
2.4.1. Arquitectura ................................................................................................ 9
2.4.2. Tecnología in-Memory ............................................................................. 10
2.5. In-memory DataBase ....................................................................................... 11
2.6. Base de datos NoSQL ...................................................................................... 11
2.6.1. Características ........................................................................................... 12
2.6.2. Clasificación base de datos NoSQL. ........................................................ 12
2.6.1. Comparación base de datos NoSQL ......................................................... 14
2.6.2. Limitaciones ............................................................................................. 15
2.7. Teorema de Brewer .......................................................................................... 16
2.7.1. Modelo ACID y BASE ............................................................................. 18
2.8. Base de datos orientado a columnas ................................................................ 19
2.8.1. Características funcionales ....................................................................... 20
2.8.2. Limitaciones ............................................................................................. 23
3. METODOLOGÍA ................................................................................................... 24
3.1. Tipo de investigación ....................................................................................... 25
3.2. Diseño de investigación ................................................................................... 25
3.3. Instrumentos y técnicas .................................................................................... 26
3.4. Procedimiento .................................................................................................. 27
4. CALCULOS Y RESULTADOS ............................................................................. 29
4.1. Determinar de la muestra ................................................................................. 29
4.2. Selección / Creación del conjunto datos .......................................................... 31
4.3. Diseñar el escenario de pruebas ....................................................................... 32
4.3.1. Consultas: ................................................................................................. 33
4.3.2. Entorno de pruebas ................................................................................... 34
4.4. Carga de datos .................................................................................................. 35
4.5. Mediciones ....................................................................................................... 36
4.6. Análisis de resultados ...................................................................................... 42
4.6.1. Resultados por escenario .......................................................................... 43
4.6.2. Resultados por consulta ............................................................................ 48
viii
5. DISCUSION............................................................................................................ 53
6. CONCLUSIONES .................................................................................................. 54
7. RECOMENDACIONES ......................................................................................... 56
CITAS BIBLIOGRAFICAS .......................................................................................... 57
ANEXOS ........................................................................................................................ 61
ix
LISTA DE TABLAS
pág.
Tabla 1.Comparación de algunas bases de datos NoSQL (Moniruzzaman & Hossain, 2013) ..... 15
Tabla 2.Cuadro comparativo de modelos ACID VS BASE ............................................................ 19
Tabla 3. Bases de datos para analizar rendimiento. ................................................................... 31
Tabla 4. Descripción campos archivo CSV ................................................................................... 32
Tabla 5. Escenario de pruebas..................................................................................................... 33
Tabla 6.Consulta dos (set de datos) para los cuatro escenarios ................................................. 34
Tabla 7. Especificaciones del equipo que se usa para evaluar los experimentos. ...................... 35
Tabla 8. Mediciones consulta 1 - primer escenario .................................................................... 37
Tabla 9. Mediciones consulta 2 – primer escenario .................................................................... 37
Tabla 10. Mediciones consulta 3 – primer escenario .................................................................. 37
Tabla 11. Mediciones consulta 1 – segundo escenario ............................................................... 38
Tabla 12. Mediciones consulta 2 – segundo escenario ............................................................... 38
Tabla 13. Mediciones consulta 3 – segundo escenario ............................................................... 39
Tabla 14. Mediciones consulta 1 – tercer escenario ................................................................... 39
Tabla 15. Mediciones consulta 2 – tercer escenario ................................................................... 40
Tabla 16. Mediciones consulta 3 – tercer escenario ................................................................... 40
Tabla 17. Mediciones consulta 1 – cuarto escenario .................................................................. 41
Tabla 18. Mediciones consulta 2 – cuarto escenario .................................................................. 41
Tabla 19. Mediciones consulta 3 – cuarto escenario .................................................................. 42
Tabla 20. Tiempos promedio de ejecución del primer escenario ............................................... 43
Tabla 21. Tiempos promedio de ejecución del primer escenario ............................................... 44
Tabla 22. Tiempos promedio de ejecución del tercer escenario ................................................ 46
Tabla 23. Tiempos promedio de ejecución del cuarto escenario ............................................... 47
Tabla 24. Tiempos promedio de ejecución primera consulta ..................................................... 48
Tabla 25. Tiempos promedio de ejecución segunda consulta .................................................... 49
Tabla 26.Tiempos promedio de ejecución tercera consulta ....................................................... 51
x
LISTA DE FIGURAS
pág.
Figura 1.Modelo de dato clave – valor ........................................................................................ 13
Figura 2. Modelo de base de datos orientado a columnas ......................................................... 13
Figura 3. Modelo de base de datos documentales ..................................................................... 14
Figura 4. Modelo de bases basadas en Grafo. (Fuente: https://neo4j.com/blog/the-top-10-
ways-to-get-to-know-neo4j/) ...................................................................................................... 14
Figura 5. Teorema de Brewer ...................................................................................................... 17
Figura 6. Operaciones de filas y columnas sobre un diseño de datos de filas y columnas
(Plattner & Leukert, 2015) ......................................................................................................... 20
Figura 7. Cuadrante mejores bases relacionales código abierto (Fuente:
https://www.g2crowd.com/categories/relational-databases?segment=small-business) ......... 30
Figura 8. Ranking bases de datos columnares (Fuente: https://db-
engines.com/en/ranking/wide+column+store) .......................................................................... 31
Figura 9. Gráfica tiempos de ejecución primer escenario. ......................................................... 43
Figura 10. Gráfica tiempos de ejecución segundo escenario. ..................................................... 45
Figura 11. Gráfica tiempos de ejecución tercer escenario. ......................................................... 46
Figura 12. Gráfica tiempos de ejecución cuarto escenario. ........................................................ 47
Figura 13. Gráfica tiempos de ejecución primera consulta ........................................................ 48
Figura 14. Gráfica en esferas tiempos de ejecución primera consulta ....................................... 49
Figura 15. Gráfica tiempos de ejecución segunda consulta ........................................................ 50
Figura 16. Gráfica esferas tiempos de ejecución segunda consulta ........................................... 50
Figura 17. Gráfica tiempos de ejecución tercera consulta .......................................................... 51
Figura 18. Gráfica tiempos de ejecución tercera consulta .......................................................... 52
xi
GLOSARIO
ACID (Atomicity, Consistency, Isolation and Durability): atomicidad, consistencia,
aislamiento y durabilidad en español. En bases de datos se denomina ACID se refiere a
un conjunto estándar de propiedades que garantiza que las transacciones de la base de
datos se procesen de manera confiable.
BASE (Basically Available, Soft state, Eventual consistency): el acrónimo BASE se usa
para describir las propiedades de ciertas bases de datos, generalmente bases de datos
NoSQL.
BI: siglas de Business Intelligence que significa inteligencia de negocios.
CAP (Consistency, Availability, Partition tolerance): el teorema de Brewer o CAP
establece que un sistema informático distribuido puede garantizar dos de las tres
propiedades al mismo tiempo.
Cloud Computing: computación en la nube es un paradigma que permite ofrecer servicios
de computación a través de una red, que usualmente es Internet.
CPU (Central Processing Unit): unidad central del procesamiento.
DBMS: sistema de gestión de base de datos.
ERP (Enterprise Resource Planning): significa “sistema de planificación de recursos
empresariales”. Estos programas se hacen cargo de distintas operaciones internas de una
empresa, desde producción a distribución o incluso recursos humanos.
ETL (Extracción, Transformación, Carga): es el proceso en el cual se toma datos de un
origen y mediante trasformación se procede a cargar en algun destino especificado.
IMDB (In Memory Data Base): en español significa Base de datos en memoria.
xii
RAM (Random Access Memory): Memoria de acceso aleatorio es donde el computador
guarda los datos que está utilizando en el momento presente. El almacenamiento es
considerado temporal por que los datos y programas permanecen en ella mientras que la
computadora este encendida o no sea reiniciada.
RDBMS: sistema de gestión de base de datos relacional.
SQL: lenguaje de consulta estructurada o por sus siglas en inglés Structured Query
Language.
Tupla: es una secuencia de valores agrupados.
xiii
TÍTULO: Estudio del rendimiento de una base de datos columnar en el análisis de datos
Autores: Jhonatan Wilson Durán Cazar
Eduardo Javier Tandazo Gaona
Tutor: Ing. Mario Raúl Morales Morales
RESUMEN
En la actualidad es decisivo para el éxito de las empresas la capacidad de procesar una
gran cantidad de datos de una amplia gama de fuentes en cualquier lugar y en cualquier
momento de manera eficiente. El análisis de datos se convierte en una estrategia clave
para la mayoría de las grandes organizaciones para lograr una ventaja competitiva. Por
tanto, surgen nuevas cuestiones a ser consideradas a la hora de almacenar y consultar
cantidades masivas de datos que, en general, las bases de datos relacionales tradicionales
no pueden abarcar. Estas cuestiones incluyen desde la capacidad de distribuir y escalar el
procesamiento o el almacenamiento físico, hasta la posibilidad de utilizar esquemas o
tipos de datos no usuales. El objetivo de esta investigación es proporcionar un instrumento
que facilite a los profesionales interesados en la analítica de datos una base para sus
conocimientos y el proyecto pueda servir como referencia de futuras investigaciones. El
primer capítulo consta de la fundamentación teórica, el segundo capítulo detalla la
metodología a usar y la justificación de su elección, el tercer capítulo realiza una
comparación entre base de datos columnares y relacionales para analizar su rendimiento.
Por último, se discutirá los resultados, conclusiones y recomendaciones.
PALABRAS CLAVES: BASES DE DATOS COLUMNAR / IN-MEMORY/
ANALISIS DE DATOS / RENDIMIETO / NOSQL
xiv
TITLE: Performance study of a core database in data analysis
Authors: Jhonatan Wilson Durán Cazar
Eduardo Javier Tandazo Gaona
Tutor: Ing. Mario Raúl Morales Morales
ABSTRACT
Companies’ capacity to efficiently process a great amount of data from a great variety of
sources anywhere and anytime is essential for them to succeed. Data analysis becomes a
key strategy for most of large organizations for them to get a competitive advantage.
Hence, when massive amounts of date are to be stored, new questionings arise for
consideration, because traditional relational database are not capable to lodge them. Such
questions include aspects that go from the capacity to distribute and escalate the physical
storage to the possibility of using schemes or non-usual types of data. The purpose of the
current investigation is providing an instrument that provides a knowledge base for
professionals interested in data analysis, so that the project can be used as a reference for
future investigations. The first chapter contains the theoretical fundamentals; the second
chapter shows details on the methodology to be used and the justification of the relevant
selection; the third chapter makes a comparison between core and relational database in
order to consider performance. Finally, results, conclusions and recommendations will be
discussed.
KEYWORDS: CORE DATABASE / IN-MEMORY / DATA ANALYSIS /
PERFORMANCE / NOSQL
1
INTRODUCCIÓN
Las bases de datos relacionales desde los años 80 han sido la opción predominante para
para almacenar datos estructurados de aplicaciones web y comerciales, teniendo su propio
lenguaje – Structured Query Language (SQL). Soluciones como bases de datos Oracle,
MySQL y Microsoft SQL han estado a la vanguardia en el ámbito de bases de datos
relacionales.
En un escenario donde los datos tienden a ser más diferentes que similares entre sí, la
estructura rígida de los sistemas relacionales dificulta enormemente su modelamiento.
El rendimiento se encuentra limitado por su escalamiento vertical, lo que no permite
distribuir la carga del sistema en múltiples máquinas sumado a la gran cantidad de
peticiones de lectura y escritura de forma concurrente, la propia complejidad de la lógica
detrás del funcionamiento de las bases de datos relacionales tiende a perder eficiencia en
relación con el crecimiento de los datos. Esto hace difícil responder con poca latencia en
el caso de aplicaciones que atienden un gran número de pedidos a la misma vez. Por tanto,
se hacen necesarios sistemas redundantes y fáciles de escalar que brinden un servicio de
alta escalabilidad y alta disponibilidad, para la gestión de altos volúmenes de datos y para
garantizar su disponibilidad (Robles, Sánchez, Serrano, Adárraga, & Heredia, 2015).
En la actualidad es decisivo para el éxito de las empresas la capacidad de procesar una
gran cantidad de datos de una amplia gama de fuentes en cualquier lugar y en cualquier
momento de manera eficiente. El análisis de datos se convierte en una estrategia clave
para la mayoría de las grandes organizaciones para lograr una ventaja competitiva. Por lo
tanto, durante los últimos diez años, el enfoque del negocio de gestión en todo el mundo
ha cambiado profundamente (Mihaela-Laura, 2014).
Emerge la necesidad de acrecentar el conocimiento en otro tipo de almacenamiento de
datos que cubra las deficiencias de las bases de datos relacionales. Los sistemas NoSQL
poseen las capacidades necesarias para cubrir estas falencias, entre los distintos tipos de
2
bases de datos NoSQL, se encuentra la familia de bases de datos columnares las cuales
manejan los datos de forma distinta a los manejadores de bases de datos relacionales, con
el objetivo de mejorar el proceso de analizar grandes volúmenes de datos.
El objetivo principal de esta investigación es evaluar el rendimiento de las bases de datos
columnares en el campo del análisis de datos. Realizar una comparación con bases de
datos de tipo relacional, para determinar su eficiencia, realizando mediciones en distintos
escenarios de pruebas.
El presente estudio pretende proporcionar (evidencia científica) un instrumento que
facilite a los profesionales interesados en la analítica de datos una base para sus
conocimientos, al incluir cuadros y tablas comparativos con datos cuantitativos con los
que se pueda sustentar las conclusiones de esta investigación. Al mismo tiempo, el
proyecto pueda servir como referencia para líneas futuras.
3
1. DEFINICIÓN DEL PROBLEMA
En esta sección, se determina el enfoque u orientación general, identificación del problema,
justificación, objetivos e hipótesis que se desea realizar en la investigación del rendimiento
de base de datos columnares en el análisis de datos.
1.1. Estado del arte
La gran mayoría de los sistemas actuales tienen implementadas bases de datos
relacionales, por ser las más tradicionales y más conocidas. Sin embargo, la actual
dinámica del mundo globalizado está poniendo a prueba la capacidad de estos sistemas:
las personas e instituciones utilizan redes sociales para interactuar; las universidades
implementan sistemas de e-learning; los bancos apoyan el comercio electrónico, el
mercado financiero y muchas actividades más que son producto del cambio hacia el
acceso a todos los servicios a través de internet, sobre todo con el auge del internet de las
cosas. Los sistemas NoSQL poseen las capacidades necesarias para apoyar este cambio y
avance tecnológico. Varios servicios empiezan a utilizar NoSQL, aunque otros son
dependientes de SQL y el cambio implicaría un gran costo operacional (Bonzi, 2017).
La situación actual consiste particularmente en que existen varios tipos de base de datos,
pero particularmente las de tipo “columnar” no son muy conocidas en el mercado local
(Áviles, 2011).
El crecimiento del sector tecnológico en los últimos años ha provocado en el entorno
socioeconómico un aumento desproporcionado en el volumen de datos e información.
Ello requiere la creación e implantación de nuevos sistemas de almacenamiento que se
ajusten a las nuevas necesidades. Las grandes empresas y organizaciones demandan cada
vez más el uso de nuevas tecnologías para almacenar su información y tratar su volumen
e inteligencia de negocio. Se pretende que esta información se gestione de una manera
rápida, fiable y eficaz. Esto también se aplica para las organizaciones de usuarios, quienes
demandan de manera creciente el uso de nuevas herramientas que resuelvan los
4
problemas derivados del aumento del volumen de información y que éstas se ajusten a las
características de las nuevas tecnologías (Borox, 2015).
1.2. Planteamiento del problema
En la actualidad la tecnología utilizada con más frecuencia en los diferentes sistemas
informáticos son bases de datos relacionales que son excelentes en el procesamiento de
transacciones, sin embargo, su rendimiento disminuye antes grandes volúmenes de datos
y si estos se encuentran menos estructurados.
Actualmente en las empresas una prioridad es poder obtener información relevante para
el negocio al procesar gran cantidad de información; con las bases de datos relacionales
podría llegar a consumir bastante tiempo y recursos el cual puede ser un factor que afecte
en costos y llegar a ser un desafío muy grande para los analistas y gestores de bases de
datos.
Aparece un problema para los manejadores de base de datos y analistas de grandes
cantidades de datos, en la elección de una mejor tecnología que supere las dificultades
que presentan las bases de datos relacionales para procesar y analizar grandes volúmenes
de datos estructurados y no estructurados.
1.3. Justificación
Debido al aumento exponencial en la cantidad de datos disponibles, a causa de redes
sociales, movilidad, aplicaciones, menor costo de la banda ancha, cloud computing, entre
otros. Dado el volumen y complejidad de los datos, las herramientas tradicionales de
bases de datos SQL y Business Intelligence pueden no dar abasto, implicando numerosos
riesgos para la empresa. Esto ha hecho que varias organizaciones recurran a nuevas
herramientas NoSQL y procesos para capturar, almacenar, procesar, analizar y sacarles
el mayor provecho a los datos con fines analíticos.
Entonces emerge la necesidad de acrecentar el conocimiento sobre las bases de datos
columnares las cuales manejan los datos de forma distinta a los manejadores de bases de
5
datos relacionales, con el objetivo de mejorar el proceso de analizar grandes volúmenes
de datos. y analizar cuáles son sus limitaciones y potencialidades en los diferentes
ambientes de trabajo para establecer un contexto en el que pueden ser más beneficioso
usar esta alternativa para el procesamiento de datos.
1.4. Hipótesis
El rendimiento de una base de datos columnar es óptimo en ambientes de análisis de datos
con altos volúmenes de datos.
1.5. Objetivos
1.5.1. Objetivo general
Estudiar el rendimiento de las bases de datos columnares en el análisis de datos.
1.5.2. Objetivos específicos
Identificar las potencialidades y limitaciones de una base de datos columnar en un
ambiente operacional.
Evaluar en diferentes escenarios el rendimiento de las bases de datos columnares.
Realizar la comparación y análisis de bases de datos columnares y bases de datos
relacionales para evaluar el rendimiento a través del tiempo de ejecución de una
consulta.
6
2. MARCO TEÓRICO
2.1. Antecedentes
De los muchos modelos de datos diferentes, el modelo relacional ha estado dominando
desde los años 80, con implementaciones como bases de datos Oracle, MySQL y
Servidores Microsoft SQL, también conocido como Sistema de Gestión de Base de Datos
Relacional (RDBMS) (Moniruzzaman & Hossain, 2013).
Debido al gran crecimiento de Internet de los últimos años y la llegada del fenómeno de
Big Data, surgen nuevas cuestiones a ser consideradas a la hora de almacenar y consultar
cantidades masivas de datos que, en general, las bases de datos relacionales tradicionales
no pueden abarcar. Estas cuestiones incluyen desde la capacidad de distribuir y escalar el
procesamiento o el almacenamiento físico, hasta la posibilidad de utilizar esquemas o
tipos de datos no usuales (Cattaneo, Nocera, & Rottoli, 2014).
En la actualidad es decisivo para el éxito de las empresas la capacidad de procesar una
gran cantidad de datos de una amplia gama de fuentes en cualquier lugar y en cualquier
momento de manera eficiente. El análisis de datos se convierte en una estrategia clave
para la mayoría de las grandes organizaciones para lograr una ventaja competitiva. Por lo
tanto, durante los últimos diez años, el enfoque del negocio de gestión en todo el mundo
ha cambiado profundamente (Mihaela-Laura, 2014).
En un escenario donde los datos tienden a ser más diferentes que similares entre sí, la
estructura rígida de los sistemas relacionales dificulta enormemente su modelamiento.
El rendimiento se encuentra limitado por su escalamiento vertical, lo que no permite
distribuir la carga del sistema en múltiples máquinas sumado a la gran cantidad de
peticiones de lectura y escritura de forma concurrente, la propia complejidad de la lógica
detrás del funcionamiento de las bases o a de datos relacionales, tiende a perder eficiencia
en relación con el crecimiento o de los datos. Esto hace difícil responder con poca latencia
7
en el caso de aplicaciones que atienden un gran número de pedidos a la misma vez. Por
tanto, se hacen necesarios sistemas redundantes y fáciles de escalar que brinden un
servicio de alta escalabilidad y alta disponibilidad, para la gestión de altos volúmenes de
datos y para garantizar su disponibilidad (Robles, Sánchez, Serrano, Adárraga, &
Heredia, 2015).
Antes de abordar como va a realizarse la investigación es necesario revisar ciertos
conceptos claves que han sido utilizados a lo largo del presente trabajo.
2.2. Base de datos SQL
El concepto de sistema de base de datos no es algo nuevo en la sociedad, sus predecesores
fueron los sistemas de ficheros, con el pasar del tiempo el uso de las bases de datos se
desarrollan debido a la necesidad de almacenar gran cantidad de información.
En 1970 se definió el modelo relacional del cual nacieron las primeras bases de datos
relacionales organizados como tablas (compuesta por filas y columnas) y su propio
lenguaje de consulta (Marqués, 2011). El principal éxito comercial de las bases de datos
relacionales fue el lenguaje SQL (Structured Query Language) diseñado e implementado
en IBM Research, ya que se convirtió en su lenguaje estándar (Ramez & Shamkant,
2015).
Los sistemas de administración de bases de datos relacionales toman el rol principal en
este campo, siendo las herramientas capaces de almacenar grandes cantidades de datos en
un formato simple y estructurado. Estos sistemas ofrecen cualidades indispensables en un
entorno transaccional siguiendo el modelo ACID (Atomicidad, Consistencia,
Aislamiento, Durabilidad). Donde todas las transacciones comprometidas son
correctamente completadas, y los datos son consistentes. Se convirtieron muy
rápidamente en las favoritas y vitales de las compañías de todo el mundo, a pesar de esto
el aumento constante de datos que se almacenan y analizan en las bases de datos
relacionales hacen que estas muestren una variedad de limitaciones, perdiendo eficiencia
en consultas de grandes volúmenes de datos, de igual forma en el almacenamiento y
administración (Abramova, Bernardino, & Furtado, 2014).
8
Aunque ha habido diferentes enfoques a lo largo de los años, como bases de datos de
objetos o tiendas XML estas tecnologías nunca han obtenido la misma adopción y
participación de mercado que los RDBMS. Esto debido a que la tecnología hace unos
años atrás no estaba tan desarrollada para dar el impulso a estos nuevos enfoques y tengan
mayor intervención en el mercado (Strauch, 2011).
2.3. Big data
Big Data ha evolucionado tan rápida y desordenadamente que no existe una declaración
formal universalmente aceptada que denote su significado. Ha habido muchos intentos de
definición de Big Data, más o menos popular en términos de utilización y citas. Sin
embargo, ninguna de estas propuestas ha impedido que los autores de trabajos
relacionados con Big Data extiendan, renueven o incluso ignoren las definiciones
anteriores y propongan otras nuevas. Aunque Big Data sigue siendo un concepto
relativamente joven, sin duda merece un vocabulario de referencia aceptado que permita
el correcto desarrollo de la disciplina entre los conocedores y los profesionales (Greco &
Grimaldi, 2015).
El mundo digital está creciendo muy rápido y se vuelve más complejo en el volumen
(terabyte a petabyte), variedad (estructurado y no estructurado e híbrido), velocidad (alta
velocidad en crecimiento) y naturaleza. Esto se conoce como el fenómeno global llamado
'Big Data'. Normalmente, esto se considera como una recopilación de datos que ha crecido
tanto que no se puede gestionar o explotar de manera efectiva utilizando herramientas de
gestión de datos convencionales: por ejemplo, sistemas de gestión de bases de datos
relacionales (RDBMS) o motores de búsqueda convencionales. Para manejar este
problema, los RDBMS tradicionales se complementan con un conjunto de sistemas de
gestión de bases de datos (DBMS) alternativo especialmente diseñado; tales como
NoSQL (Moniruzzaman & Hossain, 2013).
Otro autor define al Big Data como: Las tecnologías de Big Data tienen como objetivo
procesar datos (sets /assets) de gran volumen, alta velocidad y alta variedad para extraer
el valor de los datos previstos y garantizar una alta veracidad de los datos originales y
obtener información que exija una inversión rentable e innovadoras formas de
9
procesamiento de datos e información (análisis) para mejorar el conocimiento, la toma de
decisiones y el control de procesos; todos ellos exigen nuevos modelos de datos y nuevos
servicios y herramientas de infraestructura que permiten obtener datos de una variedad
de fuentes y entregando datos en una variedad de formas a diferentes consumidores y
dispositivos de datos e información (Demchenko, De Laat, & Membrey, 2014).
El análisis de datos es la fase final y la más importante en la cadena de valor de Big Data,
con el propósito de extraer valores útiles, proporcionar sugerencias o decisiones. Se
pueden generar diferentes niveles de valores potenciales a través del análisis de conjuntos
de datos en diferentes campos. Sin embargo, el análisis de datos es un área amplia, que
con frecuencia cambia y es extremadamente compleja (Chen, Mao, & Liu, 2014).
2.4. Plataforma tecnológica
La analítica empresarial y los conceptos relacionados que describen el análisis de los
datos comerciales para la toma de decisiones han recibido amplia atención tanto en la
comunidad académica como en la empresarial. La aparición de sistemas de bases de datos
en memoria se ha promovido aún más mediante procedimientos de gestión de datos
mejorados y arquitecturas de hardware multinúcleo que se han vuelto disponibles
recientemente (Hahn & Packowski, 2015).
2.4.1. Arquitectura
Algunos de los desarrollos más importantes de los últimos años en tecnología informática
son CPU multinúcleo y un aumento en la capacidad de memoria basada en una
arquitectura de 64 bits, que admite fácilmente terabytes de espacio directamente
direccionable. La arquitectura multinúcleo permite el procesamiento masivo en paralelo
de las operaciones de la base de datos, y dado que todos los datos relevantes se guardan
permanentemente en la memoria, el procesamiento se realiza a la mayor velocidad
posible. Las operaciones de lectura son completamente independientes de cualquier
acceso a dispositivos de almacenamiento de disco más lentos. Las operaciones de
escritura también tienen lugar en la memoria, pero también deben registrarse en un
10
almacenamiento no volátil para garantizar la persistencia de los datos (Plattner & Leukert,
2015).
La escalabilidad multinúcleo se ha vuelto igualmente importante. En la actualidad, las
bases de datos de la memoria principal se ejecutan en CPU con una asombrosa cantidad
de paralelismo, con cada generación de procesadores aumentando aún más el recuento de
núcleos. Por ejemplo, hoy en día, es común tener entre 16 y 32 núcleos de procesador en
un servidor que abarca múltiples sockets, mientras que las máquinas de alta gama tienen
hasta 144 núcleos (Larson & Levandoski, 2016).
2.4.2. Tecnología in-Memory
La tecnología In-Memory ha sido propiciada por la necesidad de procesamiento de
grandes volúmenes de datos de manera muy rápida y fundamentalmente por el desarrollo
de los procesadores y el incremento en la capacidad de memoria basada en la arquitectura
de 64-bits. Esto ha hecho posible el procesamiento paralelo masivo de las operaciones de
base de datos, albergando todos los datos relevantes en memoria (Morales & Morales,
2017). A diferencia de las bases de datos relacionales convencionales, las bases de datos
en memoria no necesitan que los datos se procesen desde un disco duro ni que se carguen
en la memoria, porque los datos ya están allí. Esto acorta dramáticamente el tiempo de
respuesta de la base de datos (Mihaela-Laura, 2014).
El surgir del Big Data está creando un cambio de paradigma arquitectónico en el
movimiento de datos. Las organizaciones se están moviendo de traer los datos hacia el
procesamiento (entiéndase como servidores) a empujar el procesamiento (distribuido)
hacia la data. El análisis de datos In-Memory, con las arquitecturas distribuidas y el
procesamiento paralelo masivo está ganando cada vez mayor impulso (Wixom & Otros,
2014).
La necesidad de rendimiento en el dominio de la Tecnologías de Información (TI)
combinado con las ventajas de la computación In-Memory son factores importantes que
han influenciado la aparición de bases de datos In-Memory. Una base de datos In-
Memory usa la memoria como el principal soporte de almacenamiento, comparado con
11
los clásicos sistemas de gestión de base de datos que usan el disco como lugar de
almacenamiento principal (Babeanu & Ciobanu, 2015).
2.5. In-memory DataBase
Se han estudiado desde la década de los 80, sin embargo, ha habido un aumento en su
interés en los últimos años. Las bases de datos tradicionales almacenan la data en disco y
las operaciones de I/O son muy lentas comparadas con aquellas hechas en memoria RAM.
In-Memory DataBase (IMDB) poseen una técnica de almacenamiento columnar lo que
posibilita el acceso a la data a grandes velocidades y capacidades de analítica en tiempo-
real (Morales & Morales, 2017).
Las IMDB constituyen un sistema de gestión de base de datos diseñadas para un alto
rendimiento con la condición de que exista suficiente memoria para mantener la data
necesaria en ella. Poseen una técnica de almacenamiento columnar lo que posibilita el
acceso a la data a grandes velocidades y capacidades de analítica en tiempo-real. En
comparación con Cloud Computing, el beneficio para el usuario es inmediatamente
entendible, porque viene de un rápido análisis de grandes volúmenes de datos (Mihaela-
Laura, 2014).
2.6. Base de datos NoSQL
Debido a las limitaciones que comenzaban a presentar las bases de datos relacionales, la
necesidad de un sistema de almacenamiento diferente era necesario, así comienza a tomar
fuerza las bases de datos No SQL, que cubren las limitaciones de los sistemas relacionales
convencionales, En comparación con las bases de datos relacionales, las bases de datos
NoSQL son más flexibles y escalables horizontalmente (Stonebraker M. , 2010).
La popularidad de las bases de datos NoSQL fue incrementado debido a la necesidad de
procesamiento rápido en grandes volúmenes de datos aprovechado las ventajas de su
arquitectura altamente escalable, estructura de datos flexible (libre de esquemas) y menor
latencia y alto rendimiento (Abdullah & Resul, 2013).
12
El término NoSQL fue acuñado por primera vez en 1998 por Carlos Strozzi, (Strozzi,
2013). Su origen también está relacionado con la creación del modelo BigTable de
Google. Este sistema de base de datos, BigTable, se usa para el almacenamiento de
proyectos desarrollados por Google, por ejemplo, Google Earth. Amazon posteriormente
desarrolló su propio sistema, Dynamo. Estos proyectos permitieron dar un paso hacia la
evolución de NoSQL (Abramova, Bernardino, & Furtado, 2014). El término NoSQL
comienza a ser utilizado mayormente a partir del año 2009, abarcando todas aquellas
tecnologías de bases de datos que no utilizan el lenguaje SQL estándar para la escritura
de sus consultas (Sadalage P, 2013).
2.6.1. Características
Estas características hacen que NoSQL sea idónea para trabajar con grandes cantidades
de datos y a su vez tan variados que son peculiaridades de Big Data (Strauch, 2011).
No se basan en un enfoque relacional.
Escala horizontalmente.
A menudo son productos de código abierto.
No necesita un esquema definido.
Proporcionar una API para la integración en otros productos de software.
Utilizan una arquitectura descentralizada para la fácil replicación de datos.
Sigue el principio BASE (Binani, Gutti, & Upadhyay, 2016).
2.6.2. Clasificación base de datos NoSQL.
Estas bases de datos pueden ser divididas en 4 categorías de acuerdo con diferentes
optimizaciones:
Base de datos Clave-Valor: Tienen un rendimiento excelente para volúmenes de datos
muy grandes, simples y sin funcionalidades, consisten en dos partes: una que representa
la clave, y el dato en sí, que se referencia como el valor en el par clave-valor (Gracia del
Busto & Yanes Enríquez, 2012). Las claves son usadas como índices para las búsquedas,
pudiendo estos ser compuestos formados por criterios distintos. Estas bases de datos
13
sacrifican la consistencia de los datos para obtener escalabilidad. Como punto débil, la
falta de un esquema hace mucho más difícil interpretar los datos. Ejemplos de estas bases
de datos son: Redis, RIAK y Amazon DynamoDB (Ameya & Anil, 2013).
Figura 1.Modelo de dato clave – valor
Base de datos orientada a columnas: En estas bases de datos, cada clave está
asociada con uno o más atributos (columnas), de manera que puedan ser accedidos
más rápidamente. Esto posee las ventajas de la posibilidad de escalar, brinda un
esquema más rígido que las bases de datos clave-valor, aun sacrificando la
consistencia. Estas tecnologías son apropiadas para la minería de datos (Ameya
& Anil, 2013). Tienen un parecido a las bases de datos relacionales, pero son muy
diferentes debido al almacenamiento de datos por columnas y su optimización en
consultas mejorando tiempos de respuesta. Ejemplos de bases de datos orientadas
a columnas son Cassandra y Big Table (Gracia del Busto & Yanes Enríquez,
2012).
Figura 2. Modelo de base de datos orientado a columnas
Bases de datos documentales o basadas en documentos: Fueron diseñados en
la forma abstracta de un documento para gestionar información de datos semi-
estructurados u orientada a documentos (Gracia del Busto & Yanes Enríquez,
2012). Dentro de estos documentos es posible anidar otros documentos
relacionados, como si se tratase de carpetas físicas. En sí, los documentos son muy
similares a los registros en las bases de datos tradicionales, pero mucho más
flexibles por su falta de esquemas. Los documentos son accesibles por medio de
claves únicas y la información que almacenan no tiene que estar normalizada. Los
Fila Clave 1
Valor 1 Valor 2
Columna 2
Columna 1
Key: USUARIO1 Value: Aníbal
Key: USUARIO2
Value: Jesica
Key: USUARIO3
Value: Isabel
14
blogs usualmente utilizan estas tecnologías, entre las cuales se pueden mencionar
MongoDB y CouchDB (Ameya & Anil, 2013).
Figura 3. Modelo de base de datos documentales
Bases de datos gráficas o basadas en grafos: En estas bases de datos se
almacenan su información en forma de nodos de un grafo y relaciones como
aristas de este (Gracia del Busto & Yanes Enríquez, 2012). Son muy eficientes
para manejar este tipo de relaciones, ya que utilizan algoritmos basados en la
teoría de grafos para ejecutar las consultas. Los datos almacenados son libres de
esquemas, por lo que cada nodo y cada relación pueden poseer atributos distintos.
Estas tecnologías son utilizadas para una amplia variedad de aplicaciones de redes
sociales, sistemas de recomendación, manejo de contenido, entre otras, siendo las
más utilizadas Neo4J, GraphBase, Infinite Graph (Ameya & Anil, 2013).
Figura 4. Modelo de bases basadas en Grafo. (Fuente: https://neo4j.com/blog/the-
top-10-ways-to-get-to-know-neo4j/)
2.6.1. Comparación base de datos NoSQL
15
En esta sección, se proporciona una evaluación de algunas de las bases de datos NoSQL
con una matriz en base a algunos atributos: diseño, integridad, indexación, distribución,
sistema. Ver tabla 1.
Tabla 1.Comparación de algunas bases de datos NoSQL (Moniruzzaman &
Hossain, 2013)
2.6.2. Limitaciones
16
Sin embargo, no es realista suponer que los almacenes de datos NoSQL son un reemplazo
de las bases de datos relacionales tradicionales. Como resultado de la naturaleza de código
abierto de NoSQL y la variedad de implementaciones que existen, no muchos estándares
confiables están disponibles, lo que hace que la portabilidad sufra. El rendimiento y la
escalabilidad a menudo se ponen antes de la consistencia y, como resultado, NoSQL a
menudo es una solución inaceptable cuando se trabaja con datos donde la consistencia es
crítica, como los registros de transacciones financieras. Los almacenes de datos NoSQL
pueden ser más fáciles de administrar, pero debido a la falta de madurez con esta nueva
tecnología, hay un número limitado de administradores y desarrolladores con el
conocimiento y las habilidades requeridas. Finalmente, los almacenes de datos NoSQL
pueden ser difíciles de usar para analizar e informar debido a la naturaleza de sus
implementaciones no estructuradas (Richard & Heather, 2014).
2.7. Teorema de Brewer
Debido a que el tamaño de los datos creció inmensamente, fue necesario encontrar más
soluciones escalables que las bases de datos ACID existentes hasta ahora. Como
resultado, se desarrollaron nuevos principios, resumido bajo el paradigma BASE (Basic
Availability, Soft-state, Eventual Consistency) (Simon, 2012).
Las propiedades de ACID se centran en la consistencia y son el enfoque tradicional de
las bases de datos. Brewer y su equipo crean BASE a finales de la década de 1990 para
capturar los enfoques de diseño emergentes para la alta disponibilidad y para hacer
explícitas tanto la elección como el espectro. Los sistemas modernos de área amplia a
gran escala, incluida la nube, usan una combinación de ambos enfoques. Esta discusión
exacta condujo al teorema (Brewer, 2012).
El teorema apareció por primera vez en el otoño de 1998. Fue publicado en 1993 y en el
discurso de apertura del Simposio sobre Principles of Distributed Computing en el año
2000. El objetivo del teorema Brewer era justificar la necesidad de explorar un espacio
de diseño más amplio, de ahí su formulación. Los diseñadores e investigadores han
utilizado el teorema de Brewer como una razón para explorar una amplia variedad de
novedosos sistemas distribuidos. El movimiento NoSQL también lo ha aplicado como
17
argumento contra las bases de datos tradicionales. En cierto sentido, el movimiento
NoSQL se trata de crear opciones que se enfocan primero en disponibilidad y luego en
consistencia; las bases de datos que se adhieren a las propiedades de ACID hacen lo
contrario (Brewer, 2012).
De acuerdo con el teorema cuando se trabaja en sistemas distribuidos es imposible
garantizar las tres características simultáneamente. Solo dos de las tres cualidades son
posibles, es necesario renunciar o bien sacrificar parcialmente una característica para
obtener las otras (Indrawan, 2012).
Consistencia (C) equivalente a tener una única copia actualizada de los datos.
Alta disponibilidad (A) de esos datos (para actualizaciones).
Tolerancia a las particiones de red (P).
Figura 5. Teorema de Brewer
Adaptado por los autores de (https://www.genbetadev.com/bases-de-datos/nosql-
clasificacion-de-las-bases-de-datos-segun-el-teorema-cap)
En la comunidad NoSQL, este teorema se ha utilizado como justificación para renunciar
a la consistencia reemplazando este objetivo con "consistencia eventual". Con esta noción
18
relajada, la justificación para renunciar a C es que se puedan preservar A y P (Stonebraker
M. , 2010).
La opción de renunciar a la Tolerancia de partición no es factible en entornos realistas,
ya que siempre se tiene particiones de red. Por lo tanto, se deduce que se debe decidir
entre Disponibilidad y Consistencia, que puede representarse mediante ACID
(Consistencia) y BASE (Disponibilidad). Sin embargo, Brewer reconoció que la decisión
no es binaria. Todo el espectro intermedio es útil; mezclar diferentes niveles de
disponibilidad y consistencia generalmente produce un mejor resultado (Simon, 2012).
Aunque los diseñadores aún deben elegir entre la coherencia y la disponibilidad cuando
las particiones están presentes, Aquí hay una increíble variedad de flexibilidad para
manejar particiones y recuperarse de ellas. El objetivo actual del teorema debe ser
maximizar las combinaciones de consistencia y disponibilidad que tienen sentido para la
aplicación específica. Tal enfoque incorpora planes para el funcionamiento durante una
partición y para la recuperación posterior, lo que ayuda a los diseñadores a pensar en el
teorema más allá de sus limitaciones históricamente percibidas (Brewer, 2012).
2.7.1. Modelo ACID y BASE
ACID y BASE representan dos filosofías de diseño en extremos opuestos del espectro de
disponibilidad-consistencia. Aunque ambos términos son más mnemotécnicos que
precisos, el acrónimo BASE (que es el segundo) es un poco más incómodo: Basically
Available, Soft state, Eventually consistent. Soft state y Eventually consistent son
técnicas que funcionan bien en presencia de particiones y, por lo tanto, promueven la
disponibilidad (Brewer, 2012).
La relación entre CAP y ACID es más compleja, en parte porque C(Consistencia) y
A(Atomicidad) en ACID representan diferentes conceptos que las mismas letras en CAP
y en parte porque elegir disponibilidad afecta solo algunas de las garantías de ACID
(Brewer, 2012).
Modelos Escalabilidad Disponibilidad Consistencia Tolerancia a fallos
B.A.S. E Alto Alto Bajo Alto
19
A.C.I. D Medio Bajo Alto Bajo
Tabla 2.Cuadro comparativo de modelos ACID VS BASE
La decisión que es mejor para un producto debe considerarse cuidadosamente. No hay
respuesta correcta. Se necesita ponderar cuidadosamente cuánto tiempo un usuario está
dispuesto a esperar la respuesta de un sistema y cuán tolerante es con las inconsistencias.
Por supuesto, el dinero también juega un papel importante para las aplicaciones
empresariales, y ha demostrado que, con esta restricción, los sistemas tienden más a la
disponibilidad: un usuario no quiere esperar demasiado tiempo en una aplicación web; él
prefiere leer datos temporalmente inconsistentes, ya que para muchas aplicaciones los
datos no son tan críticos como para ser consistentes (Simon, 2012).
2.8. Base de datos orientado a columnas
Los sistemas de bases de datos orientados a columnas, también conocidos como
almacenes de columnas, tienen una demanda importante en los últimos años.
Básicamente, se trata de almacenar cada columna de base de datos por separado para que
los atributos que pertenecen a la misma columna se almacenen de forma contigua,
comprimidos y empaquetados densamente en el disco. Este método tiene ventajas en la
lectura de registros es más rápido en comparación con los almacenes de fila clásicas en
las que cada fila se almacena uno tras otro en el disco y permite el acceso a grandes
volúmenes de datos de forma rápida porque se puede acceder como una unidad a los datos
de un atributo (columna) particular en una tabla (Yaman, 2012).
En formato columnar, todos los valores de un atributo de la tabla son almacenados como
un vector usando múltiples bloques de memoria y todos los vectores de atributos de una
tabla son almacenados secuencialmente. Matemáticamente ambos formatos son
comparables, pero su implementación técnica en memoria principal tiene cualidades muy
diferentes. Al organizar los valores en la forma de un vector de atributos permite una fácil
compresión de datos y también permite una alta velocidad de escaneo y filtraje. Esto
resulta en mucho procesamiento secuencial donde el formato columnar tiene una enorme
ventaja comparada con la tradicional base de datos de disco orientado a filas. Junto con
la opción de procesamiento paralelo, se puede alcanzar una muy alta velocidad para
20
filtraje o cualquier tipo de agregación (que constituyen algunas de las principales cargas
en procesamiento analítico). La velocidad es en efecto tan alta que se puede dejar de lado
la idea de pre-agregación de la data transaccional, la base de los sistemas de información
en las décadas pasadas. Además, ya no se requieren índices adicionales para acceso más
rápido a la data (Plattner & Leukert, 2015).
Figura 6. Operaciones de filas y columnas sobre un diseño de datos de filas y
columnas (Plattner & Leukert, 2015)
2.8.1. Características funcionales
Muchas características arquitectónicas más allá de los trabajos iniciales sobre
particionamiento vertical están diseñadas para maximizar el rendimiento en cargas de
trabajo analíticas en arquitecturas modernas. Las siguientes características son resultado
de investigación recientes, tendencias arquitectónicas y optimizaciones (Abadi, Boncz,
Harizopoulos, Idreos, & Madden, 2013).
Compresión
Una de las ventajas más citadas de los almacenes de columnas es la compresión de datos.
La compresión reduce claramente el espacio ocupado en el disco, además, dado que los
datos están comprimidos, se gasta menos tiempo en E / S mientras los datos se leen de un
disco. En las bases de columnas es más fácil resumir estas repeticiones de valores,
21
mientras que en los almacenes de fila es un proceso más complicado. En consecuencia,
la compresión tiene un gran impacto en el rendimiento de las consultas si se accede a un
alto porcentaje de columnas mediante una consulta (Yaman, 2012).
Entre las principales técnicas de compresión se tiene: Run-length Encoding, Transform-
based coding, Dictionary-based coding (Abadi, Madden, & Ferreira, 2006).
Virtual IDs
La forma más sencilla de representar una columna en un almacén de columnas implica
asociar un identificador de tupla (por ejemplo, una clave primaria numérica) con cada
columna. La representación explícita de esta clave aumenta el tamaño de los datos en el
disco y reduce la eficiencia de E / S. En cambio, los almacenes de columna modernos
evitan almacenar esta columna de ID. Utilizando la posición (offset) de la tupla en la
columna como un identificador virtual (Abadi, Boncz, Harizopoulos, Idreos, & Madden,
2013).
Materialización
En un motor de base de datos de columnas, aunque el cálculo intermedio podría basarse
en datos formateados en columnas, los resultados finales aún deben entregarse como
tuplas con formato de fila. La operación que transforma las columnas en filas se llama
materialización. Una estrategia de materialización temprana (Early Materialization- EM)
comenzará a formar tuplas formateadas en fila tan pronto como comience el
procesamiento de la consulta. Una estrategia de materialización tardía (Late
Materialization - LM), por el contrario, no comenzará a formar tuplas hasta que se haya
procesado una parte del plan de consulta (Liu, Mortazavi, Chen, & Otros, 2015).
Operación directa en datos comprimidos
22
Muchos almacenes de columnas modernos retrasan la descompresión de datos hasta que
sea absolutamente necesario, idealmente hasta que los resultados deban presentarse al
usuario. Trabajar sobre datos comprimidos mejora en gran medida la utilización del ancho
de banda de la memoria, que es uno de los principales cuellos de botella. La
materialización tardía permite que las columnas se mantengan en una representación
comprimida en la memoria, mientras que crear tuplas más amplias generalmente requiere
descomprimirlas primero (Abadi, Boncz, Harizopoulos, Idreos, & Madden, 2013).
Iteración por bloque
Para procesar una serie de tuplas, las tiendas de filas primero iteran a través de cada tupla,
y luego necesitan extraer los atributos necesarios de estas tuplas mediante una interfaz de
representación de tuplas, esto lleva a un procesamiento de tupla a la vez, donde hay 1-2
llamadas de función para extraer los datos necesarios de una tupla para cada operación,
en todos los almacenes de columnas, los bloques de valores de la misma columna se
envían a un operador en una sola llamada de función. Además, no se necesita la extracción
de atributos, y si la columna tiene un ancho fijo, estos valores se pueden iterar
directamente como una matriz. Operar sobre los datos como una matriz no solo minimiza
la sobrecarga por tupla, sino que también aprovecha el potencial para el paralelismo en
las CPU modernas (Abadi, Madden, & Hachem, 2008).
Implementación eficiente de operadores Join
Los operadores de Join presentan una gran cantidad de oportunidades para mejoras de
rendimiento en tiendas de columnas, pero estas oportunidades también pueden conducir
a cuellos de botella y complejidades si no se tratan adecuadamente. Finalmente, desde el
renacimiento de las tiendas de columnas a principios de la década de 2000, el trabajo en
Joins de MonetDB y C-store desencadenó una gran cantidad de trabajos de investigación
hacia Joins eficientes de memoria principal, estas investigaciones siguen las prácticas de
alto nivel adoptadas por primera vez en los almacenes de columnas como un enfoque en
el rendimiento de la memoria principal (Abadi, Boncz, Harizopoulos, Idreos, & Madden,
2013).
23
Una de las principales características citadas de los almacenes de columnas es la
compresión de datos. Almacenar datos de forma orientada a columnas aumenta en gran
medida la similitud de los registros adyacentes en el disco y, por lo tanto, las
oportunidades de compresión. La capacidad de comprimir muchas tuplas adyacentes a la
vez reduce el costo por tupla de la compresión, la sobrecarga de la CPU de iterar a través
de una página de los valores de columna tiende a ser menores que iterar a través de una
página de tuplas (especialmente cuando todos los valores en una columna son del mismo
tamaño), lo que permite una mayor velocidad de descompresión mediante el uso de
código vectorizado que aprovecha las propiedades super escalares de las CPU modernas
(Abadi, Madden, & Ferreira, 2006).
2.8.2. Limitaciones
Dos de las limitaciones más aludidas de los almacenes de columnas son las operaciones
de escritura y la construcción de tuplas. Las operaciones de escritura generalmente se
consideran problemáticas por dos razones: (a) las tuplas insertadas deben dividirse en sus
atributos de componente y cada atributo debe escribirse por separado, y (b) el diseño de
datos de paquete denso hace que mover las tuplas dentro de una página sea casi imposible.
Existen técnicas que utilizan los almacenes de columnas para mitigar sus problemas
fundamentales de escritura, como el almacenamiento en memoria intermedia, el
movimiento de tuplas y la fusión de particiones. La construcción de tupla también se
considera problemática ya que la información sobre una entidad lógica se almacena en
varias ubicaciones en el disco, aunque la mayoría de las consultas acceden a más de un
atributo de una entidad en algún punto de un plan de consulta, los datos de varias
columnas deben combinarse en 'filas' de información sobre una entidad (Abadi, Boncz,
& Harizopoulos, Column-oriented database systems, 2009).
Al utilizar la memoria RAM como almacenamiento principal, es un almacenamiento
volátil; por tanto, requiere el suministro de energía para mantener la información
almacenada, de otro modo se perderá su contenido durante un reset o cuando haya un
corte de energía. Entonces, el almacenamiento volátil podría causar vulnerabilidad y falta
de durabilidad para el sistema. Sin embargo, para alcanzar la durabilidad del sistema, hay
24
varias soluciones planteadas para soportar el almacenamiento de data de base de datos In-
Memory (Sakulsorn, 2013):
• On-line Backup: servicio de backup automático para la base de datos. Es la
solución más simple, y al mismo tiempo provee durabilidad en mínimo grado.
• Log de Transacciones: mantiene la historia de las acciones ocurridas después de
un checkpoint periódico. Estos archivos log deberían ser grabados en un
dispositivo no- volátil, tal como un disco duro, con el propósito de garantizar la
propiedad de durabilidad del sistema.
• Replicación de la base de datos: mantener copias replicadas de los datos se lo
conoce como implementación de alta disponibilidad. El sistema de replicación de
base de datos maneja la data distribuida sobre diferentes y múltiples nodos para
asegurar que ésta no se perderá aún en el caso de la falla de un nodo.
• NVRAM: dispositivo de memoria no-volátil la cual es llamada RAM estática con
un backup de suministro de energía. NVRAM es capaz de recuperar la base de
datos incluso sobre un reinicio. Diferente al Transaction Logging y la Replicación
de Base de Datos, esta solución no involucra ninguna latencia I/O de disco ni
sobrecarga de comunicación. Sin embargo, los fabricantes de base de datos
comerciales raramente proveen esta tecnología NVRAM debido al hecho de que
su costo es bastante caro aún.
3. METODOLOGÍA
25
La investigación científica es en esencia como cualquier tipo de investigación, sólo que
más rigurosa, organizada y cuidadosamente llevada a cabo. Como señala F. N. Kerlinger
(2002) es sistemática, empírica y crítica. Esto aplica tanto a estudios cuantitativos,
cualitativos o mixtos. Que sea sistemática implica que hay una disciplina para hacer
investigación científica y que no se dejan los hechos a la casualidad. Que sea empírica
denota que se recolectan y analizan datos. Que sea crítica quiere decir que se está
evaluando y mejorando de manera constante. Puede ser más o menos controlada, más o
menos flexible o abierta, más o menos estructurada, en particular bajo el enfoque
cualitativo, pero nunca caótica y sin método.
En el presente capítulo, se detalla el tipo de investigación, diseño, métodos, técnicas,
instrumentos con su respectiva validación, de toda información recolectada referente a al
tema tratado, y se definen los escenarios de pruebas.
3.1. Tipo de investigación
La presente investigación es de tipo aplicada, cuyo objetivo es usar los resultados
obtenidos para que sean utilizados inmediatamente en la solución de problemas
empresariales cotidianos. Se caracteriza porque busca la aplicación o utilización de los
conocimientos adquiridos, a la vez que se adquieren otros, después de implementar y
sistematizar la práctica basada en investigación (Vargas, 2009).
Esta definición se alinea al objetivo de esta investigación como es tener un panorama
claro a la hora de realizar un análisis de cantidades masivas de datos, de una amplia gama
de fuentes de una manera eficiente, por tanto, los resultados obtenidos al final podrán ser
inmediatamente aplicables.
3.2. Diseño de investigación
26
La presente investigación utiliza un diseño general descriptivo el cual indica lo siguiente:
Los estudios descriptivos buscan especificar las propiedades, las características y los
perfiles de personas, grupos, comunidades, procesos, objetos o cualquier otro fenómeno
que se someta a un análisis. Es decir, únicamente pretenden medir o recoger información
de manera independiente o conjunta sobre los conceptos o las variables a las que se
refieren, esto es, su objetivo no es indicar cómo se relacionan éstas (Sampieri &
Fernández C, 2010).
Teniendo en cuenta esta definición esta tesis tiene como finalidad ampliar y precisar qué
bases de datos tienen un mejor rendimiento en el análisis de datos y además busca
describir las características de estas bases por las cuales tienen una mejor eficiencia. Al
utilizar esta información los profesionales en software tendrán una herramienta
importante de competitividad.
Existen varios tipos de investigación descriptiva, se ha escogido el tipo de investigación
descriptiva cuantitativa comparativa que plantea lo siguiente:
Los estudios descriptivos comparativos analizan la forma como varían algunas
características entre dos o más grupos de interés. Este diseño usa dos o más
investigaciones descriptivas simples puesto que se recolecta información relevante con
respecto a un mismo fenómeno y luego se comparará los datos recogidos (Sampieri &
Fernández C, 2010).
Por tanto, se eligió este tipo de investigación descriptiva porque se ajusta al estudio en
donde se analiza como varía el tiempo de ejecución de distintos tipos de consultas en dos
grupos bases de datos tipo SQL y bases de datos tipo NoSQL. Una vez obtenida esta
información se procederá a compararla y obtener resultados que dará un panorama en el
rendimiento de distintas bases de datos en el campo del análisis de datos.
3.3. Instrumentos y técnicas
27
El presente estudio usa como instrumento pruebas estandarizadas ya que se desea analizar
el rendimiento de base de datos columnares, para este objetivo se compara dos grupos de
bases de datos: columnares y relacionales. Las cuáles serán sometidas a pruebas
específicas que reflejarán su eficiencia a través del tiempo de ejecución de una consulta.
3.4. Procedimiento
El estudio comparativo se realizó aplicando el siguiente procedimiento:
1. Determinar la muestra: primero se seleccionará los motores de base de datos
columnares y relacionales respectivamente, en los cuales se realizará las
respectivas pruebas para evaluar su rendimiento.
2. Selección / Creación del conjunto datos: seguidamente se seleccionará o
creará el conjunto de datos que serán cargados a las respectivas bases de datos
para realizar las pruebas. Estos pueden ser creados por los investigadores o
pueden seleccionar un conjunto de datos ya existente especificando su
procedencia y esta sea confiable y verificable.
3. Diseñar el escenario de pruebas: una vez definida la muestra de bases de
datos y seleccionado o creado el conjunto de datos con los que se realizarán
las pruebas, el siguiente paso será establecer cómo se realizaran las pruebas,
qué consultas se realizarán en la base de datos, el número de mediciones que
se efectuarán, especificar qué se medirá y con cuántos datos se realizarán las
pruebas, si se ocupará el conjunto completo de datos o se dividirán los datos,
esto depende del análisis del investigador.
• Entorno de pruebas: adicionalmente se debe especificar la
infraestructura donde se ejecutarán las pruebas, debe detallar las
características tanto de hardware como de software que tendrá el equipo.
28
4. Carga de datos: una vez establecido nuestro escenario de pruebas en donde
definimos que cantidades de datos se manejarán, se procede a la carga de datos
en todas las bases de datos anteriormente ya seleccionadas.
5. Medición: una vez bien definidos los pasos anteriores, se procede a realizar
las mediciones en los distintos escenarios que establecimos y registrando los
resultados para su posterior procesamiento y análisis.
6. Análisis de resultados: por último, se realiza la interpretación de los
resultados, tablas, graficas, entre otros, que arrojan las mediciones. Que
desembocará en el análisis y discusión de estos resultados.
29
4. CALCULOS Y RESULTADOS
A continuación, se detallará el procedimiento para realizar los cálculos y posteriormente
se presentará los resultados obtenidos.
4.1. Determinar de la muestra
Antes de escoger la muestra, se estableció que nuestra población son todas las bases de
datos columnares y base de datos relacionales existentes actualmente hasta el desarrollo
de la presente investigación.
Para la elección de la muestra se usó un muestreo no probabilístico por criterio, este es el
mejor tipo de muestreo no probabilístico. El muestreo se realiza sobre la base del
conocimiento y criterios del investigador. Se basa, primordialmente, en la experiencia
con la población. En algunas oportunidades, se usan como guía o muestra tentativa para
decidir cómo tomar una muestra aleatoria más adelante (Horna, 2012).
Los criterios de inclusión y exclusión para la delimitación poblacional son los siguientes:
Base de datos de código abierto (sin licencia).
Experiencia de los investigadores.
Por tanto, las bases de datos a elegir serán versiones no comerciales, que no necesitan
licencia y sean multiplataforma. Bajo estos criterios se ha elegido la siguiente muestra
para base de datos relacionales:
MySQL Community Edition v.8.0
PostgreSQL v.9.6.9
Estas dos bases de datos de código abierto han sido elegidas porque sus características en
general destacan de otras similares. Como se ve en la figura 7 hay varias opciones, todas
comparten características similares: la existencia de una potente comunidad atrás que da
soporte, la posibilidad de ver y editar el código si es necesario y son gratuitas. Sin
30
embargo, hay dos que destacan del resto, MySQL y PostgreSQL por su presencia en el
mercado y satisfacción del cliente.
Figura 7. Cuadrante mejores bases relacionales código abierto (Fuente:
https://www.g2crowd.com/categories/relational-databases?segment=small-
business)
Continuando, para la muestra de bases de datos NoSQL y siguiendo similares criterios se
ha seleccionado las siguientes:
Cassandra v.3.1.0
MonetDB
MongoDB
Estas alternativas se eligieron por ser de código abierto y de gran utilización, sus
características como escalabilidad, tolerancia a fallos, almacenamiento columnar junto
con su almacenamiento en memoria las hacen pioneras entre sus pares. Otro factor que se
tomó en cuenta es que ambas pueden interpretar sintaxis SQL, esto es de gran ayuda para
profesionales que están acostumbrados a manipular lenguaje SQL porque reduce el
impacto de cambiar a un ambiente NoSQL el cual es muy diferente. MongoDB si bien no
es una base de datos columnar, es un tipo de base de datos NoSQL, específicamente
31
documental, se la seleccionó para comparar las bases columnares, no solo con bases de
datos SQL, sino también con otro tipo de base de datos NoSQL, en este caso documental.
Adicional MongoDB también usa tecnología in-memory. La figura 8 muestra el ranking
de base de datos orientadas a columnas, donde Cassandra predomina en el primer lugar.
Figura 8. Ranking bases de datos columnares (Fuente: https://db-
engines.com/en/ranking/wide+column+store)
Por tanto, la muestra final tendrá las siguientes bases de datos expuestas en la tabla 3,
donde se detalla a qué familia de base de datos pertenece y la versión con la que se
trabajará en el transcurso de la investigación.
Nombre base de datos Tipo base de datos Versión
MySQL Relacional -SQL 8.1.0
PostgreSQL Relacional -SQL 9.6.2
Cassandra Columnar – NoSQL 3.1.0
MonetDB Columnar - NoSQL 11.29.3
MongoDB Documental - NoSQL 3.6.5
Tabla 3. Bases de datos para analizar rendimiento.
4.2. Selección / Creación del conjunto datos
Para evaluar y comparar el rendimiento de las bases de datos, se ha seleccionado un
conjunto de datos ya existente que se obtuvo de la siguiente fuente pública:
32
(https://www.kaggle.com/c/favorita-grocery-sales-forecasting/data). Corresponde a las
ventas de la Corporación La Favorita en sus diferentes tiendas ubicadas en Ecuador,
ventas realizadas entre los años 2015-2016. La cantidad de registros que contiene este
archivo es 125.000.000 (125 millones). Los datos están grabaros sobre archivos CSV para
su fácil y uniforme acceso. La descripción de los campos contenidos en el archivo se
muestra a continuación en la tabla 4.
Campo Tipo Descripción
Id INT Identificador único
Date DATE Fecha de registro del producto
Store_nbr INT Indica el número identificador de las tiendas
Ítem_nbr INT Indica el número identificador de los productos
Unit_sales DECIMAL Indica el número de unidades vendidas siendo:
un número entero, si son valores negativos
representan retornos de ese artículo en particular
onpromotion BOOLEAN Indica si ítem estaba en promoción para un
especifico date y store
Tabla 4. Descripción campos archivo CSV
4.3. Diseñar el escenario de pruebas
Para diseñar el escenario de pruebas se ha tomado en cuenta el número total de registros,
la información de acuerdo con la descripción de sus ítems para el desarrollo de las
consultas, ya que lo que se pretende medir es su tiempo de ejecución.
Por lo tanto, primero se ejecutarán las pruebas con cargas incrementales de datos, es decir
el archivo principal de datos que contiene 125 millones de registros se lo dividirá de la
siguiente manera: 1 millón, 10 millones, 25 millones y 50 millones de registros. Ahora se
tienen cuatro archivos los cuales será nuestros cuatro escenarios distintos, estos cuatro
archivos contienen el mismo número de columnas y tipo de datos. En estos cuatro
escenarios se ejecutará las consultas en todas las bases de datos. Con esto poner a prueba
el rendimiento de las bases de datos relacionales frente a las columnares en iguales
33
escenarios. Las especificaciones de los escenarios de prueba se detallan en la siguiente
tabla.
Especificaciones Escenario 1 Escenario 2 Escenario 3 Escenario 4
Tamaño de datos 1.000.000 10.000.000 25.000.000 50.000.000
Variable Tiempo de ejecución (ms)
Descripción
Se ejecutará tres tipos de Consultas:
- Tipo clave-valor
- Set de datos
- Función de agregación.
Políticas de
Consulta
Consultas a una tabla para las bases de datos relacionales y base
de datos columnares
Tabla 5. Escenario de pruebas
4.3.1. Consultas:
Posteriormente se procedió al diseño de las consultas que servirán para medir el tiempo
de respuesta con el cual se podrá observar el rendimiento de las bases de datos
seleccionadas. Para ello se ha tomado diferentes tipos de consultas, que devuelven
resultados distintos, además las bases de datos manejan estas consultas de distinta forma
y son usadas comúnmente en el análisis de datos. A continuación, se adjuntan los tres
tipos de consultas que se ejecutarán en nuestros cuatro escenarios de pruebas ya definidos.
Primera consulta (Clave-Valor):
Este tipo de consulta devuelve un solo registro de todo el conjunto de datos, el cuál será
buscado en la base por una clave (id).
SELECT id, item_nbr, store_nbr, date
FROM train
WHERE id = 500023352;
34
Segunda consulta (clausula where - Set de Datos):
Para el diseño de esta consulta se tomó en consideración lo siguiente: el set de datos
resultante debe retornar por lo menos un tercio o más del total de datos en cada escenario,
por lo tanto, se tuvo cuatro consultas, una por cada escenario. Como se observa en la
siguiente tabla en cada consulta cambia la fecha para devolver aproximadamente el 30%
de datos del total.
ESCENARIOS CONSULTA # DATOS
DEVUELOS
Primer
escenario
(1 Millón)
SELECT id, item_nbr, store_nbr, date FROM
train1m WHERE date >= '2015-07-05'; 388.964
Segundo
escenario
(10 Millón)
SELECT id, item_nbr, store_nbr, date FROM
train10m WHERE date >= '2015-09-15';
3.392.156
Tercer
escenario
(25 Millón)
SELECT id, item_nbr, store_nbr, date FROM
train25m WHERE date >= '2015-12-31'; 8.637.780
cuarto
escenario
(50 Millón)
SELECT id, item_nbr, store_nbr, date FROM
train50m WHERE date >= '2016-06-25'; 16.907.734
Tabla 6.Consulta dos (set de datos) para los cuatro escenarios
Tercera consulta (Función de Agregación):
La consulta usará la función de agregación SUM() para calcular las ventas totales de una
tienda determinada.
SELECT SUM(unit_sales)
FROM train
WHERE store_nbr = ‘12’
4.3.2. Entorno de pruebas
Para la infraestructura donde se realizarán las mediciones se tomó en consideración los
siguientes aspectos:
35
Se trabajará con base de datos columnares las cuales por su funcionamiento
almacenan datos en memoria, por tanto, el equipo deberá tener una adecuada
cantidad de memoria para que los resultados no se vean afectados por falta de ésta.
Para el tipo de base NoSQL existe mayor documentación, tutoriales, entre otros,
en ambientes Linux, esto motivó a que se escogiera un sistema operativo que
pertenezca a esta categoría. Sin embargo, queda a elección de los investigadores
elegir el sistema operativo que más se adecuen a su experiencia o necesidades.
Las pruebas se realizaron en un único equipo con las características descritas en la tabla7:
Software / Hardware Descripción
Sistema Operativo Ubuntu 14.04 (64- bits)
Memoria RAM 16 GB
Procesador AMD Radeon R7, 12 compute Cores 4C +
8G – 3.70 GHz
Disco Duro 1 TeraByte
Tabla 7. Especificaciones del equipo que se usa para evaluar los experimentos.
4.4. Carga de datos
Para este proceso se utilizó la herramienta de Pentaho para realizar procesos de ETL
(extracción, transformación, carga) llamada Pentaho Data Integration, esta herramienta
permite cargar archivos con la extensión CSV y migrar a distintos destinos entre los
cuales están las bases de datos que de interés, PostgreSQL, MySQL, Cassandra y
MonetDB, con esto se aseguró de migrar correctamente los datos.
Previamente a realizar la migración se creó todas las tablas a usar en las diferentes bases
de datos, la sintaxis varía de base a base incluido algunos tipos de datos por lo que se
recomienda revisar la documentación. Se recalca que en la creación de las tablas para las
bases de datos relacionales se usó una Primary Key (PK). Los scripts de creación de tablas
en las diferentes bases de datos se pueden observar en el anexo A.
36
Los detalles del procedimiento para la carga de datos en las diferentes bases de datos están
fuera del alcance de este estudio, ya que no es el objetivo de esta investigación sin
embargo en el anexo B se puede observar los parámetros configurables para la migración
a una base de datos.
4.5. Mediciones
Una vez completados los anteriores pasos se procede a ejecutar las respectivas consultas
en cada escenario para registrar los tiempos de respuesta de cada base de datos, para este
fin se utilizó la herramienta Aqua Data Studio que es una herramienta gráfica para tareas
de administración, diseño y consulta en diferentes bases de datos, con el objetivo de que
las mediciones sean más confiables y evitar el error humano en mediciones. En el anexo
C se indica la configuración de esta herramienta para la realización de las mediaciones.
Para tener un óptimo resultado, en la recolección de los valores de cada consulta se
procedió a tomar cinco mediciones en cada consulta para cada tamaño de datos elegido y
obtener un promedio, el cuál será el que represente el tiempo definitivo para esa consulta.
Todos los valores que se obtienen de la herramienta Aqua Data Studio se los almacenó
en una hoja de cálculo Excel para su posterior procesamiento y análisis. Los valores
obtenidos se observan en las siguientes tablas:
Primer Escenario – 1 millón de datos
CONSULTA 1 (CLAVE -VALOR):
SELECT id, item_nbr, store_nbr, date
FROM train1m
WHERE id = 500023352;
37
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 2 1 2 3 2 2,0
POSTGRESQL SQL 10 10 8 9 8 9,0
MONGODB NoSQL 2 3 3 2 4 2,8
MONETDB NoSQL 5 3 3 4 5 4,0
CASSANDRA NoSQL 4 3 3 4 3 3,4
Tabla 8. Mediciones consulta 1 - primer escenario
CONSULTA 2 (SET DE DATOS):
SELECT id, item_nbr, store_nbr, date
FROM train1m
WHERE date >= '2015-07-05';
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 515 594 547 484 516 531,2
POSTGRESQL SQL 462 468 460 497 453 468,0
MONGODB NoSQL 130 124 114 110 189 133,4
MONETDB NoSQL 191 184 190 189 211 193,0
CASSANDRA NoSQL 3 12 11 8 13 9,4
Tabla 9. Mediciones consulta 2 – primer escenario
CONSULTA 3 (FUNCIÓN DE AGREGACIÓN):
SELECT SUM(unit_sales)
FROM train1m
WHERE store_nbr = ‘12’
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 359 344 360 343 359 353,0
POSTGRESQL SQL 155 156 158 155 153 155,4
MONGODB NoSQL 72 64 70 88 68 72,4
MONETDB NoSQL 83 96 81 84 84 85,6
CASSANDRA NoSQL 69 72 61 49 62 62,6
Tabla 10. Mediciones consulta 3 – primer escenario
38
Segundo Escenario – 10 millones de datos
CONSULTA 1 (CLAVE -VALOR):
SELECT id, item_nbr, store_nbr, date
FROM train10m
WHERE id = 500023352;
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 4 1 2 2 3 2,4
POSTGRESQL SQL 9 10 11 10 11 10,2
MONGODB NoSQL 4 2 2 3 4 3,0
MONETDB NoSQL 5 4 4 5 5 4,6
CASSANDRA NoSQL 5 5 4 6 5 5,0
Tabla 11. Mediciones consulta 1 – segundo escenario
CONSULTA 2 (SET DE DATOS):
SELECT id, item_nbr, store_nbr, date
FROM train10m
WHERE date >= '2015-09-15';
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 6375 6141 6469 6672 6453 6422,0
POSTGRESQL SQL 4960 5739 4720 4119 5420 4991,6
MONGODB NoSQL 249 255 246 262 245 251,4
MONETDB NoSQL 267 287 248 235 305 268,4
CASSANDRA NoSQL 15 35 16 14 22 20,4
Tabla 12. Mediciones consulta 2 – segundo escenario
39
CONSULTA 3 (FUNCIÓN DE AGREGACIÓN):
SELECT SUM(unit_sales)
FROM train10m
WHERE store_nbr = ‘12’
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 4984 3437 3547 3469 3485 3784,4
POSTGRESQL SQL 1447 1411 1551 1489 1527 1485,0
MONGODB NoSQL 632 588 590 596 628 606,8
MONETDB NoSQL 716 724 704 705 694 708,6
CASSANDRA NoSQL 523 538 525 521 518 525,0
Tabla 13. Mediciones consulta 3 – segundo escenario
Tercer Escenario – 25 millones de datos
CONSULTA 1 (CLAVE -VALOR):
SELECT id, item_nbr, store_nbr, date
FROM train25m
WHERE id = 500023352;
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 3 2 3 4 2 2,8
POSTGRESQL SQL 11 14 12 12 14 12,6
MONGODB NoSQL 2 3 2 4 3 2,8
MONETDB NoSQL 6 6 5 4 4 5,0
CASSANDRA NoSQL 6 4 6 4 4 4,8
Tabla 14. Mediciones consulta 1 – tercer escenario
40
CONSULTA 2 (SET DE DATOS):
SELECT id, item_nbr, store_nbr, date
FROM train25m
WHERE date >= '2015-12-31';
TIEMPO EN (ms)
PROMEDIO
Tipo de base de
datos M1 M2 M3 M4 M5
MySQL SQL 14500 14750 14593 14641 16125 14921,8
POSTGRESQL SQL 12604 12870 12121 11930 11883 12281,6
MONGODB NoSQL 147 130 153 131 124 137,0
MONETDB NoSQL 406 404 419 397 413 407,8
CASSANDRA NoSQL 17 8 13 13 22 14,6
Tabla 15. Mediciones consulta 2 – tercer escenario
CONSULTA 3 (FUNCIÓN DE AGREGACIÓN):
SELECT SUM(unit_sales)
FROM train25m
WHERE store_nbr = ‘12’
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 10781 10937 10579 9204 9078 10115,8
POSTGRESQL SQL 4660 3778 4846 4109 3709 4220,4
MONGODB NoSQL 1488 1765 1776 1487 1454 1594,0
MONETDB NoSQL 1818 2513 1823 1799 1788 1948,2
CASSANDRA NoSQL 1855 1715 1936 1962 2017 1897,0
Tabla 16. Mediciones consulta 3 – tercer escenario
41
Cuarto Escenario – 50 millones de datos:
CONSULTA 1 (CLAVE -VALOR):
SELECT id, item_nbr, store_nbr, date
FROM train50m
WHERE id = 500023352;
TIEMPO EN (ms) PROMEDIO
Tipo de base de datos M1 M2 M3 M4 M5
MySQL SQL 3 3 5 2 3 3,2
POSTGRESQL SQL 12 13 15 12 13 13,0
MONGODB NoSQL 4 3 2 2 3 2,8
MONETDB NoSQL 5 4 4 4 4 4,2
CASSANDRA NoSQL 7 4 11 6 9 7,4
Tabla 17. Mediciones consulta 1 – cuarto escenario
CONSULTA 2 (SET DE DATOS):
SELECT id, item_nbr, store_nbr, date
FROM train50m
WHERE date >= '2016-06-25';
TIEMPO EN (ms)
PROMEDIO
Tipo de base de
datos M1 M2 M3 M4 M5
MySQL SQL 28625 28829 29891 29828 29953 29425,2
POSTGRESQL SQL 24369 24709 26570 25182 26190 25404,0
MONGODB NoSQL 295 298 292 293 296 294,8
MONETDB NoSQL 779 718 654 656 767 714,8
CASSANDRA NoSQL 19 8 11 25 14 15,4
Tabla 18. Mediciones consulta 2 – cuarto escenario
42
CONSULTA 3 (FUNCIÓN DE AGREGACION):
SELECT SUM(unit_sales)
FROM train50m
WHERE store_nbr = ‘12’
TIEMPO EN (ms)
PROMEDIO
Tipo de base de
datos M1 M2 M3 M4 M5
MySQL SQL 21172 21266 21125 20641 20562 20953,2
POSTGRESQL SQL 7930 8110 9876 8504 8179 8519,8
MONGODB NoSQL 3196 3337 3446 2978 3667 3324,8
MONETDB NoSQL 3791 4058 3745 3629 4424 3929,4
CASSANDRA NoSQL 2989 3212 3015 3172 2905 3058,6
Tabla 19. Mediciones consulta 3 – cuarto escenario
4.6. Análisis de resultados
A continuación, se muestra los resultados y la interpretación de los datos obtenidos en la
presente investigación. Los resultados que se analizan aquí muestran cómo las bases de
datos responden a las consultas en cada escenario que se ha definido anteriormente,
mediante el tiempo de respuesta para cada una de ellas. Como se explicó la métrica para
analizar los resultados es a través del tiempo de ejecución en milisegundos, para ello se
ha ejecutado cada consulta 5 veces y el tiempo que se mostrará aquí es el promedio de
éstas. En base a estos resultados se puede sacar las respectivas conclusiones del estudio.
Los resultados se presentan de dos maneras: los primeros resultados son los
correspondientes al tiempo de ejecución por escenario, es decir los tiempos promedio de
consulta en el primer escenario con un millón de registros, el segundo escenario con diez
millones de registros y así sucesivamente, completando todos los escenarios. La segunda
corresponde a los tiempos de ejecución por consulta aquí los resultados se agrupan por
las tres consultas realizadas como se observa a continuación en las siguientes tablas y
gráficos.
43
4.6.1. Resultados por escenario
En las siguientes subsecciones se presentan y analizan los tiempos promedio en
milisegundos resultantes de la ejecución de las 3 consultas en los cuatro escenarios con
1,10, 25 y 50 millones de datos y un gráfico respectivamente para apreciar visualmente
de una manera más adecuada.
Primer escenario – 1 millón de datos
La tabla 32 muestra los resultados en milisegundos, obtenidos durante la ejecución de las
tres consultas con un total de 1 millón de datos.
PRIMER ESCENARIO
TIEMPO EN (ms)
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
MySQL 2,0 531,2 353,0
PostgreSQL 9,0 468,0 155,4
MongoDB 2,8 133,4 72,4
MonetDB 4,0 193,0 85,6
Cassandra 3,4 9,4 62,6
Tabla 20. Tiempos promedio de ejecución del primer escenario
Figura 9. Gráfica tiempos de ejecución primer escenario.
0,0
100,0
200,0
300,0
400,0
500,0
600,0
MySQL PostgreSQL MongoDB MonetDB Cassandra
Tiem
po
(ms)
Base de datos
Primer Escenario - 1M
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
44
La figura 9 correspondiente al primer escenario, se observa la eficiencia de cada base de
datos en las tres consultas realizadas con un millón de registros. Para la primera consulta
de tipo clave / valor, no se observan cambios en los tiempos de ejecución entre las bases
de datos comparadas, al contrario, el tiempo de respuesta en todas es semejante. En la
segunda consulta donde se usa una cláusula where que retorna un set de datos, ya se
observa variaciones entre el rendimiento de las bases de datos, en donde MySQL muestra
el peor tiempo de respuesta con 531,2 milisegundos seguida de Postgres, a comparación
de la base de datos columnar Cassandra que presenta un tiempo de respuesta de 9, 4
milisegundos, esto es un tiempo 56,51 veces más eficiente que el mostrado por MySQL,
En la tercera consulta utilizando la función de agregación SUM, se observan que los
mejores tiempos de respuesta se obtienen con Cassandra, MonetDB y MongoDB, siendo
Cassandra la de mejor eficiencia con un tiempo de 62,6 milisegundos que es 5,64 más
eficiente a comparación de MySQL que tiene un tiempo de 353 milisegundos.
Segundo escenario – 10 millones de datos
La tabla 33 muestra los resultados en milisegundos, obtenidos durante la ejecución de las tres
consultas con un total de 10 millones de datos.
SEGUNDO ESCENARIO
TIEMPO EN (ms)
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
MySQL 2,4 6422,0 3784,4
PostgreSQL 10,2 4991,6 1485,0
MongoDB 3,0 251,4 606,8
MonetDB 4,6 268,4 708,6
Cassandra 5,0 20,4 525,0
Tabla 21. Tiempos promedio de ejecución del primer escenario
45
Figura 10. Gráfica tiempos de ejecución segundo escenario.
Al analizar el segundo escenario en la figura 10. Se observa una notable diferencia en los
tiempos de respuesta de la segunda y tercera consulta entre las bases de datos bases de
datos columnares en comparación con las bases de datos relacionales, sin embargo, para
la primera consulta los tiempos de respuesta en los dos tipos de base de datos sigue
manteniéndose regular sin variaciones. Las bases MongoDB, MonetDB y Cassandra
tuvieron tiempos similares en las consultas dos y tres, en la segunda consulta el más bajo
rendimiento presentó MySQL que expuso un tiempo de 6422 milisegundos casi similar a
Postgres, que a comparación con Cassandra con un tiempo de 20,4 milisegundos esta
última es 314,8 veces más eficiente que MySQL, la tercera consulta se mantiene MySQL
con el más bajo tiempo de respuesta con 3784 milisegundos a comparación de Cassandra
con 525 milisegundos siento 7,21 veces más eficiente la base de datos columnar.
Tercer escenario – 25 millones de datos
La tabla 34 muestra los resultados en milisegundos, obtenidos durante la ejecución de las
tres consultas con un total de 25 millones de datos.
0,0
1000,0
2000,0
3000,0
4000,0
5000,0
6000,0
7000,0
MySQL PostgreSQL MongoDB MonetDB Cassandra
Tiem
po
(ms)
Base de datos
Segundo Escenario - 10M
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
46
TERCER ESCENARIO
TIEMPO EN (ms)
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
MySQL 2,8 14921,8 10115,8
PostgreSQL 12,6 12281,6 4220,4
MongoDB 2,8 137,0 1594,0
MonetDB 5,0 407,8 1948,2
Cassandra 4,8 14,6 1897,0
Tabla 22. Tiempos promedio de ejecución del tercer escenario
Figura 11. Gráfica tiempos de ejecución tercer escenario.
Al analizar los resultados de la ejecución de las pruebas en el tercer escenario mostrados
en la figura 11, se mantienen iguales los tiempos de respuesta para la primera consulta en
todas las bases de datos, para las consultas dos y tres se logra un buen rendimiento en las
bases de datos MongoDB, MonetDB y Cassandra. Entre las bases de datos del tipo
orientado a columnas, Cassandra en las consultas dos y tres exhibió un tiempo de
respuesta similar a MonetDB. En la segunda consulta el peor rendimiento fue presentado
por la base de datos de MySQL con 14921,8 milisegundos, esto es un tiempo de ejecución
1000 veces mayor en comparación con la base de datos columnar Cassandra con 14,6
milisegundos. Al igual que en la tercera consulta MySQL presenta un tiempo de 10115,8
milisegundos, lo cual es 5,38 veces más lento que Cassandra con 1879 milisegundos.
0,0
2000,0
4000,0
6000,0
8000,0
10000,0
12000,0
14000,0
16000,0
MySQL PostgreSQL MongoDB MonetDB Cassandra
Tiem
po
(ms)
Base de datos
Tercer Escenario - 25M
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
47
Cuarto escenario – 50 millones de datos.
La tabla 35 muestra los resultados en milisegundos, obtenidos durante la ejecución de las
tres consultas con un total de 50 millones de datos.
CUARTO ESCENARIO
TIEMPO EN (ms)
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
MySQL 3,2 29425,2 20953,2
PostgreSQL 13,0 25404,0 8519,8
MongoDB 2,8 294,8 3324,8
MonetDB 4,2 714,8 3929,4
Cassandra 7,4 15,4 3058,6
Tabla 23. Tiempos promedio de ejecución del cuarto escenario
Figura 12. Gráfica tiempos de ejecución cuarto escenario.
La figura 12 del cuarto escenario, muestra que la primera consulta permanece sin
variaciones en el tiempo de respuesta en todas las bases de datos, siendo similar su
rendimiento para esta consulta. Para la consulta dos y tres se puede observar que las bases
de datos con peor rendimiento son MySQL seguido de PostgreSQL. MySQL es 46,1
veces más lento que MonetDB. PostgreSQL respondió un poco mejor en la tercera
consulta siendo solo 2,7 veces más lento que Cassandra. Aun así, se observa el del tipo
de base de datos columnares Cassandra y MonetDB tienen mejor tiempo de respuesta en
comparación al tipo de bases relacionales, especialmente en la consulta dos, donde se
0,0
5000,0
10000,0
15000,0
20000,0
25000,0
30000,0
35000,0
MySQL PostgreSQL MongoDB MonetDB Cassandra
Tiem
po
(ms)
Base de datos
Cuarto Escenario - 50M
C1 - CLAVE/VALOR C2 - SET DE DATOS C3 - AGREGACIÓN
48
devuelve un tercio del total de datos. Cassandra lidera en eficiencia siendo 46 veces más
rápido que su homóloga MonetDB en la segunda consulta.
4.6.2. Resultados por consulta
En estas subsecciones se presenta y se analiza los tiempos promedio de respuesta
resultantes agrupados por consulta en todos los escenarios, con el objeto de poder
observar el rendimiento de las bases de datos en cada consulta, mientras se aumenta el
volumen de datos.
Primera Consulta – Clave / Valor
La tabla 36 muestra los resultados en milisegundos, obtenidos durante la ejecución solo
de la primera consulta (Clave - Valor) en todos los escenarios.
Primera consulta - Clave/Valor
Base de datos Número de registros
1MM 10MM 25MM 50MM
MySQL 2,0 2,4 2,8 3,2
PostgreSQL 9,0 10,2 12,6 13,0
MongoDB 2,8 3,0 2,8 2,8
MonetDB 4,0 4,6 5,0 4,2
Cassandra 3,4 5,0 4,8 7,4
Tabla 24. Tiempos promedio de ejecución primera consulta
Figura 13. Gráfica tiempos de ejecución primera consulta
0,0
2,0
4,0
6,0
8,0
10,0
12,0
14,0
1MM 10MM 25MM 50MM
Tiem
po
(m
s)
Volumen de datos (Millones)
Primera Consulta - Clave/Valor
MySQL PostgreSQL MongoDB MonetDB Cassandra
49
Figura 14. Gráfica en esferas tiempos de ejecución primera consulta
En la figura 13 se observa que para la primera consulta los tiempos de respuesta son muy
similares y eficientes en todas las bases de datos, tanto en MySQL y PostgreSQL los
tiempos de respuesta no varían considerablemente mientras crece el volumen de datos, lo
mismo ocurre con los tiempos de respuesta de Cassandra, MongoDB y MonetDB que
permanecen sin cambios notables. Ninguna de estas bases de datos demora más de un
segundo en realizar esta consulta.
Segunda Consulta – Set de datos
Segunda consulta - Set de datos
Base de datos Número de registros
1MM 10MM 25MM 50MM
PostgreSQL 468,0 4991,6 12281,6 25404,0
MySQL 531,2 6422,0 14921,8 29425,2
MongoDB 133,4 251,4 137,0 294,8
MonetDB 193,0 268,4 407,8 714,8
Cassandra 9,4 20,4 14,6 15,4
Tabla 25. Tiempos promedio de ejecución segunda consulta
-2
0
2
4
6
8
10
12
14
16
0 10 20 30 40 50 60
Tiem
po
(ms)
Volumen de datos (Millones)
Primera consulta - Clave/Valor
MySQL PostgreSQL MongoDB MonetDB Cassandra
50
Figura 15. Gráfica tiempos de ejecución segunda consulta
Figura 16. Gráfica esferas tiempos de ejecución segunda consulta
En la figura 15 cuando se ejecuta la segunda consulta que utiliza una cláusula where que
retorna el 30% de todos los datos, se observa una clara diferencia en los tiempos de
respuesta cuando va aumentado el tamaño de los datos entre las bases de datos
relacionales y columnares. MySQL con 1M de datos su tiempo de respuesta fue 531
milisegundos, pero con 50M de datos su tiempo de respuesta tiene un fuerte incremento
presentando un tiempo de 29425 milisegundos, caso similar presenta PostgreSQL.
Mientras que con bases de datos columnares mantienen un tiempo promedio
independiente del volumen de datos. Como Cassandra que con 1M de registros su tiempo
0,0
5000,0
10000,0
15000,0
20000,0
25000,0
30000,0
1MM 10MM 25MM 50MM
Tiem
po
(m
s)
Volumen de datos (millones)
Segunda Consulta - Set de datos
MySQL PostgreSQL MongoDB MonetDB Cassandra
-5000
0
5000
10000
15000
20000
25000
30000
35000
0 10 20 30 40 50 60
Tiem
po
(ms)
Volumen de datos (Millones)
Segunda Consulta - Set de datos
MySQL PostgreSQL MongoDB MonetDB Cassandra
51
de respuesta es 9,4 milisegundos y con 50M de registros presento un tiempo de respuesta
de 15,4 milisegundos. El mismo caso sucede con MonetDB y MongoDB se observa
tiempos de respuesta bajos tanto con 1M y 50M.
Tercera Consulta – Función de agregación SUM()
Tercera consulta - Función de agregación (SUM)
Base de datos Número de registros
1MM 10MM 25MM 50MM
MySQL 353,0 3784,4 10115,8 20953,2
PostgreSQL 155,4 1485,0 4220,4 8519,8
MongoDB 72,4 606,8 1594,0 3324,8
MonetDB 85,6 708,6 1948,2 3929,4
Cassandra 62,6 525,0 1897,0 3058,6
Tabla 26.Tiempos promedio de ejecución tercera consulta
Figura 17. Gráfica tiempos de ejecución tercera consulta
0,0
5000,0
10000,0
15000,0
20000,0
25000,0
30000,0
1MM 10MM 25MM 50MM
Tiem
po
(m
s)
Volumen de datos (millones)
Tercera consulta - Función de agregación (SUM)
MySQL PostgreSQL MongoDB MonetDB Cassandra
52
Figura 18. Gráfica tiempos de ejecución tercera consulta
Analizando el grafico de la figura 17 y 18, para 1 millón de datos y 10 millones de datos,
las variaciones en tiempos de respuesta en todas las bases de datos no arrojan una
diferencia significativa, por ejemplo, con 10 millones de datos en MySQL se tiene un
tiempo de 1485 milisegundos y en Cassandra 525 milisegundos, solo 2,8 veces más lento
MySQL en comparación con Cassandra. En cambio, cuanto aumenta el volumen de datos
a 25 y 50 millones respectivamente ya se tiene una variación considerable en los tiempos
de respuesta entre el tipo de base relacionales y columnares, PostgreSQL cuando se
ejecuta la consulta con 50 millones de datos el tiempo de respuesta es 20953 milisegundos
y en MongoDB 3324 milisegundos, A medida que aumenta el tamaño de los datos, la
diferencia de rendimiento entre MongoDB y PostgreSQL se hace evidente. Cassandra,
MonetDB y MongoDB son ligeramente afectadas en el tiempo de respuesta conforme
incrementa el volumen de datos.
-5000
0
5000
10000
15000
20000
25000
0 10 20 30 40 50 60
Tiem
po
(ms)
Volumen de datos (Millones)
Tercera consulta - Función de agregación (SUM)
MySQL PostgreSQL MongoDB MonetDB Cassandra
53
5. DISCUSION
Los resultados de tiempo de ejecución de la primera consulta clave-valor reveló que el
rendimiento tanto en las bases de datos relacionales: MySQL y PostgreSQL, como en las
bases de datos columnares: MonetDB, Cassandra, es semejante. Presentando una
eficiencia adecuada para este tipo de consultas. Debido a que el modelamiento en las
bases de datos relacionales se utiliza un Primary Key (PK), este actúa como un índice de
dato, haciéndola eficiente para este tipo de consultas.
En la segunda consulta que usa una cláusula where y retorna el 30% de datos del total, al
igual que en la tercera consulta donde se utiliza una función de agregación, en los
resultados de ambas consultas se aprecia grandes cambios en el rendimiento de las bases
de datos relacionales a comparación de las bases de datos columnares, teniendo estas
últimas un favorable rendimiento. Este resultado se obtiene por las características propias
de las bases de datos orientadas a columnas como son: el almacenamiento en columnas,
la compresión de datos, materialización, entre otras. Estas características hacen que este
tipo de consultas se ejecuten de una manera mucho más eficiente que en una base de datos
relacional.
Considerando los resultados obtenidos y las características propias de cada base de datos,
se encontró que, en las bases de datos relacionales MySQL y Postgres hay una relación
directamente proporcional entre el volumen de datos y el tiempo, es decir, mientras se
incrementa el volumen de datos, el tiempo de consulta tambien se incrementa en mayor
proporción. A diferencia de las bases de datos columnares Cassandra y MonetDB, en las
cuales, al incrementar el volumen de datos, tiene un impacto menor en los tiempos de
respuesta. Las bases de datos columnares tienen un rendimiento superior debido a que
ocupan tecnología in-memory (en memoria RAM) para el almacenamiento y la
recuperación de datos, lo que permite un menor tiempo de ejecución de las consultas, a
diferencia del tipo de base de datos relacionales donde el rendimiento se ve afectado
debido al hecho de que los registros deben leerse desde el disco, que es mucho más lento
en comparación con la memoria RAM.
54
6. CONCLUSIONES
• Como resultado de la presente investigación realizada se ha podido cumplir con
los objetivos planteados, por lo cual, se concluye que el rendimiento de una base de datos
columnar es óptimo en ambientes de análisis de datos.
• En las bases de datos MySQL y Postgres la relación entre el volumen de datos y
el tiempo es directamente e incrementalmente proporcional, al contrario, en las bases de
datos de la familia columnar Cassandra y MonetDB, los tiempos de ejecución no sufren
variaciones notables mientras aumenta el volumen de los datos.
• Todas las bases de datos comparadas tuvieron la misma eficiencia en la ejecución
de la primera consulta tipo Clave – Valor, debido a la presencia de la clave primaria, tanto
MySQL, PostgreSQL como MonetDB, Cassandra y MongoDB presentaron tiempos de
ejecución similares, por tanto, para este tipo de consultas, ambos tipos de bases de datos
tienen un óptimo rendimiento. A diferencia de los resultados en la segunda consulta (set
de datos) y la tercera consulta (función de agregación) donde la diferencia de tiempos de
ejecución es bastante notoria.
• El rendimiento superior de las bases de datos columnar que presento mejoras de
hasta 7, 21 y 1900 veces más eficiencia en la tercera y segunda consulta respectivamente,
se debe a que ocupan altamente la memoria volátil para el almacenamiento y la
recuperación de datos, lo que permite un menor tiempo de ejecución de las consultas, a
diferencia del tipo de base de datos relacionales donde el rendimiento no fue el mejor
debido al hecho de que los registros deben leerse desde el disco, que es mucho más lento
en comparación con la memoria volátil.
• El tipo de base de datos columnar y el movimiento NoSQL en general, es
adecuado para resolver un problema actual del Big Data, que es el manejo de grandes
cantidades de datos. Es necesario también tener en cuenta características como el
55
escalamiento horizontal, o la facilidad de modelado sin esquemas, junto con los puntos
débiles de estas tecnologías.
• El análisis de datos necesita bases de datos capaces de almacenar y procesar
grandes cantidades de datos con eficacia, la demanda de alto rendimiento al leer y escribir,
así que la base de datos relacional tradicional no resultan la solución más adecuada. Bases
de datos columnares surgen como una solución que cumple con las expectativas de
rendimiento en este campo.
• Se comparó y valoró dos de las más populares bases de datos NoSQL: MongoDB
(documental) y Cassandra (columnar) con grandes cantidades de datos, estas mostraron
los mejores resultados para todas las pruebas realizadas, independientemente del tamaño
de datos, estas bases de datos pueden brindar mayor flexibilidad y proporcionar menor
tiempo de ejecución.
• Las bases de datos SQL y NoSQL proporcionan diferentes características y una
no puede reemplazar a otra. Si el sistema no es flexible en términos de consistencia,
entonces el sistema de administración de base de datos relacional es la opción correcta.
Si el sistema puede renunciar a cierta consistencia, las bases de datos NoSQL pueden ser
la mejor opción para proporcionar más disponibilidad, escalabilidad y alto rendimiento.
56
7. RECOMENDACIONES
• Como trabajo futuro, se podría realizar el mismo estudio, pero en un entorno
distribuido y paralelo para contrastar y verificar los resultados obtenidos en esta
investigación.
• Con los resultados obtenidos en la recolección de datos al momento de ejecutar
las consultas y la documentación teórica redactada, se deja la posibilidad de continuar
este estudio más a profundidad en temas de configuración y elaboración de las consultas
para obtener un mejor provecho de estas herramientas, debido a que las bases de datos
basadas en columnas son una elección que considerar para temas de analítica.
• En estudios próximos se recomienda realizar un análisis detallado de escrituras en
bases de datos columnares con respecto a base de datos relacionales.
• Dependiendo del objetivo que se persiga, se podría pensar en un modelo hibrido
que combine las dos tecnologías SQL y NoSQL, donde sí se necesita mantener mayor
consistencia se puede almacenar de una manera relacional mientras que para consultas
inmediatas o recurrentes, se utilizarían bases de datos columnares.
• Se debe analizar primero la lógica de negocio, caso de uso e infraestructura para
verificar que tipo de base de datos es la más apta para la solución de las problemáticas
que se posean, referente a esto se puede evaluar otros tipos de base de datos NoSQL que
existen en el mercado.
• Se recomienda revisar bien la documentación de las bases de datos NoSQL al
momento de realizar la migración de datos para no tener inconvenientes con los tipos de
datos y mal rendimiento a la hora de realizar las consultas por un mal modelamiento, ya
que no se usan esquemas como en las bases de datos relacionales.
57
CITAS BIBLIOGRAFICAS
Abadi, D., Boncz, P., & Harizopoulos, S. (2009). Column-oriented database systems.
Proceedings of the VLDB Endowment, II, 1664-1665. doi:10.14778/1687553.1687625
Abadi, D., Boncz, P., Harizopoulos, S., Idreos, S., & Madden, S. (2013). The design and
implementation of modern column-oriented database systems. Foundations and
Trends in Databases, 5(3), 197-280. doi:10.1561/1900000024
Abadi, D., Madden, S., & Ferreira, M. (2006). Integrating Compression and Execution in
ColumnOriented. In Proceedings of the 2006 ACM SIGMOD international conference on
Management of data ACM., I, 671-682. doi:10.1145/1142473.1142548
Abadi, J., Madden, R., & Hachem, N. (2008). Column-Stores vs. Row-Stores: How Different Are
They Really ? I, 967-980. doi:10.1145/1376616.1376712
Abdullah, T., & Resul, K. (2013). A performance evaluation of in-memory databases. Computer
and Information Sciences, XXIX, 520-525.
doi:https://doi.org/10.1016/j.jksuci.2016.06.007
Abramova, V., Bernardino, J., & Furtado, P. (2014). EXPERIMENTAL EVALUATION OF NOSQL.
International Journal of Database Management Systems, VI, 1.
doi:10.5121/ijdms.2014.6301
Ameya, N., & Anil, P. (2013). Type of NOSQL Databases and its Comparison with Relational
Databases. International Journal of Applied Information Systems (IJAIS), V, 16-19.
doi:10.5120/ijais12-450888
Áviles, I. P. (2011). Investigación sobre base de datos columnares y su implementación en el
mercado ecuatoriano. Guayaquil, Guayas, Ecuador.
Babeanu, R., & Ciobanu, M. (2015). In-memory databases and innovations in Business
Intelligence. Database Systems Journal, VI, 59-67. doi:10.1007/s12599-011-0188-y
Binani, S., Gutti, A., & Upadhyay, S. (2016). SQL vs. NoSQL vs. NewSQL-A Comparative Study.
Communications on Applied Electronics (CAE) , 6(1). Recuperado el 8 de Abril de 2018
Bonzi, E. (Agosto de 2017). Experiecias con sistemas de bases de datos NoSQL para su
implementación en la docencia. 1(1). Santiago, Chile. Recuperado el 15 de Enero de
2018
Borox, A. M. (Septiembre de 2015). Almacenes de datos NoSQL, estudio de la tecnología.
Leganés, España. Recuperado el 3 de Febrero de 2018, de
http://hdl.handle.net/10016/23908
Brewer, E. (2012). CAP Twelve Years Later: How the “Rules” Have Changed. IEEE Computer
Society, VL, 23-29. doi:10.1109/MC.2012.37
58
Browne, J. (2009). Brewer's CAP Theorem. Obtenido de
http://www.julianbrowne.com/article/viewer/brewers-cap-theorem.
Cattaneo, M., Nocera, M., & Rottoli, G. (2014). Performance of NoSQL Technology on Massive
Amounts of Data. Cuaderno Activa, 6, 11-17. Recuperado el 5 de Enero de 2018
Chen, M., Mao, S., & Liu, Y. (2014). Big data: A survey. Mobile networks and applications, 2(19),
171-209. doi:https://doi.org/10.1007/s11036-013-0489-0
Demchenko, Y., De Laat, C., & Membrey, P. (2014). Defining architecture components of the
Big Data Ecosystem. International Conference on IEEE (págs. 104-112). Minneapolis:
IEEE. doi: 10.1109/CTS.2014.6867550
Gibson, M., Arnott, D., Jagielska, I., & Melbourne, A. (2004). Evaluating the Intangible Benefits
of Business Intelligence. Conference on Decision Support Systems, (págs. 295-305).
Prato. Recuperado el 3 de Abril de 2018
Gracia del Busto, H., & Yanes Enríquez, O. (2012). Bases de datos NoSQL. Revista Telemàtica,
XI, 21-33. Recuperado el 16 de Enero de 2018, de
http://www.revistatelematica.cujae.edu.cu/index.php/tele/article/view/74
Greco, M., & Grimaldi, M. (2015). What is big data? A consensual definition and a review of key
research topics. 1, págs. 97-104. AIP. doi:10.1063/1.4907823
Hahn, G., & Packowski, J. (2015). A perspective on applications of in-memory analytics in
supply chain management. Decision Support Systems, 76, 45-52.
doi:https://doi.org/10.1016/j.dss.2015.01.003
Horna, A. (2012). Desde la idea hasta la sustentación: 7 pasos para una tesis exitosa. (Vol. 3).
Lima. Recuperado el 12 de Abril de 2018
Indrawan, M. (2012). Database Research: Are We at a Crossroad? Reflection on NoSQL.
Network-Based Information Systems (NBiS), (págs. 45-51). doi:10.1109/NBiS.2012.95
Larson, P., & Levandoski, J. (2016). Modern main-memory database systems. Proceedings of
the VLDB Endowment, 9, 1609-1610. doi:10.14778/3007263.3007321
Lidia Contreras. (4 de Febrero de 2011). Blog Historia de la Informática. Obtenido de
http://histinf.blogs.upv.es/2011/01/04/historia-de-las-bases-de-datos/
Liu, Y., Mortazavi, M., Chen, M., & Otros. (2015). DCODE: A distributed column-oriented
database engine for big data analytics. (Cham, Ed.) In Information and Communication
Technology, 289-299. doi:10.1007/978-3-319-24315-3 30
Lorente, A. (Septiembre de 2015). Almacenes de datos NoSQL, estudio de la tecnología.
Leganés, España.
Marqués, M. (2011). Bases de datos (Vol. I). Castellón de la Plana, España: Universitat Jaume I.
Recuperado el 18 de Enero de 2018, de http://hdl.handle.net/10234/24183
59
Mihaela-Laura, I. (2014). Characteristics of In-Memory Business Intelligence. Informatica
Economica, XVIII, 17-25. doi:10.12948/issn14531305/18.3.2014.02
Moniruzzaman, A., & Hossain, S. (2013). Nosql database: New era of databases for big data
analytics-classification, characteristics and comparison. International Journal of
Database Theory and Application, 6(4). doi:arXiv:1307.0191
Morales, M., & Morales, S. (2017). Inteligencia de negocios basada en Bases de Datos In-
Memory. Revista Publicando, 201-217. Recuperado el 10 de Enero de 2018
Perez, J. (4 de Marzo de 2008). definicionde.com. Obtenido de definicionde.com:
https://definicion.de/informe/
Plattner, H., & Leukert, B. (2015). The In-Memoty Revolution. Springer. doi:10.1007/978-3-319
Ramez, E., & Shamkant, N. (2015). Fundamentals of Database Systems (Vol. VII). New Jersey:
Pearson. Recuperado el 10 de Febrero de 2018, de
http://noahc.me/Fundamentals%20of%20Database%20Systems%20(7th%20edition).p
df
Richard, B., & Heather, T. (2014). Cloud Computing and Big Data: A Review of Current Service
Models and Hardware Perspectives. Journal of Software Engineering and Applications,
VII, 686-693. doi:10.4236/jsea.2014.78063
Robles, D., Sánchez, M., Serrano, R., Adárraga, B., & Heredia, D. (2015). ¿Qué características
tienen los esquemas NoSQL? Investigación y Desarrollo en TIC, 6(1), 40-44. Recuperado
el 13 de Enero de 2018
Rubenfa. (30 de Mayo de 2017). GENTEBA:DEV. Recuperado el 22 de Febrero de 2018, de
GENTEBA:DEV Web Site: https://www.genbetadev.com/bases-de-datos/nosql-
clasificacion-de-las-bases-de-datos-segun-el-teorema-cap
Sadalage P, F. M. (2013). NoSQL Distilled, A brief guide to the emerging word of polyglote,
Persistence. XXIX, 520-525. doi:10.1016/j.jksuci.2016.06.007
Sakulsorn, P. (2013). In-memory Business Intelligence Verifying its Benefits against
Conventional Approaches. In-memory Business Intelligence. KTH, School of Information
and Communication Technology . Recuperado el 4 de Abril de 2018, de
urn:nbn:se:kth:diva-128449
Sampieri, R., & Fernández C, B. ,. (2010). Metodología de la investigación (Vol. V). México: The
McGraw-Hill. Recuperado el 13 de Abril de 2018
Simon, S. (2012). Report to Brewer’s original presentation of his CAP Theorem at the
Symposium on Principles of Distributed Computing. Suiza: Distributed Information
Systems. Recuperado el 18 de Marzo de 2018, de
https://fenix.tecnico.ulisboa.pt/downloadFile/845043405442708/10.e-CAP-3.pdf
Stonebraker, M. (5 de Abril de 2010). Errors in Database Systems, Eventual Consistency, and
the CAP Theorem. Recuperado el 28 de Enero de 2018, de Communications of the
60
ACM: http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-
eventual-consistency-and-the-cap-theorem/fulltext
Stonebraker, M. (2010). SQL databases vs. NoSQL databases. Communications of the ACM, LIII,
10-11. doi:10.1145/1721654.1721659
Strauch, C. (2011). NoSQL Databases (Vol. 20). Stuttgart: Lecture Notes. Recuperado el 25 de
Febrero de 2018, de http://www.christof-strauch.de/nosqldbs
Strozzi, C. (2013). NoSQL – A relational database management system. Recuperado el 16 de
Marzo de 2018, de http://www.strozzi.it.
Vargas, Z. (2009). LA INVESTIGACIÓN APLICADA: UNA FORMA DE CONOCER LAS REALIDADES
CON EVIDENCIA CIENTÍFICA. Revista Educación, 33(1), 155-165.
doi:https://doi.org/10.15517/revedu.v33i1.538
Vatika, S., & Meenu, D. (2012). SQL and NoSQL Databases. International Journal of Advanced
Research in Computer Science and Software Engineering, 20-27. Recuperado el 3 de
Marzo de 2018
Wixom, B., & Otros. (2014). The current state of business intelligence in academia: The arrival
of big data. Communications of the Association for Information Systems, XXXIV, 1-13.
Recuperado el 12 de Enero de 2018, de http://aisel.aisnet.org/cais/vol34/iss1/1
Yaman, S. (2012). Introduction to Column-Oriented Database. Columnar Databases. Helsinki.
Recuperado el 8 de Marzo de 2018
Yuan, Y., Lee, R., & Zhang, X. (2013). The Yin and Yang of Processing Data Warehousing.
Proceedings of the VLDB Endowment, 817-828. doi:10.14778/2536206.2536210
61
ANEXOS
62
ANEXO A
SCRIPTS DE CREACIÓN DE TABLAS.
1.1 Creación de tabla en MySQL
Use database;
CREATE TABLE train_ (
id int(11) NOT NULL primary key,
date date,
item_nbr int(11),
onpromotion bit,
store_nbr int(11),
unit_sales decimal(10,0) ) ;
1.2 Creación de tabla en PostgreSQL
Use database;
CREATE TABLE public.train (
id integer NOT NULL primary key,
date date,
store_nbr integer,
item_nbr integer,
unit_sales numeric,
onpromotion boolean );
1.3 Creación de tabla en Cassandra
Use keyspace;
CREATE TABLE train (
63
id int,
date date,
item_nbr int,
onpromotion boolean,
store_nbr int,
unit_sales decimal,
PRIMARY KEY (id, date , store_nbr, item_nbr));
1.4 Creación de tabla en MonetDB
CREATE TABLE train
(
id integer,
date timestamp,
store_nbr integer,
item_nbr integer,
unit_sales double precision,
onpromotion boolean
)
CREATE USER "root" WITH PASSWORD 'root123' NAME 'root Explorer'
SCHEMA "sys";
GRANT SELECT ON sys.train TO root;
1.5 Creación de colección en MongoDB
Use escenarios;
db.createCollection("train")
64
ANEXO B
CARGA DE DATOS CON PENTAHO DATA INTEGRATION
2.1 Para realizar la carga en base de datos SQL, se realizó los siguientes pasos: primero
se va a la pestaña ficheros, Nuevo y se selecciona Transformación.
B1. Crear nueva transformación
2.2 Se abrirá un espacio de trabajo ubicado a la derecha donde se puede arrastrar y soltar
los pasos y transformaciones que se va a realizar, estos se encuentran en el panel izquierdo
en la pestaña diseño.
B2. Espacio de trabajo
65
2.3 Seguidamente en el panel izquierdo de diseño, se busca las opciones de entrada de
datos y se selecciona la opción “CSV file input” se arrastra al espacio de trabajo, esto
carga los registros desde el archivo CSV.
B3. Entrada de datos
2.4 Al hacer doble click en el icono “CSV file input” en el espacio de trabajo, se abrirá
un cuadro de configuración para cargar el archivo CSV. Lo primero es especificar la ruta
donde se encuentra alojado el archivo, seguidamente se especifica el delimitador y si el
archivo contiene nombres de las columnas se selecciona la opción “Header row present”.
Una vez hecho se da clic en el botón traer campos, si todo es correcto traerá los campos
con su tipo de datos, aquí se puede especificar el tipo de datos del archivo CSV. Se
verifica que la información este correcta y aplastar el botón Vale.
66
B4. Carga archivo CSV
2.5 Después buscar la pestaña Salida del panel izquierdo y seleccionar la opción “Salida
Tabla”, arrastrar y soltar en el espacio de trabajo. Unimos el paso CSV file input con el
que acaba de incluir.
B5. Salida de datos
2.6 Ahora configurar el destino donde quiera migrar los datos contenidos en el archivo
CSV. Hacer doble click en el paso Salida Tabla, se abrirá un cuadro de configuración
similar al anterior. Primero configurar la conexión a la base de datos destino. Por tanto,
en la línea de conexión dar click en Nuevo.
67
B6. Conexión a base de datos destino.
2.7 Aparecerá un cuadro llenar los parámetros de conexión a la base de datos deseada.
Llenar los campos y si todos los parámetros están correctos, dar clic en probar y saldrá
un cuadro notificando que la conexión es correcta, presionar en el botón vale y ok.
B7. Test de conexión
2.8 Una vez creada la conexión, seleccionar el esquema destino si lo hubiera y la tabla a
la cual se migrarán los datos. Click en el botón Ok.
68
B8. Selección tabla destino
2.9 Por último, dar click en el botón ejecutar transformación y esperar a que los datos
terminen de migrar.
B9. Ejecutar carga de datos.
Para las bases de datos columnar, realizar los mismos pasos, a excepción del paso 1.5,
aquí buscar la base de datos destino en el panel de diseño, en la opción de Big Data,
69
buscar, arrastrar y soltar en el espacio de trabajo la opción de la base de datos columnar
destino.
B10. Configuración base de datos columnar
Del paso 2.6 en adelante es similar a lo descrito anteriormente, se configuran los
parámetros de conexión a Cassandra y se sigue los pasos descritos.
70
ANEXOS C
CONEXIÓN DE AQUA DATA STUDIO CON BASE DE DATOS NOSQL
3.1 Creación y configuración de la conexión de la base de datos (MonetDB)
C1. configuración de conexión
3.2 Se prueba la conexión
C2.test de conexión
71
3.3 Se realiza la conexión con el Servidor
C3. Conexión con la base de datos
4.- Se confirma la conexión visualizando las tablas para poder realizar las consultas
C4. Espacio de trabajo