database - svolti - serie storiche statistica esercizi




Memorizzazione di dati di serie temporali, relazionali o non? (7)

5 milioni di righe non sono nulla per i dati torrenziali di oggi. Aspettatevi che i dati siano nella TB o PB in pochi mesi. A questo punto RDBMS non si adatta all'attività e abbiamo bisogno della scalabilità lineare dei database NoSql. Le prestazioni verrebbero raggiunte per la partizione colonnare utilizzata per archiviare i dati, aggiungendo più colonne e meno tipi di concetto di righe per migliorare le prestazioni. Sfrutta il lavoro Open TSDB fatto su HBASE o MapR_DB, ecc.

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

Ho cercato di utilizzare RRDTool in passato, ma l'ho rifiutato poiché la memorizzazione dei dati acquisiti a tempo indeterminato è importante per il mio progetto e desidero un accesso di livello superiore e più flessibile ai dati acquisiti. Quindi la mia domanda è davvero:

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 si interrogano i dati per la creazione di grafici.

relazionale

Dato un database relazionale, utilizzerei una tabella data_instances , in cui verrebbero archiviate tutte le istanze di dati acquisiti per ogni metrica da misurare per tutti i dispositivi, con i seguenti campi:

Campi: id fk_to_device fk_to_metric metric_value timestamp

Quando voglio disegnare un grafico per una particolare metrica su un particolare dispositivo, devo interrogare questa tabella singolare che filtra gli altri dispositivi e le altre metriche analizzate per questo 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 sarà:

d * m_d * f * t

dove d è il numero di dispositivi , m_d è il numero cumulativo di metriche registrate per tutti i dispositivi, f è la frequenza alla quale i dati vengono interrogati e t è la quantità totale di tempo in cui il sistema ha raccolto i dati.

Per un utente che registra 10 metriche per 3 dispositivi ogni 5 minuti per un anno, avremmo meno di 5 milioni di record.

indici

Senza indici su fk_to_device e fk_to_metric scansione di questa tabella in continua espansione richiederebbe troppo tempo. Quindi l'indicizzazione dei campi summenzionati e anche la data / ora (per la creazione di grafici con periodi localizzati) è un requisito.

Non relazionale (NoSQL)

MongoDB ha il concetto di una collezione , a differenza delle tabelle queste possono essere create a livello di codice senza configurazione. Con questi ho potuto partizionare la memorizzazione dei dati per ogni dispositivo, o anche ogni metrica registrata per ciascun dispositivo.

Non ho esperienza con NoSQL e non so se forniscono funzionalità di miglioramento delle prestazioni di query come l'indicizzazione, tuttavia il paragrafo precedente propone di eseguire la maggior parte del lavoro di query relazionale tradizionale nella struttura mediante la quale i dati vengono archiviati in NoSQL.

indeciso

Una soluzione relazionale con indicizzazione corretta si ridurrebbe a una scansione entro l'anno? Oppure la struttura basata sulla raccolta di approcci NoSQL (che corrisponde al mio modello mentale dei dati memorizzati) fornisce un beneficio notevole?


Crea un file, chiamalo 1_2.data. idea stanca? cosa ottieni:

  • Si risparmia fino al 50% di spazio perché non è necessario ripetere il valore fk_to_device e fk_to_metric per ogni punto dati.
  • Risparmia ancora più spazio perché non hai bisogno di alcun indice.
  • Salva coppie di (timestamp, metric_value) nel file accodando i dati in modo da ottenere un ordine per data e ora gratuitamente. (presupponendo che le tue fonti non inviino dati fuori ordine per un dispositivo)

=> Le query di timestamp vengono eseguite in modo incredibilmente veloce perché è possibile utilizzare la ricerca binaria per trovare il posto giusto nel file da cui leggere.

se ti piace ancora più ottimizzato inizia a pensare a dividere i tuoi file in quel modo;

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

oppure usa kdb + da http://kx.com perché fanno tutto questo per te :) orientato alle colonne è ciò che può aiutarti.

È disponibile una soluzione basata su colonne basata su cloud, quindi potresti dare un'occhiata a: http://timeseries.guru


Dovresti esaminare il database delle serie temporali . È stato creato per questo scopo.

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

Esempio popolare di database di serie InfluxDB


La tabella contiene dati in una singola tabella. Quindi relazionale vs non relazionale non è la domanda. Fondamentalmente è necessario leggere molti dati sequenziali. Ora se hai abbastanza RAM per archiviare un valore di dati per anni, niente di simile a Redis / MongoDB ecc.

La maggior parte dei database NoSQL memorizzerà i tuoi dati sulla stessa posizione su disco e in forma compressa per evitare l'accesso multiplo al disco.

NoSQL fa la stessa cosa della creazione dell'indice sull'id del dispositivo e sull'ID metrico, ma a suo modo. Con il database anche se lo fai, l'indice e i dati possono trovarsi in posizioni diverse e ci sarebbe un sacco di IO del disco.

Strumenti come Splunk utilizzano i backend NoSQL per archiviare i dati delle serie temporali e quindi utilizzano la riduzione mappa per creare aggregati (che potrebbero essere ciò che si desidera in seguito). Quindi, secondo me, usare NoSQL è un'opzione in quanto le persone lo hanno già provato per casi d'uso simili. Ma un milione di righe porterà il database a strisciare (forse no, con hardware decente e configurazioni corrette).


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

Ho anche utilizzato RRDTool per un altro progetto che è stato eccellente.


Se stai guardando i pacchetti GPL, RRDTool è una buona cosa da guardare. È un ottimo strumento per archiviare, estrarre e rappresentare graficamente i dati delle serie temporali. Il tuo caso d'uso sembra esattamente come i dati delle serie temporali.


Trovato molto interessante le risposte di cui sopra. Sto cercando di aggiungere un paio di altre considerazioni qui.

1) Invecchiamento dei dati

La gestione delle serie temporali di solito ha bisogno di creare politiche di invecchiamento. Uno scenario tipico (ad es. Monitoraggio della CPU del server) richiede di memorizzare:

  • Campioni grezzi di 1 secondo per un breve periodo (ad es. Per 24 ore)

  • Campioni aggregati di 5 minuti di dettaglio per un periodo medio (es. 1 settimana)

  • Dettaglio di 1 ora su quello (es. Fino a 1 anno)

Sebbene i modelli relazionali rendano possibile (la mia azienda ha implementato enormi database centralizzati per alcuni grandi clienti con decine di migliaia di serie di dati) per gestirli in modo appropriato, la nuova generazione di archivi di dati aggiunge funzionalità interessanti da esplorare come:

  • eliminazione automatica dei dati (consultare il comando EXPIRE di Redis)

  • aggregazioni multidimensionali (ad es. lavori di riduzione della mappa a-la-Splunk)

2) Raccolta in tempo reale

Ancora più importante, alcuni archivi dati non relazionali sono distribuiti in modo intrinseco e consentono una raccolta di dati in tempo reale (o quasi in tempo reale) molto più efficiente che potrebbe costituire un problema con RDBMS a causa della creazione di hotspot (gestione dell'indicizzazione durante l'inserimento in un solo tavolo). Questo problema nello spazio RDBMS viene in genere risolto passando alle procedure di importazione batch (l'abbiamo gestito in questo modo in passato) mentre le tecnologie no-sql sono riuscite in una raccolta e aggregazione in tempo reale massiva (vedi Splunk, ad esempio, menzionato nelle risposte precedenti) .







non-relational-database