You are on page 1of 6

MongoDB, son las bases

de datos no relacionales el
futuro?
9 junio, 2014 Tecnologa 9

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


Si hay algo que ha permanecido prcticamente inmutable en tecnologa, eso
son las bases de datos. El modelo relacional, con ms de 40 aos a sus
espaldas, sigue vigente en nuestros das y es la base de la mayora 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, tambin conocidas como
NoSQL, por no utilizar el lenguaje SQL casi universal en las bases de datos
convencionales. Se trata de una moda? Estn 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 CMO FUNCIONA UNA BASE DE DATOS?

Las bases de datos relacionales organizan la informacin en tablas. Cada


tabla tiene un nmero 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 clculo

Adems, estas tablas pueden relacionarse entre s, de manera que mediante


consultas que combinan varias tablas (denominadas JOIN), se puede
obtener informacin 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 informacin 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 mayora de
aplicaciones por varios motivos.
El primero es que organiza la informacin de forma muy clara: cada fila (tupla)
de la tabla Empleados contendr la informacin de un empleado, mientras que
la tabla Nminas contendr una nmina.
Adems, estas bases de datos estn diseadas para mantener la integridad de
las relaciones: no puede haber una nmina para un empleado inexistente, as
como parece lgico pensar que en la tabla Nminas no se permitir que haya
varias filas con el mismo cdigo 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 ms 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
trminos de rendimiento. No es que las bases de datos relacionales sean
terriblemente lentas pero cada operacin tiene un coste de tiempo elevado,
precisamente, por todas esas garantas sobre los datos y las transacciones.
Adems, las estructuras que se crean estn diseadas para modificarse poco.
Si necesitamos aadir un nuevo dato a algunos de nuestros empleados, la
tabla Empleado necesitar una nueva columna. Todos los empleados
existentes tendrn ese nuevo campo, lo necesiten o no. Esto puede hacer que
una base de datos cuya estructura necesite ser modificada peridicamente
crezca a lo ancho, aumentando la necesidad de almacenamiento y los tiempos
de proceso.
LA APROXIMACIN 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 nminas
parece que lo que ganamos en velocidad no compensa. Una aplicacin para
gestionar este tipo de informacin, incluso en una compaa con muchos
empleados, no suele tener tanta interaccin con la base de datos como para

que la velocidad llegue a suponer un problema si tanto la aplicacin como la


base de datos estn bien diseadas.
Adems, en el caso de los empleados es muy til que la integridad de los datos
est garantizada. De este modo evitamos que se emitan nminas a un
empleado que ha dejado la compaa, 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 informacin es muy grande. Aplicaciones
cientficas, las transacciones de un gran banco o incluso sistemas de analtica
web en tiempo real. En estos casos, la cantidad de informacin es tanta que
las aproximaciones mediante bases de datos relacionales obligan a
dedicar muchos esfuerzos a la optimizacin para obtener un resultado
aceptable.
CMO SE DISEA UN MODELO NO RELACIONAL?

Las bases de datos basadas en SQL son parte de las habilidades bsicas de la
mayora de programadores. Incluso los especializados en reas bien alejadas
de las aplicaciones de gestin conocen los principios bsicos y son capaces de
utilizar el lenguaje SQL en caso de necesidad.
Esto hace que la forma de disear 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 ms utilizada), nuestras tablas
Empleados y Vacaciones, podran quedar as:

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 informacin
relacionada est almacenada en el mismo sitio. A la hora de acceder a los
datos de un empleado podremos leer toda la informacin, vacaciones incluidas,
en una sola operacin de forma muy rpida. Fjate tambin que aquellos
campos que no tenan informacin 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
nminas. Si el administrador de la empresa quiera obtener un listado con todas
las nminas del mes de junio. En ese caso, habr que recorrer uno por uno los
empleados en busca de las nminas adecuadas. Dado que, en este caso,
puede ser incmodo utilizar un nico documento, MongoDB proporciona
tambin referencias a otros documentos. El de las nminas podra ser una
buena aplicacin de esta caracterstica pero los ms puristas te dirn que
aqu tambin puedes evitar usarla!
EL LENGUAJE DE MONGODB

Recuperar informacin 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*FROMEMPLEADOS,NOMINAS,VACACIONES
WHEREEMPLEADOS.ID_EMPLEADO=NOMINAS.ID_EMPLEADO
ANDEMPLEADOS.ID_EMPLEADO=VACACIONES.ID_EMPLEADO
ANDEMPLEADOS.APELLIDOS="FERNNDEZGARCA"

Consulta en MongoDB
db.empleados.find({apellidos:'FERNNDEZGARCA'})

En el primer ejemplo, hemos seleccionado toda la informacin de las tres


tablas, para lo que hemos tenido que indicar las relaciones (JOIN) entre
ellas, as como especificar una condicin sobre la columna por el que
queremos filtrar la consulta.
En el segundo caso, slo tenemos que especificar la condicin por la que
queremos buscar. La informacin relativa a las vacaciones est en el
mismo documento y la que hemos llevado a otro, las nminas, son accesibles
desde los resultados de forma automtica.
Supongamos ahora que necesitamos aadir 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 cuestin:
Insercin en SQL
INSERTINTOVACACIONES(ID_EMPLEADO,FECHA_INICIO,FECHA_FIN)
SELECTID_EMPLEADOS,'20/07/2014'ASFECHA_INICIO,'31/07/2014'AS
FECHA_FIN
FROMEMPLEADOSWHEREAPELLIDOS="FERNNDEZGARCA",

Actualizacin en MongoDB
db.empleados.update(
{apellidos:"FERNNDEZGARCA"},
{$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 operacin utilizamos un
pequeo truco, introducir como cadenas los valores que no salen de la tabla de
empleados.
En MongoDB se utilizan dos parmetros, el primero para especificar la
condicin de bsqueda y el segundo para indicar los cambios a realizar
en el empleado. La orden $push indica que se debe incorporar la informacin a
un array.
Como ves, la forma de interactuar con la base de datos es ms 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 programacin orientada a objetos (el lenguaje usado es
JavaScript) y dispone de libreras para trabajar con la base de datos en
los lenguajes ms utilizados.
Por supuesto, hay capas de abstraccin que permiten trabajar con bases de
datos relacionales de forma ms intuitiva que las viejas, pero potentes,
instrucciones SQL. An as no se mejora el rendimiento (es posible que incluso
salga penalizado) y hay que desarrollar ms cdigo para poder utilizarlas.
TIPOS DE BASES NO RELACIONALES

Aunque MongoDB es la ms 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 ms 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.
Adems, 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 informacin en disco, de modo que son muy
rpidas 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 da, bsquedas, calculo de los trending topics en tiempo real,
etc.

You might also like