Salvataggio su file prima di archiviare in un database in un servizio REST

Question

Salvataggio su file prima di archiviare in un database in un servizio REST

#1 da (2 voti)
#2 da (1 voti)

0

Un back-end mobile che sto costruendo dovrebbe ricevere una quantità maggiore di dati (alcune registrazioni di sensori) da un telefono Android. Il telefono non ha molto uso di esso, quindi è stato più efficiente memorizzare i dati in file semplici (SQLite può diventare piuttosto lento con importi maggiori). Ora, quando carichiamo i dati su un servizio REST supportato da un database distribuito, abbiamo un altro problema. La memorizzazione richiede tempo, poiché è davvero molto. Ho pensato di caricare il file sul servizio web il più velocemente possibile, di lasciare solo il telefono, di mettere il file in cache da qualche parte sul server e poi alcuni lavoratori di lunga data raccoglieranno i dati e li ridurranno in database. Abbiamo altri meccanismi per verificare che i dati siano archiviati correttamente e così via, ma ciò non è importante.

Mi piacerebbe sapere che l'approccio al database REST- > file- > è valido? La mia preoccupazione è dove archiviare il file? Disco, qualche database in memoria, una cache? I server Web non riescono (possiamo richiedere un nuovo caricamento, ma preferirei mitigare il rischio in precedenza), altrimenti il server potrebbe essere ingombrante. Ho paura che lo spazio di archiviazione locale sui server Web non si adatti in modo ottimale, se disponiamo di più server e dipendenti.

Grazie in anticipo.

java database rest web-services upload

posta Aleksandar Stojadinovic 15.01.2015 - 17:07

fonte

2 risposte

2

Potresti prendere in considerazione un servizio di Accodamento messaggi come Rabbit MQ, questo ti consentirebbe di inviare dati a un server che lo manterrebbe semplicemente finché non avrai a disposizione un consumatore / lavoratore per elaborarlo. Dovresti considerare cose come l'utilizzo della memoria sul server dei messaggi se i tuoi set di dati sono molto grandi (o trovare un modo per inviare i dati in blocchi più piccoli), ma supporta cose come la persistenza dei messaggi (salvando i dati sul disco prima di viene elaborato, ovvero i dati non vengono persi se il server muore) e il clustering se il tuo utilizzo lo richiede.

Se ciò non è possibile, la tua idea di base di REST Upload > Store on Disk > Process in to DB è perfettamente valida, se sei preoccupato per la perdita di dati puoi applicare processi di ridondanza standard allo spazio di archiviazione (replica ecc.) e dovresti assicurarti che Process in to DB stage elimina i file caricati quando non sono più necessari.

risposta data 15.01.2015 - 17:36

fonte

Leggi altre domande sui tag java database rest web-services upload

Analisi statiche per trovare le incoerenze tra maiuscole / maiuscole nei nomi dei file Stato globale dei giochi (o altro). Esempio: Attesa, Scommessa, Battaglia nel gioco d'azzardo

score 1 · Accepted Answer

È perfettamente valido e viene solitamente fatto in situazioni come quella che hai. Altri hanno suggerito code di messaggi, che sono carine, ma occupano memoria o finiscono per scrivere i dati in un backing store, quindi ora hai un altro livello di software che fa ciò che potresti fare direttamente. Detto questo, potrebbe essere più semplice e più pulito usare l'API di una coda di messaggi invece di lanciare la propria soluzione; tutto dipende dall'ambiente e dai requisiti di prestazione. Immagino che la coda dei messaggi fornisca una separazione più chiara delle preoccupazioni, ma dovrai determinare da solo se ci sarà un successo in termini di prestazioni.