{"id":56365,"date":"2020-02-11T00:00:00","date_gmt":"2020-02-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike"},"modified":"2020-02-18T14:04:37","modified_gmt":"2020-02-18T11:04:37","slug":"highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Coerenza causale: dalla teoria alla pratica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La prossima conferenza HighLoad++ si terr\u00e0 il 6 e 7 aprile 2020 a San Pietroburgo.
\nDettagli e biglietti al link<\/a><\/noindex>. HighLoad++ Siberia 2019. Sala \u00abKrasnoyarsk\u00bb. 25 giugno, 12:00. Tesi e presentazione<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nA volte, i requisiti pratici entrano in conflitto con la teoria, dove non sono considerati aspetti importanti per un prodotto commerciale. In questa relazione viene presentato il processo di selezione e combinazione di diversi approcci per la creazione di componenti di Causal consistency basati su ricerche accademiche, in base ai requisiti di un prodotto commerciale. Gli ascoltatori apprenderanno gli approcci teorici esistenti riguardanti orologi logici, tracciamento delle dipendenze, sicurezza dei sistemi, sincronizzazione degli orologi, e perch\u00e9 MongoDB ha scelto determinate soluzioni.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (di seguito \u2013 MT):<\/b> \u2013 Parler\u00f2 di Causal consistency \u2013 una caratteristica su cui abbiamo lavorato in MongoDB. Lavoro nel gruppo dei sistemi distribuiti, l'abbiamo realizzata circa due anni fa.<\/p>\n

\"HighLoad++,
\n
\nNel processo, \u00e8 stato necessario familiarizzare con un gran numero di ricerche accademiche, poich\u00e9 questa caratteristica \u00e8 ben studiata. Si \u00e8 scoperto che nessun articolo soddisfa i requisiti di produzione di un database a causa delle esigenze piuttosto specifiche che possono esistere in qualsiasi applicazione di produzione.<\/p>\n

Parler\u00f2 di come, come consumatori della ricerca accademica, trasformiamo queste informazioni in qualcosa che possiamo poi presentare ai nostri utenti come un piatto pronto, facile e sicuro da usare.<\/p>\n

Causal consistency. Definiamo i concetti<\/h3>\n

\nPer iniziare, voglio dire a grandi linee cos'\u00e8 la Causal consistency. Ci sono due personaggi \u2013 Leonard e Penny (serie \u00abThe Big Bang Theory\u00bb):<\/p>\n

\"HighLoad++,
\n
\nSupponiamo che Penny sia in Europa, e Leonard voglia farle una sorpresa, una festa. E non trova idea migliore che rimuoverla dalla lista amici, inviando a tutti i suoi amici un aggiornamento sul feed: \u00abFacciamo una sorpresa a Penny!\u00bb (lei \u00e8 in Europa, mentre dorme, non vede nulla e non pu\u00f2 vederlo, perch\u00e9 non \u00e8 l\u00ec). Alla fine, elimina questo post, cancella dal \u00abFeed\u00bb e ripristina l'accesso, affinch\u00e9 lei non se ne accorga e non ci siano scandali.
\nTutto ci\u00f2 \u00e8 fantastico, ma supponiamo che il sistema sia distribuito e che gli eventi non siano andati come previsto. Pu\u00f2 accadere, ad esempio, che il vincolo di accesso di Penny si sia verificato dopo che questo post \u00e8 apparso, se gli eventi non sono correlati da legami di causa ed effetto. In effetti, questo \u00e8 un esempio di quando \u00e8 necessaria la coerenza causale per eseguire una funzione aziendale (in questo caso).<\/p>\n

In realt\u00e0, queste sono propriet\u00e0 piuttosto non banali dei database \u2013 molto pochi le supportano. Passiamo ai modelli.<\/p>\n

Modelli di Coerenza (Consistency Models)<\/h3>\n

\nChe cos'\u00e8 in realt\u00e0 un modello di coerenza nei database? Sono alcune garanzie che un sistema distribuito fornisce riguardo a quali dati e in quale sequenza il cliente pu\u00f2 ricevere.<\/p>\n

In linea di principio, tutti i modelli di coerenza si riducono a quanto un sistema distribuito assomigli a un sistema che funziona, ad esempio, su un solo nodo su un laptop. E quanto un sistema che funziona su migliaia di nodi geograficamente distribuiti assomiglia a un laptop, in cui tutte queste propriet\u00e0 vengono eseguite fondamentalmente in modo automatico.<\/p>\n

Pertanto, i modelli di coerenza si applicano solo ai sistemi distribuiti. Tutti i sistemi che esistevano in precedenza e funzionavano su un'unica scalabilit\u00e0 verticale non aveva tali problemi. C'era un solo Buffer Cache, e da esso veniva sempre letto tutto.<\/p>\n

Modello Strong<\/h3>\n

\nLa prima vera modello \u00e8 lo Strong (o la linea di rise ability, come viene spesso chiamato). Questo \u00e8 un modello di coerenza che garantisce che ogni modifica, non appena si riceve conferma che \u00e8 avvenuta, diventi visibile a tutti gli utenti del sistema.<\/p>\n

Questo crea un ordine globale di tutti gli eventi nel database. Questa \u00e8 una propriet\u00e0 di coerenza molto forte, ed \u00e8 anche molto costosa. Tuttavia, \u00e8 ben supportata. \u00c8 semplicemente molto costosa e lenta \u2013 viene utilizzata raramente. Questo si chiama rise ability.<\/p>\n

C'\u00e8 anche un'altra propriet\u00e0, pi\u00f9 robusta, supportata in 'Spanner' \u2013 chiamata Coerenza Esterna. Ne parleremo pi\u00f9 avanti.<\/p>\n

Causale<\/h3>\n

\nIl seguente \u00e8 Causal, proprio ci\u00f2 di cui parlavo. Tra Strong e Causal ci sono ancora alcuni sottolivelli, di cui non parler\u00f2, ma tutti si riducono a Causal. \u00c8 un modello importante perch\u00e9 \u00e8 il pi\u00f9 forte di tutti i modelli, la coerenza pi\u00f9 forte in presenza di reti o partizioni.<\/p>\n

I Causals sono la situazione in cui gli eventi sono legati da una relazione causale. Spesso vengono percepiti come Read your own rights dal punto di vista del cliente. Se un cliente ha osservato alcuni valori, non pu\u00f2 vedere i valori che erano nel passato. Inizia gi\u00e0 a vedere letture prefissate. Questo si riduce a una questione comune.
\nI Causals come modello di coerenza rappresentano un ordinamento parziale degli eventi sul server, in cui gli eventi da tutti i clienti sono osservati nella stessa sequenza. In questo caso: Leonard e Penny.<\/p>\n

Eventual<\/h3>\n

\nIl terzo modello \u00e8 la Eventual Consistency. Questo \u00e8 ci\u00f2 che supporta assolutamente tutti i sistemi distribuiti, il modello minimo che ha senso. Significa quanto segue: quando ci sono alcuni cambiamenti nei dati, a un certo punto diventano coerenti.<\/p>\n

In quel momento non dice nulla, altrimenti si trasformerebbe in External Consistency \u2013 sarebbe completamente un'altra storia. Tuttavia, \u00e8 un modello molto popolare, il pi\u00f9 comune. Per impostazione predefinita, tutti gli utenti dei sistemi distribuiti utilizzano proprio la Eventual Consistency.<\/p>\n

Voglio fornire alcuni esempi comparativi:<\/p>\n

\"HighLoad++,
\n
\nCosa significano queste frecce?<\/p>\n