mysql - Creación de filas vs. columnas rendimiento

Question

Creé un motor de análisis que extrae 50-100 filas de datos brutos de mi base de datos (llamémoslo raw_table), ejecuta varias medidas estadísticas en PHP y luego aparece exactamente 140 puntos de datos que luego necesito almacenar en otra tabla (vamos a llamarlo results_table). Todos estos puntos de datos son muy pequeños ("40", "2.23", "- 1024" son buenos ejemplos de los tipos de datos).

Sé que el número máximo de columnas para mysql es bastante alto (4000+) pero parece que hay una gran cantidad de áreas grises en cuanto a cuando el rendimiento realmente comienza a degradarse.

Así que un par de preguntas aquí sobre las mejores prácticas de desempeño:

1) Los 140 puntos de datos podrían ser, si es mejor, dividido en 20 filas de 7 puntos de datos todos con el mismo 'experiment_id' si un menor número de columnas es mejor. SIN EMBARGO, siempre tendría que sacar TODAS las 20 filas (con 7 columnas cada una, más identificación, etc.) así que no creo que esto sería un mejor rendimiento que tirar 1 fila de 140 columnas. Entonces, la pregunta: ¿es mejor almacenar 20 filas de 7-9 columnas (que tendrían que ser tiradas al mismo tiempo) o 1 fila de 140-143 columnas?

2) Dados mis ejemplos de datos ("40", "2.23", "- 1024" son buenos ejemplos de lo que se almacenará) Estoy pensando en smallint para el tipo de estructura. ¿Algún comentario, en cuanto a rendimiento o si no?

3) Cualquier otro comentario sobre problemas de rendimiento de mysql es bienvenido.

Gracias de antemano por su contribución.

Answer 1

Creo que la ventaja de almacenar más filas (es decir, normalizada) depende de las consideraciones de diseño y mantenimiento frente a cambios.

Además, si las 140 columnas tienen el mismo significado o si difieren por experimento, modelar adecuadamente los datos según las reglas de normalización, es decir, cómo se relacionan los datos con una clave candidata.

En lo que respecta al rendimiento, si se usan todas las columnas, hay muy poca diferencia. En ocasiones, una operación de pivote/desvinculación puede ser costosa en una gran cantidad de datos, pero tiene poca importancia en un solo patrón de acceso de clave. A veces, un pivote en la base de datos puede hacer que el código de su interfaz sea mucho más simple y el código de back-end sea más flexible ante los cambios.

Si tiene muchos valores NULL, es posible eliminar filas en un diseño normalizado y esto ahorraría espacio. No sé si MySQL tiene soporte para un concepto de tabla dispersa, que podría entrar allí.

Answer 2

Tiene 140 elementos de datos para devolver cada vez, cada uno de tipo doble.

No hace ninguna diferencia práctica si se trata de 1x140 o 20x7 o 7x20 o 4x35, etc. Podría ser infinitamente más rápido por una forma, por supuesto, pero entonces habría que considerar la complejidad adicional en el código PHP para hacer frente a una diferente forma.

¿Tiene un cuello de botella verificado o es solo una optimización prematura al azar?

Answer 3

No ha sugerido que tenga la intención de almacenar datos grandes en la base de datos, pero a los efectos de este argumento, supondré que tiene 1 mil millones (10^9) puntos de datos.

Si los almacena en 140 columnas, tendrá solo 7 millones de filas, sin embargo, si desea recuperar un único punto de datos de muchos experimentos, tendrá que buscar una gran cantidad de datos muy anchos filas

Estas filas muy anchas ocuparán más espacio en su innodb_buffer_pool, por lo tanto, no podrá almacenar en caché tantas; esto potencialmente lo desacelerará cuando acceda a ellos de nuevo.

Si almacena un punto de datos por fila, en una tabla con muy pocas columnas (experiment_id, datapoint_id, value), tendrá que sacar el mismo número de filas más pequeñas.

Sin embargo, el tamaño de las filas hace poca diferencia con el número de operaciones de E/S requeridas. Si suponemos que sus mil millones de puntos de datos no encajan en RAM (lo cual NO es una suposición segura hoy en día), tal vez el rendimiento resultante será aproximadamente el mismo.

Probablemente sea mejor el diseño de la base de datos para usar pocas columnas; pero usará menos espacio en disco y quizás sea más rápido de llenar, si usa muchas columnas.