Sharding

Resumen

Sharding es una forma de particionamiento horizontal donde los fragmentos —shards— residen en servidores distintos. Cada shard es una base de datos independiente que contiene un subconjunto de los datos. Un user con ID 42 va al shard 2; un user con ID 105 va al shard 4, según una función de sharding —hash modular, rango, directorio—.

Importa porque es la estrategia definitiva para escalar bases de datos más allá de los límites físicos de una máquina. Cuando una base de datos crece a terabytes y el servidor más grande del mercado no alcanza, shardear es la respuesta.

Pero sharding es complejo. Las queries que cruzan shards —«todos los usuarios con más de 100 órdenes»— requieren consultar todos los shards y mergear resultados. Los JOINs entre datos de distintos shards son imposibles. Las transacciones ACID entre shards requieren protocolos como Two-Phase Commit.

Alcance y supuestos

Cubre sharding como estrategia de escalabilidad, elección de clave de shard y limitaciones. Asume familiaridad con bases de datos distribuidas.

Modelo mental

Una biblioteca universitaria con varias sedes. Los libros de ingeniería están en la sede de ingeniería, los de medicina en la de medicina. Si buscás un libro específico, el sistema te dice a qué sede ir. Pero si querés «todos los libros publicados en 2020», tenés que consultar todas las sedes.

Uso práctico

• ✅ Datos que crecen a escala que ninguna máquina puede manejar.
• ❌ Aplicaciones con muchas queries entre shards —shardear el dato incorrecto es peor que no shardear—.

Ejemplo trabajado: shardear por tenant

Una plataforma multi-tenant shardea por tenant_id. Los datos del tenant 42 viven en el shard B. Una query SELECT * FROM orders WHERE tenant_id = 42 toca un solo shard —rápido—. Una query de analytics entre tenants debe consultar todos los shards.

Evidencia

• MongoDB, Cassandra, Vitess y Citus implementan sharding. La elección de la clave de shard es la decisión más crítica del diseño.