Come archiviare in modo efficiente i dati delle serie storiche?

Devo archiviare e poter interrogare alcuni dati di serie temporali di grandi quantità.

Le proprietà dei dati sono le seguenti:

numero di serie: circa 12.000 (dodicimila)
numero di punti dati, a livello globale: circa 500.000.000 al mese (cinquecento milioni)
tipi di valori misti: la maggior parte dei punti dati sono valori in virgola mobile, il resto sono stringhe
periodo di campionamento: variabile tra le serie e all'interno di una serie
timestamp: precisione in millisecondi
periodo di conservazione dei dati: diversi anni, senza decadimento o downsampling
gli archivi di dati devono essere costruiti quasi in tempo reale, ma è accettabile un ragionevole ritardo (~ 1 ora)
i dati passati possono essere ricostruiti se necessario, ma a costi elevati
a volte, ma abbastanza raramente, alcuni dati passati devono essere aggiornati

Proprietà delle query previste:

la maggior parte delle query relative ai dati saranno query basate su data / ora; che vanno da un giorno a diversi mesi / anni. 90% + saranno query sui dati più recenti

Altri requisiti:

la soluzione deve essere gratuita come nella birra gratuita e preferibilmente open source

Il mio pensiero iniziale era di usare PyTables / Pandas con file HDF5 come archivio back-end anziché come database SQL.

Domande :

Supponendo che PyTables / Pandas sia il percorso "migliore", sarebbe meglio dividere i dati in diversi file HDF, ognuno in un determinato periodo di tempo, o mettere tutto in un singolo file che diventerebbe enorme?
Dovrei andare e preferire il formato fisso o tabella? Per me, il formato fisso sembra OK se mantengo un file HDF al mese, poiché in questo modo un'intera serie probabilmente si adatta alla RAM e posso tagliare in memoria senza bisogno di un indice di formato tabella. Ho ragione ?

E se questo non è l'approccio migliore, come dovrei strutturare questo archivio dati o quali tecnologie dovrei prendere in considerazione? Non sono il primo ad affrontare l'archiviazione di grandi serie di dati di serie temporali, qual è l'approccio generale per risolvere questa sfida?

Altri approcci che ho considerato:

database di array: si adattano perfettamente alle serie temporali con periodo di campionamento costante, poiché è quindi necessario memorizzare solo i tempi di inizio e fine e il periodo di campionamento dell'array, quindi solo i valori nell'array stesso e l'indicizzazione sono facili. Ma con periodi di campionamento variabili all'interno delle serie stesse, ho bisogno di mantenere una relazione timestamp-> value più stretta, che a mio avviso non è adatta per il DBMS di array.
database SQL standard con data / ora, paramID, valore come colonne ma per loro natura richiedono molto I / O su disco per qualsiasi query

database python performance

— flyingmig
fonte

Dovresti prendere in considerazione i database array - en.wikipedia.org/wiki/Array_DBMS#List_of_Array_DBMS . Non sto dicendo che uno di loro sarebbe la risposta giusta, o anche la migliore o addirittura abbastanza buona, solo che dovrebbero entrare nei tuoi pensieri. Oltre alle voci in quella lista c'è il sistema kdb ( kx.com ) anche se è tutt'altro che gratuito.

— High Performance Mark

Grazie per il tuo contributo. Ho preso in considerazione i database di array, ma il problema che ho riscontrato è che si adattano perfettamente alle serie temporali con periodo di campionamento costante , poiché è quindi necessario memorizzare solo i tempi di inizio e fine e il periodo di campionamento dell'array, quindi solo i valori in l'array stesso e l'indicizzazione sono facili. Ma con periodi di campionamento variabili all'interno delle serie stesse, ho bisogno di mantenere una relazione timestamp-> value più stretta, che a mio avviso non è adatta per il DBMS di array. Detto questo, sarei felice di essere smentito.

— Flyingmig

domanda di modifica per aggiungere ciò che ho considerato finora

— flyingmig

Domanda: è necessario memorizzare tutti i dati? I dati possono decadere nel tempo e / o esiste un livello accettabile di precisione per le serie basate su float?

— J Trana,

@ moinuddin-quadri Ho finito con gli oggetti panda DataFrame supportati da file mensili HDF5 usando il formato tabella. Il sistema funziona da più di un anno e si è dimostrato molto stabile e veloce, nemmeno usando i dischi SSD. Cercherò di scrivere tutto ciò come risposta quando avrò tempo. Altrimenti, sentitevi liberi di parlarmi.

— flyingmig

Risposte:

Potresti dare un'occhiata al carbonio e al sussurro , parte del progetto di grafite . Il carbonio è in grado di gestire grandi quantità di dati relativi alle serie storiche. Tuttavia, ora che ho letto i documenti (sono passati alcuni anni da quando l'ho usato), è solo per i dati numerici. Hai detto che hai anche i dati delle stringhe, quindi potresti non essere utile. Tuttavia, potresti essere in grado di raccogliere un po 'di saggezza su come sono in grado di elaborare rapidamente grandi quantità di dati.

Per darti un'idea di come si ridimensiona, quando la grafite è stata messa in produzione per la prima volta in Orbitz, gestiva 160.000 metriche al minuto .

— Bryan Oakley
fonte

Grazie per il suggerimento, ma dalla mia comprensione il sussurro non si adatta perché la sua precisione è la seconda quando ho bisogno di una precisione di millisecondi e, come hai giustamente sottolineato, ho anche dati di stringa che non possono essere memorizzati lì.

— maschera volante

@flyingmig Non scrivere sussurri così in fretta. I suoi timestamp sono valori di epoca Unix. E i "dati stringa" che hai descritto nella domanda suonano più come enumerazioni, e quelli sono di solito memorizzati come piccoli valori interi.

— Ross Patterson,

Sears utilizza Carbon / Graphite / Ceres per memorizzare 4 milioni di punti dati unici al minuto. Non è perfetto e richiede cluster di grafite e SSD, ma funziona. Tutte le altre soluzioni là fuori non sono scalabili a questo livello, che abbiamo trovato, ma se hai idee, sentiti libero di entrare.

— Kevin J. Rice,

InfluxDB è un database open source scritto in Go. È stato scritto appositamente per gestire i dati delle serie temporali e hanno pubblicato benchmark che mostrano prestazioni molto migliori rispetto a Cassandra :

InfluxDB ha sovraperformato Cassandra in tutti e tre i test con un throughput di scrittura 4,5 volte maggiore, utilizzando allo stesso tempo 10,8 volte meno spazio su disco e offrendo tempi di risposta fino a 168 volte più veloci per le query testate.

— Dan Dascalescu
fonte

potresti voler controllare i database orientati alle colonne. Non sono sicuro di cosa intendi per database di array, ma con il mio approccio suggerito puoi avere un numero dinamico di valori per intervallo di tempo. Puoi anche avere più valori per lo stesso timestamp. La parte interessante è che se si hanno valori misurati nello stesso timestamp, è possibile salvarli come colonne aggiuntive (ad esempio un sensore che misura la temperatura e l'umidità, il prezzo di borsa e le dimensioni di un trade, ...). A causa della natura orientata alle colonne puoi avere tabelle con 100 colonne ma se la tua query accede solo a cinque colonne il database legge solo i dati delle cinque colonne.

Ho scritto una serie sulla creazione del tuo database di serie storiche, potresti dare un'occhiata:

— hellomichibye
fonte