Comparativa del rendimiento de bases de datos NoSQL con grandes volúmenes de datos

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on: Tecnolog´ ıas de la informaci´ on Comparativa del rendimiento de bases de datos NoSQL con grandes vol´umenes de datos Autor: Victor Guijarro Esteban Tutor: D˜na. Carmen Hern´andez D´ıez 2 Resumen En la actualidad, el uso de bases de datos NoSQL se ha extendido de forma generalizada, llegando a sustituir a las bases relacionales SQL “cl´asicas” en muchos aspectos. Esto es debido principalmente a la gran cantidad de informaci´on que se hace necesario almacenar y analizar, y a la necesidad imperiosa de su disponibilidad permanente. Las limitaciones de las bases de datos relacionales en cuanto entra en juego ese curioso, y en ocasiones esquivo, concepto al que llamamos (( Big Data )) , se hacen palpables, y no es demasiado arriesgado decir que las bases de datos NoSQL est´an originadas en las necesidades espec´ıficas para tratar con recursos de datos extremadamente grandes o complejos. Existen varios tipos bien diferenciados de bases de datos NoSQL, con sus propias caracter´ısticas y peculiaridades, pero en el mercado actual destacan dos de ellas, cada una perteneciente a un tipo diferente; MongoDB y Cassandra. Estas bases de datos NoSQL est´an entre los 10 motores de bases de datos m´as usados en la actualidad, pero lo cierto es que hace ya m´as de un lustro que estas Bases de Datos NOSQL est´an entre las m´as usadas, y parece un ejercicio muy interesante analizar y comprender su funcionamiento, y probar sus virtudes o defectos ante un gran volumen de datos Conceptos clave: Base de datos, NoSQL, Big Data, Rendimiento, MongoDB, Cassandra. 3 4 Tabla de Contenidos 1. Introducci´on 11 1.1. Marco del proyecto y Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.2. Objetivos ............................................. 14 1.3. Metodolog´ıa............................................ 15 2. Big Data y NoSQL 17 2.1. Elnuevomundo:BigData.................................... 19 2.2. La nueva alternativa: NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1. Diferencias con las bases de datos relacionales: ACID Vs BASE . . . . . . . . . . . 23 2.2.2. Tipos de bases de datos NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.3. Escalabilidad horizontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.4. VentajasyDesventajas ................................. 30 3. MongoDB y Cassandra 33 3.1. MongoDB............................................. 33 3.1.1. ¿Qui´enusaMongoDB? ................................. 34 3.1.2. Caracter´ısticas ...................................... 35 3.1.3. Consultas......................................... 37 3.1.4. Naturalezadistribuida.................................. 39 3.1.5. Seguridad......................................... 41 3.2. ApacheCassandra ........................................ 42 3.2.1. ¿Qui´enusaCassandra? ................................. 42 3.2.2. Caracter´ısticas ...................................... 43 3.2.3. Modelodedatos ..................................... 44 3.2.4. LenguajedeConsultas.................................. 45 3.2.5. Naturalezadistribuida.................................. 47 3.2.6. Seguridad......................................... 49 3.3. Principalesdiferencias ...................................... 50 4. Preparaci´on del experimento 53 4.1. Obtenci´ondelosdatos...................................... 53 4.1.1. Elecci´on del conjunto de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.1.2. Descripci´on del conjunto de datos elegido . . . . . . . . . . . . . . . . . . . . . . . 55 4.2. Obtenci´on de los modelos de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.1. Modelado de datos NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.2. Modelado de los datos elegidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3. Adecuaci´ondelosficheros.................................... 59 4.4. Implementaci´on de las bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5 4.4.1. Creaci´on de las bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.5. M´aquinas de prueba y m´etricas de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . 61 5. Pruebas realizadas 63 5.1. Operaciones sobre las bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.1.1. Inserciones ........................................ 63 5.1.2. Consultas......................................... 64 5.1.3. Actualizaciones...................................... 65 5.1.4. Borrado.......................................... 66 5.2. Mediciones y Ejecuci´on de comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6. An´alisis de los resultados 69 6.1. MongoDB............................................. 69 6.2. Cassandra............................................. 70 6.3. Comparaci´ongr´afica ....................................... 72 6.4. Valoraci´on de las hip´otesis formuladas y conclusiones extra´ıdas del experimento . . . . . . 75 7. Conclusiones 77 Anexos 83 A. Contenido del soporte digital 85 B. Comandos y logs 87 I. Comandos para la modificaci´on de la fuente de datos . . . . . . . . . . . . . . . . . . . . . 87 II. Hardware de la m´aquina virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 III. Comandos para la realizaci´on de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 89 C. Scripts 91 I. inicializacion.sh.......................................... 91 II. creacion.cql ............................................ 91 III. mongoscriptpruebas.sh..................................... 92 IV. cassandrascriptpruebas.sh ................................... 93 6 Lista de Figuras 1.1. Ranking BD-Engine Julio 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2. Ranking BD-Engine Julio 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3. Ranking BD-Engine Octubre 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.4. Ranking BD-Engine Julio 2014 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5. Gr´afico de evoluci´on de la popularidad de las bases de datos MongoDB y Cassandra frente aOracleyMySQL........................................ 14 2.1. Infograf´ıa sobre los datos generados en un minuto de 2018 . . . . . . . . . . . . . . . . . . 18 2.2. EcosistemaBigData....................................... 19 2.3. Principales caracter´ısticas consideradas en el Big Data . . . . . . . . . . . . . . . . . . . . 20 2.4. Tri´anguloCAP .......................................... 22 2.5. Ejemplo de almacenamiento de informaci´on con un esquema de clave-valor . . . . . . . . . 25 2.6. Ejemplo de almacenamiento de informaci´on en una base de datos documental. . . . . . . . 26 2.7. Ejemplo de almacenamiento de informaci´on con una base de datos orientada a columnas. 27 2.8. Ejemplo de almacenamiento de informaci´on con un esquema orientado a grafos. . . . . . . 28 2.9. Escalabilidad vertical Vs. Escalabilidad horizontal. . . . . . . . . . . . . . . . . . . . . . . 29 3.1. Replicaci´onenMongoDB .................................... 39 3.2. ShardingenMongoDB ..................................... 40 3.3. Modelo de filas y columnas en Cassandra. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4. Modelo de datos de Cassandra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.1. Dise˜no Bases de Datos Relacionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2. Ejemplo de diagrama Entidad Relaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.1. Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en I5. . . . . . . . . . 72 6.2. Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en MV. . . . . . . . . 72 6.3. Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en I3. . . . . . . . . . 73 6.4. Comparaci´on de tiempos de b´usqueda entre MongoDB y Cassandra en I5. . . . . . . . . 73 6.5. Comparaci´on de tiempos de b´usqueda entre MongoDB y Cassandra en MV. . . . . . . . 74 6.6. Comparaci´on de tiempos de b´usqueda entre MongoDB y Cassandra en I3. . . . . . . . . 74 6.7. Comparaci´on de tiempos de actualizaci´on entre MongoDB y Cassandra en I5. . . . . . . 74 6.8. Comparaci´on de tiempos de actualizaci´on entre MongoDB y Cassandra en MV. . . . . . 75 6.9. Comparaci´on de tiempos de actualizaci´on entre MongoDB y Cassandra en I3. . . . . . . 75 7 8 Lista de Tablas 2.1. Caracter´ısticas ACID vs. Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2. Principales diferencias entre las caracter´ısticas de las bases de datos relacionales y NoSQL. 31 3.1. Principales diferencias entre MongoDB y Cassandra. . . . . . . . . . . . . . . . . . . . . . 51 4.1. M´aquinas sobre las que se realizar´an las pruebas . . . . . . . . . . . . . . . . . . . . . . . 61 6.1. Datos obtenidos en las pruebas de MongoDB sobre el port´atil i5 . . . . . . . . . . . . . . 69 6.2. Datos obtenidos en las pruebas de MongoDB sobre la m´aquina virtual . . . . . . . . . . . 70 6.3. Datos obtenidos en las pruebas de MongoDB sobre el port´atil I3 . . . . . . . . . . . . . . 70 6.4. Datos obtenidos en las pruebas de Cassandra sobre el port´atil I5 . . . . . . . . . . . . . . 70 6.5. Datos obtenidos en las pruebas de Cassandra sobre la m´aquina virtual . . . . . . . . . . . 70 6.6. Datos obtenidos en las pruebas de Cassandra sobre el port´atil I3 . . . . . . . . . . . . . . 70 6.7. Datos obtenidos al repetir las pruebas de b´usqueda sobre Cassandra. . . . . . . . . . . . . 71 9 16 Cap´ıtulo 2 Big Data y NoSQL Desde el nacimiento de la inform´atica, ´esta ha tenido como uno de sus principales objetivos la recolecci´on, almacenamiento y gesti´on de datos. En 1970 se establecen los fundamentos te´oricos del modelo relacional de base de datos y gracias a ello se pas´o de almacenar cantidades limitadas de informaci´on en tarjetas perforadas al almacenamiento masivo del orden de los terabytes de informaci´on. El modelo relacional fue dise˜nado y creado para soportar cientos o miles de usuarios simult´aneos, as´ı como para poder manejar grandes cantidades de datos, pero debido al avance que existe d´ıa a d´ıa en las tecnolog´ıas de la informaci´on junto al incremento de la informaci´on recabada a trav´es de medios como el web, el modelo relacional ha comenzado a tener problemas cuando se trata de grandes vol´umenes de informaci´on. Con la profunda penetraci´on de la red de redes en todos los aspectos de la vida diaria, los usuarios han comenzado a tener una mayor integraci´on con los sistemas, lo que ha propiciado que servicios como las redes sociales, blogs, e-comerce, etc, tuvieran cada vez una mayor demanda de almacenamiento de datos, lo cual, a su vez, trajo consigo importantes retos en los temas de escalabilidad, rendimiento y velocidad. Especialmente en el tema de escalabilidad, las bases de datos relacionales comenzaron a dar muestras de que las exigencias de sus modelos relacionales generan tiempos de respuesta muy altos para poder incrementar la manera en que la informaci´on es almacenada sin perder coherencia entre ella. Para darnos una idea de la cantidad de informaci´on que la web genera y su evoluci´on, podemos remitirnos a los estudios hechos por la empresa DOMO [15,16] en 2018 y 2019, que analizan la cantidad de informaci´on que los internautas (4.39 mil millones de personas aproximadamente en 2019) generan por minuto: Se reproducen 4 millones y medio de v´ıdeos s´olo en YouTube, hay aproximadamente un mill´on de usuarios viendo v´ıdeos en streaming en Twitch y se consumen cerca de 700.000 horas de v´ıdeo en Netflix. Realizan 4 millones y medio de consultas en Google. Escriben m´as de 500.000 tweets en Twitter y se realizan m´as de 200.000 videollamadas por Skype. Suben unas 50.000 fotos y postean cerca de 300.000 stories en Instagram. Se env´ıan m´as de 180 millones de emails. Se realizan cerca de mill´on y medio de swipes en Tinder, 10.000 viajes en Uber y 2.000 reservas por Airbnb. Estos datos aqu´ı mencionados s´olo son una muestra ilustrativa, y tanto en la infograf´ıa que se ve en la figura 2.1 como en el informe completo citado anteriormente se pueden apreciar otros datos muy interesante sobre las operaciones que se hacen aproximadamente en cada minuto del a˜no 2019. 17 Figura 2.1: Infograf´ıa sobre los datos generados en un minuto de 2018 18 2.1. El nuevo mundo: Big Data El propio concepto del Big Data es en ocasiones bastante confuso y est´a lleno de matices. En t´erminos generales, puede referirse a esa tendencia tecnol´ogica que ha abierto las puertas hacia un nuevo enfoque de entendimiento y toma de decisiones, la cual se utiliza para describir enormes cantidades de datos (estructurados, no estructurados y semi estructurados) que tomar´ıa demasiado tiempo y ser´ıa muy costoso cargarlos a una base de datos relacional para su an´alisis. De tal manera que este concepto se aplica para toda aquella informaci´on que no puede ser procesada o analizada utilizando procesos o herramientas tradicionales. Sin embargo, –y es aqu´ı donde m´as confusi´on tiende a causar el t´ermino– Big Data no se refiere a ninguna cantidad de informaci´on en espec´ıfico, aunque es usualmente utilizado cuando se habla en t´erminos de petabytes y exabytes de datos. Tampoco se refiere a ning´un tipo concreto de datos, ni a ninguna de las maneras en las que pueden ser generados, representados o utilizados, por ejemplo: dispositivos m´oviles, audio, v´ıdeo, sistemas GPS, sensores digitales en equipos industriales, autom´oviles, anem´ometros, etc., de tal forma que las aplicaciones que analizan o utilizan estos datos requieren que la velocidad de respuesta sea lo suficientemente r´apida como para lograr llevar a cabo su funci´on en el momento preciso. As´ı pues, tratando de dar una definici´on m´as formal a ´este concepto, podr´ıamos decir que el Big Data agrupa las t´ecnicas de almacenamiento, an´alisis y manejo de inmensos repositorios de datos –en un tiempo razonable– y dando por hecho que estos repositorios de datos son tan grandes que resulta imposible tratarlos con las herramientas de bases de datos y anal´ıticas convencionales. De esta forma, han surgido multitud de diversas tecnolog´ıas que continuamente est´an evolucionando, mejorando las anteriores y dej´andolas obsoletas a un ritmo vertiginoso. Cada una de estas nuevas tecnolog´ıas por si mismas no ser´ıa capaz de satisfacer las necesidades originadas por las grandes cantidades de datos que se tratan en el big data, sin embargo, la combinaci´on de estas piezas da resultado a lo que se ha llamado como “Ecosistema Big Data” [17], y cuyos principales componentes y tecnolog´ıas de referencia pueden observarse en la imagen 2.2, y si bien no cabe duda de que el almacenamiento es una parte importante, queda patente que es s´olo una pieza m´as de lo que en realidad es el big data. Figura 2.2: Ecosistema Big Data 19 El BigData y sus componentes centran sus caracter´ısticas en las tres partes fundamentales que se listan a continuaci´on, aunque recientemente se han incluido otras que se pueden apreciar tambi´en en la imagen 2.3: Volumen . Grandes vol´umenes de datos, generalmente del orden de TeraBytes de informaci´on o mayor. Variedad . El concepto de BigData tambi´en suele venir acompa˜nado de diversos tipos de fuentes de datos, ya sean estructurados, no estructurados o ambos a la vez. Velocidad . El procesamiento y posterior an´alisis ha de realizarse pr´acticamente en tiempo real para poder mejorar la toma de decisiones en base a la informaci´on generada. Figura 2.3: Principales caracter´ısticas consideradas en el Big Data De este punto, podemos dirimir que el Big Data como tal, en un sentido bastante estricto, se puede considerar una cuesti´on de escala. No se fija en ning´un momento una cantidad m´axima de datos o una velocidad m´ınima en la que deben ser procesados, por que estos l´ımites vienen dados por la capacidad (de almacenamiento, procesamiento, de la red...) de los propios sistemas, y evidentemente, cada sistema tiene los suyos propios. Con esta premisa de que el Big Data es una cuesti´on de escala, y tomando como idea que el concepto del Big Data hace referencia al momento en el que el repositorio de datos a manejar es simplemente inviable utilizando otras t´ecnicas m´as convencionales, podemos ver f´acilmente que no se puede considerar el mismo Big Data seg´un hablemos de, por ejemplo, un dispositivo wearable, una Raspberry Pi, un port´atil de uso dom´estico o un servidor perteneciente a un centro de procesamiento de datos. Claramente, cada uno de estos ejemplos tiene unas limitaciones de hardware y software que definen para cada situaci´on lo que es viable, de esta forma en un dispositivo modesto y con poca capacidad, el an´alisis de unos cuantos MegaBytes o de un ´unico GigaByte de informaci´on podr´ıa llevarse a cabo ´unicamente empleando t´ecnicas de Big Data, mientras que en otros dispositivos m´as potentes esa misma informaci´on 20 podr´ıa manejarse sin ning´un problema con t´ecnicas convencionales y el l´ımite a lo que llamar´ıamos Big Data podr´ıa estar en el orden de TeraBytes de informaci´on o unidades superiores. Actualmente se cree que la informaci´on generada a partir de la abundancia de sensores, micr´ofonos, c´amaras, elementos IoT y un largo etc, en nuestra vida diaria ser´a dentro de poco el segmento m´as grande de toda la informaci´on disponible. En este punto, Big Data ser´a una herramienta indispensable para quienes se dedican a la investigaci´on, pues gracias a ella ser´a posible descubrir cosas que sin estas herramientas habr´ıa tomado a˜nos de investigaci´on y recopilaci´on de informaci´on. La cuesti´on que afronta el Big Data es, por tanto, el modo en el que esa ingente cantidad de datos, lo que en muchas ocasiones es nombrado como el “data deluge” (el diluvio universal de datos) que se almacenan y producen diariamente pueda ser gestionado de tal modo que se convierta en conocimiento; y con el conocimiento, en valor. [18] 2.2. La nueva alternativa: NoSQL Cuando se consideran las tecnolog´ıas necesarias para abordar el problema del Big Data, tiende a ser natural considerar en primer lugar el sistema de gesti´on de bases de datos, que se encargar´a de almacenar la gran cantidad de datos que deberemos tratar. La mayor parte de las bases de datos m´as utilizadas se encuentran ya optimizadas para almacenar y gestionar grandes cantidades de datos. Desde hace ya muchos a˜nos los sistemas basados en el modelo relacional se han venido utilizando de manera exitosa tanto en la industria como en entornos de investigaci´on. Sin embargo, el umbral que define el t´ermino Big Data implica, en primer lugar, un cambio de paradigma en el modelo de gesti´on de la informaci´on, ya que al enfrentar a las bases de datos relacionales con el big data, surge un importante problema de “escalabilidad”. Y este problema de escalabilidad de SQL fue reconocido por empresas Web 2.0, con grandes necesidades de datos e infraestructura, como Google, Amazon y Facebook. Ellos solos tuvieron que buscar soluciones propias a este problema. Estas soluciones dieron lugar a una serie de sistemas de gesti´on de base de datos nuevos, con un enfoque en el rendimiento, la fiabilidad y la coherencia. Para esto se reutilizaron y mejoraron varias estructuras de indexaci´on existentes con el prop´osito de mejorar la b´usqueda y el rendimiento de lectura. En primer lugar, surgieron bases de datos desarrolladas por estas grandes empresas para satisfacer sus necesidades espec´ıficas; como BigTable de Google, que se considera el primer sistema NoSQL y DynamoDB de Amazon. El ´exito de estos sistemas patentados inici´o el desarrollo de varios sistemas de bases de datos inspirados por ellos –la mayor´ıa de c´odigo abierto– siendo los m´as conocidos a d´ıa de hoy Hypertable, Cassandra, MongoDB, HBase y Redis. Mientras que en las bases de datos que siguen el modelo relacional se garantizan determinadas propiedades que a priori parecen completamente imprescindibles (ACID), hoy por hoy, es complicado gestionar grandes vol´umenes de datos sin relajar algunas de ellas. Precisamente de esta relajaci´on y de la necesidad de cumplir con otras propiedades y necesidades nuevas, emerge un nuevo paradigma de gesti´on de datos: NoSQL. Las propiedades o caracter´ısticas que deben poseer estos nuevos sistemas, principalmente en el entorno de Internet, son: Disponibilidad. Estos sistemas en si mismos deben tener una alt´ısima disponibilidad para los usuarios, de forma que siempre, o al menos la mayor parte del tiempo, sean accesibles y funcionales. Tolerancia a fallos, especialmente a fallos de red, de forma que, aunque queden aislados m´aquinas o partes del sistema, no afecten a la disponibilidad y funcionalidad del sistema. 21 Gran capacidad de almacenamiento yAlta capacidad de Entrada/Salida. Estas caracter´ısticas pueden resultar evidentes en el contexto en que nos encontramos, pero sin duda son las dos m´as vitales e importantes para estos nuevos sistemas, ya que resultan ser los factores m´as limitantes para estos sistemas. Para conseguir cumplir con todo esto, un sistema con una arquitectura distribuida resulta ideal, aunque normalmente habr´a que renunciar a las garant´ıas ACID, ya que se requieren resultados de rendimiento ´optimos. Por ejemplo, lo m´as normal es que la consistencia no est´e garantizada, dado que en una arquitectura distribuida los cambios deben propagarse entre las diferentes m´aquinas. Cumplir con los principios ACID supondr´ıa una lacra para el rendimiento que har´ıa el sistema poco ´optimo para el escenario m´as normal de Big Data. Hoy en d´ıa se pueden encontrar diferentes sistemas de bases de datos distribuidos que potencian diferentes atributos. De hecho, existe un teorema sobre sistemas distribuidos, el teorema CAP o teorema de Brewer, que los agrupa de forma clara. Seg´un este teorema, un sistema distribuido o un sistema web no puede satisfacer de manera completa los siguientes 3 atributos al mismo tiempo: Consistencia fuerte : Todos los nodos ven los mismos datos al mismo tiempo. Esto implica que tras una actualizaci´on o cambio en la base de datos realizada por un nodo, ´este debe asegurarse de que el resto de nodos realicen dicha operaci´on tambi´en y que la respuesta dada a una petici´on debe ser id´entica independientemente del nodo que responda. Alta disponibilidad : Cualquier petici´on recibida en un nodo del sistema debe obtener una respuesta, aunque los dem´as nodos del sistema fallen o simplemente no est´an disponibles. Tolerancia al particionamiento : Una petici´on debe ser procesada por el sistema incluso si se pierden mensajes entre alguno o todos los nodos del sistema o si se crean “islas de nodos” incapaces de entablar contacto entre ellas. En este punto tambi´en se incluye la capacidad del sistema de funcionar a´un cuando se est´en a˜nadiendo o quitando nodos en ese momento. Figura 2.4: Tri´angulo CAP Teniendo en cuenta que seg´un el Teorema de Brewer una base de datos distribuida s´olo puede cumplir con dos de estos atributos de manera satisfactoria, se pueden establecer grupos de estos sistemas de acuerdo a estas caracter´ısticas. En la imagen 2.4 se pueden observar las 3 agrupaciones que conforman el tri´angulo CAP: 22 * CA: el sistema siempre responder´a a las peticiones y los datos procesados ser´an consistentes. En este caso no se permite la partici´on del sistema. * CP: el sistema ejecutar´a las operaciones de forma consistente, aunque se pierda la comunicaci´on entre nodos (partici´on del sistema), pero no se asegura la disponibilidad. * AP: el sistema siempre responder´a a las peticiones, aunque se pierda la comunicaci´on entre nodos. A cambio, los datos procesados pueden no ser consistentes. Como puede observarse, en el grupo de sistemas que cumplen con los requisitos de disponibilidad y consistencia (CA) se encuentran los derivados del modelo relacional. En la parte de la derecha (AP) est´an aquellos inspirados en Amazon Dynamo, entre los que encontramos a Cassandra, y abajo (CP) los hijos de Google BigTable, con MongoDB entre ellos. Esta clasificaci´on resulta de mucha utilidad a la hora de tomar una decisi´on para el dise˜no de una plataforma para afrontar problemas relacionados con Big Data. Adem´as, tambi´en pone de manifiesto lo pertinente que ha resultado la elecci´on entre las dos bases de datos que vamos a estudiar, ya que desde el primer momento, y sin profundizar a´un demasiado, estamos viendo que estas dos bases de datos poseen unas filosof´ıas completamente diferentes. 2.2.1. Diferencias con las bases de datos relacionales: ACID Vs BASE A lo largo de esta secci´on, en varios puntos se ha comentado que las propiedades ACID est´an fuertemente ligadas a las bases de datos relacionales, aunque no se ha explicado que significa dicho acr´onimo ni por qu´e es importante en las bases de datos relacionales. Esto se explicar´a a continuaci´on. ACID En inform´atica y m´as concretamente dentro del mundo de las bases de datos, ACID es un conjunto de caracter´ısticas o propiedades que garantizan que las transacciones en una base de datos sean fiables . En el contexto de bases de datos relacionales, una transacci´on es una o m´as sentencias SQL que se ejecutan como una secuencia de operaciones que forman una unidad l´ogica ´unica de trabajo. Un ejemplo de una transacci´on ser´ıa la transferencia de fondos de una cuenta a otra, la cual implica m´ultiples operaciones individuales, probablemente en diferentes tablas. En 1970, Jim Gray defini´o las propiedades que necesitaba tener una transacci´on confiable –Atomicidad, Consistencia y Durabilidad–, y desarroll´o tecnolog´ıas para automatizarlas [19]. M´as tarde, en 1983, Andreas Reuter y Theo H¨arder crearon el t´ermino “ACID” para describir estas 4 –incluyendo ya el aislamiento– propiedades [20]. 1. Atomicity (Atomicidad): asegura que la operaci´on se ha realizado con ´exito. De esta forma se requiere que cada transacci´on sea “todo o nada” y que si una parte de la transacci´on falla, todas las operaciones de la transacci´on fallan, y por lo tanto la base de datos no sufre cambios. 2. Consistency (Consistencia): propiedad que se encarga de asegurar que s´olo se va a comenzar aquello que se pueda finalizar. Dicho de otra forma, esta propiedad asegura que cualquier transacci´on llevar´a a la base de datos de un estado v´alido a otro estado v´alido, asegurando que cualquier dato que se escriba en la base de datos tiene que ser v´alido de acuerdo a todas las reglas que se hayan definido. 3. Isolation (Aislamiento): la ejecuci´on de una transacci´on no puede afectar a otras. M´as concretamente, se asegura que la ejecuci´on concurrente de las transacciones resulte en un estado del sistema que 23 se obtendr´ıa si estas transacciones fueran ejecutadas una atr´as de otra y de forma completamente independiente. 4. Durability (Durabilidad): cuando se realiza y confirma una transacci´on, nos asegura que ´esta se almacenar´a de forma persistente, a´un habiendo fallos en el sistema o incluso, cortes el´ectricos. BASE El enfoque BASE, abandona las propiedades ACID de consistencia y aislamiento en favor de la disponibilidad, la “degradaci´on elegante” y el rendimiento. El acr´onimo BASE est´a compuesto por: 1. Basically Availability. 2. Soft-state. 3. Eventual consistency. Bob Ippolito resume las caracter´ısticas de BASE de la siguiente manera: Una aplicaci´on funciona b´asicamente todo el tiempo pero no tiene que ser consistente todo el tiempo, ya que al final acabar´a alcanzando la consistencia entre los nodos en alg´un momento [21]. BASE es diametralmente opuesto a ACID. Donde ACID es pesimista y fuerza a que se alcance la consistencia al final de cada transacci´on, BASE es optimista y acepta que la consistencia de la base de datos acabar´a llegando con el tiempo. Este enfoque puede parecer un absoluto disparate, y m´as para usuarios acostumbrados a las bases de datos relacionales, pero lo cierto es que resulta ser un enfoque muy manejable y que conduce a niveles de escalabilidad y flexibilidad simplemente imposibles con ACID. En la tabla 2.1, Brewer contrasta las propiedades de los dos enfoques, considerando los dos conceptos m´as como un espectro de posibilidades en lugar de alternativas excluyentes entre si. [22,23] ACID BASE Consistencia fuerte Consistencia d´ebil Aislamiento Disponibilidad primero Centrar esfuerzos en “Commit” Hacer el mejor esfuerzo (Best effort) Transacciones anidadas Respuestas aproximadas Conservador (pesimista) Agresivo (optimista) Dif´ıcil evoluci´on F´acil evoluci´on ¿Disponibilidad? Sencillo R´apido Tabla 2.1: Caracter´ısticas ACID vs. Base Las diferencias conceptuales y paradigm´aticas de ACID y BASE ponen de manifiesto lo diferentes –y en ocasiones, pr´acticamente opuestas– que resultan ser las bases de datos relacionales (SQL) y las NoSQL, pero desde luego no son las ´unicas. A continuaci´on se listan algunas de las diferencias m´as destacables que nos podemos encontrar entre los sistemas NoSQL y los sistemas SQL [24]: No utilizan SQL como lenguaje de consultas . La mayor´ıa de las bases de datos NoSQL evitan utilizar este tipo de lenguaje o de utilizarlo, lo emplean m´as como un lenguaje de apoyo. Por poner algunos ejemplos, Cassandra utiliza el lenguaje CQL, MongoDB utiliza JSON y BigTable hace uso de GQL. No utilizan estructuras fijas (tablas) para el almacenamiento de los datos . Permiten hacer uso de otros tipos de modelos de almacenamiento de informaci´on como sistemas de clave–valor, objetos o grafos. 24 No suelen permitir operaciones JOIN . Al disponer de un volumen de datos tan extremadamente grande suele resultar deseable evitar los JOIN. Esto se debe a que, cuando la operaci´on no es la b´usqueda de una clave, la sobrecarga puede llegar a ser muy costosa. Las soluciones m´as directas consisten en desnormalizar los datos, o bien realizar el JOIN mediante software, en la capa de aplicaci´on. Arquitectura distribuida . Las bases de datos relacionales suelen estar centralizadas en una ´unica m´aquina o bien poseer una estructura distribuida de tipo maestro–esclavo, sin embargo, la naturaleza de NoSQL posibilita el normal almacenamiento de los datos de manera distribuida. 2.2.2. Tipos de bases de datos NoSQL Hablar de bases de datos NoSQL es hablar de estructuras que nos permiten almacenar informaci´on en aquellas situaciones en las que las bases de datos relacionales generan problemas debido principalmente a cuestiones de escalabilidad y rendimiento de las bases de datos relacionales, donde se dan cita miles de usuarios concurrentes y con millones de consultas diarias. Adem´as de lo comentado anteriormente, las bases de datos NoSQL son sistemas de almacenamiento de informaci´on que no cumplen con el esquema entidad–relaci´on. Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los datos sino que para el almacenamiento hacen uso de otros formatos muy diversos. Dependiendo de como se almacene la informaci´on, podemos encontrarnos con 4 grandes tipos de bases de datos NoSQL bien diferenciados entre si [24,25]: Clave-Valor Estas bases de datos guardan la informaci´on como una colecci´on de pares de valores, en donde hay una clave y un valor. El valor puede ser tan complejo como se quiera y funciona como una “caja negra”, es decir, no se pueden hacer consultas filtrando por lo que est´e en esa parte, todas las consultas que se pueden realizar son filtrando los valores de la clave o Key. que debe ser ´unica. Figura 2.5: Ejemplo de almacenamiento de informaci´on con un esquema de clave-valor Este tipo de BDs tienen un alto rendimiento realizando operaciones CRUD (Create, Read, Update y Delete), pero con consultas que requieren JOINs tienen un desempe˜no pobre. Las bases de datos del tipo Key-Value garantizan la atomicidad a nivel de Clave, es decir las operaciones que se realizan sobre una clave espec´ıfica son at´omicas. 25 32 Cap´ıtulo 3 MongoDB y Cassandra En el cap´ıtulo anterior hemos podido ver con bastante profundidad las particularidades de NoSQL y su vital participaci´on dentro del mundo del Big Data, as´ı como las diferencias que presenta este nuevo modelo en relaci´on con los sistemas cl´asicos relacionales y las posibles ventajas o inconvenientes que podr´ıan aportar o surgir. Tambi´en en el cap´ıtulo anterior se ha empezado a vislumbrar, de una forma introductoria, alguna de las caracter´ısticas y particularidades m´as interesantes de los dos sistemas de gesti´on de base de datos objetivos de este trabajo. En este cap´ıtulo se profundizar´a a´un m´as en MongoDB y Cassandra; en su filosof´ıa, el funcionamiento interno y sus implicaciones en el rendimiento, as´ı como su evoluci´on a lo largo de los a˜nos y los cambios o adaptaciones que hayan realizado para adaptarse a su “nicho de mercado”. 3.1. MongoDB MongoDB es un sistema de base de datos multiplataforma orientado a documentos de esquema libre. Esto significa que cada entrada o registro puede tener un esquema de datos diferente, con atributos que no tienen por qu´e repetirse de un registro a otro. Fue desarrollado originariamente en 2007 por una empresa americana llamada 10gen siendo originalmente una parte de un sistema de su propiedad. En 2009 esta compa˜n´ıa decidi´o liberar MongoDB y centrarse en su desarrollo, dejando a un lado el sistema del que formaba parte. Posteriormente, la empresa cambi´o su nombre por MongoDB Inc., confirmando as´ı que iba a centrar esfuerzos ´unicamente en desarrollar su buque insignia. Es de c´odigo abierto y podemos encontrarlo en la plataforma GitHub [30]. Est´a escrito en C++ –principalmente–, C y JavaScript, de forma que resulta ser muy eficiente a la hora de ejecutar sus tareas, y adem´as, est´a licenciado como una combinaci´on de “GNU Affero General Public License” (GNU AGPL 3.0) y Apache License v2, de modo que se trata de un software de licencia libre, aunque tambi´en dispone de licencias comerciales propias (MongoDB, Inc.) para otros de sus productos. Funciona y est´a soportado en la mayor´ıa de los sistemas operativos m´as usados en el mundo, incluyendo Microsoft Windows (a partir de Windows Vista) y macOS de Apple, aunque es en Linux donde m´as destaca, pues est´a disponible para m´ultiples distribuciones; Amazon Linux, Debian, Ubuntu, SUSE y RHEL (Red Hat Enterprise Linux). En este aspecto de los sistemas soportados, hay un par de apuntes hist´oricos o curiosidades rese˜nables. El primero de ellos es que actualmente MongoDB s´olo est´a soportado en sistemas operativos de 64 bits. Esto es debido a que se sab´ıa desde 2009 que las versiones de 32 bits ten´ıan un importante problema a la hora de manejar m´as de 2GB de datos [31], lo que llev´o a la decisi´on de enfocar el software ´unicamente 33 para los sistemas operativos de 64 bits. La segunda curiosidad es mucho m´as reciente, ya que a finales de 2017 el equipo de MongoDB decidi´o abandonar el soporte para Solaris, que hab´ıa sido uno de los primeros sistemas soportados por este gestor de bases de datos [32]. 3.1.1. ¿Qui´en usa MongoDB? En el primer cap´ıtulo se hac´ıa bastante hincapi´e en la popularidad de MongoDB, ya que est´a considerado como el sistema gestor de bases de datos NoSQL m´as popular en la actualidad. Esto plantea a su vez otras preguntas, quiz´as m´as importante que el propio dato sobre la popularidad de este software: ¿Qui´en lo usa y para qu´e? Ciertamente, MongoDB tiene un importante nicho de mercado en peque˜nas y medianas empresas que necesitan un tratamiento de datos potente y flexible. Pero es en las grandes empresas done podemos ver realmente el potencial de esta base de datos, ya que la lista de estas grandes empresas que lo usan, a parte de ser extensa, resulta ser tambi´en bastante impresionante. Plataformas de redes sociales como LinkedIn o Facebook. Empresas ligadas al mundo de los videojuegos como SEGA o Square Enix. Lineas a´ereas como Air France o agencias de viajes como Expedia. Empresas de telecomunicaciones como Telef´onica y medios de comunicaci´on como el Washington Post o Forbes. Y algunas otras grandes empresas tecnol´ogicas presentes en todo el mundo como Ebay, Google, Adobe, NOKIA, Bosch, McAfee o Cisco, as´ı como el CERN (Organizaci´on Europea para la Investigaci´on Nuclear) que utiliza MongoDB para manejar los grandes vol´umenes de datos que genera el acelerador de part´ıculas, son s´olo algunos de los ejemplos m´as contundentes de los clientes de MongoDB [33]. La ciudad de Chigago merece una menci´on a parte, ya que quiz´as sea uno de los ejemplos m´as curiosos que podemos encontrar. Recientemente ha desarrollado una plataforma de operaciones inteligente llamada WindyGrid usando MongoDB. WindyGrid re´une a diario millones de piezas de datos de diferentes departamentos de la ciudad, creando una especie de sistema nervioso central para la ciudad, cuyo objetivo es ayudar a mejorar los servicios, reducir costos y crear una ciudad m´as habitable. Adem´as, Mongo colabora estrechamente con socios como IBM o Red Hat, grandes empresas dentro del mundo de las tecnolog´ıas de la informaci´on, entre otras muchas. En cuanto a la pregunta de para qu´e emplean estas compa˜n´ıas MongoDB, hay que decir que muchas de ellas no lo han publicado o que simplemente conforma una de las muchas partes de su complejo sistema. En cualquier caso, hay compa˜n´ıas que si han explicado para qu´e est´an usando MongoDB, y en general sus usos recaen en alguno de los siguientes grupos [34]: 1. Visi´on unificada del conjunto: aseguradoras como MetLife o aerol´ıneas como Air France emplean esta base de datos para crear un repositorio central que recopila la informaci´on de sus muchos usuarios, proveniente de muchas fuentes de datos, para crear una visi´on completa de los mismos. 2. Internet de las cosas: en el mundo de IoT tenemos muchos dispositivos conectados y generando y compartiendo informaci´on, por eso, bases de datos nosql como MongoDB son escogidas por muchas empresas para llevar a cabo sus proyectos de IoT. 3. Tecnolog´ıas m´oviles: cada vez son m´as las compa˜n´ıas que est´an empezando a apostar por MongoDB como tecnolog´ıa backend en el mundo de los smartphones. 4. An´alisis en tiempo real: el sistema WindyGrip de la ciudad de Chicago resulta un buen ejemplo de la necesidad cada vez mayor de conseguir resultados de manera inmediata y de la implantaci´on de MongoDB para lograrlo. 34 5. Personalizaci´on: buscan crear y ofrecer experiencias hechas a la medida de los usuarios en tiempo real. Para ello es necesario hacer un an´alisis r´apido y certero del perfil de usuario, comportamiento, datos demogr´aficos, gustos, etc... Expedia es un buen ejemplo del uso de MongoDB en este aspecto. 6. Administraci´on de contenido: permiten gestionar archivos junto a sus metadatos. Forbes construy´o todo su sistema de gesti´on de contenidos en MongoDB. Adem´as, lo utiliza para anal´ıtica en tiempo real, de forma que cuando alg´un art´ıculo se hace viral, Forbes detecta la forma en que se est´a compartiendo entre los usuarios y de este modo sabe qu´e tipo de contenido le debe ofrecer a sus lectores. 3.1.2. Caracter´ısticas Las caracter´ısticas que m´as destacan los usuarios de MongoDB son su velocidad y su rico pero sencillo sistema de consulta de los contenidos de la base de datos. Es m´as, en su p´agina web podemos ver que lo definen de la siguiente manera: “MongoDB es una base de datos documental con la escalabilidad y flexibilidad que quieres, con las consultas y el indexado que necesitas” [35]. Espec´ıficamente, se puede decir que las principales caracter´ısticas de este SGBD son las siguientes: MongoDB almacena los datos en documentos similares a JSON, lo que significa que los campos pueden variar de un documento a otro y la estructura de los datos se puede cambiar con el tiempo. El modelo de base de datos orientada a documentos permite mapear c´omodamente los objetos de las aplicaciones que usen la base de datos, facilitando el trabajo con los datos y la forma de almacenarlos. Este modelo tambi´en resulta sencillo de aprender y utilizar para los desarrolladores, facilitando la migraci´on hacia este sistema. Tambi´en disponen de numerosos drivers, con licencia Apache v2, para un gran n´umero de lenguajes de programaci´on muy diversos. Las consultas Ad-Hoc, la indexaci´on y la agregaci´on en tiempo real brindan formas muy potentes de acceder y analizar los datos. Es una base de datos distribuida en su n´ucleo, por lo que la alta disponibilidad, el escalado horizontal y la distribuci´on geogr´afica est´an incorporados pr´acticamente por defecto y son f´aciles de emplear. Es gratuito y de c´odigo abierto, publicado bajo la Licencia P´ublica General Affero de GNU. En la versi´on m´as reciente de MongoDB, la versi´on 4.0, se ha a˜nadido el soporte de transacciones ACID en m´ultiples documentos, por lo que seg´un sus desarrolladores, es la ´unica base de datos de c´odigo abierto que combina la velocidad, flexibilidad y potencia del modelo orientado a documentos con las garant´ıas de ACID. A trav´es del “aislamiento de instant´aneas” (snapshot isolation), las transacciones proporcionan una visi´on coherente de los datos y hacen cumplir la ejecuci´on de todo o nada para mantener la integridad de los datos. En esta lista se pueden ver algunas caracter´ısticas que ya se han comentado en este documento y tambi´en han salido a relucir algunas nuevas que se comentar´an en los siguientes puntos, pero hay una con una importancia vital, y es la ´ultima listada: multi-document ACID o soporte para transacciones. En las versiones de MongoDB anteriores a la versi´on 4.0 s´ı se pod´ıan ver satisfechas las propiedades ACID, pero s´olo dentro de un mismo documento. Como se ha visto en el cap´ıtulo anterior, el no implementar las propiedades ACID en toda la base de datos implica que ´esta no asegure la durabilidad, la integridad, la consistencia y el aislamiento requeridos obligatoriamente en el concepto de transacci´on. 35 Esto pod´ıa crear diversos problemas; como problemas de consistencia, leyendo versiones obsoletas del documento o devolviendo datos basura de escrituras que no deber´ıan haber ocurrido; problemas de bloqueos a nivel de documento al realizar escrituras concurrentes en el mismo documento; problemas de p´erdidas de informaci´on, ya que las escrituras no eran durables ni verificables; y si la ausencia de ACID multidocumental podr´ıa provocar estos tres problemas, a su vez ´estos pod´ıan provocar problemas de rendimiento y desempe˜no al enfrentarse a cantidades de informaci´on muy altas. Algunos de estos problemas estuvieron presentes hasta hace no mucho tiempo y se consideraban como un mal menor o simplemente inevitables, otros se solucionaron con la versi´on 3.0 del software, pero en cualquier caso, todos ellos se ver´ıan solventados con la completa implantaci´on de ACID. Y llama mucho la atenci´on que ACID resultase ser la soluci´on elegida para una base de datos NoSQL, ya que, como se ha visto en el cap´ıtulo 2, este paradigma tiende a huir de las obligaciones de ACID en favor de la libertad y flexibilidad de BASE. Desde luego, la evoluci´on vista hasta ahora de esta plataforma demuestra su firme intenci´on de competir abiertamente con los sistemas relacionales cl´asicos, incluso llegando a adquirir muchas de sus caracter´ısticas y acerc´andose m´as a ellos, y su posicionamiento como una base de datos de prop´osito general, en vez de buscar un nicho de mercado m´as orientado a soluciones particulares y concretas, como hacen otras bases de datos NoSQL. Estructura de documentos: BSON MongoDB es una base de datos orientada a documentos, esto quiere decir que un documento es la unidad b´asica de datos que podremos encontrar. Los documentos son an´alogos a los objetos JSON (JavaScript Object Notation) pero se almacenan en la base de datos en una representaci´on binaria de JSON, m´as rica en tipos de datos, conocida como BSON. Los documentos de MongoDB est´an compuestos por pares de campos y valores separados por comas, y tienen la siguiente estructura: { campo1: valor1, campo2: valor2, campo3: valor3, ... campoN: valorN } En un documento se pueden agregar, eliminar, modificar o renombrar nuevos pares de campo-valor en cualquier momento. El valor de un campo puede pertenecer a cualquiera de los tipos de datos BSON [36], incluidos otros documentos, arrays e incluso arrays de documentos. El siguiente ejemplo proporcionado en la documentaci´on de MongoDB especifica la manera de incluir otros documentos o arrays, as´ı como tipos de datos complejos como fechas: { _id: ObjectId("5099803df3f4948bd2f98391"), name-documento: { first: "Alan", last: "Turing" }, birth: new Date(’Jun 23, 1912’), 36 death: new Date(’Jun 07, 1954’), contribs-array: [ "Turing machine", "Turing test", "Turingery" ], views : NumberLong(1250000) } Una colecci´on es una agrupaci´on de documentos de MongoDB, y a su vez, una base de datos est´a compuesta por colecciones de documentos. Se podr´ıa entender el concepto de colecci´on como una aproximaci´on a una tabla de un sistema relacional, con la principal diferencia que las colecciones no imponen un esquema, por lo que los documentos dentro de una colecci´on pueden tener diferentes campos. T´ıpicamente, todos los documentos en una colecci´on tienen un prop´osito similar o relacionado por lo que es habitual que compartan el mismo n´umero de campos o atributos. Para crear una base de datos en MongoDB, una vez que el SGDB ha sido instalado y la Shell de Mongo est´a en ejecuci´on, simplemente se le debe decir el nombre de la base de datos que se quiere usar. Si esa base de datos a´un no existe, se crear´a autom´aticamente al crear una colecci´on y a˜nadirle el primer documento. De igual manera, una colecci´on se crea autom´aticamente al almacenar un documento en ella: use BD_TFG db.coleccion_TFG.insert( { x: 1 } ) De esta forma, se ha indicado el nombre de la base de datos que queremos usar (BD TFG) y el nombre de la colecci´on (coleccion TFG) pero ni la base de datos ni la colecci´on estar´an realmente creadas hasta el momento en que se ejecuta la sentencia . insert() , que es la que a˜nade el documento y propicia la creaci´on de la colecci´on y de la base de datos. El documento que se ha insertado solo deber´ıa tener un campo (x) y un valor (1), sin embargo, durante la inserci´on, mongod crear´a el campo id y le asignar´a un valor de tipo ObjectId ´unico y espec´ıfico para cada m´aquina y momento en que se ejecuta la operaci´on. El campo id puede ser a˜nadido con un valor concreto, igual que si se tratase de otro campo, pero hay que entender que est´a reservado para su uso como clave principal; su valor debe ser ´unico en la colecci´on, es inmutable y no puede ser un array. Al igual que para la inserci´on mostrada anteriormente, MongoDB usa la notaci´on por puntos para acceder a los elementos de un array o a los campos de un documento embebido dentro de otro. Para acceder a un elemento espec´ıfico de un array se puede indicar la posici´on o ´ındice (comenzando a contar la primera posici´on como 0) del elemento deseado sobre el array, indicando su nombre. Para el ejemplo de Alan Turing visto anteriormente, si quisi´esemos acceder a la tercera posici´on del array se deber´ıa emplear la siguiente notaci´on: contribs-array.2. El caso de los documentos dentro de un documento es an´alogo, pero empleando el nombre del campo en vez de su posici´on. En ese mismo ejemplo anterior se emplear´ıa la siguiente notaci´on para acceder al nombre: name-documento.first. 3.1.3. Consultas Soporta consultas Ad Hoc, es decir aquellas en las que los usuarios pueden personalizar las consultas en tiempo real y buscar cualquier elemento que deseen, sin ajustarse a, por ejemplo, consultas predise˜nadas para generar informes. MongoDB soporta la b´usqueda por campos, rangos y expresiones regulares. Las consultas pueden devolver campos espec´ıficos de documentos y tambi´en incluyen funciones de JavaScript definidas por el usuario. 37 Para realizar estas consultas, emplea el m´etodo find() aplicado sobre la colecci´on deseada, de forma que si suponemos que la colecci´on coleccion TFG almacena los documentos de ejemplo empleados, se podr´ıa emplear la sentencia db.coleccion TFG.find( ) para buscar todos los documentos en la colecci´on. Para buscar por un valor espec´ıfico, se har´ıa de la siguiente forma: db.coleccion TFG.find( campo1: valor1 ). El m´etodo find() no es el ´unico m´etodo existente para realizar una consulta, otros muy usados son findOne() para que la consulta s´olo devuelva un documento, aunque haya m´as que coincidan con el criterio de b´usqueda y findAndModify(), que permite realizar una consulta y posteriormente, actualizar los valores de uno o m´as campos. Si bien la forma de realizar las consultas tiene este formato especial, que en realidad es JavaScript, las consultas son equivalentes a las tradicionales SQL, tanto que poseen los mismos operadores y se aplican de una forma muy similar. $in, $eq, $and, $or son solo algunos de los ejemplos de los operadores que se pueden usar en MongoDB con una funcionalidad id´entica a los operadores de SQL, con la ´unica diferencia que llevan el s´ımbolo “$” delante. As´ı pues, la siguiente consulta devolver´ıa los documentos que cumplan simult´aneamente con los criterios de que el nombre sea Alan y el n´umero de vistas sea mayor de 30: db.coleccion TFG.find( “name-documento.first”: “Alan”, views: $gt: 30 ). N´otese que la sintaxis de esta consulta no emplea el operador $and, ya que impl´ıcitamente incluye el operador l´ogico AND cuando se emplean consultas compuestas sin especificar un operador. Indexado Los ´ındices son estructuras de datos especiales (´arboles-B) que almacenan una peque˜na parte del conjunto de datos de la colecci´on en una forma f´acil de recorrer. Un ´ındice almacena el valor de un campo espec´ıfico o conjunto de campos, ordenados por su valor. El orden de las entradas del ´ındice admite coincidencias de igualdad eficientes y operaciones de consulta basadas en rango. Los ´ındices son los que realmente permiten la ejecuci´on eficiente de las consultas en MongoDB. Sin ´ındices, no queda m´as remedio que realizar un escaneo de la colecci´on completa, es decir, escanear cada documento presente en una colecci´on para seleccionar aquellos documentos que coincidan con la declaraci´on de consulta. Si existe un ´ındice apropiado para una consulta, MongoDB puede usar el ´ındice para limitar el n´umero de documentos que debe inspeccionar y optimizar as´ı los tiempos. Se puede afirmar que el concepto de ´ındices es muy similar a los encontrados en bases de datos relacionales. MongoDB define los ´ındices a nivel de colecci´on y cualquier campo o sub-campo de un documento puede ser indexado, pudi´endose tambi´en incluir ´ındices secundarios. Este SGDB crea un ´ındice ´unico –y que no puede eliminarse– en el campo id en el momento en que se crea la colecci´on, de esta forma previene adem´as que se inserten dos documentos con el mismo valor de id. Se puede crear un ´ındice sobre un campo con la siguiente sentencia: db.collection.createIndex(campo: indice), empleando el nombre de la colecci´on para llamar a createIndex y el nombre del campo o los campos que queramos indexar. En este caso, el valor del ´ındice puede ser 1 o -1, dependiendo de como se quieran ordenar los resultados. Con un valor 1 el ´ındice los ordena de forma ascendente y con un valor -1 los ordena de una manera descendente. Agregaci´on Las operaciones de agregaci´on procesan y agrupan los valores de varios documentos y pueden realizar una variedad de operaciones en ellos para reducirlos y devolver un solo resultado. MongoDB proporciona un framework que permite realizar operaciones similares a las que se obtienen con el comando SQL ”GROUP BY”. El framework de agregaci´on est´a construido como un pipeline en el que los datos van pasando a trav´es de diferentes etapas, durante las cuales son modificados, agregados, filtrados y formateados hasta obtener el resultado deseado. Durante todo este proceso se puede utilizar ´ındices si 38 existieran, y adem´as se produce en memoria. Asimismo, MongoDB proporciona una funci´on MapReduce que puede ser utilizada para el procesamiento por lotes de datos y operaciones de agregaci´on [37]. 3.1.4. Naturaleza distribuida Otra de las principales caracter´ısticas de este sistema es su concepci´on como una base de datos distribuida. Presenta dos maneras de distribuir los datos entre varias m´aquinas, cada una de ellas para abordar un problema diferente: la replicaci´on y el sharding. Replicaci´on MongoDB, como muchos sistemas NoSQL, es considerablemente m´as flexible que las bases de datos relacionales, lo que puede ocasionar problemas de volatilidad de los datos ante ca´ıdas de los servidores o cortes el´ectricos. La replicaci´on proporciona redundancia y aumenta la disponibilidad de los datos, ya que con m´ultiples copias de los datos en diferentes servidores aumenta el nivel de tolerancia a fallos. En algunos casos, la replicaci´on adem´as puede proporcionar una mayor capacidad de lectura, ya que los clientes pueden enviar operaciones de lectura a diferentes servidores. Tambi´en se emplea para mantener copias para fines dedicados, como recuperaci´on ante desastres, informes o copias de seguridad. MongoDB soporta un tipo de replicaci´on primario-secundario basado en replica sets. Un replica set es un conjunto de instancias o nodos de mongod que mantienen los mismos datos. Figura 3.1: Replicaci´on en MongoDB Dentro de este replica set hay un nodo primario que recibe todas las operaciones, tanto de lectura como de escritura, y despu´es de ejecutarlas, almacena todos los cambios que se han realizado en la base de datos dentro de un registro de operaciones. Los nodos secundarios utilizan dicho registro para replicar los datos y alcanzar el mismo estado que el nodo primario, la funci´on por defecto de un nodo secundario es la de copia de seguridad aunque pueden ser configurados para responder a peticiones de lectura. Adicionalmente, si el nodo primario dejase de estar disponible, un nodo secundario puede ocupar temporal o permanentemente el puesto de nodo primario. Existe un tercer tipo de nodos que puede estar presente en un replica set, los ´arbritros, aunque esta clase de nodo no almacena ni replica los datos, si no que tiene una responsabilidad de gesti´on interna, como la de determinar si un nodo est´a funcionando correctamente o la de elegir un nuevo nodo primario en caso de que el actual no est´e disponible. 39 La replicaci´on en MongoDB es sencilla de implementar y configurar, pero tiene algunas limitaciones. Por ejemplo, tras el failover, o lo que es lo mismo, la elecci´on de un nodo secundario como nuevo nodo primario si este fallase, se requiere un tiempo durante el cual habr´a problemas de disponibilidad. Por otra parte, la replicaci´on no ayuda demasiado a aumentar la escalabilidad, ya que las escrituras siempre se hacen en el nodo primario. Adem´as, compartir la carga de lectura con los nodos secundarios puede llevar impl´ıcita una p´erdida de consistencia si ´estos no est´an completamente actualizados. Sharding En MongoDB es natural complementar la replicaci´on con el sharding o particionado de la informaci´on. De esta manera se pueden alcanzar los objetivos de alto rendimiento, capacidad de almacenamiento y escalabilidad horizontal necesarios para los sistemas Big Data. El Sharding es una t´ecnica que consiste en particionar los datos de una base de datos horizontalmente, agrup´andolos de alg´un modo que tenga sentido y que permita un enrutado eficiente. Un Sharded cluster o cl´uster particionado de Mongo consta de los siguientes componentes: 1. Shard: cada partici´on contiene un subconjunto de los datos fragmentados. Cada fragmento se puede implementar como un conjunto de replicaci´on. 2. Mongos: son instancias que act´uan como enrutadores de consultas y operaciones de escritura, proporcionando una interfaz entre las aplicaciones cliente y el cl´uster de shards. 3. Servidores de configuraci´on: los servidores de configuraci´on almacenan metadatos y configuraciones para el cl´uster. Figura 3.2: Sharding en MongoDB La fragmentaci´on de los datos se realiza a nivel de colecci´on, distribuyendo los documentos entre las m´aquinas del cl´uster. Para distribuir los documentos emplea una “clave de partici´on”, que es un campo o campos que existen en todos los documentos de la colecci´on. Los datos se parten en “chunks” –que se parten nuevamente si alcanzan un tama˜no superior al tama˜no de chunk, que por defecto tiene un valor de 64MB– y despu´es migra los chunks dentro de los shards del cl´uster, procurando que exista un balance entre los distintos shards y los chunks que se almacenan en ellos. Los mongos rastrean qu´e datos est´an en qu´e shard almacenando en cach´e los metadatos de los servidores de configuraci´on, despu´es los emplean para enrutar las operaciones de las aplicaciones y los clientes a las instancias de mongod. 40 3.1.5. Seguridad Menci´on a parte merece el tema de la seguridad, pues la falta de seguridad por defecto ha sido uno de los aspectos m´as criticados a lo largo de la historia de MongoDB. Originalmente, y durante muchas versiones, estaba dise˜nado para que los nuevos usuarios pudiesen empezar a utilizar mongo lo m´as r´apido posible. Si bien esto es un punto positivo, resulta que la configuraci´on b´asica por defecto era tambi´en por defecto insegura. Se pod´ıan hallar varios problemas, pero sin duda el mayor de ellos se encontraba en un par´ametro de configuraci´on llamado bind ip y cuyo valor por defecto era 0.0.0.0 (todas las interfaces). Esta configuraci´on permit´ıa que todas las interfaces de red pudiesen establecer una conexi´on con la base de datos sin ning´un tipo de limitaci´on, y junto a otros fallos de seguridad como no establecer credenciales de autenticaci´on, ha sido una de las brechas de seguridad m´as usadas para atacar a este tipo de bases de datos. Aunque a partir de la versi´on 3.6 este par´ametro por defecto se volvi´o m´as restrictivo, cambiando su valor a 127.0.0.1 (localhost), a´un se pueden encontrar noticias sobre grandes ataques de ramsonware y robos de informaci´on sobre servidores MongoDB mal configurados [38,39]. Los desarrolladores de MongoDB son conscientes de que la seguridad ha sido uno de los aspectos m´as criticados de su sistema y por ello en la documentaci´on de su p´agina web podemos encontrar una checklist [40] con pasos a seguir para que los administradores de servidores mongod puedan configurarlos de manera segura. En esta lista se encuentran los siguientes puntos, que si bien no se entrar´a en detalles sobre ninguno, dan una idea general del nivel de seguridad que se puede alcanzar en este SGDB: Habilitar el control de acceso y exigir la autenticaci´on. Configurar el control de acceso basado en roles. Encriptar la comunicaci´on, as´ı como cifrar los datos. Limitar la exposici´on de la red (limitar las interfaces en las que se escuchan las conexiones entrantes). Auditar la actividad del sistema. Ejecutar MongoDB con un usuario dedicado y con opciones de configuraci´on seguras. 41 Gossip [48] es un protocolo de comunicaci´on de igual a igual en el que los nodos intercambian peri´odicamente informaci´on de estado sobre ellos mismos y sobre otros nodos que conocen, por lo que todos los nodos aprenden r´apidamente sobre los dem´as nodos del cl´uster. Este protocolo tambi´en es ´util para la detecci´on de fallos y el enrutamiento de peticiones, ya que a partir del estado y el historial de un nodo se puede saber si ´este est´a inactivo o si se ha recuperado tras una ca´ıda, y tambi´en se puede usar esta informaci´on para evitar enviar las solicitudes de los clientes a nodos inalcanzables o a nodos con bajo rendimiento, proceso que en Cassandra se comoce como “Snitching” [49]. El hecho de que Cassandra est´e descentralizada implica que no tiene un punto ´unico de fallo. Todos los nodos en un cl´uster funcionan del mismo modo y son iguales entre s´ı, por lo que no existe un nodo administrador o maestro que coordine tareas entre los nodos, como es habitual en otras arquitecturas distribuidas. Replicaci´on y distribuci´on de datos En Cassandra la distribuci´on y la replicaci´on de los datos van juntos. Los datos se organizan por tablas y se identifican mediante la clave principal o primaria, que determinar´a en qu´e nodo se almacenan los datos. Las r´eplicas son copias de las filas, que se almacenan en varios nodos para garantizar la fiabilidad y la tolerancia a fallos. Para la distribuci´on de datos se utilizan t´ecnicas de sharding empleando un particionador, que determina c´omo se distribuyen los datos entre los nodos del cl´uster, incluyendo las r´eplicas. Un particionador es, en esencia, una funci´on hash que emplea tokens para determinar la ubicaci´on de los datos almacenados en una tabla, de forma que cada fila de datos se distribuye a trav´es del cl´uster en funci´on del valor de su token. Estos tokens representan lo que se conoce como la clave de partici´on , que es la clave primaria de la tabla si ´esta es ´unica o el primer componente de la clave primaria si esta clave est´a compuesta por varias columnas. De esta forma, la base de datos asigna un valor hash a cada token, y cada nodo en el cl´uster es responsable de un rango de datos en base a los hashes. Esta pol´ıtica de sharding trata de distribuir de forma uniforme los datos de todas las tablas a lo largo de todos los nodos que conforman el cl´uster, teniendo en cuenta que los datos que poseen la misma clave de partici´on estar´an siempre juntos, en los mismos nodos. Esto tambi´en implica que las solicitudes de lectura y escritura al cl´uster se distribuyen uniformemente entre los nodos, simplificando el balanceo de la carga. Por otra parte, tal y como se ha visto anteriormente, la pol´ıtica o estrategia de replicaci´on es un par´ametro necesario para crear un keyspace y se aplica a todos los datos contenidos en las tablas de ese keyspace. La estrategia de replicaci´on concreta los nodos donde se colocar´an las r´eplicas de los datos. El n´umero total de r´eplicas en el cl´uster se conoce como el factor de replicaci´on. Un factor de replicaci´on de 1 significa que solo hay una copia de cada fila en el cl´uster, un factor de replicaci´on de 2 significa que hay dos copias de cada fila y que cada copia est´a en un nodo diferente, y as´ı sucesivamente. Hay dos estrategias de replicaci´on disponibles: SimpleStrategy. Es la estrategia m´as sencilla y se considera adecuada si ´unicamente hay un centro de datos. Con esta estrategia, la primera r´eplica se coloca en un nodo determinado por el particionador y las r´eplicas adicionales, si las hay, se colocar´an en los siguientes nodos disponibles. NetworkTopologyStrategy. Es la estrategia recomendada si se dispone de m´ultiples centros de datos, y permite especificar cuantas r´eplicas se desea tener en cada centro de datos. 48 Al igual que ocurre con los nodos, todas las r´eplicas son igualmente importantes y no existe r´eplica primaria o maestra. Como regla general, se considera que el factor de replicaci´on no debe exceder el n´umero de nodos en el cl´uster. Niveles de consistencia Al estar hablando de una red peer-to-peer en la que los datos est´an replicados en diferentes nodos y que juega con las reglas de consistencia eventual presentes en NoSQL, se presenta la situaci´on de que m´as de un nodo podr´ıa responder a la misma operaci´on, cada uno con una respuesta diferente. Para solventar esto, Cassandra permite ajustar el nivel de consistencia para operaciones de lectura y escritura, ya sea para operaciones concretas o de forma global en un cl´uster o centro de datos. Esencialmente, para resolver una operaci´on se elige un coordinador, de forma que el nivel de consistencia indica cu´antas de las r´eplicas deben responder al coordinador para considerar la operaci´on como un ´exito. Si las r´eplicas contactadas tuviesen una versi´on diferente de los datos, se tomar´ıa por v´alida la versi´on m´as reciente. Estos niveles de consistencia, que se listan a continuaci´on, permiten a Cassandra alcanzar un equilibrio entre la consistencia y la disponibilidad, o priorizar uno de ellos, seg´un sea necesario para las aplicaciones concretas que usen este SGBD. ONE, TWO or THREE: estos tres niveles de consistencia indican el n´umero concreto de r´eplicas que deben responder. QUORUM: la mayor´ıa de las r´eplicas debe responder. Esto significa que si tenemos un cl´uster con un factor de replicaci´on 3, deben responder 2 de las r´eplicas. ALL: todas las r´eplicas deben responder. LOCAL QUORUM y EACH QUORUM: teniendo m´ultiples centros de datos, especifica si se debe consultar s´olo al centro de datos en el que est´a el coordinador (local), evitando la latencia de comunicaci´on entre centros de datos, o a todos los centros de datos (each). LOCAL ONE: solo una r´eplica debe responder. En un cl´uster de centros de datos m´ultiples, esto garantiza que las solicitudes de lectura no se env´ıen a las r´eplicas en otro centro de datos. Las operaciones de escritura siempre se env´ıan a todas las r´eplicas, independientemente del nivel de consistencia elegido. El nivel de consistencia simplemente controla cu´antas respuestas espera el coordinador antes de responder al cliente [50]. 3.2.6. Seguridad Para comenzar a utilizar Cassandra en un entorno con varios nodos, es necesario realizar configuraciones tras su instalaci´on, lo que en principio deber´ıa reducir los problemas de seguridad asociados a una configuraci´on por defecto insuficiente. Obligar al usuario a configurar algunos aspectos antes de empezar a funcionar aumenta la seguridad en comparaci´on con otros SGBD, pero en el caso de Cassandra, tambi´en adolece de otros problemas de seguridad comunes, ya que configuraciones de seguridad como la autenticaci´on o la autorizaci´on de acceso son par´ametros considerados como “adicionales y opcionales”, lo cual puede dejar los datos almacenados completamente expuestos [51]. En cualquier caso, esta base de datos provee tres medidas de seguridad fundamentales [52]: Encriptaci´on TLS/SSL para las comunicaciones y transferencias de datos, tanto desde el cliente al cl´uster, como entre los nodos del cl´uster. Autenticaci´on. Permite establecer unos credenciales de usuario (usuario y contrase˜na) que se almacenan encriptados en una tabla del sistema. Por defecto, no se emplea ning´un tipo de autenticaci´on y 49 activar esta opci´on en la configuraci´on tampoco es una soluci´on instant´anea, ya que el super usuario por defecto es bien conocido (usuario: cassandra, contrase˜na: cassandra), por lo que habr´ıa que crear uno nuevo y deshabilitar el por defecto. Roles y Autorizaci´on. Permite establecer diferentes roles de usuarios y diferentes permisos para cada rol (una lista blanca). Por defecto, se otorgan todos los permisos a todos los roles. Una vez que se ha configurado la base de datos para que la autorizaci´on est´e activada, los permisos deben establecerse con la sentencia GRANT y se pueden eliminar con REVOKE. 3.3. Principales diferencias Desde el segundo cap´ıtulo se ha podido empezar a ver las enormes diferencias que hay entre MongoDB y Cassandra, y son tantas que casi se podr´ıa decir que s´olo coinciden en que son sistemas de gesti´on de bases de datos NoSQL de c´odigo abierto. Las diferencias entre ellos comienzan en su propia filosof´ıa y concepci´on, ya no s´olo como base de datos, si no en un nivel m´as general. MongoDB posee una filosof´ıa Plug-and-Play que resulta muy c´omoda y atractiva para sus usuarios, ya que la instalaci´on es muy sencilla en todas las plataformas y no necesita configuraci´on para poder empezar a funcionar, aunque si es recomendable configurar algunos aspectos previamente. Por su parte, habitualmente Cassandra si necesita configuraci´on tras su instalaci´on, y como se ha comentado, la instalaci´on en algunos sistemas operativos no resulta sencilla. Tambi´en hay que decir que Cassandra presenta un modelo de datos y lenguaje de consulta m´as cercano a las bases de datos relacionales, mientras que en MongoDB son completamente diferentes. Existe otra diferencia importante en este aspecto, y es la documentaci´on. El desarrollo y el soporte de MongoDB siempre ha sido ofrecido por la misma empresa que lo cre´o, y tanto la documentaci´on oficial disponible en la p´agina web de MongoDB como los cursos de MongoDB University resultan bastante completos e intuitivos. El desarrollo inicial de Cassandra estuvo a cargo de Facebook. Tras ser liberado, el proyecto fue desarrollado y mantenido por Apache, aunque durante un tiempo estuvo muy ligado a otras empresas como DataStax, que tambi´en ofrec´ıa documentaci´on de Cassandra (Planet Cassandra), hasta finales de 2016. El resultado de esto, es que actualmente la p´agina web oficial de Cassandra tiene numerosos enlaces a Planet Cassandra, plataforma que est´a fuera de servicio y que a su vez redirige a la p´agina principal de la web de Cassandra. Por si esto fuese poco, secciones completas de la documentaci´on oficial de Cassandra, como el modelo de datos o cuestiones de arquitectura, est´an incompletas o simplemente vac´ıas. En cuestiones de seguridad, hay una diferencia notable, y es que realizando una exploraci´on de ambas bases de datos a trav´es de la plataforma shodan.io, para conocer los servidores de bases de datos que son directamente accesibles a trav´es de internet (que no poseen ning´un tipo de autenticaci´on o emplean credenciales por defecto d´ebiles como admin/admin), el resultado para Cassandra fue que tiene muchas menos m´aquinas accesibles (1.272) que MongoDB (62.326). Esto no quiere decir que haya m´as de 60.000 bases de datos MongoDB y Cassandra cuyos datos est´an esperando a ser robados o borrados, simplemente indica que las bases de datos son accesibles. La naturaleza de la informaci´on expuesta puede ser muy diversa; es posible que algunos de esos sistemas f´acilmente accesibles si est´en exponiendo los datos almacenados por sus aplicaciones o usuarios, pero en muchos casos la informaci´on accesible es propia del servidor y su gesti´on, como ficheros logs. 50 En la siguiente tabla se resumen las principales diferencias entre MongoDB y Cassandra. MongoDB Cassandra Teorema CAP CP AP Filosof´ıa Orientado a Documentos Orientado a Columnas Programado en C++ Java Almacenamiento de datos Documentos BSON Familias de columnas Lenguaje de consulta Objetos y m´etodos JavaScript CQL Distribuido Maestro-Esclavo Peer-to-Peer Disponibilidad Alta disponibilidad, basada en la recuperaci´on ante fallos autom´atica en el nodo maestro Alta disponibilidad, basada en un modelo altamente distribuido y redundante Tolerancia a fallos Alta Excepcional ´ Ultima versi´on 4.2 3.11.4 Tabla 3.1: Principales diferencias entre MongoDB y Cassandra. 51 52 Cap´ıtulo 4 Preparaci´on del experimento En este cap´ıtulo se entra en un terreno mucho m´as pr´actico, con el fin ´ultimo de abordar el segundo objetivo principal de este trabajo: comparar el rendimiento de los dos sistemas de bases de datos NoSQL estudiados. Adem´as de realizar el paso evidente de instalar ambas bases de datos en las m´aquinas donde se har´an las pruebas y realizar las configuraciones necesarias, en este cap´ıtulo tambi´en se especificar´an las m´etricas de rendimiento elegidas y la manera en que se realizar´an las mediciones. Para poder comparar el rendimiento de estas dos bases de datos hace falta un elemento adicional: datos. Y no s´olo hace falta tener datos que almacenar en las BD, si no que, para que las pruebas de rendimiento realizadas sean v´alidas, tambi´en se hace necesario que los “modelos o esquemas” para almacenarlos en ambas bases de datos sean lo m´as equivalentes posibles. Todo esto se tratar´a en las siguientes secciones. 4.1. Obtenci´on de los datos La adquisici´on de los datos que se emplear´an en las pruebas es un proceso m´as delicado de lo que puede parecer a primera vista y requiere tener en cuenta varios factores que se enumeran a continuaci´on: 1. Volumen de datos: la cantidad de datos o su peso es un factor importante a la hora de hablar de Big Data, aunque como se ha explicado anteriormente, no existe una cifra que separe lo que se considera Big Data de lo que no. 2. Estructura y formato: Los datos pueden ser completamente estructurados, completamente desestructurados o semi-estructurados. Tambi´en el tipo de formato en el que est´en almacenados puede suponer alguna diferencia a la hora de importar los datos. 3. N´umero de filas y columnas: si bien est´a relacionado con los dos factores anteriores, proporciona una forma mucho m´as real y cercana de ver el volumen que alcanzar´a la base de datos. 4. Relaciones entre los datos: la interconexi´on de los datos resulta importante, y lo ser´ıa a´un m´as si la comparaci´on se hiciese entre un sistema relacional y un sistema nosql, ya que la integridad referencial es muy importante en el mundo relacional, y sin embargo, en muchos sistemas nosql no hay ninguna forma real de implementarla. La correcta elecci´on de los datos que se manejar´an en el experimento resulta vital para que este pueda ser considerado como exitoso. Elegir un conjunto de datos con unas caracter´ısticas que puedan favorecer a uno de los dos sistemas en estudio podr´ıa llevar a unas conclusiones err´oneas en cuanto al rendimiento del mismo. 53 En este caso, el volumen de datos est´a limitado por la capacidad de almacenamiento de las m´aquinas de pruebas. Desde luego, lo ideal ser´ıa obtener un gran conjunto de datos de cientos de GB, o incluso superar el TB. Pero siendo realistas, el volumen de datos tendr´a que limitarse a unos pocos GB. Ambos sistemas NoSQL est´an preparados para trabajar con datos no estructurados o semi-estructurados de una manera sencilla y eficaz as´ı que en este caso por simple comodidad y por resultar m´as sencillo de obtener, se optar´a por un conjunto de datos estructurados o semi-estructurados con un elevado n´umero de filas y un n´umero m´as reducido de atributos o columnas. A su vez, se procurar´a que el formato en el que est´en almacenados los datos sea CSV, por tratarse de un formato bien conocido y de f´acil importaci´on en ambos sistemas de bases de datos. Los joins suponen un elemento muy diferencial, pues Cassandra no aporta ninguna utilidad para su implementaci´on y uso, y sin embargo MongoDB, tras su acercamiento al mundo relacional incorporando ACID, s´ı permite realizar joins, aunque con ciertas limitaciones. Y si bien en MongoDB se permite referenciar otros documentos y realizar transacciones, Cassandra no soporta ninguna de estas opciones –aunque existe el concepto de transacci´on ligera– por lo cual se optar´a por un conjunto de datos sencillo, sin relaciones entre ellos. Para realizar el proceso de obtenci´on de los datos que se utilizar´an en las pruebas posteriores, se han barajado varias maneras de conseguirlos que podr´ıan resultar satisfactorias. La primera en ser valorada fue la opci´on de crear una aplicaci´on (por ejemplo, una aplicaci´on web funcionando en un servidor Apache) que obtuviese datos en tiempo real de alguna plataforma de red social, como Twitter. Esta opci´on se descart´o al introducir m´as complejidad en las pruebas (diferentes APIs o interfaces para comunicar con las distintas bases de datos) y tiempos de latencia (de red, del servidor e incluso de la plataforma de red social). Puesto que en el fondo el contenido de los datos es ciertamente irrelevante, se consider´o la opci´on de generar datos aleatorios, en un formato elegido, hasta tener el volumen que se considere adecuado. En este orden, tambi´en se ha valorado la opci´on de obtener un conjunto de datos real desde un banco de datos o una fuente similar. Finalmente se consider´o que aunque el contenido de los datos no importase, el hecho de que los datos sean reales si podr´ıa a˜nadir cierto valor a las pruebas, que no se tendr´ıa al hacerlas con datos arbitrariamente aleatorios, ya que aunque no sea el objetivo, se estar´ıa empleando informaci´on real que podr´ıa resolver un problema real. 4.1.1. Elecci´on del conjunto de datos Al poner el foco en un conjunto de datos reales y en el contexto NoSQL, fue bastante natural pensar en datos obtenidos por sensores o aparatos IoT, de forma que se estar´ıa empleando informaci´on de una naturaleza similar a la que se emplea habitualmente en casos reales de aplicaciones NoSQL. Por este motivo, se ha optado por recurrir a un banco de datos, concretamente un repositorio de datos relacionados con el Machine Learning de la Universidad de California [53]. Buscando en este repositorio, se encontr´o un conjunto de datos bastante interesante y que cumpl´ıa con los requisitos especificados anteriormente; datos reales pertenecientes a mediciones realizadas con sensores de Smartphones ySmartwatches, con un gran n´umero de filas o instancias (43.930.257 exactamente) y un n´umero adecuado de columnas o atributos (16). El peso de este conjunto de datos completo es de 3.07 GB, pero est´a fraccionado en 4 archivos de formato .csv. Adem´as, se indica que existen valores faltantes o “perdidos”, lo cual tambi´en se adapta bien a la estructura deseada. Puesto que ese data set se ajusta bien a lo que se necesita para realizar las pruebas, se ha optado por emplearlo como el conjunto de datos que poblar´a las bases de datos. 54 4.1.2. Descripci´on del conjunto de datos elegido El conjunto de datos elegido recibe el nombre de “Heterogeneity Activity Recognition Data Set” [54] y es un conjunto de datos dise˜nado para comparar algoritmos de reconocimiento de la actividad humana (clasificaci´on, segmentaci´on autom´atica de datos, fusi´on de sensores, extracci´on de caracter´ısticas, etc.) en un contexto perteneciente al mundo real. Este data set contiene las lecturas de dos sensores de movimiento que se encuentran integrados com´unmente en los dispositivos inteligentes: aceler´ometro y giroscopio. Las lecturas se registraron mientras los usuarios –llevando un smartphone o un smartwatch– realizaban diferentes actividades; andar, ir en bici y subir o bajar escaleras, as´ı como estar sentado o de pie. Estos datos se han recogido en 4 archivos .csv seg´un el tipo de dispositivo y el tipo de sensor, y tienen los siguientes nombres: Phones accelerometer.csv, Phones gyroscope.csv, Watch accelerometer.csv, Watch gyroscope.csv. Los dispositivos que se han utilizado para recoger las muestras fueron 4 smartwatches (2 LG Watches y 2 Samsumg Galaxy Gears) y 8 smartphones (2 Samsung Galaxy S3 mini, 2 Samsumg Galaxy S3, 2 LG Nexus 4 y 2 Samsung Galaxy S+). Estos dispositivos fueron empleados por 9 usuarios diferentes, cada uno de ellos con un identificador distintivo asignado para poder diferenciarlos. La informaci´on de este conjunto de datos est´a estructurada de la siguiente manera: Index: Un ´ındice indicando el n´umero de fila. Arrival Time: Indica la hora a la que la medici´on lleg´o a la aplicaci´on de monitorizaci´on. Creation Time: Marca temporal que el Sistema Operativo asigna a la medici´on. X,y,z: Indica los valores proporcionados por los sensores en los 3 ejes; X, Y, Z. User: Nombre del usuario que gener´o la muestra, identificados por una letra de la “a a la “i. Model: Indica el modelo de tel´efono o reloj que origin´o la muestra. Device: Especifica el dispositivo en concreto que origin´o la muestra. Se les nombra a˜nadiendo al nombre del modelo, el n´umero identificativo de dispositivo, por ejemplo nexus4 1 y nexus4 2. Gt: Se˜nala la actividad que se estaba realizando; bike, sit, stand, walk, stairsup, stairsdown o null. Adicionalmente, este conjunto de datos anexa otro conjunto de datos muy diferente con 6 atributos relativos a la posici´on del aceler´ometro, sumando de esta forma 16 atributos totales con los 10 que se han explicado en la lista anterior. Para el caso de este experimento, se emplear´an los archivos en formato csv comentados anteriormente, con los 10 atributos listados. 4.2. Obtenci´on de los modelos de bases de datos En el mundo de las bases de datos relacionales, las metodolog´ıas y buenas pr´acticas a la hora de obtener modelos han sido ampliamente estudiadas, probadas y refinadas tras d´ecadas de investigaci´on y uso. En la figura 4.1 se muestra un flujo conceptualmente simplificado del proceso habitual a la hora de dise˜nar una base de datos relacional. Tal y como puede verse, tras analizar los requisitos y requerimientos de los datos, se realiza el modelado conceptual, normalmente en un diagrama de entidad-relaci´on (DER) [55] para posteriormente, normalizar el modelo relacional obtenido a partir del modelo conceptual. En la figura 4.2 se puede ver un ejemplo protot´ıpico de un Diagrama E-R. 4.2.1. Modelado de datos NoSQL El proceso de modelado de los datos en el mundo NoSQL se afronta con un punto de vista muy diferente al modelado relacional. No existe un est´andar ni unas normas bien definidas para la generaci´on de los 55 Figura 4.1: Dise˜no Bases de Datos Relacionales. Figura 4.2: Ejemplo de diagrama Entidad Relaci´on. modelos de datos NoSQL, en parte, por que existen demasiados tipos de bases de datos NoSQL, y cada una trata los datos de maneras diferentes. Por otra parte, las t´ecnicas aplicadas al dise˜no relacional no son aplicables (no eficazmente) en bases de datos no relacionales. Los diagramas de entidad-relaci´on, pese a formar parte del proceso de Modelado Conceptual (y por tanto, ser t´ecnicamente aplicables tambi´en al mundo no relacional), est´an muy ligados al Modelo Relacional, tanto que existe una cierta tendencia en el mundo NoSQL de evitar este tipo de diagramas a menos que sea estrictamente necesario (estar manejando datos que poseen relaciones importantes entre ellos y usar una base de datos no relacional que permita implementar dichas relaciones). Las bases de datos NoSQL est´an dise˜nadas pensando en maximizar la eficiencia y en afrontar los problemas que el enfoque relacional no puede gestionar de manera eficaz, de esta forma, el modelado de datos NoSQL se pliega a los requisitos y estructuras de datos cambiantes, apostando por la flexibilidad y enfoc´andose en qu´e datos se buscar´an y qu´e caracter´ısticas tendr´a dicha b´usqueda. As´ı pues, al modelar datos orientados al mundo NoSQL, se tiende a realizar un proceso de desnormalizaci´on de los datos. Las tendencias actuales a la hora de realizar un modelo de datos NoSQL seg´un las relaciones de los mismos son las siguientes: Embedding : Consiste en almacenar datos relacionados (generalmente, con una relaci´on 1 a 1) en una ´unica estructura (documento, tabla, keyspace...). De esta forma, a la hora de realizar b´usquedas se evita realizar operaciones de JOIN y se maximiza el rendimiento. Establecer relaciones : Consiste en generar referencias y relaciones entre elementos existentes en la base de datos (normalmente cuando las relaciones son de tipo 1 a * ). A diferencia de en los sistemas gestores de bases de datos relacionales, este tipo de modelado de datos no es aplicable a todas las 56 bases de datos NoSQL, y en las que lo es, queda naturalmente restringido por las caracter´ısticas propias de cada sistema gestor de bases de datos. Con esta tendencia es habitual emplear diagramas DER para el modelado conceptual de los datos. Gestionar las relaciones en la capa de aplicaci´on : Por ´ultimo, es habitual en el mundo NoSQL almacenar los datos en bruto, sin importar en absoluto cuestiones como que sean no estructurados o semi-estructurados, que no est´en normalizados, que haya cierta redundancia en ellos o que est´en relacionados entre s´ı. De esta forma el sistema gestor de bases de datos nosql ´unicamente se encargar´ıa de realizar las lecturas y escrituras de los datos, dejando las cuestiones relativas a su tratamiento a la capa de aplicaci´on del servicio que los emplea. En base a estas tres tendencias, se puede asumir que el enfoque de embeber datos en una ´unica estructura ser´ıa una decisi´on acertada cuando las relaciones entre ellos sean simples y que el de establecer relaciones y referencias entre los datos lo ser´a cuando sea necesario un enfoque m´as relacional de los mismos. Por su parte, el almacenamiento en bruto de los datos ignora casi por completo cuestiones relativas al modelado conceptual o l´ogico y se centra en la eficiencia m´axima de la escritura y lectura de los datos. Esta tendencia a la hora de tratar la informaci´on es muy adecuada cuando hablamos en t´erminos de Big Data e IoT, ya que son dos situaciones en las que, tanto la afluencia como el volumen de los datos que se acaban manejando resultan enormes. En definitiva, se puede decir que el mundo NoSQL genera nuevos desaf´ıos a la hora de modelar los datos de manera flexible y siempre ha de estar orientado a la eficacia de las consultas. Es por eso que la representaci´on del modelo de datos no relacional es en ocasiones problem´atico, pudi´endose encontrar representaciones variopintas de los mismos; desde modelos de entidad-relaci´on cl´asicos, representaciones en JSON, descripciones m´as o menos formales representadas en tablas o esquemas, etc... Todo lo explicado en este apartado sobre la problem´atica del modelado de la informaci´on para bases de datos NoSQL lleva habitualmente a la conclusi´on l´ogica de que en realidad, el enfoque NoSQL no emplea ning´un modelo de datos. Esta afirmaci´on es en algunos casos un tanto arriesgada y en otros, errada. Lo que s´ı es cierto, es que sea cual sea el enfoque del SGBD NoSQL que se emplee, este emplear´a un esquema o modelo flexible que normalmente se ir´a adaptando y refinando con el tiempo. 4.2.2. Modelado de los datos elegidos Siguiendo con lo explicado en el punto anterior, en este punto se pasar´a a comentar c´omo se modelar´a concretamente el dataset elegido, as´ı como las opciones que se han barajado y el razonamiento para aceptarlas o rechazarlas. El conjunto de datos que se emplear´a est´a repartido entre 4 archivos en formato CSV que no tienen unas relaciones fuertes entre ellos. Naturalmente, desde un punto de vista relacional se podr´ıa realizar un proceso de modelado conceptual y normalizaci´on que probablemente generar´ıa otras tablas adicionales, como “Usuarios”, “Modelo del dispositivo” o “Actividad” y que podr´ıan ser empleadas para mantener la integridad referencial (claves for´aneas) de las tablas ya existentes. Sin embargo, como se ha podido ver a lo largo del presente documento, emplear una base de datos no relacional utilizando un enfoque puramente relacional, si bien en ocasiones concretas podr´ıa resultar ser viable, no es recomendable. Debido a esto, a continuaci´on se enumeran las opciones que se han valorado a la hora de implementar las tablas de las bases de datos para MongoDB y Cassandra. Enti´endase que en este punto se est´a empleando el t´ermino “tabla” de manera gen´erica para referirse a las estructuras propias de cada SGBD NoSQL, y no en t´erminos relacionales. 1. Desnormalizaci´on total en una ´unica tabla: Esta opci´on ser´ıa completamente contraria al modelado relacional cl´asico, uniendo la informaci´on contenida en los 4 archivos .csv en una ´unica 57 user, model, device, gt) FROM ’/home/opcion2_watch.csv’ WITH HEADER = TRUE;" Al tener dos modelos bien diferenciados, con una gran diferencia de filas a insertar, se podr´a establecer una comparativa entre ambas bases de datos teniendo en cuenta la cantidad de datos a importar. Es por esto que en este punto, se ha optado por realizar la carga de dos de los archivos, en lugar de los 3 preparados anteriormente. En las consultas sobre el modelo 2 no se realizar´an JOINS entre las dos estructuras, por lo tanto cargar ambos archivos no ofrece nada demasiado relevante ni diferencial, pues las consultas se deber´an hacer sobre las tablas separadas. Debido a esto, se importar´an el archivo .csv correspondiente al primer modelo y el archivo .csv correspondiente a la los datos de los Smart Watchs en el modelo 2, por ser el que tiene un n´umero menor de filas, y por tanto, presentar una mayor diferencia de tama˜no con respecto al archivo que contiene todos los datos. Es importante se˜nalar en este punto que, la inserci´on masiva de datos se realizar´a de una forma m´as lenta al contar ambas bases de datos con estructuras de ´ındices creadas previamente, pues se ordenar´an las filas/documentos seg´un se vayan importando. Si bien en cuanto a los tiempos de inserci´on no estaremos en un escenario del mejor caso, si estamos en un escenario m´as realista y equilibrado entre ambos sistemas de bases de datos. Tambi´en cabe destacar que estas estructuras de ´ındices ser´an ´utiles para la ejecuci´on ´optima del resto de consultas, y que como se ha comentado en el cap´ıtulo anterior, en el caso de Cassandra su uso se hace necesario para no perder contenido. 5.1.2. Consultas Para la realizaci´on de consultas o b´usquedas a la base de datos, MongoDB emplea la sentencia propia de JavaScript find() mientras que Cassandra emplea SELECT, igual que en SQL. Con el objetivo de establecer una comparativa fiable entre ambas bases de datos, se ha optado por realizar una consulta relativamente sencilla, con varios operadores de b´usqueda (igualdad, mayor que, menor que...), que afecten tanto a campos indexados como a no indexados y que adem´as arrojen el mismo resultado tanto para el modelo 1, en el que todos los datos se han cargado desde un ´unico archivo en una ´unica estructura, como para el modelo 2 en el que los archivos estaban separados, y por tanto, los datos almacenados tambi´en. Con esto en mente, se han seleccionado los campos Sensor, User, Model, x, z y gt como el objeto de las consultas y se han establecido los valores por los que se filtrar´an: sensor = accelerometer user = a Model = lgwatch x > −6,9 z < 2,3 gt = sit De esta forma, las consultas resultantes quedar´ıan de la siguiente forma, respectivamente para MongoDB y para Cassandra: db.coleccion.find({"Sensor":"accelerometer","gt":"sit","User":"a","Model":"lgwatch", "x": {$gt: -6.9},"z":{$lt:2.3}}).forEach(printjson) SELECT * FROM tabla WHERE sensor=’accelerometer’and gt=’sit’ and user=’a’ and model=’lgwatch’ and x >-6.9 and z<2.3 ALLOW FILTERING; Las consultas sobre las bases de datos con estos filtros, ofrecen 81 documentos/filas como resultado para ambas bases de datos. Si bien, se hace necesario explicar las ordenes a˜nadidas a cada una de los comandos de b´usqueda. 64 En MongoDB, los datos por defecto se cargan en un cursor que permite iterarlos de 20 en 20, ya sea de forma manual en la shell de mongo o con un script que lo haga autom´atico. Para evitar este comportamiento por defecto, se a˜nade el m´etodo forEach(), indic´andole que muestre todos los datos en formato JSON. Por su parte, el comportamiento por defecto de Cassandra no permite realizar consultas que escapen del ´ambito de la clave primaria o de los ´ındices secundarios, s´olo permitiendo dichas consultas si se incluye la cl´ausula ALLOW FILTERING. Por otra parte, Cassandra muestra los resultados por lotes, de forma an´aloga a MongoDB, con un batch de 100 filas iterables. La consulta elegida proporciona 81 resultados, y por tanto no se hace necesario evitar este comportamiento, pero de requerirlo, se podr´ıa abordar con la sentencia PAGING OFF. 5.1.3. Actualizaciones La idea original al plantear las operaciones que se ejecutar´ıan para las pruebas de rendimiento radicaba en pares sim´etricos: Que las operaciones de inserci´on y borrado, por un lado, y las de b´usqueda y actualizaci´on, por otro, involucrasen a las mismas filas. De esta manera, el borrado se realizar´ıa sobre toda la base de datos, y se realizar´ıa un UPDATE sobre los 81 resultados obtenidos por la consulta anterior. En MongoDB, esta idea se reflejar´ıa con la siguiente consulta, donde se actualiza el campo model: .updateMany({"Sensor":"accelerometer","gt":"sit","User":"a","Model":"lgwatch", "x": {$gt: -6.9},"z":{$lt:2.3}}, {$set: {"model":"newwatch"}}) No obstante, las sentencias UPDATE en Cassandra tienen las siguientes limitaciones: 1. Tiene que actualizarse un campo que no forme parte de la clave primaria. 2. En la cl´ausula WHERE se tienen que incluir todos los campos que compongan la clave primaria. 3. Las comparaciones han de ser de igualdad (= ´o IN ). 4. No se pueden incluir comparaciones de campos que no pertenezcan a la clave primaria. Al darse las limitaciones que se acaban de enumerar de manera conjunta, la idea original se ve truncada, pues estas limitaciones implican que las actualizaciones de datos est´an orientadas a realizarse sobre filas individuales y no sobre grandes conjuntos de filas. Por esto, se ha optado por adaptar la sentencia de actualizaci´on de datos para ambos sistemas gestores de bases de datos, de forma que actualicen el valor del campo de una ´unica fila, tal y como puede verse a continuaci´on: UPDATE watch SET model =’newwatch’ where sensor=’accelerometer’ and gt=’sit’ and user=’a’ and indice =122214; db.watch.updateOne({"Sensor":"accelerometer","gt":"sit","User":"a","Index":122214}, {$set: {"model":"newwatch"}}) Si bien, estas sentencias distan bastante del concepto original mostrado anteriormente, tambi´en resulta interesante ver como manejan las dos bases de datos este tipo de actualizaciones tan concretas, especialmente en el primer modelo, que maneja una gran cantidad de filas/documentos. 65 5.1.4. Borrado A diferencia de la sentencia de actualizaci´on de Cassandra, que result´o ser muy poco flexible e intuitiva, la sentencia de borrado si permite un mayor grado de flexibilidad. DELETE permite borrar tanto filas como columnas, siendo necesario indicar condiciones en la cl´ausula where, a diferencia del lenguaje SQL. Estas condiciones de la sentencia where no est´an sujetas a las mismas restricciones que el UPDATE, pudi´endose emplear campos no pertenecientes a la clave primaria y comparaciones de mayor o menor, por ejemplo. Cassandra tambi´en permite el borrado masivo de los datos contenidos en una tabla, al eliminar dicha tabla (DROP TABLE) o truncarla (TRUNCATE TABLE), siendo la ´unica diferencia entre estas sentencias que drop table tambi´en elimina la estructura de la tabla y truncate table, ´unicamente el contenido. Como la intenci´on desde el principio fue borrar todo el contenido de la tabla, se optar´a por emplear la sentencia de truncado en Cassandra y una sentencia equivalente en MongoDB. Un ejemplo de ambas puede verse en las siguientes l´ıneas: TRUNCATE watch; db.watch.deleteMany({}) En esta secci´on se han fijado las sentencias que se ejecutar´an en ambas bases de datos, realizando un esfuerzo para que sean equivalentes y equitativas para las dos, de forma que las pruebas de rendimiento sean v´alidas y ´utiles. No obstante, esto tambi´en ha servido para hacer una comparativa a nivel conceptual y funcional sobre el uso y la flexibilidad de estas bases de datos, quedando patente que MongoDB resulta mucho m´as flexible y accesible que Cassandra. 5.2. Mediciones y Ejecuci´on de comandos El comando time es un comando del sistema operativo Unix y derivados que se utiliza para determinar la duraci´on de ejecuci´on de un determinado comando. Este comando informa de cuanto tiempo llev´o ejecutar la orden indicada en t´erminos de tiempo de CPU de usuario, tiempo de CPU del sistema y tiempo real, arrojando una salida similar a la siguiente: # time ls -lh total 8,0K drwxr-xr-x 3 root root 4,0K abr 10 16:16 Desktop drwxr-xr-x 5 root root 4,0K abr 10 22:09 ejemplos real 0m0.020s user 0m0.000s sys 0m0.004s Como este comando proporciona diferentes tiempos, se hace necesario explicar qu´e es cada tiempo y cu´al se tomar´a como el valor m´as ´util para la medici´on del rendimiento. A modo de ejemplo, cuando un programa recorre una matriz, se acumula tiempo de CPU de usuario. Por el contrario, cuando un programa ejecuta una llamada al sistema, como un exec o un fork, se est´a acumulando tiempo de CPU del sistema. Por su parte, el t´ermino tiempo real en este contexto se refiere al tiempo transcurrido, como si fuese un cron´ometro. El tiempo de CPU total (tiempo de usuario + tiempo de sistema) puede ser mayor o menor que ese valor de tiempo real, seg´un el comportamiento del sistema en el momento que se ejecuta el comando. [58] 66 Conociendo esto, se optar´a por tomar el valor de tiempo real que proporciona el comando time. Una vez definida la manera en la que se tomar´a los tiempos, ´unicamente queda adaptar las sentencias fijadas en la secci´on anterior para poder lanzarlas desde la consola de linux, junto al comando time. Como se ha podido observar, la mayor´ıa de estas sentencias se realizan desde el bash propio de cada gestor, accediendo a ´el con los comandos mongo ycqlsh, siendo la excepci´on el comando mongoimport, que se ejecuta desde la consola de linux. Para lanzar consultas desde la consola de linux, en MongoDB encontramos la opci´on - -eval ’sentencia javascript’ del comando mongo, teniendo que indicar la base de datos sobre la que se realizar´a la consulta. Mientras que en Cassandra, se dispone de la opci´on -e “sentencia CQL” del comando cqlsh, habiendo que indicarle con el comando -k el keyspace que se usar´a. As´ı pues, las sentencias completas que se han usado para la realizaci´on de las pruebas se pueden ver en el Anexo III. Finalmente, la ejecuci´on de estos comandos se ha automatizado mediante el uso de scripts bash sencillos, que recogen la salida de los comandos (incluyendo el tiempo proporcionado por “time”) en archivos separados, para poder validar su correctitud. Estos scripts, que pueden verse en los anexos III y IV realizan el flujo completo de pruebas, comenzando por la inserci´on masiva de datos, continuando con la b´usqueda y la actualizaci´on de los mismos, y finalizan borrando todos los datos de las bases de datos. Debido a la forma en la que han sido dise˜nadas las pruebas, no es necesario repetir las sentencias de creaci´on de las bases de datos: el truncado en Cassandra no elimina el esquema de la base de datos y el borrado de todos los documentos de la colecci´on no elimina los ´ındices creados en MongoDB sobre la misma, de forma que tras el borrado de todo el contenido, las bases de datos quedan preparadas para volver a repetir todo el proceso. La forma en la que se lanzan los scripts para la realizaci´on de las pruebas es la siguiente: sudo ./mongo_script_pruebas.sh >> salida_mongo.txt 2>> salida_mongo.txt sudo ./cassandra_script_pruebas.sh >> salida_cassandra.txt 2>> salida_cassandra.txt 67 68 Cap´ıtulo 6 An´alisis de los resultados Tras haber realizado las pruebas de rendimiento y tomado las medidas de tiempo tal y como se indic´o en el cap´ıtulo anterior, en este cap´ıtulo se presentar´an los resultados obtenidos mediante tablas y gr´aficas, con el fin de poder analizar los resultados de una forma clara y eficaz. Tras la presentaci´on de los resultados obtenidos en las pruebas, se espera que el an´alisis de los mismos revele cual de estos motores de bases de datos tiene un mejor desempe˜no. Antes de realizar dicho an´alisis y de ver los resultados de las pruebas realizadas, en funci´on de lo visto en los anteriores cap´ıtulos, se realizan las siguientes hip´otesis sobre el comportamiento de estas bases de datos ante las pruebas: 1. Las operaciones de inserci´on y borrado de todos los datos ser´an las m´as costosas en t´erminos computacionales y de tiempo para ambas bases de datos. 2. Las operaciones de inserci´on tardar´an aproximadamente lo mismo para ambas bases de datos, pues han de ordenarlos (indexarlos) seg´un se insertan. 3. Las b´usquedas en Cassandra, al emplear valores que est´an fuera de la clave primaria, deber´ıan ser m´as lentas. 4. Debido a lo restrictiva que ha resultado ser Cassandra para las actualizaciones de los datos almacenados, se presupone que deber´an ser m´as r´apidas. Como parte del an´alisis final, se comprobar´a si estas hipot´eticas suposiciones se muestran como correctas, o si por el contrario, algunas de ellas –o todas– est´an equivocadas. 6.1. MongoDB Los datos obtenidos al realizar las pruebas sobre MongoDB se encuentran reflejados en las 3 tablas siguientes: Modelo 1 Modelo 2 Port´atil I5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 19m 14.36s 20m 8s 20m 54.6s 18m 27.24s 18m 25.65s 3m 4.09s 3m 9.78s 2m 47.71s 2m 47.27s 2m 47.63s B´usqueda 35.780s 33.24s 29.44s 30.80s 29.99s 2.88s 3.08s 2.64s 2.65s 2.57s Actualizaci´on 3.34s 2.97s 2.74 s 2.41s 2.62s 0.11s 0.107s 0.09s 0.1s 0.096s Borrado 14m 34.38s 14m 14.89s 12m 8.95s 12m 8.20s 12m 11.72s 1m 55.46s 1m 59.95s 1m 41.2s 1m 42.06s 1m 41.92s Tabla 6.1: Datos obtenidos en las pruebas de MongoDB sobre el port´atil i5 69 Modelo 1 Modelo 2 M´aquina Virtual R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 27m 18,83s 28m 20,19s 28m 30,71s 28m 43,3s 28m 38,21s 4m 10,60s 4m 12,36s 4m 17,68s 4m 13,47s 4m 14,47s B´usqueda 1m 2,50s 1m 3,52s 1m 6,10s 1m 5s 1m 2,19s 4.80s 4,56s 4,87s 4,91s 4,74s Actualizaci´on 5,12s 5,60s 5,91s 5,85s 6,13s 0.10s 0.11s 0,10s 0,12s 0,12s Borrado 30m 4,43s 31m 0,21s 32m 8,72s 31m28,12s 31m 56,71 4m 50,22s 4m 56,89s 5m 10,19s 4m 54,26s 5m 1,3s Tabla 6.2: Datos obtenidos en las pruebas de MongoDB sobre la m´aquina virtual Modelo 1 Modelo 2 Port´atil I3 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 43m 30,61s 54m 49,84s 41m 58,45s 49m 7,69s 54m 42,88s 5m 9,08s 4m 36,92s 4m 53,61s 4m 44,597ss 4m 50,81s B´usqueda 1m 35,79s 1m 5,41s 58,16s 1m 5,02s 59,90s 11,46s 9,98s 10,88s 7,80s 8,88s Actualizaci´on 19,21s 7,53s 6,37s 8,99s 7,40s 2,31s 0,18s 0,13s 0,23s 0,23s Borrado 38m 53,28s 33m 37,68s 38m 57,14s 35m 21,64s 37m 19,09s 3m 25,19s 3m 14,14s 3m 16,46s 3m 23,74s 3m 26,85s Tabla 6.3: Datos obtenidos en las pruebas de MongoDB sobre el port´atil I3 6.2. Cassandra Los datos obtenidos al realizar las pruebas sobre Cassandra se encuentran reflejados en las 3 tablas siguientes: Modelo 1 Modelo 2 Port´atil I5 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 43m 53,94s 43m 26,51s 43m 30,75s 43m 23,37s 43m 30,40s 7m 58,33s 7m 56,65s 7m 56,54s 7m55,91s 7m 58,88s B´usqueda error error error error error error error error error error Actualizaci´on 0,64s 0,62s 0,46s 0,53s 0,60s 0,63s 0,47s 0,48s 0,55s 0,61s Borrado 1,53s 0,74s 0,73s 0,85s 0,71s 0,99s 1,01s 0,72s 0,80s 1,11s Tabla 6.4: Datos obtenidos en las pruebas de Cassandra sobre el port´atil I5 Modelo 1 Modelo 2 M´aquina virtual R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 91m 16,04s 91m 53,86s 95m 38,51s 94m12,19s 95m 23,53s 16m 43,13s 17m 48,52s 18m 23,85s 17m 5,21s 17m 36,92s B´usqueda error error error error error error error error error error Actualizaci´on 0,60s 0,59s 0,64s 0,61s 0,60s 0,58s 0,61s 0,60s 0,61s 0,58s Borrado 2,37s 2,24s 2,01s 1,23s 1,94s 1,03s 0,93s 1,88s 1,51s 1,54s Tabla 6.5: Datos obtenidos en las pruebas de Cassandra sobre la m´aquina virtual Modelo 1 Modelo 2 Port´atil I3 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 Inserciones 57m 33,95s 57m 12,68s 57m 40,28s 59m 9,14s 57m 11s 10m 34,44s 10m 31,76s 10m 26,45s 10m 34,54s 10m 31,34 B´usqueda error error error error error error error error error error Actualizaci´on 0,59s 0,53s 0,75s 0,52s 0,55s 0,56s 0,80s 0,74s 0,66s 0,72s Borrado 2,98s 2,28s 3,07s 1,59s 4,51s 2,14s 4,08s 3,82s 3,30s 5,18s Tabla 6.6: Datos obtenidos en las pruebas de Cassandra sobre el port´atil I3 Los datos obtenidos en las pruebas de este gestor de bases de datos han sido an´omalos en 2 de las 4 operaciones realizadas: b´usqueda y borrado. A la hora de realizar las b´usquedas en Cassandra, en todas las ejecuciones del script, al llegar a la secci´on de b´usqueda han arrojado el siguiente error: ReadFailure: Error from server: code=1300. Replica(s) failed to execute read. message=”Operation failed - received 0 responses and 1 failures” info=’failures’: 1, ’received responses’: 0, ’required responses’:1, ’consistency’: ’ONE’ Error que al consultarlo en la web, resulta ser un error gen´erico muy habitual en Cassandra y puede estar originado por m´ultiples motivos. Tras indagar en los diferentes logs que genera la base de datos, se encontr´o en /var/log/cassandra/debug.log la siguiente l´ınea: 70 <SELECT * FROM opcion1.phone_watch WHERE sensor = accelerometer AND model = lgwatch AND x > -6.9 AND z < 2.3 AND >, total time 5006 msec, timeout 5000 msec Que viene a indicar que la operaci´on se ha cancelado por alcanzar un estado de timeout. As´ı pues, para poder repetir las pruebas, se ha realizado la siguiente modificaci´on en el fichero de configuraci´on cassandra.yaml, modificando los valores para hacerlos lo suficientemente grandes como para que no puedan interferir con la operaci´on de b´usqueda. # How long the coordinator should wait for read operations to complete read_request_timeout_in_ms: 50000000 # How long the coordinator should wait for seq or index scans to complete range_request_timeout_in_ms: 10000000 # The default timeout for other, miscellaneous operations request_timeout_in_ms: 10000000 Y tras reiniciar el servicio de cassandra, se han repetido las pruebas, arrojando esta vez un resultado v´alido para el port´atil I5, pero saltando otro error diferente para la m´aquina virtual y el port´atil I3: OperationTimedOut: errors=127.0.0.1: Client request timeout. See Session.execute[async] (timeout), last host=127.0.0.1 Este error se ha esquivado introduciendo un par´ametro adicional en la sentencia cqlsh que se lanza por consola, siendo 12.000 un n´umero arbitrario lo suficientemente alto como para asegurar que no haya ning´un problema m´as de tipo request timeout: time cqlsh --request-timeout 12000 Modelo 1 Modelo 2 R1 R2 R3 R4 R5 R1 R2 R3 R4 R5 B´usqueda I5 8,00s 8,02s 8,06s 8,03s 8,11s 4,01s 3,83s 3,77s 3,71s 3,71s B´usqueda MV 22,69s 20,81s 20,23s 19,86s 19,75s 11,35s 10,989s 10,91s 10,01s 9,91s B´usqueda I3 16,75s 10,92s 10,37s 10,21s 10,27s 12,24s 6,24s 6,12s 6,12s 6,10s Tabla 6.7: Datos obtenidos al repetir las pruebas de b´usqueda sobre Cassandra. Por su parte, el truncado/borrado de la base de datos en Cassandra es, en todo momento, un proceso extremadamente r´apido seg´un los datos obtenidos. Datos que no parecen tener ning´un sentido tras observar que Cassandra es objetivamente m´as lenta que MongoDB en las operaciones de escritura –inserciones– realizadas previamente. Esto es, al parecer, debido a la forma en que Cassandra realiza esta operaci´on. En lugar de borrar del disco una a una todas las filas, marca el contenido de toda la tabla como borrado y posteriormente, seg´un el comportamiento por defecto, realiza un snapshot de todos los datos almacenados, para posibilitar su posterior recuperaci´on en caso de ser necesario. Este comportamiento puede deshabilitarse en el fichero de configuraci´on de la base de datos. En cualquier caso, los datos dejan de estar accesibles inmediatamente tras el truncado de la tabla, aunque el espacio en disco no se recupera inmediatamente. Tambi´en es interesante la salida del comando time para cassandra, pues en algunas de las inserciones se observa algo similar a esto: 71 *** -> Empezando repeticion: 5 Poblando base de datos Cassandra en opcion1 real 43m30,405s user 97m12,845s sys 4m2,408s Siendo el tiempo de usuario mucho mayor que el tiempo real, que proporcionan tanto el comando time como el propio servicio de cassandra tras finalizar la inserci´on masiva de datos. 6.3. Comparaci´on gr´afica Tras la presentaci´on de los tiempos obtenidos en las 5 repeticiones establecidas para cada base de datos y cada modelo en cada m´aquina de pruebas, en esta secci´on se presenta una comparativa gr´afica entre los tiempos medios obtenidos por cada gestor para cada modelo. Figura 6.1: Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en I5. En la gr´afica 6.1 se puede ver la fuerte correlaci´on existente entre el tiempo y el n´umero de instancias a insertar. Tambi´en es palpable el hecho de que Cassandra necesita aproximadamente el doble de tiempo que MongoDB para realizar el mismo trabajo de inserci´on masiva. Figura 6.2: Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en MV. En la gr´afica 6.2, que muestra la comparaci´on de tiempo de inserci´on en la m´aquina virtual, tenemos una situaci´on curiosa, pues los tiempos para importar los datos en MongoDB son ligeramente mayores que a los vistos en la m´aquina I5, lo que simplemente indica que este port´atil es algo m´as potente que 72 la m´aquina virtual, pero resulta un tanto extra˜no que los tiempos para las inserciones de Cassandra se disparen en la m´aquina virtual, siendo m´as de 3 veces superiores a los tiempos de MongoDB, y siendo m´as del doble de los tiempos de Cassandra en el port´atil I5. Figura 6.3: Comparaci´on de tiempos de inserci´on entre MongoDB y Cassandra en I3. Por su parte, la gr´afica 6.3 muestra una situaci´on m´as paritaria en la m´aquina I3 entre ambas bases de datos y en ambos modelos. Los resultados para MongoDB son mayores que los vistos en las otras dos m´aquinas –lo cual resulta bastante normal, pues parece poseer el hardware m´as modesto– pero los de Cassandra son ostensiblemente menores que los encontrados en la m´aquina virtual. Figura 6.4: Comparaci´on de tiempos de b´usqueda entre MongoDB y Cassandra en I5. En cuanto a la comparaci´on de tiempos de b´usqueda, los resultados encontrados son realmente curiosos e interesantes. Empezando por la m´aquina I5, en la gr´afica 6.4 tenemos que las b´usquedas en Cassandra para ambos modelos est´an muy pr´oximas en tiempo, siendo algo menores para el segundo modelo, que contiene menos datos. Lo que se hace evidente tanto en esta gr´afica como en las gr´aficas 6.5 y 6.6 es que el tiempo de b´usqueda en Cassandra no depende directamente de la cantidad de datos contenidos, a diferencia de MongoDB, donde se ve claramente que s´ı tiene esa dependencia directa. Tambi´en es destacable la brutal diferencia que esta dependencia sobre la cantidad de datos genera en ambos modelos, teniendo en cuenta el hardware. Para el modelo con m´as cantidad de datos, la b´usqueda en MongoDB es aproximadamente tres veces m´as lenta tanto para el port´atil I5 como para la m´aquina virtual, pero es 6 veces m´as lenta para el port´atil I3. Por el otro lado, encontramos que para el segundo modelo, MongoDB es ostensiblemente m´as r´apido en las dos m´aquinas m´as potentes, y ligeramente m´as lento en la m´aquina modesta. 73 [12] R. Garc´ıa Cebreiros. (2016-07-21) An´alisis de bases de datos y tendencias tecnol´ogicas. un caso de uso en twitter para aplicaciones de an´alisis de sentimientos y opiniones. Universidad de Alicante. [Online]. Available: http://hdl.handle.net/10045/57065 [13] V. J. BAS ABAD. (2015) Estudio comparativo de BBDD relacionales y NoSQL en un entorno industrial. Universidad Polit´ecnica de Valencia. [Online]. Available: http: //hdl.handle.net/10251/55530 [14] (2018) DB Engine. [Online]. Available: https://db-engines.com/en/ [15] (2018) Data Never Sleeps 6.0. DOMO.com. [Online]. Available: https://www.domo.com/learn/ data-never-sleeps-6 [16] (2019) Data Never Sleeps 7.0. DOMO.com. [Online]. Available: https://www.domo.com/learn/ data-never-sleeps-7 [17] Ecosistema Big Data. paradigmadigital.com. [Online]. Available: https://www.paradigmadigital.com/ ecosistema-big-data/ [18] (2017) ¿Qu´e es NoSQL y qu´e Big Data? edgartec.com. [Online]. Available: http://edgartec.com/ que-es-nosql-y-que-bigdata/ [19] J. Gray. (1981) The Transaction Concept: Virtues and Limitations. [Online]. Available: http://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf [20] T. Haerder and A. Reuter, “Principles of transaction-oriented database recovery,” ACM Comput. Surv., vol. 15, no. 4, pp. 287–317, Dec. 1983. [Online]. Available: http://doi.acm.org/10.1145/289.291 [21] B. Ippolito. (2009) Drop ACID and think about data. PyCOn 2009. [Online]. Available: https: //bob.ippoli.to/python/pycon/archives/2009/04/01/pycon-2009-drop-acid-and-think-about-data [22] C. Strauch. (2011) NoSQL Databases. Stuttgart Media University. [Online]. Available: http://www.christof-strauch.de/nosqldbs [23] E. Brewer. (2000) Towards Robust Distributed Systems. [Online]. Available: http://www.cs.berkeley. edu/∼brewer/cs262b-2004/PODC-keynote.pdf [24] Bases de datos NoSQL. Qu´e son y tipos que nos podemos encontrar. Acens. [Online]. Available: https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf [25] (2017) NoSQL y sus tipos. Smart Base. [Online]. Available: http://smartbasegroup.com/ bds-nosql-tipos/ [26] (2018) NoSQL Databases. [Online]. Available: http://nosql-database.org/ [27] O. Blancarte. (2017) Escalabilidad Horizontal y Vertical. [Online]. Available: https://www. oscarblancarteblog.com/2017/03/07/escalabilidad-horizontal-y-vertical/ [28] (2015) NoSQL vs SQL: Principales diferencias y cu´ando elegir cada una de ellas. PandoraFMS. [Online]. Available: https://blog.pandorafms.org/es/nosql-vs-sql-diferencias-y-cuando-elegir-cada-una/ [29] (2017) Bases de datos NoSQL : Gu´ıa definitiva. PandoraFMS. [Online]. Available: https: //blog.pandorafms.org/es/bases-de-datos-nosql/ 80 [30] (2018) Repositorio de MongoDB en GitHub. Github. [Online]. Available: https://github.com/ mongodb/mongo [31] (2009) 32-bit limitations. MongoDB. [Online]. Available: https://www.mongodb.com/blog/post/ 32-bit-limitations [32] (2017) farewell, Solaris. MongoDB. [Online]. Available: https://engineering.mongodb.com/post/ farewell-solaris [33] (2018) Our Customers. MongoDB Inc. [Online]. Available: https://www.mongodb.com/ who-uses-mongodb [34] (2017) Empresas que usan MongoDB. Openwebinars. [Online]. Available: https://openwebinars.net/ blog/empresas-que-usan-mongodb/ [35] (2018) What is MongoDB? MongoDB Inc. [Online]. Available: https://www.mongodb.com/ what-is-mongodb [36] BSON types. MongoDB Inc. [Online]. Available: https://docs.mongodb.com/manual/reference/ bson-types/ [37] Aggregation. MongoDB Inc. [Online]. Available: https://docs.mongodb.com/manual/aggregation/ [38] (2017) Ransomware groups have deleted over 10,000 MongoDB databases. computerworld. [Online]. Available: https://www.computerworld.com/article/3155260/security/ ransomware-groups-have-deleted-over-10000-mongodb-databases.html [39] (2018) Its the data. Stupid! Shodan.io. [Online]. Available: https://blog.shodan.io/its-the-data-stupid/ [40] (2018) Security Checklist. MongoDb Inc. [Online]. Available: https://docs.mongodb.com/manual/ administration/security-checklist/ [41] (2018) GitHub Cassandra. GitHub. [Online]. Available: https://github.com/apache/cassandra [42] (2018) DataStax Enterprise. DataStax. [Online]. Available: https://www.datastax.com/products/ datastax-enterprise [43] (2018) DataStax Distribution of Apache Cassandra. DataStax Academy. [Online]. Available: https://academy.datastax.com/planet-cassandra//cassandra [44] (2017) No Datastax - Apache Cassandra 3.11 - Windows installation. YouTube. [Online]. Available: https://www.youtube.com/watch?v=Mn1xOHAH dc [45] (2016) Apache Cassandra. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/ [46] (2018) Cassandra System Properties. DB-ENgine. [Online]. Available: https://db-engines.com/en/ system/Cassandra#a34 [47] (2016) CQL - Data definition. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/ doc/latest/cql/ddl.html [48] (2018) Internode Communications (Gossip). DataStax. [Online]. Available: https://docs.datastax. com/en/dse/6.0/dse-arch/datastax enterprise/dbArch/archGossipAbout.html [49] (2016) Snitch. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/doc/latest/ operating/snitch.html 81 [50] (2016) Tunable Consistency. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/ doc/latest/architecture/dynamo.html#tunable-consistency [51] (2016) Big Data Security Tales: MongoDB Cassandra (Level 101). Un Inform´atico en el Lado del Mal. [Online]. Available: https://www.elladodelmal.com/2016/07/big-data-security-tales-mongodb.html [52] (2016) Security. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/doc/latest/ operating/security.html [53] D. Dua and C. Graff, “UCI machine learning repository,” University of California, Irvine, School of Information and Computer Sciences, 2017. [Online]. Available: http://archive.ics.uci.edu/ml [54] (2015) Heterogeneity Human Activity Recognition Dataset. University of California, Irvine, School of Information and Computer Sciences. [Online]. Available: https://archive.ics.uci.edu/ml/datasets/ Heterogeneity+Activity+Recognition [55] (2019) Modelo entidad-relaci´on. Wikipedia. [Online]. Available: https://es.wikipedia.org/wiki/ Modelo entidad-relaci%C3%B3n [56] (2019) Installing Cassandra. Apache Cassandra. [Online]. Available: https://cassandra.apache.org/ doc/latest/getting started/installing.html [57] (2019) Install MongoDB. MongoDB Inc. [Online]. Available: https://docs.mongodb.com/manual/ tutorial/install-mongodb-on-ubuntu/ [58] (2017) time (Unix). Wikipedia. [Online]. Available: https://es.wikipedia.org/wiki/Time (Unix) 82 Anexos 83 Anexo A Contenido del soporte digital El CD contiene el siguiente material: Documento PDF que contiene la memoria del proyecto (memoria.pdf) Carpeta resultados, donde est´an almacenados las salidas de los comandos ejecutados para la realizaci´on de las pruebas de rendimiento y las tablas empleadas para su an´alisis y obtenci´on de los gr´aficos. Carpeta scripts donde se encuentran los scripts empleados para automatizar las pruebas realizadas. 85 86 Anexo B Comandos y logs I. Comandos para la modificaci´on de la fuente de datos Generar la primera linea (cabecera) modificada para la primera opci´on. sed -n ’1p’ Watch_gyroscope.csv | sed ’1 s/^/Tipe_Device,Sensor,/’ > opcion1.csv Los siguientes comandos vuelcan el contenido de los 4 archivos de datos origen en el final del archivo cuya cabecera se gener´o con el comando anterior, eliminando la primera l´ınea de cada archivo correspondiente a la cabecera original. sed ’1d’ Watch_gyroscope.csv | sed ’s/^/watch,gyroscope,/’>> opcion1.csv sed ’1d’ Watch_accelerometer.csv | sed ’s/^/watch,accelerometer,/’>> opcion1.csv sed ’1d’ Phones_gyroscope.csv | sed ’s/^/phone,gyroscope,/’>> opcion1.csv sed ’1d’ Phones_accelerometer.csv | sed ’s/^/phone,accelerometer,/’>> opcion1.csv Al generar el nuevo archivo con los nuevos atributos, se incrementa el peso del mismo, de forma que finalizar el proceso, el archivo resultante tiene las siguientes caracter´ısticas: wc -l opcion1.csv 33741501 opcion1.csv du -h opcion1.csv 3,7G opcion1.csv La siguiente secuencia de comandos genera los archivos que se emplear´an para la opci´on 2, en la que los datos se separan en funci´on del tipo del dispositivo: sed -n ’1p’ Watch_gyroscope.csv | sed ’1 s/^/Sensor,/’ > opcion2_watch.csv sed ’1d’ Watch_gyroscope.csv | sed ’s/^/gyroscope,/’>> opcion2_watch.csv sed ’1d’ Watch_accelerometer.csv | sed ’s/^/accelerometer,/’>> opcion2_watch.csv sed -n ’1p’ Phones_gyroscope.csv | sed ’1 s/^/Sensor,/’ > opcion2_phone.csv sed ’1d’ Phones_gyroscope.csv | sed ’s/^/gyroscope,/’>> opcion2_phone.csv sed ’1d’ Phones_accelerometer.csv | sed ’s/^/accelerometer,/’>> opcion2_phone.csv 87 II. Hardware de la m´aquina virtual usuario@virtual:~$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 15 Model: 6 Model name: Common KVM processor Stepping: 1 CPU MHz: 2394.268 BogoMIPS: 4788.53 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 4096K L3 cache: 16384K NUMA node0 CPU(s): 0,1 usuario@virtual:~$ free total used free shared buff/cache available Mem: 8168212 102448 7057104 680 1008660 7777556 Swap: 131068 0 131068 usuario@virtual:~$ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 50G 0 disk vda1 252:1 0 1M 0 part vda2 252:2 0 50G 0 part / 88 III. Comandos para la realizaci´on de las pruebas Para la realizaci´on de las pruebas, se ejecutan los comandos que se indican a continuaci´on, desde la consola de comandos de Linux. Poblar las bases de datos: >>MongoDB mongoimport --db opcion1 --collection phone_watch --type csv --headerline --file /home/datos/opcion1.csv mongoimport --db opcion2 --collection swatch --type csv --headerline --file /home/datos/opcion2_watch.csv >>Cassandra cqlsh -k opcion1 -e "COPY phone_watch (type_device, sensor, indice, arrival_time, creation_time, x, y, z, user, model, device, gt) FROM ’/home/datos/opcion1.csv’ WITH HEADER = TRUE;" cqlsh -k opcion2 -e "COPY watch (sensor, indice, arrival_time, creation_time, x, y, z, user, model, device, gt) FROM ’/home/datos/opcion2_watch.csv’ WITH HEADER = TRUE;" Ejecuci´on de las b´usquedas: >>MongoDB mongo opcion1 --eval ’db.phone_watch.find({"Sensor":"accelerometer","gt":"sit", "User":"a","Model":"lgwatch","x": {$gt: -6.9},"z":{$lt:2.3}}).forEach(printjson)’ mongo opcion2 --eval ’db.swatch.find({"Sensor":"accelerometer","gt":"sit", "User":"a","Model":"lgwatch","x": {$gt: -6.9},"z":{$lt:2.3}}).forEach(printjson)’ >>Cassandra cqlsh localhost -k opcion1 -e "select * from phone_watch where sensor=’accelerometer’ and gt=’sit’ and user=’a’ and model=’lgwatch’ and x >-6.9 and z<2.3 ALLOW FILTERING;" cqlsh localhost -k opcion2 -e "select * from watch where sensor=’accelerometer’ and gt=’sit’ and user=’a’ and model=’lgwatch’ and x >-6.9 and z<2.3 ALLOW FILTERING;" Actualizaci´on de la fila elegida: >>MongoDB mongo opcion1 --eval ’db.phone_watch.updateOne({"Sensor":"accelerometer","gt":"sit", "User":"a","Index":122214}, {$set: {"model":"newwatch"}})’ mongo opcion2 --eval ’db.swatch.updateOne({"Sensor":"accelerometer","gt":"sit", "User":"a","Index":122214}, {$set: {"model":"newwatch"}})’ >>Cassandra cqlsh localhost -k opcion1 -e "UPDATE phone_watch SET model =’newwatch’ where type_device=’watch’ and sensor=’accelerometer’ and gt=’sit’ and user=’a’ and indice =122214;" cqlsh localhost -k opcion2 -e "UPDATE watch SET model =’newwatch’ where sensor=’accelerometer’ and gt=’sit’ and user=’a’ and indice =122214;" Borrado de la base de datos 89