Bases de datos NoSQL: qué son, tipos y cuándo utilizarlas

Las bases de datos NoSQL surgieron para resolver problemas que no siempre encajan bien en el modelo relacional tradicional: grandes volúmenes de información, estructuras de datos variables, aplicaciones distribuidas o cargas que deben escalar horizontalmente entre muchos servidores.

NoSQL no designa un único modelo de base de datos. Es una familia que incluye sistemas orientados a documentos, clave-valor, columnas y grafos, entre otros. Tampoco significa que SQL haya quedado obsoleto: en muchas arquitecturas modernas conviven bases de datos relacionales y NoSQL, utilizando cada tecnología donde aporta más ventajas.

Qué es una base de datos NoSQL

Una base de datos NoSQL almacena y consulta información utilizando modelos distintos del esquema clásico de tablas, filas, columnas y relaciones mediante claves externas.

Una diferencia habitual es la flexibilidad del esquema. En una base documental, por ejemplo, dos registros de una misma colección pueden contener campos diferentes. La documentación de MongoDB sobre modelado de datos describe precisamente un modelo flexible en el que los datos relacionados pueden almacenarse juntos dentro de un documento.

Esto puede simplificar aplicaciones cuyos objetos evolucionan con frecuencia. Un catálogo de comercio electrónico podría almacenar una batería en un teléfono móvil, una diagonal de pantalla en un televisor y una capacidad de almacenamiento en un SSD sin tener que crear una estructura relacional extremadamente dispersa.

NoSQL, sin embargo, no equivale a «sin esquema»: la aplicación sigue necesitando definir qué información espera encontrar y cómo se validará.

Principales tipos de bases de datos NoSQL

No existe un único modelo NoSQL. Los cuatro grupos más habituales responden a necesidades diferentes.

Bases de datos documentales

Almacenan objetos completos en documentos, normalmente representados mediante estructuras similares a JSON. MongoDB es uno de los ejemplos más conocidos.

Un documento correspondiente a un usuario puede contener su nombre, direcciones, preferencias y otros atributos relacionados. Evitar determinadas operaciones de unión puede resultar conveniente cuando esos datos suelen consultarse conjuntamente.

Este modelo funciona especialmente bien en catálogos, sistemas de gestión de contenidos, perfiles de usuarios y aplicaciones web con estructuras de información variables.

Bases de datos clave-valor

Cada dato se identifica mediante una clave única asociada a un valor. Conceptualmente funcionan de forma parecida a un gran diccionario distribuido:

usuario:2481 → datos del usuario

Su sencillez permite realizar determinadas operaciones con una latencia muy baja. Redis, por ejemplo, proporciona estructuras como cadenas, hashes, listas, conjuntos y conjuntos ordenados, además de otras estructuras especializadas.

Son habituales para cachés, sesiones, contadores, colas y datos que necesitan acceso muy rápido.

Bases de datos de columnas anchas

Organizan los datos alrededor de claves de partición y familias o grupos de columnas. Están diseñadas principalmente para sistemas distribuidos de gran escala.

Apache Cassandra es un ejemplo representativo. Distribuye las particiones entre los nodos del clúster mediante una variante de consistent hashing y permite seleccionar distintos niveles de consistencia para las operaciones.

Resultan interesantes cuando se necesitan grandes tasas de escritura, distribución geográfica o capacidad para continuar funcionando aunque fallen determinados nodos.

Bases de datos de grafos

Representan directamente entidades y relaciones. En un property graph, por ejemplo, existen nodos, relaciones y propiedades asociadas a ambos elementos. Así funciona el modelo descrito en la documentación de Neo4j.

Son especialmente útiles cuando las conexiones constituyen una parte central del problema: redes sociales, recomendaciones, detección de fraude, gestión de identidades o análisis de dependencias.

Escalabilidad horizontal y sistemas distribuidos

Una de las razones fundamentales para adoptar NoSQL es facilitar el escalado horizontal: aumentar la capacidad incorporando nuevos nodos en lugar de depender exclusivamente de servidores cada vez más potentes.

Los datos pueden dividirse mediante sharding o particionamiento. MongoDB, por ejemplo, utiliza sharding para distribuir conjuntos de datos entre varias máquinas y soportar volúmenes elevados de información y tráfico.

Esta distribución introduce nuevos problemas: replicación, particiones de red, sincronización y elección del nivel de consistencia.

Aquí aparece el conocido teorema CAP. En presencia de una partición de red, un sistema distribuido no puede garantizar simultáneamente consistencia fuerte y disponibilidad completa; debe existir algún compromiso entre ambas propiedades. Este resultado fue formalizado por Seth Gilbert y Nancy Lynch a partir de la conjetura de Eric Brewer.

Por eso algunos sistemas permiten configurar cuántas réplicas deben confirmar una operación antes de considerarla válida.

NoSQL, consistencia y transacciones ACID

Es habitual asociar SQL con transacciones ACID y NoSQL con consistencia eventual, pero esa simplificación ya no describe correctamente muchos gestores modernos.

ACID hace referencia a atomicidad, consistencia, aislamiento y durabilidad, propiedades esenciales para operaciones como transferencias bancarias o movimientos de inventario relacionados.

Algunos motores NoSQL también proporcionan garantías transaccionales importantes. MongoDB admite, por ejemplo, transacciones distribuidas que abarcan varios documentos, colecciones y bases de datos. Cassandra, por su parte, permite seleccionar distintos niveles de consistencia y dispone de operaciones específicas con garantías más fuertes.

Por tanto, la elección no debería reducirse a «SQL tiene consistencia y NoSQL no». Hay que analizar las garantías concretas ofrecidas por cada producto y configuración.

NoSQL frente a bases de datos relacionales

Las bases relacionales siguen siendo una excelente elección cuando existen relaciones estructuradas, consultas complejas, restricciones de integridad y operaciones transaccionales frecuentes.

NoSQL suele destacar cuando predominan estructuras flexibles, enormes volúmenes de información, patrones de acceso muy específicos o necesidades importantes de distribución horizontal.

En una misma plataforma pueden utilizarse ambas aproximaciones. Una tienda online podría almacenar pedidos y facturación en PostgreSQL, mantener el catálogo en una base documental y utilizar Redis como caché. Esta combinación se conoce habitualmente como persistencia políglota.

En este artículo de Tecnoic sobre arquitectura web moderna puedes ver cómo la base de datos forma parte de una arquitectura completa junto al front-end, el back-end y otros servicios.

Cuándo merece la pena utilizar NoSQL

La elección debe comenzar por el modelo de datos y los patrones de acceso, no por la popularidad de una tecnología.

NoSQL puede ser especialmente adecuado cuando necesitamos distribuir grandes cantidades de información entre muchos servidores, gestionar esquemas que cambian con frecuencia, almacenar relaciones complejas mediante grafos o proporcionar accesos de muy baja latencia.

También tiene inconvenientes. La desnormalización puede duplicar información, un mal diseño de las claves de partición puede crear nodos sobrecargados y determinados tipos de consulta pueden ser mucho más complicados que mediante SQL. La propia documentación de Cassandra advierte de que ciertos patrones de acceso pueden generar particiones especialmente activas capaces de afectar a la estabilidad del clúster.

NoSQL, por tanto, no sustituye al modelo relacional: amplía las herramientas disponibles para diseñar sistemas de información.

Qué base de datos elegir

Antes de seleccionar un gestor conviene definir qué datos vamos a almacenar, cómo se consultarán, qué garantías de consistencia necesitamos y cómo deberá crecer el sistema.

MongoDB puede encajar en modelos documentales flexibles; Redis en cachés y operaciones rápidas sobre estructuras de datos; Cassandra en sistemas distribuidos con grandes volúmenes; y Neo4j cuando las relaciones entre entidades constituyen el núcleo del problema.

La arquitectura correcta incluso puede combinar varios de ellos. La cuestión importante no es si SQL o NoSQL es mejor, sino qué modelo representa y procesa nuestros datos con menor complejidad. ¿En qué tipo de proyecto utilizarías una base de datos NoSQL?