2.2 · Modelos NoSQL: clave-valor, documentos, columnar y grafos

¿Por qué NoSQL?

Las bases de datos relacionales (RDBMS) dominan desde los años 80, y con razón: esquema claro, SQL potente y transacciones confiables. Pero el Big Data trajo requisitos que no encajan bien en ese modelo:

• Escalamiento horizontal: repartir datos entre cientos de nodos baratos, no un servidor gigante.
• Esquemas flexibles: datos semi-estructurados (JSON, logs) que cambian de forma constante.
• Volumen y velocidad extremos: millones de escrituras por segundo.

NoSQL (“Not Only SQL”) no es una tecnología única sino una familia de modelos de datos que sacrifican parte de la rigidez relacional a cambio de escalabilidad y flexibilidad. Hay cuatro modelos principales.

Los cuatro modelos NoSQL

1. Clave-valor

El modelo más simple: un diccionario gigante distribuido. Cada dato se guarda bajo una clave única y la base de datos no interpreta el valor (es un blob opaco). Ejemplo representativo: Redis (también DynamoDB, Memcached).

• Ideal para: cachés, sesiones de usuario, contadores, colas simples.
• Límite: solo puedes buscar por clave; no hay consultas por contenido.

2. Documentos

Los valores son documentos estructurados (normalmente JSON/BSON) con esquema flexible: cada documento puede tener campos distintos. Ejemplo: MongoDB (también CouchDB, Firestore).

• Ideal para: catálogos, perfiles de usuario, contenido, APIs — cualquier entidad que se lee y escribe como unidad.
• Límite: las uniones (joins) entre colecciones son costosas; se modela por agregado, no por normalización.

3. Columnar (familias de columnas)

Los datos se organizan en familias de columnas dispersas: cada fila puede tener columnas distintas y se almacenan juntas las columnas que se consultan juntas. Ejemplos: Cassandra, HBase (inspiradas en BigTable de Google).

• Ideal para: series temporales, telemetría, escrituras masivas, datasets con billones de filas.
• Límite: el modelo de consultas es rígido; hay que diseñar las tablas pensando en las consultas desde el inicio.

4. Grafos

Los datos son nodos y relaciones con propiedades, optimizados para recorrer conexiones. Ejemplo: Neo4j (también Amazon Neptune).

• Ideal para: redes sociales, detección de fraude, motores de recomendación, redes de conocimiento.
• Límite: no brilla en agregaciones masivas sobre datos tabulares; es especialista en recorridos.

graph TD
NOSQL["Bases de datos NoSQL"]
NOSQL --> KV["Clave-valor<br/>Redis, DynamoDB"]
NOSQL --> DOC["Documentos<br/>MongoDB, Firestore"]
NOSQL --> COL["Columnar<br/>Cassandra, HBase"]
NOSQL --> GRA["Grafos<br/>Neo4j"]
KV --> KV1["usuario:1234 → datos de sesión"]
DOC --> DOC1["JSON: nombre, email, pedidos..."]
COL --> COL1["Fila → familias de columnas"]
GRA --> GRA1["(Ana) -SIGUE_A→ (Luis)"]

NoSQL vs. RDBMS

No es “NoSQL reemplaza a SQL”. En arquitecturas reales conviven: el RDBMS guarda la verdad transaccional (pagos, inventario) y los sistemas NoSQL manejan el volumen y la velocidad (logs, sesiones, recomendaciones). Esto se conoce como persistencia políglota.

ACID vs. BASE

Las RDBMS garantizan ACID:

• Atomicidad: una transacción se completa entera o no ocurre.
• Consistencia: cada transacción lleva la base de un estado válido a otro.
• Islamiento: transacciones concurrentes no se interfieren.
• Durabilidad: lo confirmado sobrevive a fallos.

Los sistemas NoSQL distribuidos suelen ofrecer BASE, un juego de palabras deliberado:

• Basically Available: el sistema responde siempre, aunque sea con datos parciales o desactualizados.
• Soft state: el estado puede cambiar con el tiempo aun sin escrituras nuevas (por la propagación de réplicas).
• Eventual consistency: si dejas de escribir, todas las réplicas terminarán convergiendo al mismo valor.

La razón profunda de esta renuncia la veremos en la próxima lección con el teorema CAP: en un sistema distribuido, ante una partición de red, no puedes tener a la vez consistencia estricta y disponibilidad total.

Ejercicio: CRUD estilo documento en Python

coleccion = []
siguiente_id = 1

def crear(coleccion, doc):
  global siguiente_id
  doc = dict(doc)
  doc["_id"] = siguiente_id
  siguiente_id += 1
  coleccion.append(doc)
  return doc["_id"]

def leer(coleccion, id):
  for doc in coleccion:
      if doc["_id"] == id:
          return doc
  return None

def actualizar(coleccion, id, cambios):
  doc = leer(coleccion, id)
  if doc is None:
      return False
  doc.update(cambios)
  return True

def eliminar(coleccion, id):
  doc = leer(coleccion, id)
  if doc is None:
      return False
  coleccion.remove(doc)
  return True

uid = crear(coleccion, {"nombre": "Ana", "email": "ana@uni.edu"})
crear(coleccion, {"nombre": "Luis", "carrera": "Computación"})
actualizar(coleccion, uid, {"carrera": "Estadística"})
print(leer(coleccion, uid))
eliminar(coleccion, uid)
print(leer(coleccion, uid))  # None

Comprueba lo aprendido

Resumen

• NoSQL es una familia de modelos pensada para escalamiento horizontal y esquemas flexibles, no un reemplazo universal de SQL.
• Los cuatro modelos: clave-valor (Redis: caché/sesiones), documentos (MongoDB: entidades JSON flexibles), columnar (Cassandra/HBase: escritura masiva y series temporales), grafos (Neo4j: datos conectados).
• Frente a las RDBMS: se gana escalabilidad y flexibilidad, se pierden joins arbitrarios y transacciones estrictas.
• ACID (transacciones estrictas) vs. BASE (disponibilidad básica, estado blando, consistencia eventual).
• La persistencia políglota combina ambos mundos en una misma arquitectura.

📚 Lecturas y fuentes