Decisión: ¿qué estrategia de particionamiento?
El particionamiento divide una tabla grande en varias piezas físicas bajo un único nombre lógico, lo que facilita eliminar datos antiguos y permite a las consultas mirar solo las piezas relevantes (partition pruning). Sin embargo, en tablas pequeñas solo añade complejidad. Este árbol cuestiona primero si el particionamiento es realmente necesario y luego le orienta entre Range, List, Hash y Composite según los patrones de acceso y distribución.
¿La tabla es realmente lo bastante grande como para necesitar particionamiento?
El particionamiento no es magia de rendimiento; es una herramienta de escala y mantenimiento (ciclo de vida). Si la tabla no es lo bastante grande o las consultas ya rinden bien con índices, el particionamiento solo aporta complejidad en los planes y sobrecarga de gestión. ¿Su tabla alcanza decenas de millones o más de filas/cientos de GB, o sigue siendo pequeña/mediana?
- Sí, es muy grande y/o hay que borrar/archivar datos antiguos de forma masiva
- No, tabla pequeña/mediana, o no estoy seguro
¿Cómo accede a los datos y cómo deben dividirse?
La clave de partición debe ser la columna por la que filtran la mayoría de las consultas; solo así se activa el pruning. ¿Cuál es el patrón de acceso predominante? ¿Por fechas/rangos secuenciales (últimos 30 días), por valores concretos de categoría/región, o no hay un filtro claro y quiere repartir la carga de forma uniforme?
- Rangos secuenciales como fecha/número de secuencia (últimos X días, por mes)
- Conjuntos de valores discretos como categoría/región/tenant
- Sin rango/categoría claros; el objetivo es repartir la carga de forma uniforme
- Fecha y gran volumen a la vez; hay que dividir en dos dimensiones
Recomendación: no particionar (todavía)
El particionamiento no aporta ningún beneficio en tablas pequeñas/medianas; bastan índices bien elegidos y el mantenimiento normal. El particionamiento prematuro complica los planes de consulta, pierde el pruning con una clave equivocada y añade sobrecarga operativa.
Recomendación: particionamiento por rango (Range)
El particionamiento por rango divide las filas por rangos secuenciales de una columna (p. ej. rangos de fechas: una partición por mes/trimestre). Es la estrategia más común y potente para series temporales y tablas en crecimiento continuo.
Recomendación: particionamiento por lista (List)
El particionamiento por lista agrupa las filas por valores discretos y conocidos de una columna (p. ej. region = 'TR','EU','US' o el ID de tenant). Cuando existen categorías naturales y finitas, hace que el acceso y la gestión sean claros.
Recomendación: particionamiento Hash (distribución uniforme)
El particionamiento hash distribuye las filas de forma relativamente uniforme entre un número predefinido de particiones según el hash de la columna clave. Se usa para evitar puntos calientes y equilibrar la carga cuando no hay un rango/categoría natural.
Recomendación: particionamiento compuesto (Composite, multinivel)
El particionamiento compuesto combina dos estrategias: divide primero en el nivel superior y luego divide cada partición en subparticiones (p. ej. Range-by-Hash o Range-by-List). Se usa cuando se necesitan al mismo tiempo un ciclo de vida basado en el tiempo y una distribución uniforme/separación por categorías.