OLTP frente a OLAP
Bases de datos transaccionales frente a analíticas.
OLTP frente a OLAP es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué son OLTP y OLAP?
Las bases de datos no sirven para todos los casos por igual. Dos cargas de trabajo fundamentalmente distintas han determinado cómo diseñamos y operamos las bases de datos: OLTP (procesamiento de transacciones en línea) y OLAP (procesamiento analítico en línea).
Comprender la diferencia es esencial para cualquier profesional de datos. La elección correcta entre OLTP y OLAP determina la velocidad de las consultas, el coste del almacenamiento y la arquitectura general del sistema de datos.
OLTP: diseñado para transacciones
Los sistemas OLTP gestionan un gran volumen de operaciones breves y rápidas —inserciones, actualizaciones y eliminaciones que reflejan eventos empresariales en tiempo real—. Algunos ejemplos son realizar un pedido, procesar un pago o actualizar el registro de un cliente.
Las propiedades clave de OLTP son una baja latencia por operación, una alta concurrencia y una consistencia sólida. Cada transacción debe cumplir con ACID para proteger la integridad de los datos.
-- OLTP example: inserting a new order
INSERT INTO orders (customer_id, product_id, quantity, order_date)
VALUES (1042, 88, 3, CURRENT_DATE);
-- Immediately update inventory
UPDATE inventory
SET stock = stock - 3
WHERE product_id = 88;OLAP: diseñado para análisis
Los sistemas OLAP están optimizados para consultas complejas que recorren grandes cantidades de datos históricos con el fin de revelar tendencias, patrones y resúmenes. Los analistas de negocio y los científicos de datos utilizan OLAP para responder preguntas como: «¿Cuáles fueron nuestras ventas totales por región el último trimestre?»
Las consultas OLAP suelen agregar millones de filas e implican varios joins entre tablas de hechos y dimensiones. La velocidad de las escrituras individuales es secundaria; lo importante es el rendimiento de lectura y la flexibilidad de las consultas.
-- OLAP example: total sales by region for Q1 2024
SELECT
d.region,
SUM(f.sales_amount) AS total_sales,
COUNT(f.order_id) AS order_count
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
JOIN dim_store d ON f.store_key = d.store_key
WHERE dd.year = 2024
AND dd.quarter = 1
GROUP BY d.region
ORDER BY total_sales DESC;Comparación directa
La forma más sencilla de recordar la diferencia es pensar en quién utiliza cada sistema y cómo lo utiliza:
- OLTP: lo utilizan los backends de las aplicaciones; miles de usuarios simultáneos; cada consulta afecta a unas pocas filas.
- OLAP: lo utilizan analistas y herramientas de generación de informes; hay menos consultas simultáneas, pero cada una recorre millones de filas.
Estos patrones de acceso opuestos dan lugar a diseños de esquemas, estrategias de indexación e incluso elecciones de hardware muy diferentes.
-- OLTP: lookup a single customer's latest order (row-level access)
SELECT o.order_id, o.order_date, o.total_amount
FROM orders o
WHERE o.customer_id = 1042
ORDER BY o.order_date DESC
LIMIT 1;
-- OLAP: monthly revenue trend over the past year (aggregate scan)
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(total_amount) AS revenue
FROM orders
WHERE order_date >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;Diseño de esquemas: normalizado frente a desnormalizado
Las bases de datos OLTP favorecen los esquemas normalizados (3NF o superior) para eliminar la redundancia y hacer eficientes las escrituras. Cada entidad reside en su propia tabla, lo que reduce la cantidad de datos afectados por cada transacción.
Las bases de datos OLAP favorecen los esquemas desnormalizados, especialmente los esquemas de estrella y de copo de nieve, en los que los datos ya están unidos y son redundantes. Esto elimina las uniones costosas en el momento de consultar y permite que los motores de almacenamiento columnar exploren los datos con mayor rapidez.
-- Normalized OLTP design (3NF)
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
name VARCHAR(100),
email VARCHAR(150) UNIQUE
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE,
total NUMERIC(10,2)
);
-- Denormalized OLAP fact table (star schema)
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
customer_key INT,
date_key INT,
product_key INT,
region VARCHAR(50),
category VARCHAR(50),
amount NUMERIC(12,2)
);Las estrategias de indexación son diferentes
Los sistemas OLTP dependen en gran medida de los índices B-tree en las claves primarias y foráneas para permitir búsquedas rápidas de una sola fila y uniones eficientes dentro de una transacción.
Los sistemas OLAP se benefician de los índices de mapa de bits, el almacenamiento columnar y el particionamiento. Explorar una columna completa (p. ej., todos los importes de ventas) es mucho más eficiente cuando los datos se almacenan por columnas en lugar de por filas.
-- OLTP: B-tree index for fast order lookup by customer
CREATE INDEX idx_orders_customer
ON orders (customer_id);
-- OLTP: compound index for range queries
CREATE INDEX idx_orders_date_customer
ON orders (order_date, customer_id);
-- OLAP: partition fact table by year to prune scan
CREATE TABLE fact_sales_2024
PARTITION OF fact_sales
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');Concurrencia y bloqueo
Los sistemas OLTP deben gestionar miles de escrituras simultáneas sin conflictos. Las bases de datos utilizan el bloqueo a nivel de fila y MVCC (control de concurrencia multiversión) para que las lecturas nunca bloqueen las escrituras y viceversa.
Las consultas OLAP son predominantemente de solo lectura. El bloqueo rara vez supone un problema, pero las exploraciones de larga duración pueden consumir una cantidad considerable de CPU y E/S. La mayoría de los almacenes de datos ejecutan OLAP en un sistema independiente, alimentado mediante ETL por lotes o CDC (captura de datos modificados) desde la fuente OLTP.
-- OLTP: explicit transaction with row-level lock
BEGIN;
SELECT balance
FROM accounts
WHERE account_id = 7
FOR UPDATE;
UPDATE accounts
SET balance = balance - 200
WHERE account_id = 7;
COMMIT;ETL: el puente entre OLTP y OLAP
Como OLTP y OLAP tienen diseños incompatibles, las organizaciones ejecutan procesos ETL (extracción, transformación y carga) para copiar y remodelar los datos de la base de datos transaccional en el almacén analítico según una programación (cada noche, cada hora o casi en tiempo real).
El proceso ETL transforma las filas normalizadas de OLTP en registros desnormalizados de hechos y dimensiones, aplicando lógica de negocio durante el proceso (p. ej., conversión de divisas o segmentación de clientes).
-- Simplified ETL INSERT from OLTP orders into OLAP fact table
INSERT INTO fact_sales (
customer_key,
date_key,
product_key,
amount
)
SELECT
dc.customer_key,
dd.date_key,
dp.product_key,
o.total_amount
FROM orders o
JOIN dim_customer dc ON dc.source_customer_id = o.customer_id
JOIN dim_date dd ON dd.calendar_date = o.order_date
JOIN dim_product dp ON dp.source_product_id = o.product_id
WHERE o.order_date = CURRENT_DATE - INTERVAL '1 day'
AND o.order_id NOT IN (SELECT source_order_id FROM fact_sales);Patrones habituales de consulta OLAP
Las consultas OLAP casi siempre incluyen agregaciones (SUM, COUNT, AVG), agrupaciones en varias dimensiones y filtrado por intervalos de fechas o categorías. Estos son los componentes básicos de los paneles y los informes empresariales.
Las funciones de ventana son especialmente potentes en las cargas de trabajo OLAP: permiten comparar las cifras de cada período con las del período anterior sin una autounión.
-- Year-over-year revenue comparison using a window function
SELECT
dd.year,
dd.quarter,
SUM(f.amount) AS revenue,
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year) AS prev_year_revenue,
ROUND(
100.0 * (SUM(f.amount) -
LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year))
/ NULLIF(LAG(SUM(f.amount)) OVER (PARTITION BY dd.quarter
ORDER BY dd.year), 0)
, 2) AS yoy_pct_change
FROM fact_sales f
JOIN dim_date dd ON f.date_key = dd.date_key
GROUP BY dd.year, dd.quarter
ORDER BY dd.quarter, dd.year;HTAP: desdibujando las fronteras
Los sistemas modernos como TiDB, SingleStore y PostgreSQL + extensiones columnares implementan HTAP (procesamiento híbrido transaccional y analítico). Su objetivo es gestionar ambas cargas de trabajo en un único motor y evitar la complejidad operativa de mantener sistemas OLTP y OLAP independientes.
HTAP lo consigue almacenando los datos simultáneamente en dos formatos: un almacén orientado a filas para las escrituras transaccionales y un almacén orientado a columnas para las lecturas analíticas, ambos sincronizados automáticamente.
-- PostgreSQL with cstore_fdw (columnar extension) example
-- Analytical table stored in columnar format
CREATE FOREIGN TABLE fact_sales_columnar (
date_key INT,
product_key INT,
region VARCHAR(50),
amount NUMERIC(12,2)
)
SERVER cstore_server
OPTIONS (filename '/data/fact_sales_columnar');
-- Regular OLTP table remains row-based
-- Both can be queried in the same SQL statement
SELECT f.region, SUM(f.amount)
FROM fact_sales_columnar f
GROUP BY f.region;Elegir el sistema adecuado
La decisión entre OLTP y OLAP (o HTAP) depende de su carga de trabajo principal:
- Si está desarrollando una aplicación que registra eventos en tiempo real, use una base de datos OLTP (PostgreSQL, MySQL, SQL Server).
- Si está desarrollando una capa de informes sobre datos históricos, use un almacén OLAP (BigQuery, Redshift, Snowflake, ClickHouse).
- Si necesita ambas cosas y desea simplificar las operaciones, evalúe las opciones HTAP.
Muchas arquitecturas de producción utilizan ambos: una base de datos OLTP como sistema de registro y un almacén de datos independiente para análisis, conectados mediante un proceso ETL.
-- Quick diagnostic: check table access pattern
-- High seq_scan relative to idx_scan = analytical (OLAP-like) load
SELECT
relname AS table_name,
seq_scan,
idx_scan,
n_live_tup AS live_rows
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 10;Comprobación de conocimientos
Compruebe su comprensión de las diferencias clave entre los sistemas OLTP y OLAP.
Resumen de la lección
OLTP frente a OLAP: conclusiones clave:
- OLTP gestiona cargas de trabajo transaccionales en tiempo real: escrituras rápidas y simultáneas a nivel de fila con garantías ACID.
- OLAP gestiona cargas de trabajo analíticas: agregaciones complejas sobre grandes conjuntos de datos históricos mediante esquemas desnormalizados.
- El diseño del esquema depende de la carga de trabajo: normalizado (3NF) para OLTP y de estrella o de copo de nieve para OLAP.
- Los procesos ETL conectan ambos sistemas y cargan los datos OLTP transformados en el almacén analítico.
- Los sistemas HTAP intentan atender ambas cargas de trabajo desde un único motor mediante almacenamiento dual por filas y por columnas.
Elegir la arquitectura adecuada desde el principio evita migraciones problemáticas más adelante y garantiza que las consultas se ejecuten con la velocidad que esperan sus usuarios.
Preguntas frecuentes
¿La lección «OLTP frente a OLAP» es gratis?
Sí — el texto completo de «OLTP frente a OLAP» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Academy, actualiza a CoddyKit PRO. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué aprenderé en «OLTP frente a OLAP»?
Bases de datos transaccionales frente a analíticas. Practicas SQL Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Academy?
No se requiere experiencia previa. SQL Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «OLTP frente a OLAP»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Academy?
Sí. Cada lección de SQL Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- OLTP frente a OLAP
- Tablas de hechos y dimensiones
- Esquemas de estrella y copo de nieve
- Escritura de consultas analíticas