# OLAP y OLTP

> Dos trabajos de una base de datos: muchas transacciones chicas o pocas preguntas enormes.

- Nivel: Avanzado
- Temas: Datos
- URL: https://tidbit.legios.com.ar/es/olap-and-oltp/
- En inglés: [OLAP and OLTP](https://tidbit.legios.com.ar/olap-and-oltp/)

**OLTP** (procesamiento de transacciones en línea) es el trabajo que hay detrás de una app mientras la gente la usa: creá este pedido, cobrá esta tarjeta, actualizá esta dirección. Cada operación toca unas pocas filas, hay miles por segundo, y cada una tiene que salir bien aunque dos pasen al mismo tiempo. Bases como PostgreSQL, MySQL, Amazon RDS o DynamoDB están hechas para esto, y suelen guardar los datos fila por fila, con índices para encontrar un registro rápido.

**OLAP** (procesamiento analítico en línea) es el trabajo de hacerle preguntas grandes a toda esa historia: facturación por región y por mes de los últimos cinco años, o qué productos se compran juntos. Una sola consulta lee millones o miles de millones de filas pero pocas columnas, y a nadie le molesta esperar unos segundos. Los data warehouses como Snowflake, BigQuery o Amazon Redshift están hechos para esto: guardan los datos columna por columna (como los archivos Parquet), así cada consulta lee solo lo que necesita y todo se comprime bien.

Los dos se mantienen separados a propósito. Correr un reporte pesado en la base OLTP de producción puede trabar el checkout de clientes reales, y un warehouse en columnas es torpe para actualizar una fila por vez. Por eso los datos se copian de los sistemas OLTP a uno OLAP con ETL o streaming. Algunos sistemas más nuevos, llamados **HTAP**, intentan hacer las dos cosas, pero la separación sigue siendo el diseño habitual en la mayoría de las empresas.

## Una analogía

La caja del supermercado contra la oficina central. La caja atiende a un cliente por vez, rápido y sin errores; la oficina mira un año de tickets para decidir qué comprar. No querés que la oficina haga su análisis anual en la caja.

## Para quedarse

- OLTP: muchas lecturas y escrituras chicas, guardado por filas, exactitud bajo carga.
- OLAP: pocas consultas grandes sobre la historia, guardado en columnas, agregaciones.
- Los datos pasan de los sistemas OLTP a un warehouse OLAP con ETL o streaming.
- Separarlos protege a la app en vivo de los reportes pesados.

## Para seguir leyendo

- [OLAP y OLTP: diferencias (AWS)](https://aws.amazon.com/es/compare/the-difference-between-olap-and-oltp/)
- [OLAP en Wikipedia](https://es.wikipedia.org/wiki/OLAP)
- [OLTP en Wikipedia](https://es.wikipedia.org/wiki/OLTP)

## Términos relacionados

- [Amazon RDS](https://tidbit.legios.com.ar/es/amazon-rds/): Una base de datos relacional lista para usar, que AWS mantiene parchada y respaldada.
- [Amazon DynamoDB](https://tidbit.legios.com.ar/es/amazon-dynamodb/): Una base de datos clave-valor que responde en milisegundos por más que crezca la tabla.
- [Índice de base de datos](https://tidbit.legios.com.ar/es/database-index/): Un atajo ordenado para que la base encuentre filas sin leer toda la tabla.
- [Regiones y zonas de disponibilidad](https://tidbit.legios.com.ar/es/regions-and-availability-zones/): Dónde vive AWS físicamente: ciudades del mundo, cada una con varios centros de datos.
- [Data warehouse](https://tidbit.legios.com.ar/es/data-warehouse/): Una base hecha para analizar: años de historia, de muchas fuentes, en un solo lugar.
- [Amazon Redshift](https://tidbit.legios.com.ar/es/amazon-redshift/): El data warehouse de AWS: SQL sobre tablas enormes, pensado para analizar, no para apps.
- [Parquet](https://tidbit.legios.com.ar/es/parquet/): Un formato que guarda tablas por columna y comprimidas, para que analizar lea mucho menos.
- [ETL](https://tidbit.legios.com.ar/es/etl/): Sacar datos de sus fuentes, limpiarlos y cargarlos donde se puedan analizar.