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.

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.

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í:

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.

Probar MongoDB

¿Te interesan las bases de datos no relacionales? Puedes probar MongoDB en su propia web..

Fuente: Tek’n’life