Eventuale coerenza in inglese semplice


130

Sento spesso l'eventuale coerenza in diversi discorsi su NoSQL, griglie di dati, ecc. Sembra che la definizione di eventuale coerenza vari in molte fonti (e forse dipenda anche da una memoria di dati concreta).

Qualcuno può dare una semplice spiegazione di quale eventuale coerenza è in termini generali, non correlata a una memorizzazione dei dati concreta?


1
Ad esempio Wikipedia non ha aiutato? en.wikipedia.org/wiki/Eventual_consistency
Oliver Charlesworth

22
@OliCharlesworth: no. Forse sono solo io, ma è assolutamente poco chiaro anche dopo aver letto due volte.
Romano

Risposte:


228

Consistenza finale:

  1. Guardo il bollettino meteorologico e apprendo che domani pioverà.
  2. Ti dico che domani pioverà.
  3. Il tuo vicino dice a sua moglie che domani ci sarà il sole.
  4. Di 'al tuo vicino che domani pioverà.

Alla fine, tutti i server (tu, io, il tuo vicino) conoscono la verità (che domani pioverà), ma nel frattempo il cliente (sua moglie) è venuto via pensando che sarebbe soleggiato, anche se lei ha chiesto dopo che uno o più server (io e te) avevano un valore più aggiornato.

A differenza della rigorosa coerenza / conformità ACID:

  1. Il tuo saldo bancario è di $ 50.
  2. Depositi $ 100.
  3. Il tuo saldo bancario, richiesto da qualsiasi bancomat ovunque, è di $ 150.
  4. Tua figlia ritira $ 40 con la tua carta bancomat.
  5. Il tuo saldo bancario, richiesto da qualsiasi bancomat ovunque, è di $ 110.

In nessun momento il tuo saldo può riflettere altro che la somma effettiva di tutte le transazioni effettuate sul tuo conto in quel preciso momento.

Il motivo per cui così tanti sistemi NoSQL hanno un'eventuale coerenza è che praticamente tutti sono progettati per essere distribuiti e con sistemi completamente distribuiti c'è un sovraccarico super-lineare per mantenere una coerenza rigorosa (il che significa che puoi ridimensionare così tanto prima che le cose inizino a rallentare down, e quando lo fanno è necessario lanciare esponenzialmente più hardware al problema per mantenere il ridimensionamento).


Non capisco. La crescita è lineare o esponenziale?
Maciek Kreft,

4
La crescita nell'overhead di comunicazione di un sistema di N nodi strettamente coerenti è generalmente considerata super-lineare (cioè più che lineare). Potrebbe essere esponenziale, potrebbe essere cubico ... Dipende dal protocollo di comunicazione, ecc.
Chris Shain,

2
Buona risposta. Alcune domande di follow-up: non è "cattivo" che le richieste a un server possano ottenere informazioni errate / non aggiornate? Le persone stanno bene o c'è una soluzione per questo? Inoltre, come vengono infine replicati i dati su server diversi? Se uno dei server si è arrestato e i dati vengono replicati su tutti i server, se quel server viene ripristinato, come li aggiorna?
noblerare,

5
@noblerare è "cattivo" per vari gradi di cattiveria. Sarebbe molto brutto se il mio saldo ATM non fosse aggiornato. È meno male se il mio database di registrazione non è abbastanza raggiunto, o se il mio feed di Facebook è indietro di qualche secondo. I meccanismi di replica e durata dei dati sono molto vari e dipendono dalla piattaforma specifica. Per Cassandra (come esempio) lo scrittore può decidere se una determinata scrittura ha successo deve essere impegnata su uno, tutti o un quorum (maggioranza) di nodi. HBase adotta un approccio diverso, in cui un nodo particolare è il "master" per ogni riga di dati.
Chris Shain,

In realtà, la maggior parte dei sistemi bancari sono infine coerenti.
Caos,

106

Consistenza finale:

  1. I tuoi dati vengono replicati su più server
  2. I tuoi clienti possono accedere a qualsiasi server per recuperare i dati
  3. Qualcuno scrive un dato su uno dei server, ma non è stato ancora copiato nel resto
  4. Un client accede al server con i dati e ottiene la copia più aggiornata
  5. Un client diverso (o anche lo stesso client) accede a un server diverso (uno che non ha ancora ricevuto la nuova copia) e ottiene la vecchia copia

Fondamentalmente, poiché ci vuole tempo per replicare i dati su più server, le richieste per leggere i dati potrebbero andare a un server con una nuova copia, quindi a un server con una vecchia copia. Il termine "eventuale" significa che alla fine i dati verranno replicati su tutti i server, e quindi avranno tutti la copia aggiornata.

L'eventuale coerenza è indispensabile se si desidera leggere a bassa latenza, poiché il server di risposta deve restituire la propria copia dei dati e non ha tempo di consultare altri server e raggiungere un accordo reciproco sul contenuto dei dati. Ho scritto un post sul blog spiegando questo in modo più dettagliato.


2
Bel post sul blog. Vale la pena leggere per qualcuno di nuovo all'idea di eventuale coerenza. Questa risposta sarebbe migliore se fosse riscritta per spiegare di più di ciò che è nel post del blog.
axiopisty,

1
Ben spiegato nel tuo blog. Grazie per la condivisione.
Ataur Rahman Munna,

12

Pensi di avere un'applicazione e la sua replica. Quindi devi aggiungere un nuovo elemento di dati all'applicazione.

inserisci qui la descrizione dell'immagine

Quindi l'applicazione sincronizza i dati con altri spettacoli di replica in basso

inserisci qui la descrizione dell'immagine

Nel frattempo il nuovo client otterrà i dati da una replica che non si aggiorna ancora. In tal caso, non è possibile ottenere dati aggiornati aggiornati. Perché la sincronizzazione richiede del tempo. In tal caso, alla fine non ha coerenza

Il problema è come possiamo infine coerenza ?

Per questo usiamo l'applicazione mediatore per aggiornare / creare / eliminare i dati e utilizzare la query diretta per leggere i dati. che aiutano a rendere alla fine la coerenza

inserisci qui la descrizione dell'immagine inserisci qui la descrizione dell'immagine


3

Quando un'applicazione apporta una modifica a un elemento di dati su una macchina, tale modifica deve essere propagata alle altre repliche. Poiché la propagazione del cambiamento non è istantanea, c'è un intervallo di tempo durante il quale alcune copie avranno il cambiamento più recente, ma altre no. In altre parole, le copie saranno reciprocamente incoerenti. Tuttavia, il cambiamento verrà eventualmente propagato a tutte le copie, e quindi al termine "eventuale coerenza". Il termine eventuale coerenza è semplicemente un riconoscimento del fatto che c'è un ritardo illimitato nella propagazione di una modifica apportata su una macchina a tutte le altre copie. L'eventuale coerenza non è significativa o rilevante nei sistemi centralizzati (copia singola) poiché non è necessaria la propagazione.

fonte: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf


1

In un inglese semplice, possiamo dire: sebbene il tuo sistema possa trovarsi in stati incoerenti, l'obiettivo è sempre di raggiungere la coerenza a un certo punto per ogni dato.


1

Eventualmente coerenza significa che le modifiche richiedono tempo per propagarsi e che i dati potrebbero non essere nello stesso stato dopo ogni azione, anche per azioni identiche o trasformazioni dei dati. Ciò può causare cose molto brutte quando le persone non sanno cosa stanno facendo quando interagiscono con un tale sistema.

Si prega di non implementare archivi di dati aziendali critici fino a quando non si comprende bene questo concetto. Il rovinare l'implementazione di un archivio dati di documenti è molto più difficile da correggere rispetto a un modello relazionale perché le cose fondamentali che verranno rovinate semplicemente non possono essere riparate in quanto le cose necessarie per risolverlo non sono presenti nell'ecosistema. Il refactoring dei dati di un negozio in volo è anche molto più difficile delle semplici trasformazioni ETL di un RDBMS.

Non tutti gli archivi di documenti sono creati uguali. Alcuni in questi giorni (MongoDB) supportano transazioni di un tipo, ma la migrazione dei datastore è probabilmente paragonabile alle spese di reimplementazione.

ATTENZIONE: gli sviluppatori e persino gli architetti che non conoscono o comprendono la tecnologia di un archivio di dati documentali e hanno paura di ammetterlo per paura di perdere il lavoro, ma sono stati formati in modo classico in RDBMS e che conoscono solo i sistemi ACID (quanto può essere diverso ?) e chi non conosce la tecnologia o non si prende il tempo per impararla, mancherà progettare un archivio di dati di documenti. Potrebbero anche provare a usarlo come RDBMS o per cose come la memorizzazione nella cache. Abbatteranno quelle che dovrebbero essere le transazioni atomiche che dovrebbero operare su un intero documento in pezzi "relazionali" dimenticando che la replica e la latenza sono cose, o peggio ancora, trascinando sistemi di terze parti in una "transazione". Lo faranno in modo che il loro RDBMS possa rispecchiare il loro lago di dati, indipendentemente dal fatto che funzionerà o meno, e senza test, perché sanno cosa stanno facendo. Quindi agiranno sorpresi quando gli oggetti complessi memorizzati in documenti separati come "ordini" hanno meno "articoli ordine" del previsto, o forse nessuno. Ma non succederà spesso, o abbastanza spesso, quindi avanzeranno. Potrebbero anche non colpire il problema in fase di sviluppo. Quindi, anziché riprogettare le cose, genereranno "ritardi", "tentativi" e "controlli" per falsificare un modello di dati relazionali, che non funzionerà, ma aggiungerà ulteriore complessità senza alcun vantaggio. Ma ormai è troppo tardi: la cosa è stata implementata e ora l'azienda ci sta lavorando. Alla fine, l'intero sistema verrà espulso e il dipartimento sarà esternalizzato e qualcun altro lo manterrà. Non funzionerà ancora correttamente, ma possono fallire in modo meno costoso rispetto al fallimento attuale.


0

La consistenza finale è più simile a uno spettro. Da un lato hai una forte coerenza e dall'altro hai un'eventuale coerenza. Nel mezzo ci sono livelli come Snapshot, leggi le mie scritture, staleness limitata. Doug Terry ha una bella spiegazione nel suo articolo sull'eventuale coerenza con il baseball .

Secondo me l'eventuale coerenza è sostanzialmente la tolleranza ai dati casuali in ordine casuale ogni volta che si legge da un archivio dati. Qualcosa di meglio di questo è un modello di coerenza più forte. Ad esempio, un'istantanea contiene dati non aggiornati ma restituirà gli stessi dati se letti di nuovo, quindi è prevedibile. A volte l'applicazione può tollerare dati non aggiornati per un determinato periodo di tempo oltre il quale richiede dati coerenti.

Se si guarda al significato di coerenza, si riferisce più all'uniformità o alla mancanza di deviazione. Quindi, in termini di sistemi non informatici, potrebbe significare tolleranza per variazioni impreviste. Potrebbe essere spiegato molto bene tramite ATM. Un bancomat potrebbe essere offline, quindi divergente dal saldo del conto rispetto ai sistemi principali. Tuttavia, esiste una tolleranza per la visualizzazione di saldi diversi per una finestra temporale. Una volta online, l'ATM può sincronizzarsi con i sistemi principali e riflettere lo stesso equilibrio. Quindi si potrebbe dire che un bancomat alla fine sia coerente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.