Calcolo del Riepilogo del viaggio effettuato da un veicolo e Inserimento nella cache del database

Question

Calcolo del Riepilogo del viaggio effettuato da un veicolo e Inserimento nella cache del database

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Questo è più che altro un punto nella giusta direzione del tipo di domanda, ho 2 soluzioni ma entrambe non sono valide perché i dati calcolati non sono validi in alcuni scenari.

Sto lavorando su un sistema in cui un veicolo invia letture di posizione a un server TCP.

Tutti questi dati vengono archiviati in una tabella Log di posizione con i seguenti dati:

Latitude, Longitude, Speed, DateTime, Event, Address (and other relevant data)

Un evento può essere periodico, accensione attivata, ignizione disattivata, velocità eccessiva, frenatura brusca, accelerazione aspra, tornitura dura ecc.

Ora tutti i miei rapporti sono generati in base all'intero viaggio. Un viaggio sarebbe costituito da tutti i registri della posizione tra Ignition On e Ignition Off .

Quindi un semplice rapporto sarebbe

Vehicle ID  
Journey Start Date Time   
Journey End Date Time  
Start Address 
End Address 
Distance Travelled (KM) 
Journey Duration  
No. Overspeedings 
No. Harsh Turnings  
Average Speed  
Max Speed

Ora ogni volta che creo un rapporto, passa alla tabella LocationLog e calcola tutti i viaggi durante un intervallo di date.

Che è un processo costoso quando ci sono 300 veicoli che fanno 50 viaggi al giorno nell'arco di 3 mesi, quando c'è un registro di posizione ONE al minuto.

La mia domanda è questa,

Qual è il modo migliore per calcolare e cache questi viaggi su una tabella separata? Perché una volta completato il viaggio, le proprietà non cambieranno.

Ho implementato entrambe le soluzioni seguenti - Ma entrambe non funzionano.

1 - Ogni volta che c'è un evento di Ignition Off - sparo un evento per calcolare i dettagli del viaggio e la cache nel database.

QUESTO NON FUNZIONA - Perché in alcuni casi gli Eventi Accensione / Spegnimento Accensione sono ricevuti prima di inviare Letture Periodiche. [Le letture periodiche hanno una priorità inferiore rispetto a Eventi]

Questo sta causando calcoli non validi di Distanza, Numero di sovravelocità ecc. perché saranno ricevuti dopo che il dispositivo ha inviato le letture di Accensione.

2 - Ho sviluppato un servizio Windows che esegue un'attività giornaliera - Che calcola i viaggi per l'intera giornata e li memorizza nella cache del database.

QUESTO NON FUNZIONA - Perché in alcuni casi il veicolo viaggia durante la notte, il che non consente di calcolare e memorizzare nella cache il viaggio in particolare.

Le tecnologie di questo progetto sono: C #, .NET, Entity Framework, SQL Server 2016.

design database architecture performance caching

posta Dawood Awan 17.08.2018 - 00:15

fonte

3 risposte

Leggi altre domande sui tag design database architecture performance caching

Quando si crea un fornitore per un oggetto meno costoso rispetto alla creazione dell'oggetto stesso? Come confrontare le prestazioni del software nelle stesse condizioni (RAM, caching della CPU, ecc.)?

score 1 · Answer 1

Sono d'accordo con tutto ciò che dice @candied_orange. Inoltre:

Non hai menzionato se il messaggio invia ristabilire una nuova connessione TCP o tentare di continuare a utilizzare una connessione (presumo piuttosto la prima).

Devi mettere una specie di riquadro attorno agli eventi in arrivo in ritardo, e anche se è possibile, forse ancora ancora, essere pronti ad aggiornare il calcolo memorizzato nella cache quando arrivano gli eventi in ritardo (se il calcolo è avvenuto).

Questo non è diverso da un protocollo di rete orientato alla connessione come TCP, che rileva pacchetti fuori ordine, pacchetti scartati, ecc. - in breve, il problema potrebbe non essere completamente risolvibile senza apportare modifiche al protocollo dei messaggi degli eventi. (La differenza sta forse nel fatto che potresti desiderare tali funzionalità di protocollo in cima e tra le connessioni TCP, ad esempio a livello di applicazione.)

Se riesci a risolverli, forse puoi almeno sapere se hai ricevuto tutti gli eventi ed essere in grado di etichettare un livello di fiducia nel rapporto generato.

Se non riesci a risolvere questi problemi fissando il protocollo di messaggistica (supponendo che non abbia già le qualità necessarie), dovrai informare i consumatori di segnalazioni del potenziale di inesattezza dovuto a messaggi di eventi mancanti o in ritardo .

Un modo per mitigare sarebbe quello di offrire una notifica ai consumatori che un rapporto che avevano visualizzato fosse necessariamente aggiornato, nel caso di messaggi di eventi in ritardo. (Non so che cosa si potrebbe fare sui messaggi di evento rilasciati, se non c'è alcun numero di messaggio o qualcos'altro come TCP.)

Devi conoscere maggiori dettagli su cosa succede se

non è stato possibile inviare un evento periodico (ad esempio ricezione errata, assenza di Internet) durante lo spostamento, quindi l'auto è parcheggiata per un po 'dove non c'è la reception (ampio parcheggio). Dopo alcuni giorni, l'auto ritorna in un'area di buona ricezione internet. Invierà pacchetti molto tardi, ad es. giorni?
un messaggio evento viene rilasciato (mai ricevuto)

Un protocollo che rileva i messaggi mancanti e fuori ordine dovrebbe essere applicato in modo uniforme ai messaggi di tutte le priorità, in modo che, ad esempio, il messaggio di ignizione off indichi se ci sono (quanti) messaggi di eventi in sospeso ci sono.

score 1 · Answer 2

Le mie ipotesi sono:

1) Gli eventi sono memorizzati in una sorta di database RDBMS (come mySQL) o noSQL come MongoDB.

2) Gli eventi viaggiano da veicolo a server TCP tramite rete G4 o simili e non passano attraverso server intermedi, a parte i buffer dei messaggi del provider di telecomunicazioni.

3) La "casella" del veicolo impone la priorità del messaggio - inviando prima eventi non periodici.

4) La "casella" del veicolo aggiunge un timestamp a tutti i messaggi.

5) Il veicolo non aggiunge numeri di sequenza di viaggio a ciascun messaggio.

6) C'è anche la possibilità che singoli messaggi vengano persi del tutto per una serie di motivi.

Quindi si finisce con un registro dei messaggi in cui i messaggi possono essere 1) fuori servizio o 2) incompleti in un dato momento. Peggio è che potresti non sapere (in assenza di numeri di sequenza dei messaggi) che mancano i messaggi. Questi sono i motivi per cui le tue soluzioni non avranno una percentuale di successo del 100%.

In tale sistema non è possibile completare un rapporto di viaggio corretto al 100% mai , a causa della possibilità che uno o più eventi periodici manchino del tutto o siano ancora in transito.

Il modo migliore per gestire questo è aggiungere colonne "confidenziali" e "commenti" al tuo rapporto. Questo è il modo professionale per riconoscere che è impossibile essere corretti al 100%, mentre ti consente di indicare il tuo livello di confidenza + il motivo.

Puoi essere accettabilmente vicino al 100% sicuro di qualsiasi rapporto se esegui test per assicurarti che non vi siano ritardi non spiegati tra le letture GPS (il driver potrebbe aver dormito - o aver preso una rotta non approvata, ecc.)

Se un viaggio sembra incoerente, inseriscilo in un elenco separato e rielaboralo nella prossima esecuzione.

Puoi aumentare la tua certezza su qualsiasi rapporto di:

a) scansione della coda messaggi sul server TCP / IP per qualsiasi messaggio in transito (se si ha accesso alla coda).

b) controllare i numeri di sequenza dei messaggi (se il veicolo li trasmette)

c) eseguire controlli di coerenza su tutti i rapporti di viaggio per assicurarsi che abbiano senso e si può essere ragionevolmente sicuri che non manchi nulla.

Se fai tutto questo, avrai un sistema migliore, ma non sarà mai corretto al 100% per i motivi indicati.

Modifica

I controlli di consistenza dipendono davvero dalle regole aziendali (non hai menzionato ciò che fa la flotta). Tuttavia, ecco alcuni suggerimenti:

1) Verifica i viaggi contro i record di spedizione. cioè il viaggio eseguito corrisponde a ciò che è stato inviato all'autista?

2) Se vi è un lungo intervallo tra i record del periodo, calcolare la distanza percorsa (formula haversine) e il tempo impiegato, tra i messaggi del periodo successivo che sono stati ricevuti. Permettendo effetti "in linea d'aria" puoi valutare se la velocità media ha senso o no, o se mancano grossi pezzi di viaggio.

3) I viaggi sono suddivisi, ovvero l'unità ha spento il motore a metà viaggio causando l'avvio di un nuovo viaggio.

4) Se disponi di buoni protocolli end-to-end, emetterebbero avvisi se i messaggi venissero persi o ritardati. Controllare i log degli errori per i messaggi del server. A seconda del modo in cui i tuoi protocolli sono implementati e della tua capacità di comunicare con i box e il server del veicolo, potresti essere in grado di richiedere segnalazioni di messaggi non consegnati / ricevuti.

Buona fortuna!

score 0 · Answer 3

Registra tutti i dati che ottieni, così com'è.
Utilizza gli eventi di attivazione / disattivazione di Ignition come marker. Non come trigger di calcolo del rapporto.
Calcolo del rapporto di trigger quando i dati periodici mostrano che il veicolo è rimasto fermo per un determinato periodo di tempo. O solo quando qualcuno lo richiede.