Estrategias de fragmentación: rango, hash y directorio
Compare la fragmentación por rango, hash y directorio, y elija una clave de fragmentación que equilibre la carga y se mantenga estable.
Estrategias de fragmentación: rango, hash y directorio es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué es el sharding?
Dividir una base de datos lógica entre varios servidores físicos («shards»), cada uno de los cuales contiene un subconjunto de los datos. Se hace cuando un solo servidor ya no puede gestionar la carga de trabajo.
El sharding ≠ la replicación
- Replicación: los mismos datos en varios servidores (para alta disponibilidad y escalado de lecturas)
- Sharding: datos diferentes en servidores diferentes (para escalar las escrituras y la capacidad)
A menudo se combinan ambos enfoques: cada shard se replica para lograr alta disponibilidad.
Tres estrategias de sharding
- Por rangos: dividir por rangos de valores (los ID del 1 al 1M en el shard A y del 1M al 2M en el shard B)
- Por hash: aplicar un hash a la clave del shard y calcular el módulo N
- Por directorio: una tabla independiente asigna cada clave a un shard
Sharding por rangos
Es sencillo y funciona bien para series temporales e identificadores ordenados. Riesgo: que se produzcan shards saturados si todo el tráfico se concentra en los datos recientes.
-- Conceptually:
-- Shard A: user_id 1 - 1,000,000
-- Shard B: user_id 1,000,001 - 2,000,000
-- Shard C: user_id 2,000,001 - 3,000,000Sharding por hash
Ofrece una distribución uniforme de forma predeterminada. Añadir shards es difícil (al volver a fragmentar, se mueven todas las claves):
-- shard_id = hash(user_id) % N
-- N=4: any user_id evenly distributed across 4 shardsSharding por directorio
Una tabla de búsqueda asigna cada clave a su shard:
CREATE TABLE shard_routing (
user_id BIGINT PRIMARY KEY,
shard_id INT NOT NULL
);
-- Looking up a user costs a directory query first; cache it.Hashing consistente
El hashing mediante módulo es frágil al añadir shards. El hashing consistente minimiza las claves que deben moverse:
-- Each shard owns a ring segment.
-- Adding a new shard moves only ~1/N of the keys.Cómo elegir una clave de shard
La clave del shard lo determina todo. Las buenas claves de shard:
- Distribuyen los datos de manera uniforme
- Están presentes en la mayoría de las consultas (evitan la expansión entre shards)
- Son inmutables (o cambian muy pocas veces)
<p>Common picks: user_id, tenant_id, customer_id. Avoid: timestamps for write-heavy workloads (creates hot shards).</p>Un tenant por shard
En un SaaS multiinquilino, cada tenant se aloja en un shard dedicado. Es sencillo de comprender y facilita aislar los tenants que generan una carga excesiva.
Diseño preparado para volver a fragmentar
Diseñe teniendo en cuenta una futura redistribución:
- Use shards virtuales (por ejemplo, 1024 lógicos asignados a shards físicos)
- Facilite la migración de un shard lógico a otro servidor físico
- Evite el código de la aplicación que establezca el número de shards de forma fija
Consultas entre shards
Es el problema más difícil. Los JOIN y los informes entre shards requieren expandir la consulta y agregar la lógica en la aplicación. Se tratará en la próxima lección.
Transacciones entre shards
Las transacciones atómicas entre shards requieren un compromiso en dos fases (2PC) o sagas. El consejo habitual es diseñar el sistema para que las transacciones permanezcan dentro de un solo shard.
Resumen
Hay tres estrategias; elija según la forma del tráfico.
- Por rangos: sencilla, con riesgo de shards saturados
- Por hash: uniforme, pero rígida
- Por directorio: flexible, pero añade latencia
- Hashing consistente para volver a fragmentar de forma gradual
Comprobación rápida
Divide una tabla de usuarios mediante hash(user_id). Pasa de 4 shards a 5. ¿Cuántas claves deben moverse?
Preguntas frecuentes
¿La lección «Estrategias de fragmentación: rango, hash y directorio» es gratis?
Sí — el texto completo de «Estrategias de fragmentación: rango, hash y directorio» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Academy, actualiza a CoddyKit PRO. El curso de SQL Academy incluye 4 lecciones en total.
¿Qué aprenderé en «Estrategias de fragmentación: rango, hash y directorio»?
Compare la fragmentación por rango, hash y directorio, y elija una clave de fragmentación que equilibre la carga y se mantenga estable. Practicas SQL Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Academy?
No se requiere experiencia previa. SQL Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.
¿Cuánto tiempo toma la lección «Estrategias de fragmentación: rango, hash y directorio»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Academy?
Sí. Cada lección de SQL Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Estrategias de fragmentación: rango, hash y directorio
- Consultas entre fragmentos: el problema difícil
- Citus y Postgres distribuido
- Cuándo NO fragmentar