Particionado: qué es y cómo decidir la clave de partición
El particionado consiste en dividir una tabla o un conjunto de ficheros en trozos separados según el valor de una o varias columnas, de forma que una consulta pueda leer solo los trozos que le interesan e ignorar el resto. La columna que decide el reparto se llama clave de partición.
Si una tabla de ventas está particionada por fecha, una consulta que pide el último trimestre lee tres particiones y deja intactas las de los años anteriores. Ese descarte se llama partition pruning y es el motivo por el que existe la técnica: no se trata de guardar el dato de otra manera, sino de no leerlo.
Particionado no es lo mismo que sharding
Se confunden a menudo porque ambos parten datos, pero resuelven problemas distintos:
- El particionado organiza los datos dentro de un mismo sistema. El objetivo es leer menos.
- El sharding reparte los datos entre varias máquinas. El objetivo es que quepan y que la carga se distribuya.
Un almacén puede estar particionado sin estar shardeado, y a la inversa. En la práctica los sistemas distribuidos usan los dos a la vez y la clave de partición acaba influyendo también en cómo se reparte el trabajo entre nodos.
Cómo se elige la clave
La regla es simple de enunciar y fácil de incumplir: la clave de partición debe ser la columna por la que se filtra casi siempre. Si el 90% de las consultas llevan un rango de fechas, la clave es la fecha. Si el filtro habitual es el país, la clave es el país.
Cuando se elige por otro criterio —porque parece más «natural» en el modelo de negocio, o porque es la clave primaria— el pruning no se activa nunca y el particionado solo añade complejidad.
Hay dos errores frecuentes al fijar la granularidad:
- Particiones demasiado finas. Particionar por marca temporal completa genera millones de directorios con unos pocos registros cada uno. El coste de listar y abrir tantos ficheros supera con creces lo que se ahorra leyendo menos. En formatos de fichero como Parquet este es el problema clásico de los ficheros pequeños.
- Particiones demasiado gruesas. Particionar por año cuando las consultas piden días obliga a leer trescientas sesenta y cinco veces más de lo necesario.
El punto razonable suele estar en particiones de un tamaño que permita leer una entera sin esfuerzo, y que a la vez sean suficientes para que el filtro descarte la mayor parte del conjunto.
El sesgo de partición
Una clave puede ser correcta desde el punto de vista de las consultas y aun así repartir mal. Si se particiona por cliente y un cliente concentra el 60% de las filas, esa partición será enorme mientras las demás quedan vacías. El resultado en un motor distribuido como Spark es que una tarea tarda mucho más que las otras y el trabajo entero espera por ella.
Ese desequilibrio se llama sesgo o skew, y las salidas habituales son combinar la clave con otra columna para repartir mejor, o tratar los valores dominantes por separado.
Particionado y evolución del modelo
Cambiar la clave de partición de una tabla grande obliga a reescribirla entera, así que es una decisión que conviene tomar bien desde el principio. Los formatos de tabla modernos suavizan el problema porque desacoplan la partición física de cómo se declara la consulta, pero no lo eliminan: la reescritura sigue siendo cara.
Por eso el particionado se decide junto al modelo de acceso, no después. Es una de esas elecciones de arquitectura cuyo coste de corrección crece con el volumen acumulado, igual que ocurre con la evolución de esquema.
Para comparar motores y cómo resuelve cada uno el particionado, el directorio de plataformas de datos de Dataprix recoge fichas y análisis editorial de las principales opciones. El encaje de estas decisiones en el diseño global está en la guía de arquitectura de datos.