Deep EVM #26: Sharding vs Particionamiento — Arquitectura para Tablas Masivas

Particionamiento vs Sharding

Aunque a menudo se confunden, particionamiento y sharding son conceptos diferentes:

• Particionamiento: dividir una tabla en múltiples tablas físicas dentro del mismo servidor de base de datos
• Sharding: distribuir datos entre múltiples servidores de base de datos

El particionamiento es más simple pero tiene un techo: un solo servidor. El sharding escala horizontalmente pero introduce complejidad distribuida.

Cuándo escalar verticalmente vs horizontalmente

Escenario	Solución
Tabla de 50M filas, lecturas lentas	Particionamiento
500M filas, un solo servidor al límite	Sharding
Escrituras saturan I/O del disco	Sharding
Diferentes regiones necesitan baja latencia	Sharding geográfico
Datos temporales con retención	Particionamiento por rango + DROP

Estrategias de clave de sharding

La clave de sharding determina en qué servidor se almacena cada fila:

Hash-based sharding

shard = hash(key) % num_shards

Distribuye uniformemente pero dificulta range queries.

Range-based sharding

shard_0: block 0-999999
shard_1: block 1000000-1999999

Perfecto para datos temporales, pero puede crear hotspots.

Directory-based sharding

Un servicio centralizado mapea claves a shards. Flexible pero añade latencia.

Implementación con Citus

Citus es la extensión de PostgreSQL más popular para sharding:

-- En el nodo coordinador
SELECT create_distributed_table('transactions', 'address');

-- Las queries se enrutan automáticamente
SELECT * FROM transactions WHERE address = '0xABC...';
-- Se ejecuta solo en el shard correcto

Consistencia entre shards

El mayor desafío del sharding es mantener la consistencia:

• Transacciones cross-shard: requieren two-phase commit (2PC)
• Joins entre shards: se ejecutan en el coordinador, potencialmente lento
• Agregaciones globales: requieren scatter-gather a todos los shards

Patrón de migración gradual

1. Comenzar con particionamiento local
2. Cuando un servidor no es suficiente, migrar a Citus
3. Añadir nodos worker incrementalmente
4. Re-balancear datos automáticamente

Conclusión

Particionamiento y sharding son herramientas complementarias. Comienza con particionamiento local, que es simple y efectivo. Escala a sharding solo cuando los límites de un solo servidor se alcanzan. Citus facilita la transición manteniendo la compatibilidad con PostgreSQL estándar.