Ben Dicken explica por qué particionar los datos por rango parece intuitivo, pero a menudo amontona datos y tráfico en las particiones equivocadas. La solución, dice, es una clave de hash que distribuya la carga y el crecimiento de forma más equilibrada.
Particionar una base de datos parece un paso limpio, casi matemático. Pero Ben Dicken dice que elegir la clave de partición suele determinar si el particionado realmente funciona o si solo traslada el problema de un gran servidor a varios servidores desbalanceados. Su idea es simple: una mala elección puede concentrar datos, consultas y crecimiento futuro en la partición equivocada. Una clave con hash, en cambio, reparte todo eso de forma más justa.
Dicken empieza con una pregunta: ¿por qué particionar, en primer lugar? No solo para separar datos, sino para mejorar las copias de seguridad, el rendimiento y la capacidad de atender más consultas. Usa el ejemplo de un único servidor de Postgres o MySQL con 4 TB de datos, y explica por qué repartir la carga entre varios nodos se vuelve atractivo a medida que crece la escala.
La clave de partición es, básicamente, la forma en que controlas qué datos terminan en qué partición, y esa elección afecta muchísimo a cómo se distribuyen los datos, al rendimiento y a cuántas veces tienes que hacer joins entre nodos.
Hay beneficios que te permiten escalar mejor, hacer copias de seguridad más rápidas, repartir consultas y soportar una mayor carga de consultas por segundo.
0:11
El primer esquema que critica Dicken es el particionado por rango: usuarios del 0 al millón en una partición, del 1 al 2 millones en la siguiente, y así sucesivamente. Sobre el papel parece ordenado; pero en la práctica, dice, no refleja cómo crece realmente un sistema, porque el número de usuarios rara vez coincide con la carga que esos usuarios generan.
Podrías tener solo 1,5 millones de usuarios. En ese caso, al migrar, pones a todos los usuarios en las dos primeras particiones y dejas las demás completamente vacías.
1:17
Puedes acabar con una base de datos que tiene menos datos, pero que en realidad recibe más consultas por segundo.
2:05
Y ahí su argumento se vuelve más fuerte: el problema no es solo cómo se reparte el espacio, sino cómo se reparte la actividad. Los usuarios nuevos tienden a ser más activos, mientras que muchos usuarios antiguos casi dejan de usar el servicio; por eso la partición que parece más pequeña puede acabar siendo la más caliente.
Dicken amplía la crítica a los prefijos alfabéticos, como particionar por la primera letra del nombre o del nombre de usuario. Su razonamiento es que la frecuencia de las letras cambia según el idioma, el país e incluso el conjunto de caracteres; así que un límite que parece neutral puede resultar arbitrario y sesgado.
La frecuencia de nombres que empiezan por A, B o C no es la misma en todas las letras, y quizá ni siquiera lo sea en todas las regiones geográficas.
3:14
Un país puede tener muchos más nombres que empiezan por A, y otro puede tener muchos más que empiezan por E.
3:29
La conclusión, para él, es que el criterio más intuitivo suele ser el menos fiable. Un sistema que parece bien repartido en una muestra limitada puede mostrar un fuerte desequilibrio en cuanto cambia la base de usuarios o entra en juego otro alfabeto.*
La solución que propone Dicken es el hash. En vez de usar el ID del usuario tal cual, lo pasas por un algoritmo que produce un resultado aparentemente aleatorio, de modo que identificadores cercanos acaben en particiones muy distintas y el sistema evite acumular a los recién llegados en el mismo sitio.
Incluso dos identificadores muy cercanos, como 1 y 2, pueden convertirse en dos valores totalmente diferentes.
4:09
Ya no estás metiendo a todos los usuarios nuevos en un solo cubo.
5:31
Dicken insiste en que el hash no es realmente aleatorio, pero sí lo bastante impredecible como para comportarse así a efectos de distribución. Si los identificadores llegan en secuencia —1, 2, 3, 4, 100, 101, 102, 1.000, 1 millón—, la tendencia es repartirlos de forma mucho más uniforme, alrededor de un 25% por partición en su ejemplo de cuatro nodos.
La conclusión de Dicken es que una buena clave de partición no es la más fácil de explicar, sino la que refleja cómo funciona de verdad el sistema. El rango sirve cuando los datos ya están ordenados de la misma forma en que se leerán; el hash sirve cuando la prioridad es evitar cuellos de botella y cargas concentradas.
A medida que cada identificador entra en secuencia, debería, en esencia, acabar repartido por igual.
6:05
Aproximadamente un 25% irá allí, un 25% allí, un 25% allí y un 25% allí.
6:25
Su mensaje final no es que particionar sea fácil, sino que el criterio inicial lo condiciona casi todo. Si la clave de partición sigue la forma natural de los datos, el sistema solo parece ordenado; si mezcla bien los datos, paga un precio en complejidad conceptual pero gana estabilidad operativa. Dicken deja una regla práctica muy clara: antes de particionar, no preguntes solo dónde viven los datos, sino cómo se mueven.
¿Qué es una clave de partición?
Es el criterio que determina a qué partición va cada trozo de datos. Dicken la describe como el punto que afecta a la distribución, al rendimiento y al número de joins entre nodos.
¿Por qué son un problema los rangos fijos?
Porque los datos y las consultas no crecen de forma uniforme. Según Dicken, pueden dejar particiones vacías o concentrar el tráfico en los nodos con usuarios más nuevos y activos.
¿Por qué el hash distribuye mejor?
Porque convierte identificadores cercanos en valores muy diferentes, evitando que los registros nuevos caigan siempre en la misma partición. Eso hace la distribución más uniforme, dice Dicken.
¿Es siempre mejor el hash?
No. Es útil cuando lo más importante es equilibrar la carga, pero puede empeorar las consultas por rango y la localidad de los datos.
Resumen asistido por IA del pódcast de Ben Dicken, verificado con la transcripción original.