13

Ho iniziato a esaminare gli approcci alla sincronizzazione dei dati tra una serie di peer. I peer devono essere in grado di lavorare in modo disconnesso e quindi sincronizzarsi insieme per unire le loro modifiche locali.

I peer dovrebbero essere in grado di unire gli aggiornamenti locali con una "fusione a tre vie" . Quindi, alla sincronizzazione, i peer dovrebbero sapere quali fatti sono più recenti, ma dove non esiste un ordinamento rigoroso, dovrebbero essere in grado di unire i fatti in base alla radice comune.

Quando i peer indipendenti apportano modifiche, possono "timestamp" con un "orologio". Uso il termine "orologio" e "timestamp" ma non intendo un orologio da parete. Intendo una sorta di ordinamento parziale degli eventi che chiarisce la causalità. È la relazione "accaduta prima" tra gli eventi che forma un grafico aciclico diretto (DAG).

Sembra che il "solito" modo per fare questo ordinamento parziale sia usare un orologio vettoriale . Questi possono diventare molto grandi, tuttavia. Gli sviluppi più recenti come gli orologi ad albero ad intervalli forniscono una memorizzazione più compatta dei timestamp.

Ciò di cui non sono affatto chiaro è perché i protocolli di sincronizzazione apparentemente non "memorizzano" il DAG in modo esplicito. (O lo fanno?)

I peer possono creare indipendentemente un timestamp generando casualmente un UUID (o con altri mezzi, come <peer-name> + <local-monotonically-increasing-counter>). L'ordinamento di questo timestamp è del tutto chiaro per quel peer.

Quando 2 peer si sincronizzano tra loro, possono concordare un nuovo timestamp. Ancora una volta, l'ordine di questo timestamp è chiaro per entrambi i peer.

Ora è necessario passare tra i peer l'accaduto prima del DAG, ma i requisiti di archiviazione e larghezza di banda di questo sono piccoli. I punti temporali sono vertici grafici. Come tali hanno 1 o 2 fronti in entrata (1 per un evento su un client e 2 per una sincronizzazione tra client). Questo è limitato e indipendente dal numero di peer nella rete.

Per utilizzare un singolo punto temporale, è necessario il grafico dei punti temporali che conducono a questo. Tuttavia, per quanto posso vedere, ogni peer che è in grado di conoscere di un punto temporale (che ha generato esso stesso, o generate con un altro peer, o è stato detto che da un altro peer durante la sincronizzazione con esso) ha anche avuto un'opportunità per conoscere la storia che porta a quel momento. Penso che ci sia probabilmente una prova induttiva per questo.

Dato che archiviare e sincronizzare il DAG sembra esplicitamente semplice: viene utilizzato nella pratica? In caso contrario, perché sono preferiti gli orologi vettoriali?

Appunti

Peer to peer

Preferirei una soluzione peer to peer su una soluzione server client.

La probabile topologia finale saranno molti client che si connettono a un gruppo molto più piccolo di server che si replicano tra loro. Tuttavia, sarebbe bello avere una soluzione generale che supportasse questa particolare topologia piuttosto che una soluzione che richiede questa specifica topologia.

synchronization

— Benjohn
fonte

Potrei fraintendere quello che stai dicendo, ma non è chiaro come un grafico di tutti gli eventi che portano a uno stato possa essere più piccolo di un vettore di contatori. A meno che non ci si trovi in un sistema che ha un numero estremamente elevato di nodi e un numero estremamente piccolo di modifiche.

— kdgregory,

Grazie @kdgregory - buon punto. Per poter calcolare una fusione a tre vie in futuro, è necessario conoscere il passato (ed essere in grado di determinare il DAG dei punti temporali passati). Quindi, se stai memorizzando quei punti del tempo passato, archiviare esplicitamente il DAG è più economico. Se si non memorizzano i punti di tempo passato, allora non è possibile calcolare una fusione a tre vie dei dati in ogni caso. - Mi chiedo se questo requisito a tre vie potrebbe essere la cosa giusta? Se non vuoi un modo a 3 vie, forse gli orologi vettoriali sono meglio del DAG esplicito?

— Benjohn,

Penso che questo potrebbe essere il punto cruciale @kdgregory, quindi ho aggiunto un po 'di questo alla domanda. Suppongo che sia possibile eseguire un'unione a 3 vie, il che implica anche che tutta la storia è nota. Se tutta la storia è nota, allora (credo) un DAG esplicito è più economico. Se la storia viene troncata, allora gli orologi vettoriali sono probabilmente l'approccio meno costoso.

— Benjohn,

1

Sì, la mia comprensione degli orologi vettoriali è che sono intesi semplicemente per una decisione di accettazione / rifiuto: "il nodo C sta provando ad aggiornare questo dato, ma non è a conoscenza dell'aggiornamento del nodo B".

— kdgregory,

1

Per quanto ne so, i sistemi di controllo della versione come Git e Mercurial usano l'approccio DAG piuttosto che i clock vettoriali.

— bikeman868
fonte

1

Senza una spiegazione, questa risposta potrebbe diventare inutile nel caso in cui qualcun altro pubblichi un'opinione opposta. Ad esempio, se qualcuno pubblica un reclamo come "I sistemi di controllo della propulsione come Git e Mercurial usano orologi vettoriali anziché l'approccio DAG" , in che modo questa risposta aiuterebbe il lettore a scegliere due opinioni opposte? Valuta di modificarlo in una forma migliore, per soddisfare gli standard di qualità di Come rispondere .

— moscerino

2

Nel modo in cui ho capito la domanda, mi stavano chiedendo se ci sono esempi nel mondo reale di dove viene utilizzato DAG piuttosto che orologi vettoriali.

— bikeman868,

1

Sia Git che Mecurial sono esempi reali di sincronizzazione peer to peer change con DAG, e spero che benjohn troverà utile la mia risposta anche se l'hai votata.

— bikeman868

Ciao @ bikeman868 Ti ho votato per un netto 0 (scusa). La tua risposta è utile, anche se con incertezza! Mentre i riferimenti o le risposte autorevoli sono sempre carini, gli scambi di stack non lo impongono! Il tuo suggerimento ha senso con i punti nei commenti sulla domanda. Sembra che quando si desidera archiviare la cronologia ed essere in grado di unire le storie, allora un DAG è appropriato. Quando non memorizzi la cronologia e desideri la sincronizzazione e il consenso sullo stato corrente, gli orologi vettoriali sono ciò di cui hai bisogno.

— Benjohn

1

Dai un'occhiata al problema del consenso . A seconda dei requisiti dell'attività (quanto alla quantità di dati che hai, quanti nodi di sincronizzazione, quanto spesso ecc.) Le soluzioni esistenti a quel problema (come "Raft") potrebbero essere adatte al tuo caso.

Un altro approccio (forse tangenziale) a questo problema è la progettazione di un CRDT .

— battlmonstr
fonte

Braid HTTP sta tentando di creare un protocollo di sincronizzazione dello stato basato su CRDT tramite HTTP in aumento. Hanno una grande visualizzazione di un DAG temporale e di un DAG spaziale e di come questi due concetti si relazionano per arrivare a un'eventuale coerenza.

— Duane J,

-1

Il protocollo Aleph è un protocollo leaderless p2p che costruisce un DAG distribuito di insiemi di transazioni (o eventi) per consenso

https://arxiv.org/pdf/1908.05156

— ferranpujolcamins
fonte

È necessario espandere la risposta per mostrare come il protocollo di riferimento affronta i punti sollevati dalla domanda originale. È importante rendere le risposte autosufficienti, poiché ciò avvantaggia tutti coloro che si imbattono in questa domanda.

— BobDalgleish,

DAG esplicito invece di Vector Clocks per la sincronizzazione

Appunti

Peer to peer