MySQL vs MongoDB ¿Cuándo y dónde usar cada uno?

Una de las interrogantes más comunes a la hora de definir un nuevo proyecto, tanto para el equipo de desarrollo como para el equipo de planificación y gestión de un nuevo software, app, web, etc., es, por supuesto, ¿qué tipo de base de datos debemos usar? Seamos honestos, a priori todos llegan a un consenso no verbal y comienzan a definir un modelo entidad relación para construir una base de datos relacional en MySQL el 99% de las veces, la pregunta entonces es ¿Qué se está dejando a un lado? y es que, en definitiva, las ventajas de una base de datos no relacional pueden traernos bastantes beneficios según la naturaleza de nuestro proyecto.

Comparemos estructuras

Tomando esto en cuenta y antes de hacer una comparativa específica entre MongoDB y MySQL, resaltemos las diferencias entre una base de datos relacional y una base de datos no relacional tomando en cuenta algunos aspectos fundamentales a considerarse para el desarrollo, crecimiento y sustantividad de una aplicación.

Primero que nada, hablemos del lenguaje la mayoría de los desarrolladores y administradores de bases de datos prefieren usar SQL por ser un lenguaje de consultas estándar, soportado por múltiples manejadores de bases de datos y porque trabaja con una estructura definida y robusta, asegurando la integridad de los datos. Esto sin mencionar que SQL proporciona la posibilidad de realizar consultas anidadas y complejas entre tablas o entidades.

Sin embargo, la fortaleza de SQL resulta ser su punto débil, esta estricta norma de definir estructuras de datos es lo que pone la principal limitante al lenguaje de consultas y al trabajo con SQL, y es una de las principales razones por las que nace el NoSQL. El atractivo “comercial” de las bases de datos no relacionales es, como ya habrán adivinado, su flexibilidad a la hora de definir esquemas de datos, esta flexibilidad permite, entre otras cosas:

  • Insertar documentos (registros) sin una estructura rígida
  • Cambiar la naturaleza de los registros, pueden ser pares de llave-valor, estructuras basadas en grafos, documentos o columnas
  • Dinamismo a la hora de consultar, pudiendo agregar/quitar propiedades de una entidad a medida que se van agregando registros nuevos

¿Suena bastante bien no? Sin embargo, esta flexibilidad también puede traernos problemas, por ejemplo, al migrar de un motor NoSQL a otro, pues no comparten un lenguaje de consultas estándar.

Otro factor a considerar hoy en día es la escalabilidad, por lo general, las bases de datos SQL son verticalmente escalables, esto quiere decir que, para tener más potencia, espacio, velocidad, etc. se debe invertir en CPU, memoria RAM y máquinas más potentes. Por otro lado NoSQL es horizontalmente escalable, por lo que podemos repartir una base de datos muy grande en shards o particiones entre varios equipos con requerimientos de baja o media gama sin ningún problema.

Vayamos a por las herramientas

Ahora que conocemos un poco más acerca de la definición y las diferencias entre SQL y NoSQL, podemos centrarnos en MySQL vs MongoDB como herramientas principales de estos dos esquemas.

MySQL

Comencemos con lo más usado, en el caso de MySQL, podemos contar con las siguientes ventajas:

  • Compatibilidad: dado que tiene un gran tiempo y un alto grado de aceptación por parte de los desarrolladores de todo el mundo, MySQL es compatible con diversos lenguajes de programación, sistemas operativos y plataformas.
  • Crecimiento: en línea con el punto anterior, el tiempo que lleva MySQL en uso lo hace uno de los motores más robustos y maduros y, por lo tanto, una de las opciones más confiables en la red.
  • Al igual que MongoDB, la herramienta es Open Source y puede descargarse y usarse completamente gratis.

MongoDB

En el caso de la herramienta líder para el uso de bases de datos NoSQL, podemos mencionar los siguientes puntos a favor:

  • Como lo mencionamos arriba, presenta un esquema dinámico, lo que nos da la posibilidad de modificar el esquema de nuestra base de datos a medida que ingresamos registros nuevos.
  • La velocidad es otro punto a favor, dada la simplicidad de su estructura, las consultas son mucho más rápidas.

Ejemplos prácticos

¿Qué sería de una comparativa sin algo de código no? Veamos un ejemplo para tener más clara la diferencia entre estos dos motores de bases de datos.

Comencemos con el cambio más impactante entre ambos esquemas, la flexibilidad del mismo, revisando lo que necesitamos para definir una entidad en nuestro esquema de base de datos e insertar un primer registro en ella:

MySQL

CREATE DATABASE ejemplo;
USE ejemplo;
CREATE TABLE tabla (
id INT PRIMARY KEY AUTO_INCREMENT,
nombre VARCHAR(255) NOT NULL
);
INSERT INTO tabla (nombre) VALUES ("Un registro en MySQL");

Como podemos observar, para poder crear una tabla/entidad en MySQL debemos seguir un esquema algo rígido, definiendo la tabla, sus atributos, tipos de datos que almacenarán, algunas restricciones y validaciones y, por último, proceder a insertar un primer registro.

Todo esto tomando en cuenta que, a partir de este momento, la entidad mantendrá esa estructura, de modificarla, los registros anteriores tendrían una nueva propiedad con valores nulos o algún valor por defecto (aunque éste no sea necesario en todos los registros) lo que puede penalizar en cuanto a memoria y agilidad en las consultas.

MongoDB

use ejemplo
db.tabla.insert({
"nombre": "Un documento en mongodb"
})

¿Sencillo no? Es bastante directo, con el comando use ya podemos usar la entidad “ejemplo”, accesible luego a través de db, solo debemos indicar el nombre de la colección en este caso “tabla”, e insertar nuestro primer documento en formato json, con un atributo nombre y su valor. Todo esto sin definir tipos, estructura, atributos ni claves primarias.

Todo bien hasta ahora, pero, ¿Cuándo debo usar NoSQL?

Los casos recomendados en los que podemos optar preferiblemente por un esquema NoSQL son aquellos en los que tenemos un proyecto, sistema o base de datos con la siguiente expectativa de actividad y crecimiento:

  • Tendrá una carga de escritura alta, escritura en lotes o una gran cantidad de usuarios haciendo escrituras simultáneamente
  • Cuando necesitamos disponibilidad inmediata y contra fallos con la posibilidad de tener servidores particionados, incluso en distintas locaciones físicas
  • Esperamos crecer rápido y mucho, por lo que necesitaremos del escalado horizontal que nos provee el esquema
  • Tendremos data categorizada por locaciones, MongoDB permite consultas espaciales, por lo que podemos buscar datos sobre cierta área geográfica a través de coordenadas de forma bastante sencilla obteniendo resultados óptimos y rápidos
  • Cuando nuestra data tiene un peso masivo (generalmente mayor a 1GB) y nuestro esquema de base de datos restringe su crecimiento y mantenimiento

¿Quieres saber más?

No te pierdas nuestro webinar donde hablaremos de las diferencias entre MySQL y MongoDB de forma teórica y práctica para entrar en más detalles sobre el tema, puedes inscribirte ingresando a: http://www.tecnowebinars.com/webinar/17792/mongodb-vs-mysql/dev-academy. ¡Nos vemos pronto!

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s