Come gestire i dati in tempo reale dal punto di vista del database?

Ho un'idea in mente, ma mi confonde ancora l'area del database .

Immagina di voler mostrare dati in tempo reale e di utilizzare una delle più recenti tecnologie di browser ( socket Web - anche utilizzando browser più vecchi ), è molto facile mostrare a tutti gli osservabili (browser dell'utente) ciò che fanno tutti.

Remy Sharp ha un esempio della semplicità al riguardo.

Ma non riesco ancora a ottenere la parte del database, come potrei nutrirmi , immaginiamo (usando Remy Game Tron) che voglio salvare il percorso per ogni utente connesso in un database e se un client vuole vedere cosa sta succedendo un ritardo di 5 secondi , lo vedrà, non solo i 5 secondi fino a quel momento, ma la continuazione nel tempo ...

come posso interrogare un DB del genere?

SELECT x, y FROM run WHERE time >= DATEADD(second, -5, rundate);

non è il percorso consigliato giusto?

e tirando questo x in x time ... questo non è un vero feed di dati corretto?

Se qualcuno può aiutarmi a capire il punto di vista del database, lo apprezzerei molto.

I database relazionali sono ottimizzati per le relazioni. I database delle serie temporali sono ottimizzati per l'archiviazione e l'utilizzo di una serie di valori che cambiano nel tempo. Nel mondo industriale, chiamano questi "storici". Probabilmente il più famoso è il PI dell'OSI .

È possibile eseguire una query su un insieme di segnali per un determinato punto nel tempo, anche se non memorizza un valore per quel particolare punto (può interpolare tra punti noti).

Tuttavia, ogni query fornisce solo un singolo punto nel tempo. Devi ancora votare.

Continuando sul tema del database delle serie temporali, controlla openPDC (un concentratore di dati Phasor è specifico della rete elettrica, ma è uno storico delle serie temporali). Nello specifico, questa citazione:

utility di riproduzione in streaming che può essere utilizzata per riprodurre eventi dall'archivio storico locale ed estrarre set di dati di grandi dimensioni

È proprio quello che vuoi ... una specie di meccanismo di riproduzione.

Non penso che tu voglia davvero un database. Vuoi un sacco di FIFO.

Il tempo reale e il database non hanno nulla a che fare l'uno con l'altro.

Quando ho realizzato radar (e pompe di calore e sistemi di controllo navale) ho appreso che i dati in tempo reale vivono interamente in buffer e memoria condivisa.

I dati possono anche essere inviati a un database per successive analisi e recupero. Il volume deve essere piccolo, quindi i riepiloghi o i digest o i campioni di dati vanno nella memoria persistente.

I dati in tempo reale effettivi, tuttavia, fluiscono attraverso la rete tramite code di messaggi per affidabilità o pacchetti UDP per notifiche istantanee (ma probabilmente fragili).

Inciampando su questa domanda penso che tu stia pensando a questo sbagliato, e le altre risposte non evidenziano davvero il problema.

Martellare il tuo database non è davvero una buona idea. Mentre sono abbastanza sicuro che tu l'abbia capito, altri potrebbero non averlo fatto. Ricordo che un mio amico ha provato a utilizzare uno script php e una funzione Javascript AJAX in un ciclo per un gioco semi-real time. Si rese conto molto rapidamente che le prestazioni peggioravano quando si univano più persone, semplicemente perché stava eseguendo una tonnellata di query al secondo che martellavano il database.

Per come la vedo io, ci deve essere un'applicazione di lunga durata che si trova tra l'utente e il database. Gli utenti si connettono direttamente a questa applicazione e passano tutte le sue informazioni all'app. Questa app li copia immediatamente le informazioni a tutti coloro che vi sono connessi. Questo si carica in un'app molto leggera, poco traffico e in tempo reale.

Se è necessario utilizzare un database, l'app deve quindi gestirlo in una coda di aggiornamenti in background. Ovviamente devi scegliere ciò che salvi perché non vuoi martellare il database con un muro di piccoli frammenti di informazioni (come la posizione corrente di un utente in un gioco), che ti riporta allo stesso problema che hai iniziato con. Invece della posizione, memorizzare la distanza percorsa per 5 secondi o altre informazioni più significative

Questo sito ha alcune funzionalità "in tempo reale". Scoprirai che molti siti ad alto traffico hanno molti giochi tra il web server e il database. Redis è qualcosa che puoi usare per conservare i dati in memoria. Sono sicuro che ce ne sono altri per varie pile.

Penso che Firebase.com sia un ottimo servizio di dati in tempo reale (non sono sicuro di cosa facciano per l'effettivo back-end del database, ma dato che lo servono, non sono sicuro che mi interessi davvero oltre la curiosità.).