Para agregar o no agregar, esa es la pregunta de diseño de esquema de base de datos

Question

Si está haciendo consultas min/max/avg, ¿prefiere usar tablas de agregación o simplemente consultar en un rango de filas en la tabla sin formato?

Esta es obviamente una pregunta muy abierta y no hay una respuesta correcta, así que estoy buscando las sugerencias generales de la gente. Supongamos que la tabla de datos sin formato consta de una marca de tiempo, una clave externa numérica (por ejemplo, una identificación de usuario) y un valor decimal (por ejemplo, una cantidad de compra). Además, supongamos que hay millones de filas en la tabla.

He hecho ambas cosas y estoy desgarrado. Por un lado, las tablas de agregación me han dado consultas significativamente más rápidas, pero a costa de una proliferación de tablas adicionales. La visualización de los valores actuales para un rango agregado requiere volver a la tabla de datos sin formato o combinar agregaciones más finas. He encontrado que hacer un seguimiento en el código de la aplicación de la tabla de agregación para consultar cuándo es más trabajo que usted pensaría y que los cambios de esquema serán necesarios, ya que los intervalos de agregación originales invariablemente no serán suficientes ("Pero yo quería ver nuestras ventas en los últimos 3 períodos de pago! ").

Por otro lado, las consultas a partir de los datos brutos pueden ser terriblemente lentas, pero me permite ser muy flexible con respecto a los rangos de datos. Cuando cambian los límites del rango, simplemente cambio una consulta en lugar de tener que volver a generar las tablas de agregación. Del mismo modo, el código de la aplicación requiere menos actualizaciones. Sospecho que si fuera más inteligente sobre mi indexación (es decir, siempre tuviera buenos índices de cobertura), sería capaz de reducir la penalidad de seleccionar a partir de los datos en bruto, pero eso no es una panacea.

¿De todos modos puedo tener lo mejor de ambos mundos?

Answer 1

Tuvimos el mismo problema y encontramos los mismos problemas que se encontraron. Terminamos cambiando nuestros informes a Analysis Services. Hay una curva de aprendizaje con los servicios MDX y Analysis en sí, pero ha sido excelente. Algunos de los beneficios que hemos encontrado son:

1. Tiene mucha flexibilidad para consultar de la forma que desee. Antes de que tuviéramos que crear agregados específicos, pero ahora un cubo responde todas nuestras preguntas .
2. El almacenamiento en un cubo es mucho más pequeño que los datos detallados.
3. Construir y procesar los cubos lleva menos tiempo y produce menos carga en los servidores de base de datos que los agregados.

algunas desventajas:

1. Hay una curva de aprendizaje en torno a la creación de cubos MDX y el aprendizaje.
2. Tuvimos que crear algunas herramientas para automatizar el trabajo con los cubos.

ACTUALIZACIÓN: Dado que está utilizando MySQL, se puede echar un vistazo a Pentaho Mondrian, que es una solución OLAP de código abierto que soporta MySQL. Nunca lo he usado, así que no sé si funcionará para ti o no. Sin embargo, estaría interesado en saber si funciona para usted.

Answer 2

Siempre me inclino por los datos brutos. Una vez agregado, no puede regresar.
No tiene nada que ver con la eliminación - a menos que exista el conjunto de datos agregados más simple, no puede revertir/transponer los datos de forma exacta a raw.

Idealmente, usaría una vista materializada (suponiendo que los datos pueden caber dentro de las restricciones) porque efectivamente es una tabla. Pero MySQL no los admite, por lo que la siguiente consideración sería una vista con las columnas calculadas o un activador para actualizar una tabla real.

Answer 3

Ayuda a elegir una buena clave principal (es decir [user_id, used_date, used_time]). Para un user_id constante, es muy rápido hacer una condición de rango en used_date.

Pero a medida que la tabla crece, puede reducir su tamaño de tabla agregando a una tabla como [user_id, used_date]. Para cada rango donde la hora del día no importa, puede usar esa tabla. Otra forma de reducir el tamaño de la tabla es archivar datos antiguos que ya no permite (permitir) consultar.