Situazione: Ho iniziato un nuovo lavoro e mi è stato assegnato il compito di capire cosa fare con la tabella dei dati del sensore. Ha 1,3 miliardi di file di dati del sensore. I dati sono piuttosto semplici: in pratica solo un ID sensore, una data e il valore del sensore in quel momento (doppio).Come archiviare e interrogare in modo efficiente un miliardo di righe di dati del sensore
Attualmente, i dati sono memorizzati in una tabella in un database MSSQL Server.
Entro la fine di quest'anno, mi aspetto che il numero di righe sia aumentato a 2-3 miliardi.
Sto cercando un modo migliore per archiviare e interrogare questi dati (per data), e dato che ci sono molti prodotti "big data", e non ho alcuna esperienza reale nella gestione di insiemi di dati così grandi, chiedo qui per qualsiasi suggerimento.
Non è una grande azienda, e le nostre risorse non sono illimitate;)
Alcuni dettagli sul nostro caso d'uso:
- vengono tracciati i dati in grafici e mostra i valori dei sensori nel tempo.
- Abbiamo in programma di creare un'API per consentire ai nostri clienti di recuperare i dati dei sensori per qualsiasi periodo di tempo a loro interesse (... i dati di 2 anni precedenti sono rilevanti quanto i dati del mese scorso).
La mia ricerca finora mi ha portato a considerare le seguenti soluzioni:
mantenere i dati in SQL Server
ma partizionare il tavolo (non è partizionato in questo momento). Ciò richiederà la versione enterprise di SQL Server, che costa molto.
Spostare i dati su SQL Server di Azure.
Lì avremo la funzione di partizionamento per un sacco di soldi in meno, ma una volta che il nostro database supera i 250 GB costa molto di più (e troppo oltre i 500 gb).
utilizzare diversi database
Potremmo usare 1 DB per cliente. Diversi DB più piccoli saranno meno costosi di 1 enorme DB, ma abbiamo un sacco di clienti e piani per di più, quindi non mi piace pensare di gestire tutti questi database.
Tabelle Azure
Questa è l'opzione che mi piace migliore finora. Possiamo suddividere i dati per azienda/sensore/anno/mese, utilizzare la data per il tasto riga e memorizzare il valore del sensore.
Non ho ancora avuto il tempo di testare le prestazioni della query, ma da quello che ho letto dovrebbe essere buono. Ma c'è uno svantaggio importante, ed è il limite di 1000 articoli restituiti per richiesta HTTP. Se abbiamo bisogno di recuperare tutti i dati del sensore per una settimana, dobbiamo fare un sacco di richieste HTTP. Non sono sicuro in questo momento di quanto grande sia il problema per il nostro caso d'uso.
Azure HDInsight (Hadoop in Azure)
Come detto non ho alcuna esperienza con grandi dei dati, e attualmente non ottenere Hadoop abbastanza bene per sapere se si adatta il nostro caso (esporre i dati dei sensori, per un dato un intervallo di tempo, tramite un'API). Dovrei scavare più a fondo e imparare o il mio tempo è trascorso meglio a perseguire un'altra alternativa?
Qualcuno ha esperienza di un caso simile. Cosa funziona per te? Tieni presente che il prezzo è importante e che una soluzione "semplice" potrebbe essere preferita a una soluzione molto complessa, anche se quella complessa ha risultati migliori di alcuni secondi.
UPDATE 1: Per rispondere ad alcune delle domande nei commenti seguenti.
- Ci sono circa 12.000 sensori, che potenzialmente possono segnalare un valore ogni 15 secondi. Ciò si traduce in ~ 70 milioni al giorno. In realtà, non tutti questi sensori hanno "report" attivati, quindi non riceviamo tutti quei dati ogni giorno, ma dal momento che naturalmente desideriamo espanderci con più clienti e sensori, ho davvero bisogno di una soluzione che possa scalare fino a molti milioni di valori di sensore al giorno.
- Il partizionamento è una soluzione, e l'utilizzo di diversi database e/o tabelle diverse è qualcosa che ho di sì, ma vedo questo come un fallback se/quando ho esaurito altre soluzioni.
- Ho letto altro su HBase, http://opentsdb.net/ e su google https://cloud.google.com/bigtable/ e sembra che Hadoop potrebbe essere una vera alternativa almeno.
UPDATE 2: Oggi ho sperimentato un po 'con entrambi Azure tavolo e HDInsight (HDI). Non richiediamo molto in termini di "flessibilità" delle query, quindi penso che Azure Table Storage appaia molto promettente. È un po 'lento estrarre i dati a causa del limite di 1000 articoli per richiesta, come ho detto, ma nei miei test penso che sia abbastanza veloce per i nostri casi d'uso.
Mi sono anche imbattuto in OpenTSDB, che è quello che mi ha portato a provare HDI in primo luogo. Dopo un'esercitazione su Azure (https://azure.microsoft.com/en-us/documentation/articles/hdinsight-hbase-tutorial-get-started/) sono riuscito a memorizzare un milione di record abbastanza rapidamente ea testare alcune query. È stato molto più veloce eseguire una query rispetto a Archiviazione tabelle di Azure. Potrei persino abbattere 300.000 record in una sola richiesta http (sono stati necessari 30 secondi).
Ma costa un po 'più di Azure Table Storage, e penso di poter ottimizzare il mio codice per migliorare le prestazioni delle query con Azure Table Storage (chiave di partizione a grana più fine e richieste in esecuzione in parallelo). Quindi ora sto pensando ad Azure Table Storage per la semplicità, il prezzo e le prestazioni "abbastanza buone".
Ho intenzione di presentare le mie scoperte a un consulente esterno al più presto, quindi sono entusiasta di conoscere il suo punto di vista sulle cose pure.
Prima di provare qualsiasi cosa, leggere su [tabelle partizionate] (https://msdn.microsoft.com/en-us/library/ms190787.aspx) in SQL Server. O se si intende memorizzare i dati su più server, leggere su [viste partizionate] (https://msdn.microsoft.com/en-us/library/ms187956.aspx) (vedere la sezione * Viste partizionate *). –
Si parla di clienti ... Se i dati del sensore si trovano in un'unica grande tabella senza un ID cliente, in che modo il cliente è vincolato a questo? Esiste una mappatura con il sensore? Perché sto chiedendo: immagino che le tue query non verranno interrogate su tutti i clienti ma sempre sui dati di un cliente specifico, giusto? Se sì: quante righe ci sono per ogni cliente? Potresti pensare a una tabella per ogni cliente, tutti con la stessa struttura, indici, vincoli ... Ciò richiederebbe un TVF con SQL dinamico, il resto potrebbe rimanere lo stesso ... – Shnugo
Inoltre, se richiedi regolarmente uno standard insieme di aggregati da segnalare, ricerca Viste indicizzate che gestiranno interamente il processo di memorizzazione nella cache, in un indice separato, vari aggregati predefiniti. –