Memorizzazione dei dati di serie temporali, relazionale o non?

Question

Sto creando un sistema che esegue il polling dei dispositivi per i dati sulle metriche diverse come ad esempio l'utilizzo della CPU, l'utilizzo del disco, temperatura, ecc a (probabilmente) intervalli di 5 minuti utilizzando SNMP. L'obiettivo finale è fornire visualizzazioni ad un utente del sistema sotto forma di grafici di serie temporali.

Ho guardato utilizzando RRDTool in passato, ma ha respinto come la memorizzazione dei dati acquisiti a tempo indeterminato è importante per il mio progetto, e voglio di più alto livello e l'accesso più flessibile ai dati acquisiti. Quindi la mia domanda è in realtà:

Cosa c'è di meglio, un database relazionale (come MySQL o PostgreSQL) o un database non relazionale o NoSQL (come MongoDB o Redis) per quanto riguarda le prestazioni quando query sui dati per la rappresentazione grafica.

Relazionale

Dato un database relazionale, desidero utilizzare una tabella data_instances, in cui potrebbero essere memorizzati ogni istanza di dati acquisiti per ogni essere metrica misurata per tutti i dispositivi, con i seguenti campi:

I campi: id fk_to_device fk_to_metric metric_value timestamp

Quando voglio tracciare un grafico per un particolare parametro su un particolare dispositivo, devo interrogare questa tabella singolare filtrando gli altri dispositivi e gli altri parametri da analizzare per il dispositivo:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Il numero di righe in questa tabella sarebbe:

d * m_d * f * t

dove d è il numero di Dispositivi , m_d è accumulativo numero di metriche in fase di registrazione per tutti i dispositivi, f è il frequenza quali dati polling e t è la quantità totale di ora il sistema ha raccolto dati.

Per una registrazione di 10 metriche per 3 dispositivi ogni 5 minuti per un anno utente, avremmo poco meno di 5 milione record.

Indici

Senza indici su fk_to_device e fk_to_metric scansione di questo tavolo in continua espansione richiederebbe troppo tempo. Così indicizzare i campi di cui sopra e anche timestamp (per la creazione di grafici con periodi localizzate) è un requisito.

non relazionali (NoSQL)

MongoDB ha il concetto di una collezione , a differenza di tabelle Questi possono essere creati a livello di codice, senza l'installazione. Con questi ho potuto dividere la conservazione dei dati per ogni dispositivo, o anche ogni metrica registrate per ogni dispositivo.

Non ho esperienza con NoSQL e non so se prevedono alcun prestazioni delle query migliorare caratteristiche come l'indicizzazione, ma il precedente paragrafo si propone di fare la maggior parte del lavoro tradizionale interrogazione relazionale nella struttura con la quale i dati sono memorizzati in NoSQL.

Non ho ancora deciso

Sarebbe una soluzione relazionale con la corretta indicizzazione ridurre a passo d'uomo entro l'anno? O fa la struttura basata collezione di NoSQL si avvicina (che corrisponde il mio modello mentale dei dati memorizzati) fornire un beneficio evidente?

Answer 1

Sicuramente relazionale. la flessibilità e l'espansione illimitata.

Due correzioni, sia nel concetto e nell'applicazione, seguito da un aumento.

Correzione

1. Non è "filtrando i dati non necessari"; è selezionare solo i dati necessari. Sì, naturalmente, se si dispone di un indice per sostenere le colonne identificate nella clausola WHERE, è molto veloce, e la query non dipende dalla dimensione della tabella (afferrando 1.000 righe da una tabella 16 miliardi di fila è istantanea) .

2. Il tavolo ha un grave impedimento. Data la descrizione, il PK reale è (Device, Metric, DateTime). (. Per favore non chiamatelo TimeStamp, che significa qualcosa di diverso, ma questo è un problema minore) L'unicità della fila è identificato da:

      (Device, Metric, DateTime)
   

   • La colonna Id non fa nulla, è totalmente e completamente ridondante.

     • Una colonna Id non è mai una chiave (righe duplicate, che sono vietati in un database relazionale, devono essere evitati con altri mezzi).

     • La colonna Id richiede un indice aggiuntivo, che impedisce ovviamente la velocità di INSERT/DELETE, e aggiunge allo spazio su disco utilizzato.

     • Si può sbarazzarsi di esso. Per favore.

Altitudine

1. Dopo aver rimosso l'impedimento, non si può avere riconosciuto, ma il vostro tavolo è al sesto Normal Form. Molto alta velocità, con un solo indice dal PK. Per capire, leggere questa risposta dal Qual è la sesta forma normale? voce in poi.

   • (ho un indice unico, non tre, sulla non SQLs potrebbe essere necessario tre indici).

   • Ho lo stesso tavolo esatto (senza la "chiave" Id, ovviamente). Ho un Server colonna aggiuntiva. Sostengo più clienti da remoto.

     (Server, Device, Metric, DateTime)

   La tabella può essere utilizzata per far ruotare il dati (es. Devices in alto e Metrics lungo il lato, o fulcrato) usando esattamente lo stesso codice SQL (sì, commutare le celle). Io uso il tavolo di erigere una varietà illimitata di grafici e tabelle per i clienti re le loro prestazioni del server.

   • Monitor Statistiche Data Model .
     (Troppo grande per inline; alcuni browser non può caricare in linea,.. Clic sul collegamento, inoltre, che è la versione demo obsoleta, per ovvi motivi, non posso mostrare DM prodotto commerciale)

   • Mi permette di produrre Grafici Like This , sei combinazioni di tasti dopo aver ricevuto un file RAW di monitoraggio statistiche da parte del cliente, utilizzando un unico comando SELECT . Si noti il ??mix-and-match; OS e il server sullo stesso grafico; una varietà di perni. Naturalmente, non v'è alcun limite al numero di statistiche matrici, e quindi i grafici. (Usato con il permesso del cliente.)

   • I lettori che non hanno familiarità con lo standard per la modellazione database relazionali possono trovare il IDEF1X notazione utile.

One More Thing

Ultimo ma non meno importante, SQL è un IEC / ISO / ANSI. Il freeware è in realtà non-SQL; è fraudolenta per usare il termine di SQL se non forniscono la standard. Essi possono fornire "extra", ma sono assenti i principi fondamentali.

Answer 2

trovato molto interessante le risposte di cui sopra. Cercando di aggiungere un altro paio di considerazioni qui.

1) I dati di invecchiamento

gestione

Time-series di solito bisogno di creare politiche di invecchiamento. Un tipico scenario (ad esempio il monitoraggio della CPU del server) richiede di negozio:

• 1-sec campioni grezzi per un breve periodo (ad esempio per 24 ore)

• 5-min campioni globali di dettaglio per un periodo medio (per esempio 1 settimana)

• 1 ora dettaglio oltre che (per esempio fino a 1 anno)

Sebbene i modelli relazionali consentono di sicuro (la mia azienda ha implementato enormi banche dati centralizzate per alcuni grandi clienti con decine di migliaia di serie di dati) per gestire in modo appropriato, la nuova generazione di archivi di dati aggiungere funzionalità interessanti da esplorare come:

• automatizzato di dati spurgo (vedi Redis' comando EXPIRE)

• aggregazioni multidimensionali (ad esempio MAP-ridurre posti di lavoro a-la-Splunk)

2) raccolta in tempo reale

Ancora più importante alcuni archivi di dati non relazionali sono intrinsecamente distribuito e consentire un più efficiente in tempo reale (o quasi in tempo reale) la raccolta dei dati che potrebbe essere un problema con RDBMS a causa della creazione di hotspot (indicizzazione gestione mentre l'inserimento in una singola tabella). Questo problema nello spazio RDBMS è in genere risolto tornando al procedure di importazione in batch (siamo riusciti in questo modo in passato) mentre non-SQL tecnologie sono riusciti a massiccia raccolta in tempo reale e l'aggregazione (vedi Splunk per esempio, menzionato nelle risposte precedenti) .

Answer 3

tabella

Si dispone di dati in un'unica tabella. Così relazionale vs non relazionale non è la domanda. Fondamentalmente è necessario leggere un sacco di dati sequenziali. Ora, se avete abbastanza RAM per memorizzare un valore di anni di dati poi nulla come l'utilizzo di Redis / MongoDB etc.

Per lo più i database NoSQL memorizzerà i dati sullo stesso percorso sul disco e in forma compressa per evitare l'accesso al disco multiplo.

NoSQL fa la stessa cosa come creare l'indice sul dispositivo e nell'identificazione del metrica, ma a suo modo. Con database anche se si esegue questa operazione l'indice ed i dati possono essere in luoghi diversi e ci sarebbe un sacco di IO disco.

Strumenti come Splunk stanno utilizzando backend NoSQL ai dati di serie temporali negozio e poi usando la mappa di ridurre per creare aggregati (che potrebbe essere ciò che si desidera in seguito). Quindi, a mio parere per l'uso NoSQL è un'opzione come persone hanno già provato per casi d'uso simili. Ma saranno un milione di righe portare il database di ricerca per indicizzazione (forse non, con l'hardware decente e le configurazioni corrette).

Answer 4

Creare un file, nominarlo 1_2.data. idea weired? quello che si ottiene:

• risparmiare fino al 50% di spazio in quanto non è necessario ripetere la fk_to_device e il valore fk_to_metric per ogni punto di dati.
• risparmiare ancora di più spazio, perché non hai bisogno di qualsiasi indice.
• Salva coppie di (timestamp, metric_value) al file aggiungendo i dati in modo da ottenere un ordine da timestamp gratis. (Assumendo che le vostre fonti non inviare dei dati degli ordini per un dispositivo)

=> Query da corsa timestamp incredibilmente veloce, perché si può usare la ricerca binaria per trovare il posto giusto nel file da cui leggere.

Se ti piace ancora di più ottimizzato pensiero inizio su come dividere i file così;

• 1_2_january2014.data
• 1_2_february2014.data
• 1_2_march2014.data

o l'uso KDB + da http://kx.com perché fanno tutto questo per voi :) colonna-oriented è ciò che può aiutare.

C'è una soluzione di colonna-oriented basata su cloud popping up, quindi si consiglia di avere uno sguardo a: http: // timeseries .guru

Answer 5

Se siete alla ricerca di pacchetti GPL, RRDTool è una buona per guarda a. È un buon strumento per la memorizzazione, l'estrazione e la rappresentazione grafica dei dati delle serie temporali. I vostri casi d'uso appare esattamente come i dati di serie temporali.

Answer 6

Questo è un problema che abbiamo avuto per risolvere a ApiAxle. Abbiamo scritto un blog post su come abbiamo fatto utilizzando Redis. Non è stato là fuori per molto tempo, ma sta dimostrando di essere efficace.

Ho anche usato RRDTool per un altro progetto che era eccellente.

Answer 7

Credo che la risposta a questo tipo di domanda dovrebbe ruotare principalmente sul modo in cui il database utilizzare archiviazione. Alcuni server di database utilizzo di RAM e disco, un certo uso di RAM solo (opzionalmente disco per la persistenza), etc. La maggior parte delle soluzioni di database SQL comuni utilizzano memoria + storage su disco e scrive i dati in un layout basato Row (ogni grezzo inserita è scritto nella stessa posizione fisica). Per TimeSeries negozi, nella maggior parte dei casi il carico di lavoro è qualcosa di simile: relativamente bassa dell'intervallo di massiccia quantità di inserti, mentre si legge si basano colonna (nella maggior parte dei casi si desidera leggere una serie di dati da una colonna specifica, che rappresenta una metrica)

Ho trovato colonnari Databases (google, troverete MonetDB, Infobright, ParAccel, ecc) stanno facendo ottimo lavoro per le serie temporali.

Per quanto riguarda la tua domanda, che personalmente credo sia un po 'valido (come tutte le discussioni che utilizzano il termine colpa NoSQL - IMO): È possibile utilizzare un server di database che può parlare SQL da un lato, rendendo la vita molto facile come tutti sanno SQL per molti anni e questo linguaggio è stato perfezionato più e più volte per le query di dati; ma ancora utilizzare RAM, CPU Cache e Disk in modo orientato a colonne, rendendo la soluzione più adatta Time Series

Answer 8

5 milioni di righe è nulla per i dati torrenziali di oggi. Aspettatevi dati siano nel TB o PB in pochi mesi. A questo punto RDBMS non scala al compito e abbiamo bisogno del scalabilità lineare dei database NoSQL. Prestazioni potrebbe essere raggiunto per la partizione colonnare utilizzato per memorizzare i dati, l'aggiunta di più colonne e meno righe tipo di concetto per migliorare le prestazioni. Sfruttare il lavoro aperto TSDB fatto in cima HBase o MapR_DB, ecc

Answer 9

I faccia requisiti simili regolarmente, e hanno recentemente iniziato a utilizzare Zabbix per raccogliere e archiviare questo tipo di dati. Zabbix ha una propria capacità di grafica, ma è abbastanza facile per estrarre i dati dal database Zabbix ed elaborarlo come più vi piace. Se non l'hai già controllato Zabbix fuori, si potrebbe trovare pena il tempo di farlo.

Answer 10

Si dovrebbe guardare in Tempo database di serie . E 'stato creato per questo scopo.

Un database serie temporale (TSDB) è un sistema software che è ottimizzato per la gestione di dati di serie temporali, array di numeri indicizzati da tempo (un datetime o un intervallo datetime).

esempio popolare di banca dati di serie temporali InfluxDB