2009-11-04 19 views
5

Tenemos un montón de datos que los usuarios pueden querer ver en las ventanas de y lo hacen rápidamente. Es posible que deseen consultar una ventana de datos que es un día, una semana, un mes o datos arbitrarios de inicio y finalización. Ordenar y resumir todo esto en tiempo real está demostrando ser doloroso para nosotros, así que tuve la idea de hacer algo similar a Mipmaps en 3D. Usted termina almacenando los mismos datos precalculados en una variedad de escalas diferentes y luego interpola los resultados usando las escalas variables. Así que ya sabría cuáles eran los números de un año, un mes determinado, una semana determinada y un día determinado para una tienda, y si me piden un rango en particular, utilizo las diversas escalas para agregar rápidamente algo que da la razón. resultados, pero no necesariamente tengo que volver a procesar todo el conjunto de datos, solo recupero cuatro o cinco registros y los agrego o los resta.¿Hay un patrón de almacenamiento de datos similar a mipmaps en gráficos?

¿Es este un patrón real? ¿Tiene algún sentido y hay lugares que puedo leer sobre cómo hacerlo mejor o hay formas mucho mejores de manejar grandes cantidades de datos como este en los que es necesario verlos en diferentes sectores?

Parece que esto debería ser un problema conocido y resuelto. Por ejemplo, muchas personas tienen carteras de acciones y necesitan hacer este tipo de cosas todos los días. Nuestros datos no son precios de acciones, pero la idea es la misma.

Respuesta

2

OK, busqué y busqué y busqué un poco más. Los enlaces de Andy Dent me hicieron comenzar a describir los datos como "series de tiempo" y eso ayudó a algunos. Luego me encontré con OLAP y me di cuenta de que lo que estoy haciendo es reinventar eso. Sabía que tenía que tratarse de un problema bien conocido, completamente abordado, y tenía razón. OLAP es eso.

Crea un conjunto de tablas agregadas que agregan los datos a lo largo de dimensiones particulares (tiempo en este caso) e incluso puede obtener herramientas como Mondrian que tomarán consultas escritas en otro lenguaje de consulta (es decir, no SQL) y un conjunto de tablas de hechos más agregados y decidirá la mejor forma de realizar la consulta en esas tablas.

1

En cierto sentido, creo que respondiste tu pregunta aquí cuando explicaste cómo funciona Mip Mapping (por interpolación/extrapolación).

En diferentes niveles de "zoom", elegiría una menor resolución o frecuencia de muestreo de los datos. Lo contrario se aplicaría a niveles más altos de "zoom", hasta el punto donde necesitaría usar la interpolación (como lineal/polinomial/spline/etc.) en los datos para estimar los valores entre sus puntos de datos.

+0

Me pregunto si hay un cuerpo de literatura para esto. Tal vez esta es una solución horrible para los datos y solo funciona bien para las cosas visuales (que pueden ser mucho menos permisivas que el dinero, créanme en eso). Esperaba que alguien dijera: "Ah, sí, eso es lo que hacemos para bla, bla, bla, y funciona muy bien", o "puedo ver dónde podría pensar que una solución ingenua funcionaría, pero realmente debería usando una estructura Bumpletag y resolvería tu problema mucho mejor ". –

1

Me gusta su analogía con mipmapping y creo que el campo de Observations and Measurements, especialmente los regímenes de muestreo es probablemente donde encontrará el diseño de datos abstractos que está buscando. Le da la teoría detrás de los datos, aunque piensan más en términos de modelos de datos XML que de tablas relacionales.

Solía ​​trabajar con los chicos de CSIRO detrás de esto y una gran parte del pensamiento viene de tener que administrar grandes conjuntos de datos para cosas como sensores de muestreo de agua. Más detalles en el SEEGrid wiki.

Cuestiones relacionadas