opzioni per l'analisi dei dati per l'archivio delle serie temporali

4

Sto creando una soluzione Internet of Things che ha un numero di feed in tempo reale. Ho bisogno di prendere un paio di decisioni di progettazione per quanto riguarda l'archivio dati e la segnalazione e la ricerca di input.

Ho due modelli di implementazione, locale in cui un piccolo server Linux cattura più flussi di solito un nuovo punto dati ogni secondo e la lunghezza della registrazione è piccola, in pratica un messaggio di formato fisso di circa 20 byte. L'altro modello è basato su cloud, dove il tasso di transazione sarà molto più alto, fino a 1000 punti dati al secondo.

Concentrandomi innanzitutto sul modello locale, il mio prototipo utilizza SQLite sotto MONO e funziona bene in un modo RDMS tradizionale. Tuttavia, sono consapevole del fatto che RDBMS non è ottimale per i sistemi di serie storiche e probabilmente una soluzione NOSQL potrebbe essere migliore.

Sto avendo un ripensamento sull'approccio SQL a causa dei miei requisiti di analisi in tempo reale. Voglio essere in grado di riferire facilmente su SUM, COUNT, MEDIA, MEDIA, SD, MIN, MAX su potenzialmente tutti i set di dati della serie storica, in pratica il sistema la ricalcola per ogni nuovo punto dati. Anche se non ho eseguito alcun test delle prestazioni, posso vedere se ho un anno o più dati la dimensione del set di dati sarà piuttosto grande (20 byte al secondo in un anno è 600 MB e potrei avere fino a 30 diverse serie temporali set di dati) e non saranno grandi per il calcolo in tempo reale delle medie ecc. in SQL normale. Voglio anche mantenere basse le dimensioni / il costo del server, quindi non sarò in grado di aggiungere gocce di CPU o memoria, ma lo spazio su disco dovrebbe essere OK.

L'altra opzione che ho è che il mio sistema può memorizzare il delta (modifiche) ai feed in tempo reale invece del normale punto dati, che farà risparmiare circa l'80% dello spazio su disco. Tuttavia, non conosco un modo semplice per fare calcoli come le medie correnti se sto memorizzando delta (per quanto ne so non è possibile con le istruzioni SQL standard, ma potrei sbagliarmi).

Dato il mio caso di utilizzo sopra ho 3 domande:

1) Dovrei considerare seriamente un archivio dati NOSQL? Hai qualche suggerimento sui vantaggi di un negozio NOSQL per questo modello?

2) Come posso fare in modo ottimale calcoli in tempo reale come la media senza molta complessità o hardware? Ho opzioni di piattaforma di MONO o NODE su Linux o Windows.

3) Come eseguire calcoli di set in tempo reale efficienti (in particolare le medie che costituiranno la maggior parte dei calcoli) su SQLite o su un DB NOSQL quando sto memorizzando delta?

    
posta deandob 18.04.2014 - 08:04
fonte

1 risposta

3

NoSQL

Per le tue transazioni non elaborate, se i dati che stai ricevendo non sono obbligati a seguire un formato specifico, NoSQL potrebbe essere un buon modo per archiviare i dati. Se è in grado di essere memorizzato facilmente in un modello di dati relazionali (tabelle e colonne), vi sono significativi vantaggi di velocità nell'utilizzo di un database relazionale.

Come eseguire calcoli efficienti

Aggregazione basata su un periodo di tempo

Una delle cose più veloci che puoi fare è aggregare i tuoi dati in un periodo di tempo, archiviare i risultati .

Supponiamo che i tuoi feed in tempo reale siano al minuto. Ciò equivale a 1.440 punti dati al giorno, 10.080 a settimana, circa 43.000 al mese o 525.600 all'anno. Ora, ridurlo a un record al giorno. Sarebbe un risparmio di 525.236 record all'anno. È anche oltre mezzo milione di righe che non è necessario aggregare ogni volta che è necessario eseguire un calcolo "in tempo reale". Dovrai determinare qual è il periodo temporale più piccolo per un'aggregazione significativa che non sia eccessivamente grande o piccola.

Un esempio concreto aiuterà a illustrare questo principio: il mercato azionario viene scambiato con il simbolo del ticker. Ogni transazione attraversa il filo con il simbolo del ticker, l'ora dello scambio, il prezzo per azione e la quantità di azioni scambiate. Ci possono essere altri dati nel feed, ma questo sarà sufficiente per l'esempio. Conoscere il massimo (massimo), il basso (minimo) e la media (media) di tutte le negoziazioni per giorno mostrerà determinati tipi di trend. Non è necessario vedere le singole transazioni quando si sta cercando una tendenza che è di giorni, mesi o persino anni di elaborazione. Dopo aver aggregato i dati per le transazioni non elaborate del giorno precedente, non è necessario ricalcolare di nuovo tali elementi. Memorizza i dati aggregati in un'altra tabella. Quindi, se si desidera determinare un prezzo medio (medio) per un ticker specifico per un periodo di tempo (settimana, mese, trimestre, ecc.), È un'istruzione SQL abbastanza semplice con un intervallo di date.

Aggregazione ponderata

Un altro metodo molto veloce che puoi usare è comunemente noto come medie ponderate .

In poche parole, si tratta di un'aggregazione in esecuzione in cui si ha un valore aggregato moltiplicato per un peso (spesso una quantità totale), si aggiunge il nuovo valore e quindi si divide per il peso + il nuovo peso. È più facile di quanto sembri.

Se hai un prezzo medio per azione per il giorno (tornando all'esempio del mercato azionario di cui sopra), puoi mediare il prezzo per transazione (somma (prezzo) / numero di transazioni). Questo sarebbe un metodo per eseguire la media.

Per rendere la media di una media ponderata uguale a quella di una media standard, devi moltiplicare la media attuale per il numero di transazioni che sono già state completate.

Il metodo della media ponderata ti manterrà una media costante del prezzo e del numero di transazioni. Quando arriva una nuova transazione, il prezzo medio precedente viene moltiplicato per il numero di transazioni, aggiunto al nuovo prezzo di transazione e infine diviso per il numero di transazioni + 1. Se si avevano 10 transazioni a un prezzo medio di $ 20 e un il nuovo commercio arriva con un prezzo di $ 24, la tua media ponderale sarebbe $ 20,37 ((10 < - numero di transazioni * 20 < - prezzo medio ) + 24 < - nuovo prezzo commerciale ) / 11 < - nuovo numero di transazioni . Quando il prossimo scambio arriverà a $ 25, la tua media ponderata sarà $ 20,76 ((11 < - numero di transazioni * 20,37 < - prezzo medio ) + 25 < - nuovo prezzo commerciale ) / 12 < - nuovo numero di transazioni .

    
risposta data 18.04.2014 - 09:38
fonte

Leggi altre domande sui tag