Bases de Datos No Relacionales (NoSQL): cuándo, cómo y para qué usarlas

José María Baquero, desarrollador web de Arsys, cree que “hay todo un mundo más allá de MySQL”.

Cuando hablamos de sistemas gestores de base de datos el más usado con diferencia es MySQL. A veces puede parecer que no es necesario buscar alternativas, pues se trata de una estupenda opción, pero lo cierto es que hay todo un mundo más allá de MySQL. De hecho, en función de nuestras necesidades, MySQL no es siempre la mejor alternativa.

En este sentido, las bases de datos NoSQL están empezando a ocupar una importante parcela dentro de este espectro de soluciones ya que resuelven necesidades habituales para aplicaciones web, apps móviles o en el Internet de las Cosas.

En general, podemos encontrar de gran utilidad una base de datos NoSQL cuando nuestras necesidades se concentran en las llamadas “3V”:

  • Si una aplicación necesita almacenar o acceder a mucha información en poco tiempo se necesita una base de datos que aporte gran velocidad. Las bases de datos documentales son capaces de ser mucho más rápidas que las relacionales, ya que pueden atender proyectos que exigen muchas operaciones por segundo.
  • En cuanto al tamaño de la base de datos, si tenemos una cantidad de información enorme, entonces tenemos unas necesidades importantes de volumen. Las bases de datos relacionales tienen tendencia a funcionar más lentamente cuando en una tabla se encuentran cantidades muy grandes de registros (del orden de un millón para arriba). Situaciones así obligan a los administradores a buscar soluciones, como dividir las tablas en diversos segmentos, incrementando los tiempos y recursos que destinamos a la gestión de los datos. Este no es un problema en las bases de datos NoSQL, que son capaces de administrar volúmenes gigantescos de datos.
  • Las necesidades enormes de velocidad y volumen suelen darse juntas y afectan a muchas aplicaciones actuales. Sin embargo, hay otra característica de la información que es todavía más representativa para decantarse por las NoSQL, como la variabilidad. En bases de datos relacionales el esquema de la información está minuciosamente definido de antemano. Por ejemplo, no puedes inventarte campos en los registros sobre la marcha. En las bases de datos documentales no hay problema en que cada documento almacene campos distintos, ya que pueden ser flexibles en cuanto al esquema de la información.

Ante cualquiera de estas situaciones, las bases de datos NoSQL pueden aportar una solución ideal para los proyectos. Sin embargo, siempre conviene recordar que estas ventajas que aportan las NoSQL van en detrimento de otras operaciones básicas sobre los datos. Por ejemplo, la necesidad de joins (acceder a información de varias tablas a la vez, relacionando datos entre unas tablas y otras) son el día a día de cualquier motor de base de datos tradicional, pero no resulta una funcionalidad habitual en las NoSQL. Afortunadamente esto está cambiando y las últimas versiones de bases de datos no relacionales implementan ya funcionalidades de joins en ciertas operaciones.

Lo que a día de hoy no se encuentra disponible en las NoSQL son los mecanismos para hacer transacciones entre varios documentos. Por ello, pueden no ser la opción más adecuada para ciertas operativas de negocio, ya que se tendrá que profundizar mucho en los mecanismos para almacenar la información y puede no compensar el esfuerzo.

Respecto a qué bases NoSQL utilizar, la respuesta tampoco es única. Existen más de 200 sistemas distintos y pueden clasificarse en distintas tipologías (orientadas a Objetos, Columnas, Clave-Valor…). Entre ellas, destacan algunas de sobra conocidas por los desarrolladores, como MongoDB, Cassandra, Hadoop o Redis.

En definitiva, debemos ser conscientes de que no existen las balas de plata a la hora de hablar de las bases de datos. Las relacionales todavía son muy importantes para la mayoría de las aplicaciones, pero no son la única opción. La elección del motor de base de datos, al igual que el resto piezas de un proyecto web, debe hacerse atendiendo a los requisitos y necesidades específicas del trabajo que tenemos entre manos. Y ahí, es donde tendremos que elegir entre SQL y NoSQL.