Cuándo NO fragmentar
Las réplicas de lectura, el particionado y las máquinas más grandes resuelven la mayoría de los problemas de escalabilidad; aprenda cuándo la fragmentación es la respuesta equivocada.
Cuándo NO fragmentar es una lección gratuita de SQL Academy en CoddyKit. Esta es la lección 4 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 sharding es el último recurso
El sharding multiplica la complejidad operativa. La mayoría de las aplicaciones nunca lo necesitan. Agote primero las opciones más sencillas.
Paso 1: escalado vertical
Una máquina más grande. Las instancias modernas en la nube gestionan fácilmente:
- 128 núcleos
- 1 TB de RAM
- 50.000 IOPS en NVMe
Eso equivale a entre 100.000 y 500.000 QPS en un solo nodo de Postgres. La mayoría de las aplicaciones funcionan cómodamente con esa capacidad.
Paso 2: réplicas de lectura
Si predominan las lecturas, añada réplicas. Un primario y 3 réplicas pueden atender 10 veces más lecturas.
Paso 3: almacenamiento en caché
Coloque Redis/memcached delante de las consultas de acceso frecuente. A menudo es la mejora más económica.
Paso 4: particionamiento
El particionamiento declarativo nativo de PG resuelve el problema de una «tabla demasiado grande» dentro de un solo servidor. A menudo es 100 veces más sencillo que el sharding.
Paso 5: separar los servicios
Mueva cada dominio a una base de datos diferente: base de datos de pedidos, de usuarios y de análisis. Cada una puede escalar de forma independiente.
Paso 6: sacar los análisis
Consultas OLTP → Postgres. Consultas analíticas → ClickHouse / BigQuery / Snowflake. Muchas historias de «necesitamos hacer sharding» son en realidad «los análisis están consumiendo nuestro OLTP».
Después, quizá, sharding
Si sigue quedándose sin capacidad con 50 TB de datos exclusivamente OLTP y la carga de trabajo exige más escrituras de las que puede gestionar un solo servidor, empiece a planificar los shards.
Coste operativo del sharding
- Más servidores que supervisar y actualizar
- Las copias de seguridad de los shards deben coordinarse
- Las consultas entre shards pasan a la aplicación
- Volver a fragmentar es difícil
- Los shards saturados requieren un reequilibrado activo
La estrategia de «fragmentar tarde»
Desarrolle el sistema con patrones compatibles con el sharding (incluya siempre tenant_id y no use nunca contadores con incremento global) para poder fragmentarlo más adelante. Pero no haga sharding hasta que sea imprescindible.
Esquema preparado para sharding
Aunque mantenga un solo nodo, diseñe el sistema como si pudiera fragmentarlo:
- tenant_id en cada fila
- UUID o identificadores distribuidos (no autoincrementales)
- Ninguna secuencia con unicidad global
- Claves foráneas dentro del ámbito de un tenant
Reconozca la contrapartida
El sharding aumenta la capacidad a costa de reducir las posibilidades. Los JOIN, las transacciones y las consultas se vuelven más difíciles. Asegúrese de que la mejora compensa el coste.
Resumen
El sharding resuelve un problema real, pero es una solución pesada.
- Empiece por el escalado vertical
- Réplicas de lectura y almacenamiento en caché
- Particionamiento antes que sharding
- Saque los análisis del OLTP
- Diseñe para poder fragmentar y posponga la fragmentación real
Comprobación rápida
Está considerando hacer sharding porque las consultas OLTP son lentas. Antes de fragmentar, ¿qué paso tiene más probabilidades de ayudar?
Preguntas frecuentes
¿La lección «Cuándo NO fragmentar» es gratis?
Sí — el texto completo de «Cuándo NO fragmentar» 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 «Cuándo NO fragmentar»?
Las réplicas de lectura, el particionado y las máquinas más grandes resuelven la mayoría de los problemas de escalabilidad; aprenda cuándo la fragmentación es la respuesta equivocada. 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 4 de 4.
¿Cuánto tiempo toma la lección «Cuándo NO fragmentar»?
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