{"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\/ro\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Urm\u0103toarea conferin\u021b\u0103 HighLoad++ va avea loc pe 6 \u0219i 7 aprilie 2020 \u00een Sankt Petersburg. <br \/>\nDetalii \u0219i bilete <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">la link<\/a><\/noindex>. HighLoad++ Siberia 2019. Sala \u201eKrasnoyarsk\u201d. 25 iunie, 12:00. Teze \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5253\">prezentare<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/cded9c5434d670db7295aadf5da0a9f1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe \u00eent\u00e2mpl\u0103 ca cerin\u021bele practice s\u0103 intre \u00een conflict cu teoria, unde nu sunt luate \u00een considerare aspecte importante pentru un produs comercial. \u00cen aceast\u0103 prezentare este prezentat procesul de selec\u021bie \u0219i combinare a diferitelor abord\u0103ri pentru crearea componentelor Causal consistency, bazat pe cercet\u0103ri academice, \u00een func\u021bie de cerin\u021bele unui produs comercial. Ascult\u0103torii vor afla despre abord\u0103rile teoretice existente pentru logical clocks, dependency tracking, system security, clock synchronization \u0219i de ce MongoDB a optat pentru anumite solu\u021bii.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><b>Mikhail Tyulenyev (\u00een continuare \u2013 MT):<\/b> \u2013 Voi vorbi despre Causal consistency \u2013 este o caracteristic\u0103 pe care am dezvoltat-o \u00een MongoDB. Lucrez \u00een grupul de sisteme distribuite, am realizat-o acum aproximativ doi ani.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/b8d0a5b64e715f53b033fa8c398e2eb4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen proces, a fost necesar s\u0103 ne familiariz\u0103m cu o cantitate mare de cercet\u0103ri academice, deoarece aceast\u0103 caracteristic\u0103 este destul de bine studiat\u0103. S-a constatat c\u0103 niciun articol nu se potrive\u0219te perfect cu ceea ce este necesar \u00een produc\u021bie, a\u0219a cum baza de date are cerin\u021be destul de specifice care sunt, cred, valabile pentru orice aplica\u021bie de produc\u021bie.<\/p>\n<p>Voi vorbi despre cum, fiind consumatori ai cercet\u0103rii academice, preg\u0103tim din aceasta ceva ce putem oferi utilizatorilor no\u0219tri ca un fel de preparat gata, de care este u\u0219or \u0219i sigur de folosit.<\/p>\n<h3>Causal consistency. S\u0103 stabilim conceptele<\/h3>\n<p>\nPentru \u00eenceput, vreau s\u0103 spun, \u00een linii mari, ce este Causal consistency. Sunt dou\u0103 personaje \u2013 Leonard \u0219i Penny (serialul \u201eTeoria Big Bang\u201d):<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/ee0835b604ae5d5d6c0fa1bc369e6b18.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u0103 presupunem c\u0103 Penny se afl\u0103 \u00een Europa, iar Leonard vrea s\u0103-i fac\u0103 o surpriz\u0103, o petrecere. \u0218i el nu g\u0103se\u0219te altceva mai bun dec\u00e2t s\u0103 o scoat\u0103 din lista de prieteni, s\u0103 trimit\u0103 tuturor prietenilor o actualizare pe feed: \u201eHai s\u0103 o surprindem pe Penny!\u201d (ea este \u00een Europa, dormind, nu vede nimic din toate acestea \u0219i nu poate vedea, pentru c\u0103 nu este acolo). \u00centr-un moment final, \u0219terge aceast\u0103 postare, o elimin\u0103 din \u201eFeed\u201d \u0219i restabile\u0219te accesul, astfel \u00eenc\u00e2t ea s\u0103 nu observe nimic \u0219i s\u0103 nu fie un scandal.<br \/>\nEste totul foarte frumos, dar s\u0103 presupunem c\u0103 sistemul este distribuit \u0219i evenimentele nu au decurs exact a\u0219a. Poate, de exemplu, s\u0103 se \u00eent\u00e2mple ca restric\u021bia access a lui Penny s\u0103 fi avut loc dup\u0103 ce acest post a ap\u0103rut, dac\u0103 evenimentele nu sunt legate \u00eentre ele prin rela\u021bii cauzale. \u00cen esen\u021b\u0103, acesta este un exemplu de c\u00e2nd este necesar\u0103 o consisten\u021b\u0103 cauzal\u0103 pentru a \u00eendeplini o func\u021bie de afaceri (\u00een acest caz).<\/p>\n<p>De fapt, acestea sunt propriet\u0103\u021bi destul de netriviale ale bazelor de date \u2013 foarte pu\u021bine dintre ele le sus\u021bin. S\u0103 trecem la modele.<\/p>\n<h3>Modelele de consisten\u021b\u0103 (Consistency Models)<\/h3>\n<p>\nCe este, de fapt, un model de consisten\u021b\u0103 \u00een bazele de date? Acesta sunt anumite garan\u021bii pe care un sistem distribuit le ofer\u0103 cu privire la ce date \u0219i \u00een ce ordine clientul poate ob\u021bine.<\/p>\n<p>Practic, toate modelele de consisten\u021b\u0103 se reduc la c\u00e2t de mult un sistem distribuit seam\u0103n\u0103 cu un sistem care func\u021bioneaz\u0103, de exemplu, pe un singur nod pe un laptop. \u0218i c\u00e2t de mult un sistem care func\u021bioneaz\u0103 pe mii de \"noduri\" geo-distribuite seam\u0103n\u0103 cu laptopul \u00een care toate aceste propriet\u0103\u021bi sunt \u00eendeplinite practic automat.<\/p>\n<p>De aceea, modelele de consisten\u021b\u0103 se aplic\u0103 doar sistemelor distribuite. Toate sistemele care existau anterior \u0219i func\u021bionau pe o scalare vertical\u0103 nu \u00eent\u00e2mpinau astfel de probleme. Aveau un singur Buffer Cache \u0219i din el se citea \u00eentotdeauna totul.<\/p>\n<h3>Modelul Strong<\/h3>\n<p>\nPractic, cel mai vechi model este Strong (sau linia de rise ability, cum este adesea numit). Este un model de consisten\u021b\u0103 care garanteaz\u0103 c\u0103 fiecare modificare, imediat ce se prime\u0219te confirmarea c\u0103 a avut loc, devine vizibil\u0103 pentru to\u021bi utilizatorii sistemului.<\/p>\n<p>Acest lucru creeaz\u0103 o ordine global\u0103 a tuturor evenimentelor \u00een Baza de Date. Aceasta este o proprietate de consisten\u021b\u0103 foarte puternic\u0103 \u0219i, \u00een general, foarte costisitoare. Totu\u0219i, este foarte bine sus\u021binut\u0103. Este pur \u0219i simplu foarte costisitoare \u0219i lent\u0103 \u2013 folosit\u0103 rar. Se nume\u0219te rise ability.<\/p>\n<p>Exist\u0103 o alt\u0103 proprietate, mai puternic\u0103, care este sus\u021binut\u0103 \u00een \u201eSpanner\u201d \u2013 numit\u0103 Consisten\u021b\u0103 Extern\u0103. Vom vorbi despre ea pu\u021bin mai t\u00e2rziu.<\/p>\n<h3>Causal<\/h3>\n<p>\nUrm\u0103toarele sunt Causal, exact despre ce vorbeam. \u00centre Strong \u0219i Causal exist\u0103 \u00eenc\u0103 c\u00e2teva subniveluri despre care nu voi discuta, dar toate se reduc la Causal. Este un model important, deoarece este cel mai puternic dintre toate modelele, cea mai puternic\u0103 consisten\u021b\u0103 \u00een prezen\u021ba unei re\u021bele sau a partition\u0103rii.<\/p>\n<p>Causal este situa\u021bia \u00een care evenimentele sunt legate printr-o rela\u021bie de cauzalitate. Adesea, acestea sunt percepute ca Read your rights din perspectiva clientului. Dac\u0103 clientul a observat anumite valori, el nu poate vedea valorile care au fost \u00een trecut. \u00cencep s\u0103 observe citirile prefixed. Totul se reduce la acela\u0219i lucru.<br \/>\nCausal ca model de consisten\u021b\u0103 reprezint\u0103 o ordonare par\u021bial\u0103 a evenimentelor pe server, \u00een care evenimentele din toate clien\u021bii sunt observate \u00een aceea\u0219i secven\u021b\u0103. \u00cen acest caz \u2013 Leonard \u0219i Penny.<\/p>\n<h3>Eventual<\/h3>\n<p>\nAl treilea model este Eventual Consistency. Acesta este ceea ce sus\u021bine toate sistemele distribuite, modelul minim care are sens. Aceasta \u00eenseamn\u0103 urm\u0103toarele: atunci c\u00e2nd avem anumite modific\u0103ri \u00een date, ele devin consistente la un moment dat.<\/p>\n<p>\u00cen acel moment, nu spune nimic, altfel ar deveni External Consistency \u2013 ar fi o poveste complet diferit\u0103. Cu toate acestea, este un model foarte popular, cel mai r\u0103sp\u00e2ndit. \u00cen mod implicit, to\u021bi utilizatorii sistemelor distribuite utilizeaz\u0103 Eventual Consistency.<\/p>\n<p>Vreau s\u0103 aduc c\u00e2teva exemple comparative:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/c23e59b30d96de6ec456aaa76c67ad61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe \u00eenseamn\u0103 s\u0103ge\u021bile acestea?<\/p>\n<ul>\n<li><b>Latenc\u0103.<\/b> Pe m\u0103sur\u0103 ce puterea consisten\u021bei cre\u0219te, aceasta devine mai mare din motive evidente: trebuie s\u0103 facem mai multe \u00eenregistr\u0103ri, s\u0103 primim confirm\u0103ri de la toate gazdele \u0219i nodurile implicate \u00een cluster, c\u0103 datele sunt deja acolo. Prin urmare, \u00een Eventual Consistency, r\u0103spunsul este cel mai rapid, deoarece de obicei se poate chiar comite \u00een memorie \u0219i acest lucru ar fi suficient.<\/li>\n<li><b>Disponibilitate.<\/b> Dac\u0103 \u00een\u021belegem asta ca pe capacitatea sistemului de a r\u0103spunde \u00een cazul \u00eentreruperilor de re\u021bea, partition\u0103ri sau diverse defec\u021biuni \u2013 rezilien\u021ba cre\u0219te odat\u0103 cu reducerea modelului de consisten\u021b\u0103, deoarece este suficient s\u0103 existe o gazd\u0103 activ\u0103 care s\u0103 ofere anumite date. Eventual Consistency nu garanteaz\u0103 nimic \u00een leg\u0103tur\u0103 cu datele \u2013 acestea pot fi orice.<\/li>\n<li><b>Anomalii.<\/b> \u00cen acest context, cu siguran\u021b\u0103, num\u0103rul anomaliilor cre\u0219te. \u00cen cazul Consisten\u021bei Puternice, acestea ar trebui s\u0103 fie practic inexistente, \u00een timp ce \u00een Consisten\u021ba Final\u0103, ele pot ap\u0103rea \u00een diverse forme. Se ridic\u0103 \u00eentrebarea: de ce aleg oamenii Consisten\u021ba Final\u0103, dac\u0103 aceasta con\u021bine anomalii? R\u0103spunsul este c\u0103 modelele de Consisten\u021b\u0103 Final\u0103 sunt aplicabile, iar anomaliile exist\u0103, de exemplu, pentru o scurt\u0103 perioad\u0103 de timp; exist\u0103 posibilitatea de a folosi un master pentru citire \u0219i a citi date consistente mai mult sau mai pu\u021bin; adesea exist\u0103 posibilitatea de a utiliza modele puternice de consisten\u021b\u0103. Practic, acest lucru func\u021bioneaz\u0103, iar de multe ori num\u0103rul anomaliilor este limitat \u00een timp.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Teorema CAP<\/h3>\n<p>\nC\u00e2nd auzi cuvintele consisten\u021b\u0103, disponibilitate - ce \u00ee\u021bi vine \u00een minte? Corect - Teorema CAP! Acum vreau s\u0103 demontez un mit\u2026 Nu sunt eu, ci Martin Kleppmann, care a scris un articol minunat, o carte minunat\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/02a9b84585218c4e85afd65f7e88aa26.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTeorema CAP este un principiu formulat \u00een anii 2000, referitor la Consisten\u021b\u0103, Disponibilitate, Parti\u021bii: ia oricare dou\u0103, iar nu po\u021bi alege trei. A fost un principiu general. A fost dovedit ca teorem\u0103 c\u00e2\u021biva ani mai t\u00e2rziu, de c\u0103tre Gilbert \u0219i Lynch. Apoi a \u00eenceput s\u0103 fie folosit ca o mantr\u0103 - sistemele au \u00eenceput s\u0103 se \u00eempart\u0103 \u00een CA, CP, AP \u0219i a\u0219a mai departe.<\/p>\n<p>Aceast\u0103 teorem\u0103 a fost dovedit\u0103 de fapt \u00een urm\u0103toarele cazuri\u2026 \u00cen primul r\u00e2nd, Disponibilitatea nu a fost considerat\u0103 ca o valoare continu\u0103 de la zero la o sut\u0103 (0 - sistemul este \u00abmort\u00bb, 100 - r\u0103spunde rapid; a\u0219a suntem obi\u0219nui\u021bi s\u0103 o consider\u0103m), ci ca o proprietate a algoritmului care garanteaz\u0103 c\u0103 \u00een toate execu\u021biile sale, acesta returneaz\u0103 date.<\/p>\n<p>Nu exist\u0103 nicio men\u021biune despre timpul de r\u0103spuns! Exist\u0103 un algoritm care returneaz\u0103 date dup\u0103 100 de ani - un algoritm disponibil complet splendid, care face parte din teorema CAP.<br \/>\n\u00cen al doilea r\u00e2nd: teorema a fost dovedit\u0103 pentru modific\u0103rile valorilor acelea\u0219i chei, sub cond\u021bia c\u0103 aceste modific\u0103ri sunt o linie redimensionabil\u0103. Aceasta \u00eenseamn\u0103 c\u0103, de fapt, ele sunt practic inutilizate, deoarece modelele sunt diferite: Consisten\u021ba Final\u0103, Consisten\u021ba Puternic\u0103 (posibil).<\/p>\n<p>Cu ce se termin\u0103 toat\u0103 asta? Cu faptul c\u0103 teorema CAP, exact \u00een forma \u00een care a fost dovedit\u0103, este practic inapplicabil\u0103, utilizat\u0103 rar. \u00cen forma teoretic\u0103, somehow restric\u021bioneaz\u0103 totul. Rezult\u0103 un principiu, care este intuitiv adev\u0103rat, dar nici cum, \u00een general, nu este dovedit.<\/p>\n<h3>Consisten\u021ba cauzal\u0103 este cel mai puternic model<\/h3>\n<p>\nCeea ce se \u00eent\u00e2mpl\u0103 acum este c\u0103 po\u021bi ob\u021bine toate cele trei lucruri: Consisten\u021b\u0103, Disponibilitate prin intermediul Partitions. \u00cen special, consisten\u021ba cauzal\u0103 \u2013 este cea mai puternic\u0103 model de consisten\u021b\u0103, care func\u021bioneaz\u0103 chiar \u0219i \u00een prezen\u021ba partition-urilor (discontinu\u0103ri \u00een re\u021bea). De aceea reprezint\u0103 un interes at\u00e2t de mare, de aceea ne ocup\u0103m de ea.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/c4320294320261858a6d22faa97b9e23.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen primul r\u00e2nd, simplific\u0103 munca dezvoltatorilor de aplica\u021bii. \u00cen special, exist\u0103 un suport mare din partea serverului: c\u00e2nd toate \u00eenregistr\u0103rile care se efectueaz\u0103 \u00een cadrul unui client ajung garantat \u00een aceea\u0219i ordine la cel\u0103lalt client. \u00cen al doilea r\u00e2nd, rezist\u0103 partition-urilor.<\/p>\n<h3>Buc\u0103t\u0103ria intern\u0103 a MongoDB<\/h3>\n<p>\n\u021ain\u00e2nd cont de faptul c\u0103 este pr\u00e2nz, ne mut\u0103m \u00een buc\u0103t\u0103rie. Voi vorbi despre modelul sistemului, \u0219i anume \u2013 ce este MongoDB pentru cei care aud pentru prima dat\u0103 despre o astfel de baz\u0103 de date.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/a1784442ff1c44403b5347f4f43a1197.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/a1f9bcb4daebb43e4fc848a5f5f07c60.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMongoDB (denumit\u0103 \u00een continuare \u00abMongoDB\u00bb) este un sistem distribuit care suport\u0103 scalarea orizontal\u0103, adic\u0103 sharding; \u0219i \u00een interiorul fiec\u0103rui shard, de asemenea, suport\u0103 redundan\u021ba datelor, adic\u0103 replicarea.<\/p>\n<p>Sharding-ul \u00een \u00abMongoDB\u00bb (o baz\u0103 de date non-rela\u021bional\u0103) efectueaz\u0103 o echilibrare automat\u0103, adic\u0103 fiecare colec\u021bie de documente (sau \u00abtabel\u00bb \u00een termeni de date rela\u021bionale) este \u00eemp\u0103r\u021bit\u0103 \u00een buc\u0103\u021bi, iar serverul le mut\u0103 automat \u00eentre shard-uri.<\/p>\n<p>Query Router, care distribuie cererile, este un fel de client pentru client, prin care interac\u021bioneaz\u0103. Acesta deja \u0219tie unde \u0219i ce date se afl\u0103, \u00eendrept\u00e2nd toate cererile c\u0103tre shard-ul corect.<\/p>\n<p>Un alt aspect important: MongoDB este un singur master. Exist\u0103 un Primary \u2013 acesta poate prelua \u00eenregistr\u0103ri care sus\u021bin cheile pe care le con\u021bine. Nu se poate face scriere multi-master.<\/p>\n<p>Am lansat versiunea 4.2 \u2013 au ap\u0103rut lucruri noi \u0219i interesante. \u00cen special, am integrat Lucene \u2013 c\u0103utare \u2013 difuz\u00e2nd direct java executabil pe \u00abMongo\u00bb, \u0219i acum este posibil s\u0103 efectuezi c\u0103ut\u0103ri prin Lucene, la fel ca \u00een \u00abElastic\u00bb.<\/p>\n<p>\u0218i am creat un produs nou \u2013 Charts, care este de asemenea disponibil pe \u00abAtlas\u00bb (Cloud-ul propriu al \u201eMongo\u201d). Au un Free Tier \u2013 po\u021bi experimenta cu acesta. Charts mi-a pl\u0103cut foarte mult \u2013 vizualizare de date, foarte intuitiv\u0103.<\/p>\n<h3>Ingredientele consisten\u021bei cauzale<\/h3>\n<p>\nAm num\u0103rat aproximativ 230 de articole care au fost publicate pe aceast\u0103 tem\u0103 \u2013 de Leslie Lampert. Acum, din memorie, v\u0103 voi transmite c\u00e2teva p\u0103r\u021bi din aceste materiale.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/e88b34b7a724e94837b944a4ddd21a04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTotul a \u00eenceput cu un articol scris de Leslie Lampert \u00een anii '70. Dup\u0103 cum pute\u021bi observa, cercet\u0103rile \u00een acest domeniu continu\u0103 \u0219i ast\u0103zi. \u00cen prezent, coeren\u021ba cauzal\u0103 suscit\u0103 interes datorit\u0103 dezvolt\u0103rii sistemelor distribuite.<\/p>\n<h3>Limit\u0103ri<\/h3>\n<p>\nCe limit\u0103ri exist\u0103? Acesta este, de fapt, unul dintre cele mai importante aspecte, deoarece limitele impuse de sistemele de produc\u021bie sunt foarte diferite de cele men\u021bionate \u00een articolele academice. Frecvent, acestea sunt destul de artificiale.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/9583ba9ff870e4ddc7aad4ba4c59ecc1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>\u00cen primul r\u00e2nd, MongoDB este un sistem cu master unic, dup\u0103 cum am men\u021bionat (acest lucru simplific\u0103 mult lucrurile).<\/li>\n<li>Consider\u0103m c\u0103 sistemul ar trebui s\u0103 suporte aproximativ 10.000 de \u0219arduri. Nu putem lua decizii arhitecturale care s\u0103 limiteze clar aceast\u0103 valoare.<\/li>\n<li>Avem un serviciu cloud, dar consider\u0103m c\u0103 utilizatorul ar trebui s\u0103 aib\u0103 posibilitatea, atunci c\u00e2nd descarc\u0103 binary-ul, s\u0103-l ruleze pe laptop-ul s\u0103u \u0219i totul s\u0103 func\u021bioneze perfect.<\/li>\n<li>Ne a\u0219tept\u0103m la ceea ce este rar utilizat \u00een cercetare: clien\u021bii externi pot face orice. MongoDB este open-source. Prin urmare, clien\u021bii pot fi at\u00e2t de inteligen\u021bi, dar \u0219i r\u0103i \u2013 ar putea dori s\u0103 strice totul. Ne a\u0219tept\u0103m la o apari\u021bie a 'tr\u0103d\u0103torilor bizantini'.<\/li>\n<li>Pentru clien\u021bii externi, care sunt \u00een afara perimetrului, o limitare important\u0103 este: dac\u0103 aceast\u0103 func\u021bionalitate este dezactivat\u0103, atunci nu ar trebui s\u0103 existe nicio degradare a performan\u021bei observat\u0103.<\/li>\n<li>Un alt aspect \u2013 complet anti-academic: compatibilitatea versiunilor anterioare \u0219i viitoare. Driverele vechi ar trebui s\u0103 suporte noile actualiz\u0103ri, iar baza de date ar trebui s\u0103 suporte driverele vechi.<\/li>\n<\/ul>\n<p>\n\u00cen general, toate acestea impun limit\u0103ri.<\/p>\n<h3>Componentele coeren\u021bei cauzale<\/h3>\n<p>\nAcum voi vorbi despre c\u00e2teva componente. Dac\u0103 lu\u0103m \u00een considerare coeren\u021ba cauzal\u0103 \u00een general, putem distinge blocuri. Am ales din lucr\u0103rile care se refer\u0103 la un anumit bloc: Urm\u0103rirea dependen\u021belor, alegerea orelor, cum pot fi sincronizate aceste ore \u00eentre ele \u0219i cum asigur\u0103m securitatea \u2013 aceasta este o schi\u021b\u0103 aproximativ\u0103 a ceea ce voi discuta:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/10c2631d6e61a280139b448628db763e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Urm\u0103rirea complet\u0103 a dependen\u021belor<\/h3>\n<p>\nDe ce este necesar? Pentru a se asigura c\u0103 atunci c\u00e2nd datele sunt replicate, fiecare \u00eenregistrare \u0219i fiecare modificare a datelor con\u021bin informa\u021bii despre ce modific\u0103ri depind. Cea mai simpl\u0103 \u0219i naiv\u0103 modificare este c\u00e2nd fiecare mesaj care con\u021bine o \u00eenregistrare, con\u021bine informa\u021bii despre mesajele anterioare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/fa5d0086c3c77e33631d8a2cd5c217fa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen acest exemplu, num\u0103rul din acolade reprezint\u0103 numerele \u00eenregistr\u0103rilor. Uneori, aceste \u00eenregistr\u0103ri cu valori sunt transmise chiar \u00een \u00eentregime, alteori sunt transmise anumite versiuni. Ideea este c\u0103 fiecare modificare con\u021bine informa\u021bii despre anterioara (de obicei le poart\u0103 \u00een sine).<\/p>\n<p>De ce am decis s\u0103 nu folosim aceast\u0103 abordare (urm\u0103rire complet\u0103)? Evident, deoarece aceast\u0103 abordare este impracticabil\u0103: orice modificare \u00eentr-o re\u021bea social\u0103 depinde de toate modific\u0103rile anterioare \u00een acea re\u021bea, transmit\u00e2nd, s\u0103 zicem, \u201eFacebook\u201d sau \u201eVkontakte\u201d \u00een fiecare actualizare. Cu toate acestea, exist\u0103 multe studii despre Full Dependency Tracking \u2013 aceste re\u021bele sociale, pentru anumite situa\u021bii, func\u021bioneaz\u0103 \u00eentr-adev\u0103r.<\/p>\n<h3>Urm\u0103rirea explicit\u0103 a dependen\u021belor (Explicit Dependency Tracking)<\/h3>\n<p>\nUrm\u0103torul este mai restric\u021bionat. De asemenea, se analizeaz\u0103 transmiterea informa\u021biilor, dar doar a celor care depind \u00een mod explicit. Ce depinde de ce, de obicei, este determinat deja de Aplica\u021bie. C\u00e2nd datele sunt replicate, la solicitate sunt oferite doar r\u0103spunsurile c\u00e2nd dependen\u021bele anterioare au fost satisf\u0103cute, adic\u0103 au fost prezentate. Acesta este principiul conform c\u0103ruia func\u021bioneaz\u0103 consisten\u021ba cauzal\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/7fe101b998c1a0c922788d8d36a5243f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEa vede c\u0103 \u00eenregistrarea 5 depinde de \u00eenregistr\u0103rile 1, 2, 3, 4 \u2013 prin urmare, a\u0219teapt\u0103 \u00eenainte ca clientul s\u0103 aib\u0103 acces la modific\u0103rile f\u0103cute de decizia de acces a Penny, c\u00e2nd toate modific\u0103rile anterioare au trecut deja \u00een baza de date.<\/p>\n<p>Aceasta ne deranjeaz\u0103, deoarece informa\u021bia este tot prea mult\u0103 \u0219i va \u00eencetini. Exist\u0103 o alt\u0103 abordare\u2026<\/p>\n<h3>Ceasurile lui Lamport (Lamport Clock)<\/h3>\n<p>\nSunt foarte vechi. Ceasul Lamport presupune c\u0103 aceste dependen\u021be se reduc la o func\u021bie scalar\u0103, care se nume\u0219te Ceas Lamport.<\/p>\n<p>Func\u021bia scalar\u0103 este un num\u0103r abstract. Adesea este numit timp logic. La fiecare eveniment, acest counter cre\u0219te. Counter-ul cunoscut \u00een prezent procesului trimite fiecare mesaj. Este clar c\u0103 procesele pot fi desincronizate, av\u00e2nd momente complet diferite. Totu\u0219i, printr-un asemenea schimb de mesaje, sistemul reu\u0219e\u0219te cumva s\u0103 echilibreze ceasurile. Ce se \u00eent\u00e2mpl\u0103 \u00een acest caz?<\/p>\n<p>Am \u00eemp\u0103r\u021bit acel shard mare \u00een dou\u0103, pentru a fi clar: Friends pot tr\u0103i \u00eentr-un nod care con\u021bine o parte din colec\u021bie, iar Feed \u2013 \u00eentr-un nod complet diferit, care con\u021bine o por\u021biune din aceast\u0103 colec\u021bie. Este clar cum pot s\u0103 nu ajung\u0103 \u00een coad\u0103? Mai \u00eent\u00e2i, Feed va spune: \u201eA fost replicat\u201d, iar apoi \u2013 Friends. Dac\u0103 sistemul nu ofer\u0103 anumite garan\u021bii c\u0103 Feed-ul nu va fi afi\u0219at p\u00e2n\u0103 c\u00e2nd dependen\u021bele Friends din colec\u021bia Friends nu vor fi livrate, atunci avem exact situa\u021bia despre care am men\u021bionat.<\/p>\n<p>Vezi cum cre\u0219te timpul logic al counter-ului pe Feed:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/bae152d1890b53804f2cb28122983df6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAstfel, proprietatea principal\u0103 a acestui Ceas Lamport \u0219i a consisten\u021bei cauzale (explicat\u0103 prin Ceas Lamport) este urm\u0103toarea: dac\u0103 avem evenimentele A \u0219i B, iar evenimentul B depinde de evenimentul A *, atunci rezult\u0103 c\u0103 LogicalTime al evenimentului A este mai mic dec\u00e2t LogicalTime al evenimentului B.<\/p>\n<p><i>* Uneori se mai spune \u0219i c\u0103 A a avut loc \u00eenainte de B, adic\u0103 A s-a \u00eent\u00e2mplat \u00eenainte de B \u2013 aceasta este o rela\u021bie care par\u021bial ordoneaz\u0103 \u00eentreaga multitudine de evenimente care au avut loc.<\/i><\/p>\n<p>Inversa nu este adev\u0103rat\u0103. Aceasta este de fapt una dintre principalele dezavantaje ale Ceasului Lamport \u2013 ordinea par\u021bial\u0103. Acolo exist\u0103 no\u021biunea de evenimente concomitente, adic\u0103 evenimente \u00een care nici (A a avut loc \u00eenainte de B), nici (A a avut loc dup\u0103 B). Un exemplu poate fi ad\u0103ugarea simultan\u0103 de c\u0103tre Leonard a cuiva pe lista de prieteni (chiar \u0219i nu de Leonard, ci de Sheldon, de exemplu).<br \/>\nAceasta este proprietatea care este adesea utilizat\u0103 c\u00e2nd se lucreaz\u0103 cu ceasurile Lamport: se analizeaz\u0103 exact func\u021bia \u0219i de aici se concluzioneaz\u0103 \u2013 poate c\u0103 aceste evenimente depind. Pentru c\u0103 \u00een una dintre direc\u021bii este adev\u0103rat: dac\u0103 LogicalTime A este mai mic dec\u00e2t LogicalTime B, atunci B nu poate avea loc \u00eenainte de A; iar dac\u0103 este mai mare, atunci poate fi.<\/p>\n<h3>Ceasuri vectoriale (Vector Clock)<\/h3>\n<p>\nEvolu\u021bia logic\u0103 a ceasurilor Lamport este ceasul vectorial. Acestea se disting prin faptul c\u0103 fiecare nod prezent con\u021bine propriile ceasuri separate, care sunt transmise ca un vector.<br \/>\n\u00cen acest caz, observa\u021bi c\u0103 indexul zero al vectorului corespunde Feed-ului, iar primul index al vectorului corespunde Friends-ului (fiecare dintre aceste noduri). \u0218i acum ele vor cre\u0219te: indexul zero al \u00abFeed-ului\u00bb cre\u0219te cu 1, 2, 3.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/d89292686ed8dd41aef06090f16db1c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe avantaje au ceasurile vectoriale? Ele permit identificarea momentelor \u00een care evenimentele sunt simultane \u0219i c\u00e2nd acestea apar pe diferite noduri. Acest lucru este foarte important pentru sistemul de sharding, cum ar fi \u00abMongoDB\u00bb. Cu toate acestea, nu l-am ales, de\u0219i este o solu\u021bie excelent\u0103, care func\u021bioneaz\u0103 bine \u0219i care ne-ar fi fost, probabil, util\u0103...<\/p>\n<p>Dac\u0103 avem 10.000 de sharduri, nu putem transmite 10.000 de componente, chiar dac\u0103 comprim\u0103m sau g\u0103sim alte solu\u021bii \u2013 totu\u0219i, \u00eenc\u0103rc\u0103tura util\u0103 va fi de c\u00e2teva ori mai mic\u0103 dec\u00e2t volumul \u00eentregului vector. A\u0219adar, cu durere \u00een suflet \u0219i cu din\u021bii scr\u00e2\u0219nind, am renun\u021bat la aceast\u0103 abordare \u0219i am trecut la alta.<\/p>\n<h3>Spanner TrueTime. Ceasuri atomice.<\/h3>\n<p>\nAm spus c\u0103 va fi o poveste despre \u00abSpanner\u00bb. Este o solu\u021bie grozav\u0103, direct din secolul XXI: ceasuri atomice, sincronizare GPS.<\/p>\n<p>Care este ideea? \u00abSpanner\u00bb este sistemul Google care recent a devenit disponibil \u0219i pentru oameni (l-au echipat cu SQL). Fiecare tranzac\u021bie are un timestamp. Deoarece timpul este sincronizat*, fiec\u0103rui eveniment i se poate atribui un anumit timp \u2013 ceasurile atomice au un timp de a\u0219teptare, dup\u0103 care timpul se schimb\u0103 garantat.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/707b5998fbb500d201aafffccc666f0e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAstfel, pur \u0219i simplu \u00eenregistr\u00e2nd \u00een baza de date \u0219i a\u0219tept\u00e2nd o anumit\u0103 perioad\u0103 de timp, se garanteaz\u0103 automat serializabilitatea evenimentului. Are cel mai puternic model de coeren\u021b\u0103, care poate fi imaginat \u2013 aceasta este coeren\u021ba extern\u0103.<\/p>\n<p>* Aceasta este principala problem\u0103 a ceasurilor Lamport \u2013 ele nu sunt niciodat\u0103 sincronizate \u00een sistemele distribuite. Ele pot diverge, chiar \u0219i \u00een prezen\u021ba NTP nu func\u021bioneaz\u0103 foarte bine. \u00abSpanner\u00bb are ceasuri atomice \u0219i sincronizare, pare a fi de ordinul microsecundelor.<\/p>\n<p>De ce nu l-am ales? Nu presupunem c\u0103 utilizatorii no\u0219tri au ceasuri atomice integrate. C\u00e2nd vor deveni disponibile, fiind integrate \u00een fiecare laptop, va exista o sincronizare GPS super avansat\u0103 \u2013 atunci, da... P\u00e2n\u0103 atunci, ce este mai bun este \u00abAmazon\u00bb, sta\u021bii de baz\u0103 \u2013 pentru pasiona\u021bi... A\u0219adar, am folosit alte ceasuri.<\/p>\n<h3>Ceasuri hibride (Hybrid Clock)<\/h3>\n<p>\nAceasta este, de fapt, ceea ce tic\u0103ie \u00een \u201eMongoDB\u201d pentru a asigura consisten\u021ba cauzal\u0103. \u00cen ce const\u0103 hibriditatea? Hibridul este o valoare scalar\u0103, dar aceasta const\u0103 din dou\u0103 componente:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/dab03a87d9f6ee2e716f75baff1736bc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<ul>\n<li>Prima este epoca Unix (c\u00e2te secunde au trecut de la \u201e\u00eenceputul lumii computerizate\u201d).<\/li>\n<li>A doua este un anumit increment, tot un int nesemnat de 32 de bi\u021bi.<\/li>\n<\/ul>\n<p>\nAceasta este, de fapt, tot. Exist\u0103 o abordare: partea care r\u0103spunde de timp este constant sincronizat\u0103 cu ceasurile; de fiecare dat\u0103 c\u00e2nd are loc o actualizare, aceast\u0103 parte se sincronizeaz\u0103 cu ceasurile, iar rezultatul este c\u0103 timpul este mereu mai mult sau mai pu\u021bin corect, iar incrementul permite deosebirea \u00eentre evenimentele care au avut loc \u00een acela\u0219i moment.<\/p>\n<p>De ce este important pentru \u201eMongoDB\u201d? Pentru c\u0103 permite realizarea unor backup-uri-restaur\u0103ri la un anumit moment \u00een timp, adic\u0103 evenimentul este indexat \u00een func\u021bie de timp. Acest lucru este important atunci c\u00e2nd sunt necesare anumite evenimente; pentru Baze de Date, evenimentele sunt modific\u0103rile din Baz\u0103 de Date care au avut loc \u00een anumite intervale de timp.<\/p>\n<p>Voi spune doar cea mai important\u0103 cauz\u0103 (v\u0103 rog, nu spune\u021bi nim\u0103nui altcuiva)! Am f\u0103cut asta deoarece a\u0219a arat\u0103 datele ordonate, indexate \u00een MongoDB OpLog. OpLog-ul este o structur\u0103 de date care con\u021bine absolut toate modific\u0103rile din baz\u0103: acestea ajung \u00eent\u00e2i \u00een OpLog, iar apoi sunt aplicate efectiv \u00een Storage atunci c\u00e2nd este vorba despre date replicate sau sharduite.<\/p>\n<p>Aceasta a fost motivul principal. Totu\u0219i, exist\u0103 \u0219i cerin\u021be practice pentru dezvoltarea bazei, ceea ce \u00eenseamn\u0103 c\u0103 trebuie s\u0103 fie simplu \u2013 c\u00e2t mai pu\u021bin cod, c\u00e2t mai pu\u021bine lucruri care trebuie rescrise \u0219i testate. Faptul c\u0103 op-log-urile noastre au fost indexate cu ceasuri hibride a ajutat foarte mult \u0219i a permis o alegere corect\u0103. A fost \u00eentr-adev\u0103r justificat \u0219i a func\u021bionat magic, \u00een primul prototip. A fost super tare!<\/p>\n<h3>Sincronizarea ceasurilor<\/h3>\n<p>\nExist\u0103 mai multe metode de sincronizare descrise \u00een literatura de specialitate. Vorbesc despre sincronizare atunci c\u00e2nd avem dou\u0103 sharde diferite. Dac\u0103 avem un replica set, atunci nu este necesar\u0103 nicio sincronizare: este un \u00absingl-master\u00bb; avem un OpLog \u00een care toate modific\u0103rile sunt \u00eenregistrate \u2013 \u00een acest caz, totul este deja ordonat secven\u021bial \u00een \u00abOpLog\u00bb. Dar dac\u0103 avem dou\u0103 sharde diferite, sincronizarea timpului devine important\u0103. Aici, ceasurile vectoriale au ajutat mai mult! Dar nu le avem.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/7d3306747490ac044b7f8130defea0c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl doilea mod este \u00abHeartbeats\u00bb. Se pot schimba unele semnale care apar la fiecare unitate de timp. Dar \u00abHeartbeats\u00bb sunt prea lente, nu putem asigura laten\u021ba dorit\u0103 clientului nostru.<\/p>\n<p>Timpul adev\u0103rat \u2013 desigur, este o idee minunat\u0103. Dar, din nou, cred c\u0103 este, probabil, viitorul\u2026 De\u0219i \u00een \u00abAtlas\u00bb este deja posibil, exist\u0103 deja sincronizatoare rapide de timp \u00abamazoniste\u00bb. Dar nu vor fi disponibile pentru toat\u0103 lumea.<\/p>\n<p>Gossiping \u2013 aceasta este atunci c\u00e2nd toate mesajele includ timpul. Este cam ceea ce folosim noi. Fiecare mesaj \u00eentre noduri, driver, router date noduri, absolut tot pentru \u00abMongoDB\u00bb \u2013 sunt anumite elemente, componente ale bazei de date, care con\u021bin ceasuri care curg. Toate au o valoare a timpului hibrid, care este transmis\u0103. 64 de bi\u021bi? Este permis, este posibil.<\/p>\n<h3>Cum func\u021bioneaz\u0103 totul \u00eempreun\u0103?<\/h3>\n<p>\nAici analizez un replica set pentru a fi pu\u021bin mai simplu. Exist\u0103 un Primary \u0219i un Secondary. Secondary efectueaz\u0103 replicarea \u0219i nu este \u00eentotdeauna complet sincronizat cu Primary.<\/p>\n<p>Se realizeaz\u0103 o inser\u021bie (insert) \u00een \u00abPrimary\u00bb cu o anumit\u0103 valoare a timpului. Aceast\u0103 inser\u021bie cre\u0219te contorul intern cu 11, dac\u0103 este maxim. Sau va verifica valorile ceasurilor \u0219i se va sincroniza dup\u0103 ceasuri, dac\u0103 valorile ceasurilor sunt mai mari. Acest lucru permite ordonarea \u00een func\u021bie de timp.<\/p>\n<p>Dup\u0103 ce face \u00eenregistrarea, intervine un moment important. Ceasurile \u00een \u00abMongoDB\u00bb se incrementeaz\u0103 doar \u00een cazul \u00een care have loc o \u00eenregistrare \u00een \u00abOpLog\u00bb. Acesta este evenimentul care schimb\u0103 starea sistemului. \u00cen toate articolele clasice, un eveniment este considerat a fi primirea unui mesaj de c\u0103tre nod: mesajul a sosit \u2013 \u00eenseamn\u0103 c\u0103 sistemul \u0219i-a schimbat starea.<\/p>\n<p>Aceasta se datoreaz\u0103 faptului c\u0103, \u00een cadrul cercet\u0103rii, nu este \u00eentotdeauna clar cum va fi interpretat acest mesaj. \u0218tim cu siguran\u021b\u0103 c\u0103, dac\u0103 nu este reflectat \u00een \u201eOpLog\u201d, atunci nu va fi interpretat deloc, iar schimbarea st\u0103rii sistemului const\u0103 doar \u00een \u00eenregistrarea \u00een \u201eOpLog\u201d. Aceasta ne simplific\u0103 totul: \u0219i modelul este simplificat, \u0219i permite ordonarea \u00een cadrul unui singur set de replici, \u0219i multe alte lucruri utile.<\/p>\n<p>Se returneaz\u0103 o valoare care este deja \u00eenregistrat\u0103 \u00een \u201eOpLog\u201d \u2013 \u0219tim c\u0103 \u00een \u201eOpLog\u201d se afl\u0103 deja aceast\u0103 valoare \u0219i timpul ei este 12. Acum, s\u0103 spunem c\u0103 citirea \u00eencepe de la un alt nod (Secondary), iar acesta transmite deja afterClusterTime \u00een mesajul s\u0103u. El spune: \u201eAm nevoie de tot ce s-a \u00eent\u00e2mplat cel pu\u021bin dup\u0103 12 sau \u00een timpul celor doisprezece\u201d (vezi figura de mai sus).<\/p>\n<p>Aceasta este ceea ce se nume\u0219te Causal and consistent (CAT). Exist\u0103 un astfel de concept \u00een teorie, care reprezint\u0103 o anumit\u0103 fereastr\u0103 de timp care este consistent\u0103 \u00een sine. \u00cen acest caz, putem spune c\u0103 acesta este starea sistemului care a fost observat\u0103 la momentul 12.<\/p>\n<p>Acum, aici nu este nimic pentru c\u0103, \u00eentr-un fel, imit\u0103 situa\u021bia \u00een care Secondary trebuie s\u0103 replic\u0103 datele cu Primary. A\u0219teapt\u0103... \u0218i iat\u0103 c\u0103 datele au sosit \u2013 returneaz\u0103 \u00eenapoi aceste valori.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/54d9de3e2696c1e5d19f4da206be090b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA\u0219a func\u021bioneaz\u0103 totul, cam a\u0219a.<\/p>\n<p>Ce \u00eenseamn\u0103 \u201ecam a\u0219a\u201d? S\u0103 presupunem c\u0103 exist\u0103 o persoan\u0103 care a citit \u0219i a \u00een\u021beles cum func\u021bioneaz\u0103 totul. A \u00een\u021beles c\u0103 fiecare dat\u0103 se produce ClusterTime, \u00ee\u0219i actualizeaz\u0103 ceasurile logice interne, iar apoi urm\u0103toarea \u00eenregistrare cre\u0219te cu o unitate. Aceast\u0103 func\u021bie ocup\u0103 20 de linii. S\u0103 spunem c\u0103 aceast\u0103 persoan\u0103 transmite un num\u0103r 64-bit maxim, minus unu.<\/p>\n<p>De ce \u201eminus unu\u201d? Pentru c\u0103 ceasurile interne se vor substitui \u00een aceast\u0103 valoare (evident, acesta este cel mai mare posibil \u0219i mai mare dec\u00e2t timpul actual), apoi se va produce \u00eenregistrarea \u00een \u201eOpLog\u201d, iar ceasurile se vor incrementa cu \u00eenc\u0103 o unitate \u2013 \u0219i va fi deja valoarea maxim\u0103 (toate unit\u0103\u021bile, nu mai este niciunde de ajuns, unsaint int\u2019uri).<\/p>\n<p>Este evident c\u0103 dup\u0103 aceasta sistemul devine absolut inaccesibil pentru orice. Poate fi doar desc\u0103rcat, cur\u0103\u021bat \u2013 mult\u0103 munc\u0103 manual\u0103. Disponibilitate complet\u0103:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/634b25fe0ef1e0af39181cd59c7b522f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMai mult, dac\u0103 acest lucru se replic\u0103 \u00een alt\u0103 parte, atunci \u00eentregul cluster se va pr\u0103bu\u0219i. O situa\u021bie complet inacceptabil\u0103, pe care oricine poate organiza foarte repede \u0219i simplu! De aceea, am considerat acest aspect ca fiind unul dintre cele mai importante. Cum putem preveni asta?<\/p>\n<h3>Calea noastr\u0103 \u2013 s\u0103 semn\u0103m clusterTime<\/h3>\n<p>\nA\u0219a se transmite \u00een mesaj (p\u00e2n\u0103 la textul albastru). Dar acum gener\u0103m \u0219i semn\u0103tura (textul albastru):<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/c16e985f9610e01a61293e0d6dde459b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSemn\u0103tura este generat\u0103 cu o cheie care este stocat\u0103 \u00een baza de date, \u00een interiorul perimetrului protejat; este generat\u0103 \u0219i actualizat\u0103 (utilizatorii nu v\u0103d acest lucru). Se genereaz\u0103 un hash, iar fiecare mesaj este semnat la crearea sa, iar la primire \u2013 validat.<br \/>\nProbabil c\u0103 se ridic\u0103 \u00eentrebarea oamenilor: \u201eC\u00e2t de mult \u00eencetine\u0219te tot asta?\u201d Am spus c\u0103 trebuie s\u0103 func\u021bioneze rapid, mai ales \u00een absen\u021ba acestei func\u021bii.<\/p>\n<p>Ce \u00eenseamn\u0103 s\u0103 folose\u0219ti Coeren\u021ba cauzal\u0103 \u00een acest caz? Asta \u00eenseamn\u0103 s\u0103 ar\u0103\u021bi parametrul afterClusterTime. F\u0103r\u0103 acesta, el va transmite pur \u0219i simplu valori \u00een orice caz. Gossiping, \u00eencep\u00e2nd cu versiunea 3.6, func\u021bioneaz\u0103 \u00eentotdeauna.<\/p>\n<p>Dac\u0103 l\u0103s\u0103m generarea constant\u0103 a semn\u0103turilor, acest lucru va \u00eencetini sistemul chiar \u0219i \u00een absen\u021ba func\u021biei, ceea ce nu se aliniaz\u0103 cu abord\u0103rile \u0219i cerin\u021bele noastre. \u0218i ce am f\u0103cut?<\/p>\n<h3>F\u0103-o rapid!<\/h3>\n<p>\nEste un lucru destul de simplu, dar trucul este interesant \u2013 voi \u00eemp\u0103rt\u0103\u0219i, poate va fi interesant pentru cineva.<br \/>\nAvem un hash \u00een care sunt stocate datele semnate. Toate datele trec prin cache. Cache-ul nu semneaz\u0103 \u00een mod specific timpul, ci un Range. C\u00e2nd vine o valoare, gener\u0103m un Range, masc\u0103m ultimele 16 bi\u021bi, iar aceast\u0103 valoare o semn\u0103m:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/f4810456f08ba1cc69730ac0079d4206.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOb\u021bin\u00e2nd o astfel de semn\u0103tur\u0103, acceler\u0103m sistemul (teoretic) de 65 de mii de ori. Func\u021bioneaz\u0103 minunat: c\u00e2nd am realizat experimentele \u2013 timpul s-a redus \u00een realitate de 10 mii de ori c\u00e2nd am avut un update secven\u021bial. Evident, c\u00e2nd sunt \u00een dezordine, asta nu func\u021bioneaz\u0103. Dar \u00een majoritatea cazurilor practice, acest lucru func\u021bioneaz\u0103. Combina\u021bia dintre semn\u0103tura Range \u0219i semn\u0103tura a permis rezolvarea problemei de securitate.<\/p>\n<h3>Ce am \u00eenv\u0103\u021bat?<\/h3>\n<p>\nLectiile pe care le-am \u00eenv\u0103\u021bat din aceasta:<\/p>\n<ul>\n<li>Trebuie s\u0103 citim materiale, pove\u0219ti, articole, pentru c\u0103 avem multe lucruri interesante de \u00eemp\u0103rt\u0103\u0219it. C\u00e2nd lucr\u0103m la o anumit\u0103 func\u021bionalitate (mai ales acum, c\u00e2nd am realizat tranzac\u021bii etc.), trebuie s\u0103 citim \u0219i s\u0103 \u00een\u021belegem. Asta ne ia timp, dar este de fapt foarte util, deoarece devine clar unde ne afl\u0103m. Nu am inventat nimic nou \u2013 doar am luat ingredientele.\n<p>\u00cen general, exist\u0103 o diferen\u021b\u0103 vizibil\u0103 \u00een g\u00e2ndire atunci c\u00e2nd se desf\u0103\u0219oar\u0103 o conferin\u021b\u0103 academic\u0103 (de exemplu, \u201eSigMon\u201d) \u2013 acolo, toat\u0103 lumea se concentreaz\u0103 pe idei noi. \u00cen ce const\u0103 noutatea algoritmului nostru? Aici nu este nimic deosebit. Noutatea const\u0103 mai mult \u00een modul \u00een care am combinat abord\u0103rile existente. A\u0219adar, prima regul\u0103 este s\u0103 citim clasici, \u00eencep\u00e2nd cu Lamport.<\/li>\n<li>\u00cen produc\u021bie, cerin\u021bele sunt complet diferite. Sunt sigur c\u0103 mul\u021bi dintre voi nu se confrunt\u0103 cu \u201ebaze de date sferice\u201d \u00een absen\u021b\u0103 abstract\u0103, ci cu lucruri normale, reale, care au probleme legate de disponibilitate, laten\u021b\u0103 \u0219i toleran\u021b\u0103 la erori.<\/li>\n<li>\u00cen cele din urm\u0103, a fost necesar s\u0103 lu\u0103m \u00een considerare diferite idei \u0219i s\u0103 combin\u0103m mai multe articole complet diferite \u00eentr-o singur\u0103 abordare. Ideea despre semn\u0103tura, de exemplu, a venit dintr-un articol care examina protocolul Paxos, care se ocup\u0103 de erorile non-bizantine \u00een cadrul protocolului de autorizare, pentru erorile bizantine \u2013 \u00een afara protocolului de autorizare\u2026 \u00cen general, exact asta am realizat la final.\n<p>Nu este nimic nou aici! Dar de \u00eendat\u0103 ce am amestecat totul \u00eempreun\u0103\u2026 Asta ar fi ca \u0219i cum ai spune c\u0103 re\u021beta salatei Olivier este o prostie, deoarece ou\u0103le, maioneza \u0219i castrave\u021bii au fost deja inventate\u2026 Este cam aceea\u0219i poveste.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/2f9e5cb77079f9a0f7bdf76430c3386e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cenchei aici. Mul\u021bumesc!<\/p>\n<h3>\u00centreb\u0103ri<\/h3>\n<p>\n<b>\u00centrebare din sal\u0103 (ulterior \u2013 \u00ce):<\/b> \u2013 Mul\u021bumesc, Mihail, pentru prezentare! Tema despre timp este interesant\u0103. Folosi\u021bi Gossiping. A\u021bi spus c\u0103 to\u021bi au timpul lor, to\u021bi \u0219tiu timpul lor local. Am \u00een\u021beles c\u0103 avem un driver \u2013 pot exista mul\u021bi clien\u021bi cu drivere, mul\u021bi planificatori de interog\u0103ri, mul\u021bi shard-uri\u2026 Ce se va \u00eent\u00e2mpla cu sistemul dac\u0103 apare o neconcordan\u021b\u0103: cineva decide c\u0103 este cu un minut \u00eenainte, cineva \u2013 cu un minut \u00een urm\u0103? Unde ne vom afla?<\/p>\n<p><b>MT:<\/b> \u2013 O \u00eentrebare excelent\u0103, de fapt! Voi vorbi despre sharde. Dac\u0103 \u00een\u021beleg corect \u00eentrebarea, avem situa\u021bia urm\u0103toare: exist\u0103 shard 1 \u0219i shard 2, iar citirea are loc din aceste dou\u0103 sharde \u2013 acestea sunt divergente, nu interac\u021bioneaz\u0103 \u00eentre ele, deoarece timpul de care sunt con\u0219tiente este diferit, \u00een special timpul pe care \u00eel de\u021bin \u00een loguri.<br \/>\nS\u0103 presupunem c\u0103 shard 1 a f\u0103cut un milion de \u00eenregistr\u0103ri, iar shard 2 \u2013 nimic, \u0219i o interogare a venit la cele dou\u0103 sharde. \u0218i shard-ul 1 are afterClusterTime mai mare de un milion. \u00cen aceast\u0103 situa\u021bie, a\u0219a cum am explicat, shard 2 nu va r\u0103spunde niciodat\u0103.<\/p>\n<p><b>M:<\/b> \u2013 Voiam s\u0103 \u0219tiu cum se sincronizeaz\u0103 \u0219i aleg un singur timp logic?<\/p>\n<p><b>MT:<\/b> \u2013 Se sincronizeaz\u0103 foarte simplu. Shard-ul, c\u00e2nd prime\u0219te afterClusterTime \u0219i nu g\u0103se\u0219te timpul \u00een \u201eOpLog\u201d \u2013 ini\u021biaz\u0103 no approved. Asta \u00eenseamn\u0103 c\u0103 \u00ee\u0219i cre\u0219te manual timpul la acea valoare. Aceasta este o indicare c\u0103 nu exist\u0103 evenimente care s\u0103 corespund\u0103 acestei interog\u0103ri. Creeaz\u0103 acest eveniment artificial \u0219i devine astfel Causal Consistent.<\/p>\n<p><b>M:<\/b> \u2013 \u0218i dac\u0103 ulterior vor veni \u0219i alte evenimente, care s-au pierdut \u00een re\u021bea?<\/p>\n<p><b>MT:<\/b> \u2013 Shard-ul este construit astfel \u00eenc\u00e2t acestea nu vor mai veni, deoarece este un master unic. Dac\u0103 a \u00eenregistrat deja, atunci nu vor mai veni, ci vor fi ulterior. Nu poate ap\u0103rea o situa\u021bie \u00een care ceva s-a blocat undeva, apoi el va face no write, iar apoi aceste evenimente au venit \u2013 \u0219i s-a \u00eenc\u0103lcat Causal consistency. C\u00e2nd face no write, toate trebuie s\u0103 vin\u0103 mai departe (le va a\u0219tepta).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/dbbc7c5c653f0c9fa449cceb88ed62ef.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>M:<\/b> \u2013 Am c\u00e2teva \u00eentreb\u0103ri cu privire la cozi. Causal consistency presupune c\u0103 exist\u0103 o anumit\u0103 coad\u0103 de ac\u021biuni care trebuie executate. Ce se va \u00eent\u00e2mpla dac\u0103 un pachet dispare? S\u0103 presupunem c\u0103 a mers 10, 11\u2026 al 12-lea a disp\u0103rut, iar toate celelalte a\u0219teapt\u0103 s\u0103 fie executat. \u0218i brusc, m\u0103\u0219ina a murit, nu putem face nimic. Exist\u0103 o lungime maxim\u0103 a cozii care se acumuleaz\u0103, \u00eenainte de a fi executat\u0103? Ce fel de e\u0219ec fatal are loc \u00een cazul pierderii unui singur stadiu? Mai ales, dac\u0103 \u00eenregistr\u0103m c\u0103 exist\u0103 un anumit stadiu anterior, de la care ar trebui s\u0103 ne baz\u0103m? \u0218i de la el nu ne-am bazat!<\/p>\n<p><b>MT:<\/b> \u2013 O \u00eentrebare \u0219i mai bun\u0103! Ce facem? \u00cen MongoDB exist\u0103 conceptul de \u00eenregistr\u0103ri de quorum, citire de quorum. \u00cen ce situa\u021bii un mesaj poate disp\u0103rea? C\u00e2nd \u00eenregistrarea nu este de quorum sau c\u00e2nd citirea nu este de quorum (de asemenea, poate aduce ni\u0219te garbage).<br \/>\nReferitor la consisten\u021ba cauzal\u0103, am efectuat un studiu experimental extins, a c\u0103rui concluzie a fost c\u0103, \u00een cazul \u00een care scrierile \u0219i citirile nu sunt cu quorum, apar \u00eenc\u0103lc\u0103ri ale consisten\u021bei cauzale. Exact ceea ce spui!<\/p>\n<p>Sfatul nostru: folosi\u021bi cel pu\u021bin citiri cu quorum atunci c\u00e2nd utiliza\u021bi consisten\u021ba cauzal\u0103. \u00cen acest caz, nu se va pierde nimic, chiar dac\u0103 o scriere cu quorum dispare... Aceasta este o situa\u021bie ortogonal\u0103: dac\u0103 utilizatorul nu vrea ca datele s\u0103 dispar\u0103, trebuie s\u0103 foloseasc\u0103 scrierea cu quorum. Consisten\u021ba cauzal\u0103 nu ofer\u0103 nicio garan\u021bie de durabilitate. Garan\u021bia de durabilitate este oferit\u0103 de replicare \u0219i mecanismele asociate cu replicarea.<\/p>\n<p><b>M:<\/b> \u2013 C\u00e2nd cre\u0103m o instan\u021b\u0103 care face shard (nu master, ci slave \u00een consecin\u021b\u0103), se bazeaz\u0103 pe timpul unix al propriei ma\u0219ini sau pe timpul \u00abmaster\u00bb-ului; este sincronizat\u0103 prima dat\u0103 sau periodic?<\/p>\n<p><b>MT:<\/b> \u2013 Acum voi clarifica. Shardul (adic\u0103 partitia orizontal\u0103) are \u00eentotdeauna un Primary. \u0218i \u00een shard poate fi un \u00abmaster\u00bb \u0219i pot exista replici. Dar shardul sus\u021bine \u00eentotdeauna scrierea, deoarece trebuie s\u0103 sus\u021bin\u0103 un anumit domeniu (\u00een shard se afl\u0103 Primary).<\/p>\n<p><b>M:<\/b> \u2013 Deci totul depinde exclusiv de \u00abmaster\u00bb? Se folose\u0219te \u00eentotdeauna timpul \u00abmaster\u00bb-ului?<\/p>\n<p><b>MT:<\/b> \u2013 Da. Se poate spune c\u0103: ceasurile tic\u0103ie atunci c\u00e2nd are loc o scriere \u00een \u00abmaster\u00bb, \u00een \u00abOplog\u00bb.<\/p>\n<p><b>M:<\/b> \u2013 Avem un client care se conecteaz\u0103 \u0219i nu are nevoie s\u0103 \u0219tie nimic despre timp?<\/p>\n<p><b>MT:<\/b> \u2013 Deloc nu trebuie s\u0103 \u0219tie nimic! Dac\u0103 vorbim despre cum func\u021bioneaz\u0103 la client: clientul, atunci c\u00e2nd dore\u0219te s\u0103 foloseasc\u0103 consisten\u021ba cauzal\u0103, trebuie s\u0103 deschid\u0103 o sesiune. Acum este totul acolo: \u0219i tranzac\u021biile \u00een sesiune, \u0219i a ob\u021bine drepturi... Sesiunea este o ordonare a evenimentelor logice care se \u00eent\u00e2mpl\u0103 cu clientul.<\/p>\n<p>Dac\u0103 deschide aceast\u0103 sesiune \u0219i spune c\u0103 dore\u0219te consisten\u021b\u0103 cauzal\u0103 (dac\u0103, \u00een mod implicit, sesiunea sus\u021bine consisten\u021ba cauzal\u0103), totul func\u021bioneaz\u0103 automat. Driverul \u00ee\u0219i aminte\u0219te acest timp \u0219i \u00eel cre\u0219te atunci c\u00e2nd prime\u0219te un mesaj nou. \u00ce\u0219i aminte\u0219te ce r\u0103spuns a returnat anterior serverul, care a returnat date. Urm\u0103toarea cerere va con\u021bine afterCluster (\u00abtimp mai mare dec\u00e2t acesta\u00bb).<\/p>\n<p>Clientul nu trebuie s\u0103 \u0219tie nimic concret! Este complet opac pentru el. Dac\u0103 oamenii folosesc aceste func\u021bii, ce se poate realiza? \u00cen primul r\u00e2nd, se poate citi \u00een siguran\u021b\u0103 din secondaries: se poate scrie pe Primary \u0219i citi de la secondary-uri replicate geografic \u0219i s\u0103 fii sigur c\u0103 func\u021bioneaz\u0103. \u00cen plus, sesiuni scrise pe Primary pot fi transferate chiar \u0219i c\u0103tre Secondary, adic\u0103 se pot folosi nu o sesiune, ci mai multe.<\/p>\n<p><b>M:<\/b> \u2013 Tema coeren\u021bei eventuale este str\u00e2ns legat\u0103 de o nou\u0103 ramur\u0103 a \u0219tiin\u021bei calculatoarelor \u2013 tipuri de date CRDT (Conflict-free Replicated Data Types). A\u021bi luat \u00een considerare integrarea acestor tipuri de date \u00een baz\u0103 \u0219i ce pute\u021bi spune despre acest lucru?<\/p>\n<p><b>MT:<\/b> \u2013 O \u00eentrebare bun\u0103! CRDT are sens pentru conflictele la scriere: \u00een MongoDB \u2013 un singur master.<\/p>\n<p><b>M:<\/b> \u2013 Am o \u00eentrebare din partea devops-ilor. \u00cen lumea real\u0103, apar situa\u021bii ispititoare \u00een care apare o e\u0219ec bizantin \u0219i persoane malefice din interiorul perimetrului securizat \u00eencep s\u0103 se bage \u00een protocol, trimi\u021b\u00e2nd pachete special modificate?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/99a521d04b416e6978aa68ce7c4a4c46.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>MT:<\/b> \u2013 Persoanele malefice din interiorul perimetrului sunt ca un cal troian! Aceste persoane pot face multe lucruri rele.<\/p>\n<p><b>M:<\/b> \u2013 Este evident c\u0103 a l\u0103sa \u00een server, ca s\u0103 zicem a\u0219a, o \u201efereastr\u0103\u201d prin care se poate introduce un zoo de elefan\u021bi \u0219i pr\u0103bu\u0219i \u00eentregul cluster pentru totdeauna\u2026 Va dura timp pentru o recuperare manual\u0103\u2026 Asta, \u00eencet spus, nu este corect. Pe de alt\u0103 parte, este interesant: \u00een via\u021ba real\u0103, \u00een practic\u0103, \u00eent\u00e2lni\u021bi astfel de situa\u021bii \u00een care atacurile interne naturale au loc?<\/p>\n<p><b>MT:<\/b> \u2013 Deoarece nu m\u0103 \u00eent\u00e2lnesc frecvent cu bre\u0219e de securitate \u00een via\u021ba real\u0103, nu pot spune \u2013 poate c\u0103 au loc. Dar dac\u0103 este s\u0103 vorbim despre filosofia de dezvoltare, consider\u0103m c\u0103: avem un perimetru care asigur\u0103 echipa care se ocup\u0103 de securitate \u2013 este un lac\u0103t, un zid; iar \u00een interiorul perimetrului putem face tot ce dorim. Este clar c\u0103 sunt utilizatori care pot vedea doar, \u0219i utilizatori care pot \u0219terge catalogul.<\/p>\n<p>\u00cen func\u021bie de permisiuni, daunele pe care utilizatorii le pot produce pot varia de la a fi simple ca o pisic\u0103, p\u00e2n\u0103 la a fi devastatoare ca un elefant. Este clar c\u0103 un utilizator cu drepturi complete poate face orice. Un utilizator cu permisiuni limitate poate provoca daune considerabil mai mici. \u00cen special, nu poate distruge sistemul.<\/p>\n<p><b>M:<\/b> \u2013 \u00cen perimetrul protejat, cineva s-a g\u00e2ndit s\u0103 formeze protocoale nea\u0219teptate pentru server, pentru a compromite serverul, iar, dac\u0103 are noroc, \u00eentregul cluster... Este posibil s\u0103 fie at\u00e2t de \u201ebine\u201d?<\/p>\n<p><b>MT:<\/b> \u2013 Nu am auzit niciodat\u0103 de astfel de lucruri. Faptul c\u0103 se poate compromite un server \u00een acest fel nu este un secret. A compromite din interior, fiind pe protocol, fiind un utilizator autorizat, care poate scrie \u00een mesaj ceva... De fapt, nu este posibil, pentru c\u0103 oricum va trece printr-o verificare. Exist\u0103 posibilitatea de a dezactiva aceast\u0103 autentificare pentru utilizatorii care nu doresc \u2013 aceasta devine problema lor; ei, pe scurt, \u0219i-au distrus singuri zidurile \u0219i pot aduce un elefant care s\u0103 calce... \u00cen general, po\u021bi s\u0103 te \u00eembraci ca un tehnician, s\u0103 vii \u0219i s\u0103-l sco\u021bi!<\/p>\n<p><b>M:<\/b> \u2013 Mul\u021bumesc pentru prezentare. Sergey (\u201eYandex\u201d). \u00cen \u201eMongo\u201d exist\u0103 o constant\u0103 care limiteaz\u0103 num\u0103rul de membri votan\u021bi \u00een Replica Set, iar aceast\u0103 constant\u0103 este 7 (\u0219apte). De ce este aceasta o constant\u0103? De ce nu este un parametru oarecare?<\/p>\n<p><b>MT:<\/b> \u2013 Replica Set-ul nostru poate avea \u0219i 40 de noduri. Acolo este \u00eentotdeauna majoritatea. Nu \u0219tiu ce versiune este...<\/p>\n<p><b>M:<\/b> \u2013 \u00cen Replica Set po\u021bi lansa membri ne-votan\u021bi, dar votan\u021bi \u2013 maxim 7. Cum gestion\u0103m situa\u021bia dac\u0103 avem Replica Set pe 3 centre de date? Un centru de date poate fi oprit u\u0219or, iar \u00eenc\u0103 o ma\u0219in\u0103 ar putea ie\u0219i din func\u021biune.<\/p>\n<p><b>MT:<\/b> \u2013 Aceasta este deja pu\u021bin dincolo de prezentare. Este o \u00eentrebare general\u0103. Poate, mai t\u00e2rziu pot s\u0103 \u00eei povestesc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Mihail Tiuleniev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103\" src=\"\/wp-content\/uploads\/2020\/02\/161966c7e77704dc619674ff0302ff57.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"UnAprFMX1d4\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/UnAprFMX1d4\/hqdefault.jpg\" alt=\"Reda\u021bi video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Pu\u021bin publicitate \ud83d\ude42<\/h3>\n<p>\nMul\u021bumim c\u0103 r\u0103m\u00e2ne\u021bi cu noi. V\u0103 plac articolele noastre? Dori\u021bi s\u0103 vede\u021bi mai multe materiale interesante? Sus\u021bine\u021bi-ne, efectu\u00e2nd o comand\u0103 sau recomand\u00e2ndu-ne prietenilor, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud pentru dezvoltatori de la 4,99 $<\/a><\/noindex>, <b>un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Toat\u0103 adev\u0103rul despre VPS (KVM) E5-2697 v3 (6 nuclee) 10GB DDR4 480GB SSD 1Gbps de la 19 $ sau cum s\u0103 \u00eemp\u0103r\u021bi\u021bi corect un server?<\/a><\/noindex> (sunt disponibile op\u021biuni cu RAID1 \u0219i RAID10, p\u00e2n\u0103 la 24 nuclee \u0219i p\u00e2n\u0103 la 40GB DDR4).<\/p>\n<p><b>Dell R730xd la jum\u0103tate de pre\u021b \u00een centrul de date Equinix Tier IV din Amsterdam?<\/b> Numai la noi <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB de la 199 $<\/a><\/noindex> \u00een Olanda! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 de la 99 $!<\/b><\/b> Citi\u021bi despre <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Cum s\u0103 construi\u021bi o infrastructur\u0103 de clas\u0103 enterprise folosind servere Dell R730xd E5-2650 v4 la pre\u021buri foarte mici de 9000 \u20ac?<\/a><\/noindex><br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/487638\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u041a\u0440\u0430\u0441\u043d\u043e\u044f\u0440\u0441\u043a\u00bb. 25 \u0438\u044e\u043d\u044f, 12:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0411\u044b\u0432\u0430\u0435\u0442, \u0447\u0442\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0435 \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u0443\u044e\u0442 \u0441 \u0442\u0435\u043e\u0440\u0438\u0435\u0439, \u0433\u0434\u0435 \u043d\u0435 \u0443\u0447\u0442\u0435\u043d\u044b \u0432\u0430\u0436\u043d\u044b\u0435 \u0434\u043b\u044f \u043a\u043e\u043c\u043c\u0435\u0440\u0447\u0435\u0441\u043a\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 \u0430\u0441\u043f\u0435\u043a\u0442\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0432\u044b\u0431\u043e\u0440\u0430 \u0438 \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432 \u043a \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-56365","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u041c\u0438\u0445\u0430\u0438\u043b \u0422\u044e\u043b\u0435\u043d\u0435\u0432 (MongoDB): Causal consistency: \u043e\u0442 \u0442\u0435\u043e\u0440\u0438\u0438 \u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-10T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:04:37+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Mihail Tyulenev (MongoDB): Consisten\u021ba cauzal\u0103: de la teorie la practic\u0103 | ProHoster","description":"Urm\u0103toarea conferin\u021b\u0103 HighLoad++ va avea loc pe 6 \u0219i 7 aprilie 2020 \u00een Sankt Petersburg. Detalii \u0219i bilete la link.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u041c\u0438\u0445\u0430\u0438\u043b \u0422\u044e\u043b\u0435\u043d\u0435\u0432 (MongoDB): Causal consistency: \u043e\u0442 \u0442\u0435\u043e\u0440\u0438\u0438 \u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 | ProHoster","og:description":"\u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e \u0441\u0441\u044b\u043b\u043a\u0435.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-10T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56365","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:26:38","updated":"2022-09-29 16:36:31","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/56365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=56365"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/56365\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=56365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=56365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=56365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}