UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE …€¦ · Minango Román Carlos Edmundo Tenelema...

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERÍA INFORMÁTICA

Análisis del Uso de Recursos entre Bases de Datos Columnares versus Bases de Datos

Relacionales

Trabajo de Titulación Modalidad Proyecto de Investigación, Previo a la obtención del

Título de Ingeniero Informático

AUTORES: Minango Román Carlos Edmundo

Tenelema Cóndor Cristian Jefferson

TUTOR: Ing. Mario Raúl Morales Morales Mba.

QUITO, 2018

ii

DERECHOS DE AUTOR

Nosotros, MINANGO ROMÁN CARLOS EDMUNDO Y CRISTIAN JEFFERSON

TENELEMA CÓNDOR en calidad de autores y titulares de los derechos morales del

trabajo de titulación ANÁLISIS DEL USO DE RECURSOS ENTRE BASES DE

DATOS COLUMNARES VERSUS BASES DE DATOS RELACIONALES, 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 investigació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.

En la ciudad de Quito, a los 30 días del mes de Julio del 2018.

___________________________ ______________________________

Minango Román Carlos Edmundo Tenelema Cóndor Cristian Jefferson

C.C. 1723370217 C.C. 1719858019

Teléfono: 022353339 Teléfono: 023212111

Celular: 0995731024 Celular: 0986932426

E-mail: [email protected] E-mail: [email protected]

iii

APROBACIÓN DEL TUTOR

Yo, Ing. Mario Raúl Morales Morales, en calidad de tutor del trabajo de titulación:

“ANÁLISIS DEL USO DE RECURSOS ENTRE BASES DE DATOS COLUMNARES

VERSUS BASES DE DATOS RELACIONALES”, elaborado por los estudiantes Carlos

Edmundo Minango Román y Cristian Jefferson Tenelema Cóndor, de la Carrera de

Ingeniería Informática, Facultad de Ingeniería, Ciencias Físicas y Matemática de la

Universidad Central del Ecuador, considero que el mismo reúne los requisitos y méritos

necesarios en el campo metodológico y en el campo epistemológico, para ser sometido a

la evaluación por parte del jurado examinador que se designe, por lo que lo APRUEBO,

a fin de que el proyecto de investigación sea habilitado para continuar con el proceso de

titulación determinado por la Universidad Central del Ecuador.

.

En la Ciudad de Quito, a los 30 días del mes de Julio del 2018.

___________________________________

Ing. Mario Raúl Morales Morales Mba.

DOCENTE - TUTOR

C.C. 1709026577

iv

DEDICATORIA

En primer lugar, este proyecto de investigación se lo dedico a mi Virgencita del Quiche,

por guiarme en cada paso que he dado, por la salud y vida que me concedió para poder

realizar este gran sueño y con su bendición seguir superando día a día, y logra más retos

en mi vida.

Este gran logro de mi vida profesional se lo dedico a las personas que han sido el pilar de

mi vida con todo el amor y cariño a mis padres Freddin y Mariana, por darme la vida y

los más grande de esta vida mis hermanos Patricio y Karina. A mi padre Freddin, por todo

su apoyo incondicional, la persona más recta que pudo saberme aconsejar y aprender

muchas cosas buenas de él. A mi madre Mariana, por todo el apoyo incondicional en este

camino y lo mejor que la vida me ha dado.

A mi hermano Patricio, el cual es un pilar importante por ayudarme en lo que necesité y

siempre confiar en mí, por su amor y cariño que me brindan tanto de mi hermano como

de mi cuñada y mis sobrinos. A mi hermana Karina, por los buenos momentos

compartidos y por el cariño de mis sobrinos.

A una persona que fue muy importante en mi vida que hoy me cuida y guía mí camino

desde el cielo a mí tía Yolanda quien fue una persona que me supo aconsejar que nunca

me aparte de mis sueños y para mi abuelita Clemencia por todo su cariño y amor.

Carlos Minango

v

DEDICATORIA

Dedico el siguiente trabajo de Tesis a Dios por guiarme, cuidarme en cada momento y

permitir que cumpla mis objetivos, metas y logros.

Este gran logro se lo dedico con mucho amor a mis padres Viviana y Juan, así como a

mis tíos Eduardo y Anita, por su infinito amor, paciencia, sabiduría, consejo oportuno y

apoyo incondicional en todo momento, ya que sin ellos este logro no habría sido posible.

A mi mamá Viviana, por ser la mejor mamá del mundo y estar siempre en los buenos y

malos momentos, por siempre guiarme con amor, cuidarme y protegerme siempre y

porque sin ella no estaría donde estoy ahora. A mi papá Juan, por ser un excelente padre,

por aconsejarme con sabiduría y con amor, por apoyarme en mis decisiones y darme

aliento en los momentos más difíciles.

A mis abuelos paternos Carmen y Juan por brindarme tanto amor, tantas lecciones de vida

y por cuidarme desde el cielo. A mis abuelos maternos Rosa y Alfonso por su cariño,

amor y a todos ellos por haberme dado lo más importante que tengo en la vida que son

mis padres.

A Marco, Xavier, Gabriel, Verónica, Mayra, Cristóbal, Armando, Manuel y demás

amigos de Nación Star Wars Ecuador porque han sabido demostrar que los amigos son la

familia que uno elige y con certeza puedo decir que tengo a la mejor familia de la Galaxia,

gracias por su cariño, apoyo, fidelidad y por tantos momentos felices.

Jefferson Tenelema

vi

AGRADECIMIENTOS

Damos infinitamente gracias a Dios por habernos dado fuerzas, salud y valor para

culminar esta etapa de nuestras vidas.

A nuestros padres, que nos han ayudado de forma económica y personal, por su

confianza y aliento para concluir con éxito nuestra carrera universitaria.

A nuestras familias quienes nos han motivado a seguir adelante en nuestra vida

profesional.

Al Ing. Mario Morales, que ha sabido guiarnos y compartir sus conocimientos

como profesor y tutor a lo largo de este proceso y por ser uno de los mejores

profesores que tiene la Universidad Central del Ecuador.

A nuestros revisores Ing. Julio Mendoza e Ing. Alicia Andrade, así como también

al Director de la Carrera de Ingeniería Informática, Ing. Boris Herrera por su

valiosa colaboración y su excelente desempeño docente, les deseamos muchos

éxitos y logros en sus vidas.

A nuestros amigos y amigas, quienes nos brindaron su apoyo y sus palabras de

aliento para nunca rendirnos en nuestra meta.

Carlos Minango y Jefferson Tenelema

vii

CONTENIDO

DERECHOS DE AUTOR ................................................................................................ ii

APROBACIÓN DEL TUTOR ........................................................................................ iii

DEDICATORIA .............................................................................................................. iv

DEDICATORIA ............................................................................................................... v

AGRADECIMIENTOS ................................................................................................... vi

CONTENIDO ................................................................................................................. vii

LISTA DE FIGURAS ..................................................................................................... xi

LISTA DE TABLAS ..................................................................................................... xiii

RESUMEN ..................................................................................................................... xv

ABSTRACT .................................................................................................................. xvi

INTRODUCCIÓN ............................................................................................................ 1

1. DEFINICIÓN DEL PROBLEMA ............................................................................ 2

1.1. Planteamiento del Problema .............................................................................. 2

1.2. Formulación del Problema ................................................................................. 2

1.3. Interrogantes de la Investigación ....................................................................... 2

1.4. Objetivos de la Investigación ............................................................................. 3

1.4.1. Objetivo General......................................................................................... 3

1.4.2. Objetivo Específicos ................................................................................... 3

1.5. Justificación ....................................................................................................... 3

1.6. Alcance .............................................................................................................. 3

1.7. Limitaciones ....................................................................................................... 4

viii

2. MARCO TEÓRICO ................................................................................................. 5

2.1. Antecedentes ...................................................................................................... 5

2.2. Marco Conceptual .............................................................................................. 6

2.2.1. Introducción a Bases de Datos Relacionales y Columnares ....................... 6

2.2.2. Base de Datos Relacional ........................................................................... 8

2.2.3. Base de datos Columnar ............................................................................. 9

2.2.3.1. Características ................................................................................... 10

2.2.3.2. Ventajas y desventajas de las bases de datos columnares ................. 18

3. METODOLOGÍA ................................................................................................... 21

3.1. Metodología de Investigación .......................................................................... 21

3.2. Diseño Descriptivo........................................................................................... 21

3.3. Procedimiento .................................................................................................. 21

4. CÁLCULOS Y RESULTADOS ............................................................................ 23

4.1. Determinación Muestral................................................................................... 23

4.1.1. Vertica (versión 9.0.1-0) ........................................................................... 23

4.1.2. MonetDB (versión 11.23.13) .................................................................... 23

4.1.3. PostgreSQL (versión 9.3.22): ................................................................... 24

4.1.4. NetData (versión 1.10.1) .......................................................................... 25

4.2. Selección / Creación del Conjunto de Datos .................................................... 25

4.2.1. Volúmenes de Base de Datos ................................................................... 26

4.3. Diseño del Escenario de Pruebas ..................................................................... 26

ix

4.3.1. Escenario I: ........................................................................................... 27

4.3.2. Escenario II: .......................................................................................... 27

4.3.3. Escenario III: ......................................................................................... 28

4.4. Entorno de Pruebas ................................................................................... 28

4.5. Mediciones ....................................................................................................... 29

4.5.1. CPU o Procesador:.................................................................................... 29

4.5.2. Memoria RAM: ........................................................................................ 30

4.5.3. DISCO I/O: ............................................................................................... 30

4.6. Análisis e interpretación de resultados ............................................................ 31

4.6.1. Escenario I: ............................................................................................... 31

4.6.1.1. CPU o Procesador: ............................................................................ 31

4.6.1.2. Memoria RAM: ................................................................................. 34

4.6.1.3. Disco (I/O): ....................................................................................... 37

4.6.2. Escenario II: .............................................................................................. 40

4.6.2.1. CPU o Procesador: ............................................................................ 40

4.6.2.2. Memoria RAM: ................................................................................. 43

4.6.2.3. Disco (I/O): ....................................................................................... 46

4.6.3. Escenario III: ............................................................................................ 49

4.6.3.1. CPU o Procesador: ............................................................................ 49

4.6.3.2. Memoria RAM: ................................................................................. 51

x

4.6.3.3. Disco (I/O): ....................................................................................... 54

4.6.4. Cuadro Comparativo de Escenarios ......................................................... 56

5. DISCUSIÓN ........................................................................................................... 58

6. CONCLUSIONES Y RECOMENDACIONES ..................................................... 59

6.1. Conclusiones .................................................................................................... 59

6.2. Recomendaciones: ........................................................................................... 60

BIBLIOGRAFÍA ............................................................................................................ 62

xi

LISTA DE FIGURAS

Figura 1. Almacenamiento BD Relacionales vs BD Columnares ................................... 7

Figura 2. Tabla en el modelo de Datos Relacionales ...................................................... 8

Figura 3. Almacenamiento de BD Relacionales .............................................................. 8

Figura 4. Manejo de Registros en BD Columnares ......................................................... 9

Figura 5. Almacenamiento de BD Columnares ............................................................. 10

Figura 6: Funcionamiento Run Length Encoding (RLE) .............................................. 14

Figura 7: Funcionamiento Codificación Huffman ........................................................ 15

Figura 8: Entorno Distribuido para el Análisis ............................................................. 28

Figura 9: Logo Vertica .................................................................................................. 23

Figura 10: Logo MonetDB ............................................................................................ 23

Figura 11: Logo PostgreSQL ........................................................................................ 24

Figura 12: Logo NetData............................................................................................... 25

Figura 13: Medidor de Rendimiento del Sistema.......................................................... 25

Figura 14: Uso del CPU en cada Nodo ......................................................................... 30

Figura 15: uso de Memoria RAM en cada Nodo .......................................................... 30

Figura 16: Uso de Disco I/O en cada Nodo .................................................................. 31

Figura 17: Uso de Procesador (Nodo 1 - Escenario I) .................................................. 32

Figura 18: Uso de Procesador (Nodo 2 - Escenario I) .................................................. 33

Figura 19: Tiempo de Respuesta (Nodo 1 - Escenario I) .............................................. 34

Figura 20: Tiempo de Respuesta (Nodo 2 - Escenario I) .............................................. 34

Figura 21: Uso de Memoria RAM (Nodo 1 - Escenario I) ........................................... 35

Figura 22: Uso de Memoria RAM (Nodo 2 - Escenario I) ........................................... 36

xii

Figura 23: Uso de Disco (Nodo 1 - Escenario I) ........................................................... 38

Figura 24: Uso de Disco (Nodo 2 - Escenario I) ........................................................... 39

Figura 25: Uso de Procesador (Nodo 1 - Escenario II) ................................................. 41

Figura 26: Uso de Procesador (Nodo 2 - Escenario II) ................................................. 42

Figura 27: Uso de Memoria RAM (Nodo 1 - Escenario II) .......................................... 44

Figura 28: Uso de Memoria RAM (Nodo2 - Escenario II) ........................................... 45

Figura 29: Tiempo de Respuesta (Nodo 1 - Escenario II) ............................................. 46

Figura 30: Tiempo de Respuesta (Nodo 2 - Escenario II) ............................................. 46

Figura 31: Uso de Disco I/O PostgreSQL & MonetDB (Nodo 1 - Escenario II) ......... 47

Figura 32: Uso de Disco I/O PostgreSQL & Vertica (Nodo 1 - Escenario II) .............. 47

Figura 33: Uso de Disco I/O PostgreSQL & MonetDB (Nodo 2 - Escenario II) ......... 48

Figura 34: Uso de Disco I/O PostgreSQL & Vertica (Nodo 2 - Escenario II) .............. 48

Figura 35: Uso de Procesador (Nodo 1 - Escenario III) ................................................ 49

Figura 36: Uso de Procesador (Nodo 2 - Escenario III) ................................................ 50

Figura 37: Uso de Memoria RAM (Nodo 1 - Escenario III) ......................................... 52

Figura 38: Uso de Memoria RAM (Nodo 2 - Escenario III) ......................................... 53

Figura 39: Tiempo de Respuesta (Nodo 1 - Escenario III) ........................................... 54

Figura 40: Tiempo de Respuesta (Nodo 2 - Escenario III) ........................................... 54

Figura 41: Uso de Disco I/O PostgreSQL & MonetDB (Nodo 1 - Escenario III) ........ 55

Figura 42: Uso de Disco I/O PostgreSQL & Vertica (Nodo 1 - Escenario III) ............ 55

Figura 43: Uso de Disco Duro I/O PostgreSQL & MonetDB (Nodo 2 - Escenario III) 55

Figura 44: Uso de Disco Duro I/O PostgreSQL & Vertica (Nodo 2 - Escenario III) ... 55

xiii

LISTA DE TABLAS

Tabla 1: Codificación algoritmo Lempel Ziv Welch .................................................... 13

Tabla 2: Codificación algoritmo Huffman .................................................................... 14

Tabla 3: Comparativa BDD Columnares vs BDD Relacionales ................................... 17

Tabla 4: Columnas de la Base de Datos Música ........................................................... 26

Tabla 5: Volumen de Dase de Datos Música ................................................................ 26

Tabla 6: Volumen de Datos para Escenario I ................................................................ 27

Tabla 7: Uso de Procesador (Nodo 1 - Escenario I) ...................................................... 32

Tabla 8: Uso de Procesador (Nodo 2- Escenario I) ....................................................... 32

Tabla 9: Tiempo de Respuesta (Nodo 1 - Escenario I) ................................................. 34

Tabla 10: Tiempo de Respuesta (Nodo 2 - Escenario I) ............................................... 34

Tabla 11: Uso de Memoria RAM (Nodo 1 - Escenario I) ............................................. 35

Tabla 12: Uso de Memoria RAM (Nodo 2 - Escenario I) ............................................. 36

Tabla 13: Uso de Disco (Nodo 1 - Escenario I) ............................................................ 38

Tabla 14: Uso de Disco (Nodo 2 - Escenario I) ............................................................ 39

Tabla 15: Uso de Procesador (Nodo 1 - Escenario II)................................................... 40

Tabla 16: Uso de Procesador (Nodo 2 - Escenario II)................................................... 41

Tabla 17: Uso de Memoria RAM (Nodo 1 - Escenario II) ............................................ 43

Tabla 18: Uso de Memoria RAM (Nodo 2 - Escenario II) ............................................ 44

Tabla 19: Tiempo de Respuesta (Nodo 1 - Escenario II) .............................................. 45

Tabla 20: Tiempo de Respuesta (Nodo 2 - Escenario II) .............................................. 45

Tabla 21: Uso de Disco I/O (Nodo 1 - Escenario II) ..................................................... 47

Tabla 22: Uso de Disco I/O (Nodo 2 - Escenario II) ..................................................... 48

xiv

Tabla 23: Uso de Procesador (Nodo 1 - Escenario III) ................................................. 49

Tabla 24: Uso del Procesador (Nodo 2 - Escenario III) ................................................ 50

Tabla 25: Uso de Memoria RAM (Nodo 1 - Escenario III) .......................................... 51

Tabla 26: Uso de Memoria RAM (Nodo 2 - Escenario III) .......................................... 52

Tabla 27: Tiempo de Respuesta (Nodo 1 - Escenario III) ............................................. 53

Tabla 28: Tiempo de Respuesta (Nodo2 - Escenario III) .............................................. 53

Tabla 29: Uso de Disco I/O (Nodo 1 - Escenario III) ................................................... 54

Tabla 30: Uso de Disco I/O (Nodo 2 - Escenario III) ................................................... 55

Tabla 31: Cuadro Comparativo entre Recursos y Escenarios ....................................... 56

xv

TITULO: Análisis del uso de recursos entre bases de datos columnares versus bases de

datos relacionales

Autores: Minango Román Carlos Edmundo


Tutor: Ing. Mario Raúl Morales Morales

RESUMEN

Este trabajo de investigación es de tipo experimental, exploratoria y bibliográfica, cuyo

objetivo principal es analizar qué tipo de base de datos es más eficiente en cuanto a gestión

de recursos, como son mediciones de porcentaje de uso de procesador, uso de memoria

RAM y tráfico I/O de datos en disco, mediante un estudio comparativo entre bases de

datos columnares con respecto a bases de datos relacionales. Las conclusiones fueron

evaluadas en base a un prototipo de medición y comparación entre estos dos tipos de

bases de datos, mediante el cual se efectuaron consultas masivas de datos, con comandos

de cálculo de agregación y con sentencias comparativas en cantidades que van desde 1

millón hasta 15 millones de registros.

PALABRAS CLAVE: BASE DE DATOS / COMPARACIÓN / ANÁLISIS /

RENDIMIENTO / RECURSOS / COLUMNAR / RELACIONAL

xvi

TITLE: Analysis of the use of resources between columnar databases versus relational

databases

Authors: Minango Román Carlos Edmundo


Tutor: Ing. Mario Raúl Morales Morales

ABSTRACT

This research work is experimental, exploratory and bibliographic, whose main objective

is to analyze what type of database is more efficient in terms of resource management,

such as measurements of percentage of processor use, use of RAM and traffic I / O data

on disk, through a comparative study between columnar databases with respect to

relational databases. The conclusions were evaluated based on a prototype of

measurement and comparison between these two types of databases, through which

massive data consultations were carried out, with aggregation calculation commands and

with comparative sentences in amounts ranging from 1 million to 15 million records.

KEYWORDS: DATABASE / COMPARISON / ANALYSIS / PERFORMANCE /

RESOURCES / COLUMNAR / RELATIONAL

1

INTRODUCCIÓN

En la actualidad se ha presentado un alto crecimiento de volúmenes de datos en las

organizaciones, lo cual exige un rápido tiempo de respuesta y un adecuado consumo de

recursos a nivel de hardware y software. Además, las bases de datos columnares se han

consolidado como una de las herramientas más difundidas en el entorno de

implementación en el mundo del manejo de la información. Debido a que permiten

almacenar, manipular y recuperar los datos de tablas con alto volumen de registros,

ofreciendo al mismo tiempo una mejor gestión de recursos frente a las bases de datos

relacionales.

Mediante la presente investigación se busca determinar la eficiencia de las bases de datos

columnares con respecto a las bases de datos relacionales, a través de un análisis

comparativo. En el mismo, se involucran métricas para evaluar el desempeño de estos

dos tipos de bases de datos en un entorno distribuido. Para definir qué base de datos

administra de mejor manera los recursos se utilizan consultas masivas de datos, consultas

con sentencias de cálculo de agregación y con sentencias comparativas.

2

1. DEFINICIÓN DEL PROBLEMA

1.1. Planteamiento del Problema

Debido a la existencia de grandes volúmenes de información que las empresas manejan

en la actualidad, causado por el alto uso de redes sociales, información no estructurada y

volumen transaccional se necesita una mayor velocidad de procesamiento. Por lo cual

surge la opción de utilizar bases de datos columnares, pues ofrece más eficiencia y

optimización. Estas características se deben a su estructura para el almacenamiento y

manipulación de datos, ya que maneja columnas en lugar de filas al momento de utilizar

los registros de la base de datos.

La actual investigación consiste en dar a conocer los beneficios que las bases de datos

columnares ofrecen hoy en día, con técnicas que incluyan la mejora en el rendimiento,

recursos de almacenamiento, uso de memoria RAM, tiempo de respuesta y

procesamiento; y descubrir qué factores propician un alto o bajo grado de optimización

de recursos al momento de ser implementados.

1.2. Formulación del Problema

¿La investigación del análisis del uso de recursos entre bases de datos columnares versus

bases de datos relacionales ayudará a una mejor implementación al momento de consumir

recursos y mejorar el tiempo de respuesta ante solicitudes de datos?

1.3. Interrogantes de la Investigación

¿Qué tipo de base de datos gestiona de mejor manera los recursos?

¿Cómo varía el desempeño en varios escenarios con consultas en bases de datos

columnares y relacionales?

3

1.4. Objetivos de la Investigación

1.4.1. Objetivo General

Definir qué tipo de base de datos es mejor en cuanto a gestión de recursos mediante un

análisis comparativo entre Bases de Datos Columnares con respecto a Bases de Datos

Relacionales.

1.4.2. Objetivo Específicos

Analizar qué tipo de base de datos consume menos recursos en hardware y

software durante el procesamiento masivo de datos.

Analizar los resultados obtenidos al comparar las dos bases de Datos Columnares

y Relacionales.

1.5. Justificación

Las bases de datos Columnares se han popularizado como una mejor propuesta de valor

para una carga de trabajo analítica especializada, obteniendo logros como aplicabilidad,

mayor velocidad y alto rendimiento, orientado hacia un nuevo enfoque que viene ganando

reconocimiento por su versatilidad y escalabilidad. Además, este tipo de base de datos

presume ser más flexible y permitir el procesamiento de grandes cantidades de

información, centrándose en la escalabilidad, que hace referencia a los procesos de

analizar grandes volúmenes de datos. Se observa que esta nueva tecnología es de gran

ayuda para el manejo de información y su aplicación se expande a diferentes sectores de

la sociedad donde el manejo de grandes volúmenes de datos es esencial.

1.6. Alcance

Esta investigación genera diferentes escenarios de volúmenes de información aleatoria en

bases de datos columnares y relacionales para analizar los resultados en cuanto al uso de

4

recursos tanto físicos como lógicos, recursos en almacenamiento, uso de memoria RAM,

tiempo de respuesta y procesamiento.

1.7. Limitaciones

Este análisis comparativo entre bases de datos columnares y relacionales estará orientado

solamente al uso de recursos, no se enfoca en un análisis detallado de velocidad en tiempo

de respuesta.

5

2. MARCO TEÓRICO

2.1. Antecedentes

En la actualidad, existen algunos estudios e investigaciones relacionadas con las bases de

datos relacionales y columnares, obteniendo algunas ideas importantes, las cuales han

sido útiles para este estudio.

Por ejemplo, en un trabajo investigativo para el Journal of King Saud University

correspondiente a una evaluación del rendimiento de las bases de datos In-Memory

(IMDB) se planteó que las bases de datos NoSQL se basan en el modelo de coherencia

BASE en lugar del modelo de coherencia ACID, renunciando a cierta consistencia para

proporcionar más disponibilidad, escalabilidad y alto rendimiento. Las bases de datos

NoSQL se han incrementado debido a la necesidad de procesar una gran cantidad de datos

más rápido que los sistemas de administración de bases de datos relacionales al

aprovechar la arquitectura altamente escalable, flexible (schema-free), estructura de

datos, baja latencia y alto rendimiento (Kabakus & Kara, 2016).

Las bases de datos In-Memory están orientadas en una estructura columnar para asegurar

un alto nivel de comprensión de datos y velocidad de acceso (Morales Morales & Morales

Cardoso, 2017). En la presente investigación, se busca demostrar con casos prácticos la

proposición a la que llegaron los autores en el estudio ya mencionado.

Basándonos en estas premisas, esta investigación también busca realizar un análisis en

cuanto al consumo de recursos de las bases de datos relacionales con respecto a las bases

de datos columnares, proponiendo opciones específicas de uso, para llegar a comprobar

o negar la hipótesis de la presente tesis.

Mediante esta investigación, se pretende proporcionar información confiable y práctica

acerca de los beneficios de las bases de datos columnares y cómo mejoran el rendimiento

6

en el procesamiento de los datos, con el fin de que sirva para la futura toma de decisiones

empresariales en este campo.

2.2. Marco Conceptual

2.2.1. Introducción a Bases de Datos Relacionales y Columnares

En el mundo del manejo de la información, siempre se ha requerido un rápido acceso a

los datos y además un óptimo uso de recursos, tanto para tareas de Procesamiento

Analítico en Línea (OLAP) como para tareas de Procesamiento de Transacciones en

Línea (OLTP). Para que estos requerimientos sean satisfechos, se deben tomar en cuenta

las arquitecturas disponibles, como son 32 y 64 bits. Dentro de este estudio se pone

especial énfasis en la arquitectura de 64 bits, puesto que sus sistemas aprovechan de mejor

manera el uso del CPU brindando más eficiencia en el hardware, ya que los bloques de

memoria se asignan más fácilmente y en mayor volumen que en la arquitectura de 32 bits.

Esta característica es beneficiosa para los sistemas de gestión de bases de datos en

memoria (IMDB) debido al enfoque que tienen en cuanto a consultas y análisis que son

realizados dentro de la memoria RAM. La diferencia con los sistemas de gestión de bases

de datos relacionales (RDBM) radica en que forman cuellos de botella al acceder al disco

para la obtención de datos (Baboo & Kumar, 2013).

En las limitaciones en cuanto a memoria volátil para estas arquitecturas, tenemos que la

arquitectura de 32 bits está condicionada a trabajar hasta con 4GB en RAM, y en el caso

de la arquitectura de 64 bits, tiene un límite de hasta 192GB para equipos de escritorio y

24TB para servidores (Da Costa, 2016).

Siendo que las bases de datos relacionales pertenecen a las RDBM y las bases de datos

columnares pertenecen a las IMDB, tenemos que en las primeras la lectura se realiza a

toda la fila con el fin de acceder a los atributos necesarios. Al contrario, en las bases de

datos columnares los datos están organizados y almacenados en columnas para poder

recuperar sólo los valores solicitados en las columnas específicas (ver Fig. 1).

7

Figura 1. Almacenamiento BD Relacionales vs BD Columnares (Garcete, 2012)

El almacenamiento en filas es útil en consultas donde todas las columnas de una fila son

necesarias, es decir, es ideal para el mundo transaccional donde usualmente se necesita

todo el detalle de una entidad. En cambio, el almacenamiento en columnas se utiliza

cuando solo se requieren algunas de ellas para el análisis y lo que se busca es información

consolidada (sumas, cantidades, promedios). Este almacenamiento es bastante útil para

un mundo analítico donde la información se concentra en la métrica de distintas entidades

(Vivas, Cambarieri, Petroff, García, & Formia, 2015).

Si bien la mayoría de sistemas de gestión de base de datos con los que se trabaja son

orientados a filas, desde la década de los 70 ya existían las bases de datos columnares

como otra opción. Han sido implementadas en productos como Model 204 y ABABAS, en

los cuales, los datos están organizados en columnas en lugar de filas. Se almacenan todos

los casos de un solo elemento de datos (por ejemplo, Nombre de cliente) para que su

acceso sea como al de una unidad (Garcete, 2012). Esto los hace especialmente eficaces

en las consultas, ofrecen un mejor rendimiento y velocidad.

Una base de datos In-Memory (IMDB) usa la memoria como el principal soporte de

almacenamiento, comparado con los clásicos sistemas de gestión de base de datos que

usan el disco como lugar de almacenamiento principal (Babeanu & Ciobanu, 2015). Las

IMDBs 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. La organización de

los valores en la forma de un vector de atributos (columnar) permite una fácil compresión

de datos y también permite una alta velocidad de escaneo y filtraje (Morales Morales &

Morales Cardoso, 2017).

8

2.2.2. Base de Datos Relacional

Las bases de datos relacionales son modelos de datos utilizados para modelar problemas

reales y administrar datos dinámicamente. Su idea fundamental radica en las relaciones

que se dan entre las entidades del diagrama como conjuntos de datos (tuplas). Cada

relación funciona como una tabla compuesta por campos y registros (Córdova Espinoza

& Cuzco Sarango, 2013).

En una base de datos relacional, los datos están conectados por medio de relaciones entre

las tablas que los almacenan, es decir, sus registros se guardan en fila, de forma

secuencial, uno tras otro (ver Fig. 2).

Figura 2. Tabla en el modelo de Datos Relacionales (Elaboración de los autores)

Por ejemplo, tomando en cuenta la información de la Figura 2, una base de datos

relacional almacena los registros de la siguiente forma:

Figura 3. Almacenamiento de BD Relacionales (Elaboración de los autores)

En formato de filas, todos los atributos de entrada son almacenados uno junto a otro como

una secuencia, usando uno o múltiples bloques de memoria. Al acceder al disco para la

lectura de datos, se lee el registro completo y de forma consecutiva. Este tipo de acceso

9

resulta útil para sistemas OLTP, puesto que las bases de datos relacionales son “write-

friendly”, es decir, es bastante simple agregar una fila de datos a una tabla (Venkat, 2007),

pero no se utiliza para sistemas OLAP que son del interés de este estudio.

2.2.3. Base de datos Columnar

El formato de almacenamiento de este tipo de base de datos es columnar, su ventaja radica

cuando aumenta el volumen de datos y éstos empiezan a ser menos estructurados; al

guardar los datos en columna, aumenta la posibilidad de compresión y los tiempos de

respuesta de las peticiones disminuyen. La desventaja de estas bases de datos es que solo

permite la actualización de procesos (en el disco) por lotes, que tiene un tiempo de

actualización mucho más lento que los modelos tradicionales (Jara, 2012).

Las bases de datos columnares están orientadas a consultas analíticas (OLAP),

proporcionando alta velocidad de desempeño y que al final, significa menos horas de

trabajo. Además, las sentencias OLAP a pesar de ser más complejas tienen un menor

tamaño de almacenamiento, lo que hace que se optimicen los recursos y el rendimiento

en el manejo de grandes volúmenes de datos. (Matei, 2010).

En bases de datos columnares, el manejo de registros es de tipo clave-valor (ver Fig. 4):

Figura 4. Manejo de Registros en BD Columnares (Elaboración de los autores)

10

De este modo, una base de datos columnar almacena los registros de la siguiente forma:

Figura 5. Almacenamiento de BD Columnares (Elaboración de los autores)

2.2.3.1. Características

Vatika Sharma y Meenu Dave en su publicación SQL and NoSQL Databases (Sharma &

Dave, 2012), indican que las bases de datos columnares tienen las siguientes

características:

Son más rápidas que las bases de datos orientadas a filas en las consultas.

En las bases de datos columnares, la asignación de la unidad de almacenamiento

se realiza a cada columna.

En la DBMS (Data Base Management System) columnar, solo se leen las

columnas requeridas, lo que hace la lectura más rápida en este caso.

Además de estas características, en la publicación A Comparative Study of Database

Systems (Bajaj & Dhindsa, 2012) se habla acerca de una característica muy importante

como es la de la compresión de datos dentro de las bases de datos columnares:

a) Compresión de datos: La compresión es una técnica usada por muchos sistemas

de gestión de bases de datos para incrementar el rendimiento. Esta técnica reduce

el tamaño del uso de recursos, disminuye los tiempos de búsqueda y aumenta la

tasa de transferencia de datos. Por ejemplo, en una tabla de clientes con

información como nombre, teléfono, e-mail, etc., el almacenamiento de las bases

de datos columnares permite que todos los nombres sean almacenados juntos. En

el caso de campos numéricos como los números telefónicos, serán más similares

entre sí que los campos de texto que lo rodean. Además si los datos están

ordenados por una de las columnas, esta columna será la que mayor compresión

obtenga. La compresión es útil porque ayuda a reducir el alto consumo de

recursos, como el espacio en el disco duro o transmisión de ancho de banda. De

11

esta forma, es relevante resaltar otras características de la compresión en las bases

de datos columnares frente a otros tipos de bases de datos.

b) Uso mejorado del ancho de banda: dentro del aspecto de base de datos

columnar, se leen desde la memoria solo aquellos atributos de la consulta, que, a

diferencia de las bases de datos orientados a filas, se leen todos los atributos

circundantes para obtener el campo deseado.

c) Uso mejorado del caché: Al leer atributos irrelevantes para la consulta, se

desperdicia espacio en la memoria caché y reduce la tasa de aciertos.

Para complementar el significado de la compresión, destacamos algunas de las ideas

importantes del artículo Column-Stores vs Row-Stores: How Different Are They Really?

(Abadi, Madden, & Hachem, 2008):

a) Se puede asegurar que la compresión mejora el rendimiento ya que se invierte

menos tiempo en entrada y salida de datos a medida que se realiza la lectura desde

el disco a la memoria o de la memoria al CPU.

b) En las bases de datos columnares, al tener valores repetidos dentro de una

columna, luego de ser comprimidos, las repeticiones se resumen y se opera

directamente sobre este resumen, que, a diferencia de las bases de datos orientadas

a filas, éstas complican el proceso mediante las lecturas redundantes de datos

innecesarios.

Al comprimir datos, se utilizan métodos que examinan y buscan redundancia en los

mismos para poder comprimirlos aplicando algoritmos que eliminen o remuevan dicha

redundancia, pero esta compresión depende mucho del tipo de dato, ya que no existe un

método universal de compresión. Al momento de clasificar la compresión de datos,

podemos tomar en cuenta como aspecto crítico a la integridad de la información, de esta

manera tenemos (Kodituwakku & Upali, 2010):

a) Compresión con pérdida: También llamado lossy, tiene una mayor taza de

compresión, pero a cambio, existe una leve pérdida de información con una

calidad aceptable. En la descompresión, la reconstrucción obtenida es una

12

aproximación a los datos originales, se utiliza en aplicaciones orientadas al

entretenimiento, que manejan imágenes, audio y video.

b) Compresión sin pérdida: Conocido también como lossless, en este tipo de

compresión se reconstruyen exactamente los datos originales al momento de

descomprimirlos. Esta técnica emplea métodos estadísticos y es utilizada en

aplicaciones con compresión de texto.

Al clasificar a la compresión por las técnicas que usa, tenemos a los algoritmos de

compresión que se basan en el análisis inicial de las secuencias de datos para tomar las

secuencias repetidas y armar un diccionario de equivalencias y luego transformar los

datos iniciales con estas equivalencias. Además, el diccionario generado no es

almacenado físicamente, obteniendo un archivo de menor tamaño (Blelloch, 2013), de

manera referencial, dentro de estos algoritmos tenemos los siguientes:

a) Lempel Ziv Welch (LZW): Es un algoritmo sin pérdida orientado a su

diccionario, escanea la información en búsqueda de secuencias de datos que

ocurran más de una vez (Islam & Arafat, 2014).

Su principal ventaja radica en que no asume nada sobre las propiedades de la

entrada antes de recibirla, es decir, construye el diccionario para la compresión a

partir de datos como tal. La desventaja de este algoritmo es que requiere una

construcción secuencial del diccionario. Además, es necesaria una comparación

constante de los datos de entrada con el contenido del diccionario durante la

compresión (Yang, Yang Guo, Yong, & Guo, 2015).

Para entender mejor este algoritmo, se presenta su pseudocódigo y un ejemplo (Wang,

Yang, Cheng, & Chang, 2013):

i. Al inicializar un diccionario, éste va a tener un formato de tabla, donde se asigna

a cada letra un código de 0 a M-1.

ii. Luego, se inicializa la primera letra de la frase P.

iii. S será el siguiente caracter de la frase.

iv. De tal forma, si PS es una palabra en el diccionario

13

P=PS e ir al paso 3

v. Caso contrario

Añadir PS al diccionario, asignándole un código n no utilizado c(PS)=n,

luego P=S e ir al paso 3.

Para el ejemplo, tenemos un alfabeto con 3 letras A, B, C, y queremos codificar la palabra

ABACABA:

Tabla 1: Codificación algoritmo Lempel Ziv Welch (Elaboración de los autores)

De esta forma, el valor de la palabra ABACABA al pasar por el algoritmo LZW sería

010230 tomando en cuenta los valores de la columna P.

b) Run Length Encoding (RLE): Es una de las técnicas más simples de compresión

de datos, donde su principal objetivo es eliminar la redundancia de la información

(Seleznjev & Shykula, 2012) y divide los datos comprimidos en dos categorías

(Martínez Prieto, 2010):

Símbolos repetidos: Se refiere a los símbolos que pueden comprimirse,

reemplazando la cantidad de veces que un dígito se repite por número

entero y luego éste transformarlo a binario para la descompresión.

Símbolos no repetidos: Son los símbolos que no pueden comprimirse

porque no están repetidos.

14

En la Fig. 7, encontramos un ejemplo de cómo funciona RLE, donde cada repetición de

0’s es reemplazada por 2 caracteres en el código de compresión, de esta forma, el 0 indica

el carácter que se está repitiendo y luego el número de veces que se repite:

Figura 6: Funcionamiento Run Length Encoding (RLE) (Elaboración de los autores)

c) Codificación Huffman: Consiste en un código de longitud variable, donde su

longitud cambia según la frecuencia relativa de aparición de cada símbolo en un

texto: cuanto más frecuente sea un símbolo, su código asociado será más corto; se

elimina la ambigüedad puesto que este código no lleva prefijos (Salomon, 2014).

Para entender de una mejor forma el funcionamiento del algoritmo de Huffman, se tiene

el siguiente ejemplo en la Tabla. 2, donde se puede visualizar que este algoritmo también

utiliza la probabilidad de ocurrencia de cada carácter y para la codificación agrupa el

código binario de todos los caracteres en grupos de 8 bits (ver Fig. 7).

Tabla 2: Codificación algoritmo Huffman (Elaboración de los autores)

15

Figura 7: Funcionamiento Codificación Huffman (Elaboración de los autores)

Otro elemento importante para este estudio está relacionado con los paradigmas ACID,

BASE y CAP (Teorema de Brewer) para garantizar la confiabilidad de las transacciones

mediante sus propiedades deseables, de esta forma, tenemos que para ACID, sus

propiedades son (Lorente Borox, 2015):

a) Atomicidad (Atomicity): Esta propiedad busca que toda o ninguna operación de

una transacción se refleje en la base de datos, las transacciones se ejecutan por

completo, es decir, las operaciones no quedan a medias, en caso de falla no se

realiza cambio alguno a la base de datos.

b) Consistencia (Consistency): Significa no violar las restricciones de la integridad

de la base de datos, busca preservar su coherencia, la ejecución de la transacción

debe realizarse de forma aislada, es decir, no ejecutar ninguna transacción al

mismo tiempo en un mismo registro y además esta transacción debe ser válida de

acuerdo a las reglas definidas.

c) Aislamiento (Isolation): Las transacciones que se llevan a cabo son

independientes entre sí, de esta forma se garantiza que una operación no afecte a

otras operaciones.

d) Durabilidad (Durability): Al completar exitosamente una transacción, los

cambios que hayan sido realizados en la base de datos y los efectos que estos

conllevan deben ser permanentes, incluso si se presenta una falla en el sistema.

Por otro lado, en el año 2000 Eric Brewer presentó el modelo CAP para sistemas de

computación distribuida; este teorema asume una concurrencia en un entorno distribuido

16

y no en un administrador central de concurrencia como el modelo clásico, de esta forma,

sus características son (Cruz, Manjarrez, Martínez Castro, & Cuevas Valencia, 2014):

a) Consistencia (Consistency): Al realizar una consulta o inserción siempre se tiene

que recibir la misma información, con independencia del nodo o servidor que

procese la petición.

b) Disponibilidad (Availability): Significa que el servicio o sistema está disponible

cuando se hace una petición.

c) Tolerancia a partición (Partition tolerance): O robustez, significa que, dado un

sistema, tiene que seguir funcionando, aunque existan fallos o caídas parciales que

dividan el sistema.

A diferencia de las bases de datos relacionales, las bases de datos columnares siguen el

modelo BASE, que tiene un enfoque similar a ACID pero que se diferencia al perder

consistencia y aislamiento, pero a cambio, favorece la disponibilidad y el rendimiento.

De tal forma, las características de BASE son (Lorente Borox, 2015):

a) Disponibilidad Básica (Basic Availability): Con esta característica el sistema

garantiza su funcionamiento la mayor parte del tiempo, incluso ante posibles

fallos debido al almacenamiento distribuido y replicado.

b) Estado Flexible (Soft-State): Los sistemas no tienen por qué ser consistentes en

todo momento.

c) Consistencia Eventual (Eventual Consistency): Dentro del sistema y en la

ejecución de la tarea, la consistencia se produce de forma eventual.

En base a estas características tanto generales como relacionadas a ACID, BASE y CAP,

podemos utilizar un cuadro comparativo propuesto por Ana María Lorente Borox1 tal

como se muestra a continuación:

1 Almacenes de datos NoSQL, Estudio de la Tecnología, características de bases de datos Relacionales y

las bases de datos Columnares.

17

Tabla 3: Comparativa BDD Columnares vs BDD Relacionales (Lorente Borox, 2015)

Bases de Datos Columnares versus Bases de Datos

Relacionales

Características Columnares Relacionales

Sistemas de

Almacenamiento

comerciales

Vertica

MonetDB

HBase

Hypertable

PostgreSQL

Oracle

MySQL

SQLite

Modo de

almacenamiento

Columnar y clave-valor

Relacional almacenamiento por

filas

Escalabilidad Altamente escalable Difícilmente escalable, datos en

un punto concreto

Consistencia Consistencia eventual Altamente consistente

Disponibilidad Alta disponibilidad En un punto, cuellos de botella

Recomendado

para

Procesamiento y escaneo de

grandes cantidades de datos

Operaciones y transacciones que

impliquen muchas relaciones

Datos estructurados

Casos de uso Escaneo masivo de datos

Banca, industria financiera

Informes históricos

Bases de datos científicas

Gestión empresarial

Recursos humanos

Las bases de datos columnares son de tipo In-Memory Data Base (IMDB), por lo tanto,

las siguientes características relacionadas con este tipo de base de datos son (Morales

Morales & Morales Cardoso, 2017).

a) Caching: Esta técnica consiste en mantener la data más reciente usada en

memoria, además asegura la consistencia con la base de datos física y el

cachelookup2 en caso de que los datos sean requeridos. Dentro de las IMDB los

procesos de caching han sido removidos, es decir, que la sobrecarga de

rendimiento y los procesos entre RAM y CPU son eliminados.

b) Procesamiento de transacciones: Para cualquier sistema de base de datos, uno

de los aspectos críticos es el de prevenir pérdidas, tanto de datos como de archivos

de registro como logs y backups, así como también guardar su integridad. En el

2 Método donde los registros se cargan en la memoria al cargar la tabla por primera vez

18

caso de las IMDB se mantiene la imagen original de los datos nuevos y

modificados en la memoria, al confirmar la transacción, estas imágenes son

enviadas para realizar el almacenamiento, en caso de abortar la transacción, se

recupera la base de datos original a la memoria

2.2.3.2. Ventajas y desventajas de las bases de datos columnares

A diferencia de las bases de datos relacionales que tienen la información de todo un

registro inmediatamente accesible, las bases de datos columnares leen unos pocos

elementos de datos para realizar la consulta que necesita. Según Harrison Guy en su libro

Next Generation Databases explica que existen dos grandes ventajas en la arquitectura

columnar (Harrison, 2015):

a) Las consultas que buscan valores de columnas específicas se optimizan, porque

todos los valores que se recuperan están dentro del mismo bloque de disco, lo que

significa que, para consultas en grandes cantidades de datos, ya no es necesario

escanear fila por fila hasta encontrar el campo deseado y luego ir a la siguiente

fila, como lo hacen las bases de datos relacionales, sino que se necesita de un solo

acceso a un determinado bloque de memoria. Las optimizaciones brindadas por la

arquitectura columnar varían según la carga de trabajo, indexación y el diseño del

esquema.

b) La segunda ventaja clave para la arquitectura columnar es la compresión. Los

algoritmos de compresión funcionan principalmente al eliminar la redundancia

dentro de los valores de datos, al tener datos altamente repetitivos se logran

índices de compresión más altos que los datos con baja repetición. Aunque la

cantidad total de repetición es la misma en todas las bases de datos,

independientemente de la orientación de fila o columna, los esquemas de

compresión generalmente intentan trabajar en subconjuntos localizados de los

datos; la sobrecarga de la CPU en la compresión es mucho más bajo si centra su

trabajo en bloques de datos aislados. En muchos casos, una base de datos en

columnas almacenará datos en orden, lo que representa que se pueden lograr

relaciones de compresión muy altas simplemente representando el valor de cada

19

columna como un "delta" del valor de la columna anterior. El resultado es una

relación de compresión extremadamente alta lograda con muy baja carga

computacional.

En el estudio Column Oriented Databases Vs Row Oriented Databases realizado por los

autores Ventak & Rakesh encontramos las siguientes ventajas que se complementan con

las citadas anteriormente (Venkat, 2007):

a) Mientras que el almacenamiento en filas es extremadamente "amigable con la

escritura", en el almacenamiento columnar resulta mejor para consultas de lectura

complejas. Para tablas con muchas columnas se limitan las lecturas a las columnas

requeridas, mientras que un almacén de filas debe leer toda la tabla, lo que reduce

en gran medida el número de lecturas de disco reales necesarias para satisfacer

una consulta.

b) Los datos de columna son de tipo uniforme, por lo tanto, son más fáciles de

comprimir que los datos en fila y los valores NULL pueden ser omitidos. El

almacenamiento en fila no puede omitir columnas de ninguna fila ni tener acceso

aleatorio a una tabla, puesto que requeriría que los datos de cada fila sean de ancho

fijo, en cambio, en las bases de datos columnares, estos aspectos son triviales

debido a la uniformidad de datos en una sola columna, lo que permite la omisión

de valores NULL y almacenamiento eficiente en tablas escasamente pobladas.

La principal desventaja de la arquitectura columnar es la sobrecarga en operaciones de

una sola fila (Harrison, 2015). Por esta razón, la arquitectura columnar no es una opción

para OLTP debido a que recuperar una sola fila implica ensamblar la fila con cada uno

de los bloques de memoria únicamente para esa solicitud. La sobrecarga de lectura se

puede reducir en parte mediante el almacenamiento en caché y las proyecciones en

múltiples columnas, pero cuando se trata de operaciones DML3 (Lenguaje de

Manipulación de datos), particularmente inserciones, no hay forma de evitar el tener que

modificar todas las columnas para cada fila (Harrison, 2015).

3 Sentencias DML son: INSERT: Añade registros a una tabla. UPDATE: Modifica registros existentes de

una tabla. Y DELETE: Elimina registros existentes de una tabla.

20

Ahora, tomando en cuenta que las bases de datos columnares son de tipo IMDB4 y

refiriéndonos a aspectos de memoria, una de las desventajas de este tipo de bases de datos

radica en la durabilidad, puesto que, todo el trabajo que realizamos está en la memoria

RAM (de tipo de almacenamiento volátil). La memoria RAM requiere de un suministro

de energía para mantener la información almacenada, caso contrario, su contenido se

perderá al tener algún corte de energía de dicho suministro (Morales Morales & Morales

Cardoso, 2017). Esta característica resulta ser una vulnerabilidad directa y afectación en

la durabilidad. El autor Pattaravadee Sakulsorn apoya el planteamiento de esta desventaja

al asegurar que una gran diferencia entre la IMDB y los sistemas tradicionales basados

en disco es que las imágenes de una IMDB se perderán si el sistema se enfrenta a una

situación catastrófica (Sakulsorn, 2011).

4 Base de Datos En Memoria (In Memory Database)

21

3. METODOLOGÍA

3.1. Metodología de Investigación

El tipo de investigación a realizar es de tipo aplicada ya que, al ser práctica, sus resultados

son utilizados inmediatamente en la solución de problemas empresariales cotidianos.

Además se aplica el diseño descriptivo (cuantitativo) como nivel de desarrollo especifico,

pues este tipo de diseño utiliza estudios que se abocan más a la amplitud y precisión que

a la profundidad, es decir, utiliza métodos y técnicas tanto para la recolección de datos

como para su análisis (Vara Horna, 2012). Asimismo, se aplicará un subtipo descriptivo

comparativo pues los resultados se han obtenido mediante una herramienta para la

comparabilidad de bases de datos columnares y relacionales.

Es importante recalcar que además se realiza una investigación bibliográfica, mediante

consultas en estudios previamente realizados, artículos y tesis tanto de fuentes relevantes

académicamente, así como también consultas de reconocidos sitios web para conocer qué

bases de datos se va a utilizar en la comparación.

3.2. Diseño Descriptivo

Para este estudio comparativo, se utilizarán volúmenes de datos con variaciones desde 1

millón, 5 millones, 10 millones y 15 millones de registros, para analizar las variables

planteadas, controlar y medir cualquier cambio de una manera eficiente y ordenada y

demostrar así el beneficio en cuanto a manejo de recursos que tienen las bases de datos

columnares sobre las relacionales.

3.3. Procedimiento

Para la realización del presente estudio comparativo el procedimiento a seguir es el

siguiente:

22

a) Determinación Muestral: Consiste en la selección de los motores de bases de

datos columnares y relacionales, mismas en las que se aplicarán las pruebas de

rendimiento de recursos.

b) Selección / Creación del Conjunto de Datos: Este paso se enfoca en buscar y/o

generar el conjunto de datos a utilizar en la realización de las pruebas. Este

conjunto de datos debe tener una procedencia confiable y verificable o provenir

de la elaboración de los investigadores.

c) Diseño del Escenario de Pruebas: A continuación, se procede a definir la

realización de las pruebas, las consultas con sus respectivas sentencias para cada

escenario, el número de mediciones que se realizarán. Además, se especifica las

métricas a utilizar y se determina si el volumen de datos es representativo para el

análisis o si es necesario ampliar o disminuir dicho volumen. Este último aspecto

dependerá del análisis del investigador.

d) Entorno de Pruebas: Es importante también especificar la infraestructura de

cada uno de los nodos que serán utilizados en el entorno distribuido, es decir

características de hardware y software.

e) Métricas: Consiste en registrar los valores para las métricas de los escenarios

planteados anteriormente para su posterior análisis.

f) Análisis de Resultados: Como parte final de la investigación se procede al

estudio de los valores obtenidos, así como también a la realización de tablas y

graficas en torno a estos valores para una mejor interpretación de los resultados

que sirvan de ayuda a la compresión de las conclusiones obtenidas.

23

4. CÁLCULOS Y RESULTADOS

4.1. Determinación Muestral

Se eligió trabajar con 3 bases de datos, dos de ellas columnares y una relacional, también

se necesitó de herramientas gráficas de administración para cada uno de los motores de

bases de datos, la selección se realizó según sus características, que se presentan a

continuación:

4.1.1. Vertica (versión 9.0.1-0)

De propiedad de HP, Vertica está diseñada para el

almacenamiento de grandes volúmenes de datos, con

su arquitectura distribuida organiza los datos en

columnas para ofrecer una velocidad y compresión más

efectiva, un mejor volumen de datos en la lectura, mayor

procesamiento y optimización a los accesos de los datos. Vertica utiliza el

almacenamiento columnar ya que es ideal para operaciones intensivas de lectura, pues

reduce drásticamente el número de accesos al disco, en comparación con el

almacenamiento basado en filas de las bases de datos relacionales (Vertica, 2018).

Para la administración, consultas y obtención de resultados de forma gráfica para Vertica

se utilizó DBeaver en su versión 5.1.0, que se autodenomina como una herramienta

gratuita de base de datos multiplataforma, de código abierto, de simple descarga y de fácil

uso (DBeaver, 2014).

4.1.2. MonetDB (versión 11.23.13)

Este DBMS está orientado al almacenamiento de bases

de datos de alto rendimiento. Mediante su modelo de

fragmentación vertical, ajusta la ejecución de consultas

Figura 8: Logo Vertica (Logo

Página Oficial Vertica).)

Figura 9: Logo MonetDB (Logo

Página Oficial de MonetDB)

24

al CPU con la utilización de índices automáticos y adaptivos lo que conlleva una

optimización en tiempos de ejecución. Además, MonetDB se ha hecho acreedor a varios

premios con su tecnología de almacenamiento columnar, posicionándola en el mercado

para aplicaciones potenciadas por estas técnicas por su alto nivel de respuesta y

rendimiento (MonetDB, 2017).

Puesto que MonetDB no tiene una herramienta de administración nativa, se eligió una

herramienta que se adapte lo mejor posible a los requerimientos hacia los que va orientada

esta investigación. De esta forma se trabajó con SQL Workbench/J en su versión

1.8.0_171, ya que es una herramienta de consulta SQL gratuita, independiente de DBMS

y multiplataforma, está escrita en Java y tiene como objetivo principal la ejecución de

secuencias de comandos SQL (Workbench/J, 2017).

4.1.3. PostgreSQL (versión 9.3.22):

Es un potente sistema de base de datos relacional, utiliza y amplía

el lenguaje SQL combinado con muchas características que

almacenan y escalan de forma segura las cargas de trabajo de datos

más complicadas. Cuenta con una arquitectura confiable, integridad

de datos y extensibilidad en el manejo de los datos (PostgreSQL,

2018). A diferencia de los motores de bases de datos anteriormente

citados, PostgreSQL tiene una herramienta de administración nativa,

llamada pgAdmin y que fue utilizada en su versión 1.18.1; pgAdmin

es la plataforma de administración y desarrollo de código abierto más popular y rica en

características para PostgreSQL (pgAdmin, 2018).

Para el monitoreo de las mediciones que se tomaron, se utilizó la herramienta

especializada para Linux NetData:

Figura 10: Logo

PostgreSQL (Logo

Página Oficial de

PostgreSQL)

25

4.1.4. NetData (versión 1.10.1)

Ofrece valores de las métricas en tiempo real con paneles web

interactivos y potentes medidores de rendimiento, información del uso

de CPU, RAM, discos, red, firewall, etc., además tiene 0 dependencias,

no requiere mantenimiento, utiliza solo el 1% de CPU, pocos MB de

RAM y ninguna E/S de disco (NetData, 2017).

Figura 12: Medidor de Rendimiento del Sistema (NetData, 2017)

4.2. Selección / Creación del Conjunto de Datos

Para el desarrollo de esta investigación se usaron diferentes volúmenes de datos, cada uno

en una tabla para cada base de datos y cuenta con las siguientes columnas:

Figura 11: Logo

NetData (Logo

Página Oficial de

NetData)

26

Tabla 4: Columnas de la Base de Datos Música

(Elaboración de los autores)

Nombre de la Columna Definición Longitud

Calificación Float 20

Id Character 50

Nombre Character 500

Ciudad Character 100

Lanzamiento Character 500

Genero Character 100

Titulo Character 500

Año Integer 50

4.2.1. Volúmenes de Base de Datos

Para la obtención de métricas y el análisis de esta investigación se implementaron los

siguientes volúmenes de datos:

Tabla 5: Volumen de Dase de Datos Música


Tabla de Datos Volumen

musica1 1.000.000 registros




4.3. Diseño del Escenario de Pruebas

Para las mediciones se plantearon 3 posibles escenarios, los cuales consisten en rescatar

la esencia de las consultas analíticas OLAP, con obtención masiva de datos de los

diferentes volúmenes ya descritos, de tal forma los escenarios son:

27

4.3.1. Escenario I:

Debido a que las sentencias OLAP se basan en consultas analíticas, se propuso la

siguiente consulta para obtener la mayor cantidad de registros de una tabla y así probar el

rendimiento de los nodos con las bases de datos:

SELECT * FROM TABLA;

Al obtener la mayor cantidad de registros de una tabla, se puede saber qué cantidad de

recursos se utilizan en cada nodo por consulta. Debido a que la respuesta a esta consulta

contiene un gran volumen de datos, se procede a reducir la cantidad de registros en cada

tabla, pero con valores equivalentes a los originales, puesto que la memoria RAM y los

procesadores utilizados no abastecieron para los resultados obtenidos, teniendo las

siguientes cantidades:

Tabla 6: Volumen de Datos para Escenario I


Tabla de Datos Volumen % del Total

musica1 100.000 registros 10,00%

musica5 500.000 registros 10,00%

musica10 1.000.000 registros 10,00%

musica15 5.000.000 registros 33,33%

4.3.2. Escenario II:

Para el segundo escenario, se realizó una consulta con sentencias de cálculo de agregación

mediante la cual se obtiene un solo valor luego de haber procesado toda la tabla mediante

operaciones de suma en una columna de tipo INTEGER y obtención de promedio en otra

columna de tipo FLOAT, con lo cual la consulta es la siguiente:

SELECT SUM(año), AVG(calificación) FROM TABLA;

Mediante esta consulta se hace un recorrido por todos los registros de la tabla y a su vez

se realizan 2 operaciones matemáticas en sus columnas, esto para conocer cuántos

recursos se utilizan para este tipo de consultas.

28

4.3.3. Escenario III:

Este escenario se enfocó en la obtención de al menos una tercera parte de los registros

por tabla, además de la mitad de columnas de cada tabla, es decir cuatro campos:

SELECT nombre, año, calificación, ciudad FROM TABLA WHERE año>0 AND

año<2003 ORDER BY (nombre);

De esta forma se obtiene un volumen de datos luego de realizar una sentencia comparativa

como es el WHERE y ordenando los datos resultantes mediante la sentencia ORDER BY,

esto con el objetivo de evaluar qué impacto tienen en los recursos las sentencias de

comparación, validación y ordenamiento.

4.4. Entorno de Pruebas

Para la presente investigación, se utilizó un entorno distribuido para la toma de datos, que

consiste en 2 nodos con las siguientes características:

Figura 13: Entorno Distribuido para el Análisis (Elaboración de los autores)

Nodo 1:

Sistema Operativo: Ubuntu 14.04 de 64 bits

Procesador: Intel® Core™ i7 de 2.30GHz

Memoria RAM: 8 GB

29

Disco Duro:

o Capacidad: 750 GB

o Marca: Toshiba

o Velocidad de Transferencia: 3.0 Gbps

o Velocidad de Rotación: 5400 RPM

o Dirección IP: 192.168.1.2

Nodo 2:

Sistema Operativo: Ubuntu 14.04 de 64 bits

Procesador: Intel® Core™ i3 de 2.40GHz

Memoria RAM: 8 GB

Disco Duro:

o Capacidad: 320 GB

o Marca: Samsung

o Velocidad de Transferencia: 3.0 Gbps

o Velocidad de Rotación: 5400 RPM

o Dirección IP: 192.168.1.3

4.5. Mediciones

4.5.1. CPU o Procesador:

En esta métrica se puede visualizar el porcentaje de uso del CPU, tanto a nivel general

como núcleo a núcleo, de esta forma podemos determinar si existe algún proceso que está

formando un cuello de botella. En la toma de datos en esta investigación se elimina el

porcentaje que usa el sistema operativo (1.2%) para tener el valor exacto del uso del

procesador que se está usando en cada consulta y transacción.

30

Figura 14: Uso del CPU en cada Nodo (NetData, 2017)

4.5.2. Memoria RAM:

Esta métrica consiste en conocer el uso de memoria RAM utilizada por el proceso de

análisis en cada nodo, este valor se obtiene en GB en tiempo real y seleccionamos el valor

mayor que se obtiene al realizar la consulta, al igual que en la métrica de CPU, se elimina

la cantidad de memoria RAM utilizada por el sistema operativo (1.32 GB) para la

obtención del valor real de memoria utilizada.

Figura 15: uso de Memoria RAM en cada Nodo (Elaboración de los autores)

4.5.3. DISCO I/O:

NetData utiliza el comando nativo de Linux iostat –x que mide a nivel general el uso de

disco de los procesos, así como los kilobytes entrantes y salientes tanto de escritura como

de lectura. Para la medición tomamos el valor de salida de datos para las consultas

analíticas, que es hacia donde está orientada la investigación, este valor está dado en

kilobytes por segundo.

31

Figura 16: Uso de Disco I/O en cada Nodo (Elaboración de los autores)

4.6. Análisis e interpretación de resultados

4.6.1. Escenario I:

4.6.1.1. CPU o Procesador:

El uso de CPU en bases de datos relacionales, en este caso PostgreSQL, utiliza un bajo

porcentaje del procesador en comparación con las bases de datos columnares, tanto en el

Nodo 1 como en el Nodo 2, ya que se observan valores máximos de 3.54% en el Nodo 1

(ver Fig. 17) y 14.12% en el Nodo 2 (ver Fig. 18). Además, se debe considerar el número

de núcleos del procesador de cada nodo, de esta forma PostgreSQL utiliza un mayor

porcentaje de procesador en el nodo 2 que cuenta con 3 núcleos que en el nodo 1 que

cuenta con 7 núcleos, es decir, mientras más núcleos, menos porcentaje de CPU a nivel

general se utiliza.

32

Tabla 7: Uso de Procesador (Nodo 1 - Escenario I)


% de Uso de Procesador en Nodo 1

Vol. de Datos PostgreSQL Vertica MonetDB

100 mil 2,06 9,82 22,78

500 mil 2,46 15,72 45,08

1 millón 3,26 54,90 81,70

5 millones 3,54 97,16 98,20

Figura 17: Uso de Procesador (Nodo 1 - Escenario I) (Elaboración de los autores)

Tabla 8: Uso de Procesador (Nodo 2- Escenario I)




100 mil 4,08 23,66 39,26

500 mil 12,80 31,58 84,52

1 millón 13,64 83,60 98,78

5 millones 14,12 98,66 98,24

2,06 2,46 3,26 3,549,82 15,72

54,90

97,16

22,78

45,08

81,70

98,20

0

10

20

30

40

50

60

70

80

90

100

100 mil 500 mill 1 millon 5 millones

% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS

Uso de Procesador en Nodo 1

Postgres Vertica MonetDB

33

Figura 18: Uso de Procesador (Nodo 2 - Escenario I) (Elaboración de los autores)

En el caso de las bases de datos columnares, se tiene que este tipo de bases de datos

utilizan una mayor cantidad de CPU a la hora de realizar una consulta, en los porcentajes

obtenidos se observa que las cantidades máximas de CPU utilizadas en MonetDB es de

98.20% para el caso del Nodo 1 (ver Fig. 17) y de 98.78% para el caso del Nodo 2 (ver

Fig. 18) con 5 millones y 1 millón de registros respectivamente.

Por otro lado, Vertica utiliza el 97.16% de procesador del Nodo 1 y 98.66% en el Nodo

2 con el máximo volumen de datos. Una vez más se observa que ambos tipos de bases de

datos utilizan una mayor cantidad de procesador en el nodo con menor cantidad de

núcleos, es decir, tiene mayor carga en su CPU frente a equipos con mayor capacidad de

procesamiento.

Al parecer, el uso de CPU sería un aspecto en contra de las bases de datos columnares,

pero al relacionar el porcentaje de uso de procesador con el tiempo de respuesta se obtiene

que:

4,08

12,8 13,64 14,12

23,66 31,58

83,60

98,66

39,26

84,52

98,78 98,24

0

20

40

60

80

100


% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS


Postgres Vertica MonetDB

34

Tabla 9: Tiempo de Respuesta (Nodo 1 -

Escenario I) (Elaboración de los autores)

Tiempo de Respuesta Nodo 1 (min:seg:ms)

Vol.

de Datos PostgreSQL Vertica MonetDB

100 mil 0:02:34 0:01:10 0:02:28

500 mil 0:20:55 0:05:21 0:15:56

1 millón 1:40:52 0:32:29 1:18:09

5 millones 3:20:11 1:09:57 1:42:26




Vol.


100 mil 0:02:55 0:01:42 0:03:24

500 mil 0:21:08 0:05:50 0:21:13

1 millón 1:43:23 0:46:50 1:45:13

5 millones 3:25:34 1:14:29 2:01:19

Figura 19: Tiempo de Respuesta (Nodo 1 -




Las bases de datos columnares al usar un mayor porcentaje de procesador, los tiempos de

respuesta son mucho menores frente al de las bases de datos relacionales, lo que convierte

el alto uso de CPU en una ventaja para las bases de datos columnares.

A pesar de que este estudio se enfoca al uso de recursos y a métricas de rendimiento, se

decidió colocar el tiempo de respuesta obtenido en las mediciones con el fin de justificar

el alto uso CPU y memoria por las bases de datos columnares.

4.6.1.2. Memoria RAM:

En el caso de la memoria RAM, PostgreSQL (representando a las bases de datos

relacionales) ocupa hasta 1.60 GB del total de 8 GB del Nodo 1 (ver Fig. 21) y alcanza

un valor máximo de 0.89 GB en el Nodo 2 (ver Fig. 22) que también cuenta con 8 GB, lo

35

que indica que tiene un mayor impacto en equipos con mayor capacidad de procesamiento

(CPU).

Tabla 11: Uso de Memoria RAM (Nodo 1 - Escenario I)


Uso de Memoria RAM en Nodo 1 (GB)


100 mil 1,32 2,21 1,67

500 mil 1,35 2,64 2,34

1 millón 1,46 3,26 3,18

5 millones 1,60 5,98 5,18

Figura 21: Uso de Memoria RAM (Nodo 1 - Escenario I)


1,32 1,35 1,46 1,60

2,212,64

3,26

5,98

1,672,34

3,18

5,18

0

1

2

3

4

5

6

7

8


GB

VOLUMEN DE DATOS

Uso de Memoria RAM en Nodo 1

PostgreSQL Vertica MonetDB

36

Tabla 12: Uso de Memoria RAM (Nodo 2 - Escenario I)




100 mil 0,59 2,07 1,91

500 mil 0,63 2,52 2,56

1 millón 0,75 3,03 3,16

5 millones 0,89 5,04 5,19

Figura 22: Uso de Memoria RAM (Nodo 2 - Escenario I) (Elaboración de los autores)

En comparación con las bases de datos relacionales, las bases de datos columnares

representadas por MonetDB y Vertica ocupan una cantidad mayor de memoria RAM, con

valores como 5.18 GB en ambos nodos para MonetDB y con Vertica alcanzando los

niveles de 5.98 GB y 5.04 GB del Nodo 1 y 2 respectivamente, lo que demuestra que a

pesar de que la potencia de las bases de datos columnares radica en el almacenamiento de

datos en la memoria RAM, al igual que en el caso del uso del CPU, el alto consumo de

memoria volátil se justifica con los cortos tiempos de respuesta, esto para el caso de los

altos volúmenes de datos (5 millones), puesto que para cantidades de datos más pequeños

el uso de memoria RAM no resulta desmedido, es decir, exceptuando el caso del volumen

0,59 0,63 0,750,89

2,07

2,523,03

5,04

1,91

2,563,16

5,19

0

1

2

3

4

5

6

7

8


GB

VOLUMEN DE DATOS



37

de datos máximo, ninguna base de datos columnar supera el 50% del total de 8 GB de

memoria en ninguno de los nodos para el escenario I que consiste en la consulta masiva

de registros.

Siendo que las consultas realizadas están siendo procesadas en un ambiente distribuido,

observamos que Vertica ocupa mayor memoria RAM dentro de ambos nodos (ver Fig.

21), pero teniendo variaciones mayores en el Nodo 1 que en el Nodo 2, donde en este

último nodo, las variaciones de valores entre Vertica y MonetDB son muy bajas y que,

en comparación con PostgreSQL, se aprovecha al máximo la capacidad del CPU y

memoria RAM para la entrega de resultados de la consulta de este escenario.

Cabe recalcar que, en todos los casos, para cada valor obtenido y para todos los

escenarios, se realizó una limpieza de memoria caché antes de realizar las consultas

mediante los respectivos comandos para cada DBMS, esto para que no exista

acumulación de registros en dicha memoria y que se tomen de forma errónea los datos.

4.6.1.3. Disco (I/O):

Para este escenario, se evaluó la cantidad de kilobytes por segundo que tenían ocurrencia

en el disco, siendo así, mediante las Fig. 23 y 24 se distingue la gran cantidad de uso de

disco por parte de PostgreSQL, tanto en el Nodo 1 como en el Nodo 2, siendo menor en

este último pero que en comparación con las bases de datos columnares, éstas resultan

insignificantes, especialmente si tomamos en cuenta los casos extremos, donde para 100

mil registros PostgreSQL toma valores como 40.84 kB/s y 27.28 kB/s mientras que con

MonetDB y Vertica existen valores hasta de 6.10 kB/s; por otro lado para el caso de 5

millones de registros, los valores en las bases de datos relacionales se disparan hasta

alcanzar valores de 189.28 kB/s en el Nodo 1 y de 81.58 kB/s en el Nodo 2, mientras que

las bases de datos columnares siguen manteniendo un bajo nivel de tráfico de kilobytes

en el disco, demostrando que las bases de datos relacionales realizan el almacenamiento

directamente en el disco duro y con grandes cantidades de I/O por segundo, que a

diferencia de las bases de datos columnares, al realizar su almacenamiento en la memoria

volátil, ocupan valores muy bajos con respecto a la entrada y salida de datos en el disco.

38

Tabla 13: Uso de Disco (Nodo 1 - Escenario I)


Uso de Disco I/O en Nodo 1 (kilobytes/s)


100 mil 40,84 1,06 6,10

500 mil 69,94 2,22 6,64

1 millón 111,86 1,62 4,90

5 millones 189,28 9,20 7,94

Figura 23: Uso de Disco (Nodo 1 - Escenario I) (Elaboración de los autores)

40,84

69,94

111,86

189,28

1,06 2,22 1,62

9,206,10 6,64 4,90

7,940

20

40

60

80

100

120

140

160

180


KIL

OB

YTE

S/S

VOLUMEN DE DATOS

Uso de Disco Duro I/O en Nodo 1


39

Tabla 14: Uso de Disco (Nodo 2 - Escenario I) (Elaboración de los autores)



100 mil 27,28 0,11 2,98

500 mil 57,42 4,20 3,44

1 millón 65,12 8,20 5,28

5 millones 81,58 12,80 11,43

Figura 24: Uso de Disco (Nodo 2 - Escenario I) (Elaboración de los autores)

Se debe tomar en cuenta que en el presente escenario se realiza una consulta con el

objetivo de obtener la mayor cantidad de registros de una tabla, con lo cual analizando

los valores obtenidos, las bases de datos columnares ponen énfasis a aprovechar de una

manera óptima los recursos que tiene cada nodo para la obtención de resultados, lo que

no pasa con las bases de datos relacionales, puesto que al querer utilizar menos recursos

se genera un mayor tráfico en la entrada y salida de datos al momento del

almacenamiento.

27,28

57,42

65,12

81,58

0,11

4,20

8,20 12,802,98

3,44 5,2811,43

0

10

20

30

40

50

60

70

80

90


KIL

OB

YTE

S/S

VOLUMEN DE DATOS

Uso de Disco Duro I / O en Nodo 2


40

Dentro del ambiente distribuido manejado para esta investigación, se tiene que las bases

de datos están almacenadas físicamente en el Nodo 1, por lo cual el tiempo de respuesta

en este nodo es menor que en el Nodo 2 y que en el caso del valor de kilobytes por segundo

esa proporción se mantiene, debido a que no importa en qué espacio físico se almacenen

los registros de la tabla, las bases de datos columnares buscan administrar de manera

eficiente los recursos para las consultas analíticas hacia las cuales están enfocadas.

4.6.2. Escenario II:


A diferencia del escenario I, en la consulta utilizada para este escenario se manejaron

sentencias de cálculo de agregación como son SUM para la suma de un campo de la tabla

y AVG para el promedio de otro campo de la tabla.

Tabla 15: Uso de Procesador (Nodo 1 - Escenario II)




1 millón 4,20 9,92 10,64

5 millones 4,42 10,79 10,51

10 millones 7,36 11,00 11,72

15 millones 9,80 11,36 12,08

41

Figura 25: Uso de Procesador (Nodo 1 - Escenario II) (Elaboración de los autores)

Tabla 16: Uso de Procesador (Nodo 2 - Escenario II)




1 millón 4,76 23,72 25,24

5 millones 5,64 24,88 25,40

10 millones 7,54 24,76 26,60

15 millones 8,39 24,72 26,74

4,204,42

7,36

9,809,92

10,79

11,0011,36

10,64

10,51

11,72 12,08

-1,00

1,00

3,00

5,00

7,00

9,00

11,00

13,00

1 millon 5 millones 10 millones 15 millones

% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS



42

Figura 26: Uso de Procesador (Nodo 2 - Escenario II) (Elaboración de los autores)

Los valores obtenidos resultan peculiares debido a su variación, especialmente con los

valores descritos (ver Fig. 25) donde para el caso del Nodo 1 que es donde se encuentra

físicamente la base de datos, se observa que si bien MonetDB ocupa valores entre 10.64%

y 12.08% del CPU, Vertica entre 9.92% y 11.36% y PostgreSQL tiene valores entre

4.20% y 9.80% para los diferentes volúmenes de datos, se puede observar que para

consultas con sentencias de este tipo, con un millón de datos la diferencia de cantidad del

uso de procesador es más del doble entre bases de datos, pero que al llegar al máximo

volumen de datos (15 millones) esta diferencia disminuye considerablemente (2.28%

MonetDB/PostgreSQL – 1.56% Vertica/PostgreSQL) con lo que se puede afirmar que

ambas bases de datos utilizan un similar porcentaje de CPU cuando las consultas se

realizan en nodos donde las bases de datos están almacenadas de manera físicamente

local, esto en comparación con el Nodo 2, donde como se visualiza (ver Fig. 26) si bien

los valores de las dos bases de datos de tipo columnar mantienen valores similares entre

sí, no ocurre lo mismo que en la figura anterior, puesto que estos valores observados si

varían entre los dos tipos de bases de datos.

Otra observación está en que el porcentaje de CPU utilizado en el Nodo 1 para los dos

tipos de bases de datos no supera el 12.08% mientras que en el Nodo 2, MonetDB alcanza

4,76 5,647,54 8,39

23,72 24,88 24,76 24,72

25,24 25,4026,60 26,74

0,00

5,00

10,00

15,00

20,00

25,00

30,00


% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS



43

el valor máximo de 26.74% para 15 millones de registros, por lo que se puede proponer

que este tipo de consultas analíticas no resultan una carga para el procesador, pero esta

proposición deberá ser contrastada con las métricas siguientes para llegar a una adecuada

conclusión.


En el caso de la memoria RAM para consultas con sentencias con cálculo de agregación,

se distingue que la base de datos relacional PostgreSQL mantiene un porcentaje de uso

de memoria RAM constante (ver Fig. 27 y 28) debido a que el almacenamiento y

extracción de resultados de la consulta lo realiza directamente en el disco duro; en cambio

se observa que Vertica y MonetDB utilizan al máximo la memoria volátil para realizar el

procesamiento de la consulta, en el caso de un millón de registros Vertica es el motor de

base de datos que menos cantidad de memoria RAM utiliza en ambos nodos, aún menos

que PostgreSQL; también se observa que los dos tipos de bases de datos columnares

utilizan una cantidad mayor de memoria volátil cuando la consulta es realizada de manera

local (ver Fig. 27).

Tabla 17: Uso de Memoria RAM (Nodo 1 - Escenario II)




1 millón 2,16 1,54 2,39

5 millones 2,21 3,24 3,59

10 millones 2,22 4,51 4,66

15 millones 2,23 5,94 6,79

44

Figura 27: Uso de Memoria RAM (Nodo 1 - Escenario II) (Elaboración de los autores)

Tabla 18: Uso de Memoria RAM (Nodo 2 - Escenario II) (Elaboración de los autores)



1 millón 1,66 0,88 1,52

5 millones 1,66 2,59 2,74

10 millones 1,67 3,41 3,76

15 millones 1,67 5,02 5,86

2,162,21 2,22 2,23

1,54

3,24

4,51

5,94

2,39

3,59

4,66

6,79

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00


GB

VOLUMEN DE DATOS



45

Figura 28: Uso de Memoria RAM (Nodo2 - Escenario II) (Elaboración de los autores)

Otra observación importante es que en el caso de los 15 millones de registros MonetDB

en un punto alcanza 6.79 GB (Ver Fig. 27) al cual, si se le añade el 1.2GB que utiliza el

sistema operativo, estaría usando 7.99 GB de 8 GB de uno de los nodos, pero esta gran

cantidad de memoria RAM una vez más se justifica con el tiempo de respuesta:


Escenario II) (Elaboración de los autores)


Vol.


1 millón 2:04:22 0:22:51 0:27:24

5 millones 2:14:03 0:30:51 0:38:24

10 millones 2:36:03 0:33:33 0:41:06

15 millones 3:38:32 0:44:15 0:55:48




Vol.


1 millón 2:16:06 0:27:33 0:30:42

5 millones 3:24:45 0:33:27 0:36:36

10 millones 3:27:58 0:35:29 0:38:38

15 millones 4:06:06 0:40:06 0:43:15

1,661,66 1,67 1,67

0,88

2,593,41

5,02

1,52

2,74

3,76

5,86

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00


GB

VOLUMEN DE DATOS



46





La relación entre el tiempo de respuesta y el uso de memoria RAM se hace evidente para

ambos nodos (ver Fig. 29 y 30), donde a pesar de la gran cantidad de memoria volátil

utilizada por las bases de datos columnares, resultan ser mejores en cuanto a tiempo de

respuesta para el tipo de consultas planteadas en este escenario, por ejemplo, se ven

resultados drásticos desde el primer volumen de datos que es 1 millón (ver Fig. 29), con

un tiempo de respuesta para PostgreSQL de un poco más de 2 minutos frente a MonetDB

con casi 30 segundos y a Vertica con 22 segundos en el tiempo promedio, sin embargo

los valores más representativos se alcanzaron con una alto volumen de datos como es el

de 15 millones, donde la base de datos relacional PostgreSQL demora 03:38 minutos en

devolver el mismo resultado que las bases de datos columnares Vertica con un tiempo de

44 segundos y MonetDB con 55 segundos.

Así mismo se diferencia el período de tiempo existente al devolver el resultado de la

consulta en el Nodo 2 y con excelentes resultados tales como 4 minutos con PostgreSQL

frente a 40 y 43 segundos para Vertica y MonetDB respectivamente (ver Fig. 30), con

estos valores queda justificado el alto uso de memoria RAM por parte de las bases de

datos columnares, que es donde radica su característica principal.

4.6.2.3. Disco (I/O):

Debido a que para este escenario los volúmenes de datos son mayores que en el escenario

I, la proporción de los sucesos se mantiene a gran escala, además para esta métrica se

47

dividió a las gráficas de los resultados puesto que Vertica y MonetDB tenían valores

similares, lo cual no permitía una correcta visualización de las mediciones obtenidas.

Basándonos en los valores para el Nodo 1 (ver Fig. 31 y 32), se denota el incremento en

el uso de I/O del disco por parte de la base de datos relacional. Al realizar la consulta del

escenario II que contiene sentencias con cálculo de agregación se observa que el mínimo

valor que ocupa esta base de datos relacional es de 404.26 kB/s y que el máximo valor es

de 67876.34 kB/s ambos en el Nodo 1, lo que se puede relacionar con el aspecto

mencionado anteriormente (almacenamiento local), ya que al realizar la comparativa (ver

Fig. 33 y 34) se tienen valores en el Nodo 2 que si bien son altos, son menores a los

obtenidos en el Nodo 1.

Tabla 21: Uso de Disco I/O (Nodo 1 - Escenario II) (Elaboración de los autores)

Uso de Disco I/O en Nodo 1 (kilobyte/s)

Vol. de Datos PostgreSQL MonetDB Vertica

1 millón 404,26 12,62 8,47

5 millones 2427,01 13,8 9,65

10 millones 10047,7 14,72 10,57

15 millones 67876,34 25,4 21,25

Figura 31: Uso de Disco I/O PostgreSQL &

MonetDB (Nodo 1 - Escenario II)



Vertica (Nodo 1 - Escenario II) (Elaboración

de los autores)

48

Tabla 22: Uso de Disco I/O (Nodo 2 - Escenario II)


Uso de Disco I/O en Nodo 2 (kilobyte/s)


1 millón 425,23 10,92 8,85

5 millones 2777,93 10,66 9,31

10 millones 15550,00 12,74 9,81

15 millones 54634,86 25,41 21,24


MonetDB (Nodo 2 - Escenario II) (Elaboración

de los autores)

Figura 34: Uso de Disco I/O PostgreSQL

& Vertica (Nodo 2 - Escenario II)


Con respecto a las bases de datos columnares, Vertica sigue liderando en cuanto a

consumo eficiente de recursos, ya que es el motor de base de datos que menor valores de

I/O tiene tanto en el Nodo 1 como en el Nodo 2, además de que en ambos nodos, ninguna

de los dos motores de bases de datos superan los 25.41 kB/s siendo este valor tomado por

MonetDB y que una vez más resulta insignificante con respecto a la cantidad utilizada

por PostgreSQL, demostrando nuevamente que las bases de datos de tipo columnar tienen

una mejor administración de recursos en este caso para consultas con sentencias con

cálculos de agregación.

49

4.6.3. Escenario III:


Dentro del escenario III se planteó la realización de la consulta con el afán de tener como

resultado al 50% de las columnas de la tabla, también de que este resultado esté dentro de

un rango basado en un valor dado de una de las columnas y además que los registros

obtenidos sean ordenados alfabéticamente en base al valor de dicho campo.

Tabla 23: Uso de Procesador (Nodo 1 - Escenario III)




1 millón 14,64 14,38 22,00

5 millones 15,28 14,82 31,52

10 millones 18,80 44,56 54,98

15 millones 22,28 76,10 86,52

Figura 35: Uso de Procesador (Nodo 1 - Escenario III) (Elaboración de los autores)

14,6415,28

18,8022,28

14,38 14,82

44,56

76,10

22,00

31,52

54,98

86,52

0

10

20

30

40

50

60

70

80

90

100


% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS

Uso de procesador en Nodo 1


50

Tabla 24: Uso del Procesador (Nodo 2 - Escenario III)




1 millón 13,38 25,82 26,28

5 millones 13,88 27,24 43,14

10 millones 15,88 41,72 57,86

15 millones 16,16 87,50 88,92

Figura 36: Uso de Procesador (Nodo 2 - Escenario III) (Elaboración de los autores)

Con la explicación anterior, se observa que en el Nodo 1, PostgreSQL y Vertica tienen

valores similares para los volúmenes de datos de 1 y 5 millones, considerando que las

bases de datos relacionales ocupan un porcentaje bajo de procesador en este tipo de

consultas, también lo hacen las bases de datos columnares en este caso representadas por

Vertica. Para el caso del Nodo 2 dentro de este mismo contexto, se puede distinguir que

para estos 2 volúmenes de datos se tiene un comportamiento distinto al del Nodo 1, siendo

mayor el porcentaje utilizado por las bases de datos columnares ante estos volúmenes de

datos, por lo que se llega a definir que al contrario de los escenarios anteriores, las

13,38 13,88 15,88 16,16

25,82 27,24

41,72

87,50

26,28

43,14

57,86

88,92

0

20

40

60

80

100

% D

E P

RO

CES

AD

OR

VOLUMEN DE DATOS

Uso de procesador en Nodo 2


51

consultas con comandos comparativos y de orden varían con respecto al uso de

procesador, rompiendo así la tendencia que se venía siguiendo de usar más recursos de

este tipo en nodos donde el almacenamiento se realiza de manera local.

También se observa que la base de datos relacional ocupa un bajo porcentaje de

procesador en ambos nodos y en todos los volúmenes de datos, con lo que este tipo de

base de datos resultan una buena opción para equipos con poca capacidad de

procesamiento y donde las consultas analíticas no son requeridas de una manera rápida,

siendo así, se puede afirmar que las bases de datos columnares están orientadas a

consultas con un alto nivel de análisis y para equipos con una gran capacidad de

procesamiento ofreciendo a cambio una gran velocidad de respuesta.


Para el caso de la memoria RAM la base de datos relacional PostgreSQL una vez más

ocupa una capacidad baja y constante; a diferencia de ésta se distingue que las bases de

datos columnares tienen un crecimiento en el uso de memoria RAM conforme el volumen

de datos va creciendo para la consulta, sin embargo, no llegan a ocupar la cantidad

máxima de memoria volátil para ninguno de los casos como lo hizo en el escenario II. De

esta forma se puede afirmar que las consultas con sentencias con cálculo de agregación

son las que ocupan más memoria RAM al momento de ejecutarse tanto en

almacenamiento local como remoto.

Tabla 25: Uso de Memoria RAM (Nodo 1 - Escenario III) (Elaboración de los autores)



1 millón 2,92 2,16 2,56

5 millones 2,91 3,30 4,70

10 millones 2,88 4,70 5,49

15 millones 2,88 5,55 5,95

52

Figura 37: Uso de Memoria RAM (Nodo 1 - Escenario III)


Tabla 26: Uso de Memoria RAM (Nodo 2 - Escenario III)




1 millón 2,15 1,62 2,04

5 millones 2,11 2,73 2,32

10 millones 2,10 3,24 3,82

15 millones 2,07 4,97 5,39

2,92

2,91 2,88 2,882,16

3,30

4,70

5,55

2,56

4,70

5,495,95

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00


GB

VOLUMEN DE DATOS



53

Figura 38: Uso de Memoria RAM (Nodo 2 - Escenario III)


También se observa que, en relación con los escenarios anteriores, en este tercer escenario

la base de datos Vertica no se desempeña de una mejor manera que MonetDB, ya que

anteriormente este motor de base de datos consume menos recursos en ambos nodos y

con todos los volúmenes de datos, especialmente en el Nodo 2 donde existe una variación

ascendente en el caso de los 5 millones en comparación a MonetDB.

Tabla 27: Tiempo de Respuesta (Nodo

1 - Escenario III)



Vol.


1 millón 0:13:20 0:10:16 0:05:33

5 millones 1:05:59 0:31:17 0:33:02

10 millones 2:16:37 1:00:46 1:10:26

15 millones 3:28:49 2:24:38 2:36:27

Tabla 28: Tiempo de Respuesta (Nodo2 -

Escenario III)



Vol.


1 millón 0:13:15 0:08:17 0:07:25

5 millones 1:12:04 0:13:59 0:47:01

10 millones 2:34:10 0:44:33 1:35:16

15 millones 3:45:43 1:32:17 1:59:04

2,15

2,11 2,102,07

1,62

2,73

3,24

4,97

2,04 2,32

3,82

5,39

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00


GB

VOLUMEN DE DATOS



54


Escenario III) (Elaboración de los autores)


Escenario III) (Elaboración de los autores)

Otra característica a destacar es que en este escenario, a diferencia de los demás se utiliza

una gran cantidad tanto de procesador como de memoria RAM, lo que no ocurrió

anteriormente donde para otros tipos de consultas se usaba más o uno u otro recurso, en

este caso se utilizan los dos pero se sigue la tendencia definida también en estos escenarios

donde la justificación al alto uso de estos recursos está en el tiempo de respuesta, donde

una vez más se observa que las bases de datos columnares conservan un bajo tiempo de

retorno de resultados con respecto a las bases de datos relacionales.

4.6.3.3. Disco (I/O):

Se sigue la tendencia ascendente del escenario III para el caso de uso de disco I/O en las

bases de datos relacionales. Se observa en la Figura 41 y 42 que la máxima cantidad de

kB/s que usa PostgreSQL es de 26843 kB en el Nodo 1 para el volumen de datos de 15

millones.

Tabla 29: Uso de Disco I/O (Nodo 1 - Escenario III) (Elaboración de los autores)



1 millón 1925,20 248,20 195,80

5 millones 2614,00 240,60 185,40

10 millones 9716,8,00 226,60 158,86

15 millones 26843,00 218,60 151,40

55


MonetDB (Nodo 1 - Escenario III)



Vertica (Nodo 1 - Escenario III) (Elaboración

de los autores)

Tabla 30: Uso de Disco I/O (Nodo 2 - Escenario III)




1 millón 1497,60 201,72 184,36

5 millones 1870,60 198,96 181,6

10 millones 8518,60 198,44 181,08

15 millones 26077,40 176,02 164,04

Figura 43: Uso de Disco Duro I/O

PostgreSQL & MonetDB (Nodo 2 - Escenario

III) (Elaboración de los autores)

Figura 44: Uso de Disco Duro I/O

PostgreSQL & Vertica (Nodo 2 - Escenario

III) (Elaboración de los autores)

Por otro lado, las bases de datos columnares mantienen un uso de disco balanceado y con

valores bajos en comparación con la base de datos relacional, siendo los valores más bajos

56

obtenidos en el Nodo 2 para MonetDB y en el Nodo 1 para Vertica, en relación con este

aspecto, Vertica logra un mejor desempeño en cuanto al recurso I/O del disco.

A pesar de ser una consulta compleja, este escenario ocupa menos tráfico de kB/s que el

escenario II donde como resultado se obtienen solo 2 valores producto de la consulta

realizada, esto se debe a que para la obtención de los resultados del escenario II se realiza

una lectura de todos los registros, para el caso del escenario III mediante el comando

WHERE y la ordenación, obtenemos una cantidad mayor al 30% de los registros del total

de la tabla.

4.6.4. Cuadro Comparativo de Escenarios

De manera general, se realiza un cuadro comparativo entre los diferentes escenarios

expuestos con la finalidad de brindar un mejor panorama acerca de las características

analizadas en cada uno de ellos:

Tabla 31: Cuadro Comparativo entre Recursos y Escenarios


Cuadro Comparativo entre Recursos y Escenarios

CPU o Procesador Memoria RAM Disco I/O

Escenario I: SELECT * FROM

TABLA;

PostgreSQL utiliza

una mayor cantidad

de CPU.

En BDD

columnares, a mayor

capacidad de

procesamiento,

mayor carga en el

CPU

Menor tiempo de

respuesta en BDD

columnares.

PostgreSQL tiene un

mayor consumo en

equipos con mayor

capacidad de

procesamiento.

Las BDD

Columnares, el alto

consumo de

memoria volátil se

justifica con los

cortos tiempos de

respuesta.

Vertica ocupa mayor

cantidad de memoria

RAM.

Las BDD columnares

mantienen un bajo

nivel de tráfico de

kilobytes en el disco.

Las BDD columnares

aprovechan los

recursos de cada nodo

para la obtención de

resultados.

RECURSO

ESCENARIO

57

Escenario II: SELECT

SUM(año),

AVG(calificación)

FROM TABLA;

Las BDD

columnares utilizan

un porcentaje mayor

al de las BDD

relacionales.

Las BDD

relacionales utilizan

un porcentaje poco

significativo de

CPU.

Las BDD

relacionales utilizan

una baja y constante

cantidad de memoria

RAM.

Las BDD

columnares llegan a

consumir a la

memoria RAM en su

totalidad, pero una

vez más se justifica

con su bajo tiempo

de respuesta.

Vertica y MonetDB

tienen valores bajos y

similares entre sí.

Existe un alto tráfico

de datos en las BDD

relacionales, debido a

que el procesamiento

de la consulta se la

realiza directamente

en el disco.

Escenario III: SELECT nombre,

año, calificación,

ciudad FROM

TABLA WHERE

año>0 AND

año<2003 ORDER

BY (nombre);

Ambos tipos de

BDD tienen valores

similares para bajos

volúmenes de datos

en nodos con

almacenamiento

local.

Las BDD

relacionales ocupan

un bajo porcentaje

de procesador pero

tienen un mayor

tiempo de respuesta.

Las BDD

columnares están

orientadas a

consultas de alto

nivel y para equipos

con gran capacidad

de procesamiento.

Este tipo de

consultas ocupan

más memoria RAM

en ambos tipos de

BDD.

Solo en este caso,

Vertica utiliza

mayor cantidad de

memoria RAM que

MonetDB.

Las BDD

relacionales siguen

ocupando una baja

cantidad de memoria

RAM pero sigue la

tendencia de un

mayor tiempo de

respuesta.

Las BDD columnares

mantienen un uso de

disco balanceado y

con valores bajos en

comparación con las

BDD relacionales.

En este escenario, las

sentencias devuelven

una cantidad mayor al

30% del total de

registros de la tabla.

58

5. DISCUSIÓN

En la presente tesis se realizó un análisis comparativo entre bases de datos relacionales

versus bases de datos columnares donde se encontró que un mayor desempeño y mejor

gestión de recursos está dado por parte de las bases de datos columnares. Este tipo de

bases de datos puede desempeñar un rol importante para las organizaciones que manejan

grandes cantidades de información, no solo por el consumo de recursos a nivel de

hardware y software sino también por el tiempo de respuesta, que es un aspecto crítico

para los procesos empresariales. Cabe recalcar que no existen estudios previos donde se

realice una comparación igual a la elaborada en la presente investigación.

De acuerdo con los resultados obtenidos se puede decir que existe un mejor desempeño

por parte de las bases de datos columnares en equipos de mayor capacidad ya que se

aprovechan de mejor manera los recursos a nivel de procesamiento y memoria RAM, este

desempeño se hace visible en pruebas con altos volúmenes de datos como los manejados

en esta investigación.

Las limitaciones que tuvo esta investigación fueron que a pesar de haber instalado de

forma correcta los motores de bases de datos y sus herramientas para su administración,

el hardware con el que contaban los nodos de nuestro entorno distribuido no abastecieron

para el caso obtención masiva de datos como ocurrió en el escenario I.

Para futuras investigaciones se recomienda realizar un análisis con diferentes tipos de

variables o en mayor cantidad a las usadas en esta investigación, así como también con

equipos de mejor capacidad tanto a nivel de hardware como de software.

59

6. CONCLUSIONES Y RECOMENDACIONES

6.1. Conclusiones

Previamente a las conclusiones, se debe aclarar que esta investigación no se enfoca al

desarrollo de ningún software, sino al análisis de rendimiento en cuanto al uso de recursos

tanto de las bases de datos relacionales como columnares.

Si bien las bases de datos relacionales ocupan menos recursos para la obtención de

resultados, esto no implica que sean más eficientes, ya que las bases de datos columnares

aprovechan al máximo los recursos disponibles para ofrecer un mejor desempeño.

Se determinó que el mayor uso de porcentaje de CPU y memoria RAM por parte de las

bases de datos columnares se justifican con el tiempo de respuesta, siendo esta su

principal ventaja, ya que este tiempo disminuye considerablemente frente al de las bases

de datos relacionales si tomamos en cuenta el volumen de datos que manejan, siendo este

tipo de base de datos la que mejor gestiona los recursos de los nodos.

En cuanto a los datos obtenidos en el I/O del disco, es más probable tener un cuello de

botella con bases de datos relacionales al momento de realizar las consultas, ya que la

cantidad de kilobytes por segundo que este tipo de bases de datos utiliza es mucho mayor

con respecto a las bases de datos columnares, lo que influye también en los altos tiempos

de respuesta que ofrece en este caso PostgreSQL, que es la base de datos relacional

utilizada para esta investigación.

De las dos bases de datos columnares utilizadas, Vertica fue la que obtuvo un mejor

desempeño, puesto que fue la que menos porcentaje de CPU, memoria RAM y cantidad

de I/O de disco utilizó frente a MonetDB.

60

Por otro lado, la mayor desventaja por parte de las bases de datos columnares es que se

necesita una gran cantidad de recursos, específicamente CPU y memoria RAM para

consultas cuya respuesta tenga un alto volumen de registros, como se pudo observar en

el escenario I.

Las bases de datos relacionales ocupan un bajo porcentaje de procesador como se ha

demostrado en los escenarios expuestos, así como los volúmenes de datos estudiados, por

lo que este tipo de base de datos resultan una buena opción para equipos con poca

capacidad de procesamiento y donde las consultas analíticas no son exigentes en tiempo

de respuesta.

Por otro lado, las bases de datos columnares se orientan a consultas con un alto nivel de

análisis y para equipos con gran capacidad de procesamiento y recursos ofreciendo a

cambio una alta velocidad de respuesta.

6.2. Recomendaciones:

Con respecto a la reducción del volumen de datos del escenario I, se la realizó ya que la

capacidad de procesamiento del CPU como la memoria RAM en bases de datos

columnares alcanzaron su límite al llegar a los 5 millones de registros y luego los nodos

del entorno distribuido dejaron de responder, con lo cual se recomienda que para este tipo

de consultas cuente con equipos de mayor capacidad respecto a hardware puesto que el

extenso volumen de datos en la respuesta de la consulta no permitió el correcto

funcionamiento de los nodos (CPU, memoria RAM).

Se utilizó un sistema operativo de código abierto ya que utiliza menos recursos y de esa

forma los motores de bases de datos aprovechan el entorno para la ejecución de los

procesos.

Se recomienda utilizar un entorno distribuido en caso de no contar con equipos de alta

gama para realizar un balanceo de carga y distribución del uso de recursos entre nodos al

ejecutar las consultas.

61

Para estudios futuros, se sugiere realizar un análisis orientado a sentencias de tipo OLTP

que cuente con análisis relacionados con la escritura masiva de datos, así como el estudio

de la compresión y rendimiento de dichos datos.

Se sugiere que el uso de herramientas de administración y de monitoreo sean también de

código abierto ya que, al ser configurables, se obtienen las características específicas que

se requieren evaluar.

62

BIBLIOGRAFÍA

Abadi, D., Madden, S., & Hachem, N. (2008). Column-Stores vs. Row-Stores: How

Different Are They Really? Proceedings of the ACM SIGMOD International

Conference on Management of Data., 10(1145), 967-980.

Babeanu, R., & Ciobanu, M. (2015). In-memory databases and innovations in Business

Intelligence. Database Systems Journal, VI(1), 59-67.

Baboo, S., & Kumar, R. (Mayo de 2013). Next Generation Data Warehouse and In-

Memory Analytics. International Journal of Computer Applications, 69(18), 25-

30.

Bajaj, P., & Dhindsa, S. (June de 2012). A Comparative Study of Database Systems.

International Journal of Engineering and Innovative Technology, 1(6), 267-269.

Blelloch, G. (31 de Enero de 2013). Introduction to Data Compression. Pittsburgh, USA:

Computer Science Department of Carnegie Mellon University.

Córdova Espinoza, R. F., & Cuzco Sarango, B. E. (2013). Análisis Comparativo Entre

Base De Datos Relacionales con Bases de Datos No Relacionales. Tesis de

pregrado. Cuenca, Azuay, Ecuador: Universidad Politécnica Salesiana.

Cruz, A., Manjarrez, A., Martínez Castro, J. M., & Cuevas Valencia, R. E. (Octubre de

2014). Migración de Bases de Datos SQL a NoSQL. (U. A. Guerrero, Ed.) Revista

Tlamati Sabiduria(3).

Da Costa, A. (2 de Septiembre de 2016). www.groovypost.com. Recuperado el Abril de

2018, de https://www.groovypost.com/news/microsoft-increases-ram-limit-in-

windows-server-2016-to-24-tbs/

63

DBeaver. (2014). DBeaver - Free Universal Database Tool. Recuperado el 13 de Junio

de 2018, de https://dbeaver.io/about/

Garcete, A. (Septiembre de 2012). Base de Datos Orientado a Columnas. Tesis de Grado,

1-13. Asunción, Paraguay: Universidad Católica ”Nuestra Señora de la

Asunción”.

Harrison, G. (2015). Next Generation Databases. California: Apress.

Islam, K., & Arafat, Y. (Agosto de 2014). Redundant Reduced LZW (RRLZW)

Technique of Lossless Data Compression. International Journal of Advanced

Computer Research., 261-266.

Jara, J. (2012). Big Data & Web Intelligence. Paraguay: Universidad Católica "Nuestra

Señora de la Asunción".

Kabakus, A., & Kara, R. (2016). A performance evaluation of in-memory databases.

Journal of King Saud University –Computer and Information Sciences, 29(Issue

4), 520-525.

Kodituwakku, S., & Upali, A. (2010). Comparison of lossless data compression

algorithms for text data. Indian Journal of Computer Science and Engineering,

1(4), 416-425.

Lorente Borox, A. (Octubre de 2015). Almacenes de Datos NoSQL, Estudio de la

Tecnología. Tesis de Grado, 1, 1, 44. Madrid: Universidad Carlos III de Madrid.

Departamento de Informática.

Martínez Prieto, M. (2010). Estudio y Aplicación de Nuevos Métodos de Compresión de

Texto Orientada a Palabras. (D. d. Informática, Ed.) Valladolid, España:

Universidad de Valladolid.

64

Matei, G. (2010). Column-Oriented Databases, an Alternative for Analytical

Environment. Database Systems Journal, 1(2), 3-16.

MonetDB. (2017). The column-store pioneer. Recuperado el 13 de Junio de 2018, de

https://www.monetdb.org/Home

Morales Morales, M. R., & Morales Cardoso, S. L. (2017). Inteligencia de negocios

basada en Bases de Datos In-Memory. Revista Publicando, 4(11), 201-217.

NetData. (2017). My NetData.IO. Recuperado el 14 de Juno de 2018, de https://my-

netdata.io/

pgAdmin. (2018). pgAdmin - PostgreSQL Tools. Recuperado el 13 de Junio de 2018, de

https://www.pgadmin.org/

PostgreSQL. (2018). PostgreSQL - Home. Recuperado el 13 de Junio de 2018, de

https://www.postgresql.org/about/

Sakulsorn, P. (2011). In-memory Business Intelligence. Suecia: KTH Royal Institute Of

Technology, Department of Computer and Systems Sciences.

Salomon, D. (2014). Data Compression - The complete reference. En D. Salomon, G.

Motta, & D. Bryant, Data Compression - The complete reference (4 ed., págs. 79-

81). Northridge, California: Springer-Verlag London.

Seleznjev, O., & Shykula, M. (2012). Run-length compression of quantized Gaussian

stationary signals. Random Operators and Stochastic Equations, 20(10), 311-328.

Sharma, V., & Dave, M. (Agosto de 2012). SQL and NoSQL Databases. International

Journal of Advanced Research in Computer Science and Software Engineering,

2(8), 21-27.

Vara Horna, A. A. (2012). Desde la idea inicial hasta la sustentación: 7 Pasos para una

tesis exitosa (3 ed.). Lima: Universidad de San Martín de Porres.

65

Venkat, R. (3 de Diciembre de 2007). Column Oriented Databases Vs Row Oriented

Databases. ITK - 478. Special Interest Activity.

Vertica. (2018). Overview of Vertica. Recuperado el 13 de Junio de 2018, de

https://www.vertica.com/overview/.

Vivas, H., Cambarieri, M., Petroff, M., García, M. N., & Formia, S. (2015). Tratamiento

de Grandes Volúmenes de Datos en Ciudades Inteligentes Una Propuesta de Big

Data con NoSQL. Repositorio Institucional Digital de la Universidad Nacional

de Rio Negro, 1-10.

Wang, Z.-H., Yang, H.-R., Cheng, T.-F., & Chang, C.-C. (2013). A high-perfomance

reversible data-hiding scheme for LZW codes. The Journal of Systems and

Software, 86(11), 2771-2778.

Workbench/J, S. (2017). SQL Workbench/J. Recuperado el 13 de Junio de 2018, de

https://www.sql-workbench.eu/

Yang, L., Yang Guo, Z., Yong, S., & Guo, F. (2015). Materials and Engineering

Technology. Applied Mechanics and Materials, 719-720, 554-560.

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE …€¦ · Minango Román Carlos Edmundo Tenelema...

Documents

Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE …€¦ · Minango Román Carlos Edmundo Tenelema...