Concepto clave

La arquitectura de PostgreSQL para alta concurrencia se basa en un modelo de procesos por conexión y un sistema de control de concurrencia multiversión (MVCC). Imagina una biblioteca donde cada lector (proceso) tiene su propia copia temporal de las páginas que está consultando, permitiendo que múltiples personas lean simultáneamente sin bloquearse, mientras los escritores actualizan copias separadas que se sincronizan cuidadosamente.

PostgreSQL maneja la concurrencia mediante snapshots que capturan el estado de la base de datos en un momento dado, y transacciones que aseguran aislamiento. Esto es crucial para aplicaciones como plataformas de comercio electrónico donde miles de usuarios pueden estar viendo productos y realizando compras al mismo tiempo, sin que las lecturas interfieran con las escrituras.

Cómo funciona en la práctica

Cuando una aplicación con alta concurrencia, como un sistema de reservas de vuelos, ejecuta múltiples transacciones simultáneas, PostgreSQL asigna un proceso separado para cada conexión. Cada transacción ve una versión consistente de los datos gracias al MVCC, que mantiene múltiples versiones de las filas. Por ejemplo, si un usuario está actualizando un asiento mientras otro lo consulta, el segundo verá la versión anterior hasta que la transacción se complete.

Paso a paso: 1) Un cliente se conecta y PostgreSQL crea un nuevo proceso backend. 2) El proceso inicia una transacción y toma un snapshot. 3) Las lecturas acceden a las versiones de filas visibles en ese snapshot. 4) Las escrituras crean nuevas versiones de filas, marcando las antiguas para limpieza posterior. 5) Al commit, los cambios se hacen visibles para nuevas transacciones.

Código en acción

Ejemplo de configuración para alta concurrencia en postgresql.conf:

-- Aumentar el número máximo de conexiones concurrentes
max_connections = 200

-- Ajustar la memoria compartida para manejar más procesos
shared_buffers = 4GB

-- Optimizar el trabajo de autovacuum para mantener el MVCC eficiente
autovacuum_max_workers = 3
autovacuum_vacuum_scale_factor = 0.05

-- Configurar el tiempo de espera para evitar conexiones colgadas
idle_in_transaction_session_timeout = '10min'

Ejemplo de transacción con aislamiento REPEATABLE READ para consistencia:

-- Antes: Lectura inconsistente bajo alta concurrencia
BEGIN;
SELECT asientos_disponibles FROM vuelos WHERE id = 123; -- Podría cambiar antes del UPDATE
UPDATE vuelos SET asientos_disponibles = asientos_disponibles - 1 WHERE id = 123;
COMMIT;

-- Después: Usar REPEATABLE READ para snapshot consistente
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT asientos_disponibles FROM vuelos WHERE id = 123; -- Snapshot fijo
UPDATE vuelos SET asientos_disponibles = asientos_disponibles - 1 WHERE id = 123;
COMMIT;

Errores comunes

Configurar max_connections demasiado alto: Esto puede agotar la memoria y degradar el rendimiento. En su lugar, usa connection pooling como PgBouncer.
Ignorar autovacuum: Sin un mantenimiento adecuado, el MVCC acumula versiones muertas, causando bloat y lentitud. Monitoriza con pg_stat_user_tables.
Usar niveles de aislamiento incorrectos: READ COMMITTED puede causar non-repeatable reads en alta concurrencia. Evalúa si necesitas REPEATABLE READ o SERIALIZABLE.
No limitar transacciones largas: Las transacciones que duran mucho retienen snapshots y bloquean la limpieza. Configura timeouts como idle_in_transaction_session_timeout.
Olvidar índices en condiciones WHERE: En alta concurrencia, las consultas sin índices causan sequential scans que bloquean tablas. Usa EXPLAIN ANALYZE para identificar cuellos de botella.

Checklist de dominio

¿Has configurado max_connections basado en los recursos del servidor y usado connection pooling?
¿Monitorizas regularmente el bloat de tablas y ajustas autovacuum parameters?
¿Seleccionas el nivel de aislamiento de transacción apropiado para tu caso de uso?
¿Has implementado timeouts para prevenir transacciones colgadas?
¿Optimizas índices para consultas concurrentes frecuentes?
¿Usas EXPLAIN ANALYZE para analizar el impacto de consultas bajo carga?
¿Probaste la configuración con herramientas de estrés como pgbench?

Optimización de una tabla de pedidos para alta concurrencia

En este ejercicio, mejorarás una tabla de pedidos en una aplicación de e-commerce que experimenta picos de 100+ transacciones por segundo.

Crea una tabla de ejemplo:

CREATE TABLE pedidos (
    id SERIAL PRIMARY KEY,
    usuario_id INT,
    monto DECIMAL(10,2),
    estado VARCHAR(20),
    creado_en TIMESTAMP DEFAULT NOW()
);

Simula alta concurrencia insertando 10,000 filas con pgbench o un script.

Identifica problemas ejecutando consultas concurrentes de actualización y lectura. Usa:

-- En una sesión
BEGIN;
UPDATE pedidos SET estado = 'procesado' WHERE id = 1;
-- En otra sesión simultánea
SELECT * FROM pedidos WHERE id = 1;

Optimiza la tabla:
- Añade índices a usuario_id y estado si son usados en WHERE.
- Ajusta los parámetros de autovacuum para la tabla.
- Cambia el nivel de aislamiento a REPEATABLE READ si es necesario.
Mide la mejora comparando tiempos de ejecución antes y después.

Pistas

Usa pg_stat_user_tables para ver n_live_tups y n_dead_tups después de la carga concurrente.
Considera usar índices parciales si solo ciertos estados son consultados frecuentemente.
Prueba con pgbench para simular múltiples clientes ejecutando transacciones.

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.

Arquitectura de PostgreSQL para Alta Concurrencia