SciELO - Scientific Electronic Library Online

 
 número22Detección de fallas en motores de combustión mediante indicadores de temperatura y presión de inyecciónEvaluación de la gestión del mantenimiento en hospitales del instituto ecuatoriano de seguridad social de la zona 3 del Ecuador índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Ingenius. Revista de Ciencia y Tecnología

versión On-line ISSN 1390-860Xversión impresa ISSN 1390-650X

Ingenius  no.22 Cuenca jun./dic. 2019

 

Artículo Científico

Rendimiento de bases de datos columnares

Performance of columnar database

Jhonatan W. Durán-Cazar1 
http://orcid.org/0000-0002-8574-1435

Eduardo J. Tandazo-Gaona2 
http://orcid.org/0000-0002-2209-3952

Mario R. Morales-Morales3 
http://orcid.org/0000-0002-7493-8072

Santiago Morales Cardoso4 
http://orcid.org/0000-0002-3833-9654

1Facultad de Ciencias Físicas y Matemáticas, Universidad Central del Ecuador, Ecuador.

2Facultad de Ciencias Físicas y Matemáticas, Universidad Central del Ecuador, Ecuador.

3Facultad de Ciencias Físicas y Matemáticas, Universidad Central del Ecuador, Ecuador.

4Facultad de Ciencias Físicas y Matemáticas, Universidad Central del Ecuador, Ecuador


Resumen

En la actualidad para el éxito de las empresas es decisiva la capacidad de procesar de manera eficiente una considerable cantidad de datos de una amplia gama de fuentes en cualquier lugar y momento. El análisis de datos se convierte en una estrategia clave para la mayoría de las grandes organizaciones para lograr una ventaja competitiva. Por tanto, surgen nuevas cuestiones a ser tomadas en cuenta a la hora de almacenar y consultar cantidades masivas de datos que, en general, las bases de datos relacionales tradicionales no pueden abarcar. Estas cuestiones incluyen desde la capacidad de distribuir y escalar el procesamiento o el almacenamiento físico, hasta la posibilidad de utilizar esquemas o tipos de datos no usuales. El objetivo principal de la investigación es evaluar el rendimiento de las bases de datos columnares en analítica de datos. Efectuar una comparación con bases de datos de tipo relacional, para determinar su eficiencia, realizando mediciones en distintos escenarios de pruebas. El presente estudio pretende proporcionar (evidencia científica) un instrumento que facilite a los profesionales interesados en la analítica de datos una base para sus conocimientos, al incluir cuadros y tablas comparativos con datos cuantitativos con los que se pueda sustentar las conclusiones de esta investigación. Se usa una metodología aplicada y de diseño descriptivo cuantitativo-comparativo al ser el que mejor se ajusta al estudio de características de eficiencia de bases de datos. En la medición se usa el método de promedios para n número de tomas y se soporta en la herramienta Aqua Data Studio que garantiza una alta confiabilidad al ser un programa especializado para la administración de bases de datos. Finalmente, se ha logrado determinar que las bases columnares tienen un mejor rendimiento en ambientes de análisis de datos.

Palabras clave análisis de datos; base de datos columnar; en memoria; NoSQL; rendimiento

Abstract

Companies’ capacity to efficiently process a great amount of data from a great variety of sources anywhere and anytime is essential for them to succeed. Data analysis becomes a key strategy for most of large organizations for them to get a competitive advantage. Hence, when massive amounts of date are to be stored, new questionings arise for consideration, because traditional relational database are not capable to lodge them. Such questions include aspects that go from the capacity to distribute and escalate the physical storage to the possibility of using schemes or non-usual types of data. The main objective of the research is to evaluate the performance of the columnar databases in data analytics. Make a comparison with relational databases, to determine their efficiency, making measurements in different test scenarios. The present study aims to provide (scientific evidence) an instrument that provides professionals interested in data analytics with a base for their knowledge, to include comparative tables with quantitative data that can support the conclusions of this research. A methodology of applied type and quantitative-comparative descriptive design is used, as it is the one that best adjusts to the study of database efficiency characteristics. In the measurement the averages method is used for n number of shots and it is supported in the Aqua Data Studio tool that guarantees a high reliability as it is a specialized software for the administration of databases. Finally, it has been determined that the columnar bases have a better performance in data analysis environments.

Keywords data analytics; columnar database; in memory; NoSQL; performance

1. Introducción

De los muchos modelos de datos diferentes, el modelo relacional ha estado dominando desde los años 80, con implementaciones como bases de datos Oracle, MySQL y Servidores Microsoft SQL, también conocido como Sistema de Gestión de Base de Datos Relacional (RDBMS) [1].

Debido al gran crecimiento de Internet en los últimos años y la llegada del fenómeno de big data (macrodatos), surgen nuevas cuestiones a ser consideradas a la hora de almacenar y consultar cantidades masivas de datos que, en general, las bases de datos relacionales tradicionales no pueden abarcar. Estas cuestiones incluyen desde la capacidad de distribuir y escalar el procesamiento o el almacenamiento físico, hasta la posibilidad de utilizar esquemas o tipos de datos no usuales [2].

La capacidad de procesar una gran cantidad de datos de una amplia gama de fuentes en cualquier lugar y momento de manera eficiente es decisiva para el éxito de las empresas. Para lograr una ventaja competitiva el análisis de datos se convierte en una estrategia clave para la mayoría de organizaciones. Por lo tanto, durante los últimos diez años, el enfoque mundial del negocio de gestión ha cambiado profundamente [3].

En un escenario donde los datos tienden a ser más diferentes que similares entre sí, la estructura rígida de los sistemas relacionales dificulta enormemente su modelamiento. El rendimiento se encuentra limitado por su escalamiento vertical, lo que no permite distribuir la carga del sistema en múltiples máquinas sumado a la gran cantidad de peticiones de lectura y escritura de forma concurrente, la propia complejidad de la lógica detrás del funcionamiento de las bases de datos relacionales tiende a perder eficiencia en relación con el crecimiento de los datos.

Esto hace difícil responder con baja latencia en el caso de aplicaciones que atienden un gran número de pedidos a la misma vez. Por tanto, se hacen necesarios sistemas redundantes y fáciles de escalar que brinden un servicio de alta escalabilidad y disponibilidad para la gestión de elevados volúmenes de datos y así garantizar su disponibilidad [4].

Antes de abordar cómo va a realizarse la investigación es necesario revisar ciertos conceptos claves que han sido utilizados a lo largo del presente trabajo. Base de datos SQL.- El concepto de sistema de base de datos no es algo nuevo en la sociedad, sus predecesores fueron los sistemas de ficheros. Con el pasar del tiempo, las bases de datos se desarrollaron debido a la necesidad de almacenar gran cantidad de información.

En 1970 se definió el modelo relacional del cual nacieron las primeras bases de datos relacionales organizados como tablas (compuesta por filas y columnas) y su propio lenguaje de consulta [5]. Estos sistemas ofrecen cualidades indispensables en un entorno transaccional siguiendo el modelo ACID. El principal éxito comercial de las bases de datos relacionales fue el lenguaje SQL (Structured Query Language) diseñado e instalado en IBM Research, ya que se convirtió en su lenguaje estándar [6].

Big data.- El mundo digital está creciendo muy rápido y se vuelve más complejo en volumen (terabyte a petabyte), variedad (estructurado, no estructurado e híbrido), velocidad (alta velocidad en crecimiento) y naturaleza. Esto se conoce como el fenómeno global llamado big data.

Normalmente, esto se considera como una recopilación de datos que ha crecido tanto que no se puede gestionar o explotar de manera efectiva utilizando herramientas de gestión de datos convencionales: por ejemplo, sistemas de gestión de bases de datos relacionales (RDBMS) o motores de búsqueda convencionales. Para manejar este problema, los RDBMS tradicionales se complementan con un conjunto de sistemas de gestión de bases de datos (DBMS) alternativo especialmente diseñado; tales como NoSQL [1].

1.1. Plataforma tecnológica

La analítica empresarial y los conceptos relacionados que describen el análisis de los datos comerciales para la toma de decisiones han recibido amplia atención tanto en la comunidad académica como en la empresarial. La aparición de sistemas de bases de datos en memoria se ha promovido aún más mediante procedimientos de gestión de datos mejorados y arquitecturas de hardware multinúcleo que se han vuelto disponibles recientemente [7].

1.1.1. Arquitectura

Algunos de los desarrollos más importantes de los últimos años en tecnología informática son los CPU multinúcleo y un aumento en la capacidad de memoria basada en una arquitectura de 64 bits, que admite fácilmente terabytes de espacio directamente direccionable. La arquitectura multinúcleo permite el procesamiento masivo en paralelo de las operaciones de la base de datos, y dado que todos los datos relevantes se guardan permanentemente en la memoria, el procesamiento se realiza a la mayor velocidad posible.

Las operaciones de lectura son completamente independientes de cualquier acceso a dispositivos de almacenamiento de disco más lentos. Las operaciones de escritura también tienen lugar en la memoria, pero también deben registrarse en un almacenamiento no volátil para garantizar la persistencia de los datos [8].

1.1.2. Tecnología in-memory

Ha sido propiciada por la necesidad de procesamiento de grandes volúmenes de datos de manera muy rápida y fundamentalmente por el desarrollo de los procesadores y el incremento en la capacidad de memoria basada en la arquitectura de 64-bits. Esto ha hecho posible el procesamiento paralelo masivo de las operaciones de base de datos, albergando todos los datos relevantes en memoria [9].

La necesidad de rendimiento en el dominio de las Tecnologías de Información (TI) combinado con las ventajas de la computación in-memory son factores importantes que han influenciado la aparición de bases de datos in-memory (IMDB) [10].

1.2. In-memory database

Las IMDB constituyen un sistema de gestión de base de datos diseñadas para un alto rendimiento con la condición de que exista suficiente memoria para mantener la data necesaria en ella. Poseen una técnica de almacenamiento columnar lo que lo que posibilita el accesoa la data a grandes velocidades y capacidades deanalítica en tiempo-real. En comparación con CloudComputing, el beneficio para el usuario es inmediatamenteentendible, porque viene de un rápido análisisde grandes volúmenes de datos [3].

1.3. Bases de datos NoSQL

La comunidad de desarrollo desea una base de datosflexible que se adapte fácilmente a los nuevos tiposde datos y no se vea interrumpida por los cambiosen la estructura de contenido. Desafortunadamente, elenfoque rígidamente definido y basado en el esquemautilizado por las bases de datos relacionales hace quesea imposible incorporar rápidamente nuevos tipos dedatos.

NoSQL proporciona un modelo de datos que se adapta mejor a estas necesidades, ya que no requiere ningún tipo de esquemas de tablas fijas, a diferencia del modelo tradicional. NoSQL generalmente se escala horizontalmente y evita las principales operaciones de unión en los datos.La base de datos NoSQL cubre un enjambre de múltiples bases de datos, cada una con un tipo diferente de modelo de almacenamiento de datos [11].

Su popularidad se ha incrementado debido a la necesidad de procesamiento rápido en grandes volúmenes de datos aprovechado las ventajas de su arquitectura altamente escalable, estructura de datos flexible (libre de esquemas),menor latencia y alto rendimiento [12]. Pueden ser divididas en 4 categorías de acuerdo con diferentes optimizaciones:

1.3.1. Base de datos clave-valor

Un almacén clave-valor consiste de un conjunto de pares donde una parte representa la clave, y la otra a los valores que pueden ser cadenas de texto o listas y conjuntos más complejos. Las búsquedas de datos se realizan contra claves, no valores [13].

1.3.2. Bases de datos documentales o basadas en documentos

Diseñadas para almacenar data almacenada en documentos que usan diferentes formatos como JSON, entre las cuales se pueden mencionar MongoDB y CouchDB [14].

1.3.3. Bases de datos gráficas o basadas en grafos

En estas bases de datos se almacenan su información en forma de nodos de un grafo y relaciones como aristas de este. Muy utilizadas en sistemas de recomendación, manejo de contenido, entre otras, siendo las más utilizadas Neo4J, GraphBase, Infinite Graph [14].

1.4. Bases de datos orientadas a columnas

En el formato columnar, todos los valores de un atributo de la tabla son almacenados como un vector usando múltiples bloques de memoria y todos los vectores de atributos de una tabla son almacenados secuencialmente. Al organizar los valores en la forma de un vector de atributos permite una fácil compresión de datos y también permite una alta velocidad de escaneo y filtraje. Esto resulta en mucho procesamiento secuencial donde el formato columnar tiene una enorme ventaja comparada con la tradicional base de datos de disco orientado a filas. Junto con la opción de procesamiento paralelo, se puede alcanzar una muy alta velocidad para filtraje o cualquier tipo de agregación (que constituyen algunas de las principales cargas en procesamiento analítico). La velocidad es en efecto tan alta que se puede dejar de lado la idea de preagregación de la data transaccional, la base de los sistemas de información en las décadas pasadas. Además, ya no se requieren índices adicionales para acceso más rápido a la data [8]. Un esquema de operaciones de filas y columnas se observa en la Figura 1.

Figura 1. Operaciones de filas y columnas sobre un diseño de datos de filas y columnas [8]

Entre las características funcionales más resaltantes están: alta compresión, materialización, operación directa en datos comprimidos, iteración por bloque, eficiencia en operadores Join, entre otros.

1.5. Teorema de Brewer

Debido a que el tamaño de los datos creció inmensamente, fue necesario encontrar más soluciones escalables que las bases de datos ACID (Atomicity, Consistency, Isolation and Durability) existentes hasta ahora. Como resultado, se desarrollaron nuevos principios, resumidos bajo el paradigma BASE (Basic Availability, Soft-state, Eventual Consistency) [15]. Las propiedades de ACID se centran en la consistencia y son el enfoque tradicional de las bases de datos. Brewer y su equipo crean BASE a finales de la década de 1990 para capturar los enfoques de diseño emergentes para la alta disponibilidad. Los sistemas modernos, incluida la nube, usan una combinación de ambos enfoques, tradicional y emergente [16].

El objetivo del teorema Brewer era justificar la necesidad de explorar un espacio de diseño más amplio, de ahí su formulación. Los diseñadores e investigadores han utilizado el teorema de Brewer como una razón para explorar una amplia variedad de novedosos sistemas distribuidos. El movimiento NoSQL también lo ha aplicado como argumento contra las bases de datos tradicionales. En cierto sentido, en el movimiento NoSQL se trata de crear opciones que se enfoquen primero en disponibilidad y luego en consistencia; las bases de datos que se adhieren a las propiedades de ACID hacen lo contrario [16]. De acuerdo con este teorema cuando se trabaja en sistemas distribuidos es imposible garantizar las tres características simultáneamente. Solo dos de las tres cualidades son posibles, es necesario renunciar o bien sacrificar parcialmente una característica para obtener las otras [17].

Figura 2. Teorema de Brewe. Adaptado de [18]  

  • Consistencia (C) equivalente a tener una única copia actualizada de los datos.

    Alta disponibilidad (A) de esos datos (para actualizaciones).

    Tolerancia a las particiones de red (P).

Una forma popular de caracterizar NoSQL ha sido examinar su enfoque para satisfacer el teorema de coherencia, disponibilidad y tolerancia de partición (CAP) de Brewer. La mayoría de los sistemas NoSQL han sido diseñados para sacrificar la consistencia a cambio de una alta disponibilidad en un entorno particionado [19]. La Figura 2 presenta un enfoque del teorema en relación con algunas bases de datos como ejemplo.

La opción de renunciar a la tolerancia de partición no es factible en entornos realistas, ya que siempre se tiene particiones de red. Por lo tanto, se deduce que se debe decidir entre disponibilidad y consistencia, que puede representarse mediante ACID (consistencia) y BASE (disponibilidad). Sin embargo, Brewer reconoció que la decisión no es binaria. Todo el espectro intermedio es útil; mezclar diferentes niveles de disponibilidad y consistencia generalmente produce un mejor resultado [15]. El objetivo actual del teorema debe ser maximizar las combinaciones de consistencia y disponibilidad que tienen sentido para una aplicación específica [16].

2. Materiales y métodos

Este trabajo desarrolla una investigación aplicada con el objetivo de que los resultados obtenidos al final sean utilizados en la solución de problemas empresariales. El diseño es descriptivo cuantitativo-comparativo ya que pretende precisar qué tipos de bases de datos tienen un mejor rendimiento a partir de la medición y estudio de las características de las mismas. El estudio usa como instrumento pruebas estandarizadas comparando dos grupos de bases de datos: columnares y relacionales.

El procedimiento a seguir se constituye de los siguientes pasos: i) determinar la muestra, en la que se selecciona los motores de bases de datos a estudiar a través de un muestreo no probabilístico por criterio, ii) selección / creación del conjunto de datos, iii) diseño del escenario de pruebas, donde se establece cómo se realizarán las pruebas, qué consultas se ejecutarán, el número de mediciones a efectuar, entre otros; además, se especifica la infraestructura de hardware y software a usarse, iv) carga de datos, donde se procede a la carga en todas las bases determinadas en la muestra, v) medición, en donde se las realizan bajo el método de promedios y con una herramienta especializada; asimismo se registran los resultados en todos los escenarios definidos, vi) análisis de resultados, en donde se interpretan los resultados mediante gráficos y tablas.

2.1. Determinación de la muestra

Antes de escoger la muestra, se estableció que la población son todas las bases de datos columnares y base de datos relacionales existentes hasta el desarrollo de la presente investigación. Para la elección se usó un muestreo no probabilístico por criterio, este es el mejor tipo de muestreo no probabilístico. Los criterios de inclusión y exclusión para la delimitación poblacional son:

  • Base de datos de código abierto (sin licencia).

    Experiencia de los investigadores.

Las bases de datos SQL evaluadas en este artículo son PostgreSQL y MySQL. Por su posicionamiento con respecto a bases de datos similares, como se observa en el cuadrante de mejores bases relacionales código abierto [20]. Bajo los mismos criterios, las bases de datos NoSQL evaluadas serán: MongoDB, Cassandra, MonetDB. Estas alternativas se eligieron por ser de código abierto y de gran utilización, sus características como escalabilidad, tolerancia a fallos, almacenamiento columnar junto con su almacenamiento en memoria las hacen pioneras entre sus pares como se observa en el Ranking de bases de datos columnares [21].

Otro factor que se tomó en cuenta es que pueden interpretar sintaxis SQL, lo que reduce el impacto de cambiar a un ambiente NoSQL. MongoDB, si bien no es una base de datos columnar, es un tipo de base de datos NoSQL, específicamente documental; se la seleccionó para comparar las bases columnares, no solo con bases de datos SQL, sino también con otro tipo de base de datos NoSQL, en este caso documental. Adicional MongoDB también usa tecnología in-memory. Por tanto, la muestra final tendrá las bases de datos expuestas en la Tabla 1, donde se detalla a qué familia de base de datos pertenece y la versión con la que se trabajará durante la investigación.

Tabla 1. Detalle bases de datos 

2.2. Selección / creación del conjunto de datos

Para evaluar y comparar el rendimiento de las bases de datos, se ha seleccionado un conjunto ya existente que se obtuvo de una fuente pública [22]. Este corresponde a las ventas de una gran corporación comercial con registros de facturas realizadas entre los años 2015-2016. La cantidad de registros que contiene este archivo es 125 000 000 (125 millones). Los datos están grabados sobre archivos CSV para su fácil y uniforme acceso. La descripción de los campos contenidos en el archivo se muestra en la Tabla 2.

Tabla 2. Descripción de los campos 

2.3. Diseño del escenario de pruebas

Primero se ejecutarán las pruebas con cargas incrementales de datos, es decir, el archivo principal de datos que contiene 125 millones de registros se lo dividirá de la siguiente manera: un millón, diez millones, veinticinco millones y cincuenta millones de registros. Ahora se tienen cuatro archivos los cuales conformarán cuatro escenarios distintos; estos cuatro archivos contienen el mismo número de columnas y tipo de datos. En estos cuatro escenarios se ejecutarán las consultas en todas las bases de datos. Con esto se pone a prueba el rendimiento de las bases de datos relacionales frente a las columnares en iguales escenarios. Las especificaciones de los escenarios de prueba se detallan en la Tabla 3.

Tabla 3. Especificaciones de los escenarios 

2.4. Diseño de consultas

Se elaboran tres tipos de consultas que se ejecutarán en los cuatro escenarios de pruebas ya definidos.

  • i. Primera consulta (clave-valor): este tipo de consulta devuelve un solo registro de todo el conjunto de datos, el cual será buscado en la base por una clave (id). Ejemplo:

SELECT id, item_nbr, store_nbr, date

FROM train

WHERE id = 500023352;

  • ii. Segunda consulta (cláusula where - Set de datos): para su diseño se tomó en consideración lo siguiente: el set de datos resultante debe retornar por lo menos un tercio o más del total de datos en cada escenario, por lo tanto, se tuvo cuatro consultas, una por cada escenario. Como se observa en la Tabla 4 en cada consulta cambia la fecha para devolver aproximadamente el 30 % de datos del total.

Tabla 4. Consulta (set de datos) para los cuatro escenarios 

  • iii. Tercera consulta (función de agregación): usará la función de agregación SUM() para calcular las ventas totales de una tienda determinada.

SELECT SUM (unit_sales)

FROM train

WHERE store_nbr = ‘12’

2.5. Entorno de pruebas

Las pruebas se realizaron en un único equipo con las características descritas en la Tabla 5.

Tabla 5. Consulta (set de datos) para los cuatro escenarios 

2.6. Mediciones

Se procede a ejecutar las respectivas consultas en cada escenario para registrar los tiempos de respuesta de cada base de datos, para este fin se utilizó Aqua Data Studio que es una herramienta gráfica para tareas de administración, diseño y consulta en diferentes bases de datos, con el objetivo de que las mediciones sean más confiables y evitar el error humano. Medición en el primer escenario – 1 millón de registros (Tablas 6, 7, 8).

Tabla 6. Consulta 1 (clave-valor) 

Tabla 7. Consulta 2 (set de datos) 

Tabla 8. Consulta 3 (función de agregación) 

Medición en el segundo escenario – 10 millones de registros (Tablas 9, 10, 11).

Tabla 9. Consulta 1 (clave-valor) 

Tabla 10. Consulta 2 (set de datos) 

Tabla 11. Consulta 3 (función de agregación) 

Medición del tercer escenario – 25 millones de registros (Tablas 12, 13, 14).

Tabla 12. Consulta 1 (clave-valor) 

Tabla 13. Consulta 2 (set de datos) 

Tabla 14. Consulta 3 (función de agregación) 

Medición del cuarto escenario – 50 millones de registros (Tablas 15, 16, 17).

Tabla 15. Consulta 1 (clave-valor) 

Tabla 16. Consulta 2 (set de datos) 

Tabla 17. Consulta 3 (función de agregación) 

3. Resultados y discusión

Analizamos los resultados de las mediciones en dos secciones, resultados por escenario y resultados por consulta.

3.1. Resultados por escenario

Aquí se presentan y analizan los tiempos promedio en milise gundos resultantes de la ejecución de las tres consultas en los cuatro escenarios con 1, 10, 25 y 50 millones de registros.

3.1.1. Primer escenario – 1 millón de registros

La Tabla 18 muestra los resultados en milisegundos, obtenidos durante la ejecución de las tres consultas con un total de un millón de registros.

Tabla 18. Resultados 1 millón de registros 

La Figura 3 muestra que para la primera consulta de tipo clave-valor no se observan cambios en los tiempos de ejecución entre las bases de datos comparadas. En la segunda consulta donde se usa una cláusula where que retorna un set de datos, ya se observa variaciones entre el rendimiento de las bases de datos, en donde MySQL muestra el peor tiempo de respuesta con 531,2 milisegundos seguida de PostgreSQL, a comparación de la base de datos columnar Cassandra que presenta un tiempo de respuesta de 9,4 milisegundos, esto es un tiempo 56,51 veces más eficiente que el mostrado por MySQL. En la tercera consulta al emplear la función de agregación SUM se observa que los mejores tiempos de respuesta se obtienen con Cassandra, MonetDB y MongoDB, siendo Cassandra la de mejor eficiencia con un tiempo de 62,6 milisegundos que es 5,64 más eficiente a comparación de MySQL que tiene un tiempo de 353 milisegundos.

Figura 3. Resultados 1 millón de registros 

3.1.2. Segundo escenario – 10 millones de registros

La Tabla 19 muestra los resultados en milisegundos, obtenidos durante la ejecución de las tres consultas con un total de 10 millones de registros.

Tabla 19. Resultados 10 millones de registros 

En la Figura 4 se observa una notable diferencia en los tiempos de respuesta de la segunda y tercera consultas entre las bases de datos columnares en comparación con las bases de datos relacionales; sin embargo, para la primera consulta los tiempos de respuesta en los dos tipos de base de datos sigue manteniéndose regular sin variaciones. Las bases MongoDB, MonetDB y Cassandra tuvieron tiempos similares. En la segunda consulta el rendimiento más bajo presentó MySQL que expuso un tiempo de 6422 milisegundos casi similar a Postgres, que a comparación con Cassandra con un tiempo de 20,4 milisegundos; esta última es 314,8 veces más eficiente que MySQL. La tercera consulta se mantiene MySQL con el tiempo de respuesta más bajo con 3784 milisegundos a comparación de Cassandra con 525 milisegundos siendo 7,21 veces más eficiente la base de datos columnar.

Figura 4. Resultados 10 millones de registros 

3.1.3. Tercer escenario – 25 millones de registros

La Tabla 20 muestra los resultados en milisegundos obtenidos durante la ejecución de las tres consultas con un total de 25 millones de registros. Los resultados del tercer escenario mostrado en la Figura 5 se mantienen semejantes los tiempos de respuesta para la primera consulta en todas las bases de datos. Para las consultas 2 y 3 se logra un buen rendimiento en las bases de datos MongoDB, MonetDB y Cassandra. Entre las bases de datos del tipo orientado a columnas, Cassandra en las consultas 2 y 3 exhibió un tiempo de respuesta similar a MonetDB. En la segunda consulta el peor rendimiento fue presentado por la base de datos de MySQL con 14 921,8 milisegundos, esto es un tiempo de ejecución 1000 veces mayor en comparación con la base de datos columnar Cassandra con 14,6 milisegundos. Al igual que en la tercera consulta MySQL presenta un tiempo de 10 115,8 milisegundos, lo cual es 5,38 veces más lento que Cassandra con 1879 milisegundos.

Tabla 20. Resultados 25 millones de registros 

Figura 5. Resultados 25 millones de registros 

3.1.4. Cuarto escenario – 50 millones de registros

La Tabla 21 muestra los resultados en milisegundos, obtenidos durante la ejecución de las tres consultas con un total de 50 millones de registros.

Tabla 21. Resultados 50 millones de registros 

La Figura 6 del cuarto escenario muestra que la primera consulta permanece sin variaciones en el tiempo de respuesta en todas las bases de datos. Para las consultas 2 y 3 se puede observar que las bases de datos con peor rendimiento son MySQL seguida de PostgreSQL. MySQL es 46,1 veces más lenta que MonetDB. PostgreSQL respondió un poco mejor en la tercera consulta siendo solo 2,7 veces más lenta que Cassandra. Esta última lidera en eficiencia siendo 46 veces más rápida que su homóloga MonetDB en la segunda consulta.

Figura 6. Resultados 50 millones de registros 

3.2. Resultados por consulta

Aquí se presentan y analizan los tiempos promedio de respuesta resultantes agrupados por consulta en todos los escenarios.

3.2.1. Primera consulta – clave-valor

La Tabla 22 muestra los resultados en milisegundos, obtenidos durante la ejecución solo de la primera consulta (clave-valor) en todos los escenarios.

Tabla 22. Resultados primera consulta 

En la Figura 7 se observa que para la primera consulta los tiempos de respuesta son muy similares y eficientes en todas las bases de datos, tanto en MySQL como en PostgreSQL los tiempos de respuesta no varían considerablemente mientras crece el volumen de datos, lo mismo ocurre con los tiempos de respuesta de Cassandra, MongoDB y MonetDB que permanecen sin cambios notables. Ninguna de estas bases de datos demora más de un segundo en realizar esta consulta.

Figura 7. Resultados primera consulta 

3.2.2. Segunda consulta – set de datos

La Tabla 23 muestra los resultados en milisegundos, obtenidos durante la ejecución de la segunda consulta (set de datos) en todos los escenarios.

Tabla 23. Resultados primera consulta 

En la Figura 8 cuando se ejecuta la segunda consulta que utiliza una cláusula where que retorna el 30 % de todos los datos. Se observa una clara diferencia en los tiempos de respuesta cuando va aumentado la cantidad de registros, entre las bases de datos relacionales y columnares. MySQL con 1M de datos su tiempo de respuesta fue 531 milisegundos, pero con 50M de datos su tiempo de respuesta tiene un fuerte incremento presentando un tiempo de 29425 milisegundos, caso similar presenta PostgreSQL. Mientras que con bases de datos columnares mantienen un tiempo promedio independiente del volumen de datos. Como Cassandra que con 1M de registros su tiempo de respuesta es 9,4 milisegundos y con 50M de registros presentó un tiempo de respuesta de 15,4 milisegundos.

Figura 8. Resultados segunda consulta 

3.3. Tercera consulta – función de agregación sum ()

La Tabla 24 muestra los resultados en milisegundos, obtenidos durante la ejecución de la tercera consulta (función de agregación) en todos los escenarios.

Tabla 24. Resultados primera consulta 

Analizando la Figura 9 para 1 y 10 millones de registros, las variaciones en tiempos de respuesta en todas las bases de datos no arrojan una diferencia significativa, en cambio, cuanto aumenta el volumen de datos a 25 y 50 millones respectivamente ya se tiene una variación considerable en los tiempos de respuesta entre el tipo de base relacionales y columnares, PostgreSQL cuando se ejecuta la consulta con 50 millones de registros el tiempo de respuesta es 20 953 milisegundos y en MongoDB 3324 milisegundos. A medida que aumenta la cantidad de registros, la diferencia de rendimiento entre MongoDB y PostgreSQL se hace evidente. Cassandra, MonetDB y MongoDB son ligeramente afectadas en el tiempo de respuesta conforme incrementa el volumen de datos.

Figura 9. Resultados tercera consulta 

Considerando los resultados obtenidos y las características propias de cada base de datos, se encontró que, en las bases de datos relacionales MySQL y Postgres, hay una relación directamente proporcional entre el volumen de datos y el tiempo, es decir, mientras se incrementa el volumen de datos, el tiempo de consulta también se incrementa en mayor proporción. A diferencia de las bases de datos columnares Cassandra y MonetDB, en las cuales, al incrementar el volumen de datos, tiene un impacto menor en los tiempos de respuesta.

Las bases de datos columnares tienen un rendimiento superior debido a que ocupan tecnología in-memory (en memoria RAM) para el almacenamiento y la recuperación de datos, lo que permite un menor tiempo de ejecución de las consultas, a diferencia del tipo de base de datos relacionales donde el rendimiento se ve afectado debido al hecho de que los registros deben leerse desde el disco, que es mucho más lento en comparación con la memoria RAM.

4. Conclusiones

Como resultado de la presente investigación se ha podido cumplir con los objetivos planteados, por lo cual, se concluye que el rendimiento de una base de datos columnar es óptimo en ambientes de análisis de datos. En las bases de datos MySQL y Postgres la relación entre el volumen de datos y el tiempo es directa e incrementalmente proporcional, al contrario, en las bases de datos de la familia columnar Cassandra y MonetDB, los tiempos de ejecución no sufren variaciones notables mientras aumenta el volumen de los datos.

Todas las bases de datos comparadas tuvieron la misma eficiencia en la ejecución de la primera consulta tipo clave-valor debido a la presencia de la clave primaria, todas las bases presentaron tiempos de ejecución similares, por tanto, para este tipo de consultas, ambos tipos de bases de datos tienen un óptimo rendimiento. A diferencia de los resultados en la segunda consulta (set de datos) y la tercera consulta (función de agregación) donde la diferencia de tiempos de ejecución es bastante notoria. El rendimiento superior de las bases de datos columnares que presentó mejoras de hasta 7,21 y 1900 veces más eficiencia en la tercera y segunda consulta respectivamente, se debe a que ocupan altamente la memoria volátil para el almacenamiento y la recuperación de datos, lo que permite un menor tiempo de ejecución de las consultas, a diferencia del tipo de base de datos relacionales donde el rendimiento no fue el mejor debido al hecho de que los registros deben leerse desde el disco, que es mucho más lento en comparación con la memoria volátil.

El tipo de base de datos columnar y el movimiento NoSQL en general, es adecuado para resolver el problema actual del big data, que es el manejo de grandes cantidades de datos. Por lo cual se recomienda analizar primero la lógica de negocio, caso de uso e infraestructura para verificar qué tipo de base de datos es la más apta para la solución de las problemáticas que se posean, referente a esto se puede evaluar otros tipos de base de datos NoSQL que existen en el mercado. El análisis de datos necesita bases de datos capaces de almacenar y procesar grandes cantidades de datos con eficacia, la demanda de alto rendimiento al leer y escribir, así que la base de datos relacional tradicional no resulta ser la solución más adecuada. Bases de datos columnares surgen como una solución que cumple con las expectativas de rendimiento en este campo.

Las bases de datos SQL y NoSQL proporcionan diferentes características y una no puede reemplazar a otra. Si el sistema no es flexible en términos de consistencia, entonces el sistema de administración de base de datos relacional es la opción correcta. Si el sistema puede renunciar a cierta consistencia, las bases de datos NoSQL pueden ser la mejor opción para proporcionar más disponibilidad, escalabilidad y alto rendimiento. Por lo cual dependiendo del objetivo que se persiga, se podría pensar en un modelo híbrido que combine las dos tecnologías SQL y NoSQL, donde sí se necesita mantener mayor consistencia se puede almacenar de una manera relacional mientras que para consultas inmediatas o recurrentes, se utilizarían bases de datos columnares. Como trabajo futuro, se podría realizar el mismo estudio, pero en un entorno distribuido y paralelo para contrastar y verificar los resultados obtenidos en esta investigación, también se deja la posibilidad de continuar este estudio más a profundidad en temas de configuración y elaboración de las consultas para obtener un mejor provecho de estas herramientas.

Otra línea futura de investigación se enfocaría en un análisis detallado de escritura en bases de datos columnares con respecto a base de datos relacionales. El presente trabajo resume los elementos y consideraciones más importantes que fueron desarrollados en su totalidad en el trabajo de tesis de [23].

Referencias

[1] A. B. M. Moniruzzaman and S. A. Hossain, “Nosql database: New era of databases for big data analytics - classification, characteristics and comparison,” International Journal of Database Theory and Application, vol. 6, no. 4, pp. 1–5, 2013. [Online]. Available: http://bit.ly/2XaKoPK [ Links ]

[2] M. F. Pollo Cattaneo, M. López Nocera, and G. Daián Rottoli, “Rendimiento de tecnologías nosql sobre cantidades masivas de datos,” Cuaderno Activa, no. 6, pp. 11–17, 2014. [Online]. Available: http://bit.ly/2Rb8zrO [ Links ]

[3] I. Mihaela-Laura, “Characteristics of in-memory business intelligence,” Informatica Economica, vol. 18, no. 3, pp. 17–25, 2014. [Online]. Available: http://doi.org/10.12948/issn14531305/18.3. 2014.02 [ Links ]

[4] D. Robles, M. Sánchez, R. Serrano, B. Adárraga, and D. Heredia, “?’qué características tienen los esquemas nosql?” Investigación y desarrollo en TIC, vol. 6, no. 1, pp. 40–44, 2015. [Online]. Available: http://bit.ly/2MJ1wZa [ Links ]

[5] M. Marqués, Bases de datos. Universitat Jaume, 2011. [Online]. Available: http://bit.ly/2RcPtS9 [ Links ]

[6] E. Ramez and S. B. N., Fundamentals of Database Systems. Pearson Education., 2015. [Online]. Available: http://bit.ly/2IG3pAk [ Links ]

[7] G. Hahn and J. Packowski, “A perspective on applications of in-memory analytics in supply chain management,” Decision Support Systems, vol. 76, pp. 45–52, 2015. [Online]. Available: https://doi.org/10.1016/j.dss.2015.01.003 [ Links ]

[8] H. Plattner and B. Leukert, The In-Memory Revolution. Springer. Springer, 2015. [Online]. Available: http://bit.ly/2F3ezhO [ Links ]

[9] M. R. Morales Morales and S. L. Morales Cardoso, “Inteligencia de negocios basada en bases de datos in-memory,” Revista Publicando, vol. 11, no. 2, pp. 201–217, 2017. [Online]. Available: http://bit.ly/2WB3vmC [ Links ]

[10] R. Babeanu and M. Ciobanu, “In-memory databases and innovations in Business Intelligence,” Database Systems Journal, vol. 6, no. 1, pp. 59–67, July 2015. [Online]. Available: http://bit.ly/2wZLFL7 [ Links ]

[11] V. D. Shetty and S. J. Chidimar, “Comparative study of sql and nosql databases to evaluate their suitability for big data application,” International Journal of Computer Science and Information Technology Research, vol. 4, no. 2, pp. 314–318, 2016. [Online]. Available: http://bit.ly/2KlNZor [ Links ]

[12] A. T. Kabakus and R. Kara, “A performance evaluation of in-memory databases,” Journal of King Saud University – Computer and Information Sciences, vol. 29, no. 4, pp. 520–525, 2017. [Online]. Available: https://doi.org/10.1016/j.jksuci.2016.06.007 [ Links ]

[13] M. T. González-Aparicio, M. Younas, J. Tuya, and R. Casado, “Testing of transactional services in nosql key-value databases,” Future Generation Computer Systems, vol. 80, pp. 384–399, 2018. [Online]. Available: https://doi.org/10.1016/j.future.2017.07.004 [ Links ]

[14] A. Nayak, A. Poriya, and D. Poojary, “Type of nosql databases and its comparison with relational databases,” International Journal of Applied Information Systems (IJAIS), vol. 5, no. 4, pp. 16–19, 2013. [Online]. Available: http://bit.ly/2X2fIQQ [ Links ]

[15] S. Simon, “Report to brewer’s original presentation of his cap theorem at the symposium on principles of distributed computing (podc) 2000,” University of Basel, HS2012, Tech. Rep., 2018. [Online]. Available: http://bit.ly/2XFBo2l [ Links ]

[16] E. Brewer, “Cap twelve years later: How the "rules" have changed,” Computer, vol. 45, no. 2, pp. 23–29, Feb 2012. [Online]. Available: https://doi.org/10.1109/MC.2012.37 [ Links ]

[17] M. Indrawan-Santiago, “Database research: Are we at a crossroad? reflection on nosql,” in 2012 15th International Conference on Network-Based Information Systems, Sep. 2012, pp. 45–51. [Online]. Available: https://doi.org/10.1109/NBiS.2012.95 [ Links ]

[18] GENBETA. (2019) Nosql: clasificación de las bases de datos según el teorema cap. [Online]. Available: http://bit.ly/2WHVvR4 [ Links ]

[19] R. D. L. Engle, B. T. Langhals, M. R. Grimaila, and D. D. Hodson, “Evaluation criteria for selecting nosql databases in a single-box environment,” International Journal of Database Management Systems (IJDMS ), vol. 10, no. 4, pp. 1–12, 2018. [Online]. Available: http://bit.ly/2ZgXEQc [ Links ]

[20] Crowd. (2019) Best relational databases software. Crowd. Inc[Online]. Available: http://bit.ly/2RbQPge [ Links ]

[21] DB-Engines. (2019) Db-engines ranking of wide column stores. [Online]. Available: http://bit.ly/2KOBYHs [ Links ]

[22] Kaggle. (2019) Corporación favorita grocery sales forecasting. [Online]. Available: http://bit.ly/2F7QYMS [ Links ]

[23] J. W. Durán Cazar, E. J. Tandazo Gaona, and M. R. Morales Morales, Estudio del rendimiento de una base de datos columnar en el análisis de datos. Tesis de Grado. Universidad Central del Ecuador, 2018. [Online]. Available: http://bit.ly/2KhB0nl [ Links ]

Recibido: 11 de Abril de 2019; Aprobado: 03 de Junio de 2019