Quale struttura dati utilizzare per la memorizzazione temporanea di dati di sensori intermittenti e asincroni?

Question

Quale struttura dati utilizzare per la memorizzazione temporanea di dati di sensori intermittenti e asincroni?

#1 da (2 voti)

1

Ecco una descrizione della configurazione:

Dati di input: Ho diverse fonti per i dati di input del sensore (GPS e una serie di altri dati di sensori provenienti da fonti diverse).

Tutti i singoli input sono costituiti da un timestamp, il nome dell'input e il valore.
Non esiste un elenco definito di input, ma possono apparire nuovi input il cui nome non era noto prima. Anche gli input possono scomparire di nuovo.
Il tasso di aggiornamento degli Input non è né predeterminato né fisso. Potrebbe essere periodico o sporadico, ma non conosciamo la sua recidiva prima e anche questo è soggetto a modifiche.

Il mio obiettivo:
Voglio riportare lo stato corrente degli Input (solo il valore più recente) in una ricorrenza fissa, ad es. ogni secondo, tramite MQTT a un server.
Non è necessario memorizzare i dati di input dopo aver inviato il messaggio MQTT. Quando uno specifico ingresso del sensore non è disponibile per diversi secondi, non deve più far parte del messaggio MQTT.

Il mio problema:
Come immagazzino i dati di input prima di inviare l'attuale "istantanea" nella recidiva fissa al server MQTT?

La mia soluzione corrente (?! brutto hack?!):

Ogni volta che viene visualizzato un nuovo valore di input del sensore, scrivo il timestamp e il valore in un file con il nome dell'ingresso del sensore in una singola cartella che viene utilizzata per tutti gli input.
Se il file esiste già, lo sovrascrivo semplicemente, poiché è importante solo il valore più recente del sensore.
Per non avere troppo vecchi dati di input del sensore in giro, rimuovo i file che sono stati creati più di un numero definito di secondi fa.
Esempio: Ingresso del sensore La latitudine GPS è memorizzata nel file latitude.dat , che ha una riga contenente il timestamp e il valore di latitudine:

pi@raspberrypi ~ $ cat latitude.dat 1534448235 46.2439877495

La soluzione funziona ed è abbastanza flessibile da gestire questo compito, ma non ne sono affatto felice. Ho pensato di usare un database SQL, ma in qualche modo penso a causa della natura degli input, non è nemmeno adatto. Qualcuno ha una buona idea, quale altra struttura dati potrei usare per la memorizzazione dei dati di input?

Modifica I dati del sensore non devono sopravvivere a un'interruzione di corrente.

database data-structures relational-database data

posta oh.dae.su 16.08.2018 - 21:48

fonte

1 risposta

Leggi altre domande sui tag database data-structures relational-database data

Come elaborare enormi quantità di dati con risorse di elaborazione limitate? [chiuso] Uso dei generici sulle interfacce quando l'implementazione non è generica

score 2 · Accepted Answer

Se hai solo bisogno di riportare l'ultimo valore e nient'altro, cioè nessun dato storico, allora tutto ciò di cui hai bisogno è un semplice, non gerarchico, valore-chiave con il nome del sensore come chiave e il valore del sensore come il valore e ignora semplicemente i timestamp.

Non è necessario distinguere tra sensori esistenti e nuovi. Se arriva una lettura del sensore, hai solo la chiave del valore. Se si tratta di un sensore esistente, questo sovrascriverà il valore esistente, se si tratta di un nuovo sensore, ciò creerà una nuova coppia valore-chiave.

Nota, questo rende alcuni presupposti:

i timestamp sono irrilevanti
le letture del sensore non arriveranno fuori servizio
le letture e le scritture sono atomiche OPPURE una sola lettura del sensore non aggiornata non ha importanza
non devono necessariamente essere coerenti su tutti i sensori

Se le letture del sensore possono arrivare fuori ordine, è necessario anche memorizzare il timestamp e confrontare il timestamp nella lettura con quello memorizzato nel database per assicurarsi che la lettura appena arrivata sia effettivamente più recente.

Ovviamente, se i timestamp fanno parte del report del sensore, è necessario memorizzarli anche.

Se le letture e le scritture non sono atomiche, allora può succedere che la parte di reporting del sistema legga un valore di sensore proprio mentre la parte che legge il sensore lo sta scrivendo. In questo caso, devi bloccare quella particolare coppia chiave-valore durante la lettura / scrittura, o rischiare di inviare valori di sensore corrotti o almeno non aggiornati.

Se il report del sensore deve essere coerente, ovvero i valori dei sensori tutti devono essere i più recenti a un determinato timestamp, è necessario bloccare l'intero intero database quando si invia un report.

Se si esegue o meno questa memoria, disco su disco, eventualmente su disco e quali sono i modelli di consistenza, dipende dalle proprie esigenze. Il database deve sopravvivere a un'interruzione di corrente? O è giusto inviare un paio di rapporti vuoti fino a quando tutti i sensori non hanno inviato nuovi aggiornamenti?