2009-11-04 12 views
5

Abbiamo un sacco di dati che gli utenti potrebbero voler visualizzare finestre e farlo velocemente. Potrebbero voler guardare una finestra dei dati che è un giorno, una settimana, un mese o un dato iniziale e finale arbitrario. L'ordinamento e la somma di tutte queste cose in tempo reale si sta dimostrando doloroso per noi, così ho avuto l'idea di fare qualcosa di simile a Mipmaps nel rendering 3D. Si finisce per memorizzare gli stessi dati precalcolati in una varietà di scale diverse e quindi interpolare i risultati usando le scale variabili. Quindi saprei già quali sono stati i numeri per un anno, un dato mese, una data settimana e un dato giorno per un negozio e se chiedono un determinato intervallo uso le varie scale per sommare rapidamente qualcosa che dà il giusto risultati ma non devo necessariamente rielaborare l'intero set di dati, recupero solo quattro o cinque record e li aggiungo o sottraggo.Esiste un modello di archiviazione dei dati simile a mipmaps nella grafica?

È questo uno schema reale? Ha senso e ci sono dei posti in cui posso leggere su come farlo meglio o ci sono modi molto migliori per gestire grandi blocchi di dati come questo in cui deve essere visualizzato in sezioni diverse?

Sembra che questo dovrebbe essere un problema ben noto e risolto. Ad esempio, molte persone hanno portafogli azionari e hanno bisogno di fare questo genere di cose ogni giorno. I nostri dati non sono prezzi delle azioni, ma l'idea è la stessa.

risposta

2

OK, ho cercato, cercato e cercato ancora. I collegamenti di Andy Dent mi hanno fatto iniziare a descrivere i dati come "serie storiche" e questo ha aiutato alcuni. Poi mi sono imbattuto in OLAP e ho capito che quello che sto facendo è reinventarlo. Sapevo che questo doveva essere un problema ben noto e completamente risolto e avevo ragione. OLAP è così.

Si costruisce un gruppo di tabelle aggregate che aggregano i dati lungo dimensioni particolari (tempo in questo caso) e si possono anche ottenere strumenti come Mondrian che richiedono query scritte in un altro linguaggio di query (cioè non SQL) e un set di tabelle fact più aggregati e deciderà il modo migliore per eseguire la query su quelle tabelle.

1

In un certo senso, penso che tu abbia risposto alla tua domanda qui quando hai spiegato come funziona il mapping Mip (per interpolazione/estrapolazione).

A diversi livelli di "zoom", basta scegliere una risoluzione più bassa o una frequenza di campionamento dei dati. L'inverso si applicherebbe ai livelli più alti di "zoom" - al punto in cui dovresti usare l'interpolazione (come lineare/polinomiale/spline/etc) sui dati per stimare i valori tra i tuoi punti dati.

+0

Mi stavo chiedendo se c'è un corpo di letteratura per questo. Forse questa è una pessima soluzione per i dati e funziona solo per le cose visive (che possono essere molto meno indulgenti dei soldi, credimi su questo). Ero quasi sperando che qualcuno dicesse "Oh sì, è proprio quello che facciamo per blah blah blah e funziona alla grande" oppure "Posso vedere dove potresti pensare che la soluzione ingenua potrebbe funzionare ma dovresti davvero essere usando una struttura Bumpletag e risolverebbe il tuo problema molto meglio. " –

1

Mi piace la tua analogia con il mipmapping e penso che il campo di Observations and Measurements, in particolare i regimi di campionamento, sia probabilmente dove troverai il disegno astratto dei dati che cerchi. Ti dà la teoria dietro i dati, anche se pensano più in termini di modelli di dati XML che di tabelle relazionali.

Di solito lavoravo con i ragazzi del CSIRO e gran parte del pensiero deriva dal dover gestire enormi set di dati per cose come sensori di campionamento dell'acqua. Maggiori dettagli allo SEEGrid wiki.

Problemi correlati