Estudio de Rendimiento de Modelos de Datos en Bases de Datos NoSQL Róttoli, Giovanni Daián AB 1 ; Lopez Nocera, Marcelo A 2 ; Pollo-Cattaneo, Ma. Florencia AB 3 A Grupo de Estudio en Metodologías de Ingeniería de Software (GEMIS). Ingeniería en Sistemas de Información - Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. Argentina. B Ingeniería en Sistemas de Información. Facultad Regional Concepción del Uruguay. Universidad Tecnológica Nacional. Argentina 1 gd.rottoli@gmail.com 2 zappapet@yahoo.com 3 flo.pollo@gmail.com Resumen Con la llegada de las nuevas tecnologías de Bases de Datos y la tendencia denominada genéricamente NoSQL, las empresas pueden optar por migrar sus datos a estas plataformas por diferentes motivos. Muchas veces, diseñar una arquitectura de bases de datos que se adapte a la estructura de los datos actuales, implica sacrificar ciertas características en pos de la compatibilidad. Surgen así interrogantes como los siguientes: Cuál es el rendimiento entre las bases de datos NoSQL si se mantiene la estructura de los datos al migrar de una tecnología a otra? Qué tan beneficioso es mantener un modelo genérico entre las distintas bases de datos y aprovechar solamente las características del motor? Estas preguntas podría planteárselas una organización que está en vías de crecimiento, con la consiguiente dificultad para tomar una decisión sobre la estructura de sus datos. En este contexto, el presente trabajo propone realizar una serie de pruebas con datos de distinta naturaleza, manteniendo un esquema de modelado que en principio es relacional, por cada una de las tecnologías de bases de datos NoSQL; como así también otro grupo de pruebas con modelos adecuados a cada una de dichas tecnologías. Con estas experiencias se busca determinar el impacto que tendría migrar los datos sin diseñar una estructura acorde a la tecnología NoSQL en cuestión. La medida a tener en cuenta es el tiempo de búsqueda, sin dejar de lado otras cuestiones como son, por ejemplo, la falta de concordancia de la naturaleza de los datos con la forma de representarlos (lo que se conoce como impedance mismatch). 1. Introducción La llegada de NoSQL se da frente a un nuevo universo de problemáticas relacionadas con el surgimiento del fenómeno de Big Data, debido a la incapacidad de las bases de datos tradicionales (relacionales, que utilizan SQL) de lidiar con estas cuestiones [1; 2; 3; 4]. El primer problema general no resuelto por las bases de datos relacionales es el de la discordancia de la impedancia (impedance mismatch), es decir, la diferencia entre el modelo y las estructuras de datos que están en memoria. Esta diferencia implica la necesidad de efectuar una traducción entre la representación de datos del modelo relacional y la representación de los datos que están en memoria [1; 2]. Otro problema no resuelto es que las estructuras relacionales se basan sobre tuplas (filas) que no pueden contener a su vez otras estructuras complejas, como listas o registros anidados. Las estructuras NoSQL permiten el uso de agregados y un manejo más acabado de las relaciones entre entidades, y además permiten el manejo de un esquema mucho más flexible, al punto de no necesitar ningún esquema predeterminado, lo que se conoce como schemaless (o sea, sin esquema) [1; 5].
Tabla 1: Problemas solucionados por los distintos tipos bases de datos NoSQL Por otra parte, el crecimiento acelerado de la cantidad de datos disponible manifiesta la necesidad de escalar el almacenamiento físico, lo cual significa utilizar servidores cada vez más grandes y más potentes, con procesadores más poderosos, discos con más espacio y más uso de memoria volátil. Este crecimiento, que se conoce como escalamiento vertical, es caro y limitado [1;6]. En este caso, la alternativa es utilizar muchas máquinas pequeñas en clúster, lo que se conoce como escalamiento horizontal [1]. Este modelo de crecimiento hacia afuera utiliza PCs estándar que actúan como servidores, por lo que es más barato, y también más resiliente (pues el clúster continúa funcionando si una PC se daña, hasta que sea repuesta), lo que lo hace una solución mucho más confiable también. Sin embargo, las bases de datos relacionales no están diseñadas para correr en estas arquitecturas distribuidas (sin contar que los productos licenciados que sí lo permiten no son económicamente accesibles). Muchas compañías, de esta forma, optan por la migración de sus datos a tecnologías NoSQL, a fin de resolver las problemáticas de esta índole que se presentan. Sin embargo, esta migración hace necesaria una adaptación de las estructuras de los datos para funcionar correctamente en estas nuevas tecnologías. Ante tal situación, surge la pregunta Cuál es el impacto de no realizar esta adaptación de las estructuras, aunque sea en una primera instancia, a fin de reducir los costos de la migración? El objetivo de este trabajo es entonces, determinar cual es el impacto de realizar migraciones de datos sin diseñar estructuras acordes a las tecnologías NoSQL, mediante la utilización de pruebas comparativas. A continuación, se define en detalle esta problemática (sección 2) para luego proponer una solución a la misma (sección 3). Esta solución se implementa mediante diversas pruebas de concepto (sección 4). Luego de realizadas las mismas, se exponen las conclusiones obtenidas (sección 5). 2. Definición del Problema El término NoSQL se conoce por primera vez en 2009 y hace referencia a bases de datos que no utilizan el lenguaje SQL estándar para sus consultas. Se trata de una nueva tendencia donde coexisten varias tecnologías, generalmente proyectos de código abierto, que corren bajo arquitecturas de procesamiento distribuido y tienen modelos de datos distintos del relacional tradicional [1; 2; 4; 7]. Estas herramientas tienen la característica de operar sin esquemas, permitiendo agregar campos libremente a los registros de la base de datos, sin tener que definir cambios previos en la estructura, teniendo además la particularidad de permitir el uso de agregados, estructuras complejas anidadas que posibilitan adaptar la estructura de datos según convenga en cada situación. Por ejemplo, un Cliente podría contener una Lista de todos sus pedidos, dentro de un solo registro, sin tener que utilizar relaciones para representarlo. Estos motores de bases de datos poseen además la particularidad de ser escalables de manera horizontal, operando sobre clusters, abaratando los costos de los servidores y aumentando la seguridad de todo el sistema de base de datos. Esta característica hace de NoSQL una solución idónea frente a la problemática de operar en ambientes donde la cantidad de datos crece enormemente de manera periódica, al no estar las bases de datos tradicionales (relacionales) preparadas para trabajar bajo estas arquitecturas de servidores, o bien siendo poco accesibles económicamente aquellas que si lo permiten [1; 8; 9; 10; 11; 12]. Por otro lado, NoSQL además se muestra útil para resolver las problemáticas de: bajo rendimiento para grandes volúmenes de datos, necesidad de paralelismo de procesamiento, discordancia de la impedancia (los datos en memoria tienen una estructura distinta a la que se almacena en la base de datos física), dinamismo de las estructuras, y la complejidad del modelado [1, 5; 7; 8; 9; 10; 11].
Los diferentes tipos de tecnologías NoSQL (Documental, Columnar, Clave Valor y Gráfica), responden de diferente manera a las problemáticas enunciadas anteriormente. En la Tabla 1 se puede observar esta comparativa, siendo las marcadas con una X aquellas que responden positivamente frente al problema [1]. En la actualidad, con la llegada del fenómeno de Internet y posteriormente de Big Data, las grandes empresas se ven motivadas a utilizar nuevas tecnologías NoSQL para responder a sus propias necesidades, como lo son los caso de Google 1, Amazon 2, Twitter 3 y demás grandes organizaciones que manejan y generan en cada instante grandes cantidades de datos [6]. A su vez, empresas de proporciones más pequeñas se pueden ver en la necesidad de migrar sus datos (o al menos una parte de ellos) y utilizar bases de datos NoSQL para resolver sus problemáticas. Sin embargo, estas migraciones desde modelos relacionales a nuevos modelos especialmente adaptados poseen costos no solo económicos, sino también relacionados con el cambio de estructura, como por ejemplo, la falta de normalización de los mismos, que acarrearía inconsistencias en la base de datos. En este punto interesa conocer cuál es el impacto de adecuar especialmente la base de datos para la realidad de la organización y de las aplicaciones que hacen uso de esos datos, en vez de utilizar una estructura más rígida como lo es una estructura relacional. Para dar respuesta a este interrogante, en el presente trabajo se prevé realizar consultas sobre distintas estructuras de datos en diferentes bases de datos (tanto SQL como NoSQL) a fin de medir la eficiencia de la ejecución de las mismas [13, 14]. 3. Solución Propuesta Como se ha mencionado, en el presente trabajo se busca verificar la eficiencia de las bases de datos NoSQL al trabajar con modelos de datos que no corresponden con la tecnología en cuestión, siendo en este caso, modelos relacionales. Para ello, se poseen distintos casos de estudios, diseñados para evidenciar relaciones complejas entre los datos, haciendo hincapié en estos vínculos, más allá de la complejidad de los datos en sí mismos. Los casos de estudios son modelados de manera relacional para ser implementados bajo distintas tecnologías NoSQL, como lo son MongoDB1 (base de datos documental), Cassandra2 (base de datos Columnar), Redis3 (base de datos Clave-Valor) y Neo4J4 1 Google: http://www.google.com 2 Amazon: http://www.amazon.com 3 Twitter: http://www.twitter.com (base de datos gráfica). Posteriormente, dichos casos de estudio son modelados de manera específica para cada tecnología de bases de datos NoSQL [2]. Una vez implementados los modelos en las tecnologías citadas, se sigue la carga de datos generados mediante algoritmos diseñados para tal fin, y se mide el tiempo de ejecución de consultas complejas sobre los mismos. Por consultas complejas, se significa consultas que involucran varias relaciones entre las entidades. Los modelos relacionales, a su vez, se prueban bajo un motor de bases de datos relacional, para poseer un punto de referencia con el tiempo que tardarían antes de ser migrados. 4. Pruebas de Concepto En esta sección se procede a enunciar cuáles fueron las herramientas y tecnologías implicadas en el desarrollo de las pruebas de concepto (sección 4.1), las actividades que se desarrollaron (sección 4.2), los resultados obtenidos (sección 4.3) y un análisis de los mismos (sección 4.4) 4.1. Herramientas Utilizadas Para la realización de las actividades de experimentación que posteriormente serán descriptas, se utilizan diversas tecnologías de bases de datos NoSQL, corriendo sobre un nodo simple (Computadora Personal) con un Intel Core I5 y 4Gb de RAM, con un sistema operativo Linux Mint 17. Los motores de bases de datos utilizados, como ya se menciona anteriormente, son: PostgreSQL 9.3 MongoDB 2.6 Redis 2.8.11 Neo4J 2.1.2, Cassandra 2.0.8 Finalmente, tanto las consultas como la implementación y carga de datos fueron llevadas a cabo utilizando Python 2.7 y las últimas versiones al 10 de julio de 2015 de las librerías PyGreSQL 4, PyMongo 5, Redis-Py 6, Py2Neo 7 y Cassandra-Driver 8. 4 PyGreSQL: http://www.pygresql.org/ 5 PyMongo: http://api.mongodb.org/python/current/ 6 Redis-Py: https://redis-py.readthedocs.org/en/latest/ 7 Py2Neo: http://py2neo.org/2.0/ 8 Cassandra-Driver: https://datastax.github.io/python-driver/
Figura 1: Diagrama de Entidades utilizado para el Caso de Pruebas Nº 1 Figura 2: Diagrama de Entidades utilizado para el Caso de Pruebas Nº 2 4.2. Procedimiento Se diseñaron tres casos de pruebas haciendo hincapié en la complejidad de las relaciones entre las entidades de datos y no en la de los datos en sí, a fin de trasladar dicha complejidad a las consultas [15]. El primer caso de prueba consiste en un conjunto de Facturas de compra de determinados Productos, y las relaciones de Amistad entre las Personas que compraron dichos Productos. Se puede observar el diagrama de entidades en la Figura 1. El segundo caso de prueba, se plantea en el área hospitalaria, para persistir internaciones de pacientes, un médico encargado del mismo, cual fue la cama y habitación que se le asigna y el encargado de enfermería designado a dicha habitación. El diagrama de entidades utilizado se puede observar en la figura 2. El tercer y último caso de prueba plantea un escenario de registro de alumnos, la inscripción de los mismos a determinadas carreras, y la designación de profesores a materias de dichas carreras. El diagrama de entidades correspondiente a este caso de estudio con el diagrama de entidades que se observa en la figura 3. Los modelos son implementados tanto en la base de datos Relacional como en las NoSQL, insertando un millón (1.000.000) de registros por cada entidad, mediante una aplicación cliente. Estos datos no son datos reales, sino que son generados automáticamente por la aplicación. Por ejemplo, los nombres de personas corresponden al patrón nombre_1, nombre_2,, nombre_n. Posteriormente se construyen modelos específicos para cada una de las tecnologías NoSQL para cada uno de los casos de estudio, resultando por cada uno de estos últimos, un modelo Columnar, un modelo Documental, uno de tipo Clave-Valor y otro Gráfico [15]. De la misma forma, se utilizan un millón (1.000.000) de inserciones por cada entidad de datos, siendo estos datos ficticios y generados de la misma manera que para los modelos relacionales. Los modelos NoSQL se construyeron evitando normalizar la estructura de los datos, a fin de aprovechar las particularidades de cada tecnología, tales como el
Figura 3: Diagrama de Entidades utilizado para el Caso de Pruebas Nº 3 anidado de documentos en las bases de datos Documentales y los índices de las bases de datos Clave- Valor y Columnar. Tanto para los modelos relacionales como los modelos dedicados a las tecnologías NoSQL, se ejecutan consultas midiendo el tiempo necesario para que cada una de ellas devuelva resultados. Este proceso fue llevado a cabo una aplicación cliente al no poder las bases de datos NoSQL realizar operaciones N-Join directamente sobre los datos. Las consultas en cuestión buscan obtener la siguiente información: Caso 1. Caso 2. Caso 3. Determinar quiénes son los amigos del cliente que compró un producto determinado antes de una fecha dada. Determinar quiénes fueron los enfermeros a cargo de las habitaciones en las que se encuentran internados pacientes de doctores de una determinada especialidad, antes de una fecha determinada. Obtener los alumnos inscriptos a carreras con materias con designaciones de determinado tipo, de profesores con título determinado. Estas consultas están diseñadas con el fin de involucrar operaciones N-Join entre la mayoría de las entidades de datos, a fin de evaluar el comportamiento de las bases de datos NoSQL al trabajar con estructuras de datos normalizadas [15]. Los resultados se detallan y se analizan en los apartados siguientes. 4.3. Resultados obtenidos Las implementaciones de los modelos relacionales tanto en la base de datos relacional como en las NoSQL, permiten observar el comportamiento de estas últimas frente a una gran normalización de la estructura de datos y compararlo con las primeras. La base de datos documental MongoDB, permite referenciar las distintas entidades de datos (documentos, en este caso), posibilitando la carga de datos como si fuese en una base de datos relacional. Las bases de datos NoSQL Columnar y Clave-Valor, permiten la implementación de las estructuras relacionales y la carga de datos, a pesar de no poseer soporte para referenciar entidades, pero simulándolo mediante el uso de identificadores que luego serían utilizados para simular las operaciones de Join. En contraste a las anteriores, resulta imposible la carga de datos en la base de datos NoSQL Gráfica, ya que el poder de procesamiento necesario para hacerlo supera ampliamente el disponible para la realización de los experimentos, ocasionando problemas de ejecución de los procesos en la computadora cliente. Por esta última razón, al no poder contar con una implementación del modelo relacional en la base de datos
NoSQL Gráfica, se decide no considerarla para la realización de los experimentos, a fin de poder incorporarla en futuros trabajos, utilizando mayor poder de procesamiento. Una vez cargados los datos en los motores de bases de datos relacional y NoSQL, se ejecutan las consultas, siendo posible obtener respuestas esperadas con la base de datos Relacional, Documental y Columnar, mas no así con la base de datos Clave-Valor, debido a que no es posible utilizar los valores de los pares en las consultas, esto es, mediante cláusulas where, pudiendo únicamente acceder mediante las claves. Por este motivo no se tienen resultados comparativos en este último caso. Posteriormente, al implementar las estructuras diseñadas especialmente para cada tecnología NoSQL en particular (con excepción de la base de datos Gráfica, como se mencionó anteriormente) y habiendo ejecutado las consultas, se obtienen resultados que pueden compararse con los obtenidos con los modelos relacionales. Los resultados obtenidos se pueden apreciar en la Tabla 2, para el Caso 1, Tabla 3 para el segundo caso, y Tabla 4, para el caso de pruebas número 3. Tabla 2.Comparativa de tiempos de ejecución de consulta para el Caso de Pruebas Nº 1, en segundos Modelo Tipo de Base de Datos Relacional Específico Relacional 0.172 Documental 0.575 0.000143 Clave Valor Sin Resultados 0.00193 Columnar 0.0787 0.00731 Tabla 3. Comparativa de tiempos de ejecución de consulta para el Caso de Pruebas Nº 2, en segundos Modelo Tipo de Base de Datos Relacional Específico Relacional 1.986 Documental 10.348 0.00107 Clave Valor Sin Resultados 0.0102 Columnar 1.274 0.0149 Tabla 4. Comparativa de tiempos de ejecución de consulta para el Caso de Pruebas Nº 3, en segundos Modelo Tipo de Base de Datos Relacional Específico Relacional 201.851 Documental 303.238 0.0468 Clave Valor Sin Resultados 0.0862 Columnar 258.650 0.589 4.4. Análisis de Resultados En función de los datos obtenidos de la ejecución del procedimiento descripto en la sección 4.2 y presentados en la sección 4.3, se realiza un análisis de los mismos para su comprensión. Cassandra, la base de datos Columnar es la que mejor se adapta al modelo relacional, obteniendo tiempos de 0.0787 segundos y de 1.274 segundos, siendo estos incluso mejores que los respectivamente obtenidos con la base de datos relacional, PostgreSQL (0.172 segundos y 1.986 segundos), como se observa en las tablas 2 y 3. Se puede observar, además, que la base de datos Documental, a pesar de poseer soporte para referencias, no se comporta adecuadamente frente a una estructura de documentos normalizada, elevando notablemente el tiempo necesario para obtener un resultado de la consulta, incluso hasta quintuplicándolo, mostrando valores de 10.348 segundos frente a los 1.986 segundos que requiere la base de datos relacional, como se aprecia en la tabla 3, a pesar de ser la base de datos que mejor tiempo de respuesta ha mostrado con un modelo específico, en los tres casos de prueba analizados (0.000143, 0.00107 y 0.0468 segundos respectivamente). Los modelos específicos para cada una de las tecnologías, mejoran notablemente la eficiencia de las búsquedas, resultando el modelo documental en 4021 veces más rápido (tabla 2) y el modelo Columnar 440 veces más rápido (tabla 4). Se aprecia, además, que las bases de datos NoSQL superaron a la base de datos relacional en la obtención de resultados para la consulta, con los modelos específicos, en todos los casos de prueba. Esto evidencia cómo las nuevas tecnologías priorizan la accesibilidad por sobre la seguridad de los datos, en cuanto a consistencia.
5. Conclusiones Las tecnologías NoSQL aparecieron con fuerza, como una nueva moda o tendencia [1]. Esta tendencia podría provocar que no se evalúe el impacto de las migraciones de datos sobre distintos aspectos de seguridad. El trabajo realizado muestra migraciones de datos desde bases de datos relacionales tradicionales a bases de datos NoSQL, no adecuando las estructuras de datos según las necesidades de cada tecnología. Es notable que el mantener una estructura fuertemente normalizada impacta drásticamente sobre la eficiencia de las bases de datos, pudiendo incluso quintuplicar el tiempo necesario para realizar una consulta, por lo que resulta imprescindible una re-estructuración de los datos según el paradigma de modelado de la base de datos NoSQL elegida, y en función de las consultas más habituales que se realizarán sobre el motor. Sin embargo, en muchas oportunidades es necesario mantener estructuras fuertemente normalizadas, por lo que las bases de datos relacionales siguen siendo altamente necesarias. Finalmente, la selección de las herramientas de almacenamiento de datos, se debería realizar aprovechando las características de cada una de ellas, optando por aquella que mejor se adecúe a las necesidades, pudiendo incluso utilizar modelos políglotas, haciendo uso de varias tecnologías de datos a la vez [1]. Como futuras líneas de trabajo, se propone profundizar la utilización de clusters, con al menos 50 nodos, y volver a realizar el procedimiento presentado en el presente documento, a fin de validar los resultados obtenidos, incorporando además modelos políglotas y en particular Neo4J, que por ser orientado a grafos, tiene mucha más afinidad con el modelo relacional, en cuanto a que se trata de un modelo que privilegia la consistencia y la disponibilidad antes que la partición de red[8]. 6. Referencias [1] Sadalage, P. J., & Fowler, M. (2012). NoSQL distilled: a brief guide to the emerging world of polyglot persistence. Pearson Education. [2] Dumbill, E. (2012). Planning for big data. " O'Reilly Media, Inc.". [3] Mannino, M. (2007). Administración de Base de Datos (3ª ed.). MCGRAW-HILL / Interamericana de México ISBN 9789701061091 [4] Redmond, E. & Wilson, J. (2012). Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement (1st ed.). Raleigh, NC: The Pragmatic Programmers, LLC. ISBN-13: 978-1934356920 ISBN-10: 1934356921 [5] Hecht, R., & Jablonski, S. (2011). NoSQL evaluation: A use case oriented survey. [6] López García, D. (2013). Análisis de las posibilidades de uso de Big Data en las organizaciones. Disponible On- Line: http://hdl.handle.net/10902/4528 (verificado el 10-07-2015) [7] Arévalo, H. H. R., & Cubides, J. F. H. (2013). Un viaje a través de bases de datos espaciales NoSQL. Redes de ingeniería, 4(2), 57-69. [8] Nayak, A., Poriya, A., & Poojary, D. (2013). Type of NOSQL Databases and its Comparison with Relational Databases. International Journal of Applied Information Systems, 5(4), 16-19. [9] Strauch, C., Sites, U. L. S., & Kriha, W. (2011). NoSQL databases. Lecture Notes, Stuttgart Media University. [10] Del Busto, H. G., & Enríquez, O. Y. (2013). Bases de datos NoSQL. Revista Telem@ tica, 11(3), 21-33. [11] Bugiotti, F., & Cabibbo, L. (2013). A Comparison of Data Models and APIs of NoSQL Datastores. Dipartamento di Ingegneria della Università di Roma. [12] Nance, C., Losser, T., Iype, R., & Harmon, G. (2013, March). Nosql vs rdbms-why there is room for both. In Proceedings of the Southern Association for Information Systems Conference (pp. 111-116). [13] Róttoli, G. D.; López-Nocera, M.; Pollo-Cattaneo, M. F. (2015) Utilización de NoSQL para resolución de problemas al trabajar con cantidades masivas de datos. Proceedings XVII Workshop de Investigadores en Ciencias de la Computación (Base de Datos y Minería de Datos). Artículo 6865. ISBN 978-987-633-134-0. [14] Pollo, M., López, M. & Rottoli, G. (2014) Rendimiento de tecnologías NoSQL sobre cantidades masivas de datos. Cuaderno Activa, 6, pp11-17. ISSN: 2027 8101 [15] Róttoli, G., Lopez, M. & Pollo, M. (2015). Modelos de Bases de Datos Relacionales y NoSQL para pruebas de Rendimiento. Disponible Online: http://sistemas.frba.utn.edu.ar/grupogemis/?p=540 (verificado el 27-07-2015)