⚡ OLTP vs OLAP
Dos paradigmas fundamentales de bases de datos. OLTP procesa transacciones en tiempo real (INSERT, UPDATE, DELETE). OLAP analiza grandes volúmenes de datos históricos (SELECT con agregaciones masivas). Mezclar ambos en la misma base de datos es una receta para el desastre.
🎯 Transaccional vs. analítico
OLTP (procesamiento de transacciones en línea) está optimizado para operaciones rápidas y puntuales: registrar un cliente, registrar una venta, actualizar el inventario. Usa row-store (datos organizados por fila).
OLAP (procesamiento analítico en línea) está optimizado para recorrer millones de registros y generar agregaciones: "¿cuál fue la facturación por región en los últimos 3 años?". Usa column-store (datos organizados por columna), lo que permite comprimir y leer solo las columnas necesarias.
- • Almacenamiento por filas: Ideal para buscar un registro completo (SELECT * WHERE id = X). PostgreSQL, MySQL, Oracle.
- • Almacenamiento columnar: Ideal para agregar una columna completa (SUM, AVG, COUNT). BigQuery, Redshift, ClickHouse.
- • Híbrido (HTAP): Intenta combinar ambos. TiDB, CockroachDB, AlloyDB. Complejo, pero prometedor.
✅ HAZLO
- • Separa las cargas OLTP y OLAP en bases de datos distintas
- • Usa réplicas de lectura para consultas analíticas
- • Evalúa un column-store para dashboards exigentes
- • Define SLAs diferentes para cada carga
❌ NO HAGAS
- • Ejecutar informes pesados en la base de datos de producción
- • Creer que una sola base de datos lo resuelve todo
- • Ignorar la latencia de escritura en sistemas OLAP
- • Confundir un row-store lento con una "base de datos mala"
📦 Particionamiento
Particionamiento divide una tabla grande en partes más pequeñas (particiones) basadas en un criterio. La base de datos sabe en qué partición buscar, lo que evita recorrer toda la tabla. Es esencial para tablas con millones o miles de millones de filas.
💻 Particionamiento por rango (PostgreSQL)
CREATE TABLE pedido (
id SERIAL,
total NUMERIC,
criado_em DATE
) PARTITION BY RANGE (criado_em);
CREATE TABLE pedido_2024 PARTITION OF pedido
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
CREATE TABLE pedido_2025 PARTITION OF pedido
FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');🔍 Tipos de particionamiento
Rango
Divide en rangos de valores (fechas, ID). Es el método más común. Ideal para datos temporales.
Hash
Distribuye uniformemente según el hash de una columna. Es útil para equilibrar la carga entre particiones.
List
Divide según valores discretos (país, estado, categoría). Cada valor va a su partición.
💡 Consejo práctico
Particiona solo tablas con millones de registros. Las tablas pequeñas no se benefician y el costo adicional de administrar particiones no compensa. La columna de partición debe estar presente en prácticamente todas las consultas con WHERE para que el partition pruning funcione.
🗄️ Archivado y retención
Los datos no pueden permanecer en la base de datos para siempre. Políticas de retención definen cuánto tiempo conservar cada tipo de dato. Archivado mueve los datos antiguos a un almacenamiento más barato. Es cuestión de cumplimiento normativo, costo y rendimiento.
🎯 Cumplimiento normativo: LGPD y GDPR
Las leyes de protección de datos exigen que los datos personales se conserven solo durante el tiempo necesario. Guardar datos más tiempo del necesario es riesgo jurídico y financiero.
- • LGPD (Brasil): Los datos personales deben eliminarse cuando se haya cumplido el propósito o se revoque el consentimiento
- • GDPR (Europa): Principio de minimización: recopila y conserva solo lo estrictamente necesario
- • Almacenamiento en frío: Los datos históricos pueden ir a un almacenamiento económico (S3 Glacier, Azure Archive) con acceso ocasional
- • Purge Jobs: Jobs programados que eliminan automáticamente los datos vencidos. Sin purge, la base de datos solo crece.
💡 Consejo práctico
Crea una tabla de políticas de retención que mapee cada tipo de dato a su plazo máximo. Implementa un cron job (o pg_cron) que se ejecute semanalmente, verifique los plazos y realice el archivado/purga automáticamente. Documenta todo: te lo pedirán en las auditorías.
📊 Almacén de datos
Un Almacén de datos y un repositorio centralizado optimizado para consultas analíticas. Mientras que las bases de datos OLTP sirven a la aplicación, el DW sirve al inteligencia de negocios. Los datos de múltiples fuentes se consolidan en un modelo optimizado para el análisis.
🎯 Star Schema
El modelo más usado en Data Warehouses. Un tabla de hechos central (métricas, eventos) rodeada por tablas de dimensiones (contexto descriptivo).
Tabla de hechos (fact)
Contiene métricas cuantitativas: valor de la venta, cantidad, costo. Claves foráneas para dimensiones. Muchas filas, pocas columnas.
Tabla de dimensión (dim)
Contiene atributos descriptivos: nombre del producto, ciudad, categoría. Pocas filas, muchas columnas. Responde "quién, qué, dónde, cuándo".
🔍 Ecosistema de Data Warehouse
- BigQuery (Google): Serverless, column-store, pago por query. Escala automáticamente.
- Redshift (AWS): Clúster administrado, column-store, integración nativa con S3.
- Snowflake: Multicloud, separa el almacenamiento del cómputo, concurrencia nativa.
- ClickHouse: Open source, extremadamente rápido para agregaciones, usado por Cloudflare y Uber.
🔄 ETL y Pipelines
ETL (Extract, Transform, Load) es el proceso de mover datos entre sistemas. Los datos sin procesar salen del origen, se limpian y transforman, y se cargan en el destino. Sin un pipeline confiable, tu Data Warehouse es basura con una interfaz bonita.
🔍 ETL vs. ELT
ETL (clásico)
Transforma antes de cargar. Los datos llegan limpios al destino. Más control, más lento. Herramientas: Airflow, Informatica, Talend.
ELT (moderno)
Carga los datos sin transformar y los transforma en el destino (que tiene capacidad de cómputo). Más rápido, más flexible. Herramientas: dbt, Fivetran + BigQuery.
🔄 Pipeline ETL en 3 etapas
Extract (Extraer)
Recopila datos de las fuentes: API, bases de datos OLTP, archivos CSV, logs, webhooks. El objetivo es capturarlo todo sin perder nada. La carga incremental es mejor que la carga completa.
Transform (Transformar)
Limpia, normaliza, agrega y enriquece los datos. Elimina duplicados, estandariza formatos y calcula métricas derivadas. dbt es la herramienta de referencia para las transformaciones en SQL.
Load (Cargar)
Inserta los datos transformados en el destino (Data Warehouse, Data Lake). Puede ser por lotes (diario/por hora) o en streaming (en tiempo real con Kafka/Kinesis).
💡 Consejo práctico
Empieza con Airflow para orquestar pipelines y dbt para transformaciones SQL. Ambos son de código abierto y el estándar del mercado. Implementa siempre comprobaciones de calidad de datos entre las etapas: los datos defectuosos que se propagan por el pipeline contaminan todo lo que viene después.
📡 Observabilidad
Observabilidad es la capacidad de entender el estado interno de la base de datos a través de señales externas. Los tres pilares: métricas, logs y trazas. Una base de datos sin monitoreo es una bomba de tiempo. Cuando ocurra el incidente —y ocurrirá— necesitas saber dónde buscar.
🎯 Los 3 pilares de la observabilidad
Métricas
Métricas a lo largo del tiempo: latencia p95/p99, throughput (queries/s), conexiones activas, uso de disco, cache hit ratio. pg_stat_statements es esencial.
Logs
Registros de eventos: consultas lentas, errores, deadlocks, autovacuum. Configura log_min_duration_statement para capturar consultas lentas automáticamente.
Trazas
Seguimiento de extremo a extremo de una solicitud: del frontend a la base de datos y de vuelta. Identifica cuellos de botella en toda la cadena. OpenTelemetry es el estándar.
🚨 Fallos comunes de monitoreo
- • Alertas solo para "disco lleno": Cuando se activa la alerta, ya es tarde. Monitorea la tasa de crecimiento, no solo el uso absoluto.
- • Sin baseline: Si no sabes qué es “normal”, no puedes detectar anomalías. Recopila métricas durante semanas antes de definir thresholds.
- • Fatiga por alertas: 200 alertas/día = cero alertas útiles. Prioriza y silencia el ruido. Menos alertas, más acción.
- • Monitorear solo la base de datos: El problema puede estar en la red, en la app o en el connection pool. La observabilidad es de extremo a extremo.
🏛️ Gobernanza
Gobernanza de datos es el marco de políticas, procesos y responsabilidades que garantiza que los datos se traten como un activo estratégico. Sin gobernanza, los datos se convierten en basura costosa. La calidad, la seguridad y el cumplimiento normativo dependen de ella.
🎯 Pilares de la gobernanza
- • Catálogo de datos: Inventario de todos los datasets, tablas, columnas, responsables y descripciones. "¿Qué datos tenemos y dónde están?" DataHub, Amundsen, OpenMetadata.
- • Linaje de datos: Seguimiento del origen y la transformación de los datos. "¿De dónde salió este número del informe?" Esencial para auditoría y depuración.
- • RBAC (control de acceso basado en roles): Cada persona/sistema accede solo a lo que necesita. Principio del menor privilegio. GRANT/REVOKE en PostgreSQL.
- • Clasificación de datos: Público, interno, confidencial, restringido. Cada nivel tiene reglas distintas de acceso, retención y cifrado.
- • Auditoría: Logs de quién accedió a qué, cuándo y por qué. Requisito legal (LGPD/GDPR) y base para investigar incidentes.
💡 Consejo práctico
La gobernanza no tiene que empezar a gran escala. Primer paso: documenta quién es el owner de cada tabla/dataset. Segundo: implementa RBAC básico con roles en la base de datos. Tercero: activa registro de auditoría. Estos tres pasos ya cubren el 80% de lo que piden las auditorías.