SQL vs NoSQL

Cuando empezamos un nuevo proyecto que requiere del uso de una base de datos nos tenemos que hacer una pregunta muy básica como ¿Debería de utilizar una base de datos SQL como MySQL o una NoSQL como MongoDB?

Últimamente, NodeJS se ha hecho un hueco importante en los sistemas backend y parece bastante común relacionar este entorno con una base de datos NoSQL como MongoDB (influyen bastante los stacks como MEAN o MERN que se han puesto tan de moda).

Sin embargo, esto es un gran error, los desarrolladores no debemos caer en la tentativa de relacionar una tecnología automáticamente con otra, sino saber qué casos son los más recomendables para utilizar una u otra.

En este artículo veremos algunos conceptos clave sobre estas dos bases de datos y las ventajas y desventajas de estas.

Bases de datos SQL

Cuando hablamos de SQL nos referimos al Lenguaje de Consulta Estructurado (Structured Query Language), con el que interactuamos con un tipo específico de base de datos. Este nos permite almacenar, obtener, actualizar y borrar datos de sistemas de bases de datos relacionales. Estos sistemas tienen dos características que son clave:

  1. Los datos se almacenan en la base de datos siguiendo un esquema estricto fijado con anterioridad por el diseñador de la base de datos.
  2. Los datos se almacenan en la base de datos en una serie de tablas y estas se conectan mediante relaciones. Por ejemplo: “Persona” (tabla) tiene (relación) “Vehículo” (tabla).

 

¿A qué nos referimos con un esquema estricto?

Como hemos dicho, los datos se almacenan en tablas y, cada una de estas, tienen una estructura muy bien definida por una serie de campos. Los campos o propiedades de cada tabla definen qué datos deberían ser almacenados y cuáles no. Estos campos tienen un tipo asociado que identifica qué tipo de dato se almacena.

En la tabla anterior, no se podrían añadir productos con otros campos ya que no cumpliría el esquema definido.

 

Relaciones entre tablas

En el siguiente ejemplo, separamos los datos en múltiples tablas con sus respectivos campos para evitar tener datos repetidos, pero ¿cómo almacenaríamos los pedidos que un usuario hace de un producto? Para eso podemos utilizar una tabla “pedidos” que relacione la de “usuarios” con la de “productos”, de manera que ahora, por ejemplo, sabemos que el usuario con id 1 realizó un pedido del producto con un id 2.

Al relacionar datos mediante identificadores tenemos la ventaja de que la tabla de Pedidos nunca va a tener datos erróneos si mantenemos los datos de Usuarios y Productos correctos, ya que evitamos la duplicidad de datos.

Bases de datos NoSQL

NoSQL se llama así básicamente porque es todo lo contrario a SQL; no hay esquemas y no hay relaciones.

Los datos se almacenan en documentos (concepto similar al de registro de SQL) contenidos en colecciones (concepto similar al de tabla de SQL).

Sin embargo, no solo se diferencian en la nomenclatura, lo interesante de dos o más documentos que pertenecen a la misma colección es que no tienen por qué tener la misma estructura (¿recordáis de la importancia de tener un esquema estricto en SQL?)

Como hemos dicho, no hay que preocuparse de un esquema estricto, pero resulta obvio que nos interese guardar datos relacionados en la misma colección, como, por ejemplo, los documentos relacionados con los pedidos dentro de la colección “Pedidos”, de esta manera conseguimos tenerlo todo relacionado sin tener que hacer nada más, ni preocuparnos de unir colecciones como hacemos en SQL (tablas).

 

Escalado vertical y horizontal

Cuando comparamos bases de datos nos tenemos que fijar en otro concepto importante. Este es el escalado. Con escalado nos referimos al número de peticiones de lectura y escritura que la base de datos es capaz de manejar, con cuánta cantidad de información es capaz de trabajar.

Podemos diferenciar dos tipos de escalado:

  • Escalado vertical: aumentar las prestaciones de nuestro ordenador. Por ejemplo, aumentar el disco duro, la memoria RAM, añadir discos SSD, etc.
  • Escalado horizontal: agregar más servidores en los que la base de datos se tiene que distribuir.

Debido a cómo se almacena la información (tablas relacionadas vs colecciones no relacionadas), las bases de datos SQL generalmente sólo soportan escalado vertical, mientras que el horizontal se deja para las NoSQL.

Se puede implementar el concepto de sharding en las bases de datos SQL, pero tiene una serie de restricciones y es difícil de implementar. Sin embargo, las no relacionales soportan de serie y es más fácil separar la información en distintos servidores.

Muy bien, pero… ¿cuál debo escoger?, ¿cuál es la mejor?

La respuesta es tan sencilla como que depende de tu caso. ¡No hay un claro ganador! Tanto SQL como NoSQL son igualmente soluciones viables, pero se utilizan de manera distinta según el problema a resolver.

Separaremos en unas pocas ventajas y desventajas para que puedas verlo con más claridad:

Ventajas

  • SQL
    • Esquema definido con claridad y la integridad en los datos está garantizada.
    • No hay duplicidad de datos gracias al uso de relaciones entre tablas.
  • NoSQL
    • Mayor flexibilidad al no disponer de esquema al que ceñirse.
    • Los datos se almacenan en un formato que tu app necesita, se gana en velocidad.
    • Se puede escalar tanto vertical como horizontalmente.
    • Ofrece un alto rendimiento

Desventajas

  • SQL
    • Menos flexibilidad: hay que planificar con tiempo el esquema ya que luego es más complicado actualizarlo.
    • El uso de relaciones puede conllevar consultas JOIN complejas.
    • A veces el escalado horizontal se torna demasiado complicado.
  • NoSQL
    • La flexibilidad puede conllevar a posponer decisiones de estructura importantes.
    • Alta posibilidad de tener datos duplicados.

¿Cuándo utilizo una base de datos relacional (SQL)?

  • Tengo datos relacionados que cambian con frecuencia y en una NoSQL me llevaría a actualizar múltiples colecciones.
  • Necesito un esquema estricto

¿Cuándo utilizo una base de datos no relacional (NoSQL)?

  • Los requisitos de los datos o los propios datos son desconocidos o están sujetos a cambiar o expandirse con facilidad.
  • Necesito un alto rendimiento de lectura, pero no quiero modificar los datos tan a menudo.
  • Necesito escalar mi base de datos horizontalmente.

Posibles casos reales de ejemplo

Cuando entramos en el mundo de las bases de datos, a pesar de que nos encontremos con multitud de páginas que nos indican ventajas y desventajas casi siempre acabamos preguntándonos a qué casos reales podríamos aplicar cada una de ellas. Vamos a ver diferentes casos:

SQL:

  • Tienda online (e-commerce): podemos almacenar a los clientes, los productos y los pedidos en tablas. Es importante que se mantenga una estructura estricta ya que necesitamos mantener la atomicidad entre los datos.
  • Plantilla de trabajadores de una empresa: podemos tener tablas que hagan referencia a los departamentos, los trabajadores y los distintos proyectos de los que se encarga cada uno. Sería un buen ejemplo de SQL ya que nos interesa que se cumpla una de las básicas de SQL (ACID: atomicidad, consistencia, aislamiento y durabilidad)

NoSQL:

  • Expedición aeroespacial para recoger muestras: podemos almacenar todos los datos recopilados en una base de datos NoSQL ya que podemos no tener la certeza de qué muestras se van a encontrar, de manera que necesitemos un esquema muy flexible.
  • IMDB: según su director técnico utilizan DynamoDB (un servicio de base de datos NoSQL) ya que les ofrece un alto rendimiento y perfecta escalabilidad, lo que les permite centrarse en otros aspectos.

Al igual que los lenguajes de programación, la elección de una base de datos u otra, dependerá mucho del tipo de proyecto que tengamos entre manos, sin embargo, no debemos tener el miedo a elegir una u otra ya que al final lo que nos dará la solución óptima entre un tipo de base de datos u otra será cacharrear, romper y volver a diseñar nuestras aplicaciones. Solo así llegaremos a un punto en el que podremos tener mayor seguridad a la hora de decidir entre una u otra.