UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · En bases de datos se denomina ACID se refiere a...

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

[email protected] [email protected]

mailto:[email protected]

mailto:[email protected]

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 14. Mediciones consulta 1 – tercer escenario ................................................................... 39



Tabla 17. Mediciones consulta 1 – cuarto escenario .................................................................. 41



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




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




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

https://neo4j.com/blog/the-top-10-ways-to-get-to-know-neo4j/

https://neo4j.com/blog/the-top-10-ways-to-get-to-know-neo4j/

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

https://www.g2crowd.com/categories/relational-databases?segment=small-business

https://www.g2crowd.com/categories/relational-databases?segment=small-business

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:

https://db-engines.com/en/ranking/wide+column+store

https://db-engines.com/en/ranking/wide+column+store

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

https://www.kaggle.com/c/favorita-grocery-sales-forecasting/data

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)


train10m WHERE date >= '2015-09-15';

3.392.156

Tercer

escenario

(25 Millón)


train25m WHERE date >= '2015-12-31'; 8.637.780

cuarto

escenario

(50 Millón)


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):


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):


FROM train1m

WHERE date >= '2015-07-05';



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


Tabla 9. Mediciones consulta 2 – primer escenario

CONSULTA 3 (FUNCIÓN DE AGREGACIÓN):


FROM train1m




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


Tabla 10. Mediciones consulta 3 – primer escenario

38

Segundo Escenario – 10 millones de datos



FROM train10m

WHERE id = 500023352;



MySQL SQL 4 1 2 2 3 2,4

POSTGRESQL SQL 9 10 11 10 11 10,2




Tabla 11. Mediciones consulta 1 – segundo escenario



FROM train10m

WHERE date >= '2015-09-15';



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



39



FROM train10m




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


Tercer Escenario – 25 millones de datos



FROM train25m

WHERE id = 500023352;



MySQL SQL 3 2 3 4 2 2,8

POSTGRESQL SQL 11 14 12 12 14 12,6




Tabla 14. Mediciones consulta 1 – tercer escenario

40



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





FROM train25m




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


41

Cuarto Escenario – 50 millones de datos:



FROM train50m

WHERE id = 500023352;



MySQL SQL 3 3 5 2 3 3,2

POSTGRESQL SQL 12 13 15 12 13 13,0




Tabla 17. Mediciones consulta 1 – cuarto escenario



FROM train50m

WHERE date >= '2016-06-25';

TIEMPO EN (ms)

PROMEDIO

Tipo de base de


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



42

CONSULTA 3 (FUNCIÓN DE AGREGACION):


FROM train50m


TIEMPO EN (ms)

PROMEDIO

Tipo de base de


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


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


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)


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


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


Tiem

po

(ms)

Base de datos

Segundo Escenario - 10M


46

TERCER ESCENARIO

TIEMPO EN (ms)


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


Tiem

po

(ms)

Base de datos

Tercer Escenario - 25M


47

Cuarto escenario – 50 millones de datos.


tres consultas con un total de 50 millones de datos.

CUARTO ESCENARIO

TIEMPO EN (ms)


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


Tiem

po

(ms)

Base de datos

Cuarto Escenario - 50M


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


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


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)


Primera consulta - Clave/Valor


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


-5000

0

5000

10000

15000

20000

25000

30000

35000

0 10 20 30 40 50 60

Tiem

po

(ms)


Segunda Consulta - Set de datos


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)


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)



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)




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

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · En bases de datos se denomina ACID se refiere a...

Documents

Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · En bases de datos se denomina ACID se refiere a...