Strategia per mantenere l'efficienza dei dati in tempo reale

Se la lista è piccola e cambiata di frequente, potrebbe essere il migliore per consentire all'abbonato di consultare l'elenco completo di volta in volta. Tuttavia, se l'elenco è enorme e le modifiche si verificano raramente, è possibile registrare qualsiasi modifica all'elenco come una sequenza di comandi INSERT / UPDATE / DELETE sul server in una sorta di tabella commands . Ogni comando richiede un numero di sequenza, in ordine crescente, e l'abbonato dovrebbe ricordare quali comandi sono stati già elaborati nella cache locale. Quindi, quando un utente riceve una notifica che l'elenco "LID" è cambiato, invia una query come

SELECT * FROM commands 
  WHERE listid= :LID AND sequenceNumber>:lastSequenceNumber 
  ORDER BY sequenceNumber

al server e recupera solo i comandi di modifica dalla precedente query di quel tipo. Quindi elabora i comandi nella cache locale dell'elenco e aumenta "lastSequenceNumber" di conseguenza.

Si noti che questo funzionerà anche quando un utente perde una notifica o non riceve alcuna notifica. Gli abbonati possono semplicemente eseguire il comando di interrogazione ed elaborazione a intervalli di tempo regolari, questo funzionerà comunque. Le notifiche servono solo a mantenere bassa la latenza e il numero richiesto di roundtrip.

Se segui questo percorso, avrai anche bisogno di una strategia per iniziare nuovi abbonati a un elenco esistente, con una cache locale vuota. In questo caso, l'intera lista dovrebbe essere trasferita al sottoscrittore una volta, insieme all'ultimo numero di sequenza del comando finale che era già stato applicato all'elenco.

Se cerchi google per "Command pattern" o "CQRS" o "event sourcing", troverai ulteriori informazioni su queste strategie.

L'unico scopo della notifica è di notify.

La tua notifica dovrebbe fornire informazioni sufficienti al client in modo che il cliente possa decidere cosa deve fare per aggiornarsi, incluso il recupero di tutti i dati necessari dal database. È del tutto possibile che l'ID della lista che è cambiata sia tutto ciò di cui ha bisogno il cliente.

In generale, quando un utente effettua l'accesso, il suo client recupera sempre una nuova copia dei dati dal database. Pertanto, a meno che non si mantenga una sorta di cache locale nel client, non si deve ragionare sulle notifiche che si verificano quando un utente non è in linea.

Potresti memorizzare i dati in un'inutile, infrastruttura persistente . Ora, se si espone tale struttura ai client, una sincronizzazione consiste nel scaricare i nuovi nodi (ad esempio, nodi che non sono condivisi con la versione precedente). Ciò comporterà un numero di nodi proporzionale al "diff" tra le due versioni.

Questo significa che la tua notifica può essere proprio quella: una notifica. È possibile (ma non è necessario) includere un riferimento alla radice della nuova struttura con la notifica. Questo è sufficiente per fare riferimento a quella versione completa. Il cliente può quindi scegliere con precisione cosa scaricare.

Inoltre, un client può avviare una sincronizzazione senza notifica semplicemente chiedendo al server la root corrente. Ciò consente il caso in cui un cliente perde una notifica per qualche motivo.

Dato che descrivi i tuoi dati come una "lista", potresti trovare qualcosa come Radix bilanciato rilassato (RRB ) Alberi appropriati. Si potrebbe anche trarre ispirazione da Hinze e Patterson di " Finger alberi: un semplice general-purpose struttura dati ".