Evaluación experimental de Neo4J para su aplicación en el dominio sanitario

fir Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Autor: Antonio Franco Romero Tutor: Jorge Calvillo Arbizu Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 iii Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Autor: Antonio Franco Romero Tutor: Jorge Calvillo Arbizu Profesor Permanente Laboral Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 v Trabajo Fin de Grado: Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Autor: Antonio Franco Romero Tutor: Jorge Calvillo Arbizu El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2025 El Secretario del Tribunal vii A mi familia A mis maestros ix Agradecimientos Quiero expresar mi agradecimiento a mis padres por haberme brindado la oportunidad de estudiar con la tranquilidad de saber que cuento con su respaldo y a mi pareja que ha supuesto un apoyo siempre que lo he necesitado Me gustaría mostrar mi más sincero agradecimiento a mi tutor el profesor Jorge Calvillo Arbizu, así como al resto de profesores del Grado de Ingeniería de las Tecnologías de Telecomunicación por compartir sus conocimientos y estar ahí siempre que lo he necesitado. Antonio Franco Romero Sevilla, 2025 xvii ÍNDICE DE FIGURAS Figura 1: Visualización de nodos en Neo4j 6 Figura 2: Nodos y relaciones de la base de datos 11 Figura 3: Dependencias 12 Figura 4: Inicialización del driver de Neo4J 12 Figura 5: Inicialización hilos 13 Figura 6: n0f0 RAM 15 Figura 7: n0f0 CPU 16 Figura 8: n10f100 CPU 17 Figura 9: n25f100 CPU 17 Figura 10: n30f100 CPU 18 Figura 11: n100f100 CPU 19 Figura 12: n149f100 CPU 20 Figura 13: n200f100 20 Figura 14: n49f50 CPU 21 Figura 15: n100f50 CPU 22 Figura 16: n149f50 CPU 22 Figura 17: n249f50 CPU 23 Figura 18: n50f25 CPU 24 Figura 19: n149f25 CPU 24 Figura 20: n200f25 CPU 25 Figura 21: Prueba inicio de hilos. 26 Figura 22: f100 RAM 27 Figura 23: f50 RAM 28 Figura 24: f25 RAM 28 Figura 25: CPU vs RAM f100 29 Figura 26: CPU vs RAM f50 30 Figura 27: CPU vs RAM f25 30 Figura 28: CPU vs RAM f25_v2 31 Figura 29: Tabla de medias CPU y RAM 32 Figura 30: Media de CPU vs dispositivos 32 Figura 31: Media de RAM vs dispositivos. 33 Figura 32: Función de ejecución de consultas 34 Figura 33: Tiempos de respuesta consultas 2 y 3 37 Figura 34: Tiempos de respuesta consultas 4,5 y 6 37 Figura 35: Tiempos de respuesta consultas 7,8 y 9 38 Figura 36: Comparación tiempos de respuesta consultas 4 y 7 39 Figura 37: Tiempos de respuesta consultas 13, 14 y 15 40 Figura 38: Tiempos de respuesta consultas 16, 17 y 18 41 Figura 39: Comparación tiempos de respuesta consultas 16 y 19 42 Figura 40: Borrado de relaciones 43 Figura 41: Borrado de nodos 43 Figura 42: Media de CPU con el paso del tiempo. 46 1 1 INTRODUCCIÓN 1.1 Motivación En el mundo actual, gracias al desarrollo de internet y los avances en las tecnologías, la velocidad de transmisión y el volumen de los datos transmitidos no solo se han incrementado exponencialmente, sino que siguen aumentando día a día. Ese alto volumen de datos transmitidos a alta velocidad debe ser recepcionado y almacenado para su posterior explotación. Es por eso que es importante desarrollar soluciones adecuadas para el almacenamiento de datos, teniendo en cuenta su conectividad, disponibilidad, seguridad y tiempos de respuesta. En el ámbito sanitario, como en otros sectores, el número de dispositivos que operan de manera autónoma (por ejemplo, realizando mediciones en pacientes) es cada día mayor. Para estos dispositivos, merece la pena introducir el término IoMT (Internet of Medical Things), que refiere a la red de dispositivos físicos implicados en la asistencia de los pacientes, por ejemplo, siendo capaces de captar y transmitir información sobre los pacientes o su entorno en tiempo real. Dicha red de dispositivos permite realizar tratamientos telemáticamente y la monitorización de pacientes en tiempo real, entre otras capacidades [1]. Todos estos avances suponen numerosas fuentes de datos mandando información simultáneamente y en tiempo real a un servidor. El volumen de datos puede ser muy alto y, si este servidor no es capaz de soportarlo, podría saturarse y perder información, lo que supondría un cuello de botella para soluciones por ejemplo de monitorización de pacientes en tiempo real. Es por ello que las características de las soluciones que recepcionen y almacenen datos de monitorización de pacientes en tiempo real son críticas para garantizar la escalabilidad de los sistemas y la conservación de los datos de salud de los pacientes. Por otro lado, el almacenamiento de los datos también es crucial para la posterior explotación de los datos y la generación de conocimiento a partir de ellos (descubrimiento de tendencias de riesgo, alarmas, etc.). Las bases de datos relacionales se llevan usando en la industria desde los inicios de la revolución computacional. Sin embargo, poseen ciertas limitaciones debido a su rigidez estructural para ciertos ámbitos de aplicación. Las bases de datos basadas en grafos solucionan este problema, dando igual importancia a la estructura y las relaciones entre datos, que a los datos en sí. Esto supone solucionar los problemas de escalabilidad que tienen las bases de datos relacionales [2]. Entre las implementaciones actuales de bases de datos, Neo4J es una de las más reconocidas y utilizadas. Su capacidad para manejar grandes volúmenes de datos y realizar consultas complejas de manera eficiente la hace la elegida para aplicaciones con un gran volumen de datos y de relaciones. Su flexibilidad permite añadir relaciones nuevas sin mayor complejidad. La motivación de este proyecto es, por tanto, analizar las prestaciones de una base de datos basada en grafos (concretamente, Neo4J) para el almacenamiento de datos de monitorización de pacientes. 1.2 Objetivos del proyecto El objetivo principal del proyecto es el análisis de las prestaciones de Neo4J en diferentes escenarios de prueba modificando tanto el número de fuentes que transmiten datos como la frecuencia de envío, así como los tiempos Introducción 2 de respuesta del sistema cuando varía la cantidad de datos almacenados. Este objetivo principal se concreta en los siguientes subobjetivos: 1. En primer lugar, estudio de Neo4j y su lenguaje de consulta (Cypher), analizando sus características, capacidades y limitaciones. 2. Posteriormente se realizará el diseño de la base de datos, indicando los tipos de nodos y las relaciones entre ellos. A partir de este análisis, se desplegará la base de datos, especificando los nodos, la información que contendrán, y las relaciones entre ellos. Se desarrollará un programa en java, que simule la inyección de datos en la base de datos. Este programa deberá ser capaz de variar tanto el número de fuentes de datos como la frecuencia de inyección. 3. Se realizarán las pruebas para ver cómo reacciona el sistema ante diferentes situaciones, tratando de encontrar su “punto de ruptura” (aquel en el que el sistema deja de funcionar correctamente). 4. Por último se analizarán los tiempos de respuesta ante diferentes consultas, variando el tamaño de la base de datos y la información que contiene. Esto evaluará tanto consultas simples como complejas, y su rendimiento bajo distintas cargas. El objetivo no sería solo encontrar el punto de saturación, si no ver en qué condiciones el sistema trabaja de manera óptima. 1.3 Plan de trabajo En este apartado se van a detallar las tareas desarrolladas para alcanzar los objetivos de este proyecto. Incluyendo las horas de trabajo, estimadas y reales, para cada tarea. Tarea 1: Búsqueda y obtención de la información. En esta actividad inicial se estudiará la documentación de la base de datos Neo4J. Tarea Tiempo estimado (horas) Tiempo real (horas) Investigación de las herramientas a usar 40 50 Total 40 50 Tabla 1: Investigación de neo4J Tarea 2: Instalación de los diferentes componentes que serán usados a lo largo del trabajo. Tarea Tiempo estimado (horas) Tiempo real (horas) Instalación de software 2 3 Total 2 3 Tabla 2: Instalación de equipos Tarea 3: Estudio del lenguaje cypher y funcionamiento de Neo4J. En esta tarea también se tiene en cuenta el estudio de los archivos de configuración de Neo4J. Tarea Tiempo estimado (horas) Tiempo real (horas) Estudio del entorno de Neo4J 10 15 Estudio del lenguaje Cypher 15 25 Total 25 35 Tabla 3: Estudio de Neo4J y cypher 3 3 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Tarea 4: Comparación y decisión de herramientas a utilizar. En esta tarea se analizará y decidirá el entorno para programar, así como el lenguaje de programación. También se buscarán herramientas para la medición de consumo CPU y RAM y tiempos de respuesta. Tarea Tiempo estimado (horas) Tiempo real (horas) Comparación y elección de lenguaje de programación 10 12 Comparación y elección de entorno de programación 2 2 Comparación y elección de herramientas de medición de consumo. 5 8 Comparación y elección de herramientas para medición de tiempos de respuesta 2 2 Comparación y elección de herramientas para hacer gráficas 2 4 Total 21 28 Tabla 4: Elección de herramientas Tarea 5: Estudio de las herramientas elegidas. Esta tarea incluye el estudio de la librería de Neo4J para Java y el estudio de la librería OSHI para medición de CPU y RAM. Tarea Tiempo estimado (horas) Tiempo real (horas) Estudio de librería de Neo4J 10 15 Estudio de librería OSHI 5 9 Estudio de Tableau Desktop 5 8 Total 20 31 Tabla 5: Estudio de las herramientas Tarea 6: Desarrollo de herramientas para la automatización de las pruebas. Tanto para pruebas de consumo de CPU y RAM como para envío de datos, creación de datos dummies, medición de tiempos, etc. Tarea Tiempo estimado (horas) Tiempo real (horas) Programa para inserción de datos 25 35 Programa de consumo de CPU y RAM 10 16 Programa para medición de tiempos 10 12 Total 45 63 Tabla 6: Tiempos de programación Tarea 7: Realización de pruebas. En esta tarea se incluyen las pruebas de CPU y RAM, así como las pruebas de Introducción 4 medición de tiempos. Tarea Tiempo estimado (horas) Tiempo real (horas) Pruebas de consumo de CPU 30 40 Pruebas de consumo de RAM 30 35 Pruebas de tiempos de respuesta 30 45 Total 90 120 Tabla 7: Realización de pruebas Tarea 8: Análisis de resultados. En esta tarea se analizarán todos los resultados obtenidos en las pruebas. Tarea Tiempo estimado (horas) Tiempo real (horas) Análisis de consumo de CPU 10 15 Análisis de consumo de RAM 10 15 Análisis de tiempos de respuesta 10 20 Total 30 50 Tabla 8: Análisis de resultados Tarea 9: Redacción de la memoria del trabajo. Tarea Tiempo estimado (horas) Tiempo real (horas) Redacción de la memoria 85 90 Total 85 90 Tabla 9: Redacción de la memoria Tiempos totales Tarea Tiempo estimado (horas) Tiempo real (horas) Total 358 474 Tabla 10: Tiempos totales 5 2 ESTADO DEL ARTE n este capítulo se explicará toda la teoría relacionada con el trabajo, así como las herramientas que se han utilizado para su desarrollo. 2.1. Conceptos clave • Testing de softwareEl testing de software es una actividad que pretende evaluar el correcto funcionamiento de un sistema y su rendimiento. La evaluación se realiza a través de diferentes pruebas centrándose cada una en un aspecto concreto. En este caso nos centraremos en las siguientes pruebas: o Prueba de rendimiento: Ponen a prueba el rendimiento de software en tiempo de ejecución. Se centran en buscar los límites del sistema, ver los puntos en los que falla y por qué. o Pruebas de recuperación: Fuerzan el sistema a fallar de diversos modos, y verifica que la recuperación es adecuada. • Cuello de botellaEn inglés “bottleneck”, se refiere al punto en el que la base de datos se ralentiza o sobrecarga. Tarda más tiempo que lo que se considera normal en realizar consultas o no admite más datos. 2.2. Internet of Medical Things (IoMT) Antes de entrar a explicar IoMT, conviene poner este concepto en contexto explicando primero el término Internet of Things (IoT). El Internet de las Cosas (IoT) abarca una red de dispositivos, sistemas y sensores interconectados que colaboran y se comunican entre sí, aprovechando los avances en la potencia de computación, la miniaturización de componentes electrónicos y la evolución de las redes de internet. Una característica clave del IoT es la capacidad de los dispositivos para operar de forma autónoma, recopilando y procesando datos sin intervención humana, lo que permite optimizar procesos y mejorar la eficiencia en diversos entornos. Esta red es altamente escalable, lo que permite integrar nuevos dispositivos fácilmente, y muchos de ellos cuentan con la capacidad de aprender y adaptarse a su entorno a través de inteligencia artificial. Estas características hacen del IoT una herramienta clave para optimizar procesos, mejorar la eficiencia y fomentar la innovación en una amplia variedad de sectores. La implementación de este tipo de red busca mejorar la calidad de vida y facilitar tareas. Abarcan un gran abanico de aplicaciones como “casas inteligentes” (por ejemplo, sensores y actuadores domóticos), “vehículos interconectados” (comunicación entre vehículos de forma autónoma), etc., pero la que nos importa es la aplicación al mundo sanitario [3]. E Estado del arte 6 Una plataforma IoMT es un “sistema inteligente” compuesto de sensores y circuitos electrónicos para obtener señales biomédicas de un paciente a través de la red para su posterior almacenamiento (temporal o permanente) [3]. La aplicación de IoT en sanidad, permite minimizar los errores humanos, y ayuda a los profesionales a diagnosticar las enfermedades más fácilmente gracias a la monitorización de las constantes vitales en tiempo real que proporciona esta red de dispositivos. 2.3. Bases de datos basadas en grafos Las bases de datos basadas en grafos no son más que otra manera de representar y definir una base de datos. En este tipo de bases de datos, la información se guarda en nodos, relaciones y propiedades. Los datos se guardan en nodos, que pueden tener propiedades, y cada nodo se relaciona con otros nodos a través de las relaciones. Dado que cada nodo en una base de datos basada en grafos tiene un enlace directo a los nodos con los que está relacionado, no es necesario crear índices adicionales para buscar o acceder a esas conexiones. Esto significa que, a diferencia de las bases de datos tradicionales, donde se deben generar índices para optimizar las búsquedas y las consultas, en las bases de datos de grafos la estructura misma facilita la navegación y recuperación de datos de manera eficiente. Cada nodo actúa como un punto de acceso inmediato a su red de relaciones, lo que simplifica la gestión y aceleración de las consultas complejas. Figura 1: Visualización de nodos en Neo4j En la figura se puede apreciar cómo se representaría la información en Neo4J, pero da una idea de las bases de datos basadas en grafos, en general. Vemos cada nodo con su información, y cómo se relacionan entre ellos. Tenemos 3 tipos de nodos en este ejemplo: médico (verde), hospital (rosa) y paciente (marrón). Un paciente estará asignado EN un hospital y A un médico y el médico trabajará para un hospital y tendrá asignados sus respectivos pacientes. Este tipo de bases de datos se suele usar cuando las relaciones entre cada nodo cobran una vital importancia, por eso es por lo que su uso se ve mayoritariamente en redes sociales. 2.4. Recursos software utilizados 2.4.1. Neo4J Neo4j es considerado el software de referencia en las bases de datos basadas en grafos y es una de las más utilizadas en áreas como la salud, el gobierno y el sector militar, entre otras. Es una base de datos de código abierto implementada en Java. Este software se lanzó en 2007 y tiene tres categorías: comunidad, gobierno y empresa. En este trabajo se utilizará la versión de comunidad. Neo4j permite a los usuarios modelar, almacenar y consultar datos altamente conectados de manera eficiente, lo que es esencial para aplicaciones que requieren 7 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario una representación rica de relaciones entre datos [2]. La arquitectura de Neo4j está optimizada para manejar millones de nodos y relaciones, proporcionando respuestas rápidas y escalabilidad horizontal. Además, Neo4j ofrece una librería de Java conocida como Neo4j Java Driver, que permite a las aplicaciones Java conectarse y comunicarse con la base de datos Neo4j. Esta librería facilita la ejecución de consultas Cypher y la manipulación de datos, proporcionando una API intuitiva y fácil de usar. El driver de Java maneja la autenticación, la conexión y el manejo eficiente de sesiones, lo cual simplifica significativamente la integración de Neo4j en aplicaciones basadas en Java [4]. Neo4j Desktop es una herramienta integral diseñada para interactuar de manera eficiente con bases de datos Neo4j. Funciona como una interfaz gráfica de usuario (GUI) que facilita la administración, exploración y prueba de bases de datos Neo4j en un entorno local o remoto. Con Neo4j Desktop, los usuarios pueden crear y configurar bases de datos, ejecutar consultas en Cypher (el lenguaje de consulta de Neo4j), y visualizar los resultados en forma de grafos interactivos, lo que mejora la comprensión y análisis de las relaciones entre los datos. 2.4.2. Cypher Cypher es el lenguaje de consulta declarativo utilizado por Neo4j. Similar al SQL en las bases de datos relacionales, Cypher está diseñado específicamente para trabajar con datos de grafos. Este lenguaje permite expresar consultas complejas de manera simple y legible, facilitando la extracción y manipulación de datos conectados. Cypher soporta patrones de búsqueda, correspondencia de nodos y relaciones, así como la actualización de datos. La capacidad de Cypher para manejar consultas sobre grafos hace que Neo4j sea una herramienta poderosa para el análisis de datos interconectados [5]. Además, Cypher proporciona soporte para operaciones de transacciones y tiene capacidades avanzadas para gestionar grandes volúmenes de datos. Para entender mejor este lenguaje, veamos una consulta. Supongamos que estamos utilizando una base de datos Neo4j para modelar una red social y queremos encontrar a todas las personas que Alice conoce. Para lograrlo, utilizamos una consulta en Cypher como la siguiente: MATCH (p:Person)-[:KNOWS]->(friend:Person) WHERE p.name = 'Alice' RETURN friend.name Esta consulta tiene varios componentes que trabajan juntos para obtener el resultado deseado. En primer lugar, el comando MATCH se utiliza para especificar un patrón de búsqueda en el grafo. En este caso, el patrón está buscando nodos etiquetados como Person (que representamos como p) conectados por una relación llamada KNOWS hacia otros nodos, también etiquetados como Person (representados como friend). El filtro WHERE p.name = 'Alice' se asegura de que la consulta solo considere los nodos que tienen un atributo name con el valor "Alice". Esto nos permite enfocarnos únicamente en las conexiones de Alice. Finalmente, el comando RETURN friend.name se utiliza para devolver el nombre de las personas conectadas a Alice a través de la relación KNOWS. Por ejemplo, si en la base de datos hay nodos para Alice, Bob y Carol, y existen relaciones de KNOWS entre Alice y estos dos, la consulta devolverá los nombres "Bob" y "Carol". Esto permite comprender rápidamente las conexiones de Alice en la red social. La gran ventaja de Cypher es su legibilidad. Su diseño declarativo y centrado en patrones facilita la comprensión y el análisis de datos interconectados, haciendo que sea una herramienta poderosa para trabajar con bases de datos basadas en grafos como Neo4j. 2.4.3. Eclipse Eclipse es un entorno de desarrollo integrado (IDE) ampliamente utilizado en la programación en Java y otros lenguajes. Es una plataforma de código abierto que ofrece un conjunto de herramientas extensibles para el desarrollo de software. Eclipse proporciona una interfaz amigable y diversas funcionalidades que ayudan en la 14 Evaluación experimental para asegurar que, en situaciones reales, la base de datos funcione de manera eficiente y sin contratiempos, garantizando la integridad y la fiabilidad de los datos manejados. 3.3.4 Monitorización La monitorización del rendimiento del sistema es un aspecto fundamental en cualquier proyecto que implique el procesamiento intensivo de datos, como es el caso de la simulación y envío de información en bases de datos. Durante el desarrollo, surgió la necesidad de observar en tiempo real el consumo de recursos del sistema, específicamente el uso de CPU y memoria RAM, para asegurar que el sistema pudiera manejar la carga sin comprometer su estabilidad y eficiencia. Inicialmente, se buscó algún software de uso libre que permitiera medir estos parámetros, pero tras una exhaustiva búsqueda, no se encontró ninguna herramienta que cumpliera con los requisitos específicos del proyecto. Esto llevó a la exploración de alternativas, resultando en la elección de la librería OSHI (Operating System and Hardware Information) en Java. OSHI es una biblioteca de código abierto que permite acceder a información detallada sobre el hardware y el sistema operativo del dispositivo en el que se ejecuta la aplicación. Esta librería resultó ser la solución ideal para el monitoreo, dado que permite recopilar datos precisos sobre el uso de CPU y memoria, así como otros recursos del sistema. Para implementar la monitorización, se desarrolló un script en un proyecto separado de Eclipse que se ejecuta en paralelo al script principal de envío de datos. Esto se hizo con el objetivo de medir el consumo de recursos en tiempo real mientras se ejecutan las pruebas. Este script se encarga de medir el porcentaje de CPU y RAM usados, mide cada medio segundo y los inserta en un archivo CSV. Archivo que posteriormente se abre en Tableau para poder visualizar las gráficas correspondientes. 3.4 Análisis de rendimiento de CPU y RAM Para poder entender el comportamiento y saber la eficiencia que tiene Neo4j, hemos hecho este análisis bajo diferentes cargas de trabajo. En este apartado se examinará cómo la carga que le proporcionemos a la base de datos afecta a los recursos que demanda la misma. Para llevar a cabo este análisis, se han realizado pruebas simulando diferentes volúmenes de datos, lo que nos llevará a ver el límite de la base de datos. Este análisis no solo proporciona información sobre la eficiencia de Neo4j, sino que también ofrece claves sobre cómo optimizar la configuración del sistema y las consultas Cypher para mejorar el rendimiento. Se presentarán gráficos y tablas con los resultados obtenidos, seguidos de una discusión sobre las posibles optimizaciones y mejores prácticas para gestionar los recursos de manera eficiente Para poner en contexto, y explicar la estructura que van a llevar a las gráficas, se muestran a continuación dos imágenes del consumo de CPU y RAM en la situación en que no se manda ningún tipo de dato. Esto nos permitirá conocer el punto de partida del sistema. En concreto podemos observar que el consumo de CPU en reposo sí es bajo, pero el de RAM es alto, aunque esté en reposo debido a que el equipo del setup tiene tan solo 8Gb de RAM. 15 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Como se ve en la gráfica, el consumo medio es bastante alto, por lo que el consumo de RAM no se verá bien reflejado en este estudio. El eje horizontal indica el tiempo (en segundos) en el que se realizó la medida, y el eje vertical, el porcentaje de consumo (RAM o CPU, dependiendo del caso). En las gráficas de consumo de RAM además se ha añadido una línea de tendencia, indicando el consumo promedio. Conviene aclarar la notación del título de las gráficas, como en n0f0. El número detrás de la “n” indica el número de dispositivos desde los que se mandan datos, mientras que el número detrás de la “f” indica la frecuencia 2 a la que se envían los mismos. 2 Aunque se utilice el término “frecuencia” en el documento, nos referimos al tiempo transcurrido entre dos datos consecutivos para el mismo dispositivo. Figura 6: n0f0 RAM 16 Evaluación experimental Figura 7: n0f0 CPU La Figura 7 refleja lo que se esperaba: un consumo de CPU bajo en las condiciones iniciales de reposo sin actividad. Antes de proceder al análisis, es preciso comentar que, cuando la tasa de envío es alta puede dar problemas de concurrencia a la hora de escribir los datos. Se ha obviado este problema a la hora de hacer las pruebas y los resultados, ya que el número de datos perdidos era menor al 1% y se ha considerado que su efecto en el rendimiento es despreciable. 3.4.1 Consumo de CPU con frecuencia 100 ms El primer bloque de pruebas se llevó a cabo con una frecuencia de 100 ms por dato, y se incrementó el número de dispositivos de manera gradual. En un principio, se escogió un aumento del número de dispositivos conservador, haciéndolo de forma incremental para evitar sobrecargar el sistema rápidamente. Sin embargo, pronto fue evidente que, con esta frecuencia, se necesitaba un número considerable de dispositivos para que el impacto en el consumo de CPU fuera notable. 17 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario En comparación con la gráfica anterior, se evidencia que, de media, consume más CPU (1,21% vs 5,7%) y llegando a picos más altos (7,88% vs 20,56%). Pero nada significante, un cambio normal dado que antes la base de datos no estaba trabajando prácticamente. Las pruebas con 15 y 20 dispositivos daban picos similares 17,28% y 20,87, respectivamente. Lo que indica que todavía esto no suponía un esfuerzo para Neo4J porque además el consumo medio de CPU bajó a 3,68% con 20 dispositivos. Al elevar los dispositivos a 25 manteniendo la frecuencia en 100 ms se pudieron observar comportamientos interesantes (Figura 9). Figura 8: n10f100 CPU 18 Evaluación experimental Figura 9: n25f100 CPU Es notable ver el pico que hay en el segundo 3 de estar transmitiendo datos, sin embargo, es algo instantáneo ya que posteriormente vuelve a unos valores más razonables. Es interesante, ya que en la Figura 10 con 30 dispositivos no llega a un pico tan alto, ni se acerca directamente. Alcanza un máximo de 53,8%, insignificante en comparación con los 95,29% alcanzados en el anterior gráfico. Figura 10: n30f100 CPU 19 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario En la Figura 11 se representa el consumo de CPU con 100 dispositivos y misma frecuencia, sin obtener cambios notables. Se puede comprobar como sigue aceptando bien la cantidad de datos, sin llegar a saturar demasiado. La situación comienza a cambiar cuando aumentamos el número de dispositivos a 149 (Figura 12) ya que es la primera vez que se mantiene por encima de 75% alrededor de 3 segundos, llegando a un pico de 97,33% de uso de CPU, algo que se podría considerar peligroso en el caso en el que estuviéramos hablando de servidores. Posteriormente, observamos con 200 dispositivos un pico de 97,88%, pero un pico momentáneo que se estabiliza rápidamente (Figura 13). Figura 11: n100f100 CPU 20 Evaluación experimental Figura 12: n149f100 CPU Figura 13: n200f100 Cuando se alcanzan los 300 dispositivos sí se puede empezar a observar un cuello de botella, en el que se mantiene el consumo de CPU por encima del 80% durante 6,5 segundos. 21 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario En la primera etapa de pruebas, vemos que la base de datos empieza a saturar seriamente con 300 dispositivos, lo que son en total unos 3000 datos enviados por segundo. Cada dato enviado es un nuevo nodo creado y dos relaciones nuevas. 3.4.2 Consumo de CPU con frecuencia 50 ms La segunda parte de las pruebas se realizaron mandando un dato cada 50 ms, es decir, cada dispositivo manda 20 datos por segundo. Empezamos con 49 dispositivos (Figura 14). Dada la estabilidad del consumo, obviamos las pruebas con menos dispositivos, ya que no se ve nada interesante en los resultados. En la Figura 15 podemos observar un pico de 62,57% pero que rápidamente disminuye, conservando un promedio de 5,89%. Tiene sentido que aguante la base de datos a pesar del incremento de frecuencia, ya que ahora mismo se estarían mandado 980 datos por segundo 3 cuando, anteriormente el problema empezó a los 3000 d/s. 3 A partir de este momento, se le abreviará datos por segundo a “d/s” para una mayor brevedad. Figura 14: n49f50 CPU 22 Evaluación experimental Siguiendo con el siguiente gráfico: Figura 15: n100f50 CPU Los datos que nos presenta este gráfico nos permiten ver dos picos altos de 92% y 86%, respectivamente, pero que no perduran en el tiempo. Salvo el otro pico de 60%, la base de datos soporta esta cantidad de dispositivos y esa frecuencia de envío. La siguiente prueba nos permite ver dos picos en vez de uno, lo que indica que Neo4j empieza a necesitar más Figura 16: n149f50 CPU 23 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario recursos para poder procesar la información (Figura 16). En este punto casi hemos alcanzado el punto de ruptura anterior, mandando 2980 d/s. Pero parece ser que a esta frecuencia el sistema aguanta mejor. Figura 17: n249f50 CPU Pero llegados a este punto sí que alcanzamos un punto crítico en el sistema. Con una tasa de 4980 d/s el sistema se pasa 4,5 segundos por encima del 95% y vemos que posteriormente la recuperación es mucho más lenta de lo que venía siendo en las anteriores pruebas. 3.4.3 Consumo de CPU con frecuencia 25 ms La tercera, y última frecuencia probada, es un dato cada 25 ms. Lo que se traduce a que cada dispositivo manda 40 d/s. 30 Evaluación experimental Figura 26: CPU vs RAM f50 En la Figura 26, para una frecuencia de 50 ms, se observa que la línea azul, que representa el uso promedio de CPU, muestra un incremento continuo y más suave en comparación con la gráfica anterior. Este comportamiento indica que, a medida que aumenta el número de dispositivos, la carga de procesamiento en la CPU sigue creciendo de manera lineal. El patrón refleja un aumento consistente en la demanda de procesamiento, probablemente debido al procesamiento de los datos que cada dispositivo está enviando en intervalos cortos. Es importante notar que, aunque el incremento es lineal, la tendencia apunta a una carga significativa a medida que se alcanzan los 360 dispositivos, llegando a un uso de CPU alrededor del 40%. Este incremento sugiere que, si se continúa aumentando el número de dispositivos, el sistema podría acercarse a un punto donde la capacidad de la CPU podría volverse un factor limitante, requiriendo posibles optimizaciones o mejoras en la capacidad de procesamiento para evitar problemas de rendimiento. Figura 27: CPU vs RAM f25 31 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario En la Figura 27, la CPU muestra un comportamiento más irregular en comparación con las gráficas anteriores. Si bien existe una tendencia general ascendente en el uso de la CPU a medida que aumenta el número de dispositivos, también se observan picos y caídas significativas, especialmente alrededor de los 180 dispositivos y luego una disminución alrededor de los 220 dispositivos. Este patrón, se debe a lo que vimos previamente en el consumo de CPU, que al saturarse la base de datos se detiene y disminuye drásticamente el consumo de CPU. Figura 28: CPU vs RAM f25_v2 Lo que se comentaba previamente se puede apreciar en la gráfica de la Figura 28, la cual es la misma que la Figura 27, pero aumentando los segundos de medición (pasando de 25 segundos a 50). Aquí se puede ver más clara la tendencia, y que a medida que se mandan más datos desde más dispositivos el sistema tiende a saturar. Pero los picos y caídas indican que el sistema podría estar experimentando momentos de alta demanda seguidos de momentos de alivio. Esto podría ser resultado de cómo se gestionan las tareas en la CPU, quizás debido a un algoritmo de distribución de carga que no distribuye de manera uniforme en todos los casos. Podemos ver también los resultados en una tabla (Figura 29). La tabla refleja la media de CPU y RAM a medida que aumenta el número de dispositivos. Hay que tener en cuenta que con un mismo número de dispositivos se han hecho pruebas a distintas frecuencias y esta tabla recoge la media de todas las medidas. En la primera columna se refleja el número de dispositivos, la segunda la media de CPU y la tercera la media de RAM. 32 Evaluación experimental Figura 29: Tabla de medias CPU y RAM Como hemos visto durante todo el análisis, el promedio de CPU aumenta poco a poco de manera lógica, mientras que el promedio de RAM va variando sin un criterio aparente. Para visualizar eso mejor, podemos ayudarnos de las dos gráficas siguientes. Figura 30: Media de CPU vs dispositivos Como hemos comentado a partir de la tabla, la media de CPU va aumentado acorde al número de dispositivos, salvo con 25 y 30 dispositivos. Esto puede deberse a que en esos casos haya más muestras de mayor frecuencia. 33 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Figura 31: Media de RAM vs dispositivos. En cuanto a la media de RAM se ve de nuevo mucha aleatoriedad, siempre un consumo alto pero sin un crecimiento acorde al número de dispositivos. 3.4.4 Conclusiones sobre los experimentos de RAM y CPU Las pruebas realizadas han revelado de manera clara y detallada las capacidades y limitaciones del sistema Neo4j cuando se enfrenta a diferentes cargas de trabajo, caracterizadas por variaciones en la frecuencia de envío de datos y el número de dispositivos conectados. A continuación, se resumen las observaciones y conclusiones más relevantes de este análisis. Frecuencia de 100 ms por dato: • Capacidad Inicial del Sistema: Al principio, el sistema maneja adecuadamente hasta 300 dispositivos con una frecuencia de 100 ms por dato. Durante estas pruebas, se observan picos de consumo de CPU por encima del 80%, pero el sistema no llega a saturarse. • Primeros Signos de Sobrecarga: Se identifican picos aislados, como con 25 dispositivos, donde se alcanza un 95,29% de uso de CPU, pero estos picos son momentáneos y no indican una saturación sostenida. • Conclusión: A esta frecuencia, el sistema muestra una robustez considerable, gestionando eficientemente hasta 300 dispositivos con un volumen de 3000 datos por segundo. Frecuencia de 50 ms por dato: • Incremento de la Demanda: Al reducir la frecuencia a 50 ms, el volumen de datos se incrementa, alcanzando hasta 4980 datos por segundo con 249 dispositivos. • Punto Crítico Identificado: A este nivel de carga, el sistema muestra signos claros de estrés, con la CPU manteniéndose por encima del 95% durante varios segundos y una recuperación más lenta. • Conclusión: Aunque el sistema aún maneja la carga, se aproxima a su límite operativo, sugiriendo que una mayor optimización o un incremento en la capacidad de procesamiento podría ser necesario para evitar problemas de rendimiento. Frecuencia de 25 ms por dato: • Sobrecarga del Sistema: Esta prueba, la más agresiva, revela que el sistema se enfrenta a su límite máximo con 149 dispositivos enviando datos a 25 ms. El consumo de CPU se eleva a niveles insostenibles, y se observa un comportamiento errático, con períodos de casi inactividad que sugieren un reinicio o interrupción en el procesamiento. • Estabilidad de la RAM: A pesar de las variaciones en la carga de la CPU, el consumo de RAM se mantiene relativamente estable en todas las pruebas, lo que indica que la memoria no es el principal factor limitante en este escenario. • Conclusión: A frecuencias tan elevadas como 25 ms por dato, el sistema alcanza rápidamente un cuello 34 Evaluación experimental de botella, mostrando que la capacidad de procesamiento es insuficiente para manejar cargas tan altas de manera sostenida. Comparación General: • Uso de CPU vs RAM: Se ha observado que, mientras la CPU presenta un comportamiento más variable y susceptible a la carga de trabajo, la RAM mantiene un consumo alto pero estable. Esto sugiere que, en estas condiciones de prueba, la CPU es el recurso que primero alcanza su límite, actuando como el principal cuello de botella del sistema. • Optimización Necesaria: Dado que el sistema muestra una capacidad de recuperación más lenta a medida que aumenta la carga, sería necesario considerar optimizaciones en la gestión de tareas, la distribución de carga o incluso mejoras en el hardware si se pretende escalar el número de dispositivos conectados o la frecuencia de envío de datos. 3.5 Análisis del tiempo de respuesta Para analizar los tiempos de respuesta, se realizó un programa en Java que permitió automatizar las consultas y a su vez añadir más datos a la base de datos tras una consulta (ayudándonos del código previamente creado PruebaDemo.java). El nuevo código es TestTime.java. La función principal y la que más nos interesa para estas pruebas es ‘executeQuery’: Figura 32: Función de ejecución de consultas Esta función ejecuta la consulta proporcionada como parámetro, midiendo el tiempo antes y después de ejecutarla. Las consultas que se han probado han sido las siguientes: Nº de la consulta Consulta Descripción 1 MATCH c = shortestPath((p:Person:Paciente {dni: 'dniEjemplo100'})-[:ASIGNADO_A*..]- >(m:Person:Medico)) RETURN length(c) AS pathLength, nodes(c) AS pathNodes ORDER BY pathLength DESC LIMIT 10 Esta consulta fue diseñada en un primer momento pero descartada posteriormente. Se mantiene aquí para no variar la numeración del resto. 2 MATCH (p:Person:Paciente) RETURN p.dni AS pacienteDNI, d.modelo AS dispositivoModelo, count(o) AS cantidadObservaciones ORDER BY cantidadObservaciones DESC Recupera el DNI de cada paciente, el modelo del dispositivo que usa y la cantidad de observaciones registradas para ese paciente. Luego, ordena los resultados en orden 35 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario descendente según la cantidad de observaciones, mostrando primero a los pacientes con más observaciones. 3 MATCH(m:Person:Medico)<-[:ASIGNADO_A]- (p:Person:Paciente) WITH m, count(p) AS numeroDePacientes ORDER BY numeroDePacientes DESC LIMIT 5 RETURN m.nombre AS medicoNombre, numeroDePacientes Identifica a los cinco médicos con más pacientes asignados. Cuenta la cantidad de pacientes asignados a cada médico, ordena los resultados en orden descendente y muestra el nombre del médico junto con el número de pacientes que tiene. 4 MATCH(o:Observacion)-[r:PERTENECE_A]- >(p:Paciente) WHERE toInteger(o.dato) > 560 RETURN p Devuelve los pacientes cuyas observaciones superen un cierto umbral 5 MATCH (o:Observacion) WHERE datetime(o.timeStamp) > datetime('2024-1027T11:35:21') RETURN o Devuelve todos los datos recopilados después de cierta fecha 6 MATCH (n) RETURN n Devuelve todos los nodos 7 Igual a consulta 4 8 Igual a consulta 5 9 Igual a consulta 6 10 MATCH (a)-[r:PERTENECE_A]->(b) WITH r LIMIT 200000 DELETE r Elimina 200.000 relaciones PERTENECE_A 11 MATCH (c)-[r2:REALIZADA_POR]->(d) " WITH r2 LIMIT 200000 DELETE r2 Elimina 200.000 relaciones REALIZADA_POR 12 MATCH (a2:Observacion) WITH a2 LIMIT 200000 DELETE a2 Elimina 200.000 nodos Observación 13 Igual a consulta 4 14 Igual a consulta 5 36 Evaluación experimental 15 Igual a consulta 6 16 Igual a consulta 4 17 Igual a consulta 5 18 Igual a consulta 6 19 MATCH (p1:Person:Paciente)<-[:PERTENECE_A]- (o1:Observacion), (p2:Person:Paciente)<- [:PERTENECE_A]-(o2:Observacion) WHERE o1.dato=o2.dato RETURN p1.dni AS Dni1, p2.dni AS Dni2 Devuelve el dni de los Pacientes que tengan nodos Observación con el mismo valor en el campo dato Tabla 11: Consultas utilizadas Es de notar cómo se han repetido las consultas 4, 5 y 6 varias veces. Esto se ha hecho porque se han probado varios métodos a la hora de realizar las pruebas. 3.5.1 Método 1 El primer método que se usará para analizar los tiempos de respuesta es el siguiente: - Se ejecutan las consultas desde el proyecto en eclipse. Cada consulta es medida en términos de tiempo de ejecución (ms), capturando los resultados para su posterior análisis. - Justo después, se ejecuta pruebaDemo, para generar nodos y relaciones en la base de datos. - Ahora, con más nodos y relaciones que en la iteración anterior, vuelta a empezar. Los resultados de las pruebas 2 y 3 fueron: 37 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario Figura 33: Tiempos de respuesta consultas 2 y 3 En la Figura 33, en el eje Y tenemos el tiempo de ejecución en ms y en el eje X el número de nodos. En la esquina superior derecha tenemos la leyenda que indican el color de las consultas. Las próximas gráficas tendrán la misma estructura que esta, salvo que se indique lo contrario. Retomando de nuevo los resultados, las consultas 2 y 3 llegan a su máximo en la primera consulta, con apenas 778 nodos. El máximo es de 78ms para la consulta 2 y de 65 para la consulta 2. A medida que el número de nodos aumenta, los tiempos de ejecución se sitúan mayormente en 0, 1 y 2 ms, salvo en algunos picos puntuales que sí que superan los 10 ms en la consulta. Esto motivó a hacer pruebas con otro tipo de consultas y llegando hasta un mayor número de nodos, para ver si se mantenía esta tendencia. Figura 34: Tiempos de respuesta consultas 4,5 y 6 La Figura 34 muestra los resultados de las consultas 4, 5 y 6. A pesar de llegar a un mayor número de nodos, el 38 Evaluación experimental patrón se repite, mayormente obtendremos tiempos despreciables como resultado de la ejecución de las consultas. Decidimos resumir los datos en una tabla, para una mejor compresión. El desglose queda de la siguiente manera: la primera columna indica el tipo de consulta y la segunda el número de consultas de ese tipo que se han realizado. Los tiempos de respuesta se agrupan en las columnas siguientes. Consulta Total medidas 0 ms 1 ms 2 ms otros 4 150 9 109 22 10 5 150 22 111 8 9 6 150 31 98 12 9 Tabla 12: Resultados método 1 Podemos ver como las medidas de 0, 1 y 2 ms son las dominantes entre todos los casos, suponiendo el 93% para la consulta número 4, el 94% para las consultas número 5 y 6. Mientras que todas las medidas que toman un tiempo superior raramente se repiten. Algo que llama la atención a simple vista es que los picos se encuentran todos ubicados en el mismo momento, lo que da que pensar que la memoria caché está jugando un papel en estos resultados. Es por eso por lo que se diseñó y experimentó con un segundo método para la realización de estas pruebas. 3.5.2 Método 2 Estas pruebas siguen el mismo procedimiento a las pruebas anteriores, pero la memoria caché se redujo de 50MB a 10MB, con la intención de ver si el tiempo se veía influenciado con esta reducción. Pero, como podemos ver en la figura 35 el patrón que sigue es el mismo. Figura 35: Tiempos de respuesta consultas 7,8 y 9 Podemos comprobar que los picos siguen coincidiendo de unas consultas con otras, y, si vemos la tabla que analizamos el caso anterior el resultado sigue siendo parecido: Consulta Total medidas 0 ms 1 ms 2 ms otros 39 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario 7 200 57 131 4 8 8 200 69 118 5 8 9 200 78 111 3 8 Tabla 13: Resultados método 2 Siendo el porcentaje de medidas de 0, 1 y 2ms suponen un 96% para las tres consultas. Lo que sigue siendo un resultado que tampoco proporciona mucha información. Algo que si proporciona algo más de información, es la comparación de las consultas con distinta memoria caché: Figura 36: Comparación tiempos de respuesta consultas 4 y 7 Si comparamos las consultas 4 y 7, teniendo que cuenta que son la misma consulta, pero con distinta memoria caché, se observa perfectamente cómo la posición de los picos cambia, pero el tiempo de las consultas sigue siendo bastante parecido. Así que, sabemos que esto sí que se debe a la memoria caché. La información recopilada, nos llevará a los métodos 3 y 4 en los que intentamos obtener unos resultados que nos permitan un mejor análisis. 3.5.3 Método 3 Tras analizar los resultados anteriores e investigar el lenguaje Cypher, encontramos una sentencia que podría ayudarnos en nuestro caso, para poder analizar el tiempo de cada consulta sin que influya la memoria caché. Este método seguirá el mismo procedimiento que el método 1, con la adición de la sentencia ‘CALL db.clearQueryCaches();’ tras añadir los nodos y relaciones a la base de datos. Este método se utilizó para las pruebas 13, 14 y 15. Para la Figura 37 se ha usado en el eje X una escala logarítmica, debido a que se alcanzó un alto número de nodos y esto permite una mejor visualización la gráfica. A pesar de estar usando la sentencia para borrar la caché, los tiempos parece que también están siguiendo un patrón, con muchas subidas y bajadas en los tiempos. Lo que nos da la sensación al ver esta gráfica es que los tiempos a los que sube y a los que baja parece que están rondando los mismos valores. 47 4 CONCLUSIONES Y LÍNEAS FUTURAS 4.1 Conclusiones El presente trabajo ha permitido evaluar de forma experimental el rendimiento de la base de datos Neo4J en un entorno simulado de monitorización de pacientes, representando escenarios propios del ámbito sanitario. A lo largo del trabajo se han realizado pruebas de inserción masiva de datos, simulando lo que sería el flujo de información que se genera en sistemas IoMT. Las conclusiones que podemos sacar del trabajo realizado se exponen a continuación. 4.1.1 Consumo de CPU A medida que se incrementó el número de dispositivos simulados y la frecuencia de envío de datos, se observó un aumento progresivo en el consumo de CPU. Si bien el sistema mantuvo un rendimiento estable durante la mayoría de las pruebas, con tasas superiores a 3000 datos por segundo comenzó a mostrar signos de saturación. Es importante destacar, que a pesar de que haya llegado a saturarse en muchos casos, el sistema siempre se adapta y con el paso del tiempo reduce drásticamente el consumo de CPU, lo que indica que el sistema podría perder algunos datos en los primeros segundos, pero con el tiempo se estabiliza y recepciona los datos sin problema. La figura 42 representa la media de todas las pruebas con respecto al paso del tiempo. No filtra por dispositivos ni frecuencia. Si nos fijamos en la figura 42, se observa lo que estamos comentando, con el paso del tiempo el consumo de CPU tiende a disminuir. Figura 42: Media de CPU con el paso del tiempo. En pruebas más agresivas, el sistema alcanzó picos superiores al 95% de uso de CPU, provocando cuellos de 48 Conclusiones y líneas futuras botella y ralentización en la inserción de datos. El mayor cuello de botella encontrado fue con 200 dispositivos a frecuencia de 25 ms, en la gráfica vimos que se saturó al principio y de repente el consumo cayó por completo durante unos 5 segundos para posteriormente volver a tener un consumo alto. En ello se identifica un cuello de botella. Este comportamiento evidencia la necesidad de optimizar el uso de recursos y mejorar la capacidad de Neo4J para manejar cargas de trabajo más pesadas sin comprometer la integridad de los datos. 4.1.2 Consumo de memoria El uso de memoria RAM se mantuvo elevado de forma constante, lo que sugiere que Neo4J realiza una gestión agresiva de memoria para optimizar el rendimiento de las consultas. Sin embargo, esta estrategia puede convertirse en una limitación en sistemas con recursos de hardware limitados. A pesar de este elevado consumo, la base de datos mantuvo su estabilidad, lo que indica que Neo4J prioriza la disponibilidad y velocidad de las consultas por encima del ahorro de memoria. 4.1.3 Manejo de consultas Las pruebas de consulta arrojaron resultados positivos incluso con bases de datos de gran tamaño, lo que subraya la capacidad de Neo4j para optimizar búsquedas y realizar consultas complejas de forma eficiente. Este comportamiento permite su aplicación en entornos críticos donde el acceso a información en tiempo real es vital. Las consultas que involucran múltiples relaciones entre nodos se ejecutaron con rapidez, lo que sugiere que el motor de búsqueda de Neo4j está bien adaptado para trabajar con datos densamente conectados. Neo4j ha demostrado ser una herramienta robusta para gestionar grandes volúmenes de datos interconectados, ofreciendo tiempos de respuesta adecuados en escenarios de baja a media carga de trabajo. La eficiencia de las consultas basadas en relaciones complejas resalta la idoneidad de este tipo de base de datos para sistemas donde las conexiones entre entidades son cruciales. La estructura de grafos facilita la recuperación de datos y el análisis de redes complejas, lo que permite detectar patrones y correlaciones que serían difíciles de identificar mediante bases de datos relacionales tradicionales. El mayor inconveniente en cuanto a las consultas sería el entorno gráfico de Neo4j, que añade un retraso de hasta 100 veces el tiempo de la consulta en los casos que se necesita representar una gran cantidad de nodos y relaciones. Esta restricción desaparece cuando se prescinde del entorno gráfico. En general, Neo4j ha demostrado ser una opción viable y eficiente para sistemas sanitarios que requieren el análisis y almacenamiento de datos interrelacionados. No obstante, es necesario considerar la escalabilidad y el consumo de recursos en implementaciones a gran escala. Este trabajo proporciona una base sólida para futuras investigaciones que busquen mejorar la infraestructura de bases de datos en el ámbito sanitario. 4.2 Líneas futuras A partir de los resultados obtenidos, se identifican diversas líneas futuras que podrían contribuir a mejorar y ampliar el alcance del proyecto: • Rendimiento: Para llevar más al límite la base de datos sería interesante hacer una base de datos con más relaciones, es decir, tener una estructura más compleja, además de probar consultas más complejas. Todo esto con el fin de llevar más al límite la base de datos. • Paralelización y distribución de carga: Una de las mayores restricciones que ha tenido este trabajo ha sido el uso de un solo dispositivo. Tanto la base de datos como los “dispositivos” estaban alojados en el mismo ordenador. Para investigaciones futuras sería 49 Evaluación experimental de Neo4J para su aplicación en el dominio sanitario interesante alojar la base de datos en un Docker, de esta manera tendría más capacidad de computación que la que tendría en un ordenador. Sería interesante también implementar un entorno distribuido que permita el procesamiento en paralelo de los datos, de manera que no se localicen todos los hilos desde un mismo dispositivo. Esta distribución de carga podría llevar a un mayor número de dispositivo mandando desde distintas localizaciones, esto se acerca más a la realidad y el rendimiento mejoraría. • Integración con sistemas reales de IoMT: Para comprobar definitivamente su posible implementación, la realización de pruebas de campo en un entorno real sería indispensable. Realizar pruebas con dispositivos médicos reales mandando los datos a la base de datos (idealmente virtualizada en un Docker) facilitaría la validación del sistema en situaciones operativas reales, identificando posibles limitaciones que en un entorno simulado no podríamos detectar. • Estudio de soluciones híbridas: En el caso de que algún estudio futuro no dé los resultados deseados, o no sean óptimos, otro posible estudio sería la combinación de bases de datos basadas en grafos con otros sistemas relacionales o NoSQL, lo que podría ofrecer un equilibrio entre el rendimiento y la flexibilidad, permitiendo almacenar datos críticos de forma eficiente y realizar consultas complejas sobre grafos. El desarrollo de arquitecturas híbridas permitiría aprovechar lo mejor de ambos mundos, utilizando bases de datos relacionales para datos estructurados y Neo4J para datos con relaciones densas. Estas líneas futuras no solo contribuirán a mejorar el rendimiento del sistema, sino que también ampliarán su aplicabilidad en entornos críticos donde la monitorización y el análisis de datos juegan un papel fundamental en la toma de decisiones médicas. 50 Referencias REFERENCIAS [1] Rose, K., Eldridge, S., & Chapin, L. (2015). The internet of things: An overview. The internet society (ISOC), 80(15), 1-53. [2] Robinson, I., Webber, J., & Eifrem, E. (2015). Graph Databases: New Opportunities for Connected Data. O'Reilly Media. [3] Vishnu, S., Ramson, S. J., & Jegan, R. (2020, March). Internet of medical things (IoMT)-An overview. In 2020 5th international conference on devices, circuits and systems (ICDCS) (pp. 101-104). IEEE. [4] Neo4j, Inc. (2021). Neo4j Java Driver 4.3 - User Manual. Retrieved from https://neo4j.com/docs/javamanual/current/ [5] Partner, C. (2014). Neo4j in Action. Manning Publications. [6] Gamma, E., & Beck, K. (1999). Contributing to Eclipse: Principles, Patterns, and Plugins. Addison-Wesley Professional. [7] Smith, W. (2014). OSHI: Operating System and Hardware Information. Available: https://github.com/OSHI/OSHI [8] "Tableau Software: Data Visualization for Business Intelligence," Tableau Software, 2023. [Online]. Available: https://www.tableau.com/