Consultas entre fragmentos: el problema difícil
Comprenda por qué las combinaciones y transacciones entre fragmentos son el problema más difícil de las bases de datos distribuidas, así como los patrones que las minimizan.
Consultas entre fragmentos: el problema difícil es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 2 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.
El coste del sharding
El sharding permite escalar las escrituras y la capacidad, pero dificulta las consultas que abarcan varios shards: cada consulta entre shards requiere expandir la consulta.
Las consultas en un solo shard son sencillas
Si la clave del shard aparece en la cláusula WHERE, el enrutador envía una consulta a un único shard:
-- shard_id = hash(user_id) % N
SELECT * FROM orders WHERE user_id = 42;
-- Router computes shard, sends one query, gets one result.Consultas con expansión
Sin la clave del shard, el enrutador consulta todos los shards y combina los resultados:
-- WHERE status = 'paid' — no user_id
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100;
-- Must query all N shards, merge results, sort, take top 100.Agregaciones con expansión
Para COUNT/SUM/AVG: obtenga resultados parciales de cada shard y combínelos después en el enrutador o en la aplicación:
-- On each shard:
SELECT COUNT(*), SUM(total) FROM orders;
-- Aggregator:
final_count = SUM(counts), final_sum = SUM(sums)
-- AVG is trickier — need SUM and COUNT, can't average averages.JOIN entre shards
Si ambos lados están fragmentados con la misma clave (están ubicados conjuntamente), el JOIN es local al shard. De lo contrario, resulta prácticamente imposible a escala.
Tablas de referencia (replicadas en todas partes)
Las tablas pequeñas de «búsqueda» se replican en cada shard, por lo que los JOIN con ellas permanecen locales. Citus las denomina «tablas de referencia».
Cómo evitar patrones entre shards
Técnicas de diseño del esquema:
- Desnormalice: duplique los datos del padre en el shard que contiene al hijo
- Use la clave del shard en todas partes, incluso cuando parezca «innecesario»
- Calcule previamente los informes en una base de datos de análisis independiente
Paginación entre shards
Usar OFFSET 1000 LIMIT 10 en muchos shards es terrible: cada shard debe producir 1010 filas. Use paginación basada en claves.
Transacciones distribuidas
El compromiso en dos fases (2PC) coordina los commits atómicos entre shards. Es lento y frágil durante una partición. En la práctica, diseñe el sistema para utilizar patrones de «saga»:
// Saga pattern (conceptual):
// 1. Local TX on shard A: mark as pending, log
// 2. RPC to shard B: do its part
// 3. Local TX on shard A: mark as committed
// 4. On failure: compensating transactionsShards saturados
Un usuario famoso o un producto viral pueden concentrar el tráfico en un shard y echar por tierra la estrategia de escalado. Detecte el problema y divídalo (subsharding) o muévalo.
Claves foráneas entre shards
Las claves foráneas de los RDBMS no abarcan varios shards. Puede aplicar la integridad referencial en la aplicación o aceptar la consistencia eventual en las relaciones entre shards.
Resumen
El sharding desplaza la dificultad de «escalar las escrituras» a «dar forma a las consultas para que permanezcan locales al shard».
- Las consultas en un solo shard son rápidas
- La expansión es lenta
- Desnormalice para mantener el trabajo local
- Use tablas de referencia para dimensiones compartidas
- Use sagas en lugar de 2PC
Comprobación rápida
¿Por qué un SELECT sin la clave del shard en WHERE resulta costoso en una base de datos fragmentada?
Preguntas frecuentes
¿La lección «Consultas entre fragmentos: el problema difícil» es gratis?
Sí — el texto completo de «Consultas entre fragmentos: el problema difícil» 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 «Consultas entre fragmentos: el problema difícil»?
Comprenda por qué las combinaciones y transacciones entre fragmentos son el problema más difícil de las bases de datos distribuidas, así como los patrones que las minimizan. 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 2 de 4.
¿Cuánto tiempo toma la lección «Consultas entre fragmentos: el problema difícil»?
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