Sharding de bases de datos - Escalamiento horizontal mediante particionamiento

¿Qué es el sharding?

El sharding es una técnica que divide horizontalmente los datos y los almacena en múltiples bases de datos (shards). Permite manejar grandes cantidades de datos y tráfico que una sola base de datos no podría procesar.

Diferencia con la replicación: La replicación mantiene copias de los mismos datos en múltiples servidores, mientras que el sharding distribuye datos diferentes en diferentes servidores.

Funcionamiento del sharding

flowchart TB
    subgraph Before["Antes del sharding"]
        Single["Base de datos única<br/>Todos los datos de usuarios<br/>(100 millones de registros)"]
    end

flowchart LR
    subgraph After["Después del sharding"]
        S0["Shard 0<br/>Usuarios A-F<br/>25 millones"]
        S1["Shard 1<br/>Usuarios G-L<br/>25 millones"]
        S2["Shard 2<br/>Usuarios M-R<br/>25 millones"]
        S3["Shard 3<br/>Usuarios S-Z<br/>25 millones"]
    end

Métodos de sharding

Sharding basado en rangos

Determina el shard por el rango de la clave.

Ventaja: Las consultas por rango son eficientes Desventaja: Fácilmente se produce desequilibrio de datos

Sharding basado en hash

Determina el shard por el valor hash de la clave.

shard_id = hash(user_id) % num_shards

Ventaja: Los datos se distribuyen uniformemente Desventaja: Las consultas por rango son ineficientes

Sharding basado en directorio

Determina el shard mediante una tabla de búsqueda.

Ventaja: Mapeo flexible Desventaja: Sobrecarga de búsqueda

Cómo elegir la clave de shard

La clave de shard es el elemento más importante que determina el éxito del sharding.

Condiciones de una buena clave de shard

• ✓ Alta cardinalidad (tiene valores diversos)
• ✓ Se ajusta al patrón de acceso
• ✓ Las escrituras se distribuyen uniformemente
• ✓ La clave está incluida en la mayoría de las consultas

Ejemplos de claves de shard

Problema de hotspots

Consultas cross-shard

Las consultas que abarcan múltiples shards se vuelven complejas.

Scatter-Gather

flowchart TB
    Client["Cliente"] --> Router["Router"]
    Router -->|"Scatter<br/>(Consulta a todos los shards)"| S0["S0"]
    Router --> S1["S1"]
    Router --> S2["S2"]
    Router --> S3["S3"]
    S0 -->|"Gather<br/>(Agregar resultados)"| Router
    S1 --> Router
    S2 --> Router
    S3 --> Router
    Router --> Client

Limitaciones de JOIN

-- Dentro del mismo shard: JOIN normal
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.id = 123;  -- Incluye la clave de shard

-- Cross-shard: Unir en el lado de la aplicación
-- 1. Obtener datos de la tabla users
-- 2. Obtener datos de la tabla orders
-- 3. JOIN en el lado de la aplicación

Rebalanceo

Es el trabajo de redistribuir datos entre shards.

Situaciones que lo requieren

• Agregar/eliminar shards
• Resolver desequilibrio de datos
• Optimización del rendimiento

Consistent hashing

Técnica que minimiza los datos que se mueven cuando cambia el número de shards.

Desafíos del sharding

Sharding administrado

Criterios de decisión para sharding

Cuando el sharding es necesario:

• Se excede el límite de capacidad de una sola BD
• El throughput de escritura está al límite
• El costo del escalamiento vertical es demasiado alto

Alternativas a considerar primero:

• Agregar réplicas de lectura
• Introducir caché
• Optimización de consultas
• Revisión de índices
• Migración a una instancia más grande

Resumen

El sharding es una técnica poderosa para lograr el escalamiento horizontal de bases de datos, pero también conlleva complejidad. La selección de la clave de shard es la clave del éxito, y se debe decidir su implementación después de analizar suficientemente los patrones de acceso. Si es posible, considerar el uso de servicios administrados puede reducir la carga operativa.