SQL vs NoSQL desde la perspectiva de MongoDB

Continuamente participamos y leemos preguntas en diversos grupos de Facebook sobre programación. Hace poco nos dábamos cuenta que varias de ellas son respecto a NoSQL y hemos podido observar que muchas de esas preguntas son como estas: “¿debería utilizar MySQL o MongoDB para mi nuevo proyecto?”, “¿Qué es NoSQL?” y “¿Cuándo debería usar NoSQL?”

El cada vez más completo (y complejo) perfil de los desarrolladores nos obliga y motiva a aprender nuevas tecnologías. El error que en muchas veces hemos caído ha sido intentar aplicar una nueva tecnología recién aprendida a un determinado proyecto. Como prueba de concepto esto resulta excelente, pero cuando nos referimos a una aplicación puesta en marcha nuestro error es no analizar el verdadero problema de la aplicación que podríamos resolver con la nueva tecnología.

No son extraños los casos en los que se ve un forzado intento por utilizar una tecnología que no es la adecuada para un determinado escenario. Debemos analizar previamente el dominio del problema.

En esta ocasión no nos explayaremos hablando sobre NoSQL y sus distintos modelos actualmente utilizados como son Document Store, Key-Value, Wide-Columns, Graph y Multi purpose. Vamos a presentar una breve comparativa entre un motor de base de datos relacional (SQL) y un NoSQL.

SQL

En un motor SQL tenemos una base de datos en la cual encontraremos múltiples tablas, con múltiples columnas y valores en estas. En una tabla cada columna tiene un nombre y tipo de dato.

Lo normal es encontrar estas tablas normalizadas bajo diversos criterios para obtener modelos relacionales. El modelo relacional fue introducido por Edgar Codd en 1970 y desde entonces ha mostrado ser un modelo bastante robusto… sin embargo para las nuevas aplicaciones con millones de usuarios activos y que generan millones de registros este modelo empieza a mostrar limitaciones. Aunque esta pueda ser una explicación bastante breve sobre SQL la idea que nos debe quedar en mente es que desde 1970 a la fecha de hoy el hardware y software han experimentado grandes cambios, así también lo debe hacer el almacenamiento de datos.
table

MongoDB

MongoDB es una base de datos NoSQL de tipo Document Store. Es aquí donde quiero hacer una pequeña ilustración. Imaginemos que tenemos la necesidad inicial de almacenar 100 gramos de azúcar. Para esta pequeña cantidad un azucarero es una buena solución. ¿Qué pasaría si luego tuviéramos 2 kilos? Sin duda deberíamos buscar un envase más grande. Para estos tamaños todavía nos resultaría sencillo guardar y obtener el azúcar. ¿Pero cuándo sea 1 tonelada? Surgirían problemas de almacenamiento, la forma de obtenerla sería más complicada y también surgiría el tema de seguridad. Cambiando el problema, si ya no fuera azúcar sino gasolina nos encontraríamos con una situación totalmente distinta.

azucar

El anterior escenario hipotético nos hace considerar múltiples aspectos que se deben analizar para tomar decisiones. Es igual para elegir una base de datos. Si bien los datos pueden ser texto, números, fechas, datos binarios, etc. su forma de ser almacenados y recuperados es lo que nos debe preocupar a la hora de realizar el análisis de nuestra aplicación.

MongoDB almacena datos en una estructura llamada documento. Estos documentos son muy similares a los objetos JSON; sin embargo, para un almacenamiento óptimo y seguro se utiliza el formato BSON.

Estos documentos forman colecciones y son sobre estas colecciones que se realizan las búsquedas. Al ser un modelo NoSQL no existen los JOINS por lo que el reto está en como almacenar la información eficientemente para leerla posteriormente. Debido a la falta de JOINS debemos crear un documento que contenga la data de manera embebida para no requerir consultas extras.

Veamos un ejemplo típico desde la perspectiva de SQL y NoSQL.

Modelamiento de Libro-Autor-Editorial

tablesss

En la imagen observamos que un libro puede tener varios autores y un autor varios libros. Un libro puede estar publicado por diversas editoriales y una editorial publica varios libros. En un modelo relacional SQL debemos romper las relaciones de muchos a muchos. Con esto terminamos con un modelo como el siguiente:

tablas relacion

Con este modelo relacional si deseáramos obtener los datos para un libro (editorial y autores) titulado “Crónicas Marcianas” tendríamos que escribir una consulta como la siguiente:

select L.nombre, L.fecha, L.isbn, E.nombre as Editorial, A.nombres as Autor
from Libro L join Editorial_Libro EL on L.libroID = EL.libroID
join Editorial E on E.editorialID = EL.editorialID
join Autor_Libro AL on L.libroID = AL.libroID
join Autor A on A.autorID = AL.autorID
where L.nombre like ‘Crónicas Marcianas’

¡Y todo esto para las 3 tablas iniciales!

OK. Es turno de MongoDB. En MongoDB los documentos no tienen una estructura definida, por eso se habla de schemaless. Veamos como crearíamos nuestro documento en MongoDB para almacenar el libro Crónicas Marcianas de Ray Bradbury.

mongo document

Como podemos observar la información del autor y las editoriales se encuentran embebidas en el documento; sin embargo, tanto autor como editorial podrían tener más campos, es por ello que estos subdocumentos tienen el valor de sus llaves para poder ser ubicados.

La consulta para poder obtener el documento sería la siguiente:

libros.find({“nombre”: “Crónicas Marcianas”})

¡Así de simple!

Hemos podido dar un primer vistazo a algunas de las ventajas que nos ofrece el modelo NoSQL Document Store; sin embargo, son otros los retos que nos trae. En el ejemplo mencionado se tienen las colecciones autor y editorial, cuando sus valores cambien también deberán hacerlo en la colección de libros.

Pronto estaremos lanzado el curso de MongoDB, pueden enterarse de nuestros últimos cursos en http://templotec.com/#cursos también pueden escribirnos a informes@templotec.com

Happy Coding!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *