Estudio de rendimiento de bases de datos para series temporales aplicado a la construcción de modelos basados en datos para la mejora de eficiencia energética en edificios inteligentes

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA DE VALLADOLID Grado en Ingenier´ıa Inform´atica Menci´on en Computaci´on Estudio de rendimiento de bases de datos para series temporales aplicado a la construcci´on de modelos basados en datos para la mejora de eficiencia energ´etica en edificios inteligentes Autor: Patricia Aguado Labrador Tutor: Jos´e Belarmino Pulido Junquera A mi abuela Carmen, por tu amor incondicional y sin l´ımites, por ser ´unica e irreemplazable en mi coraz´on, por tu creencia en m´ı que hizo que llegase a donde estoy ahora. Un besito al cielo. II AGRADECIMIENTOS Agradecimientos Este proyecto est´a firmado por un s´olo autor, pero son muchas las personas que han contribuido en ´el para que salga adelante. Estoy agradecida con todas las personas que han formado parte de mi vida durante la realizaci´on de este trabajo, porque de alguna manera me han aportado aquello que estaba a su alcance en cada momento y han hecho que siguiera adelante cuando sent´ıa que la vida me ven´ıa demasiado grande. En especial, quiero agradecer a mi tutor, Belarmino Pulido, por su apoyo y disposici´on para ayudarme y guiarme en esta etapa acad´emica; gracias por la paciencia y la confianza depositada en m´ı. Agradezco a mi familia por su apoyo, a mis amigos por su amor y fe en mi val´ıa, a la vida por los baches que me ha puesto en el camino y que me han ense˜nado muchas cosas, y a mi psic´ologa por darme las herramientas que necesitaba para convertirme en la persona que soy hoy en d´ıa. Por ´ultimo, quiero agradecerme a m´ı misma el esfuerzo puesto en cada ca´ıda para conseguir levantarme siendo m´as fuerte, haci´endome llegar a donde estoy ahora. III AGRADECIMIENTOS IV RESUMEN Resumen Como resultado del crecimiento exponencial de los datos en numerosos ´ambitos, los sistemas gestores de datos se han visto obligados a evolucionar para resolver los retos que plantea el “Big Data” o datos masivos. En el ´ambito de la sostenibilidad, los edificios inteligentes generan grandes cantidades de datos constantemente y necesitan emplear m´etodos basados en datos para intentar mejorar su rendimiento y eficiencia energ´etica en ausencia de modelos detallados. Para la construcci´on de modelos es necesario analizar datos que tienen asignadas etiquetas temporales, por ello para el presente trabajo contamos con datos de series temporales recopilados del edificio inteligente LUCIA de la Universidad de Valladolid. En este proyecto nos planteamos estudiar distintos sistemas gestores de bases de datos temporales para usarlos posteriormente en sistemas de aprendizaje autom´atico. Estudiamos las cualidades de cuatro sistemas gestores de bases de datos que existen hoy en d´ıa en el mercado y analizamos su rendimiento a trav´es de distintas consultas que est´an relacionadas con consultas t´ıpicas de recuperaci´on y an´alisis de datos. Adem´as, se desarrolla una herramienta que ayuda a la visualizaci´on de los resultados. Palabras clave: rendimiento bases de datos, bases de datos temporales, Big Data, series temporales, eficiencia energ´etica, edificios inteligentes V RESUMEN VI ABSTRACT Abstract As a result of the exponential growth of data in many areas, data management systems have been forced to evolve to meet the challenges posed by Big Data. In the field of sustainability, smart buildings are constantly generating large amounts of data and they need to employ datadriven methods to try to improve their performance and energy efficiency in the absence of detailed models. In order to build models it is necessary to analyze data that have time labels assigned to them, so for the present work we use time series data collected from the LUCIA smart building of the University of Valladolid. In this project we propose to study different temporal database management systems for later use in machine learning systems. We study the features of four database management systems that exist today in the market and analyze their performance through different queries that are related to typical data retrieval and analysis queries. Moreover, a tool is developed to help in the visualization of the results. Key words: performance databases, time-based databases, Big Data, time series, energy efficiency, smart buildings VII ´ INDICE DE FIGURAS 6.4. Arquitectura de OpenTSDB (Fuente: OpenTSDB) . . . . . . . . . . . . . . . . . 48 6.5. Modelo l´ogico de la base de datos PostgreSQL (Figura de elaboraci´on propia) . . 52 6.6. Modelo entidad-relaci´on para TimescaleDB (Figura de elaboraci´on propia) . . . 53 6.7. Arquitectura de contenedores en Docker para nuestro proyecto (Figura de elaboraci´onpropia) ................................... 54 7.1. Gr´afico de barras para los tiempos de carga de datos . . . . . . . . . . . . . . . 60 7.2. Gr´afico de barras para la consulta 1 (punto exacto) . . . . . . . . . . . . . . . . 63 7.3. Gr´afico de barras para la consulta 2 (m´ınimo) . . . . . . . . . . . . . . . . . . . 64 7.4. Gr´afico de barras para la consulta 3 (m´aximo) . . . . . . . . . . . . . . . . . . . 65 7.5. Gr´afico de barras para la consulta 4 (media aritm´etica) . . . . . . . . . . . . . . 68 7.6. Gr´afico de barras para la consulta 5 (desviaci´on est´andar) . . . . . . . . . . . . 69 7.7. Gr´afico de barras para la consulta 6 (conteo) . . . . . . . . . . . . . . . . . . . . 70 7.8. Gr´afico de barras para la consulta 7 (valores ´unicos) . . . . . . . . . . . . . . . . 73 7.9. Gr´afico de barras para la consulta 8 1 (horas) . . . . . . . . . . . . . . . . . . . 75 7.10. Gr´afico de barras para la consulta 8 2 (semanas) . . . . . . . . . . . . . . . . . . 75 7.11. Gr´afico de barras para la consulta 8 3 (meses) . . . . . . . . . . . . . . . . . . . 76 7.12. Gr´afico de barras para la consulta 9 (tercer cuartil) . . . . . . . . . . . . . . . . 78 7.13. Gr´afico de barras para la consulta 10 1 (1 d´ıa exacto) . . . . . . . . . . . . . . . 80 7.14. Gr´afico de barras para la consulta 10 2 (1 d´ıa y unas horas) . . . . . . . . . . . 80 7.15. Gr´afico de barras para la consulta 10 3 (1 mes exacto) . . . . . . . . . . . . . . 81 7.16. Gr´afico de barras para la consulta 10 4 (1 mes y unas semanas) . . . . . . . . . 81 8.1. Modelo de dominio (Figura de elaboraci´on propia) . . . . . . . . . . . . . . . . . 90 8.2. Casos de uso (Figura de elaboraci´on propia) . . . . . . . . . . . . . . . . . . . . 91 8.3. Diagrama de secuencia (Figura de elaboraci´on propia) . . . . . . . . . . . . . . . 91 8.4. Organizaci´on del MVC (Fuente: parte 1, cap´ıtulo 6. Dise˜no arquitect´onico[45]) . 92 8.5. Boceto pantalla principal de la interfaz . . . . . . . . . . . . . . . . . . . . . . . 93 8.6. Boceto pantalla de resultados de consultas de la interfaz . . . . . . . . . . . . . 94 8.7. Boceto pantalla de resultados de rendimiento de la interfaz . . . . . . . . . . . . 94 8.8. Pantalla de resultados de consultas de la aplicaci´on . . . . . . . . . . . . . . . . 96 XIV ´ INDICE DE FIGURAS 8.9. Pantalla de resultados de rendimiento de la aplicaci´on . . . . . . . . . . . . . . . 97 8.10. Pantalla de resultados de rendimiento (sin selecci´on del n´umero de variables) de laaplicaci´on...................................... 98 8.11. Pantalla de error de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.12.Estructuradelproyecto................................104 9.1. Posicionamiento de las bases de datos con respecto a las consultas realizadas . . 106 A.1. Ejemplo de la salida para los resultados de las consultas en las pruebas para 3 mesesy1variable...................................123 A.2. Ejemplo de la salida para los resultados de rendimiento en las pruebas (Figura deelaboraci´onpropia) ................................124 XV ´ INDICE DE FIGURAS XVI ´ INDICE DE CUADROS ´ Indice de cuadros 2.1. Seguimiento del plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. R-1: Fallos en la planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. R-2: Problemas con herramientas de desarrollo . . . . . . . . . . . . . . . . . . . 13 2.4. R-3: Indisponibilidad del desarrollador . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. R-4: Conocimiento insuficiente sobre las tecnolog´ıas . . . . . . . . . . . . . . . . 13 2.6. Estimaci´on de costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Diferencias entre SQL y NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Filas y columnas del fichero de datos en crudo . . . . . . . . . . . . . . . . . . . 30 5.2. Estructura en com´un de los archivos de datos . . . . . . . . . . . . . . . . . . . 30 5.3. Sensoresmonitorizados................................ 32 5.4. Estad´ısticas de diferentes analizadores de red . . . . . . . . . . . . . . . . . . . . 33 5.5. N´umero de registros para cada tama˜no de datos . . . . . . . . . . . . . . . . . . 37 6.1. Diferencias entre las bases de datos que vamos a utilizar . . . . . . . . . . . . . 39 6.2. Componentes de las consultas en OpenTSDB . . . . . . . . . . . . . . . . . . . 47 7.1. ´ Exito de las consultas en las diferentes bases de datos . . . . . . . . . . . . . . . 59 7.2. Tiempos de carga de datos (en segundos) . . . . . . . . . . . . . . . . . . . . . . 59 7.3. Espacio consumido por los archivos (MB archivo original vs. MB archivo adaptado) 61 7.4. Eficiencia de almacenamiento (MB archivo original vs. MB base de datos) . . . . 61 7.5. Factor de compresi´on (MB archivo adaptado vs. MB base de datos) . . . . . . . 62 7.6. Tiempos para obtener la medici´on de un d´ıa y hora determinadas (en milisegundos) 67 7.7. Tiempos para obtener el m´ınimo de las mediciones (en milisegundos) . . . . . . 67 XVII ´ INDICE DE CUADROS 7.8. Tiempos para obtener el m´aximo de las mediciones (en milisegundos) . . . . . . 67 7.9. Tiempos para obtener la media de las mediciones (en milisegundos) . . . . . . . 72 7.10. Tiempos para obtener la desviaci´on est´andar de las mediciones (en milisegundos) 72 7.11. Tiempos para obtener el conteo de las mediciones (en milisegundos) . . . . . . . 72 7.12. Tiempos para obtener los valores ´unicos de las mediciones (en milisegundos) . . 77 7.13. Tiempos para obtener la media de las mediciones tras agrupar en rangos de tiempo(enmilisegundos)............................... 77 7.14. Tiempos para obtener los intervalos de outliers de las mediciones (en milisegundos) 83 7.15. Tiempos para obtener las mediciones de diferentes rangos de tiempo (en milisegundos) ........................................ 83 8.1. RF-1: Acceder a los datos almacenados . . . . . . . . . . . . . . . . . . . . . . . 85 8.2. RF-2: Mostrar resultados de las consultas . . . . . . . . . . . . . . . . . . . . . . 86 8.3. RF-3: Mostrar resultados de rendimiento . . . . . . . . . . . . . . . . . . . . . . 86 8.4. RF-4: Modificar par´ametros de la visualizaci´on . . . . . . . . . . . . . . . . . . . 86 8.5. RF-5: Mostrar m´ultiples visualizaciones . . . . . . . . . . . . . . . . . . . . . . . 87 8.6. RF-6: Ajustar configuraci´on a los recursos disponibles . . . . . . . . . . . . . . . 87 8.7. RF-7: Guardar la visualizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 8.8. RF-8: Guardar la visualizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.9. RNF-1: Tiempos de respuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.10. RNF-2: Informaci´on de fallos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.11. RNF-3: Facilidad de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 XVIII CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 1 Introducci´on Desde el punto de vista tecnol´ogico, la revoluci´on de los datos est´a transformado la sociedad a pasos agigantados. El desarrollo de herramientas de c´odigo abierto para el almacenamiento de grandes cantidades de datos, el auge de la utilizaci´on de dispositivos conectados a Internet y nosotros mismos, favorecemos cada d´ıa el aumento del volumen de datos mundial, el cual tiene actualmente un crecimiento exponencial. Los macrodatos, o m´as com´unmente conocidos como “Big Data”[33], son la clave de la transformaci´on digital que estamos viviendo. Estos son conjuntos de datos de gran tama˜no, variabilidad y velocidad de crecimiento que podemos encontrar en infinidad de ´ambitos como, por ejemplo, en pol´ıtica haciendo posible el an´alisis de datos recogidos de los potenciales votantes; en salud facilitando el an´alisis de historiales m´edicos; en sostenibilidad mediante el tratamiento de datos recogidos de edificios; en empresas de cualquier sector donde clientes, productos y actividades de negocio hagan uso de internet y todo quede registrado digitalmente; as´ı como, muchos procesos industriales que recopilan cientos o miles de datos cada instante de cada proceso. Centr´andonos en el ´ambito de la sostenibilidad cabe decir que los edificios, los cuales son una parte fundamental de nuestra vida diaria, son los responsables del 40 % del consumo energ´etico de la Uni´on Europea y del 36 % de las emisiones de gases de efecto invernadero[8]. A lo largo del tiempo, tanto la Uni´on Europea como la Organizaci´on de Naciones Unidas han desarrollado proyectos y legislaciones para facilitar el desarrollo sostenible. De hecho, la necesidad de mejorar la gesti´on energ´etica de edificaciones y la posibilidad de disponer de cantidades ingentes de datos, obtenidos a trav´es de dispositivos tecnol´ogicos, presenta un abanico de posibilidades de cara a un futuro energ´etico m´as sostenible. La Comisi´on Europea puso en marcha el Pacto Verde Europeo en 2019, consistente en un conjunto de iniciativas para situar a la UE en el camino de la transici´on ecol´ogica. En 2021, se presenta una nueva propuesta orientada a la armonizaci´on de las normas de eficiencia energ´etica de los edificios y descarbonizaci´on del parque inmobiliario de la UE de aqu´ı a 2050. De esta manera se quieren alcanzar diferentes metas[4]: 1. Todos los edificios nuevos tendr´an cero emisiones a partir de 2030. 2. El 15 % del parque inmobiliario de cada Estado miembro con peor rendimiento deber´a actualizar y mejorar su certificado de eficiencia. 1 1.1. CONTEXTO 3. Planes nacionales para abandonar progresivamente los combustibles f´osiles en la calefacci´on y refrigeraci´on de aqu´ı a 2040. 4. Nuevas normas que fomenten el uso de las TIC (tecnolog´ıas de la informaci´on y las comunicaciones) y de las tecnolog´ıas inteligentes para garantizar el funcionamiento eficiente de los edificios. En relaci´on con el punto n´umero cuatro, hoy en d´ıa el incremento de herramientas software hacen posible el almacenamiento y la comunicaci´on de datos ya que, por ejemplo, sistemas SCADA (Supervisory Control And Data Acquisition) y sistemas de monitorizaci´on o BMS (Building Management Systems), nos brindan la posibilidad de procesar y almacenar grandes cantidades de datos en tiempo real. Adem´as, disponemos de todos los avances que se han llevado a cabo en la inform´atica y en especial en la ciencia de datos, la que nos permite analizar y extraer conocimiento de simples datos almacenados. Por otro lado, hay que tener en cuenta las dificultades existentes en torno al an´alisis de datos o a la aplicaci´on de t´ecnicas de aprendizaje autom´atico sobre estos, ya que podemos encontrarnos con datos inconsistentes, falta de datos precisos o un tama˜no de datos que condicione los recursos necesarios o los algoritmos que se puedan emplear. Se plantea entonces el problema de la calidad de datos y del almacenamiento de estos. A la hora de recopilar macrodatos sobre un edificio podemos encontrarnos con datos de distintas fuentes y de diversos tipos, as´ı como localizar valores ausentes o valores at´ıpicos, por lo que el preprocesado de estos ser´a una parte fundamental en el tratamiento del big data. Por otro lado, debemos contar con una tecnolog´ıa de almacenamiento eficiente que sea capaz de lidiar con amplios vol´umenes de datos, ciberataques, compatibilidad de los diferentes tipos de datos o la llegada de una cantidad mayor en el futuro. En la actualidad y debido a la necesidad de almacenar datos para su posterior utilizaci´on, se han llevado a cabo grandes avances en el desarrollo de diversos tipos de bases de datos, en funci´on de las necesidades que vayamos a tener. En el caso que hemos expuesto anteriormente, a la hora de recopilar datos de un edificio nos encontraremos con que estos est´an ligados a la variable tiempo, por lo que debemos contar con bases de datos capaces de trabajar de manera eficiente con este tipo de datos, a los que se les suele denominar series temporales. 1.1. Contexto Para la realizaci´on de este trabajo de fin de grado, cuyos objetivos se exponen en el siguiente apartado, contar´e con un conjunto de datos pertenecientes al edificio LUCIA (Lanzadera Universitaria de Centros de Investigaci´on Aplicada), situado en el Campus Miguel Delibes de la Universidad de Valladolid. El marco de trabajo que engloba este proyecto es el GIR GSI (Grupo de Investigaci´on Reconocido Grupo de Sistemas Inteligentes) dentro de la l´ınea de investigaci´on en “Tecnolog´ıas Big Data” y “T´ecnicas de aprendizaje autom´atico” para la gesti´on eficiente de energ´ıa en edificios inteligentes. El edificio LUCIA se dise˜n´o con el fin de verificar hip´otesis sobre las que se asienta la evaluaci´on medioambiental de edificios e investigar aspectos sociales de la edificaci´on sostenible 2 CAP´ ITULO 1. INTRODUCCI ´ ON y del uso ´unicamente de energ´ıas renovables. Las estrategias principales para convertir al LUCIA en un referente en eficiencia energ´etica y arquitectura sostenible se basan en un dise˜no bioclim´atico del edificio (cuenta con un 46 % de superficie acristalada), utilizaci´on de biomasa como energ´ıa primaria y cogeneraci´on de ´esta para climatizaci´on y producci´on de electricidad, recuperaci´on de agua y gesti´on de residuos en la fase de construcci´on, uso y demolici´on[58]. Gracias al enfoque llevado a cabo se consigue una reducci´on de m´as del 50 % en demanda energ´etica, un ahorro del 45 % en el gasto de iluminaci´on y un ahorro superior al 60 % en el gasto de energ´ıa del propio edificio y un 30 % en los edificios anexos. En la Figura 1.1 podemos ver las secciones del edificio y algunas de sus principales peculiaridades como pueden ser los lucernarios, la cubierta vegetal que permite el filtrado de agua de lluvia o el ascensor con regeneraci´on energ´etica. El edificio consta de cuatro plantas[58]: Planta s´otano, donde se encuentran distintas instalaciones como pueden ser el intercambiador geot´ermico o el multicicl´on. Planta baja, donde podemos encontrar el centro de procesado de datos y laboratorios dedicados al desarrollo de la Sociedad Digital del Conocimiento. Primera planta, dedicada a estudios gen´eticos y prevenci´on de metabolopat´ıas. Segunda planta, destinada a la investigaci´on de nutrici´on, alimentaci´on y diet´etica. Figura 1.1: Secciones edificio LUCIA (Fuente: blog LUCIA) Adem´as, destacar que el edificio consigui´o en el pasado 98 puntos LEED Platinum (Leadership in Energy and Enviromental Desing), 4,51 puntos sobre 5 en la certificaci´on verde de la Green Building Council Espa˜na (GBCe) en 2015[58] y, recientemente, consigui´o la certificaci´on internacional de protecci´on contra el contagio del virus COVID-19 por la Organizaci´on Mundial para la Seguridad y Salud en Espacios Interiores[5]. Los datos recogidos por en el edificio se almacenan en el BMS del LUCIA. Estos consisten en varios cientos de medidas, como se comentar´a m´as adelante, que tienen la caracter´ıstica de 3 1.2. OBJETIVOS representar series temporales de datos. Para implementar distintos algoritmos de aprendizaje autom´atico ser´a necesario analizar y recuperar parte de estos datos por lo que nos planteamos cu´al ser´ıa la arquitectura de bases de datos m´as adecuada para ellos. 1.2. Objetivos El presente trabajo de fin de grado tiene como objetivo analizar las prestaciones en t´erminos de tiempo de acceso y requisitos de almacenamiento de sistemas de adquisici´on y almacenamiento de datos relativos a un edificio inteligente como es el LUCIA. El proyecto constar´a de varias tareas enfocadas al estudio de diferentes bases de datos temporales para su uso en tiempo real, las cuales son: Estudiar las prestaciones de distintas bases de datos temporales: se elegir´an varias bases de dados enfocadas a almacenar datos ligados a la variable tiempo y se estudiar´an sus caracter´ısticas y configuraciones. Analizar y almacenar datos relacionados con el consumo energ´etico: se estudiar´an los datos almacenados sobre el edificio LUCIA y se se estudiar´a su almacenamiento en diferentes bases de datos enfocadas a las series de tiempo. Se realizar´an pruebas de rendimiento con el fin de elegir la m´as adecuada para los datos disponibles en este trabajo. Crear una herramienta de visualizaci´on para los datos energ´eticos del edificio: se realizar´a una representaci´on gr´afica del rendimiento obtenido en los experimentos y de los resultados de las pruebas realizadas en cada base de datos. 1.3. Estructura de la memoria A continuaci´on, se presentan los 9 cap´ıtulos en los que se divide la memoria de este trabajo: Cap´ıtulo 1 - Introducci´on: en el cap´ıtulo actual presentaremos el proyecto, daremos un contexto y explicaremos los objetivos de este trabajo de fin de grado y la estructura de la memoria. Cap´ıtulo 2 - Planificaci´on: en este cap´ıtulo hablaremos sobre temas relacionados con la gesti´on del proyecto como son la metodolog´ıa utilizada, la planificaci´on temporal, la gesti´on de riesgos y la estimaci´on econ´omica. Cap´ıtulo 3 - Caso de estudio: en este cap´ıtulo presentaremos el caso de estudio de este trabajo, profundizando en la organizaci´on del edificio inteligente del que proceden los datos utilizados en las pruebas de rendimiento. Cap´ıtulo 4 - Estado del arte: en este cap´ıtulo ahondamos un poco en el contexto de este trabajo y desarrollamos la evoluci´on de las bases de datos presentando los diferentes tipos que han surgido desde su aparici´on hasta la actualidad. 4 CAP´ ITULO 1. INTRODUCCI ´ ON Cap´ıtulo 5 - Datos: en este cap´ıtulo se realiza una descripci´on de los datos con los que trabajaremos, su estructura y sus caracter´ısticas, as´ı como el proceso de limpieza que se lleva a cabo con ellos. Cap´ıtulo 6 - Dise˜no e implementaci´on: en este cap´ıtulo se realiza una descripci´on de las bases de datos que utilizaremos, se describen las decisiones a la hora de implementar el caso de estudio y se presenta la estructura general que tendr´an los datos en las pruebas. Cap´ıtulo 7 - Estudio de rendimiento de bases de datos: en este cap´ıtulo se enuncian las m´etricas de evaluaci´on de rendimiento que vamos a utilizar y se analizan los resultados obtenidos mediante tablas y gr´aficos comparativos. Cap´ıtulo 8 - Herramienta de visualizaci´on desarrollada: en este cap´ıtulo se presenta el proceso de an´alisis, de modelado del sistema y de dise˜no de la aplicaci´on web desarrollada para la visualizaci´on de los resultados. Cap´ıtulo 9 - Conclusiones y trabajo futuro: en este cap´ıtulo se analiza el resultado global del proyecto exponiendo las conclusiones a las que hemos llegado y las posibles mejoras de este trabajo. 5 2.4. GESTI ´ ON DE RIESGOS Ejecuci´on pruebas rendimiento y validaci´on 1 d´ıa 2 d´ıas 28/06/23 28/06/23 09/10/23 10/10/23 Dise˜no herramienta web 5 d´ıas 9 d´ıas 29/06/23 05/07/23 11/10/23 23/10/23 Implementaci´on herramienta web 5 d´ıas 17 d´ıas 06/07/23 12/07/23 24/10/23 06/12/23 Pruebas validaci´on herramienta web 1 d´ıa 4 d´ıas 13/07/23 13/07/23 07/12/23 15/12/23 Elaboraci´on del manual del instalador 1 d´ıa 2 d´ıas 14/07/23 14/07/23 18/12/23 22/12/23 An´alisis resultados de rendimiento 3 d´ıas 7 d´ıas 17/07/23 19/07/23 26/12/23 23/01/24 Elaboraci´on de la memoria - - 08/05/23 19/07/23 08/05/23 09/02/24 Reuniones con el tutor - - 08/05/23 19/07/23 08/05/23 09/02/24 Total: 53 d´ıas 105 d´ıas 08/05/23 09/02/24 Tabla 2.1: Seguimiento del plan de trabajo 2.4. Gesti´on de riesgos La gesti´on de los riesgos del proyecto tiene como objetivo identificar los problemas que se puedan presentar durante el desarrollo del proyecto y establecer un plan de mitigaci´on para reducir el impacto negativo de estos y el aumento de los costes del proyecto. Una vez identificados los posibles riesgos que pueden surgir elaboraremos una tabla para cada uno con la siguiente informaci´on: breve descripci´on del riesgo identificado; probabilidad de ocurrencia del riesgo; impacto o grado de importancia del riesgo en una escala relativa con los valores ‘catastr´ofico’,‘cr´ıtico’,‘marginal’ y‘despreciable’; plan de mitigaci´on o medidas de prevenci´on del riesgo; y plan de contingencia o medidas de acci´on para reducir el impacto en caso de ocurrencia del riesgo. R-1 Fallos en la planificaci´on Descripci´on Los tiempos establecidos en la planificaci´on no es suficiente para el desarrollo de tareas y no se cumplen los plazos en la calendarizaci´on Probabilidad 60 % Impacto Cr´ıtico Plan de mitigaci´on Analizar las tareas de forma adecuada para no planificar tiempos que sean insuficientes. Desarrollar el trabajo en los tiempos establecidos Plan de contingencia Calcular la prioridad de las tareas a desarrollar, establecer consecuencias, reevaluar los riesgos y replanificar la calendarizaci´on de tareas Tabla 2.2: R-1: Fallos en la planificaci´on 12 CAP´ ITULO 2. PLANIFICACI ´ ON R-2 Problemas con herramientas de desarrollo Descripci´on Las herramientas de software y hardware que utilizaremos para el desarrollo del proyecto no se encuentran disponibles o presentan fallos Probabilidad 20 % Impacto Cr´ıtico Plan de mitigaci´on Realizar un control de la disponibilidad de los recursos que se utilizan, tener herramientas alternativas que poder utilizar temporalmente o de sustituci´on Plan de contingencia Adelantar la realizaci´on de otras tareas paralelas que no dependan de las herramientas y en caso de que no se pueda replanificar la calendarizaci´on Tabla 2.3: R-2: Problemas con herramientas de desarrollo R-3 Indisponibilidad del desarrollador Descripci´on Por motivos personales o m´edicos del desarrollador no se pueden realizar las tareas planificadas Probabilidad 40 % Impacto Cr´ıtico Plan de mitigaci´on Realizar un control de la disponibilidad de los recursos que se utilizan, tener herramientas alternativas que poder utilizar temporalmente o de sustituci´on Plan de contingencia Adelantar la realizaci´on de otras tareas paralelas que no dependan de las herramientas y en caso de que no se pueda replanificar la calendarizaci´on Tabla 2.4: R-3: Indisponibilidad del desarrollador R-4 Conocimiento insuficiente sobre las tecnolog´ıas Descripci´on Al planificar las tareas de adquisici´on de conocimientos y aprendizaje de herramientas tecnol´ogicas se ha establecido un tiempo inferior al necesario Probabilidad 60 % Impacto Cr´ıtico Plan de mitigaci´on Realizar un estudio exhaustivo de las tecnolog´ıas que se van a utilizar y analizar los conocimientos que tenemos acerca de ellas para ser m´as precisos con el tiempo asignado en la planificaci´on Plan de contingencia Calcular la prioridad de las tareas a desarrollar, reevaluar los riesgos y replanificar la calendarizaci´on dedicando m´as tiempo a estas tareas Tabla 2.5: R-4: Conocimiento insuficiente sobre las tecnolog´ıas 2.4.1. Seguimiento de riesgos Durante el desarrollo del proyecto se han producido los siguientes riesgos: R-1 Fallos en la planificaci´on: los tiempos estimados para las tareas en ocasiones no han sido suficientes y se han tenido que ampliar. R-2 Problemas con herramientas de desarrollo: los recursos del equipo personal en el que se desarrollaba el trabajo no era suficiente para la ejecuci´on de los programas realizados a medida que estos crec´ıan por lo que se ha necesitado solicitar recursos m´as potentes a la universidad. 13 2.5. COSTES DEL PROYECTO R-3 Indisponibilidad del desarrollador: se han presentado periodos de tiempo en los que el desarrollador no ha estado disponible por problemas personales y de salud. Estos riesgos como puede verse de color rojo en la Tabla 2.1 han supuesto cambios en la planificaci´on de las tareas provocando un desfase entre el tiempo estimado para la elaboraci´on del proyecto y el tiempo realmente empleado. Se han llevado a cabo los planes de contingencia establecidos pero las consecuencias de estos riesgos han supuesto un retraso en la entrega del proyecto. En particular, el an´alisis e implementaci´on de las bases de datos al tratarse de tecnolog´ıas que no se hab´ıan visto durante el grado y la implementaci´on de la herramienta web por la misma raz´on. 2.5. Costes del proyecto La estimaci´on de los costes supone desarrollar una estimaci´on de los costes de los recursos precisos para llevar a cabo las actividades planificadas. Realizaremos una estimaci´on reducida sin tener en cuenta los costes de esfuerzo o aquellos que son indirectos aplicados al personal del proyecto y que habr´ıa que tener en cuenta en la gesti´on de los costes de proyectos m´as grandes. En la Tabla 2.6 recogemos simplemente los costes del hardware y software que utilizaremos para la realizaci´on del trabajo propuesto. Herramienta Coste estimado Coste real Ordenador personal 699 e699 e M´aquina virtual de la universidad 1569.36 eSuponemos un coste de 0 eya que habr´a sido amortizado por la universidad para otros proyectos GanttProject 0 e0e Sublime Text 91.90 eSe puede utilizar la versi´on de prueba si no te registras: 0e Overleaf 0 eEn 2024 necesitamos la versi´on de pago para que compile el proyecto: 2 meses x 9.68 e= 19.36 e Jupyter Notebook 0 e0e Docker 0 e0e Bases de datos 0 e0e Flask 0 e0e Draw.io 0 e0e GitHub 0 e0e Total: 718.36 e Tabla 2.6: Estimaci´on de costes del proyecto Todas las herramientas que nos planteamos utilizar son de software libre o como ‘Sublime- Text’ que se puede utilizar de manera gratuita. El ´unico gasto que surge en la etapa final del proyecto y que no se hab´ıa contemplado es la cuota de pago de ‘Overleaf’ que es la plataforma en l´ınea en la que se encuentra la memoria del proyecto. 14 CAP´ ITULO 3. CASO DE ESTUDIO Cap´ıtulo 3 Caso de estudio 3.1. Edificio LUCIA En el a˜no 2013 se construy´o el edificio LUCIA en el Campus Miguel Delibes de la Universidad de Valladolid para acoger laboratorios y centros de investigaci´on cient´ıfica. Proyecto dise˜nado por el arquitecto Francisco Valbuena Garc´ıa con el objetivo de conseguir una infraestructura sostenible que garantizase y promoviese la eficiencia energ´etica. En la Figura 3.1 podemos observar algunas de las caracter´ısticas m´as significativas del edificio como son[57]: Fachada e iluminaci´on: el edificio presenta un dise˜no de sus fachadas en forma de ‘zigzag’ con el fin de reducir las cargas de refrigeraci´on en verano aprovechando el autosombreamiento y produciendo ganancias t´ermicas en invierno. En cuanto a la iluminaci´on de la estructura se combinan la utilizaci´on de pozos de luz y lucernarios, con esto se consigue reducir la demanda el´ectrica de iluminaci´on artificial. Aparcamiento descubierto: se opta por este dise˜no de cara a la obtenci´on de ventilaci´on e iluminaci´on naturales reduciendo as´ı el consumo de aparatos de refrigeraci´on. Se emplea el uso de un pavimento filtrante como parte del sistema de geotermia. Energ´ıa nula: la energ´ıa utilizada proviene del propio edificio mediante la utilizaci´on de energ´ıas exclusivamente renovables como son la fotovoltaica, geot´ermica (construcci´on de un pozo canadiense que brinda la posibilidad de ajustar la temperatura de las instalaciones sin consumir energ´ıa el´ectrica) y biomasa para cubrir todas las necesidades. Adem´as, gracias a esto es posible el autoabastecimiento y la cesi´on de energ´ıa a otros edificios del campus. Vegetaci´on: se incluye el uso de plantas y especies arb´oreas de hoja caduca aut´octonas, adem´as de una cubierta de techo ajardinada con plantas del g´enero “Sedum” que ocupan el 73,5 % de la superficie, favoreciendo as´ı el efecto isla de calor en la edificaci´on y la generaci´on de microclimas. Recuperaci´on de agua y gesti´on de residuos: la utilizaci´on de una cubierta vegetal posibilita recuperar el 100 % del agua de lluvia y a su vez, se realiza un proceso de reciclado 15 3.1. EDIFICIO LUCIA de aguas grises y un tratamiento del agua de los laboratorios ubicados en el edificio. En cuanto a la gesti´on de residuos, se ha realizado un estudio en la fase de construcci´on, utilizaci´on y demolici´on del edificio de cara a la recogida y reutilizaci´on de estos, por ejemplo mediante el reciclaje o la creaci´on de compost. (a) Fachada en forma dentada (b) Aparcamiento abierto Figura 3.1: Edificio LUCIA (Fuente: blog LUCIA) Un sistema de control centralizado se ocupa de gestionar de la forma m´as eficiente posible las instalaciones del edificio; para la monitorizaci´on de los dispositivos se utiliza un software de Siemens[43] denominado Desigo Insight1. Esta herramienta permite disponer de un sistema de control centralizado capaz de examinar la integraci´on desplegada por el edificio, as´ı como controlar todas las fuentes de energ´ıa con un ´unico sistema y hacer posible la comunicaci´on de datos a trav´es de diversas tecnolog´ıas. Este software consiste en un sistema SCADA (Supervisi´on, Control y Adquisici´on de Datos), utilizado tradicionalmente para la gesti´on de instalaciones complejas permitiendo un control autom´atico y retroalimentaci´on en tiempo real de los datos recogidos por sensores y actuadores. En la Figura 3.2 podemos ver el aspecto de su interfaz. Figura 3.2: Capturas de pantalla del sistema de monitorizaci´on (Fuente: SCADA Siemens) 1Desigo®es una marca registrada de Siemens Building Technologies Ltd 16 CAP´ ITULO 3. CASO DE ESTUDIO Las instalaciones cuentan con contadores de energ´ıa integrados mediante protocolo M-bus (Meter Bus), contadores de agua mediante pulsos, analizadores de red integrados mediante protocolo Modbus, ventiloconvectores y un sistema para el alumbrado integrado con el protocolo KNX. Adem´as, cuenta con medidores de estado y alarma para el sistema de electricidad, as´ı como controladores mediante impulsos para compuertas y lucernarios[57]. Dentro del sistema de control del edificio encontramos una serie de controladores repartidos por las cuatro plantas que se comunican con un controlador general, situado en el s´otano, desde el que se gestiona la instalaci´on. Los equipos que se encuentran conectados a estos controladores se comunican mediante diferentes protocolos. Otra parte importante de la instalaci´on son los m´as de noventa y cinco analizadores de redes el´ectricas, cuyo objetivo es el de medir la potencia el´ectrica y otros par´ametros como pueden ser tensiones, corrientes de cada fase, etc. Por ´ultimo, mencionar que hay un contador del consumo energ´etico t´ermico para todo el sistema. Las razones por las que ´unicamente se cuenta con un dispositivo para esta medici´on en lugar de tener varios distribuidos por las distintas plantas que componen el edificio son tres: instrumento de medida con un coste econ´omico elevado, posibilidad de obtener datos inv´alidos porque se den ciertas circunstancias y el bajo consumo que supone frente al consumo energ´etico debido al gran aislamiento y al destacable ratio t´ermico del edificio. A continuaci´on se describen de forma breve los principales sistemas que conforman el edificio y que pueden ser controlados desde el SCADA por personal cualificado[57]. Climatizador de aire primario El climatizador se encarga de la limpieza del aire en retorno y del control, en funci´on de sondas, de la temperatura y la humedad de ´este. El edificio cuenta con fan coils de cuatro tubos repartidos por los distintos despachos y laboratorios, estos son equipos agua-aire formados por un intercambiador de fr´ıo o calor y un ventilador. EL climatizador est´a compuesto por un control de presi´on, un control de temperatura, un control de humedad, sistema de recuperaci´on, alarmas y seguridad ante incendios. Distribuci´on de agua El edificio dispone de cuatro circuitos de distribuci´on de agua fr´ıa y seis circuitos de distribuci´on de agua caliente que arrancan en funci´on de la demanda de energ´ıa de los mismos y de la que se encuentre disponible en producci´on. Producci´on de agua A la hora de producir fr´ıo, una m´aquina de absorci´on y una enfriadora se encargan de ello. La m´aquina de absorci´on ser´a la primera opci´on a la hora de producir fr´ıo y en caso de que no sea suficiente o haya alg´un inconveniente se recurrir´a a poner en funcionamiento la enfriadora. Contadores El edificio cuenta con cinco contadores de energ´ıa que se integran en el sistema mediante protocolo M-bus, y se encargan de gestionar el calor de absorci´on, el fr´ıo de absorci´on, el calor primario, el ACS (agua caliente sanitaria) y la enfriadora. En el SCADA podremos visualizar informaci´on acerca del caudal, potencia, energ´ıa acumulada y volumen acumulado. Adem´as, dispone de contadores de agua por pulsos del ACS, climatizaci´on, general, incendios, reciclada y torre de refrigeraci´on. Adem´as, los analizadores de red integrados 17 3.1. EDIFICIO LUCIA mediante protocolo M-bus (Meter Bus) nos permiten observar en el sistema se˜nales significativas como son la energ´ıa activa, frecuencia, factor de potencia e intensidades, tensiones y potencia de fase. Unidades terminales Encontramos diferentes unidades terminales, ubicadas en cada dependencia del edificio, integradas en el sistema mediante protocolo KNX. Los fan coils de las instalaciones tienen una unidad ambiente desde la que se puede cambiar el valor de la temperatura, la velocidad del ventilador o el modo de funcionamiento. En el SCADA podemos visualizar el estado de las variables de cada dispositivo, pero al poder alterar la unidad ambiente puede que la orden representada en el sistema no sea la que se est´a dando en el dispositivo, ya que la ´ultima orden sobre el dispositivo es la que se impone. Tambi´en podemos encontrar unidades que nos permitan modificar par´ametros relacionados con la iluminaci´on. Alumbrado En cuanto a la iluminaci´on artificial del edificio, se recurre tambi´en a un sistema KNX, donde la ´ultima orden es la que se ejecuta y ´esta se puede modificar desde el puesto central o desde la unidad ambiente dispuesta en cada habitaci´on. El encendido del alumbrado en zonas comunes se realiza mediante sensores de presencia y en cuanto al apagado un programa de horario semanal se establece en el sistema para realizar los barridos de apagado. Producci´on de calor en el edificio anexo El edificio opta por la utilizaci´on de energ´ıas ´unicamente renovables. La climatizaci´on y la producci´on de energ´ıa el´ectrica se llevan a cabo a trav´es de la explotaci´on de la biomasa, lo que supone promover la utilizaci´on de este recurso frente al uso de combustibles f´osiles y una reducci´on de di´oxido de carbono. Un edificio anexo presenta un cogenerador y una caldera de biomasa destinados a la producci´on de calor que se trasladar´a al edificio LUCIA. 18 CAP´ ITULO 4. ESTADO DEL ARTE Cap´ıtulo 4 Estado del arte 4.1. Introducci´on a las bases de datos Las bases de datos han sido siempre uno de los m´etodos m´as utilizados a la hora de almacenar datos y con el paso del tiempo han evolucionado dr´asticamente desde un modelo de bases de datos jer´arquicas e informaci´on estructurada en tablas a, en la actualidad, modelos de bases de datos no relacionales e informaci´on estructurada en formato de columnas individuales o directamente en forma de documentos. Las bases de datos convencionales modelan el estado de los datos en un momento determinado, es decir, cuando estos dejan de ser ciertos se modifican y los datos nuevos sustituyen a los que hab´ıa anteriormente que dejan de ser recuperables. 4.1.1. Historia de las bases de datos Comenzaremos definiendo el concepto de base de datos como un conjunto de datos estructurados y almacenados en una unidad l´ogica. En un principio, antes de que llegasen las bases de datos a nuestras vidas se trabajaba con sistemas de ficheros los cuales surgieron al traspasar la informaci´on almacenada f´ısicamente a dispositivos electr´onicos, con el fin de ganar eficiencia a la hora de acceder a ella. Con el paso del tiempo, la existencia de un conjunto de ficheros de datos, junto con sus respectivos programas de aplicaci´on, presentaban diversos inconvenientes como son la inconsistencia de los datos al tener diversas copias repartidas por los dispositivos o la dependencia de los datos frente al soporte f´ısico. En la d´ecada de los a˜nos sesenta, el desarrollo de IDS (Integrated Data Store) por Charles Bachmann, reconocido como uno de los pioneros en los sistemas de bases de datos, supuso la creaci´on de un nuevo tipo de sistemas de bases de datos conocido como sistema de red. Posteriormente, se crean diferentes grupos de expertos para poder establecer unos est´andares acerca de las bases de datos. De esta forma se conforma la primera generaci´on de SGBD (Data Base Management Systems) compuesta por los sistemas jer´arquicos y de red. 19 4.1. INTRODUCCI ´ ON A LAS BASES DE DATOS M´as tarde, en la d´ecada de los a˜nos setenta, gracias a Edgar Frank Codd aparece la segunda generaci´on de los sistemas gestores de bases de datos, con su presentaci´on del modelo relacional y soluci´on de los inconvenientes de los sistemas existentes hasta el momento. Esto, dar´ıa paso al posterior desarrollo de un lenguaje estructurado de consultas denominado SQL (Structured Query Language) y la producci´on de varios SGBD relacionales, SQL/DS (Structured Query Language/Data System) y Oracle, durante la d´ecada de los a˜nos ochenta[27]. Ahora bien, todo avance realizado conlleva la aparici´on de inconvenientes, por lo que nos encontramos con la tercera generaci´on de los SGBD al tener que lidiar con la capacidad limitada a la hora de modelar los datos que presenta el modelo relacional. As´ı, a partir de la d´ecada de los a˜nos noventa comienzan a aparecer nuevos tipos de bases de datos como las orientadas a objeto que se encargan de almacenar objetos completos formados por un estado y un comportamiento incorporando todos los conceptos del paradigma de objetos. Como resultado de la incapacidad de las bases de datos relacionales de responder a consultas recursivas o de deducir relaciones indirectas entre los datos surgen las bases de datos deductivas basadas en l´ogica matem´atica[36]. 4.1.2. Evoluci´on de las bases de datos Poco a poco, con el desarrollo de la tecnolog´ıa, las bases de datos comenzaron a tener una posici´on relevante en el mercado, siendo cada vez m´as necesarias herramientas para gestionar los nuevos enfoques de bases de datos que iban surgiendo y nuevas formas de incorporar datos de maneras diferentes. Con la llegada de las redes sociales a nuestras vidas cuya evoluci´on se puede ver en la Figura 4.1, el aumento de datos se hizo notable y apareci´o la necesidad de disponer de bases de datos escalables y de alto rendimiento para poder cumplir con las expectativas de las nuevas tecnolog´ıas. En la actualidad, 4760 millones de personas en todo el mundo utilizan redes sociales, es decir, m´as de la mitad de la poblaci´on mundial. Dicho de otra manera, tenemos un 59,4 % de la poblaci´on mundial como usuarios activos en las redes sociales[25]. Figura 4.1: Gr´afico de aparici´on de las redes sociales (Figura de elaboraci´on propia) En el siglo XXI, adem´as de presenciar el surgimiento de las aplicaciones que nos conectan con el resto de personas a trav´es de internet, tambi´en se lleva a cabo la conexi´on de las personas 20 CAP´ ITULO 4. ESTADO DEL ARTE con los objetos que les rodean, surgiendo as´ı lo que conocemos como IoT (Internet of Things). Al mismo tiempo, la eficiencia energ´etica de los edificios va ganando peso en la sociedad, ya que supone un ahorro econ´omico y un impacto medioambiental considerable que se traduce en la transformaci´on de edificios convencionales en edificios inteligentes mediante el uso de dispositivos electr´onicos. Como podemos observar en la Figura 4.2, 307,8 millones de hogares en Enero de 2023, a nivel mundial, contaban con dispositivos inteligentes, teniendo en cuenta para las estad´ısticas dispositivos dom´esticos conectados y controlados digitalmente, a distancia o no, como son sensores, actuadores y servicios en la nube. Figura 4.2: Mercado de dispositivos dom´esticos inteligentes (Fuente: Digital 2023) Las cifras que se pueden ver en la imagen hacen referencia al gasto destinado, en d´olares, a dispositivos de automatizaci´on en el a˜no 2022. Podemos ver que, en comparaci´on con el a˜no natural anterior, hay un aumento superior al 10 % de inversi´on en cualquier tipo de uso de los dispositivos inteligentes[25]. Tal es la importancia de los datos en nuestro d´ıa a d´ıa que, en cifras, la cantidad total de datos que se prev´e crear, obtener, copiar y consumir es de 181 zettabytes en 2025, a nivel mundial. Dicho de otra manera, estamos en un per´ıodo en el que a medida que avanza nuestra tecnolog´ıa el ”Big Data”gana cada vez m´as poder. Estos grandes conjuntos de datos; los macrodatos a los que nos refer´ıamos en la Secci´on 1, son fundamentales a la hora de obtener conocimiento y crear nuevas oportunidades, pero esto tambi´en supone un gran problema para la ciencia de datos a hora de gestionarlos[49]. 21 4.3. BASES DE DATOS TEMPORALES Segmentaci´on Esta tarea est´a dirigida a reducir la dimensionalidad de las series temporales manteniendo sus caracter´ısticas fundamentales, creando una aproximaci´on precisa entre ellas. El objetivo est´a basado en reducir el error de reconstrucci´on entre la representaci´on reducida y la serie temporal original. Predicci´on Otra de las ´areas m´as importantes en relaci´on con las series temporales es el pron´ostico de valores futuros de la serie en base a la modelizaci´on de expl´ıcita de las dependencias entre los datos pasados y los presentes. Detecci´on de anomal´ıas El prop´osito de la detecci´on de anomal´ıas consiste en hallar subsecuencias extra˜nas dentro de una serie, utilizado por ejemplo a la hora de determinar si el flujos de datos procedente de una fuente incluye alguna medici´on an´omala. Descubrimiento de subsecuencias Estas subsecuencias se caracterizan por denominarse “motivos” y hacer referencia a una subsecuencia t´ıpica no solapada que aparecen de manera recurrente en una serie temporal larga. Esta idea surge del an´alisis de genes en bioinform´atica. Con lo que hemos expuesto hasta ahora, podemos ver que las series temporales tienen gran relevancia y uso en la actualidad por lo que los investigadores han dirigido sus esfuerzos a obtener un almacenamiento eficiente para este tipo de datos. Las bases de datos temporales almacenan una serie de datos que poseen ciertas caracter´ısticas[48]: En el proceso de creaci´on de datos, estos tienden a ser inmutables ya que, por lo general, las mediciones generan nuevos datos que son a˜nadidos al conjunto de datos original sin modificar las mediciones anteriores. Un conjunto de datos ligado a marcas de tiempo aumenta de volumen de manera muy r´apida y esto supone un desaf´ıo de cara al tratamiento y almacenamiento de estos. El concepto de datos formado por o que se consideran series temporales surge de la necesidad de tener un historial a lo largo del tiempo sobre el que poder realizar un seguimiento, pero no todos los datos tienen la misma importancia del conjunto. La informaci´on que podemos obtener de los datos recientes es m´as relevante que la que podemos conseguir de datos antiguos, de la misma manera, los datos de un periodo corto y reciente, son m´as f´acilmente procesables que los datos acumulados desde hace diez a˜nos. En la actualidad existen diversas bases de datos para almacenar y tratar datos ligados al tiempo y bases de datos temporales, especializadas ya en ello, de c´odigo abierto y de licencia privativa. Para la realizaci´on del trabajo de fin de grado se ha optado por la utilizaci´on de herramientas de c´odigo abierto siempre que sea posible, ya que existe la posibilidad de experimentar con diferentes bases de datos sin que eso repercuta en el coste econ´omico del proyecto. 28 CAP´ ITULO 5. DATOS Cap´ıtulo 5 Datos En este proyecto trabajaremos con conjuntos de datos reales del mismo dominio formados por mediciones de energ´ıa consumida y el momento en el que se realizaron. En lo que respecta al proceso de extracci´on de datos cabe destacar que el software DESIGO INSIGHT es muy cerrado a la hora de poder exportar los datos fuera del sistema. Se tiene constancia de que existen datos hist´oricos en formato ‘.art’ pero no se ha conseguido encontrar una forma de acceder a los datos en dicho formato, m´as all´a del visualizador de tendencias de la aplicaci´on, por lo que la forma en la que se han extra´ıdo los datos es mediante una aplicaci´on que realiza copias instant´aneas de los datos por un rango de fecha dado, obteniendo de esta forma los registros en el espacio temporal de un mes para las variables que se desean estudiar en archivos Excel[28]. Partiremos de un conjunto de archivos en formato ‘xlsx’ que contienen la recolecci´on de lecturas de los sensores del ´area de integraciones del LUCIA. Trataremos datos de un total de trece meses (11 meses del a˜no 2019 y 2 meses del a˜no 2020) que tendremos que estudiar, limpiar y dar formato para almacenar en las diferentes bases de datos. 5.1. Descripci´on de los datos Los datos en crudo o raw data son aquellos que no han sido procesados y que deberemos analizar, limpiar y estructurar para su posterior almacenamiento. Estos datos en crudo estar´an formados por un conjunto de archivos que almacenan series temporales de las variables monitorizadas por el software DESIGO en el per´ıodo de tiempo de un mes. Los archivos se dividen en distintas hojas que agrupan datos referentes a un mismo entorno y presentan una estructura en com´un como se muestra a continuaci´on. Como podemos ver en la Tabla 5.1 tenemos un grupo de datos ordenados cronol´ogicamente con una estructura en forma de registro formado por una marcha de tiempo, una medici´on y un estado de medici´on. Adem´as, en la Tabla 5.2 podemos observar la estructura com´un que en su gran mayor´ıa presentan los archivos de datos con los que contamos y que podemos desglosar de la siguiente manera: 29 5.1. DESCRIPCI ´ ON DE LOS DATOS En la primera fila y cada cuatro columnas encontramos la direcci´on del sensor y el nombre asignado por el software DESIGO. En la segunda fila y cada cuatro columnas encontramos informaci´on del sensor como el lugar en el que se encuentra y el sistema al que pertenece entre otros datos. En la tercera fila encontraremos datos referentes a la monitorizaci´on del sensor que son: •En la primera columna se registra la fecha y hora de la medici´on del sensor en formato ‘DD/MM/AA HH:MM:SS’. •En la segunda columna, cuya cabecera es la unidad de medida del sensor, se registra el valor le´ıdo. •En la tercera columna se guarda el estado y validez de la medici´on. Cabe destacar que algunos ficheros no cuentan con la columna ‘tag de tipo’ y que ser´a algo que haya que tener en cuenta al procesar los datos. •Los datos de las medidas est´an registrados a partir de la cuarta fila siguiendo este patr´on. ditech://LUCIA:AInt’PB’AnlzRed16’AI65,PrVal;AInt’PB’AnlzRed16’Trnd’TrdUFnct1 LUCIA:´ Area Integraciones‘Planta Baja’PBA5’Energia Activa,Valor actualValor actual; Funci´on universal de tendencia Fecha/Hora kWh Tag de tipo 01/03/2019 03:07:39 -4 Bien, Hora cambiada ... ... ... 03/03/2019 15:44:41 507,2 Bien, Hora cambiada 03/03/2019 23:16:20 507,2 Bien, Hora cambiada ... ... ... Tabla 5.1: Filas y columnas del fichero de datos en crudo sensor 1 sensor 2 ... informaci´on 1 informaci´on 2 ... fecha y hora unidad medida 1 tag de tipo 1 fecha y hora unidad medida 2 tag de tipo 2 ... fecha y hora valor medido estado medici´on fecha y hora valor medido estado medici´on ... ... ... ... ... ... ... ... fecha y hora valor medido estado medici´on fecha y hora valor medido estado medici´on ... valor resumen valor resumen valor resumen Tabla 5.2: Estructura en com´un de los archivos de datos A la hora de estudiar los datos y con el objetivo de tener una visi´on general de todos ellos realizamos un recuento de los sensores monitorizados, la unidad de medida en la que se toman los valores y su localizaci´on como podemos ver recogidos en la Tabla 5.3. Identificador del sensor Unidad Informaci´on AInt’PS’AnlzRed21’En1 MWh ‘Planta S´otano’General Clima’ AInt’PS’AnlzRed22’AI65 kWh ‘Planta S´otano’Enfriadora’ AInt’PS’AnlzRed23’AI65 kWh ‘Planta S´otano’Absorci´on’ Sigue en la p´agina siguiente. 30 CAP´ ITULO 5. DATOS Identificador del sensor Unidad Informaci´on AInt’PS’AnlzRed24’AI65 kWh ‘Planta S´otano’Torre’ AInt’PS’AnlzRed25’AI65 kWh ‘Planta S´otano’Imp Cl Aire’ AInt’PS’AnlzRed26’AI65 kWh ‘Planta S´otano’Ret Cl Aire’ AInt’PS’AnlzRed39’En1 MWh ‘Planta S´otano’General Red’ AInt’PS’AnlzRed29’AI65 kWh ‘Planta S´otano’P,Baja CPD CS-PB-CPD’ AInt’PS’AnlzRed34’AI65 kWh ‘Planta S´otano’Fotovoltaica Lucernarios’ AInt’PS’AnlzRed41’En1 MWh ‘Planta S´otano’General Fachada Sur’ AInt’PS’AnlzRed27’AI65 kWh ‘Planta S´otano’P,S´ot, Grupo CS-PS-S’ AInt’PS’AnlzRed36’AI65 kWh ‘Planta S´otano’P,S´ot, Red CS-PS-S’ AInt’PS’AnlzRed28’AI65 kWh ‘Planta S´otano’P,Baja Grupo CS-PB’ AInt’PS’AnlzRed37’AI65 kWh ‘Planta S´otano’P,Baja Red CS-PB’ AInt’PS’AnlzRed31’AI65 kWh ‘Planta S´otano’P,1 Grupo CS-P1’ AInt’PS’AnlzRed38’AI65 kWh ‘Planta S´otano’P,1 Red CS-P1’ AInt’PS’AnlzRed32’AI65 kWh ‘Planta S´otano’P,2 Grupo CS-P2’ AInt’PS’AnlzRed35’AI65 kWh ‘Planta S´otano’P,2 Red CS-P2’ AInt’PS’AnlzRed33’AI65 kWh ‘Planta S´otano’Laboratorios P1’ AInt’PB’AnlzRed01’AI65 kWh ‘Planta Baja’PBA1G’ AInt’PB’AnlzRed02’AI65 kWh ‘Planta Baja’PBA2G’ AInt’PB’AnlzRed03’AI65 kWh ‘Planta Baja’PBA3G’ AInt’PB’AnlzRed04’AI65 kWh ‘Planta Baja’PBA4G’ AInt’PB’AnlzRed05’AI65 kWh ‘Planta Baja’PBA5G’ AInt’PB’AnlzRed06’AI65 kWh ‘Planta Baja’PBRACK’ AInt’PB’AnlzRed07’AI65 kWh ‘Planta Baja’PBB1G’ AInt’PB’AnlzRed08’AI65 kWh ‘Planta Baja’PBB2G’ AInt’PB’AnlzRed09’AI65 kWh ‘Planta Baja’PBB3G’ AInt’PB’AnlzRed10’AI65 kWh ‘Planta Baja’PBB4G’ AInt’PB’AnlzRed11’AI65 kWh ‘Planta Baja’CF4A’ AInt’PB’AnlzRed12’AI65 kWh ‘Planta Baja’PBA1’ AInt’PB’AnlzRed13’AI65 kWh ‘Planta Baja’PBA2’ AInt’PB’AnlzRed14’AI65 kWh ‘Planta Baja’PBA3’ AInt’PB’AnlzRed15’AI65 kWh ‘Planta Baja’PBA4’ AInt’PB’AnlzRed16’AI65 kWh ‘Planta Baja’PBA5’ AInt’PB’AnlzRed17’AI65 kWh ‘Planta Baja’PBB1’ AInt’PB’AnlzRed18’AI65 kWh ‘Planta Baja’PBB2’ AInt’PB’AnlzRed19’AI65 kWh ‘Planta Baja’PBB3’ AInt’PB’AnlzRed20’AI65 kWh ‘Planta Baja’PBB4’ AInt’PB’AnlzRed44’AI65 kWh ‘Planta Baja’PBMVending’ AInt’P1’AnlzRed01’AI65 kWh ‘Planta Primera’P1A1G’ AInt’P1’AnlzRed02’AI65 kWh ‘Planta Primera’P1A2G’ AInt’P1’AnlzRed03’AI65 kWh ‘Planta Primera’P1A3G’ AInt’P1’AnlzRed04’AI65 kWh ‘Planta Primera’P1A4G’ AInt’P1’AnlzRed05’AI65 kWh ‘Planta Primera’P1A5G’ AInt’P1’AnlzRed06’AI65 kWh ‘Planta Primera’P1A6G’ AInt’P1’AnlzRed07’AI65 kWh ‘Planta Primera’P1A7G’ AInt’P1’AnlzRed08’AI65 kWh ‘Planta Primera’P1B1G’ AInt’P1’AnlzRed09’AI65 kWh ‘Planta Primera’P1B2G’ AInt’P1’AnlzRed10’AI65 kWh ‘Planta Primera’P1B3G’ AInt’P1’AnlzRed11’AI65 kWh ‘Planta Primera’P1B4G’ Sigue en la p´agina siguiente. 31 5.1. DESCRIPCI ´ ON DE LOS DATOS Identificador del sensor Unidad Informaci´on AInt’P1’AnlzRed12’AI65 kWh ‘Planta Primera’P1B5G’ AInt’P1’AnlzRed13’AI65 kWh ‘Planta Primera’P1B6G’ AInt’P1’AnlzRed14’AI65 kWh ‘Planta Primera’P1A1’ AInt’P1’AnlzRed15’AI65 kWh ‘Planta Primera’P1A2’ AInt’P1’AnlzRed16’AI65 kWh ‘Planta Primera’P1A3’ AInt’P1’AnlzRed17’AI65 kWh ‘Planta Primera’P1A4’ AInt’P1’AnlzRed18’AI65 kWh ‘Planta Primera’P1A5’ AInt’P1’AnlzRed19’AI65 kWh ‘Planta Primera’P1A6’ AInt’P1’AnlzRed20’AI65 kWh ‘Planta Primera’P1A7’ AInt’P1’AnlzRed21’AI65 kWh ‘Planta Primera’P1B1’ AInt’P1’AnlzRed22’AI65 kWh ‘Planta Primera’P1B2’ AInt’P1’AnlzRed23’AI65 kWh ‘Planta Primera’P1B3’ AInt’P1’AnlzRed24’AI65 kWh ‘Planta Primera’P1B4’ AInt’P1’AnlzRed25’AI65 kWh ‘Planta Primera’P1B5’ AInt’P1’AnlzRed26’AI65 kWh ‘Planta Primera’P1B6’ AInt’P2’AnlzRed01’AI65 kWh ‘Planta Segunda’P2A1’ AInt’P2’AnlzRed02’AI65 kWh ‘Planta Segunda’P2A2’ AInt’P2’AnlzRed03’AI65 kWh ‘Planta Segunda’P2A3’ AInt’P2’AnlzRed04’AI65 kWh ‘Planta Segunda’P2A4’ AInt’P2’AnlzRed05’AI65 kWh ‘Planta Segunda’P2A6’ AInt’P2’AnlzRed06’AI65 kWh ‘Planta Segunda’P2A7’ AInt’P2’AnlzRed07’AI65 kWh ‘Planta Segunda’P2A8’ AInt’P2’AnlzRed08’AI65 kWh ‘Planta Segunda’P2B1’ AInt’P2’AnlzRed09’AI65 kWh ‘Planta Segunda’P2B2’ AInt’P2’AnlzRed10’AI65 kWh ‘Planta Segunda’P2B3’ AInt’P2’AnlzRed11’AI65 kWh ‘Planta Segunda’P2B4’ AInt’P2’AnlzRed12’AI65 kWh ‘Planta Segunda’P2B5’ AInt’P2’AnlzRed13’AI65 kWh ‘Planta Segunda’P2A5’ AInt’P2’AnlzRed14’AI65 kWh ‘Planta Segunda’P2A1G’ AInt’P2’AnlzRed15’AI65 kWh ‘Planta Segunda’P2A2G’ AInt’P2’AnlzRed16’AI65 kWh ‘Planta Segunda’P2A3G’ AInt’P2’AnlzRed17’AI65 kWh ‘Planta Segunda’P2A4G’ AInt’P2’AnlzRed18’AI65 kWh ‘Planta Segunda’P2A5G’ AInt’P2’AnlzRed19’AI65 kWh ‘Planta Segunda’P2A6G’ AInt’P2’AnlzRed20’AI65 kWh ‘Planta Segunda’P2A8G’ AInt’P2’AnlzRed21’AI65 kWh ‘Planta Segunda’P2B1G’ AInt’P2’AnlzRed22’AI65 kWh ‘Planta Segunda’P2B2G’ AInt’P2’AnlzRed23’AI65 kWh ‘Planta Segunda’P2B3G’ AInt’P2’AnlzRed24’AI65 kWh ‘Planta Segunda’P2B4G’ AInt’P2’AnlzRed25’AI65 kWh ‘Planta Segunda’P2B5G’ AInt’P2’AnlzRed26’AI65 kWh ‘Planta Segunda’P2A7G’ AInt’P2’AnlzRed27’AI65 kWh ‘Planta Segunda’P2Lab’ AInt’PS’AnlzRed23’PotT Valor ‘Planta S´otano’Absorci´on’ Tabla 5.3: Sensores monitorizados Contamos con mediciones de 93 analizadores de red pertenecientes al ´area de integraciones del edificio (AInt). Estos se encargan de registrar datos de energ´ıa activa del edificio medidas en kWh (kilovatio hora) y MWh (megavatio hora). Tambi´en tenemos un analizador de red, el 32 CAP´ ITULO 5. DATOS ´ultimo que aparece en la Tabla 5.3, que mide el valor de potencia activa total y que no tiene una unidad de medida definida. Para tener una visi´on general acerca de c´omo son los datos decidimos estudiar dos meses, Julio y Octubre de 2019. Como vemos en la Tabla 5.4 se muestran estad´ısticas de los valores medidos por tres analizadores de red situados en la planta del s´otano y dos analizadores de las otras plantas. Con esta informaci´on observamos que la frecuencia en la toma de medidas por los analizadores de red var´ıa en el tiempo, pasamos de 1793 registros mensuales a 3099 para el analizador de red 21 del s´otano, y var´ıa de un sensor a otro, viendo que algunos realizan en el mismo mes 68 medidas y otros aumentan notablemente esta cifra. Tambi´en podemos destacar que los analizadores de red de consumos generales, como son los que se muestran en las tres primeras filas de la tabla (‘general clima’, ‘general red’ y ‘general fachada sur’ respectivamente) son los que m´as mediciones toman, en comparaci´on con sensores destinados a monitorizar variables en departamentos o laboratorios. Variable Mes Nºde registros Unidad de medida M´ınimo M´aximo Media Desviaci´on est´andar Valores nulos AInt’PS’AnlzRed21’En1 Julio 2019 1793 MWh 774.45 795.0 785.206 5.662 0 Octubre 2019 3099 MWh 812.05 819.9 816.290 2.270 0 AInt’PS’AnlzRed39’En1 Julio 2019 1860 MWh -2.0 2515.41 2486.954 60.153 0 Octubre 2019 3099 MWh 2596.43 2641.22 2619.129 12.968 0 AInt’PS’AnlzRed41’En1 Julio 2019 1860 MWh -2.0 52.83 52.354 1.287 0 Octubre 2019 3099 MWh 58.43 55.66 55.324 0.237 0 AInt’PB’AnlzRed01’AI65 Julio 2019 79 kWh -2.0 3418.9 3283.783 384.334 0 Octubre 2019 153 kWh 3.0 3432.2 3407.548 277.093 0 AInt’PB’AnlzRed15’AI65 Julio 2019 79 kWh -2.0 964.9 943.520 107.933 0 Octubre 2019 153 kWh 3.0 1008.5 994.926 80.823 0 AInt’P1’AnlzRed10’AI65 Julio 2019 61 kWh -2.0 0.0 -0.032 0.256 0 Octubre 2019 153 kWh 3.0 105.6 84.016 14.127 0 AInt’P1’AnlzRed23’AI65 Julio 2019 73 kWh -2.0 1851.3 1776.849 212.724 0 Octubre 2019 153 kWh 3.0 1875.0 1856.928 150.891 0 AInt’P2’AnlzRed10’AI65 Julio 2019 61 kWh -2.0 1522.6 1483.029 193.484 0 Octubre 2019 153 kWh 3.0 1564.8 1544.516 125.592 0 AInt’P2’AnlzRed26’AI65 Julio 2019 68 kWh -2.0 0.2 0.167 0.266 0 Octubre 2019 153 kWh 0.2 3.0 0.2183 0.226 0 Tabla 5.4: Estad´ısticas de diferentes analizadores de red Cabe destacar que las mediciones son acumuladas y que en lo que respecta a los datos de estos dos meses y nueve variables no existen nulos, adem´as la alta desviaci´on est´andar de las diferentes variables y la presencia de valores negativos ser´a algo a tener en cuenta a la hora de limpiar los datos. Utilizamos gr´aficos de l´ıneas para poder ver la tendencia temporal de los datos. En la Figura 5.1 podemos ver los datos de consumo energ´etico en MWh del analizador de red 21 situado en la planta s´otano del edificio. Como se puede ver es un consumo que aumenta a lo largo del tiempo ya que se trata de valores acumulados como ya hab´ıamos mencionado anteriormente. Representamos gr´aficamente el consumo energ´etico medido en kWh para el analizador 27 de la segunda planta en la Figura 5.2 y vemos que los valores medidos a lo largo del tiempo tienen una fluctuaci´on muy reducida salvo por las mediciones negativas que consideramos outliers o valores at´ıpicos. 33 5.1. DESCRIPCI ´ ON DE LOS DATOS Figura 5.1: Medidas tomadas por el analizador de red general 21 (planta s´otano) Figura 5.2: Medidas tomadas por el analizador de red 27 (segunda planta) Como ya hab´ıamos podido observar mediante la Tabla 5.4 y las representaciones anteriores contamos con valores at´ıpicos en el conjunto de datos por lo que decidimos representar algunas mediciones de determinados analizadores de red mediante diagramas de caja y bigotes. En la Figura 5.3 podemos hacernos una idea de como es la distribuci´on de los datos para un analizador de red general y otro de una zona m´as concreta. Al mismo tiempo y contando con las seis variables que hemos identificado tras el primer an´alisis del conjunto de datos (identificador del analizador de red, marca de tiempo de la medici´on, valor de la medici´on, unidad de medida del sensor, validez de la medici´on e informaci´on sobre la ubicaci´on) nos interesamos por la variable cualitativa que se ocupa de estudiar el tipo de validez que tiene la medici´on tomada por el sensor para saber que tipo de valores toma y la frecuencia de cada uno de ellos, informaci´on que se puede ver en la Figura 5.4. Cabe destacar que en la lectura de datos identificamos que el primer mes de datos con el que contamos carece de la columna ‘tag de tipo’ por lo que con el fin de no reducir el conjunto de datos de los que disponemos eliminando estos registros y viendo que podr´ıan ser mediciones v´alidas decidimos introducir una categor´ıa denominada Desconocido. 34 CAP´ ITULO 5. DATOS (a) Outliers analizador de red general 21 (planta s´otano) (b) Outliers analizador de red 24 (primera planta) Figura 5.3: Outliers de diferentes variables Figura 5.4: Frecuencia de valores presentes en la columna ‘tag de tipo’ 35 5.2. LIMPIEZA DE LOS DATOS 5.2. Limpieza de los datos Tras explorar y estudiar los datos de los que disponemos a trav´es de estad´ısticos, gr´aficos de l´ıneas y diagramas de caja y bigotes procedemos con la limpieza de datos que realizaremos en cuatro pasos: Eliminaci´on de valores NaN (Not a Number) Partimos de un conjunto con 543982 registros de mediciones y encontramos un valor NaN para la variable ‘device measurement’ o valor medido. Eliminaci´on de registros con un tipo de datos inv´alido Anteriormente, en la fase de representaci´on gr´afica de los datos nos damos cuenta de que para algunos identificadores de sensor obten´ıamos fallos a la hora de realizar alguna gr´afica, al igual que a la hora de querer contabilizar los valores negativos para la variable que almacena la medici´on. Teniendo en cuenta que tenemos 543981 registros de datos a simple vista no logramos ver cu´al puede ser la causa por lo que decidimos analizar el tipo de datos de todos los valores para todas las variables que tenemos. Utilizando la estructura DataFrame de Pandas[34] generamos columnas con el tipo de datos para cada variable del conjunto y utilizando la funci´on ‘value counts()’ que nos devuelve el recuento de valores ´unicos, podemos ver en la Figura 5.5c que la variable ‘timestamp’ cuyos valores deber´ıan ser todos del tipo de datos ‘datetime’ (fecha y hora) presenta valores de tipo ‘float’ (n´umero con decimales) y que la variable ‘device measurement’ cuyos valores deber´ıan ser todos del tipo de datos ‘float’ o‘int’ (n´umeros enteros) presenta valores de tipo ‘str’ (cadena de texto) y ‘datetime’. A partir de esta informaci´on analizamos los datos de las figuras 5.5a y 5.5b y al tratarse de un n´umero reducido de valores err´oneos decidimos eliminar estos registros del conjunto. Eliminaci´on de mediciones negativas En este paso descartamos los valores negativos presentes en las mediciones de los analizadores de red del conjunto de datos ya que estamos trabajando con cantidades de energ´ıa consumida y esta tiene que ser positiva. Eliminaci´on de registros duplicados Para evitar la inserci´on de registros duplicados en la base de datos realizamos una b´usqueda de estos basada en un subconjunto de variables formado por el identificador del sensor, la marca temporal, la medici´on realizada y la validez de la medici´on. Una vez eliminados estos registros contamos con un total de 517284 registros de mediciones para los trece meses de datos que tenemos. 36 CAP´ ITULO 5. DATOS (a) Atributo ‘device measurement’ (b) Atributo ‘timestamp’ (c) Recuento del tipo de datos de las variables Figura 5.5: Proceso de limpieza de datos con un tipo err´oneo Una vez que tenemos todos los datos preparados para proceder con las pruebas de rendimiento lo que haremos ser´a dividir el conjunto de datos completo en conjuntos de datos del tama˜no de 3, 6, 10 y 13 meses de datos para analizar el rendimiento de distintas bases de datos sobre distintos tama˜nos de muestras. En en la Tabla 5.5 podemos ver el n´umero de registros de mediciones que contendr´a cada tama˜no del conjunto de datos. Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses N´umero de registros 21348 98292 316488 517285 Tabla 5.5: N´umero de registros para cada tama˜no de datos 37 6.1. BASES DE DATOS UTILIZADAS Agregados continuos: teniendo en cuenta el volumen y la velocidad de crecimiento de las series temporales, esta base de datos presenta el concepto de vista agregada continua que permite realizar c´alculos agregados en los datos de manera eficiente. Las agregaciones se mantienen autom´aticamente y se actualizan a medida que llegan nuevos datos para evitar realizar c´alculos sobre toda la tabla en tiempo real reduciendo los tiempos de respuesta. En cuanto a la organizaci´on de los datos TimescaleDB organiza las series temporales utilizando los siguientes recursos[55]: Tablas: son la base del esquema de datos, se pueden crear las tablas que sean necesarias y transformarlas en las hipertablas mencionadas anteriormente. Cada tabla representar´a una entidad espec´ıfica como pueden ser registro de eventos o de mediciones. En nuestro caso, contaremos con una tabla normal para almacenar datos b´asicos de los analizadores de red as´ı como la unidad de medida en la que realizan las lecturas o informaci´on b´asica y una hipertabla para almacenar los registros de los sensores. Columnas: cada tabla tendr´a un n´umero de columnas en funci´on de los atributos que queramos almacenar acerca de los datos. Estas podr´an ser de diferentes tipos de datos, desde cadenas hasta datos en formato tiempo o datos num´ericos. En nuestro proyecto necesitaremos contar con atributos como el identificador del sensor, la unidad de medida del sensor, informaci´on general, la medici´on, la validez de la medici´on y la marca de tiempo. ´ Indices: la base de datos indexa por defecto las series temporales en funci´on del atributo tiempo pero TimescaleDB nos da la posibilidad de crear nuevos´ındices aparte de ´este para mejorar el rendimiento de las consultas en la b´usqueda y recuperaci´on de los datos que deseemos. Podemos crear ´ındices compuestos por cualquier n´umero de columnas, siempre que se incluya la columna con la marca de tiempo. Claves primarias y restricciones: al igual que en SQL podemos definir una o m´as claves primarias para identificar inequ´ıvocamente una fila dentro de una tabla y poder acceder a los datos de forma eficiente. Adem´as, podemos fijar condiciones para los datos que vamos a almacenar asegurando la integridad y coherencia de nuestros datos. Vistas: cuando se habla de vistas, la base de datos hace referencia a consultas almacenadas que pueden tratarse como tablas virtuales creadas sobre subconjuntos de los datos. Esto est´a relacionado con las agregaciones continuas que utilizan y actualizan estas vistas en segundo plano, actuando ´unicamente sobre los nuevos datos y no sobre todo el conjunto. En lo relacionado con las consultas de datos aparte de utilizar PostreSQL, TimescaleDB proporciona caracter´ısticas adicionales para ayudar con el an´alisis de datos[53]: Optimizador SkipScan para consultas que utilizan DISTINCT en TimescaleDB 2.2.1 y posteriores, optimizando las consultas que pretenden encontrar valores ´unicos en los datos saltando incrementalmente de un valor ordenado al siguiente sin necesidad de leer todos los ´ındices como hace PostreSQL nativo. 44 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON Hiperfunciones que permiten analizar datos de series temporales y obtener informaci´on significativa. Estas, algunas incluidas por defecto en la base de datos y otras accesibles a trav´es de la extensi´on Timescale Toolkit, est´an dise˜nadas para trabajar con el concepto de hipertabla y buscan sacar la m´axima utilidad de SQL permitiendo realizar consultas cr´ıticas sobre los datos y funciones como rellenar datos que faltan, interpolaciones o realizar c´alculos avanzados. Canalizaciones de funciones que transforman la programaci´on funcional en consultas SQL. El elemento m´as importante dentro de una canalizaci´on es un tipo de datos personalizado denominado ‘vector temporal’ sobre el que los dem´as elementos (transformadores y finalizadores) act´uan para crear la consulta deseada. En ocasiones se quiere mantener un hist´orico de los datos, pero otras veces en las aplicaciones de series temporales los datos pierden utilidad a medida que pasa el tiempo por lo que se ofrece la posibilidad de establecer pol´ıticas de retenci´on para eliminar determinados segmentos o datos completos, manteniendo res´umenes de ellos pero reduciendo el tama˜no de datos antiguos. A la hora de insertar datos en TimescaleDB podremos hacerlo a trav´es de herramientas de terceros, a trav´es de consultas de inserci´on t´ıpicas en SQL o bien mediante ficheros en formato CSV o JSON. TimescaleDB es utilizado por empresas como Zondax, para proyectos de blockchain y servicios financieros, Conserv, para almacenar datos de sensores y monitorizaci´on de series temporales, o Edeva, encargada de crear soluciones para ciudades inteligentes que utiliza esta base de datos para agilizar las consultas sobre su gran volumen de datos. 6.1.3. OpenTSDB OpenTSDB[31] (Open Time Series Database) es una base de datos temporal distribuida y escalable de c´odigo abierto, escrita en Java y desarrollada en el a˜no 2010 por Benoit Sigoure para monitorizar las m´etricas del motor de b´usqueda StumbleUpon. El modelo de datos implementado por OpenTSDB se basa en una estructura de la serie de tiempo como dos o m´as puntos de datos que registran una medida en un momento determinado a lo largo del tiempo y que est´a formado por los siguientes elementos: Metric: la m´etrica hace referencia al nombre de una medida cuantitativa como puede ser las descargas de un archivo en un servidor o la temperatura en una ciudad. El nombre elegido deber´a ser una cadena que no contenga espacios. En nuestro proyecto la m´etrica ser´ıa la energ´ıa medida por los analizadores de red. Value: un valor que represente la medici´on num´erica de la m´etrica dada. En nuestro caso el valor ser´an las mediciones realizadas a lo largo del tiempo por los sensores. Timestamp: ser´a la marca de tiempo en la que se registr´o el valor de la m´etrica. Este deber´a estar en formato de tiempo UNIX, que representa la cantidad de segundos o milisegundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 UTC. 45 6.1. BASES DE DATOS UTILIZADAS Tags: las etiquetas son pares clave-valor que proporcionan los metadatos para identificar y filtrar los puntos de datos de una serie. Las series de tiempo se identificar´an entre s´ı por la combinaci´on de la m´etrica y sus etiquetas. En nuestro caso, tendremos etiquetas para el identificador de cada analizador de red, la unidad de medida del sensor, la validez de la medici´on e informaci´on relevante. OpenTSDB admite en la actualidad Apache HBase[12] como principal backend o arquitectura interna de almacenamiento, la cual es una base de datos no relacional que sigue el modelo de datos clave-valor. En la Figura 6.3a vemos los componentes principales de la arquitectura empleada por HBase: RegionServers es el componente principal y administra una o varias regiones que son rangos contiguos de filas en una tabla. Master es el responsable de administrar el cl´uster de HBase, controlando la asignaci´on de regiones a los RegionServers, el balanceo de carga y la gesti´on de las tablas y los esquemas. HFile formato de archivo utilizado para almacenar datos en el disco. Los HFile est´an formados por bloques de datos comprimidos, organizados en funci´on del tama˜no y del espacio temporal. Memstore como estructura de almacenamiento temporal en memoria utilizada por cada regi´on antes de que se escriban en el disco. WAL como almacenamiento basado en archivos que registra todos los cambios que se realizan sobre los datos en HBase para cada RegionServer. HDFS (Hadoop Distributed File System) encargado de almacenar conjuntos de datos masivos. ZooKeeper que es un servicio de coordinaci´on distribuida para realizar la asignaci´on y bloqueo de regiones y un seguimiento del estado de ´estas, del Master y de otros componentes del sistema. HBase almacena los datos en uno o m´as HFiles y organiza estos en tablas (Figura 6.3b) donde encontramos filas que se identifican un´ıvocamente por su clave de fila (row key) y familias de columnas que afectan a la distribuci´on f´ısica de los datos en el almacenamiento. Todas las filas de una tabla tienen las mismas familias de columnas, identificadas por un nombre de columna (qualifier), aunque una fila no necesita tener datos en todas sus familias. Las celdas de datos se identifican de forma ´unica por una combinaci´on de una clave de fila, una familia de columnas y un nombre de columna y el valor que almacenan est´an versionados por una marca de tiempo. Hbase permite almacenar m´ultiples versiones de una celda, donde cada versi´on tiene una marca de tiempo asociada. OpenTSDB crea una tabla HBase que incluye columnas para la m´etrica, la marca de tiempo, las etiquetas y el valor, y donde la clave de fila se construye a partir de la combinaci´on de la m´etrica y las etiquetas asociadas a los datos de la serie. 46 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON (a) Arquitectura interna (b) Representaci´on de tabla Figura 6.3: Caracter´ısticas de HBase (Fuente: cap´ıtulo 8. Architecture y cap´ıtulo 9. Advanced Usage, respectivamente[12]) Para realizar las consultas[32] en OpenTSDB se utiliza un lenguaje de consulta flexible para extraer, manipular y analizar datos. Para consultar los datos se pueden utilizar herramientas de terceros como Grafana o Bosun, herramientas CLI o a trav´es de la API HTTP. En la Tabla 6.2 se recogen los elementos que puede tener una consulta en OpenTSDB. Par´ametro Tipo de dato Campo Descripci´on Hora de inicio Cadena o n´umero entero Obligatorio Instante inicial al que hace referencia la consulta, puede ser absoluta o relativa. Hora de finalizaci´on Cadena o n´umero entero Opcional Instante final al que hacer referencia la consulta, si no se da se toma la hora actual M´etrica Cadena Obligatorio Nombre completo de la m´etrica dentro del sistema Funci´on de agregaci´on Cadena Obligatorio Funciones matem´aticas para combinar series temporales Filtro Cadena Opcional Filtro de etiquetas para reducir el n´umero de series temporales recogidas en la consulta Subconjunto Cadena Opcional Intervalo o funci´on para reducir el n´umero de puntos de datos devueltos Tasa Cadena Opcional Tasa de cambio, por segundo, para el resultado de la consulta Funciones Cadena Opcional Funciones de manipulaci´on de datos Expresiones Cadena Opcional Funciones de manipulaci´on de datos entre series temporales Tabla 6.2: Componentes de las consultas en OpenTSDB Adem´as de HBase, OpenTSDB tambi´en funciona con otras tecnolog´ıas como Bigtable de Google en la nube o Cassandra. Los datos de series temporales se dividen en porciones que se distribuyen en cl´usteres de nodos de HBase, donde cada porci´on tiene un conjunto de series permitiendo un almacenamiento escalable y eficiente. Por otro lado, OpenTSDB se beneficia de las capacidades de replicaci´on y tolerancia a fallos de HBase para garantizar la disponibilidad de los datos. 47 6.1. BASES DE DATOS UTILIZADAS En esta base de datos, en lo que se refiere a su funcionamiento[2] y que est´a reflejado en la Figura 6.4, el componente principal es el TSD (Time Series Daemon). Los “demonios TSD” son procesos independientes del servidor que se ejecutan en los nodos del cl´uster y se encargan de manejar la escritura y lectura de datos en OpenTSDB. Los usuarios de la TSD no acceden directamente al almac´en de datos, sino que se comunican con ella a trav´es de protocolos de tipo telnet, API HTTP o una interfaz gr´afica integrada. Figura 6.4: Arquitectura de OpenTSDB (Fuente: OpenTSDB) OpenTSDB admite la ejecuci´on de varios TSD para gestionar una ´unica consulta, o lo que tambi´en se conoce como balanceo de carga, que permite la lectura paralela desde HBase para acelerar la obtenci´on de datos. Por otro lado, tambi´en permite escrituras concurrentes sin utilizar bloqueos, haciendo que las escrituras sean idempotentes estableciendo un l´ımite temporal fijo para cada fila de datos. En definitiva, los demonios TSD son los responsables de almacenar, recuperar, procesar y mantener los datos en OpenTSDB asegurando un almacenamiento distribuido, escalable y eficiente. Por ´ultimo, mencionar un aspecto importante dentro de esta base de datos referente a la cardinalidad. En OpenTSDB, la cardinalidad se entiende como el n´umero de valores ´unicos que puede tener un ‘tag’, o etiqueta, en los datos almacenados y tiene mucha importancia en la fase del dise˜no de datos y etiquetas ya que si es alta puede tener un impacto negativo en el rendimiento y en la escalabilidad. Los ´ındices utilizados para acelerar las consultas se basan en las combinaciones de etiquetas y m´etricas, por lo que tener muchas combinaciones resulta en tener muchos ´ındices y con ello aumenta la carga de procesamiento en las consultas. En cuanto a la escalabilidad, si la cardinalidad es alta puede llevar a un mayor consumo de memoria as´ı como incrementar la complejidad en la administraci´on de los datos. Empresas como Kentik, Server Density y Cloud Wiz utilizan los servicios de OpenTSDB. 6.1.4. KairosDB KairosDB[24] es una base de datos de series de tiempo basada en Cassandra, escrita en Java, de c´odigo abierto y desarrollada en el a˜no 2013 por KairosDB Inc. 48 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON A la hora de ofrecer una base de datos de series de tiempo eficiente KairosDB prioriza el rendimiento, utilizando tecnolog´ıas como Apache Cassandra y Apache Lucene para facilitar un acceso r´apido a los datos y consultas eficientes; la escalabilidad, permitiendo la expansi´on horizontal mediante la agregaci´on de nodos con el fin de manejar grandes cargas de trabajo y vol´umenes de datos sin perjudicar el rendimiento; la eficiencia en el almacenamiento, empleando un modelo de datos basado en columnas, t´ecnicas de compresi´on e indexaci´on y la configuraci´on de la granularidad de los datos almacenados; la flexibilidad en las consultas, proporcionando numerosas funciones y operaciones de consulta como agregaciones o filtros por etiquetas; y la facilidad de integraci´on, pudi´endose complementar con otras herramientas o plugins para ampliar las caracter´ısticas de la base de datos. El modelo de datos que sigue KairosDB estructura las series de tiempo de forma similar a la base de datos descrita anteriormente, OpenTSDB. El formato de los datos emplea los siguientes componentes: Metric: la m´etrica hace referencia a un conjunto de series temporales relacionadas, agrupan y organizan los datos en el nivel m´as alto de la base de datos. En nuestro caso ser´a la energ´ıa medida por los analizadores de red del ´area de integraciones del edificio. Datapoints: los puntos de datos representan los valores y marcas de tiempo asociados a una m´etrica en particular. Cada punto de datos hace referencia a una medici´on y se almacena en orden cronol´ogico, en nuestro caso ser´an el valor de energ´ıa medida acompa˜nado de una marca de tiempo con formato de tiempo Unix en segundos o milisegundos. Tags: las etiquetas son pares clave-valor que proporcionan informaci´on adicional de la serie temporal y que sirven para filtrar los datos a la hora de realizar consultas. En nuestro estudio emplearemos estas etiquetas para agregar informaci´on que describe los datos almacenados como el identificador del analizador de red, la unidad de medida de energ´ıa, la validez de la medici´on e informaci´on extra. En cuanto al backend utilizado por esta base de datos nos encontramos con dos posibilidades que son H2 o Cassandra. KairosDB est´a configurado por defecto para utilizar H2 que es una base de datos relacional en memoria y que puede ser utilizada para casos de prueba u ocasiones en las que la escalabilidad no sea un requisito principal. Por otro lado, tenemos Apache Cassandra[3] que nos ofrece escalabilidad, tolerancia a fallos y un mayor rendimiento a la hora de trabajar con macrodatos que ser´a la que utilicemos en este proyecto. KairosDB a trav´es de Cassandra utiliza un modelo de datos basado en filas anchas y columnas para almacenar los datos ligados a la variable tiempo en tablas. Este sistema de almacenamiento subyacente agrupa datos de un per´ıodo de tiempo determinado en cada fila en la fase de escritura y cuanto mayor sea la cantidad de puntos de datos que quepan en una de estas filas mayor ser´a el rendimiento a la hora de consultar los datos. Las familias de columnas que nos podemos encontrar siguiendo este esquema son las siguientes: ‘data points’: almac´en de datos. 49 6.1. BASES DE DATOS UTILIZADAS ‘row key index’: ´ındice heredado que se utiliza para buscar las filas necesarias en las consultas. ‘row key time index’: ´ındice para saber en que marco temporal se almacena una m´etrica. Facilita la recuperaci´on de datos en consultas que se orientadas a un rango de tiempo espec´ıfico. ‘row keys’: clave de filas para tablas donde se almacenan las m´etricas o clave de partici´on, la cual suele ser la combinaci´on de la m´etrica, la marca de tiempo de la fila y las etiquetas. Esta clave ayuda a distribuir puntos de datos relacionados en diferentes nodos de un cl´uster, es decir, organizan los datos en las tablas de Cassandra. ‘tag indexed row keys’: ´ındice de etiquetas en la clave de filas para facilitar el filtrado de los datos en funci´on de las etiquetas asociadas a la m´etrica. ‘string index’: es utilizado para acelerar la b´usqueda de datos basada en valores de tipo cadena, pudi´endose crear ´ındices espec´ıficos para el valor de una etiqueta. ‘service index’: almac´en de metadatos. ‘spec’: tabla interna que almacena ajustes internos de la base de datos como el ancho de fila, que por defecto son tres semanas pero se puede redefinir, y la granularidad temporal. En lo referente a las consultas en KairosDB cabe destacar los siguientes aspectos[17]: Almacenamiento de etiquetas Cada combinaci´on de etiqueta y valor, para todas las etiquetas asociadas a una m´etrica, se escribir´a en una partici´on separada utilizando la nomenclatura CQL (Cassandra Query Language) y a su vez la clave de partici´on se escribir´a en una tabla de ´ındices de partici´on. Por ejemplo, en nuestro caso para todo el conjunto de datos tendremos cuatro etiquetas con un n´umero determinado de valores que pueden tomar; identificador del analizador con 94 valores, unidad de medida del analizador con 3 valores, validez de la medici´on con 5 valores e informaci´on general con 95 valores; de esta manera tendr´ıamos un total de 132540 particiones. Proceso de las consultas •Fase 1: KairosDB lee el ´ındice de claves de la fila para el periodo de tiempo especificado en la consulta, de esta manera procesar´a todos los ´ındices que haya en las particiones (tres semanas por defecto) que se quieren consultar. En esta fase, la cardinalidad de las combinaciones de etiqueta y valor repercutir´a en la eficiencia de las consultas al tener que leer un mayor o menor n´umero de claves de ´ındices de partici´on. •Fase 2: KairosDB una vez haya obtenido los datos, los filtrar´a si se han incluido etiquetas en la consulta. En esta fase, la cardinalidad mencionada s´olo afectar´a a la eficiencia de la consulta si no se filtran los datos. M´etricas sobre consultas e ´ındices KairosDB define m´etricas internas que pueden utilizarse para saber que parte de las consultas toma m´as tiempo para poder tomar decisiones sobre c´omo organizar los datos para 50 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON almacenarlos. Estas son mostradas cada vez que se realiza una consulta al backend y se puede realizar operaciones con ellas para conseguir informaci´on m´as espec´ıfica. Por ejemplo, tendr´ıamos ‘kairosdb.datastore.query time’ que mide el tiempo que se tarda en procesar la consulta sin incluir agregaciones de datos o ‘kairosdb.datastore.cassandra.key query time’ que mide el tiempo que se tarda en consultar la informaci´on de la clave de fila, con respecto a estas dos m´etricas podr´ıamos obtener el tiempo de lectura de datos de Cassandra rest´andolas. A la hora de escribir consultas en esta base de datos lo haremos mediante una consulta con formato JSON enviada a la base de datos utilizando una REST API[50]. La consulta m´as b´asica que podremos realizar tendr´a que contar obligatoriamente con los siguientes par´ametros: time expr: el rango de tiempo que se quiere consultar puede expresarse de tres maneras: relativa (5d ago, 1h ago, etc), absoluta (milisegundos en formato de tiempo UNIX) o especial para hacer referencia a la actualidad como instante final de consulta (now). metric expr: contiene el nombre de la m´etrica que se quiere consultar y una condici´on de etiqueta que es opcional. Se definir´ıa de la siguiente manera: Luego se podr´an a˜nadir otros campos a mayores para modelar el conjunto de datos que deseamos obtener, como por ejemplo: condition expr: filtra los datos en funci´on de los valores de etiquetas que se incluyan en la consulta y se escribir´a como ‘tagX = valX’. aggregation expr: para realizar funciones de agregaci´on sobre los datos consultados, por ejemplo ‘sum(1d)’ para obtener el sumatorio de los datos en un d´ıa o ‘avg(1d)’ para conseguir el promedio diario. Es importante destacar que esta base de datos necesita que le proporcionen el tama˜no en el que muestrear los datos, es decir, si se quiere obtener la media de los datos almacenados habr´a que especificar el rango en el que tiene que dividir los datos, aceptando por rango m´as alto el de un a˜no. group expr: para agrupar los datos en funci´on de los valores de alguna etiqueta que contenga la m´etrica, definido como ‘tags : tagX ’. Una de las funcionalidades destacable de KairosDB que tiene como fin mejorar el rendimiento de las consultas es la posibilidad de crear “rollups” que se utilizan para crear res´umenes de datos variando la granularidad temporal y aplicando funciones de agregaci´on. Los “rollups” realizan consultas sobre los datos, aplican funciones y escriben los resultados en otra m´etrica manteniendo los datos originales. Estos se programan creando una tarea que tiene uno o varios “rollups” y una frecuencia de ejecuci´on. Empresas como Proofpoint, dedicada a la seguridad empresarial ofreciendo software para la prevenci´on de la p´erdida de datos, Zalando, dedicada a la venta online de diversos productos, o Abiquo, plataforma de software de computaci´on en la nube, utilizan los servicios que ofrece KairosDB. 51 6.2. DISE ˜ NO DEL CASO DE ESTUDIO 6.2. Dise˜no del caso de estudio En el dise˜no de nuestro caso de estudio tenemos por un lado que ocuparnos de los datos presentados en la Secci´on 5 y por consiguiente, determinar la arquitectura de almacenamiento que se emplea en cada base de datos para poder modelar los datos y adaptar el dise˜no del caso de estudio a cada una de ellas. Por otro lado, tenemos que hacer frente al almacenamiento de los resultados de los experimentos que se explican en la Secci´on 7. El SGBD que utilizaremos ser´a PostgreSQL que es un sistema de gesti´on de bases de datos relacional robusto, de c´odigo abierto y ampliamente utilizado. Siguiendo el modelo l´ogico de la base de datos mostrado en la Figura 6.5 definimos seis tablas para almacenar informaci´on relevante de las pruebas de rendimiento que llevaremos a cabo. Figura 6.5: Modelo l´ogico de la base de datos PostgreSQL (Figura de elaboraci´on propia) Para cada experimento, la tabla ‘m data’ guardar´a el tiempo de carga en milisegundos de diferentes tama˜nos de conjuntos de datos de series temporales y la tabla ‘m space’ registrar´a en megabytes el tama˜no del archivo de datos as´ı como el tama˜no de almacenamiento necesario para almacenar en cada base de datos dichos conjuntos. A su vez, decidimos tener una tabla ‘m query’ por cada tama˜no del conjunto de datos ya 52 CAP´ ITULO 6. DISE ˜ NO E IMPLEMENTACI ´ ON que de esta forma resulta m´as c´omodo el acceso a los datos de cada experimento ya que contamos con muchas columnas para definir otros par´ametros importantes de las pruebas aunque se podr´ıan fusionar en una ´unica tabla. Estas tablas reunir´an informaci´on perteneciente al tiempo que toma ejecutar diferentes consultas en cada base de datos con el fin de analizar c´omo var´ıa el rendimiento con el tama˜no de los conjuntos de datos y con el n´umero de variables (identificadores de analizadores de red) solicitadas en dichas consultas. El atributo ‘type q’ identifica el tipo de consulta realizada como ‘ep’ (exact point) para la consulta de una marca de tiempo determinada, ‘agg’ (aggregation) para las consultas anal´ıticas b´asicas, ‘gb’ (group by) para las consultas de agrupaci´on y ‘tr’ (time range) para las consultas que aplican rangos de tiempo. Adem´as, el atributo ‘size q’ nos permite diferenciar dentro de los dos ´ultimos tipos de consultas el rango temporal de agrupaci´on o de consulta que estamos abarcando. La implementaci´on del caso de estudio en InfluxDB se hace aplicando un modelo basado en pares clave-valor. Para la implementaci´on del caso de estudio en TimescaleDB, seguimos un modelo relacional y como puede verse en la Figura 6.6, definimos una tabla para los identificadores con alguna informaci´on adicional y una hipertabla para guardar los datos temporales. Como ya se explic´o anteriormente el concepto de hipertabla en esta base de datos nos permite segmentar los datos en funci´on del tiempo y aprovechar dicha arquitectura para optimizar el almacenamiento. Adem´as, definimos un ´ındice sobre la columna del identificador en la hipertabla con el fin de aprovechar las oportunidades que nos da esta base de datos para mejorar el rendimiento de las consultas. Figura 6.6: Modelo entidad-relaci´on para TimescaleDB (Figura de elaboraci´on propia) La implementaci´on del caso de estudio en OpenTSDB se hace utilizando una arquitectura basada en HBase que aplica un modelo basado en pares clave-valor. La implementaci´on del caso de estudio en KairosDB se consigue utilizando un modelo basado en colecciones de columnas y pares clave-valor que surge de la arquitectura manejada por Cassandra en su backend. 53 7.2. RESULTADOS Figura 7.1: Gr´afico de barras para los tiempos de carga de datos En base a estos resultados y teniendo en cuenta que estamos comparando tres bases de datos NoSQL y una relacional (TimescaleDB), podemos ver que hay grandes diferencias entre ambos modelos de bases de datos y en t´erminos de rendimiento de carga nos decantar´ıamos por una base de datos relacional ya que es medio orden de magnitud mejor que las dem´as. Dentro de las NoSQL InfluxDB obtiene tiempos competitivos, sobre todo para tama˜nos de conjunto de 3 y 13 meses, con respecto a OpenTSDB y KairosDB pero no frente a TimescaleDB. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. 7.2.2. Tama˜no de almacenamiento La segunda m´etrica que examinaremos ser´a la del espacio que ocupan los datos tras ser insertados en las bases de datos. Los resultados obtenidos en las pruebas de rendimiento los desglosaremos en tres tablas. Por un lado, la Tabla 7.3 nos muestra el tama˜no consumido por los datos medido en megabytes en su formato original (XLSX) y en los archivos adaptados a cada base de datos (JSON). De esta forma podemos analizar el coste que supone la transformaci´on de los datos a un formato JSON debido a los campos espec´ıficos necesarios para la correcta inserci´on en cada base de datos. Vemos que todas las bases de datos consumen m´as espacio a nivel de JSON pero en el caso de TimescaleDB obtenemos el menor coste de transformaci´on con gran diferencia y el peor con InfluxDB. 60 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses XLSX 0.608 2.757 8.821 14.391 JSON InfluxDB 8.073 37.116 119.438 195.261 JSON TimescaleDB 6.770 31.116 100.121 163.688 JSON OpenTSDB 7.401 34.022 109.478 178.981 JSON KairosDB 7.809 35.897 115.514 188.847 Tabla 7.3: Espacio consumido por los archivos (MB archivo original vs. MB archivo adaptado) Por otro lado, podemos tambi´en comparar el tama˜no del archivo original con el tama˜no de cada base de datos utilizando la Tabla 7.4 y ver que, KairosDB nos ofrece unos consumos de espacio un poco mayores pero muy similares al espacio que ocupan los datos del archivo original para casi todos los tama˜nos del conjunto de datos. Tambi´en resalta que TimescaleDB es la que peor se comporta ofreciendo unos consumos de espacio muy altos en comparaci´on con el tama˜no de los datos en bruto y con el resto de bases de datos. Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses XLSX 0.608 2.757 8.821 14.391 InfluxDB 1.593 4.696 12.054 18.671 TimescaleDB 13.788 26.930 64.205 98.403 OpenTSDB 2.084 10.751 32.105 43.816 KairosDB 1.816 4.129 9.786 14.957 Tabla 7.4: Eficiencia de almacenamiento (MB archivo original vs. MB base de datos) Por ´ultimo, podemos definir el factor de compresi´on de datos[40] como el cociente del tama˜no de entrada dividido por el tama˜no de salida, cuyo resultado si es menor que 1 implica que se ha producido una expansi´on y cu´anto mayor sea de 1 ser´a que la compresi´on es mejor: Factor de Compresi´on = Tama˜no JSON Tama˜no Base de Datos En t´erminos de rendimiento del consumo de espacio analizamos el factor de compresi´on de cada base de datos y nos encontramos con que, a partir de los datos de la Tabla 7.5, obtenemos factores de compresi´on bastante buenos y parecidos entre InfluxDB y KairosDB, siendo este ´ultimo el que mejor resultados nos ofrece. TimescaleDB presenta las peores tasas de compren- si´on de datos, ya que como vemos en la tabla para el conjunto de datos de 3 meses se produce una expansi´on (los datos duplican su tama˜no al insertarse) y aunque parece que mejora y si se comprimen los datos a medida que el volumen de estos aumenta no consigue hacer competencia a las dem´as bases de datos. 61 7.2. RESULTADOS Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses JSON InfluxDB 8.073 37.116 119.438 195.261 InfluxDB 1.593 4.696 12.054 18.671 Factor compresi´on InfluxDB 5.1 7.9 9.9 10.5 JSON TimescaleDB 6.770 31.116 100.121 163.688 TimescaleDB 13.788 26.930 64.205 98.403 Factor compresi´on TimescaleDB 0.5 1.2 1.6 1.7 JSON OpenTSDB 7.401 34.022 109.478 178.981 OpenTSDB 2.084 10.751 32.105 43.816 Factor compresi´on OpenTSDB 3.5 3.2 3.4 4.1 JSON KairosDB 7.809 35.897 115.514 188.847 KairosDB 1.816 4.129 9.786 14.957 Factor compresi´on KairosDB 4.3 8.7 11.8 12.6 Tabla 7.5: Factor de compresi´on (MB archivo adaptado vs. MB base de datos) En base a estos resultados, podemos destacar que las bases de datos NoSQL se comportan mucho mejor que la base de datos relacional en cuanto a la compactaci´on de datos se refiere. En general, podr´ıamos decir que la mejor opci´on es KairosDB, seguido de InfluxDB, Open- TSDB y TimescaleDB. Esta ´ultima nos ofrec´ıa unos tama˜nos de archivo JSON muy reducidos en comparaci´on con las dem´as pero no es un precio que se deba pagar si el resultado va a ser una base de datos que ocupe mucho y que no comprima de forma eficiente los cientos de miles de datos que va a almacenar. 7.2.3. Latencia en las consultas La tercera m´etrica que estudiaremos ser´a la de la velocidad de respuesta de diferentes tipos de consultas basadas en rangos de tiempo, funciones de agregaci´on o agrupaciones en las distintas bases de datos que tenemos. Es importante se˜nalar y tener en cuenta antes de analizar los resultados que, como reflej´abamos en la Tabla 7.1, hay bases de datos que al realizar algunas de las consultas que desarrollaremos a continuaci´on presentan las siguientes peculiaridades: KairosDB: para las consultas anal´ıticas en las que cuenta con todos los datos tiene que muestrear el conjunto de datos antes de aplicar la funci´on de agregaci´on y el m´aximo rango posible es de un a˜no, es decir en nuestro caso mientras que otras bases de datos nos ofrecen una media para el conjunto de datos, KairosDB nos dar´a dos medias, una por cada a˜no, para las mediciones de cada a˜no diferente presente en el conjunto de datos. Adem´as, la consulta en la que se obtiene el conteo de los datos, KairosDB devuelve el n´umero de veces que cada medici´on est´a presente en el conjunto pero sin devolvernos el sumatorio, por lo que hay que realizarlo posteriormente. OpenTSDB: para las consultas anal´ıticas en las que calcula la media o la desviaci´on est´andar presenta peque˜nas diferencias de c´alculo por el m´etodo utilizado con respecto a las dem´as bases de datos. 62 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Consulta de punto exacto Al realizar la consulta para recuperar la medici´on asociada a una marca de tiempo concreta, como vemos en la Tabla 7.6 el claro ganador es TimescaleDB con unos tiempos de respuesta muy inferiores al resto. Si hablamos de los peores resultados entonces nos encontramos con que para los cuatro experimentos realizados InfluxDB, OpenTSDB y KairosDB empatan en el recuento de peores casos. InfluxDB comienza con unos tiempos que podr´ıan ser aceptables y que parece que escalan linealmente a medida que se aumenta el tama˜no y el n´umero de variables consultadas, pero para grandes conjuntos de datos a partir de 5 variables consultadas se produce un aumento brusco de los tiempos de respuesta que llegan a superar por mucho a las dem´as como podemos ver en color rojo para un tama˜no de 13 meses en la Figura 7.2. OpenTSDB y KairosDB vemos que tienen un comportamiento similar con unos tiempos de consulta similares y relativamente uniformes. Figura 7.2: Gr´afico de barras para la consulta 1 (punto exacto) Si nos enfocamos en el n´umero de variables consultadas no encontramos una relaci´on clara entre tiempo de respuesta y n´umero de variables ya que hay bases de datos como TimescaleDB e InfluxDB que con excepciones presentan un aumento esperable de la latencia de consulta frente al aumento del n´umero de variables, pero hay otras como OpenTSDB que presentan una relaci´on inversa entre estos dos criterios. 63 7.2. RESULTADOS En base a estos resultados y para la consulta de obtener una medici´on de un punto exac- to, nos decantar´ıamos por el modelo relacional ya que las diferencias en este caso con el modelo NoSQL es bastante grande. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de KairosDB, OpenTSDB e InfluxDB. Aclarar que le damos el tercer lugar a OpenTSDB ya que consideramos que es preferible tener unos tiempos de respuesta m´as o menos constantes antes que obtener unos resultados muy buenos solo bajo determinadas condiciones como es el caso de InfluxDB para esta consulta. Consulta de agregaci´on: M´ınimo Al realizar la consulta para obtener el m´ınimo de las mediciones de energ´ıa, como muestra la Tabla 7.7 TimescaleDB nos da los mejores tiempos. En esta ocasi´on, nos encontramos con dos bases de datos que son candidatas a obtener el peor puesto y que podemos ver en la tabla, OpenTSDB y KairosDB. Tanto en la tabla como en la Figura 7.3 vemos que ambas presentan un factor de crecimiento geom´etrico y que ambas cuando se trata de conjuntos de datos reducidos se comportan de forma an´aloga. OpenTSDB se lleva el puesto de la peor en esta consulta ya que tiene 7/12 casos peores frente a los 5/12 de KairosDB y se aprecia que cuando m´as o menos duplica el tama˜no del conjunto (pasando de 6 a 13 meses) casi se cuadruplica la latencia de esta consulta. Figura 7.3: Gr´afico de barras para la consulta 2 (m´ınimo) Si nos enfocamos en el n´umero de variables consultadas todas las bases de datos presentan 64 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS un aumento esperable de la latencia de consulta frente al aumento del n´umero de variables consultadas. En base a estos resultados, podemos decir que la base de datos de nuestras opciones que sigue un modelo relacional es la que mejor se comporta. Las opciones NoSQL son much´ısimo peores aunque los resultados de InfluxDB ser´ıan aceptables siendo en ocasiones similares a la base de datos relacional. aunque si que es verdad que en este caso si lo comparamos con una de las opciones NoSQL no se ven grandes diferencias como en otras ocasiones. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. Consulta de agregaci´on: M´aximo Al realizar la consulta para obtener el m´aximo de las mediciones de energ´ıa, como muestra la Tabla 7.8 TimescaleDB es la mejor opci´on y con bastante diferencia de cara a las dem´as bases de datos. En la Figura 7.4 vemos que los peores tiempos de respuesta los consigue OpenTSDB con el mayor recuento de casos peores y con unos resultados que escalan por encima de la linealidad triplic´andose los tiempos de respuesta al duplicarse el tama˜no del conjunto. KairosDB tambi´en presenta malos resultados para el tama˜no m´as peque˜no del conjunto de datos en comparaci´on con las dem´as, pero despu´es se estabiliza y la latencia de consulta va aumentando seg´un lo esperable aunque igualmente de forma muy superior a TimescaleDB e InfluxDB. Figura 7.4: Gr´afico de barras para la consulta 3 (m´aximo) 65 7.2. RESULTADOS Si nos enfocamos en el n´umero de variables consultadas todas las bases de datos presentan un aumento esperable de la latencia de consulta frente al aumento del n´umero de variables consultadas. Como era de esperar las consultas sobre m´aximo y m´ınimo obtienen similares rendimientos en todas las bases de datos y, por lo tanto, las conclusiones son las mismas que en el apartado anterior. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. 66 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Tam. del conjunto de datos 3 meses 6 meses 10 meses 13 meses Nºde variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 16.187 24.123 62.236 29.614 87.771 188.515 96.904 310.859 580.922 198.415 406.773 997.282 TimescaleDB 1.917 1.907 2.453 2.606 3.199 3.449 2.663 3.325 4.084 2.800 4.476 3.35 OpenTSDB 224.123 210.795 190.596 171.280 174.485 189.172 197.927 218.274 208.694 200.946 195.964 214.362 KairosDB 278.906 193.006 172.293 180.504 206.403 237.975 190.404 171.495 172.516 155.939 187.514 159.285 Tabla 7.6: Tiempos para obtener la medici´on de un d´ıa y hora determinadas (en milisegundos) T. del conjunto de datos 3 meses 6 meses 10 meses 13 meses Nºde variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 9.155 14.606 27.761 11.305 18.291 32.816 16.251 28.714 52.277 22.691 30.288 97.612 TimescaleDB 3.929 3.824 5.550 9.339 16.293 22.383 11.803 23.499 42.863 15.542 41.072 63.609 OpenTSDB 158.499 153.514 229.748 240.831 490.021 735.557 759.105 792.984 1056.082 971.593 1238.801 1791.297 KairosDB 236.530 240.902 288.396 350.312 327.290 599.491 498.287 602.557 1276.288 453.367 620.782 1066.815 Tabla 7.7: Tiempos para obtener el m´ınimo de las mediciones (en milisegundos) T. del conjunto de datos 3 meses 6 meses 10 meses 13 meses Nºde variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 9.162 13.106 28.120 9.129 17.580 35.913 13.565 27.697 52.268 19.540 30.498 80.418 TimescaleDB 1.621 2.323 3.216 4.123 10.246 15.083 4.725 15.412 32.430 7.043 19.670 36.890 OpenTSDB 78.757 108.056 100.073 287.567 436.460 273.589 407.132 482.844 626.799 785.268 890.066 1220.362 KairosDB 142.497 113.147 195.960 143.389 219.723 292.518 316.793 321.322 457.044 158.497 304.797 626.683 Tabla 7.8: Tiempos para obtener el m´aximo de las mediciones (en milisegundos) 67 7.2. RESULTADOS Consulta de agregaci´on: Media aritm´etica Al realizar la consulta para obtener la media aritm´etica de las mediciones de energ´ıa, como muestra la Tabla 7.9 TimescaleDB nos brinda los mejores resultados con diferencia. Tanto en la tabla como en la Figura 7.5 queda claro que los peores resultados pertenecen a OpenTSDB, obtiene un recuento de peores casos de 9/12, ocurriendo un poco lo que pasaba en la consulta anterior ya que los tiempos se disparan al aumentar el tama˜no del conjunto. En este caso, KairosDB tambi´en tiene malos resultados para el tama˜no del conjunto de datos m´as peque˜no aunque su crecimiento a partir de un tama˜no de 6 meses es mucho m´as lento que el que experimenta OpenTSDB. Figura 7.5: Gr´afico de barras para la consulta 4 (media aritm´etica) Si nos enfocamos en el n´umero de variables consultadas todas las bases de datos presentan un aumento esperable de la latencia de consulta frente al aumento del n´umero de variables consultadas. En base a los resultados obtenidos, el modelo relacional resulta la mejor opci´on ya que al igual que en los dos casos anteriores cu´ando se necesita recorrer todos los valores del conjunto de datos los rendimientos son similares. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. 68 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Consulta de agregaci´on: Desviaci´on est´andar Al realizar la consulta para obtener la desviaci´on est´andar de las mediciones de energ´ıa, como muestra la Tabla 7.10 TimescaleDB nuevamente nos brinda los mejores resultados con diferencia del resto de bases de datos. OpenTSDB es la que peores resultados nos ofrece ya que son latencias de consulta mucho m´as lentas que el de las dem´as bases de datos. KairosDB, al igual que en otras consultas, repite el mismo comportamiento ya que a partir de un tama˜no de conjunto de 6 meses los tiempos se estabilizan y crecen dentro de lo esperable en la l´ınea que sigue esta base de datos. Si nos enfocamos en el n´umero de variables consultadas por lo general todas las bases de datos presentan un aumento esperable de la latencia de consulta frente al aumento del n´umero de variables consultadas como podemos observar en la Figura 7.6. Figura 7.6: Gr´afico de barras para la consulta 5 (desviaci´on est´andar) En base a los resultados obtenidos y como era de esperar obtenemos resultados id´enticos a las 3 consultas anteriores d´onde una vez m´as el modelo relacional es el que ofrece mejores resultados y dentro de los modelos NoSQL con los que contamos vemos que InfluxDB se comporta bastante bien pero que las otras dos bases de datos que aplican este modelo sobrepasan muy por encima los resultados de sus competidores. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. 69 7.2. RESULTADOS Figura 7.11: Gr´afico de barras para la consulta 8 3 (meses) 76 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS T. del conjunto de datos 3 meses 6 meses 10 meses 13 meses Nºde variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 15.535 33.812 96.264 194.116 664.757 2123.679 566.894 2580.693 7510.281 989.995 3855.499 13485.565 TimescaleDB 2.165 2.819 5.396 6.127 9.318 27.988 8.917 33.129 67.773 10.960 45.532 88.782 OpenTSDB 7 KairosDB 7 Tabla 7.12: Tiempos para obtener los valores ´unicos de las mediciones (en milisegundos) T. del conjunto de datos 3 meses 6 meses 10 meses 13 meses Nºde variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 45.727 206.787 777.724 274.166 981.002 2571.975 747.082 2649.016 7277.769 1111.250 4511.920 11245.812 TimescaleDB 3.025 5.179 18.810 7.807 23.641 44.369 14.161 76.099 157.194 19.310 99.519 240.863 OpenTSDB 69.268 77.926 88.810 214.152 263.323 382.206 340.135 585.254 681.249 516.176 703.493 1117.215 H. KairosDB 136.273 201.885 127.616 119.251 106.823 329.774 129.131 213.476 426.405 162.253 329.650 645.463 InfluxDB 12.715 29.345 87.396 54.197 102.897 265.919 88.245 288.219 828.281 143.345 569.711 1091.333 TimescaleDB 1.870 2.702 8.683 5.634 16.311 20.952 11.051 39.197 57.360 16.121 52.956 104.160 OpenTSDB 101.842 70.943 125.888 130.619 194.117 204.770 281.685 449.023 555.888 532.062 674.170 943.284 S. KairosDB 126.337 98.999 196.431 91.556 123.885 222.251 94.342 144.389 279.671 250.902 186.387 368.793 InfluxDB 14.473 19.663 60.188 43.947 96.110 209.467 108.011 265.938 595.696 122.159 512.015 942.065 TimescaleDB 1.212 2.225 6.299 7.777 11.114 16.564 11.636 25.455 43.141 13.053 33.904 72.103 OpenTSDB 39.528 54.638 90.488 140.888 137.429 242.396 277.439 470.951 518.373 462.740 585.547 803.111 M. KairosDB 120.762 75.450 98.087 79.721 118.950 156.989 77.556 134.103 205.703 101.020 150.909 420.319 Tabla 7.13: Tiempos para obtener la media de las mediciones tras agrupar en rangos de tiempo (en milisegundos) 77 7.2. RESULTADOS Consulta de agrupaci´on: Intervalos de outliers o tercer cuartil Al realizar esta consulta, es necesario aclarar que estaba pensada desde un principio para conseguir intervalos de tiempo donde las mediciones de energ´ıa no estuviesen en un rango definido, es decir el objetivo era poder conseguir con una consulta aquellas mediciones y marcas de tiempo asociadas que nos informasen de un mal comportamiento del analizador de red seleccionado. Como se puede ver en la Tabla 7.14, una vez que comenzamos a trabajar con las diferentes bases de datos pudimos comprobar que la consulta inicial s´olo era capaz de realizarla TimescaleDB as´ı que para las dem´as bases de datos llegamos hasta donde nos permit´ıa cada una. Obviamente TimescaleDB es la que mejor rendimiento nos ofrece completando la consulta y arrojando buenos tiempos. Para comparar las dem´as bases de datos contamos con la Figura 7.12 en las que realizamos una consulta para conseguir el tercer cuartil utilizado por el m´etodo del rango intercuart´ılico[41] para obtener intervalos de valores at´ıpicos. InfluxDB es la que mejores tiempos nos ofrece en comparaci´on con las dem´as y OpenTSDB la que peor obteniendo 8/12 peores casos. Figura 7.12: Gr´afico de barras para la consulta 9 (tercer cuartil) Vemos que las tres bases de datos presentan una latencia de consulta con un crecimiento exponencial que es m´as acentuado en OpenTSDB. Por otro lado, si nos enfocamos en el n´umero de variables consultadas nos encontramos en la Tabla 7.14 con que todas las bases de datos presentan un aumento l´ogico de la latencia de consulta al aumentar el n´umero de variables consultadas. 78 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS En base a los resultados obtenidos, podr´ıamos decir que el modelo relacional nos ofrece mejores resultados que el modelo NoSQL, ya que este ´ultimo no nos ha permitido realizar la consulta deseada. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de InfluxDB, KairosDB y Open- TSDB. Consulta de rangos de tiempo: Un d´ıa, m´as de un d´ıa, un mes y m´as de un mes Una de las consultas esenciales en el ´ambito de los datos de series temporales es la de recuperar datos a partir de intervalos temporales espec´ıficos. Con la intenci´on de ver como afecta la variaci´on temporal de los rangos en las distintas bases de datos decidimos establecer consultas para cuatro rangos de tiempo diferentes cuyos resultados podemos encontrar en la Tabla 7.15. En la Figura 7.13 podemos ver los resultados de la consulta que solicita las mediciones de energ´ıa para el periodo de un d´ıa completo. La mejor base de datos en esta consulta es TimescaleDB con tiempos casi constantes de uno o dos milisegundos tanto con el aumento del tama˜no del conjunto de datos como con el del n´umero de variables consultadas. KairosDB es la que peores tiempos de respuesta arroja superando en gran medida a sus competidores adem´as de presentar un comportamiento muy irregular y tambi´en destaca que InfluxDB parece ser sensible al aumento del n´umero de variables consultadas ya que sus tiempos al aumentar el tama˜no del conjunto no cambian mucho pero si nos fijamos en la gr´afica al pasar de 1 a 5 y a 20 variables los tiempos se disparan. En la Figura 7.14 observamos los tiempos de latencia tras ampliar un poco el rango de tiempo con respecto a la consulta anterior, en este caso queremos recuperar mediciones de energ´ıa en el periodo de tiempo de un d´ıa y unas horas del d´ıa siguiente. La mejor base de datos en esta consulta es TimescaleDB y podemos ver una mejor´ıa de los tiempos en relaci´on con la anterior consulta. KairosDB repite como la base de datos que peores tiempos nos ofrece pero en este caso, como refleja tambi´en la Tabla 7.15, los tiempos no presentan un crecimiento brusco en relaci´on con aumento del n´umero de variables consultadas. En la Figura 7.15 vemos los resultados de la consulta que solicita las mediciones de energ´ıa para el periodo de un mes completo. TimescaleDB contin´ua siendo la mejor opci´on aunque para este rango de tiempo parece que influye m´as el n´umero de variables solicitadas en la latencia de la consulta, adem´as de presentar un comportamiento extra˜no cuando se trata de 20 variables ya que al aumentar el tama˜no del conjunto los tiempos de consulta se reducen y es algo que no ocurre para 1 o 5 variables. Para esta consulta la base de datos que peor se comporta es InfluxDB con tiempos similares al resto de bases de datos cuando se solicita una variable pero muy superiores al resto para el resto de casos, d´onde se ve que los tiempos de latencia escalan geom´etricamente al aumentar el n´umero de variables consultadas. Por ´ultimo, contamos con la consulta con la que recuperamos los datos para un rango temporal de un mes y unas semanas. En la Figura 7.16 podemos observar que TimescaleDB es la mejor y sigue mostr´andose sensible en cuanto al n´umero de variables consultadas a medida que crece el periodo de tiempo consultado. InfluxDB repite como la peor base de datos para esta consulta ya que nos ofrece unos tiempos de respuesta muy altos y muy dispares con respecto a las dem´as. 79 7.2. RESULTADOS Figura 7.13: Gr´afico de barras para la consulta 10 1 (1 d´ıa exacto) Figura 7.14: Gr´afico de barras para la consulta 10 2 (1 d´ıa y unas horas) 80 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Figura 7.15: Gr´afico de barras para la consulta 10 3 (1 mes exacto) Figura 7.16: Gr´afico de barras para la consulta 10 4 (1 mes y unas semanas) 81 7.2. RESULTADOS Desde un punto de vista general, observando la Tabla 7.15 podemos concluir que TimescaleDB a medida que se amplia el rango de tiempo consultado el n´umero de variables solicitadas repercute de manera significativa en la latencia de consulta, que KairosDB a pesar de ser peor que otras bases de datos en rangos de tiempo peque˜nos mantiene unos tiempos de respuesta m´as estables estables que otras bases de datos aunque muy altos en comparaci´on con la mejor opci´on, que InfluxDB cuando el rango de tiempo es amplio su comportamiento es inaceptable ya que el aumento de los tiempos de respuesta se multiplican por una cifra significativa, y que, OpenTSDB ofrece unos tiempos en general tolerables que experimentan un aumento esperable en relaci´on con el aumento del rango de tiempo consultado, del tama˜no del conjunto y del n´umero de variables consultadas. En base a los resultados obtenidos, el modelo relacional es el que nos ofrece mejores resultados con tiempos inferiores a seis mil´esimas de segundo. Las bases de datos que siguen un modelo NoSQL presentan un comportamiento m´as irregular vi´endose m´as afectadas por los cambios en el n´umero de variables consultadas o en el tama˜no del conjunto, adem´as de ofrecer resultados significativamente superiores. Podr´ıamos decir que la mejor opci´on es TimescaleDB, seguido de OpenTSDB, KairosDB e InfluxDB. Cabe decir que InfluxDB obtiene el ´ultimo puesto a parte de porque presenta 29 casos negativos frente a los 15 de KairosDB, porque produce unos tiempos de latencia exageradamente elevados para cuando se consulta un elevado n´umero de variables. 82 CAP´ ITULO 7. ESTUDIO DE RENDIMIENTO DE BASES DE DATOS Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses N´umero de variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 Consulta completa TimescaleDB 6.705 8.196 12.423 19.601 29.351 56.171 64.222 133.551 116.594 119.464 143.933 263.189 InfluxDB 9.765 11.416 31.920 11.725 36.285 46.788 17.173 28.396 70.066 20.004 46.917 140.185 OpenTSDB 61.645 70.894 87.276 141.806 152.316 234.767 375.337 448.381 569.502 486.821 637.434 833.515 S´olo calculan un cuartil KairosDB 211.940 114.178 264.126 74.548 131.453 238.723 149.569 121.797 332.078 117.420 182.850 445.063 Tabla 7.14: Tiempos para obtener los intervalos de outliers de las mediciones (en milisegundos) Tama˜no del conjunto de datos 3 meses 6 meses 10 meses 13 meses N´umero de variables consultadas 1 5 20 1 5 20 1 5 20 1 5 20 InfluxDB 10.077 13.382 34.574 7.121 17.329 30.798 9.719 13.692 31.780 7.484 15.673 36.337 TimescaleDB 0.851 1.419 1.868 0.915 1.139 1.842 1.095 1.480 1.694 1.191 1.493 1.922 OpenTSDB 6.835 7.676 9.217 7.059 6.887 10.413 6.965 7.665 7.572 13.819 10.077 11.136 1 d´ıa KairosDB 39.701 71.086 24.029 33.177 21.966 25.013 13.442 29.100 45.337 10.967 15.849 18.946 InfluxDB 8.086 14.320 43.805 8.551 16.724 44.572 8.869 16.839 40.279 8.906 21.091 62.284 TimescaleDB 0.620 0.799 1.587 0.691 1.148 2.101 0.780 1.377 1.493 0.896 1.236 1.784 OpenTSDB 7.852 7.048 8.678 8.110 84.960 12.134 14.641 43.671 12.667 7.186 9.169 12.883 M´as de 1 d´ıa KairosDB 32.327 32.192 43.689 23.568 16.966 46.822 13.626 21.100 34.392 9.534 20.807 37.905 InfluxDB 30.124 106.822 341.913 28.452 114.949 459.480 36.989 107.197 336.627 32.813 120.181 329.777 TimescaleDB 0.825 1.748 6.449 1.011 2.012 5.079 1.319 2.290 3.122 1.437 1.694 3.608 OpenTSDB 16.202 21.093 25.861 15.250 23.979 24.310 24.304 51.070 28.751 19.055 18.637 33.781 1 mes KairosDB 85.952 31.691 82.225 23.552 20.112 41.868 22.115 14.767 54.521 15.039 38.670 33.054 InfluxDB 31.279 140.296 332.556 27.434 143.934 352.193 39.088 111.881 537.226 34.960 108.705 318.4629 TimescaleDB 1.066 2.074 6.505 1.207 2.227 4.501 1.343 3.222 4.289 1.297 3.089 5.899 OpenTSDB 17.133 22.571 25.382 15.455 21.789 29.914 16.418 26.244 32.487 15.746 21.676 30.211 M´as de 1 mes KairosDB 52.106 41.823 62.127 25.592 29.272 27.474 24.468 27.224 49.918 12.919 26.419 78.525 Tabla 7.15: Tiempos para obtener las mediciones de diferentes rangos de tiempo (en milisegundos) 83 7.2. RESULTADOS 84 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA Cap´ıtulo 8 Herramienta de visualizaci´on desarrollada 8.1. Definici´on de requisitos Durante la fase de an´alisis antes de implementar nuestro sistema, determinaremos los servicios que este debe proporcionar (requisitos funcionales) y sus limitaciones (requisitos no funcionales). 8.1.1. Requisitos funcionales Los requisitos funcionales enuncian los servicios que debe proporcionar el sistema, estos engloban c´omo deber´ıa reaccionar el sistema ante determinadas entradas o en situaciones espec´ıficas y, en ocasiones, tambi´en lo que no deber´ıa hacer dicho sistema. RF-1 Acceder a los datos guardados Dependencias Ninguna Caracter´ıstica El sistema deber´a ser capaz de acceder a los resultados de las pruebas realizadas Descripci´on El sistema deber´a acceder a los datos solicitados por el usuario para generar una visualizaci´on Interfaz del servicio No Importancia Alta Prioridad Alta Precondici´on El usuario deber´a haber ejecutado el script que realiza las consultas o bien tener los resultados anteriores en una carpeta llamada ‘results’ Postcondici´on Se cargar´an los datos en la visualizaci´on Comentarios Si no se ha ejecutado el script o no existen resultados guardados el sistema informar´a de ello Tabla 8.1: RF-1: Acceder a los datos almacenados 85 8.3. DISE ˜ NO 8.3. Dise˜no En esta secci´on nos centraremos en los aspectos relacionados con el dise˜no de software, decidiremos el patr´on de dise˜no de nuestra aplicaci´on, los prototipos de la interfaz de usuario y por ´ultimo, decidiremos las herramientas que utilizaremos para implementar nuestro servicio. 8.3.1. Dise˜no arquitect´onico El dise˜no arquitect´onico es una parte muy importante en el proceso de desarrollo de software ya que se encarga de comprender la organizaci´on necesaria para un sistema y determinar su estructura. Durante este proceso se deben tomar decisiones que afectar´an al sistema, una de ellas ser´a la elecci´on de la arquitectura en la que se basar´a nuestro sistema. La arquitectura de software elegida se basar´a en el uso de uno o varios patrones arquitect´onicos consistentes en una descripci´on abstracta simplificada de buena pr´actica que ha tenido ´exito en sistemas previos. Nuestra idea es desarrollar una peque˜na aplicaci´on web que muestre la visualizaci´on de los resultados de las consultas y la posibilidad de modificar determinados par´ametros para adaptar la gr´afica y obtener diferentes comparaciones, por ello creemos conveniente utilizar un patr´on MVC (Modelo - Vista - Controlador). El patr´on MVC consiste en crear una separaci´on entre la presentaci´on y la interacci´on de los datos del sistema. Como vemos en la Figura 8.4, este patr´on consta de tres componentes l´ogicos: Modelo: opera sobre los datos del sistema y las acciones sobre estos. Vista: gestiona la presentaci´on de los datos al usuario del sistema. Controlador: dirige las interacciones del usuario con el sistema, informando de esto al Modelo y a la Vista. Figura 8.4: Organizaci´on del MVC (Fuente: parte 1, cap´ıtulo 6. Dise˜no arquitect´onico[45]) Es un modelo muy utilizado a d´ıa de hoy y nos ofrece ventajas como la separaci´on de responsabilidades utilizando una estructura organizada, la facilidad de comprensi´on del c´odigo y la reutilizaci´on de este. 92 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA 8.3.2. Dise˜no de interfaz de usuario Con el objetivo de plasmar todos los requisitos funcionales definidos en la Secci´on 8.1 simularemos la interfaz de usuario que queremos conseguir realizando diferentes prototipos. Emplearemos un patr´on de dise˜no que sigue el principio KISS (Keep it Stupidly Simple) y que busca obtener una interfaz sencilla en la que el usuario no se encuentre con barreras de identificaci´on, pueda retroceder si lo desea y pueda comprender el prop´osito de la aplicaci´on y su funcionamiento de un vistazo. En la Figura 8.5 podemos observar la primera vista que se encontrar´a el usuario al ejecutar la aplicaci´on y que le dar´a a elegir entre visualizar resultados de las consultas o de las pruebas de rendimiento. Figura 8.5: Boceto pantalla principal de la interfaz En la Figura 8.6 el usuario podr´a tener acceso a una gr´afica de puntos o de l´ıneas en funci´on de la consulta seleccionada, ya que en algunos casos se mostrar´a una variable cuantitativa discreta (por ejemplo, en la consulta para la medici´on de una determinada marca de tiempo o la consulta del conteo de mediciones) y en otros casos, se representar´a una variable cuantitativa continua (por ejemplo, en consultas de rangos de tiempo donde mostraremos las mediciones ligadas a la variable tiempo de ese rano). La configuraci´on de los par´ametros en este caso nos permitir´a seleccionar una consulta, una base de datos, un tama˜no y un n´umero de variables determinado para cada visualizaci´on y despu´es filtrar esta por cada identificador de analizador de red que est´e disponible para los datos seleccionados. En la Figura 8.7 tenemos la vista que se le mostrar´a al usuario si quiere ver los resultados de las pruebas de rendimiento de este proyecto representados mediante gr´aficos de barras agrupadas. La configuraci´on de los par´ametros permitir´a seleccionar la consulta de la que se quieren mostrar los resultados y har´a posible la actualizaci´on del gr´afico en funci´on de la selecci´on m´ultiple de las bases de datos, los tama˜nos y el n´umero de variables consultadas. 93 8.3. DISE ˜ NO Figura 8.6: Boceto pantalla de resultados de consultas de la interfaz Figura 8.7: Boceto pantalla de resultados de rendimiento de la interfaz 94 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA 8.3.3. Implementaci´on de la herramienta Tras analizar un estudio comparativo entre varios frameworks web de Python[13] a la hora de desarrollar nuestra aplicaci´on nos decidimos a probar Flask[39], un microframework de c´odigo abierto escrito en Python, muy ´util para proyectos peque˜nos y con una curva de aprendizaje baja. El funcionamiento de Flask es muy sencillo ya que utiliza una biblioteca de aplicaciones web WSGI (Web Server Gateway Interface) denominada Werkzeug y un motor de plantillas Jinja2 (librer´ıa que nos permite renderizar p´aginas web)[37]. Cabe resaltar que a pesar de tratarse de un marco de trabajo minimalista, una de las ventajas de Flask es la de ser capaz de aumentar sus funcionalidades de una forma modular mediante el uso de extensiones y bibliotecas de terceros. El funcionamiento de este framework es perfectamente compatible con el patr´on MVC ya que cubre las necesidades del controlador y la vista, y es posible abarcar el modelo mediante una extensi´on ya que por defecto no se encarga de esta parte. Adem´as, emplea una arquitectura cliente-servidor en la cual desde el navegador se hace una petici´on a una direcci´on URL que el WSGI interpreta, y solicita la plantilla HTML (HyperText Markup Language) y los datos asociados a dicha direcci´on para ser enviados de vuelta al navegador[26]. Nuestra aplicaci´on estar´a formada por un archivo ‘controller.py’ que se encargar´a de definir los decoradores de Flask que se encargan de asociar una ruta de una URL de la aplicaci´on con una funci´on que debe ejecutarse. As´ı tendremos tres rutas, una para el inicio de la aplicaci´on que nos mostrar´a las opciones disponibles, una para la visualizaci´on de los resultados de las consultas y otra para la visualizaci´on de los resultados de rendimiento. En esas funciones el controlador se encargar´a de tomar los datos introducidos por el usuario en un formulario y solicitar informaci´on al modelo. A su vez, tendremos el archivo ‘models.py’ que ser´a el responsable de recuperar los resultados generados en los experimentos de rendimiento y filtrarlos para generar las gr´aficas que le solicite el controlador en base a las decisiones del usuario. Tambi´en tendremos un conjunto de plantillas HTML, un archivo de estilo CSS y un archivo con una funci´on en JavaScript para la funcionalidad de guardar la visualizaci´on. A continuaci´on, podemos ver las pantallas principales de la aplicaci´on que nos muestran las visualizaciones. En la Figura 8.8 podemos ver un gr´afico de barras en el que para la base de datos, el tama˜no, las variables y la consulta seleccionada disponemos de datos para los 5 identificadores de analizador de red de los que solo decidimos mostrar 2. Podr´ıamos tener el caso de que para los tres meses de datos seleccionados no tuvi´esemos mediciones de los 5 identificadores y de esta manera la lista se reducir´ıa. En la Figura 8.9 nos encontramos con un gr´afico de barras en el que hemos seleccionado todas las bases de datos y todos los tama˜nos posibles para la consulta seleccionada. En este caso, a la hora de mostrar resultados de rendimiento nos encontramos que para la consulta de inserci´on no tenemos la posibilidad de elegir el n´umero de variables consultadas ya que no est´a disponible. Sin embargo, en el caso de la Figura 8.10 podemos ver que en el caso de seleccionar una consulta que s´ı dispone del par´ametro configurable del n´umero de variables consultadas, en caso de que no se seleccionen ser´a la pantalla que nos muestre la aplicaci´on hasta elegir en la 95 8.3. DISE ˜ NO lista que aparece debajo de la consulta sobre qu´e n´umero o n´umeros de variables consultadas queremos realizar el gr´afico comparativo. En la Figura 8.11 podemos ver la pantalla que nos mostrar´a la aplicaci´on si no existe la carpeta resultados o si existe pero no se encuentra en la ubicaci´on correcta. Hay que mencionar, que recurrimos a esta opci´on en lugar de dar a elegir al usuario la direcci´on de los resultados del lado del servidor, ya que conllevar´ıa realizar un desarrollo m´as complejo teniendo en cuenta medidas de seguridad y configuraci´on de permisos que nos llevar´ıa m´as tiempo y nos alejar´ıa del objetivo principal del proyecto. Figura 8.8: Pantalla de resultados de consultas de la aplicaci´on 96 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA Figura 8.9: Pantalla de resultados de rendimiento de la aplicaci´on 97 8.3. DISE ˜ NO Figura 8.10: Pantalla de resultados de rendimiento (sin selecci´on del n´umero de variables) de la aplicaci´on Figura 8.11: Pantalla de error de la aplicaci´on 98 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA Es importante a˜nadir que utilizamos el servidor WSGI para desarrollo y en caso de que queramos llevarlo a producci´on para que la aplicaci´on web fuese p´ublica habr´ıa que modificar la configuraci´on de Flask para utilizar un servidor Gunicorn, Nginx u otro[38]. 8.4. Manual del instalador El objetivo principal de este proyecto es realizar un estudio sobre el rendimiento de diferentes bases de datos de series temporales. ¡Estos programas deben ser ejecutados en Linux! Para ejecutar este proyecto se necesitan los archivos de este repositorio y el directorio con los datos originales que se tendr´an que solicitar de manera privada si se dispone de los permisos necesarios. Instalaci´on Para ejecutar este proyecto debemos instalar las siguientes herramientas de software: Para ejecutar este proyecto deberemos comprobar que la versi´on que tenemos de Python es la 3 y tener el instalador de paquetes ‘pip’. Para ello podr´a ejecutar las siguientes l´ıneas de c´odigo en su terminal de Linux: sudo apt i n s t a l l python3 sudo apt i n s t a l l pip Tambi´en tendremos que instalar Docker. Para utilizar esta herramienta sin privilegios de superusuario podemos ejecutar lo siguiente: sudo groupadd docker sudo usermod −aG docker $USER sudo systemctl r e s t a r t docker sudo chmod 666 /var /run/ docker . sock Pre-requisitos En el archivo ‘requirements.txt’ podemos encontrar las bibliotecas de Python que hemos utilizado durante el desarrollo del trabajo. Para instalarlas deberemos ejecutar el siguiente comando y si lo desea puede crear antes un entorno virtual para que no afecten est´as versiones a otras que tenga instaladas en su m´aquina. pip install −r requirements . txt Ejecuci´on Teniendo en cuenta que hemos seguido los pasos anteriores y tenemos todo el software necesario, el primer paso ser´a descargar este repositorio y obtener la carpeta ‘raw data’ con los datos originales y que tendremos que ubicar en ‘TFG PatriciaAguado/data/’. A continuaci´on, tendremos que dar permisos de ejecuci´on al usuario para los scripts de Bash: 99 8.4. MANUAL DEL INSTALADOR sudo chmod u+x docker db . sh sudo chmod u+x process data . sh sudo chmod u+x v i s u a l i z a t i o n . sh En primer lugar, abrimos una terminal en ‘TFG PatriciaAguado’ y ejecutamos el script ‘process data.sh’: ./ process data . sh Este se encarga de ejecutar en orden los programas de Python que se encuentran en el directorio ‘data’. Estos consisten en: ‘read data.py’: leer todos los archivos que se encuentran en el directorio ‘data/raw data’ y juntarlos para generar el archivo ‘data/silver data.xlsx’. ‘clean data.py’: realizar sobre ‘silver data.xlsx’ un proceso de limpieza de datos y generar en el directorio ‘data/gold data’ un archivo con todos los datos de calidad y uno por cada tama˜no especificado (3, 6, 10 y 13 meses). ‘json schemas.py’: crear un directorio ‘data/json schemas’, en el que se crea un directorio por cada base de datos y en cada uno de ellos un archivo de formato JSON para cada tama˜no. En segundo lugar, una vez que ya tenemos todos los archivos preparados con los datos que queremos insertar para las pruebas de rendimiento en el directorio ‘data/json schemas’ ejecutamos el script ‘docker db.sh’: ./ docker db . sh Este primero monta un contenedor de Docker para nuestra base de datos personal, a partir del script SQL ‘docker/scripts sql/postgresdb.sql’. Como esta base de datos almacenar´a los resultados, se genera un directorio de persistencia de datos denominado ‘docker/postgresdb’. Despu´es, el script contin´ua montando un contenedor de Docker, realizando pruebas de rendimiento (es decir, ejecutando los programas Python que se encuentran en ‘docker/scripts python’), guardando los datos recuperados en cada consulta, insertando los resultados de rendimiento en nuestra base de datos y desmontando el contenedor para cada servicio definido en el archivo ‘docker/docker-compose.yml’ de forma recursiva. Al finalizar, se ejecuta el programa ‘results performance.py’ que recupera los resultados de PostgreSQL en un documento XLSX que contiene las tablas con los resultados de las pruebas de rendimiento (‘results performance.xlsx’) y que almacena en el directorio ‘results’ junto con los resultados de cada consulta en cada experimento. En ´ultimo lugar, ejecutamos el script ‘visualization.sh’ que nos abrir´a una p´agina en nuestro navegador por defecto con el puerto 5000, que es en el que se encuentra el servidor de nuestra aplicaci´on web de visualizaci´on de datos: ./ v i s u a l i z a t i o n . sh 100 CAP´ ITULO 8. HERRAMIENTA DE VISUALIZACI ´ ON DESARROLLADA Utilizaci´on de la aplicaci´on Al abrirse la aplicaci´on web nos encontramos con dos opciones: Resultados de consultas: obtendremos gr´aficas de puntos o de l´ıneas en funci´on de la consulta sobre la que queramos observar los resultados. Podremos filtrar los datos a mostrar seleccionando la base de datos, el tama˜no de meses y el n´umero de variables consultadas que queremos. Una vez pulsemos el bot´on de actualizar podremos ver el gr´afico deseado, pero si queremos por ejemplo seleccionar unos identificadores de sensor diferentes podremos elegirlos en las casillas de verificaci´on pertinentes y volver a pulsar el bot´on de actualizar. Resultados de rendimiento: obtendremos gr´aficas de barras agrupadas por tama˜nos para los resultados de las pruebas de rendimiento realizadas. Nos encontraremos casillas de verificaci´on para seleccionar las bases de datos y los tama˜nos del conjunto en meses que queremos comparar. Una vez seleccionado esto y la consulta para la que queremos graficar los resultados, una vez que pulsemos el bot´on actualizar en caso de que sea necesario elegir el n´umero de variables consultadas a comparar (porque realizamos consultas preguntando por 1, 5 y 20 variables) aparecer´a una visualizaci´on vac´ıa que nos indicar´a que debemos seleccionar este ´ultimo par´ametro que antes igual no estaba visible. S´olo tendremos que pulsar el bot´on de actualizar y volver´a a estar disponible. En ambos nos encontraremos con un bot´on para ir atr´as y con un bot´on situado debajo del gr´afico en la parte derecha para poder descargar la visualizaci´on en formato PNG. Adem´as, los gr´aficos son interactivos, podemos ampliarlos, modificar las escalas de los ejes o ver informaci´on detalla al pasar por encima del dato representado. Hay que mencionar que, en caso de que no exista la carpeta ‘docker/results’ nos aparecer´a una pantalla de error con indicaciones. En caso de querer ver varios gr´aficos en diferentes pesta˜nas, podemos abrir manualmente la misma direcci´on (http://127.0.0.1:5000/) en otra pesta˜na o en otro navegador, siempre y cuando no hayamos detenido el servidor en la terminal. Si queremos cerrar la aplicaci´on basta con cerrar el navegador y presionar en la terminal de Linux ‘CTRL+C’. Construido con Las herramientas principales que hemos utilizado para llevar acabo este proyecto son las siguientes: Python - Lenguaje de programaci´on Docker - Plataforma basada en la virtualizaci´on de entornos aislados para facilitar el despliegue de aplicaciones Sublime Text - Usado para generar todos los scripts del trabajo Flask - Usado para la aplicaci´on web 101 108 BIBLIOGRAF´ IA Bibliograf´ıa [1] A.Meier and M.Kaufmann. SQL and NoSQL databases. Springer Vieweg, 2019. [2] The OpenTSDB Authors. How does opentsdb work?, 2010. URL: http://opentsdb.net/ overview.html. Accedido 12-07-2023. [3] Apache Cassandra. P´agina principal del software apache cassandra, 2009. URL: https: //cassandra.apache.org/_/index.html. Accedido 13-07-2023. [4] European Commission. Making our homes and buildings fit for a greener future. 2021. URL: https://ec.europa.eu/commission/presscorner/detail/en/fs_21_6691. Accedido 16-05-2023. [5] El Norte de Castilla. El edificio lucia de la uva, el primero reconocido a nivel mundial como protegido de contagio de virus, 2020. URL: https://www.elnortedecastilla. es/valladolid/edificio-lucia-primero-20200630165954-nt.html. Accedido 22-05- 2023. [6] Paul Dix. Why time series matters for metrics, real-time analytics and sensor data. An InfluxData Case Study, pages 9–10, 2021. URL: https://www.influxdata.com/ time-series-database/. Accedido 05-07-2023. [7] T. Dunning and E. Friedman. Time Series Database. New ways to store an access data. O’Reilly, 2014. [8] European Commission Department: Energy. Energy efficiency in buildings. 2020. URL: https://commission.europa.eu/news/ focus-energy-efficiency-buildings-2020-02-17_en. Accedido 16-05-2023. [9] P. Esling and C. Agon. Time-series data mining. ACM Computing Surveys, pages 1–32, 2012. [10] J. Fan, F. Han, and H. Liu. Challenges of big data analysis. National Science Review, 2014. [11] Peter Gardfj¨all and Elastisys Company. Kairosdb docker image. URL: https://hub. docker.com/r/elastisys/kairosdb. Accedido 09-10-2023. [12] Lars George. HBase: The Definitive Guide. O’Reilly, 2011. URL: https: //github.com/Jayarami123/hadoop-cookbook/blob/master/HBase%EF%BC%9AThe% 20Definitive%20Guide.pdf. Accedido 11-07-2023. 109 BIBLIOGRAF´ IA [13] Devndra Ghimire. Comparative study on Python web frameworks: Flask and Django. Metropolia University of Applied Sciences, 2010. [14] S. Gilbert and N. Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. PODC 2000, 2004. [15] Peter Grace. Opentsdb docker image. URL: https://hub.docker.com/r/petergrace/ opentsdb-docker. Accedido 09-10-2023. [16] Tianon Gravi, Joseph Ferguson, and contribuidores. Postgresql docker official image. URL: https://hub.docker.com/_/postgres. Accedido 09-10-2023. [17] Brian Hawkins. Query performance, 2022. URL: https://github.com/kairosdb/ kairosdb/wiki/Query-Performance. Accedido 13-07-2023. [18] Universidad Jaime I. Apuntes ficheros y bases de datos, 2003. URL: https://www3.uji. es/~aliaga/e44/Tema_07.pdf. Accedido 26-05-2023. [19] InfluxData. Influxdb docker official image. URL: https://hub.docker.com/_/influxdb. Accedido 09-10-2023. [20] InfluxDB. P´agina principal del software influxdb, 2013. URL: https://www.influxdata. com/influxdb/. Accedido 05-07-2023. [21] Project Management Institute. Gu´ıa de los fundamentos para la direcci´on de proyectos (Gu´ıa del PMBOK®) Tercera edici´on. Project Management Institute, 2004. [22] Solid IT. Clasificaci´on para sistemas gestores de bases de datos, 2012. URL: https: //db-engines.com/en/ranking/time+series+dbms. Accedido 27-06-2023. [23] C. S. Jensen and R. T. Snodgrass. Temporal data management. IEEE Transactions on Knowledge and Data Engineering, Vol. 11, pages 1–9, 1999. [24] KairosDB. P´agina principal del software kairosdb, 2013. URL: https://kairosdb. github.io/. Accedido 13-07-2023. [25] Simon Kemp. Digital 2023: Global overview report, 2023. URL: https://datareportal. com/reports/digital-2023-global-overview-report. Accedido 23-05-2023. [26] Italo Maia. Building Web Applications with Flask. Packt Publishing, 2015. [27] Mercedes Marqu´es. Bases de datos. Castell´o de la Plana: Publicacions de la Universitat Jaume I. Servei de Comunicaci´o i Publicacions, 2011. [28] Enrique Garc´ıa Miravalles. Tfm. determinaci´on de los estados de funcionamiento y predicci´on del consumo energ´etico del edificio lucia. URL: https://uvadoc.uva.es/handle/ 10324/787/discover. Accedido 20-06-2023. [29] The University of Arizona. Christian s. jensen y richard t. snodgrass. URL: https: //timecenter.cs.aau.dk/. Accedido 31-05-2023. [30] The University of Arizona. Richard thomas snodgrass biography. URL: http://www2.cs. arizona.edu/~rts/. Accedido 31-05-2023. 110 BIBLIOGRAF´ IA [31] OpenTSDB. P´agina principal del software opentsdb, 2010. URL: http://opentsdb.net/. Accedido 10-07-2023. [32] OpenTSDB. Querying or reading data, 2010. URL: http://opentsdb.net/docs/build/ html/user_guide/query/index.html. Accedido 12-07-2023. [33] Oracle. ¿qu´e es big data?, 2021. URL: https://www.oracle.com/big-data/ what-is-big-data/. Accedido 16-05-2023. [34] Pandas. pandas.dataframe, 2008. URL: https://pandas.pydata.org/docs/reference/ api/pandas.DataFrame.html. Accedido 22-06-2023. [35] R. Ramakrishnan and J. Gehrke. Database Management Systems, Second Edition. McGraw-Hill, 1999. URL: https://xuanhien.files.wordpress.com/2011/04/ database-management-systems-raghu-ramakrishnan.pdf. Accedido 26-05-2023. [36] Catherine M. Ricardo. Bases de datos. Mc Graw Hill, 2009. [37] Armin Ronacher. Software jinja2, 2008. URL: https://jinja.palletsprojects.com/ en/3.1.x/. Accedido 26-10-2023. [38] Armin Ronacher. Flask. deploying to production, 2010. URL: https://flask. palletsprojects.com/en/3.0.x/deploying/. Accedido 26-10-2023. [39] Armin Ronacher. Framework web flask, 2010. URL: https://flask.palletsprojects. com/en/3.0.x/. Accedido 26-10-2023. [40] David Salomon. Data Compression. 3rd Edition. The Complete Reference. Springer, 2005. [41] Songwon Seo. A review and comparison of methods for detecting outliers in univariate data sets, 2006. URL: https://d-scholarship.pitt.edu/7948/1/Seo.pdf. Accedido 28-12-2023. [42] Bonil Shah, P.M. Jat, and Kalyan Sashidhar. Performance study of time series databases. arXiv preprint arXiv:2208.13982, 2022. URL: https://arxiv.org/abs/2208.13982. Accedido 26-06-2023. [43] Siemens. Sistema desigo - construyendo el futuro hoy, 1999. URL: https://new.siemens. com/es/es/productos/building-technology/automatizacion/desigo.html. Accedido 19-05-2023. [44] Richard Snodgrass. The temporal query language tquel. ACM Transactions on Database Systems, Vol. 12, pages 1–52, 1987. [45] Ian Sommerville. Ingenier´ıa de Software. Pearson, 2011. [46] Roger S.Pressman. Ingenier´ıa del software. Un enfoque pr´actico. Mc Graw Hill, 2010. [47] Andreas Steiner. A generalisation approach to temporal data models and their implementations, 1998. URL: https://www.timeconsult.com/Publications/Literature.html. Accedido 01-06-2023. [48] Rachel Stephens. The state of the time series database market, 2018. URL: https://redmonk.com/rstephens/2018/04/03/ the-state-of-the-time-series-database-market/. Accedido 02-06-2023. 111 BIBLIOGRAF´ IA [49] Petroc Taylor. Volume of data/information created, captured, copied, and consumed worldwide from 2010 to 2025. statista., 2022. URL: https://www.statista.com/statistics/ 871513/worldwide-data-created/. Accedido 24-05-2023. [50] Kairos DB Team. Documentation. querying data, 2013. URL: https://kairosdb. github.io/docs/QueryingData.html. Accedido 13-07-2023. [51] S. W. Thomas, R. T. Snodgrass, and T. Zhang. τbench: Extending xbench with time. A TimeCenter Technical Report, pages 13–26, 2013. URL: http://www2.cs.arizona.edu/ ~rts/publications.html. Accedido 01-06-2023. [52] Timescale. Timescaledb docker image. URL: https://hub.docker.com/r/timescale/ timescaledb. Accedido 09-10-2023. [53] TimeScaleDB. Querying data timescaledb, 1. URL: https://docs.timescale.com/ use-timescale/latest/query-data/. Accedido 03-07-2023. [54] TimeScaleDB. P´agina principal del software timescaledb, 2017. URL: https://www. timescale.com/. Accedido 28-06-2023. [55] TimeScaleDB. Schema management timescaledb, 2023. URL: https://docs.timescale. com/use-timescale/latest/schema-management/. Accedido 29-06-2023. [56] N. Tran, P. Dix, A. Lamb, and M. Mikulicic. Influxdb 3.0: System architecture, 2023. URL: https://www.influxdata.com/blog/influxdb-3-0-system-architecture/. Accedido 06-07-2023. [57] Marta Mart´ınez Vera. La certificaci´on leed a trav´es de sus edificios. edificio lucia, 2020. Trabajo de Fin de Grado. Escuela T´ecnica Superior de Arquitectura. Universidad de Valladolid. URL: https://uvadoc.uva.es/handle/10324/44695?locale-attribute=pt_BR. Accedido 18-05-2023. [58] Diego Tamayo Alonso y colaboradores. Edificio lucia - universidad de valladolid. URL: http://edificio-lucia.blogspot.com/. Accedido 22-05-2023. 112 AP´ ENDICE A. ANEXOS Ap´endice A Anexos A.1. Archivo servicios Docker Secci´on que presenta el fichero ‘docker-compose.yml’ a trav´es del que la herramienta Compose pone en marcha los diferentes servicios definidos en ´el. El esquema que sigue consiste en definir el nombre que tomar´a el servicio, la imagen que desea montar en el contenedor y que buscar´a en Docker Hub, par´ametros para el manejo de ficheros internos del contenedor, nombre que le queremos dar al contenedor, variables de entorno que queremos pasar al contenedor, volumen para la persistencia de datos mientras est´a en ejecuci´on el contenedor y el mapeo del puerto de nuestra m´aquina local al contenedor de Docker. Es importante mencionar que si no queremos persistencia de datos una vez se pare el contenedor podemos obviar la l´ınea que define un volumen de datos y lo mapea a la m´aquina local. services: postgresdb: image: postgres:16.0 logging: options: max-size: "10m" max-file: "5" container_name: postgres_db_container environment: - POSTGRES_DB=postgres_db - POSTGRES_USER=admin - POSTGRES_PASSWORD=admin volumes: - ./postgresdb/postgres_db_data:/var/lib/postgresql/data ports: - "5432:5432" influxdb: image: influxdb:2.7 logging: 113 A.1. ARCHIVO SERVICIOS DOCKER options: max-size: "10m" max-file: "5" container_name: influx_db_container environment: - DOCKER_INFLUXDB_INIT_MODE=setup - DOCKER_INFLUXDB_INIT_USERNAME=admin - DOCKER_INFLUXDB_INIT_PASSWORD=admin123456789 - DOCKER_INFLUXDB_INIT_ORG=myorg - DOCKER_INFLUXDB_INIT_BUCKET=mybucket - DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=mytoken ports: - "8086:8086" timescaledb: image: timescale/timescaledb:latest-pg15 logging: options: max-size: "10m" max-file: "5" container_name: timescale_db_container environment: - POSTGRES_DB=timescale_db - POSTGRES_USER=admin - POSTGRES_PASSWORD=admin ports: - "5434:5432" opentsdb: image: petergrace/opentsdb-docker:latest logging: options: max-size: "10m" max-file: "5" container_name: opents_db_container environment: - TSDB_ENABLE_STATS=true ports: - "4242:4242" kairosdb: image: elastisys/kairosdb:1.2.1 depends_on: - cassandra logging: options: max-size: "10m" max-file: "2" 114 AP´ ENDICE A. ANEXOS container_name: kairos_db_container environment: - CASSANDRA_HOSTS=cassandra - CASSANDRA_PORT=9042 ports: - "8080:8080" cassandra: image: cassandra:3.11 logging: options: max-size: "10m" max-file: "2" container_name: cassandra_db_container environment: - CASSANDRA_CLUSTER_NAME=mycluster ports: - "9042:9042" volumes: postgres_db_data: A.2. Consultas para las bases de datos A.2.1. Consultas para la base de datos InfluxDB Secci´on que contiene las consultas realizadas en las pruebas de InfluxDB utilizando Flux, un lenguaje funcional dise˜nado espec´ıficamente para trabajar con datos de series temporales. Consulta 1: obtener para un determinado sensor una medici´on de energ´ıa en un d´ıa y una hora determinados. from(bucket: "mybucket") |> range(start: time(v: "1970-01-01T00:00:00Z"), stop: now()) |> filter(fn:(r) => r._measurement == "energy" and ({ identificadores })) |> filter(fn:(r) => r._time == time(v: "2019-03-02T10:21:20Z")) Consulta 2, 3, 4, 5 y 6: obtener para un determinado sensor la m´ınima medici´on de energ´ıa (funci´on min()), la m´axima medici´on de energ´ıa (funci´on max()), la media de sus mediciones (funci´on mean()), la desviaci´on est´andar de sus mediciones (funci´on stddev()) y el conteo de sus mediciones (funci´on count()). from(bucket: "mybucket") |> range(start: time(v: "1970-01-01T00:00:00Z"), stop: now()) |> filter(fn: (r) => r._measurement == "energy" and ({ identificadores })) 115 A.2. CONSULTAS PARA LAS BASES DE DATOS |> group(columns: ["device_id"]) |> min(column: "_value") |> sort(columns: ["device_id"]) Consulta 7: obtener para un determinado sensor los valores sin duplicados que toman sus mediciones de energ´ıa. from(bucket: "mybucket") |> range(start: time(v: "1970-01-01T00:00:00Z"), stop: now()) |> filter(fn: (r) => r._measurement == "energy" and ({ identificadores })) |> group(columns: ["device_id"]) |> distinct(column: "_value") |> sort(columns: ["device_id","_time"]) Consulta 8 1, 8 2 y 8 3: obtener para un determinado sensor la media de sus mediciones de energ´ıa por horas (funci´on window(every: 1h)), semanas (funci´on window(every: 1w, offset: - 3d)) y meses (funci´on window(every: 1mo)). En la consulta 8 2 necesitamos a˜nadir el par´ametro offset con valor ‘-3d’ para a˜nadir un desplazamiento ya que establece los tiempos en base a la ´epoca Unix y queremos que tome como inicio de semana el Lunes. from(bucket: "mybucket") |> range(start: time(v: "1970-01-01T00:00:00Z"), stop: now()) |> filter(fn: (r) => r._measurement == "energy" and ({ identificadores })) |> group(columns: ["device_id"]) |> window(every: 1h) |> mean() |> sort(columns: ["device_id","_time"]) Consulta 9: obtener para un determinado sensor el tercer cuartil de sus mediciones de energ´ıa. from(bucket: "mybucket") |> range(start: time(v: "1970-01-01T00:00:00Z"), stop: now()) |> filter(fn: (r) => r._measurement == "energy" and ({ identificadores })) |> group(columns: ["device_id"]) |> quantile(column: "_value", q: 0.75) Consulta 10 1, 10 2, 10 3 y 10 4: obtener para un sensor determinado las mediciones de energ´ıa en un rango de tiempo determinado de un d´ıa, un d´ıa y unas horas, un mes, y un mes y unas horas. Obtenemos las diferentes consultas modificando las marcas de tiempo en los par´ametros start ystop. from(bucket: "mybucket") |> range(start: time(v: "2019-01-22T00:00:00Z"), stop: time(v: "2019-01-23T00:00:00Z")) |> filter(fn: (r) => r._measurement == "energy" and ({ identificadores })) |> group(columns: ["device_id","_time"]) 116 AP´ ENDICE A. ANEXOS A.2.2. Consultas para la base de datos TimescaleDB Secci´on que contiene las consultas realizadas en las pruebas de TimescaleDB utilizando el lenguaje SQL. Consulta 1: obtener para un determinado sensor una medici´on de energ´ıa en un d´ıa y una hora determinados. SELECT device_id, timestamp, device_measurement FROM energy WHERE device_id IN ({ identificadores }) AND timestamp=’2019-03-02T10:21:20’ Consulta 2, 3, 4, 5 y 6: obtener para un determinado sensor la m´ınima medici´on de energ´ıa (funci´on MIN()), la m´axima medici´on de energ´ıa (funci´on MAX()), la media de sus mediciones (funci´on AVG()), la desviaci´on est´andar de sus mediciones (funci´on STDDEV()) y el conteo de sus mediciones (funci´on COUNT()). SELECT device_id, MIN(device_measurement) AS min_energy FROM energy WHERE device_id IN ({ identificadores }) GROUP BY device_id ORDER BY device_id Consulta 7: obtener para un determinado sensor los valores sin duplicados que toman sus mediciones de energ´ıa. SELECT device_id, ARRAY_AGG(DISTINCT device_measurement) AS distinct_measurements FROM energy WHERE device_id IN ({ identificadores }) GROUP BY device_id ORDER BY device_id Consulta 8 1, 8 2 y 8 3: obtener para un determinado sensor la media de sus mediciones de energ´ıa por horas (funci´on time bucket(‘1 hour’, timestamp)), semanas (funci´on time bucket(‘1 week’, timestamp,‘1 week’::interval)) y meses (funci´on time bucket(‘1 month’, timestamp)). En la consulta 8 2 necesitamos a˜nadir el par´ametro ‘1 week’::interval para asegurarnos de que el Lunes sea el inicio de semana. SELECT device_id, AVG(device_measurement) AS avg_energy_hour, time_bucket(’1 hour’, timestamp) AS hour FROM energy WHERE device_id IN ({ identificadores }) GROUP BY device_id, hour ORDER BY device_id, hour Consulta 9: obtener para un determinado sensor un intervalo en el que se encuentren los valores at´ıpicos de sus mediciones de energ´ıa utilizando el rango intercuart´ılico. En esta consulta 117 A.2. CONSULTAS PARA LAS BASES DE DATOS Figura A.2: Ejemplo de la salida para los resultados de rendimiento en las pruebas (Figura de elaboraci´on propia) 124