Tengo una tabla grande (varios 100 millones de filas) que me gustaría particionar eficientemente. Mi pregunta es si existe una compensación entre el tamaño de la partición y el número de particiones. Según tengo entendido, la mayoría de las consultas en una columna utilizada en la partición serán más rápidas porque la consulta (para la mayoría de las consultas) solo tendrá que buscar dentro de la partición aplicable a la consulta. Por lo tanto, tendría sentido que, para maximizar la eficiencia, debe dividir una tabla grande en el número máximo de particiones, por lo tanto, haciendo que cada partición sea lo más pequeña posible. En el caso de MySQL, esto significa 1024 particiones. Pero, ¿hay algún inconveniente en el rendimiento de tener una gran cantidad de particiones? Es así, ¿cómo se encuentra el número óptimo de particiones?

Nota: Ya existe una pregunta algo similar sobre stackoverflow , pero solo una respuesta, que (desde mi punto de vista) pierde la nota. Así que haré la pregunta a mi manera ... espero que sea más clara

Vamos a compararlos

TAMAÑO DE LA PARTICIÓN

Si tienes lo siguiente:

• 100 millones de filas en una mesa
• BTREE indexación
• Cada página en el BTREE contiene 1024 claves

¿Cómo serían las métricas?

Desde LOG (100000000) / LOG (2) = 26.575424759099, un índice BTREE con 1024 claves por página treenode tendría una altura de árbol de solo 3 (TECHO (LOG (100000000) / LOG (1024))). Con solo tres nodos de páginas, una búsqueda binaria de la clave necesaria en cada treenode accedido resultaría en una poda y aislamiento de aproximadamente 30 claves.

NÚMERO DE PARTICIONES

Si tienes lo siguiente:

• 100 millones de filas en una mesa
• BTREE indexación
• Cada página en el BTREE contiene 1024 claves
• Crea 1024 pariticiones

Los números serían ligeramente diferentes.

Cada partición debe tener aproximadamente 97656 filas. ¿En qué se convertirían las métricas ahora?

Desde LOG (97656) / LOG (2) = 16.575421065795, un índice BTREE con 1024 claves por página treenode tendría una altura de árbol de solo 2 (CEILING (LOG (97656) / LOG (1024))). Con solo dos nodos de páginas, una búsqueda binaria de la clave necesaria en cada treenode accedido resultaría en una poda y aislamiento de aproximadamente 20 claves.

CONCLUSIÓN

Extender las teclas solo elimina un nivel de árbol, pero esencialmente crea 1024 índices. Las consultas no sabrán la diferencia. El tiempo de búsqueda probablemente sea nominal en el mejor de los casos a favor de las particiones. Sin embargo, asegúrese de que todos los datos estén activos. De lo contrario, puede estar golpeando solo unas pocas particiones, mientras que otras particiones con datos de acceso poco frecuente solo ocupan espacio y nunca se accede con la frecuencia suficiente para justificar la partición . Es posible que tenga que preocuparse por diferentes métricas de rendimiento que son más evidentes (como la desfragmentación interna en XFS , ext3 frente a ext4, etc.) También debe preocuparse por el motor de almacenamiento que está utilizando porque:

• La indexación de InnoDB sería un poco más complicada en comparación con MyISAM debido a que tiene que administrar un índice agrupado
• InnoDB realiza una doble escritura de datos en ibdata1, así como en el archivo de registro actual (ib_logfile0 o ib_logfile1)