Come conservare i dati registrati con frequenza diversa?

Question

Come conservare i dati registrati con frequenza diversa?

#1 da (2 voti)

4

Sto scrivendo un'applicazione web metallurgica, che deve memorizzare i dati (parametri elettrici) registrati a frequenze diverse. Ad esempio:

sei parametri registrati con frequenza di una misura al secondo,
tre parametri registrati con una frequenza di dieci misure al secondo.

(tutti i parametri sono decimali con sei cifre che seguono il punto decimale - DECIMAL(10,6) ).

Come dovrei progettare la struttura del database per memorizzare tali valori in modo efficiente? E per poter interrogare facilmente questo tipo di set di dati per presentarli su qualsiasi tipo di grafico?

Possibilità (idee?), sono arrivato così lontano:

Archiviare entrambi i set di parametri in due tabelle diverse, con un record per unità di tempo corrispondente, archiviare tutti i parametri nelle colonne dichiarate come sopra (decimali) e interrogare un record dalla prima tabella e dieci record dalla seconda tabella per ogni punto sul grafico disegnato. Ciò renderebbe 11 record al secondo .
Archivia tutti i parametri in una tabella, con un record per un secondo, memorizza ogni parametro dal primo gruppo in colonne decimali e ogni parametro dal secondo gruppo come una matrice di decimali e interroga un record da questa tabella solo per ogni punto del grafico disegnato. Ciò renderebbe 1 record al secondo .
Qualcosa di diverso (se entrambi sopra sono sbagliati).

Non ho idea di quale soluzione sarebbe migliore in termini di prestazioni migliori e minore ridondanza dei dati.

Le prime soluzioni sembrano occupare molto più spazio del database, perché hai undici record per ogni secondo di misure (e possiamo occuparci anche di migliaia di dispositivi che ricevono le loro misure ogni secondo), ma nello stesso tempo sembra essere più veloce analisi, perché si ha accesso diretto a ciascun valore in ogni record e in ogni colonna. Mentre, nel secondo caso, dovresti ottenere una dimensione del database molto inferiore (perché abbiamo un record per ogni secondo e ogni dispositivo) ma l'analisi di questi dati sembra più lenta, perché devi analizzare un array di dieci valori per ogni secondo e ogni parametro misurato con Freq. 1/100 ms

Se le mie supposizioni (sopra) sono corrette, allora questa domanda si restringe alla risposta, cosa è più importante nella progettazione del database di oggi - dimensioni del database o tempo di analisi? Per soluzioni a basso costo (come hosting condiviso o VPS low-hardware), suppongo che le dimensioni del database siano molto più importanti e quindi opterei per la seconda opzione.

Sono principalmente focalizzato sull'uso di MySQL, ma posso accettare quasi tutti gli altri tipi di database, se ci fosse qualche vantaggio nell'usare RDBMS diversi.

Informazioni aggiuntive:

Non è necessario (almeno nel mio caso) memorizzare in microtime DB nel caso di un secondo gruppo di parametri (ovvero quelli che sono registrati con una frequenza di 1/100 ms). Devono solo essere correttamente collegati a quel "secondo" (timestamp) sotto il quale vengono memorizzati altri parametri (registrati con una frequenza di 1/1 s).
Non è necessario memorizzare ciascun parametro in un record separato nel database. Come mostrano le mie idee, tutti i parametri possono essere memorizzati in un record per ogni misura.

data-structures database-design data

posta trejder 22.05.2015 - 09:16

fonte

1 risposta

Leggi altre domande sui tag data-structures database-design data

Progettazione: come gestire le autorizzazioni utente su un sistema Operatore di mutazione per algoritmi genetici per risolvere problemi di commesso viaggiatore

score 2 · Accepted Answer

Probabilmente la soluzione più semplice è quella di raccogliere i dati 1/10 di secondo nella cache e scriverli con il 1 secondo di fatto quando arriva. La memorizzazione di entrambi i valori allo stesso tempo rimuove la complessità di gestione delle tabelle di riepilogo e delle attività di pulizia correlate. Un buon modo per gestire il valore 1/10 è aggiungere tutti i campioni e dividere per il # raccolto quando arriva il 1 secondo. È inoltre possibile mantenere altre statistiche di interesse sull'1 / 10th come min, max, stddev e così via, a seconda del valore dei secondi 1/10 per informazioni come picchi. Una tabella di esempio potrebbe essere: %codice% fact 1 is the 1 sec fact 2 is the 1/10th sec

Dopo averlo implementato, potresti considerare la granularità dei dati di cui hai bisogno nel tempo e prendere in considerazione la possibilità di eseguire il rollover di entrambi i valori prima di scriverli nel database in modo che tu possa scrivere solo ogni minuto o ogni minuto o tempo configurato in la tabella.

Inoltre, poiché il sistema funziona per mesi o anni, potresti considerare se hai bisogno di sapere qual era il valore in 15/03/2012 12: 03.55. Se non ne hai bisogno, considera i livelli di riepilogo come potresti vedere in MRTG, dove hai una visualizzazione live per 24 ore, un riepilogo di 5 minuti a una visualizzazione settimanale, poi una visualizzazione di 1 ora a 30 giorni e così via. Ciò consente per mantenere i dati e mantenere prestazioni rapide e monitoraggio delle tendenze senza avere la query attraverso 31 milioni di righe di dati all'anno.

Un altro trucco per trattare dati come questo è usare una tabella che è un tavolo mobile di 24 ore. La tua chiave usa solo ora, minuti, secondi e nessuna data. In questo modo hai una tabella gratuita di 24 ore. Basta fare attenzione agli spazi vuoti (pulire i dati tra l'ultimo campione e questo in modo da non avere dati vecchi tra i valori inseriti se si perde un secondo o due durante la raccolta dei dati). Pensa a un aggiornamento anziché a un inserimento e capirai come funziona questa tabella.