Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
Questo articolo presenta un benchmark controllato che confronta le architetture di polling REST, WebSocket push e CockroachDB CDC per la sincronizzazione in tempo reale del database, rivelando che mentre il WebSocket push offre la latenza mediana più bassa e il polling REST fornisce ritardi prevedibili e limitati, il CDC offre mediane competitive ma soffre di una latenza della coda significativa a causa del batching e di specifiche incompatibilità di protocollo.
Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Nel mondo del software moderno, esiste un crescente desiderio di applicazioni che sembrino vivere sul proprio dispositivo, anche quando non si è connessi a Internet. Questo approccio, spesso chiamato software "local-first", permette di modificare un documento o aggiornare una lista mentre si è offline, con le modifiche in attesa di essere inviate a un server centrale una volta ripristinata la connessione. La sfida risiede nel momento in cui la connessione viene ripristinata: come decide il computer quale versione dei dati sia quella corretta, e quanto velocemente può aggiornare il server centrale senza far attendere l'utente? Affinché ciò funzioni fluidamente, il sistema ha bisogno di un modo affidabile per ascoltare le nuove informazioni e consegnarle istantaneamente. Se l'aggiornamento è troppo lento, l'utente percepisce un ritardo; se il sistema è troppo complesso, esaurisce la batteria o va in crash. La domanda fondamentale per gli ingegneri è come costruire questo meccanismo di ascolto: il dispositivo dovrebbe chiedere costantemente al server se è cambiato qualcosa, il server dovrebbe urlare immediatamente le modifiche, o il database stesso dovrebbe tenere un registro continuo di ogni azione da leggere in seguito?
Un ricercatore dell'Indian Institute of Technology Kharagpur si è proposto di testare queste tre comuni strategie fianco a fianco per vedere quale performi meglio in un ambiente controllato. Lo studio ha confrontato un metodo in cui il client controlla le modifiche a intervalli di tempo fissi, un metodo in cui il server invia le modifiche istantaneamente tramite una connessione permanente, e un metodo in cui il database trasmette un registro di ogni modifica ai sottoscrittori. Per garantire un test equo, il ricercatore ha costruito tre sistemi separati che apparivano identici all'utente ma utilizzavano ingranaggi interni differenti. Un sistema utilizzava un database standard con un semplice ciclo di "check-in". Un altro utilizzava lo stesso database ma aggiungeva un trigger che attivava un segnale nel momento esatto in cui avveniva una modifica. Il terzo sistema utilizzava un database distribuito differente, progettato per trasmettere la propria cronologia. L'obiettivo era misurare il tempo esatto impiegato da una modifica effettuata da un utente per viaggiare attraverso il sistema e apparire sullo schermo dell'ascoltatore, testando tutto, da un singolo utente fino a cinquanta utenti che scrivevano contemporaneamente.
I risultati hanno delineato un quadro chiaro di come ogni metodo si comporti sotto pressione. Il sistema che si basava sul server che "urlava" le modifiche istantaneamente tramite una connessione permanente si è rivelato il più veloce. Nei casi migliori, una modifica appariva sullo schermo dell'ascoltatore in soli due millisecondi e, anche quando cinquanta persone scrivevano contemporaneamente, il ritardo superava raramente i sessantatré millisecondi. Questo metodo manteneva la sua velocità sorprendentemente costante, con gli aggiornamenti più lenti che arrivavano comunque in meno di un quarto di secondo. Il metodo che si basava sul client che chiedeva aggiornamenti ogni cento millisecondi era prevedibile ma più lento. Poiché il client doveva attendere il proprio turno per chiedere, il ritardo medio era di circa sessanta millisecondi, ma non poteva mai essere più veloce del tempo tra un controllo e l'altro. Quando molti utenti scrivevano contemporaneamente, questo tempo di attesa cresceva, portando il ritardo medio a oltre cento millisecondi. Il sistema che utilizzava il registro interno delle modifiche del database mostrava una performance mista. Sebbene l'aggiornamento tipico arrivasse rapidamente, spesso in meno di un secondo, il sistema soffriva di gravi ritardi per i pochi aggiornamenti più lenti. Occasionalmente, una modifica impiegava più di due secondi per arrivare e, in alcuni casi, il ritardo raggiungeva i tre secondi e mezzo.
Il ricercatore ha scoperto che gli aggiornamenti più lenti nel sistema basato sul registro non erano un difetto dell'idea stessa di registrare le modifiche, ma il risultato di come il software specifico fosse connesso. Il sistema utilizzava un espediente per leggere il registro del database perché lo strumento di connessione standard non parlava correttamente la lingua del database. Questo espediente richiedeva l'avvio di un nuovo processo ogni volta che la connessione veniva interrotta, aggiungendo una pesante penalità di un secondo o quattro secondi al ritardo. Senza questo specifico ostacolo tecnico, il metodo basato sul registro avrebbe potuto performare molto meglio, ma in questo test, i lunghi ritardi lo rendevano inadatto per applicazioni che richiedono feedback istantaneo. Lo studio ha inoltre confermato una regola semplice per il metodo di controllo: più a lungo si attende tra un controllo e l'altro, maggiore diventa il ritardo medio. Se un sistema controlla ogni cinquanta millisecondi, l'attesa media è di circa trentasei millisecondi; se attende cinquecento millisecondi tra un controllo e l'altro, l'attesa media balza a oltre trecento millisecondi.
Queste scoperte offrono una guida pratica per costruire software che debba rimanere sincronizzato. Per le applicazioni in cui la velocità è critica, come gli strumenti di editing collaborativo dove gli utenti scrivono insieme in tempo reale, il metodo in cui il server invia le modifiche istantaneamente è la scelta evidente. Offre il minor ritardo e la prestazione più costante, anche quando molte persone stanno usando il sistema contemporaneamente. Il metodo in cui il client controlla gli aggiornamenti a intervalli regolari è un'opzione solida per applicazioni più semplici dove un ritardo di qualche centesimo di secondo è accettabile, o dove mantenere la connessione aperta è difficile, come sui dispositivi mobili che cercano di risparmiare la batteria. Il metodo che trasmette il registro del database è potente per spostare grandi quantità di dati o creare backup, ma l'implementazione specifica testata qui era troppo lenta e imprevedibile per l'uso interattivo. Lo studio conclude che, sebbene tutti e tre i metodi funzionino, la scelta migliore dipende interamente se la priorità sia la reattività istantanea o la semplicità operativa.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.