AngularJS che si occupa di set di dati di grandi dimensioni (strategia)

Question

AngularJS che si occupa di set di dati di grandi dimensioni (strategia)

#1 da (1 voti)

2

Sto lavorando allo sviluppo di un visualizzatore di registrazione della temperatura personale basato sui miei dati di curvatura raspi nell'api del mio server web. Le temperature vengono prese ogni 2 secondi e posso avere diversi sensori di temperatura che inviano i dati. Inutile dire che avrò molti dati da gestire anche entro un'ora. Ho implementato una API di paginazione molto semplice dal server, quindi il server non ha timeout e al momento restituisce solo dati in 1000 unità per chiamata, quindi eseguendo il paging dei dati. Ho avuto l'idea di mostrare intenzionalmente gli ultimi 20 minuti di dati da un sensore (o tutti i sensori a seconda delle scelte dell'utente), quindi consentire all'utente di selezionare altri tempi da cui mostrare i dati. Il problema arriva quando si desidera visualizzare tutti i sensori o un periodo di tempo esteso (ad esempio 24 ore).

Esiste una best practice per gestire questa grande quantità di dati?

Sarebbe utile caricare quei primi 20 minuti nella visualizzazione live e quindi inserire nella cache l'archiviazione locale come le ultime 24 ore?

Non sono ancora riuscito a trovare una buona idea di questo in uso, anche se ci sono molti modi per risolvere questo problema. Sto solo cercando alcuni suggerimenti su ciò che potrebbe fornire un buon equilibrio tra buone prestazioni e non mettere in cache l'intero set di dati sul lato client (perché oltre una settimana di dati potrebbe non essere fattibile).

data angularjs caching

posta Brian 05.11.2013 - 21:54

fonte

1 risposta

Leggi altre domande sui tag data angularjs caching

Struttura CSS per la creazione di siti Web reattivi Rails: esempio utile di delegato e Law of Demeter

score 1 · Answer 1

Is there a best practice of handling this large amount of data?

Non sei sicuro delle "migliori pratiche", ma penso sarebbe una buona idea definire chiaramente cosa devi fare con i dati. Che cosa l'utente dovrà effettivamente vedere in qualsiasi momento? Istintivamente, 24 ore di punti dati ogni 2 secondi non sembrano gestibili in modo cognitivo. Forse avrai una media per 5 minuti, che dovrai tracciare? In tal caso, creo un'API che richiede queste medie in modo che il browser non debba occuparsi di tutti i dati. È possibile memorizzarli in cache sul server se necessario, per altre richieste. Se l'utente vedrà una sola schermata di temperature a grana fine in qualsiasi momento, quindi creare un'API che richieda la validità di dati di una sola schermata alla volta (simile all'API di paging).

Usare una valanga di informazioni alla volta è anche una buona strategia se hai molti legami di Angular: se finisci con 1000 di essi, le prestazioni dell'interfaccia diminuiranno.

I am just looking for some suggestions as to what might provide a good balance between good performance and not caching the entire data set on the client side

Would it be useful to load those first 20 minutes into the live view and then cache into local storage something like the last 24 hours?

È sempre difficile decidere come ottimizzare prima di sapere esattamente dove si trovano i colli di bottiglia. Mantenere semplice il primo disegno è spesso una buona idea. Non creare il tuo livello di memorizzazione nella cache, almeno all'inizio: utilizza la cache integrata $ http e forse anche una strategia di caching aggressiva usando le intestazioni http, in modo che il browser possa memorizzare anche le richieste Ajax.