#2 Batalla De Gallos: MongoDB Vs MySQL

#2 Batalla de gallos: MongoDB vs MySQL

Seguimos con una nueva batalla, en este caso MongoDB vs MySQL. Vamos a ver que motor de persistencia es mejor y de entre las características de ambos cual ganará esta batalla de gallos.

Las bases de datos relacionales han sido el pilar de un montón de aplicaciones empresariales durante mucho tiempo y mas desde que se lanzó MySQL en 1995, esta ha sido la opción mas popular.

Ahora, sin embargo con la explosión de la minería de datos y el trabajo con grandes volúmenes de estos ha provocado que tecnologías en el campo de bases de datos no-relaciones hayan aparecido en el juego como requisito para el nuevo tipo de aplicaciones.

Así pues, bases de datos no-relaciones como MongoDB se utiliza para este tipo de aplicaciones, aumentando o reemplazando la infraestructura típica relacional.

¿Qué es MySQL?

MySQL es un Sistema de Gestión de Base de Datos (SGDB) Open-Source basado en entidades y relaciones. Si alguien no sabe que es el Open-Source no es nada mas y nada mas que código abierto, distribuido y desarrollado libremente. Cualquiera puede leer, utilizar y contribuir al código fuente de una aplicación Open-Source.

Pues bien, pese a ser software Open-Source, MySQL es mantenido y distribuido por Oracle pero si te apetece ver el código fuente de MySQL puedes forkearte algún repositorio de todos los que tienen en su cuenta de GitHub y echar un vistazo.

Tal y como hacen otros sistema de gestión de bases de datos, MySQL almacena los datos en tablas y estructuras utilizando un lenguaje específico para relacionarse y comunicarse con esos datos guardados. Este lenguaje se llama SQL (Structured Query Language). Como no es nada nuevo no voy a contar como utilizar SQL  sino que voy a dejar este tutorial de la W3SCHOOLS por si alguien viene de nuevas y si quiere conocer  además en qué se basa SQL, cual es el trasfondo técnico de cómo funciona, te diré que se trata del álgebra relacional, aquí tienes un paper introductorio sobre el cálculo y el álgebra relacional.

En diferentes trabajos (técnicos) que he tenido, he visto utilizar SQL no solo a informáticos sino también a gente de contabilidad y finanzas incluso al personal de marketing así que no es una mala idea que tengas unos mínimos conocimientos por si trabajas de forma directa o indirecta con ordenadores y volúmenes de datos.

En MySQL se definen tanto la estructura de la base de datos como las relaciones entre las diferentes entidades que van a existir según tus requerimientos dentro de un universo concreto de datos.

Si te cuesta visualizar la afirmación anterior o no la entiendes lo vas a ver muy claro con el siguiente ejemplo. Yo no sé si serás usuario de Netflix o no pero te voy a contar como funciona. La cuenta mas avanzada (y cara) del servicio de televisión bajo demanda permite mediante un único registro, un único email y una única cuenta bancaria o cuenta de Paypal ser utilizado hasta por cuatro personas diferentes.

Cuatro personas que van a acceder a la plataforma con sus propios dispositivos y que van a necesitar una cuenta de usuario para poder entrar. Si nos planteamos guardar este conjunto de datos podríamos hacerlo tal que así de una manera muy muy muy simplificada y sin tener en cuenta otras entidades y relaciones.

Relación de ejemplo en una base de datos relacionales como MySQL

Relación de ejemplo en una base de datos relacionales como MySQL

Como vemos aquí, tenemos la tabla de Usuario en la que almacenaremos datos relacionados sobre los usuarios, ¿lógico no? Un identificador que será un número único, el nombre de usuario, su email y su contraseña. Por otro lado tenemos la tabla Dispositivo en la que también tenemos un identificador, el tipo de dispositivo, su modelo y una referencia al usuario al que pertenece.

Tenemos así una relación, una relación 1:N en este caso, me explico.

Supongamos que el Rey de España es un viciado de las series y en un momento dado se hace una cuenta en Netflix. Al poco tiempo su mujer, la Infanta Cristina y Urdangarin se enteran y le solicitan un acceso a Felipe.

El Rey se conecta a la plataforma mediante su Mac Air, su mujer con un iPad, la infanta lo hace mediante su smartphone y Urdangarin desde una Smart TV. Así pues el conjunto de datos quedaría tal que así:

Vemos que el identificador de Usuario en la tabla Dispositivo es de 1 relacionándose así con el identificador de Usuario en la tabla Usuario. Con esto tenemos que la cuenta elRey se conecta a Netflix usando un Mac Air, un iPad, un Android y una LG.

Esto es lo que conocemos como bases de datos relacionales.

Aquí te dejo un curso completísimo sobre SQL de la Universidad de Standford.

¿Qué es MongoDB?

MongoDB es una base de datos Open-Source desarrollada por los chicos de MongoDB… y que se guía bajo el concepto de base de datos no relacionales. A diferencia de las bases de datos relacionales que exigían definir estructuras de datos fijas y estáticas que acababan tomando forma de tabla, en las bases de datos no relacionales los datos se guardan en forma de documentos en los que la estructura puede variar.

Así pues en uno de estos documentos podemos guardar  la información de la cuenta de Netflix del Rey junto a sus 4 dispositivos, pero además también podemos meter un conjunto de series y películas que le gusta a cada uno de los 4 dispositivos diferentes.

Y todo eso en un solo objeto.

Este tipo de almacenamiento junto a su forma de acceder y explotar los datos lo conocemos como NoSQL y es super rápido debido a que no tiene que ir a otras tablas a buscar información adicional para darnos una visión parcial o total de un universo de datos sino que cuando consultamos algo, todo lo referente a eso ya lo tenemos.

MongoDB utiliza esquemas de datos dinámicos, lo que significa que se pueden crear registros sin definir la estructura, tales como los campos o los tipos de datos de sus valores. Se puede cambiar la estructura de los documentos simplemente añadiendo nuevos campos o borrando los que ya tenemos.

Los documentos no necesitan tener un conjunto idéntico de datos y la desnormalización es el pan de cada día de este tipo de bases de datos. MongoDB se diseñó para tener una alta disponibilidad y una gran escalabilidad por lo que su crecimiento horizontal es mas fácil y barato para los sistemas.

Así pues para consultar la información sobre el Rey de España lo haríamos tal que así:

db.Clientes.find({Nombre:"elRey"});

Accedemos a los datos utilizando JSON para hacer las consultas. Aquí tienes el link a la universidad de MongoDB para aprender mas como funciona este tipo de base de datos no relacional.

Terminología y Conceptos

Con esta tabla vas a ver como muchos conceptos de MySQL tiene su analogía con objetos de MongoDB. Estos son los conceptos típicos de cada sistema.

MySQL MongoDB
Tablas Colecciones
Registros Documentos
Columnas Campos
Joins Documentos embebidos o lincados

 

Comparativa de funcionalidades. MongoDB vs MySQL

Al igual que MySQL, MongoDB ofrece un rico conjunto de características y funcionalidades mucho mas allá de los ofrecidos en simples conjuntos de key-value.  Algunas de las cosas que puede hacer son las consultas Ad Hoc, indexar, hacer balanceo de carga o replicarse.

En la siguiente tabla se pueden ver las funcionalidades de MySQL enfrentadas a las de MongoDB.

MySQL MongoDB
Modelos de datos enriquecidos No Si
Esquemas dinámicos No Si
Datos tipados Si Si
Localidad de los datos No Si
Actualización de campos Si Si
Facilidad para los programadores No Si
Transacciones complejas Si No
Administración y auditoría Si Si
Distribución dinámica de datos No Si

 

Lenguaje de consultas

Ambos sistemas tienen un conjunto diferente de estructuras de lenguaje para poder consultar los datos. En la documentación de MongoDB y en la de MySQL encontraras amplia información para manejarte con estas bases de datos pero para muestra un botón (que asco le he tenido siempre a esta expresión)

Consultas típicas de MySQL

Consultas típicas de MongoDB

MongoDB vs MySQL: update queries performance

MongoDB vs MySQL: update queries performance

¿Cuándo utilizar MongoDB en lugar de MySQL?

Empresas de diferente tamaño y número de trabajadores están empezando a utilizar este tipo de bases de datos ya que les permite desarrollar aplicaciones mas rápido, manejar datos de muy diferente tipo y administrar aplicaciones de manera mas eficiente a escala.

Al utilizar bases de datos no relacionales como MongoDB eliminas la capa ORM, sistema de mapeo objeto-relacional, que se encarga de convertir los datos guardados en tablas en objetos dentro del código fuente, en Java los POJOs y en PHP los POPOs.

La estructura flexible de una base de datos no relacional significa que el conjunto y tipo de datos pueden crecer y evolucionar sin que afecte a los requerimientos de la capa de negocio.

También, las bases de datos NoSQL se pueden escalar de una manera relativamente sencilla y sin tiempo de inactividad a través de diferentes centros de datos distribuidos, proporcionando nuevos niveles de disponibilidad y accesibilidad en comparación con las bases de datos relacionales.

¿Cuando es mejor opción utilizar una base de datos relacional?

Aunque la mayoría de las aplicaciones modernas requieren un sistema flexible y escalable como MongoDB, hay casos de uso para el que una base de datos relacional sería mas adecuado.

Las aplicaciones que requieren complejas transacciones de datos como el sistema de un banco, en el fondo utilizan bases de datos relacionales, al igual que se dice sobre el COBOL…

Las bases de datos no relacionales no son un sustituto de las bases de datos relacionales, son un complemento que podemos utilizar para diseñar un sistema de respuesta ágil utilizando además Varnish como sistema avanzado de cache.

Volviendo con el ejemplo del banco, podríamos tener una primera capa que manejara datos a través de NoSQL  y que fuera la encargada de interactuar con el usuario y las distintas APIs y una segunda capa utilizando SQL y que se encargase de almacenar los datos bancarios cuando los usuarios hiciesen transferencias.

Entonces… ¿MySQL y MongoDB se pueden utilizar juntos?

Pues como he contado arriba con el ejemplo del banco, si. Pero existen muchísimos ejemplos de desarrollo híbrido. En la gran mayoría de casos se trata mas de saber cual es la herramienta concreta para tus necesidades.

Por ejemplo, muchas de las herramientas de ecommerce utilizan una mezcla de ambas tecnologías. Mostrar un catálogo dinámico de productos que tienen diferentes atributos es un buen ejemplo para usar la flexibilidad en la estructura y en los datos que nos aportan las bases de datos no relacionales.

Por otro lado, el sistema de pago del ecommerce, es probable que utilice bases de datos relacionales como motor de persistencia debido a las operaciones complejas que pueden darse en la lógica de negocio y debido al sistema de transacciones que nos brinda MySQL.

En otros casos, nuevos requisitos en la lógica de negocio empujan a las organizaciones a adoptar tecnologías basadas en MongoDB de cara a la próxima generación de sus aplicaciones internas.

Así pues, con estos ejemplos, es bastante normal pensar que MongoDB es mejor que MySQL debido a su modelo de datos flexible y su arquitectura escalable pero todo es cuestión de valorar las mejores herramientas que se adapten a tus requisitos y no adaptar una solución tan solo porque esta de moda.

 

Y con esto se acabó la segunda batalla de gallos de tecnologías. Deja un comentario o ponme un tweet a través del siguiente banner con las tecnologías que quieres que enfrente en la próxima batalla 😉

@gorkakatua #faqsGorkamu pregúntame por twitter cualquier cosa y vemos cómo lo solucionamos.

Hala a mamarla!

¿Te ha parecido este un artículo de 5 estrellas? Dame tu valoración:
Review Date
Reviewed Item
#2 Batalla de gallos: MongoDB vs MySQL
Author Rating
51star1star1star1star1star

Gorka Muñoz Andrés

Me llamo Gorka Muñoz y soy un desarrollador melómano. Combino a la perfección la búsqueda de nuevos grupos con la pasión por la tecnología. Desde chiquitito me ha gustado la programación, ahora que soy mayor estoy metido en el mundo del SEO sin olvidarme del /Dev.

Deja un comentario

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