B2-T5: BASES DE DATOS NoSQL Y BIG DATA
Clasificación CAP por producto
| Combinación | Sacrifica | Productos | Uso típico |
|---|
| CA (C+A) | Tolerancia a particiones | RDBMS (MySQL, Oracle, PostgreSQL) | Transaccional clásico |
| CP (C+P) | Disponibilidad | HBase, MongoDB (strong), ZooKeeper | Consistencia crítica |
| AP (A+P) | Consistencia (eventual) | Cassandra, DynamoDB, CouchDB, Riak | Alta disponibilidad |
Clave: "¿Qué garantías sacrifica Cassandra?" → Sacrifica Consistencia (es AP). "¿RDBMS en CAP?" → CA.
Tema cada vez más preguntado en el TAI, especialmente el teorema CAP, la comparativa ACID vs BASE y los tipos de bases de datos NoSQL. En Big Data preguntan Hadoop, HDFS y MapReduce como conceptos, y cada vez más Spark. Memoriza las características de cada tipo NoSQL y en qué escenarios se usa cada uno.
BASES DE DATOS NoSQL: FUNDAMENTOS
¿Qué es NoSQL?
NoSQL ("Not Only SQL") engloba un conjunto de sistemas de gestión de bases de datos que no siguen el modelo relacional tradicional. Surgieron para abordar limitaciones de las BBDD relacionales en escenarios de alto volumen, alta velocidad y datos heterogéneos (las "3V" del Big Data).
| Característica | BBDD Relacional (SQL) | BBDD NoSQL |
|---|
| Modelo de datos | Tablas con filas y columnas, esquema fijo | Variable: documentos, clave-valor, columnas, grafos |
| Esquema | Rígido (schema-on-write) | Flexible o sin esquema (schema-on-read) |
| Escalabilidad | Vertical (más potencia al servidor) | Horizontal (añadir más nodos / sharding) |
| Transacciones | ACID completo | Generalmente BASE (eventual consistency) |
| Consultas | SQL estándar, JOINs potentes | APIs específicas, limitación en JOINs |
| Relaciones | Excelente (claves foráneas, JOINs) | Limitadas (excepto BBDD de grafos) |
| Caso de uso ideal | Datos estructurados, integridad transaccional | Datos no estructurados, alto volumen, baja latencia |
Teorema CAP (Brewer, 2000)
El teorema CAP (formulado por Eric Brewer y demostrado por Gilbert y Lynch en 2002) establece que un sistema distribuido solo puede garantizar dos de tres propiedades simultáneamente:
| Propiedad | Descripción |
|---|
| C — Consistency (Consistencia) | Todos los nodos ven los mismos datos al mismo tiempo. Una lectura siempre devuelve el último valor escrito |
| A — Availability (Disponibilidad) | Toda petición recibe una respuesta (no necesariamente con el dato más reciente) |
| P — Partition tolerance (Tolerancia a particiones) | El sistema sigue funcionando aunque haya fallos de comunicación entre nodos |
Examen: En un sistema distribuido, las particiones de red siempre pueden ocurrir (P es inevitable). Por tanto, la elección real es entre CP (consistencia + particiones → sacrifica disponibilidad) y AP (disponibilidad + particiones → sacrifica consistencia). Ejemplo CP: MongoDB, HBase. Ejemplo AP: Cassandra, DynamoDB, CouchDB.
Clasificación CAP de BBDD populares
| Tipo CAP | Bases de datos | Comportamiento ante partición |
|---|
| CP | MongoDB, HBase, Redis (cluster), Zookeeper, etcd | Rechaza escrituras en nodos desconectados para mantener consistencia |
| AP | Cassandra, DynamoDB, CouchDB, Riak, Voldemort | Acepta lecturas/escrituras en todos los nodos → posible inconsistencia temporal |
| CA | RDBMS tradicionales (PostgreSQL, MySQL) en un solo nodo | No toleran particiones (no son distribuidos nativamente) |
ACID vs BASE
| ACID (Relacional) | Significado | BASE (NoSQL) | Significado |
|---|
| Atomicity | La transacción se ejecuta completa o no se ejecuta | Basically Available | El sistema responde siempre (aunque con datos no actualizados) |
| Consistency | La BBDD pasa de un estado válido a otro válido | Soft state | El estado del sistema puede cambiar con el tiempo sin intervención |
| Isolation | Las transacciones concurrentes no se interfieren | Eventually consistent | El sistema convergerá a un estado consistente si deja de recibir escrituras |
| Durability | Una vez confirmada (commit), la transacción persiste | | |
Examen: ACID = garantías fuertes, menor rendimiento a escala. BASE = garantías relajadas, mayor rendimiento y disponibilidad. Eventual consistency = los datos se propagarán a todos los nodos eventualmente, pero puede haber un período transitorio donde nodos distintos devuelven valores distintos.
TIPOS DE BASES DE DATOS NoSQL
Comparativa de tipos
| Tipo | Modelo de datos | Fortaleza | Debilidad | Ejemplo principal |
|---|
| Clave-Valor | Pares (key → value), value es opaco | Máxima velocidad, simplicidad | Sin consultas por contenido del valor | Redis, Memcached, DynamoDB |
| Documento | Documentos JSON/BSON con estructura flexible | Consultas ricas sobre el contenido | JOINs limitados, denormalización | MongoDB, CouchDB |
| Columnar (wide column) | Filas con familias de columnas dinámicas | Escrituras masivas, series temporales | Consultas ad-hoc limitadas | Cassandra, HBase |
| Grafo | Nodos + aristas (relaciones) con propiedades | Relaciones complejas, traversals | Escalabilidad horizontal difícil | Neo4j, Amazon Neptune |
CLAVE-VALOR: REDIS
Características de Redis
| Característica | Descripción |
|---|
| Tipo | Base de datos clave-valor en memoria (in-memory) |
| Persistencia | Opcional: RDB (snapshots periódicos) y/o AOF (Append-Only File, log de operaciones) |
| Rendimiento | Submilisegundo. Cientos de miles de operaciones/segundo |
| Modelo de hilos | Single-threaded (evita locks), I/O multithreaded desde Redis 6 |
| Replicación | Master-replica asíncrona |
| Alta disponibilidad | Redis Sentinel (failover automático) |
| Clustering | Redis Cluster — sharding automático por hash slots (16.384 slots) |
| Licencia | BSD (hasta 7.0), luego RSALv2/SSPLv1 (desde 7.2) |
Estructuras de datos en Redis
| Tipo | Comandos principales | Uso típico |
|---|
| String | SET, GET, INCR, DECR | Caché, contadores, flags |
| Hash | HSET, HGET, HGETALL | Objetos (usuario: nombre, email…) |
| List | LPUSH, RPUSH, LPOP, RPOP, LRANGE | Colas, timelines, logs recientes |
| Set | SADD, SMEMBERS, SINTER, SUNION | Tags, relaciones, unicidad |
| Sorted Set (ZSet) | ZADD, ZRANGE, ZRANK, ZRANGEBYSCORE | Rankings, leaderboards, colas con prioridad |
| Bitmap | SETBIT, GETBIT, BITCOUNT | Flags por usuario, actividad diaria |
| HyperLogLog | PFADD, PFCOUNT | Conteo de elementos únicos aproximado (12 KB fijos) |
| Stream | XADD, XREAD, XREADGROUP | Log de eventos, mensajería (similar a Kafka) |
Políticas de expiración y evicción
| Política | Descripción |
|---|
| TTL (Time To Live) | Cada clave puede tener un tiempo de expiración (EXPIRE key seconds) |
| noeviction | Rechaza escrituras si la memoria está llena (por defecto) |
| allkeys-lru | Evicta las claves menos recientemente usadas (cualquier clave) |
| volatile-lru | Evicta las menos usadas, solo entre claves con TTL |
| allkeys-random | Evicta claves al azar |
| volatile-ttl | Evicta las que están más cerca de expirar |
Examen: Redis = in-memory, submilisegundo, clave-valor con estructuras ricas. Uso principal: caché, sesiones, colas, pub/sub, contadores atómicos. Persistencia RDB = snapshots (rápido en carga, puede perder datos del último intervalo). AOF = log de escrituras (más seguro, archivo más grande).
DOCUMENTOS: MONGODB
Características de MongoDB
| Característica | Descripción |
|---|
| Modelo | Documentos BSON (Binary JSON) almacenados en colecciones |
| Esquema | Flexible — cada documento puede tener campos distintos (schema-on-read) |
| Consultas | Lenguaje de consulta rico (MQL): filtros, proyecciones, agregación (pipeline) |
| Índices | B-tree, compuestos, texto, geoespaciales (2dsphere), wildcard |
| Replicación | Replica Set: 1 primary + N secondaries. Failover automático |
| Sharding | Particionamiento horizontal automático por shard key |
| Transacciones | Multi-documento ACID desde MongoDB 4.0 (replica set) y 4.2 (sharded) |
| Agregación | Pipeline: $match, $group, $sort, $project, $lookup (JOIN) |
| CAP | CP — consistencia por defecto (lecturas van al primary) |
Conceptos de MongoDB
| Concepto SQL | Equivalente MongoDB | Descripción |
|---|
| Base de datos | Base de datos | Contenedor de colecciones |
| Tabla | Colección | Grupo de documentos (sin esquema fijo) |
| Fila | Documento | Objeto BSON (JSON binario) |
| Columna | Campo | Par clave-valor dentro del documento |
| Clave primaria | _id | Generado automáticamente (ObjectId de 12 bytes) |
| JOIN | $lookup (pipeline) | Agregación que simula JOIN entre colecciones |
| Índice | Índice | B-tree sobre campos del documento |
BSON ObjectId
El ObjectId de MongoDB es un identificador único de 12 bytes con esta estructura:
| Bytes | Contenido |
|---|
| 4 bytes | Timestamp (segundos desde epoch Unix) |
| 5 bytes | Valor aleatorio (único por proceso) |
| 3 bytes | Contador incremental |
COLUMNAR: CASSANDRA
Características de Apache Cassandra
| Característica | Descripción |
|---|
| Modelo | Wide-column store (familias de columnas con filas dinámicas) |
| Arquitectura | Peer-to-peer (sin master). Todos los nodos son iguales (ring) |
| Particionamiento | Consistent hashing — datos distribuidos automáticamente por partition key |
| Replicación | Configurable: factor de replicación N (ej. RF=3 = 3 copias) |
| Consistencia | Tunable consistency: ONE, QUORUM, ALL (configurable por operación) |
| CAP | AP por defecto (disponibilidad > consistencia). Puede acercarse a CP con QUORUM |
| Lenguaje | CQL (Cassandra Query Language) — similar a SQL pero sin JOINs ni subqueries |
| Escritura | Muy rápida — append-only (LSM-tree: memtable → SSTable en disco) |
| Origen | Facebook (2008), Apache Software Foundation |
Niveles de consistencia en Cassandra
| Nivel | Lectura: responde cuando... | Escritura: confirma cuando... |
|---|
| ONE | 1 réplica responde | 1 réplica confirma la escritura |
| QUORUM | (RF/2)+1 réplicas responden | (RF/2)+1 réplicas confirman |
| ALL | Todas las réplicas responden | Todas confirman |
| LOCAL_QUORUM | Quorum dentro del datacenter local | Quorum en el datacenter local |
Examen: Cassandra usa consistent hashing (ring de tokens) para distribuir datos. No tiene un nodo master — es totalmente descentralizada. Esto la hace ideal para alta disponibilidad multi-datacenter. Las escrituras son extremadamente rápidas porque son append-only (LSM-tree).
GRAFOS: NEO4J
Características de Neo4j
| Característica | Descripción |
|---|
| Modelo | Grafo de propiedades: nodos (con etiquetas y propiedades) + relaciones (dirigidas, con tipo y propiedades) |
| Lenguaje | Cypher — lenguaje declarativo para consultas de grafos |
| Almacenamiento | Nativo de grafos (index-free adjacency) — los nodos tienen punteros directos a sus vecinos |
| Traversal | Eficiente para relaciones profundas — O(1) por salto de relación |
| Transacciones | ACID completo |
| Caso de uso | Redes sociales, detección de fraude, motores de recomendación, gestión de conocimiento |
Sintaxis básica de Cypher
| Operación | Cypher |
|---|
| Crear nodo | CREATE (p:Persona {nombre: "Ana", edad: 30}) |
| Crear relación | MATCH (a:Persona), (b:Persona) WHERE a.nombre="Ana" AND b.nombre="Luis" CREATE (a)-[:CONOCE]->(b) |
| Consultar | MATCH (p:Persona)-[:CONOCE]->(amigo) RETURN p.nombre, amigo.nombre |
| Camino más corto | MATCH path=shortestPath((a)-[*]-(b)) RETURN path |
Examen: La ventaja clave de una BBDD de grafos sobre una relacional para datos con muchas relaciones es que los JOINs en SQL crecen exponencialmente en coste con la profundidad, mientras que los traversals en grafos se mantienen en tiempo constante por salto (index-free adjacency).
OTRAS BBDD NoSQL RELEVANTES
| Base de datos | Tipo | Características clave | Caso de uso |
|---|
| Amazon DynamoDB | Clave-valor / documento | Serverless, managed, auto-scaling, DAX (caché) | Aplicaciones web, gaming, IoT |
| Apache HBase | Columnar | Sobre HDFS, Hadoop ecosystem, consistente (CP) | Big Data, análisis sobre Hadoop |
| CouchDB | Documento | HTTP/REST API, replicación multi-master, MVCC | Apps offline-first, sincronización |
| Elasticsearch | Documento (búsqueda) | Basado en Apache Lucene, full-text search, agregaciones | Búsqueda, logging (ELK stack) |
| InfluxDB | Series temporales | Optimizado para time-series data, retention policies | Monitorización, IoT, métricas |
| Memcached | Clave-valor (caché) | Solo en memoria, sin persistencia, multi-threaded | Caché simple de objetos |
BIG DATA: CONCEPTOS
Las V's del Big Data
| V | Descripción |
|---|
| Volumen | Cantidad masiva de datos (terabytes, petabytes, exabytes) |
| Velocidad | Rapidez de generación y procesamiento (streaming, tiempo real) |
| Variedad | Datos estructurados, semiestructurados y no estructurados |
| Veracidad | Calidad, fiabilidad y precisión de los datos |
| Valor | Capacidad de extraer información útil de los datos |
Procesamiento: batch vs streaming
| Aspecto | Batch (por lotes) | Streaming (tiempo real) |
|---|
| Latencia | Alta (minutos a horas) | Baja (milisegundos a segundos) |
| Datos | Dataset completo y acotado (bounded) | Flujo continuo e ilimitado (unbounded) |
| Herramientas | Hadoop MapReduce, Spark (batch), Hive | Spark Streaming, Kafka Streams, Apache Flink, Storm |
| Caso de uso | ETL nocturno, informes históricos | Detección de fraude, monitorización, alertas |
ECOSISTEMA HADOOP
Apache Hadoop: componentes principales
Apache Hadoop (proyecto Apache Software Foundation) es un framework de código abierto para almacenamiento y procesamiento distribuido de grandes volúmenes de datos en clusters de hardware commodity.
| Componente | Función | Descripción |
|---|
| HDFS | Almacenamiento | Sistema de ficheros distribuido. Archivos divididos en bloques (128 MB por defecto), replicados en múltiples nodos |
| MapReduce | Procesamiento | Modelo de programación: fase Map (transformar datos en pares clave-valor) + fase Reduce (agregar valores por clave) |
| YARN | Gestión de recursos | Yet Another Resource Negotiator. Planifica y gestiona recursos del cluster para múltiples frameworks |
| Hadoop Common | Utilidades | Librerías y utilidades comunes para los demás módulos |
HDFS: arquitectura
| Componente | Rol | Descripción |
|---|
| NameNode | Master | Almacena los metadatos del sistema de ficheros (árbol de directorios, ubicación de bloques). Único punto de fallo (se mitiga con HA: standby NameNode) |
| DataNode | Worker | Almacena los bloques de datos reales. Envía heartbeats al NameNode |
| Secondary NameNode | Auxiliar | NO es un failover. Hace checkpoints del NameNode (merge de edits log con fsimage) |
| Parámetro HDFS | Valor por defecto | Descripción |
|---|
| Tamaño de bloque | 128 MB (era 64 MB) | Cada archivo se divide en bloques de este tamaño |
| Factor de replicación | 3 | Cada bloque se replica en 3 DataNodes distintos |
| Rack awareness | Activado | Las réplicas se distribuyen en distintos racks para tolerancia a fallos |
Examen: HDFS es un sistema write-once, read-many (optimizado para lectura secuencial de archivos grandes). Bloques de 128 MB. Factor de replicación 3 por defecto. El NameNode es el punto único de fallo → se resuelve con HA (2 NameNodes activo/standby + Zookeeper).
MapReduce: paradigma de procesamiento
| Fase | Entrada | Salida | Descripción |
|---|
| Map | Registros del archivo de entrada | Pares (clave, valor) intermedios | Transforma/filtra cada registro de forma independiente y paralela |
| Shuffle & Sort | Pares intermedios | Pares agrupados por clave | El framework agrupa y ordena los pares por clave (automático) |
| Reduce | Clave + lista de valores | Resultado final | Agrega los valores de cada clave (suma, conteo, concatenación…) |
Herramientas del ecosistema Hadoop
| Herramienta | Función | Descripción |
|---|
| Apache Hive | Data Warehouse | SQL-like (HiveQL) sobre Hadoop. Traduce consultas SQL a jobs MapReduce/Tez/Spark |
| Apache Pig | ETL | Lenguaje Pig Latin para transformación de datos. Nivel de abstracción sobre MapReduce |
| Apache HBase | BBDD columnar | BBDD NoSQL sobre HDFS. Acceso aleatorio de baja latencia a datos Hadoop |
| Apache Sqoop | Importación/exportación | Transferencia de datos entre HDFS y BBDD relacionales (MySQL, Oracle, PostgreSQL) |
| Apache Flume | Ingesta de logs | Recolección y transporte de logs/eventos a HDFS |
| Apache Oozie | Orquestación | Planificador de workflows de jobs Hadoop (MapReduce, Pig, Hive, etc.) |
| Apache Zookeeper | Coordinación | Servicio centralizado de configuración, naming y sincronización distribuida |
| Apache Kafka | Mensajería/Streaming | Plataforma de streaming distribuida. Topics, particiones, consumer groups. Alta throughput |
APACHE SPARK
Características de Spark
| Característica | Descripción |
|---|
| Tipo | Framework de procesamiento distribuido en memoria |
| Velocidad | Hasta 100× más rápido que MapReduce para procesamiento en memoria |
| Abstracción principal | RDD (Resilient Distributed Dataset) — colección distribuida inmutable con tolerancia a fallos |
| APIs modernas | DataFrame y Dataset — APIs estructuradas con optimizador Catalyst |
| Lenguajes | Scala (nativo), Java, Python (PySpark), R (SparkR) |
| Almacenamiento | Compatible con HDFS, S3, Cassandra, HBase, cualquier fuente |
| Cluster managers | YARN, Mesos, Kubernetes, standalone |
Componentes de Spark
| Componente | Función | Descripción |
|---|
| Spark Core | Motor base | RDDs, planificación de tareas, gestión de memoria, E/S |
| Spark SQL | Datos estructurados | DataFrames, consultas SQL, integración con Hive |
| Spark Streaming | Streaming | Procesamiento de flujos de datos en micro-batches |
| Structured Streaming | Streaming moderno | API declarativa sobre DataFrames para streaming con garantías exactly-once |
| MLlib | Machine Learning | Algoritmos de ML distribuidos (clasificación, regresión, clustering, CF) |
| GraphX | Procesamiento de grafos | API para computación de grafos distribuida (PageRank, etc.) |
Spark vs MapReduce
| Aspecto | MapReduce | Spark |
|---|
| Procesamiento | Disco (lee/escribe entre fases) | Memoria (mantiene datos en RAM) |
| Velocidad | Lento (I/O a disco entre map y reduce) | Hasta 100× más rápido en memoria |
| Modelo | Solo Map + Reduce | Transformaciones y acciones ricas (map, filter, join, groupBy…) |
| Iteraciones | Ineficiente (escribe a disco cada iteración) | Eficiente (datos en memoria entre iteraciones) |
| Streaming | No (solo batch) | Sí (Spark Streaming / Structured Streaming) |
| Facilidad de uso | Verbose (Java) | APIs concisas (Scala, Python) |
Examen: La principal ventaja de Spark sobre MapReduce es el procesamiento en memoria — no escribe resultados intermedios a disco. Esto lo hace especialmente superior en algoritmos iterativos (ML, grafos). Spark no reemplaza HDFS — usa HDFS (u otro) como almacenamiento.
DATA WAREHOUSE, DATA LAKE Y ARQUITECTURAS DE DATOS
Comparativa de arquitecturas
| Concepto | Tipo de datos | Esquema | Usuarios | Herramienta típica |
|---|
| Data Warehouse | Estructurados (ETL previo) | Schema-on-write (estrella/copo de nieve) | Analistas de negocio | Hive, Redshift, BigQuery, Snowflake |
| Data Lake | Todos (raw: estructurados + no estructurados) | Schema-on-read | Data scientists, ingenieros de datos | HDFS, S3, Azure Data Lake |
| Data Lakehouse | Todos (raw + curados) | Schema-on-read + enforcement | Ambos perfiles | Delta Lake, Apache Iceberg, Apache Hudi |
ETL vs ELT
| Proceso | Flujo | Cuándo usar |
|---|
| ETL (Extract, Transform, Load) | Extraer → Transformar (fuera del destino) → Cargar en DW | Data Warehouse tradicional, datos estructurados |
| ELT (Extract, Load, Transform) | Extraer → Cargar crudo → Transformar dentro del Data Lake | Big Data, Data Lake, cuando la transformación es costosa |
FUENTES PÚBLICAS
Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
| Fuente | Tipo | Referencia |
|---|
| Apache Hadoop documentation | Documentación oficial | hadoop.apache.org (Apache 2.0) |
| Apache Spark documentation | Documentación oficial | spark.apache.org |
| MongoDB documentation | Documentación oficial | docs.mongodb.com |
| Redis documentation | Documentación oficial | redis.io |
| Brewer (2000) — Teorema CAP | Publicación académica | Dominio público |