" />
ZOOM
GALERÍA
1 COMENTARIO

Te explicamos cómo funcionan las bases de datos utilizadas en Big Data y otras aplicaciones

MongoDB, ¿son las bases de datos no relacionales el futuro?

Si hay algo que ha permanecido prácticamente inmutable en tecnología, eso son las bases de datos. El modelo relacional, con más de 40 años a sus espaldas, sigue vigente en nuestros días y es la base de la mayoría de aplicaciones que acceden a una base de datos.

Sin embargo, no es el único modelo existente, ni el único en uso. En los últimos tiempos han cobrado importancia las bases de datos que no cumplen con los principios expresados por Codd en 1970.

Se trata de las bases de datos no relacionales, también conocidas como NoSQL, por no utilizar el lenguaje SQL casi universal en las bases de datos convencionales. ¿Se trata de una moda? ¿Están muertas las bases de datos relacionales? En este reportaje te explicamos en qué consisten esas bases de datos y qué ventajas te pueden aportar.

¿Recuerdas cómo funciona una base de datos?

Las bases de datos relacionales organizan la información en tablas. Cada tabla tiene un número de columnas o campos, determinados por el administrador, y filas que contienen los datos.

Una tabla de una base de datos relacional tiene una estructura semejante a la de una hoja de cálculoUna tabla de una base de datos relacional tiene una estructura semejante a la de una hoja de cálculo

Además, estas tablas pueden relacionarse entre sí, de manera que mediante consultas que combinan varias tablas (denominadas JOIN), se puede obtener información de varias de ellas. Estas relaciones pueden ser de un elemento de una tabla a un elemento de otra, de uno a varios o de varios a varios.

El modelo relacional

El modelo relacionalPara mantener la integridad entre las distintas tablas que componen la base de datos se utilizan las relaciones.

En este ejemplo, la tabla Empleados mantiene una relación con las tablas Nóminas y Vacaciones. La integridad referencial impide que se den de alta nóminas o periodos vacacionales de empleados inexistentes.

Esto, unido a un lenguaje que permite obtener la información de forma sencilla, así como interactuar con ella dando de alta nuevos registros, modificando los ya existentes, etc., hace del modelo relacional perfecto para la mayoría de aplicaciones por varios motivos.

El primero es que organiza la información de forma muy clara: cada fila (tupla) de la tabla Empleados contendrá la información de un empleado, mientras que la tabla Nóminas contendrá una nómina.

Además, estas bases de datos están diseñadas para mantener la integridad de las relaciones: no puede haber una nómina para un empleado inexistente, así como parece lógico pensar que en la tabla Nóminas no se permitirá que haya varias filas con el mismo código de empleado para el mismo mes.

Pero no todo son ventajas

Este modelo parece perfecto, o casi. Permite crear desde bases de datos muy sencillas hasta las más complejas, garantiza la integridad de los datos y dispone de un lenguaje sencillo y que casi cualquier programador conoce bien.

El principal problema de este modelo es que todo esto es costoso en términos de rendimiento. No es que las bases de datos relacionales sean terriblemente lentas pero cada operación tiene un coste de tiempo elevado, precisamente, por todas esas garantías sobre los datos y las transacciones.

Además, las estructuras que se crean están diseñadas para modificarse poco. Si necesitamos añadir un nuevo dato a algunos de nuestros empleados, la tabla Empleado necesitará una nueva columna. Todos los empleados existentes tendrán ese nuevo campo, lo necesiten o no. Esto puede hacer que una base de datos cuya estructura necesite ser modificada periódicamente crezca a lo ancho, aumentando la necesidad de almacenamiento y los tiempos de proceso.

La aproximación no relacional

Supongamos que prescindimos de una estructura tan bien pensada. Renunciamos a unas tablas perfectamente definidas, que garantizan la integridad y en las que todo parece ser perfectamente predecible. A cambio, obtenemos rapidez y flexibilidad.

Desde el punto de vista de nuestra base de datos de empleados y nóminas parece que lo que ganamos en velocidad no compensa. Una aplicación para gestionar este tipo de información, incluso en una compañía con muchos empleados, no suele tener tanta interacción con la base de datos como para que la velocidad llegue a suponer un problema si tanto la aplicación como la base de datos están bien diseñadas.

Además, en el caso de los empleados es muy útil que la integridad de los datos esté garantizada. De este modo evitamos que se emitan nóminas a un empleado que ha dejado la compañía, o que alguien cobre varias veces.

Donde empieza a resultar interesante utilizar bases de datos NoSQL es en casos en los que la cantidad de información es muy grande. Aplicaciones científicas, las transacciones de un gran banco o incluso sistemas de analítica web en tiempo real. En estos casos, la cantidad de información es tanta que las aproximaciones mediante bases de datos relacionales obligan a dedicar muchos esfuerzos a la optimización para obtener un resultado aceptable.

¿Cómo se diseña un modelo no relacional?

Las bases de datos basadas en SQL son parte de las habilidades básicas de la mayoría de programadores. Incluso los especializados en áreas bien alejadas de las aplicaciones de gestión conocen los principios básicos y son capaces de utilizar el lenguaje SQL en caso de necesidad.

Esto hace que la forma de diseñar estas bases de datos pueda resultar un impedimento: las bases no relacionales exigen pensar de otra forma desde el principio.

Por ejemplo en MongoDB (la base de datos más utilizada), nuestras tablas Empleados y Vacaciones, podrían quedar así:

Shell de MongoDB mostrando la entrada de un empleado, la lista de periodos de vacaciones está embebida en esta.Shell de MongoDB mostrando la entrada de un empleado, la lista de periodos de vacaciones está embebida en esta.

Esto tiene algunas consecuencias. La primera es que toda la información relacionada está almacenada en el mismo sitio. A la hora de acceder a los datos de un empleado podremos leer toda la información, vacaciones incluidas, en una sola operación de forma muy rápida. Fíjate también que aquellos campos que no tenían información en el modelo relacional aquí, simplemente, no existen. No ocupan espacio en disco y no consumen memoria al hacer una consulta, algo que facilita que el tiempo necesario para las consultas se reduzca.

La consecuencia indeseada puede llegar cuando hacemos lo mismo con las nóminas. Si el administrador de la empresa quiera obtener un listado con todas las nóminas del mes de junio. En ese caso, habrá que recorrer uno por uno los empleados en busca de las nóminas adecuadas. Dado que, en este caso, puede ser incómodo utilizar un único documento, MongoDB proporciona también referencias a otros documentos. El de las nóminas podría ser una buena aplicación de esta característica pero… ¡los más puristas te dirán que aquí también puedes evitar usarla!

El lenguaje de MongoDB

Recuperar información de la base de datos es muy diferente en este modelo respecto a las bases de datos relacionales y el lenguaje SQL.

Consulta en SQL

SELECT * FROM EMPLEADOS,NOMINAS,VACACIONES

WHERE EMPLEADOS.ID_EMPLEADO = NOMINAS.ID_EMPLEADO

AND EMPLEADOS.ID_EMPLEADO = VACACIONES.ID_EMPLEADO

AND EMPLEADOS.APELLIDOS = "FERNÁNDEZ GARCÍA"

Consulta en MongoDB

db.empleados.find( { apellidos: 'FERNÁNDEZ GARCÍA' } )

En el primer ejemplo, hemos seleccionado toda la información de las tres tablas, para lo que hemos tenido que indicar las relaciones (JOIN) entre ellas, así como especificar una condición sobre la columna por el que queremos filtrar la consulta.

En el segundo caso, sólo tenemos que especificar la condición por la que queremos buscar. La información relativa a las vacaciones está en el mismo documento y la que hemos llevado a otro, las nóminas, son accesibles desde los resultados de forma automática.

Supongamos ahora que necesitamos añadir las vacaciones de un empleado. En la base relacional deberemos de dar de alta una entrada en la tabla Vacaciones, mientras que en MongoDB bastará con actualizar la entrada del empleado en cuestión:

Inserción en SQL

INSERT INTO VACACIONES (ID_EMPLEADO, FECHA_INICIO, FECHA_FIN)
SELECT ID_EMPLEADOS, '20/07/2014' AS FECHA_INICIO, '31/07/2014' AS FECHA_FIN
FROM EMPLEADOS WHERE APELLIDOS = "FERNÁNDEZ GARCÍA",

Actualización en MongoDB

db.empleados.update(
{ apellidos: "FERNÁNDEZ GARCÍA" },
{ $push: { vacaciones: { "fecha_inicio": "20/07/2014", "fecha_fin": "31/07/2014" } } }
)

 

En el primer caso, es necesario hacer una consulta para localizar el identificador del empleado por sus apellidos, para insertar una nueva fila en la tabla Vacaciones. Para hacer todo en una sola operación utilizamos un pequeño truco, introducir como cadenas los valores que no salen de la tabla de empleados.

En MongoDB se utilizan dos parámetros, el primero para especificar la condición de búsqueda y el segundo para indicar los cambios a realizar en el empleado. La orden $push indica que se debe incorporar la información a un array.

Como ves, la forma de interactuar con la base de datos es más sencilla que en SQL, un lenguaje cuyas primeras versiones son de 1974 y que está basado en comandos de texto. El modelo de MongoDB utiliza sintaxis propia de la programación orientada a objetos (el lenguaje usado es JavaScript) y dispone de librerías para trabajar con la base de datos en los lenguajes más utilizados.

Por supuesto, hay capas de abstracción que permiten trabajar con bases de datos relacionales de forma más intuitiva que las viejas, pero potentes, instrucciones SQL. Aún así no se mejora el rendimiento (es posible que incluso salga penalizado) y hay que desarrollar más código para poder utilizarlas.

Tipos de bases no relacionales

Aunque MongoDB es la más conocida, no es la única base de datos no relacional que existe. De hecho, hay muchos tipos de base de datos no relacionales. Existen bases de datos documentales, en grafo, clave/valor, multivalor… cada una de ellas tiene su punto fuerte y algunas encajan en varias de estas definiciones.

MongoDB, la más popular, se considera tanto una base de datos documental como clave/valor, ya que está basada en documentos y los datos se almacenan como pares de claves con un valor asignado. Una ventaja de la diversidad de opciones existente es que se pueden combinar varios sistemas de bases de datos, incluyendo las relacionales, aprovechando los puntos fuertes de cada uno en los puntos en los que es necesario.

Además, en muchas ocasiones se combinan estas arquitecturas complicadas con los sistemas de bases de datos en memoria. Se trata de bases de datos que no almacenan información en disco, de modo que son muy rápidas aunque, por supuesto, es muy costoso y tiene grandes limitaciones.

Un ejemplo de este tipo de arquitecturas es Twitter, que incluso ha aportado sus propios desarrollos sobre el modelo y combina varios de estos modelos para optimizar el acceso de millones de usuarios a los millones de tweets que se publican cada día, búsquedas, calculo de los trending topics en tiempo real, etc.

Entrevista con Luis Mesas, ingeniero de Intelygenz

Luis Mesas, Intelygenz

Luis Mesas, Innovation Architect en IntellygenzLuis Mesas es ingeniero en Intelygenz y trabaja como Innovation Architect.

Está involucrado en diversos proyectos en los que el uso de las bases de datos no relacionales es clave para ofrecer una ventaja competitiva a sus clientes.

TNL: ¿Cuáles son las diferencias entre una base de datos relacional y otra no relacional como MongoDB?
La diferencia principal es cómo almacena la información cada una de ellas. Una base de datos relacional es como una hoja de Excel. Tienes unas columnas definidas y todos los objetos que crean tienen todos los datos de esas columnas.

En una no relacional el objeto es polimórfico, puede tener los atributos que quieras para cada objeto. La ventaja principal la encuentras cuando trabajas con sistemas masivos.

En una base de datos relacional, si tuvieses miles de millones de registros y añades un campo nuevo ese campo se añade a todos los registros ya existentes. En una polimórfica no, sólo se añaden los datos al objeto concreto.

TNL: Eso implica que el programador tiene que llevarse parte de la lógica a una capa superior.
Bastante de ella sí. Cuando haces una búsqueda en una base de datos, relacional o no, la haces contra un índice. Tienes un índice en memoria que relaciona, por ejemplo, los nombres de usuario con la posición en disco duro de cada objeto. A nivel de búsqueda es muy parecido en ambos casos.

Pero en una no relacional tú puedes tener arrays de datos. Por ejemplo, si tienes más de una dirección postal, en una base de datos relacional tendrías una tabla de usuarios y otra de direcciones postales. Cuando haces una búsqueda tienes que hacer un montón de consultas en paralelo. Primero buscas los usuarios y luego las direcciones que les corresponden en otra tabla.

En una base como MongoDB tú le pides el usuario y te devuelve directamente al usuario con todas sus direcciones. Como el dato está próximo en el disco, lo puedes leer entero en mucho menos tiempo. Los discos están optimizados para hacer lecturas secuenciales y pierden tiempo para hacer saltos.

TNL: Al almacenarse toda la información junta, ¿desaparecen los JOINs propios de SQL?
Efectivamente. Las versiones nuevas empiezan a tener algunas referencias entre objetos para convencer a las personas que han usado muchos años bases de datos relacionales. Pero no es la función principal de estas bases de datos.

Tienes que hacer menos consultas y los datos están más próximos, así que tienes una mejora de eficiencia porque sacas la información del disco mucho más rápido. Para una aplicación pequeña como un blog da igual qué tipo de base de datos utilizas. Cuando la base de datos es muy grande empieza a tener más sentido irse a bases de datos no relacionales.

TNL: Es decir, ¿son bases ideales para hacer desarrollos sobre big data, científicas o estadísticas?
Hay bases de datos tipo HDFS que optimizan todo en disco duro y te permiten leer y escribir en paralelo sobre la misma colección. Normalmente de una colección de datos cuando estás escribiendo no puedes hacer otras escrituras, aunque sí puedes leer en paralelo.

TNL: Otro de los sistemas que las bases relacionales utilizan son las transacciones. ¿Cómo se gestionan en MongoDB?
No hay transaccionalidad, aunque en versiones futuras quieren meterlo. Lo delegan en el desarrollador, que tiene que implementarla mediante una máquina de estados u otros sistemas.

TNL: ¿Esto no supone una limitación para algunas aplicaciones?
Hay aplicaciones en las que la transaccionalidad es importante porque la información está distribuida en varias tablas, de modo que hasta que no se termina de escribir en todas ellas no finaliza la transacción. En una no relacional el modelo de cada objeto puede variar y si tienes toda la información en el mismo objeto, por ejemplo, una cuenta bancaria que contenga todas las operaciones y el saldo. Es un caso crítico, estás jugando con el dinero de la gente.

En una relacional tienes una tabla con un contrato, otra de movimientos, y el saldo lo puedes tener en la primera. Escribes el movimiento en su tabla y luego modificas el saldo en el contrato. Todo eso lo haces en una transacción.

En una no relacional no necesitas la transacción: tienes el objeto completo con los movimientos y el saldo, los actualizas en memoria y lo escribes en el disco en una sola operación. Puedes diseñar un modelo de datos que no te exija transaccionalidad.

TNL: ¿En qué tipo de proyectos son una ventaja estas bases de datos?
La principal ventaja es agilidad de desarrollo. En tu aplicación tienes objetos que son estructuras de datos y métodos que operan sobre ellos. En una relacional, tienes un método que busca en la base de datos y rellena la información desde muchas tablas. Tienes que hacerlo tú, tienes que programar la clase para incluir esas relaciones.

En una no relacional el modelo de datos está emparejado al modelo de objetos. Cuando cargas un objeto viene todo entero. Lo almacenas en las propiedades internas del objeto y ya lo tienes. Es más fácil a la hora de programar y es más robusto porque es más difícil cometer errores.

Te quitas la parte de datos, que es la parte más aburrida de la programación, y te puedes dedicar sólo a la funcionalidad de tu aplicación. El programador tiene la sensación de que su trabajo está más aprovechado.

el modelo de datos está emparejado al modelo de objetos, Cuando cargas un objeto viene todo entero

TNL: Se trata de un lenguaje muy simple, con principios de la programación orientada a objetos, ¿recomendarías a un empezar a aprender bases de datos con MongoDB?
Hay varios perfiles de personas que empiezan a programar. Uno muy típico es la persona que quiere aprender a hacer páginas web y luego se engancha y se quiere dedicar a eso. Normalmente quien aprende a hacer páginas web aprende HTML, CSS y Javascript. MongoDB y algunas otras utilizan JavaScript. No tienen que aprender un lenguaje nuevo, sólo objetos y métodos nuevos para acceder a la información. Es más natural para ese perfil.

TNL: ¿Y para los que hemos aprendido por el otro camino?
Lo bueno es que se simplifica tu modelo de datos. En una aplicación pequeña acabas teniendo 7 u 8 tablas. En una no relacional la reducción es máxima. Tiendes a acumular toda la información que sueles tener dispersa.

La primera dirección de acumulación son los arrays de información. Cuando tienes más de un objeto y quieres permitir que sean infinitos normalmente te creas una tabla nueva y una relación. Por ejemplo, una lista de emails o direcciones relacionadas con un usuario. En una base de datos no relacional tienes ya el objeto usuario con el listado de direcciones y de emails. Si quieres añadir o eliminar lo haces sobre el mismo objeto.

TNL: Venías de desarrollar bases de datos convencionales, ¿cuesta mucho cambiar la forma de pensar?
Cuesta bastantes iteraciones de pensamiento y leer mucho. Llevamos muchos años utilizando las bases de datos relacionales, en las universidades estamos muy acostumbrados a utilizar Excel, una representación directa de una base de datos relacional. Es muy natural pensar de esta manera, nuestra vida está muy adaptada a ella: una carta con los movimientos bancarios son una tabla. Estamos entrenados para pensar de modo relacional.

Como las no relacionales son polimórficas no hay elementos que en el mundo real te lo evoque. Es difícil explicar a la gente ese cambio. Los que llevan muchos años en el mundo relacional tienen que enfrentarse al miedo al cambio, un programador tiene unos plazos y al no conocerlo no se arriesgan. Siempre estás buscando el proyecto en el que puedas empezar.

Tienes una estimación y tienes que cumplirla y si tienes mucha experiencia con la relacional ya sabes qué esperar. Hasta que no empiezas a arriesgar usando la no relacional no conoces el ahorro de tiempo. En diseño se ahorra mucho tiempo porque el modelo de datos es más simple. En el desarrollo también se ahorra tiempo, porque la capa de datos es más sencilla.

Los que llevan muchos años en el mundo relacional tienen que enfrentarse al miedo al cambio

TNL: Un caso de éxito, quizá el más conocido, es el de Twitter.
A lo que más ha contribuido es al proceso de big data en tiempo real con Twitter Storm. También utilizan Hadoop para ofrecer la información de millones de tweets en tiempo real.

TNL: ¿Y cuál es la reacción de las grandes compañías de bases de datos a este fenómeno?

Están adquiriendo compañías [más pequeñas] de bases de datos no relacionales para aguantar el tirón. También hacen pequeñas modificaciones en sus bases relacionales y están desarrollando productos no relacionales para poder ofrecer ambos catálogos a sus clientes. Personalmente creo que los grandes actores de las relacionales juegan con ventaja. Los que han reconocido que hay que adaptarse van a mejorar su catálogo. Y pueden recomendar la más base de datos más apropiada para cada caso.

El problema de compañías como Mongo es que están convencidas de que el modelo relacional está muerto y no van a desarrollarlo. El catálogo [de las grandes compañías] es más completo.

TNL: ¿Utilizáis otras bases de datos, además de las relacionales y de MongoDB?
Utilizamos bases clave-valor como Redis o Memcache. Tienes toda la información en memoria, con lo cual es muy rápida. Se utiliza sobre todo como caché de información, pides el dato y lo guardas en esta base de datos para acelerar el acceso a determinados datos. Delegas la base de datos, relacional o no, a una mera persistencia en el tiempo.

Si tengo que regenerar mi sistema porque se ha caído, obtienes la información de otra base de datos y reconstruyes la memoria. Pero si tienes una consulta que se repite de forma desproporcionada al resto, la añades a esa base de datos clave/valor y el acceso resulta muchísimo más rápido.

Probar MongoDB

¿Te interesan las bases de datos no relacionales? Puedes probar MongoDB en su propia web, mediante una demo/tutorial. Además, pronto publicaremos un tutorial en el que te enseñamos a crear una base de datos MongoDB y acceder a ella desde tu web.

 

 

One Response to MongoDB, ¿son las bases de datos no relacionales el futuro?

  1. alejandro 26 agosto, 2017 at 0:47 #

    soy demografo de Argentina. me interesaría conversar sobre el uso de este tipo de bases para el manejo de datos censales. los censos, como casi todas las operaciones estadísticas vienen usando bases relacionales. por lo que estuve leyendo de Mongo, por ejemplo, que es poco hasta ahora, me parece interesante la opción que presentan. lo que me interesaría conocer es, cuáles son los procesos que se realizan para obtener resultados del censo en formatos que se usan habitualmente, distribuciones de frecuencias, tabulados, indicadores, etc.
    me pueden orientar?
    gracias!

Deja un comentario