HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Déi nächst HighLoad++ Konferenz gëtt de 6. a 7. Abrëll 2020 zu St.
Detailer an Ticketen Link. HighLoad++ Sibirien 2019. Hall "Krasnoyarsk". 25. Juni, 12:00. Theses et Presentatioun.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Et geschitt, datt praktesch Ufuerderunge Konflikt mat Theorie, wou Aspekter wichteg fir e kommerziellen Produit net Rechnung gedroe ginn. Dëst Gespréich presentéiert e Prozess fir verschidde Approche ze wielen an ze kombinéieren fir Kausal Konsistenz Komponenten ze kreéieren baséiert op akademescher Fuerschung baséiert op den Ufuerderunge vun engem kommerziellen Produkt. Lauschterer léieren iwwer existéierend theoretesch Approche fir logesch Aueren, Ofhängegkeetsverfolgung, Systemsécherheet, Auersynchroniséierung, a firwat MongoDB sech op bestëmmte Léisunge néiergelooss huet.

Mikhail Tyulenev (nach MT bezeechent): - Ech wäert iwwer Causal Konsequenz schwätzen - dëst ass eng Feature déi mir am MongoDB geschafft hunn. Ech schaffen an enger Grupp vu verdeelt Systemer, mir hunn et virun ongeféier zwee Joer gemaach.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Am Prozess hunn ech mech misse mat vill akademescher Fuerschung vertraut maachen, well dës Feature zimlech gutt studéiert gouf. Et huet sech erausgestallt datt keen eenzegen Artikel an dat passt wat an enger Produktiounsdatebank erfuerderlech ass wéinst ganz spezifesche Viraussetzungen déi wahrscheinlech an all Produktiounsapplikatioun präsent sinn.

Ech wäert schwätzen iwwer wéi mir als Konsumenten vun der akademescher Fuerschung eppes dovunner virbereeden, wat mir dann eise Benotzer als e fäerdege Plat presentéiere kënnen, dee praktesch a sécher ass ze benotzen.

Kausal Konsequenz. Loosst eis d'Konzepter definéieren

Fir unzefänken, wëll ech allgemeng soen wat Causal Konsistenz ass. Et ginn zwee Personnagen - Leonard a Penny (TV Serie "The Big Bang Theory"):

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Loosst eis soen datt de Penny an Europa ass an de Leonard wëll hir eng Iwwerraschungsparty maachen. An hien kann näischt Besseres denken wéi hatt vu senger Frëndschaftslëscht ze geheien, all seng Frënn en Update op Feed ze schécken: "Loosst eis Penny glécklech maachen!" (si ass an Europa, während si schléift, si gesäit dat alles net a kann et net gesinn, well si net do ass). Schlussendlech läscht si dëse Post, läscht et aus dem Feed a restauréiert den Zougang sou datt hatt näischt bemierkt an et gëtt kee Skandal.
Dëst ass alles gutt a gutt, awer loosst eis unhuelen datt de System verdeelt ass an et e bësse falsch gaang ass. Et kann zum Beispill geschéien datt dem Penny seng Zougangsbeschränkung geschitt ass nodeems dëse Post opgetaucht ass, wann d'Evenementer net mat Ursaach an Effekt verbonne sinn. Eigentlech ass dëst e Beispill vu wann Causal Konsistenz erfuerderlech ass fir eng Geschäftsfunktioun ze maachen (an dësem Fall).

Tatsächlech sinn dëst zimlech net-trivial Eegeschafte vun der Datebank - ganz wéineg Leit ënnerstëtzen se. Loosst eis op d'Modeller goen.

Konsistenz Modeller

Wat ass genau e Konsistenzmodell an Datenbanken? Dëst sinn e puer vun de Garantien, déi e verdeelt System gëtt iwwer wéi eng Donnéeën de Client ka kréien a wéi eng Reihenfolge.

Prinzipiell kommen all Konsistenzmodeller op wéi ähnlech e verdeelt System zu engem System ass, deen zum Beispill op engem Node op engem Laptop leeft. An esou ass e System deen op Dausende vu geo-verdeelte "Nodes" leeft ähnlech wéi e Laptop, an deem all dës Eegeschaften am Prinzip automatesch ausgefouert ginn.

Dofir gi Konsistenzmodeller nëmme fir verdeelt Systemer applizéiert. All Systemer, déi virdru existéiert an op der selwechter vertikaler Skala operéiert hunn, hunn net esou Problemer erlieft. Et gouf ee Buffer-Cache, an do gouf ëmmer alles gelies.

Modell staark

Eigentlech ass deen alleréischte Modell Strong (oder d'Erhéijungsfäegkeet Linn, wéi et dacks genannt gëtt). Dëst ass e Konsistenzmodell dee garantéiert datt all Ännerung, eemol bestätegt datt et geschitt ass, fir all Benotzer vum System sichtbar ass.

Dëst erstellt eng global Uerdnung vun all Eventer an der Datebank. Dëst ass eng ganz staark Konsistenzeigenschaft, an et ass allgemeng ganz deier. Allerdéngs ass et ganz gutt ënnerstëtzt. Et ass just ganz deier a lues - et gëtt just selten benotzt. Dëst nennt een Erhéijungsfäegkeet.

Et gëtt eng aner, méi staark Eegeschafte déi am Spanner ënnerstëtzt gëtt - extern Konsistenz genannt. Mir schwätzen iwwer et e bësse méi spéit.

Ursaach

Deen nächsten ass Causal, dat ass genau dat wat ech geschwat hunn. Et gi verschidde méi Ënnerniveauen tëscht Strong a Causal, iwwer déi ech net wäert schwätzen, awer all kachen op Causal erof. Dëst ass e wichtege Modell well et de stäerkste vun alle Modeller ass, déi stäerkst Konsequenz an der Präsenz vun engem Netzwierk oder Partitionen.

Causals sinn eigentlech eng Situatioun an där Evenementer duerch eng Ursaach-an-Effekt Relatioun verbonne sinn. Ganz dacks gi se ugesi wéi Liest Är Rechter aus der Siicht vum Client. Wann de Client e puer Wäerter observéiert huet, kann hien keng Wäerter gesinn déi an der Vergaangenheet waren. Hie fänkt scho Präfix Liesungen ze gesinn. Et kënnt alles op d'selwecht erof.
Causals als Konsistenzmodell ass eng partiell Uerdnung vun Eventer um Server, an deem Eventer vun alle Clienten an der selwechter Sequenz observéiert ginn. An dësem Fall, Leonard a Penny.

Eventuell

Den drëtte Modell ass Eventuell Konsistenz. Dëst ass wat absolut all verdeelt Systemer ënnerstëtzen, de minimale Modell deen iwwerhaapt Sënn mécht. Et heescht déi folgend: wa mir e puer Ännerungen an den Donnéeën hunn, ginn se iergendwann konsequent.

Zu esou engem Moment seet se näischt, soss géif se an Extern Konsistenz ginn - et wier eng ganz aner Geschicht. Trotzdem ass dëst e ganz populäre Modell, am meeschte verbreet. Par défaut benotzen all Benotzer vun verdeelt Systemer Eventuell Konsistenz.

Ech wëll e puer komparativ Beispiller ginn:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Wat bedeiten dës Pfeile?

  • Latenz. Wéi d'Konsistenzstäerkt eropgeet, gëtt se aus offensichtleche Grënn méi grouss: Dir musst méi Opzeechnunge maachen, Bestätegung vun all Hosten an Noden kréien, déi am Cluster deelhuelen, datt d'Donnéeën scho sinn. Deementspriechend huet Eventuell Konsistenz déi séierst Äntwert, well do, an der Regel, kënnt Dir et souguer an d'Erënnerung engagéieren an dëst wäert am Prinzip duergoen.
  • Disponibilitéit. Wa mir dat verstinn als d'Fäegkeet vum System ze reagéieren an der Präsenz vun Netzpausen, Partitionen oder iergendenger Aart vu Feeler, erhéicht d'Feeltoleranz wéi de Konsistenzmodell erofgeet, well et genuch fir eis ass datt een Host lieft a gläichzäiteg Zäit produzéiert puer Donnéeën. Eventuell Konsistenz garantéiert iwwerhaapt näischt iwwer d'Donnéeën - et kann alles sinn.
  • Anomalien. Zur selwechter Zäit klëmmt natierlech d'Zuel vun Anomalien. A Strong Konsistenz solle se bal guer net existéieren, awer an eventuell Konsistenz kënne se alles sinn. D'Fro stellt sech: Firwat wielen d'Leit Eventuell Konsistenz wann et Anomalien enthält? D'Äntwert ass datt Eventuell Konsistenzmodeller applicabel sinn an Anomalien existéieren, zum Beispill, an enger kuerzer Zäit; et ass méiglech den Wizard ze benotzen fir konsequent Donnéeën ze liesen a méi oder manner ze liesen; Et ass dacks méiglech staark Konsistenzmodeller ze benotzen. An der Praxis funktionnéiert dat, an dacks ass d'Zuel vun Anomalien an der Zäit limitéiert.

CAP-Theorem

Wann Dir d'Wierder Konsistenz, Disponibilitéit gesitt - wat kënnt Iech am Kapp? Dat ass richteg - CAP Theorem! Elo wëll ech de Mythos verdreiwen ... Et sinn net ech - et ass de Martin Kleppmann, deen e wonnerbaren Artikel geschriwwen huet, e wonnerschéint Buch.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

De CAP-Theorem ass e Prinzip, deen an den 2000er formuléiert gouf, datt Konsistenz, Disponibilitéit, Partitionen: huelt zwee, an Dir kënnt net dräi wielen. Et war e bestëmmte Prinzip. Et gouf als Theorem e puer Joer méi spéit vum Gilbert a Lynch bewisen. Dunn huet dëst ugefaang als Mantra benotzt ze ginn - Systemer hunn ugefaang an CA, CP, AP a sou weider opgedeelt ze ginn.

Dësen Theorem gouf tatsächlech fir déi folgend Fäll bewisen ... Als éischt gouf d'Disponibilitéit net als e kontinuéierleche Wäert vun Null bis Honnerte ugesinn (0 - de System ass "dout", 100 - reagéiert séier; mir si gewinnt et esou ze betruechten) , awer als Eegentum vum Algorithmus, dee garantéiert datt fir all seng Ausféierungen Daten zréckginn.

Et gëtt guer kee Wuert iwwer d'Äntwertzäit! Et gëtt en Algorithmus deen Daten no 100 Joer zréckginn - en absolut wonnerbare verfügbaren Algorithmus, deen Deel vum CAP-Theorem ass.
Zweetens: den Theorem gouf bewisen fir Ännerungen an de Wäerter vum selwechte Schlëssel, trotz der Tatsaach datt dës Ännerungen resizable sinn. Dëst bedeit datt se an der Realitéit praktesch net benotzt ginn, well d'Modeller sinn ënnerschiddlech Eventuell Konsistenz, Strong Konsistenz (vläicht).

Fir wat ass dat alles? Ausserdeem ass de CAP-Theorem a genau der Form an där et bewisen gouf praktesch net applicabel a gëtt selten benotzt. An theoretesch Form limitéiert et iergendwéi alles. Et stellt sech e gewësse Prinzip eraus, deen intuitiv korrekt ass, awer am Allgemengen net bewisen ass.

Causal Konsequenz ass de stäerkste Modell

Wat elo geschitt ass datt Dir all dräi Saache kritt: Konsistenz, Disponibilitéit mat Partitionen. Besonnesch Causal Konsistenz ass de stäerkste Konsistenzmodell, deen nach ëmmer an der Präsenz vu Partitionen funktionnéiert (Paus am Netz). Dofir ass et sou grousst Interessi, an dofir hu mir et ugeholl.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Éischtens, et vereinfacht d'Aarbecht vun Applikatioun Entwéckler. Besonnesch d'Präsenz vu grousser Ënnerstëtzung vum Server: wann all Rekorder, déi an engem Client optrieden, garantéiert sinn an der selwechter Sequenz op engem anere Client ze kommen. Zweetens, et toleréiert Partitionen.

MongoDB Intern Kichen

Denkt drun datt et Mëttegiessen ass, gi mir an d'Kichen. Ech soen Iech iwwer de Systemmodell, nämlech wat MongoDB ass fir déi, déi fir d'éischte Kéier iwwer sou eng Datebank héieren.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

MongoDB (nodréiglech als "MongoDB" bezeechent) ass e verdeelt System deen d'horizontale Skaléierung ënnerstëtzt, dat heescht Scherpf; a bannent all Shard ënnerstëtzt et och Daten Redundanz, dat heescht Replikatioun.

Sharding an MongoDB (net eng relational Datebank) mécht automatesch Balance, dat heescht, all Sammlung vun Dokumenter (oder "Table" a punkto relational Donnéeën) ass a Stécker opgedeelt, an de Server bewegt se automatesch tëscht Shards.

De Query Router, deen Ufroe verdeelt, fir e Client ass e Client duerch deen et funktionnéiert. Et weess scho wou a wéi eng Donnéeën sinn a riicht all Ufroen op de richtege Schnëtt.

En anere wichtege Punkt: MongoDB ass en eenzege Master. Et gëtt ee Primär - et kann records huelen déi d'Schlësselen ënnerstëtzen déi et enthält. Dir kënnt net Multi-Master Schreiwen maachen.

Mir hunn Verëffentlechung 4.2 gemaach - nei interessant Saache sinn do opgetaucht. Besonnesch hu si de Lucene - search - nämlech ausféierbar Java direkt an de Mongo agebaut, an do gouf et méiglech Recherchen duerch Lucene auszeféieren, d'selwecht wéi an Elastica.

A si hunn en neit Produkt gemaach - Charts, et ass och verfügbar op Atlas (Mongo senger eegener Cloud). Si hunn e Free Tier - Dir kënnt domat spillen. Ech hu wierklech gär Charts - Datenvisualiséierung, ganz intuitiv.

Zutaten Causal Konsequenz

Ech hunn ongeféier 230 Artikelen gezielt, déi zu dësem Thema publizéiert goufen - vum Leslie Lampert. Elo aus menger Erënnerung wäert ech Iech e puer Deeler vun dëse Materialien vermëttelen.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Et huet alles ugefaang mat engem Artikel vum Leslie Lampert, deen an de 1970er Jore geschriwwen ass. Wéi Dir kënnt gesinn, ass e puer Fuerschungen iwwer dëst Thema nach ëmmer amgaang. Elo kausal Konsistenz erlieft Interessi am Zesummenhang mat der Entwécklung vun verdeelt Systemer.

Restriktiounen

Wéi eng Restriktiounen ginn et? Dëst ass eigentlech ee vun den Haaptpunkten, well d'Restriktiounen, déi e Produktiounssystem setzt, ganz anescht sinn wéi d'Restriktiounen, déi an akademeschen Artikelen existéieren. Si sinn dacks zimlech kënschtlech.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

  • Als éischt ass "MongoDB" en eenzege Master, wéi ech scho gesot hunn (dëst vereinfacht vill).
  • Mir gleewen, datt de System ronn 10 dausend shards Ënnerstëtzung soll. Mir kënnen keng architektonesch Entscheedungen treffen, déi dëse Wäert explizit limitéieren.
  • Mir hunn eng Wollek, mä mir dovun ausgoen, datt eng Persoun nach d'Méiglechkeet hunn soll wann hien download binär, leeft et op sengem Laptop, an alles Wierker super.
  • Mir huelen un eppes wat d'Recherche selten iwwerhëlt: extern Clientë kënnen alles maachen wat se wëllen. MongoDB ass Open Source. Deementspriechend kënnen d'Clienten sou schlau a rosen sinn - si kënnen alles briechen. Mir spekuléieren datt byzantinesch Feilors entstinn.
  • Fir extern Clienten, déi ausserhalb vum Perimeter sinn, gëtt et eng wichteg Begrenzung: wann dës Fonktioun behënnert ass, da sollt keng Leeschtungsverschlechterung observéiert ginn.
  • En anere Punkt ass allgemeng anti-akademesch: d'Kompatibilitéit vu fréiere Versiounen an zukünfteg. Al Chauffeuren mussen nei Aktualiséierungen ënnerstëtzen, an der Datebank muss al Chauffeuren Ënnerstëtzung.

Am Allgemengen, setzt all dëst Restriktiounen.

Kausal Konsistenz Komponenten

Ech wäert elo iwwer e puer vun de Komponente schwätzen. Wa mir Causal Konsequenz am Allgemengen betruechten, kënne mir Blocks auswielen. Mir hunn aus Wierker gewielt, déi zu engem bestëmmte Block gehéieren: Ofhängegkeet Tracking, Aueren auswielen, wéi dës Auere matenee synchroniséiert kënne ginn, a wéi mir Sécherheet garantéieren - dëst ass e graff Kontur vu wat ech wäert schwätzen:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Voll Ofhängegkeet Tracking

Firwat ass et néideg? Also datt wann Daten replizéiert ginn, all Rekord, all Datenännerung enthält Informatiounen iwwer wéi eng Ännerungen et hänkt. Déi éischt an naiv Ännerung ass wann all Message, deen e Rekord enthält, Informatioun iwwer fréier Messagen enthält:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

An dësem Beispill ass d'Zuel an de Curly Klammeren d'Rekordzuelen. Heiansdo ginn dës Opzeechnunge mat Wäerter souguer an hirer Ganzheet transferéiert, heiansdo ginn e puer Versioune transferéiert. Déi ënnescht Linn ass datt all Ännerung Informatioun iwwer déi virdrun enthält (natierlech dréit dëst alles a sech selwer).

Firwat hu mir décidéiert dës Approche net ze benotzen (voll Tracking)? Selbstverständlech, well dës Approche onpraktesch ass: all Ännerung vun engem sozialen Netzwierk hänkt vun all fréiere Ännerunge vun deem sozialen Netzwierk of, iwwerdroen, soen, Facebook oder VKontakte an all Update. Trotzdem gëtt et vill Fuerschung iwwer Full Dependency Tracking - dëst si pre-sozial Netzwierker; fir e puer Situatiounen funktionnéiert et wierklech.

Explizit Ofhängegkeet Tracking

Déi nächst ass méi limitéiert. Hei gëtt och d'Iwwerdroung vun Informatioun berücksichtegt, awer nëmmen dat wat kloer ofhängeg ass. Wat hänkt dovun of, an der Regel, gëtt vun der Applikatioun festgeluegt. Wann d'Date replizéiert ginn, gëtt d'Ufro nëmmen Äntwerten zréck wann virdrun Ofhängegkeeten zefridden sinn, dat heescht gewisen. Dëst ass d'Essenz vu wéi kausal Konsistenz funktionnéiert.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Si gesäit, datt Rekord 5 hänkt records 1, 2, 3, 4 - deementspriechend, si waart ier de Client Zougang zu den Ännerungen huet Penny Zougang Decisioun gemaach, wann all virdrun Ännerungen schonn duerch d'Datebank passéiert.

Dëst passt eis och net, well et nach ze vill Informatioun gëtt, an et wäert d'Saache méi lues maachen. Et gëtt eng aner Approche ...

Lamport Uhr

Si si ganz al. Lamport Clock heescht datt dës Ofhängegkeeten an eng scalar Funktioun gefaltet ginn, déi Lamport Clock genannt gëtt.

Eng scalar Funktioun ass eng abstrakt Zuel. Et gëtt dacks logesch Zäit genannt. Mat all Event gëtt dëse Konter erop. De Konter, deen am Moment dem Prozess bekannt ass, schéckt all Message. Et ass kloer datt Prozesser aus der Synchroniséierung kënne sinn, si kënne ganz aner Zäiten hunn. Trotzdem balancéiert de System iergendwéi d'Auer mat sou Messagen. Wat geschitt an dësem Fall?

Ech hunn dee grousse Schnëtt an zwee gedeelt fir et kloer ze maachen: Frënn kënnen an engem Node liewen, deen e Stéck vun der Sammlung enthält, a Feed kann an engem aneren Node liewen, deen e Stéck vun dëser Sammlung enthält. Ass et kloer wéi se aus der Linn kommen? Éischt Feed seet: "Replizéiert", an dann Frënn. Wann de System keng Zort Garantie gëtt datt de Feed net gewise gëtt bis d'Friends Ofhängegkeeten an der Friends Sammlung och geliwwert ginn, da wäerte mir genau d'Situatioun hunn, déi ech ernimmt hunn.

Dir gesitt wéi d'Konterzäit op Feed logesch eropgeet:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Also d'Haapteigenschaft vun dëser Lamport Clock a Causal Konsistenz (erklärt duerch Lamport Clock) ass dëst: wa mir Eventer A a B hunn, an Event B hänkt vum Event A * of, dann folgt et datt d'LogicalTime of Event A manner ass wéi LogicalTime vum Event B.

* Heiansdo soen se och datt A virum B geschitt ass, dat ass, A virun B geschitt ass - dëst ass eng gewësse Relatioun déi deelweis de ganze Set vun Eventer bestellt, déi am Allgemengen geschitt sinn.

De Géigendeel ass falsch. Dëst ass eigentlech ee vun den Haapt Nodeeler vun Lamport Clock - deelweis Uerdnung. Et gëtt e Konzept iwwer simultan Eventer, dat heescht Eventer an deenen weder (A virun B geschitt ass) nach (A virun B geschitt ass). E Beispill wier dem Leonard seng parallel Zousatz vun engem aneren als Frënd (net emol Leonard, mee Sheldon, zum Beispill).
Dëst ass d'Eegeschaft, déi dacks benotzt gëtt wann Dir mat Lamport-Uhren schafft: si kucken speziell op d'Funktioun an dovun ofschléissen se datt vläicht dës Eventer ofhängeg sinn. Well ee Wee stëmmt: wann LogicalTime A manner wéi LogicalTime B ass, da kann B net virum A geschéien; a wa méi, dann vläicht.

Vector Auer

Déi logesch Entwécklung vun der Lamport Auer ass de Vector Clock. Si ënnerscheeden sech an datt all Node deen hei ass seng eege separat Auer enthält, a si ginn als Vektor iwwerdroen.
An dësem Fall gesitt Dir datt den nullende Index vum Vektor fir Feed verantwortlech ass, an den éischten Index vum Vektor ass fir Frënn (jiddereng vun dësen Noden). An elo wäerte se eropgoen: den Nullindex vum "Feed" erhéicht beim Schreiwen - 1, 2, 3:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Firwat ass Vector Clock besser? Well se erlaben Iech erauszefannen wéi eng Eventer gläichzäiteg sinn a wéini se op verschiddene Wirbelen optrieden. Dëst ass ganz wichteg fir e Sharding System wéi MongoDB. Mir hunn dat awer net gewielt, obwuel et eng wonnerbar Saach ass, an et funktionnéiert super, an et géif eis wahrscheinlech passen ...

Wa mir 10 dausend shards hunn, kënne mir net 10 dausend Komponente Transfert, och wa mir et kompriméieren oder mat eppes anescht kommen - d'Notzlaascht wäert nach e puer Mol méi kleng sinn wéi de Volume vun dësem ganze Vektor. Dofir, eis Häerzer an Zänn ze gräifen, hu mir dës Approche opginn an op eng aner geplënnert.

Spanner TrueTime. Atom Auer

Ech sot et géif eng Geschicht iwwer Spanner ginn. Dëst ass eng cool Saach, direkt aus dem XNUMX. Joerhonnert: Atomuhren, GPS Synchroniséierung.

Wat ass d'Iddi? "Spanner" ass e Google System dee viru kuerzem souguer fir Leit verfügbar ass (si hunn SQL derbäi gesat). All Transaktioun do huet e puer Zäitstempel. Well d'Zäit synchroniséiert ass*, kann all Event eng spezifesch Zäit zougewisen ginn - Atomuhren hunn eng Waardezäit, duerno ass eng aner Zäit garantéiert "geschéien".

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Also, andeems Dir einfach an d'Datebank schreift an e puer Zäit waart, ass d'Serialiséierung vum Event automatesch garantéiert. Si hunn dee stäerkste Konsistenzmodell deen am Prinzip virgestallt ka ginn - et ass Extern Konsistenz.

* Dëst ass den Haaptproblem mat Lampart Aueren - si sinn ni synchron op verdeelt Systemer. Si kënnen divergéieren; och mat NTP funktionnéiere se nach ëmmer net ganz gutt. "Spanner" huet eng atomar Auer an Synchroniséierung, et schéngt, ass Mikrosekonnen.

Firwat hu mir net gewielt? Mir huelen net un datt eis Benotzer eng agebaute Atomuhr hunn. Wann se optrieden, an all Laptop agebaut ginn, gëtt et eng Aart vun super cool GPS Synchroniséierung - dann jo ... Mee fir de Moment ass dat Bescht wat méiglech ass Amazon, Base Stations - fir Fanatiker ... Also hu mir aner Aueren benotzt .

Hybrid Auer

Dëst ass tatsächlech wat am MongoDB tickt wann Dir Kausal Konsistenz garantéiert. Wéi sinn se Hybrid? Hybrid ass e skalare Wäert, awer et huet zwee Komponenten:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

  • Déi éischt ass d'Unix Epoch (wéivill Sekonnen sinn zënter dem "Ufank vun der Computerwelt") vergaangen.
  • Déi zweet ass e puer Inkrement, och en 32-Bit net ënnerschriwwenen Int.

Dat ass alles, eigentlech. Et gëtt dës Approche: deen Deel dee fir d'Zäit verantwortlech ass ass déi ganzen Zäit mat der Auer synchroniséiert; all Kéier wann en Update geschitt, gëtt dësen Deel mat der Auer synchroniséiert an et stellt sech eraus datt d'Zäit ëmmer méi oder manner richteg ass, an d'Inkrement erlaabt Iech tëscht Eventer z'ënnerscheeden, déi am selwechte Moment geschitt sinn.

Firwat ass dëst wichteg fir MongoDB? Well et erlaabt Iech eng Aart vu Backup-Restauranten zu engem gewëssen Zäitpunkt ze maachen, dat heescht, d'Evenement gëtt vun der Zäit indexéiert. Dëst ass wichteg wann verschidden Evenementer néideg sinn; Fir eng Datebank sinn d'Evenementer Ännerungen an der Datebank, déi a bestëmmten Zäitintervaller geschitt sinn.

Ech soen Iech de wichtegste Grond nëmmen fir Iech (w.e.g., sot keen)! Mir hunn dat gemaach well dëst ass wéi organiséiert, indexéiert Daten am MongoDB OpLog ausgesinn. OpLog ass eng Datestruktur déi absolut all Ännerungen an der Datebank enthält: si gi fir d'éischt op OpLog, an dann gi se op d'Späichere selwer ugewannt am Fall wann et e replizéierten Datum oder Shard ass.

Dëst war den Haaptgrond. Trotzdem ginn et och praktesch Ufuerderunge fir eng Datebank z'entwéckelen, dat heescht datt et einfach soll sinn - e klenge Code, sou wéineg wéi méiglech futti Saachen, déi iwwerschriwwe a getest musse ginn. D'Tatsaach, datt eis Oplogs duerch Hybriduhren indexéiert goufen, huet vill gehollef an huet eis erlaabt déi richteg Wiel ze maachen. Et huet sech wierklech bezuelt an iergendwéi magesch um alleréischte Prototyp geschafft. Et war ganz cool!

Auer Synchroniséierung

Et gi verschidde Synchroniséierungsmethoden an der wëssenschaftlecher Literatur beschriwwen. Ech schwätzen iwwer Synchroniséierung wa mir zwee verschidde Schnëtt hunn. Wann et e Replica-Set ass, brauch keng Synchroniséierung: dëst ass e "Single Master"; Mir hunn en OpLog, an deem all Ännerungen falen - an dësem Fall ass alles schonn sequenziell am "Oplog" selwer bestallt. Awer wa mir zwee verschidde Schnëtt hunn, ass d'Zäitsynchroniséierung hei wichteg. Dëst ass wou d'Vektoruhr méi gehollef huet! Awer mir hunn se net.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Déi zweet ass gëeegent - dat ass "Heartbeats". Et ass méiglech e puer Signaler auszetauschen déi all Zäitunitéit optrieden. Awer Heartbeats sinn ze lues, mir kënnen eise Client net latency ubidden.

Richteg Zäit ass natierlech eng wonnerbar Saach. Awer, erëm, dëst ass wahrscheinlech d'Zukunft ... Och wann et schonn am Atlas gemaach ka ginn, ginn et scho séier "Amazon" Zäitsynchroniséierer. Awer et wäert net fir jiddereen verfügbar sinn.

Klatsch ass wann all Messagen Zäit enthalen. Dëst ass ongeféier wat mir benotzen. All Message tëscht Noden, e Chauffer, en Dateknuet Router, absolut alles fir MongoDB ass eng Zort Element, eng Datebankkomponent déi eng Auer enthält déi leeft. Si hunn d'Bedeitung vun Hybrid Zäit iwwerall, et gëtt iwwerdroen. 64 bits? Dëst erlaabt, dëst ass méiglech.

Wéi funktionéiert dat alles zesummen?

Hei kucken ech op ee Replika-Set fir et e bësse méi einfach ze maachen. Et gi Primär a Secondaire. Sekundär mécht Replikatioun an ass net ëmmer komplett mat Primär synchroniséiert.

Eng Insertioun geschitt an de "Primery" mat engem gewëssen Zäitwäert. Dësen Insert erhéicht den internen Zuel ëm 11, wann dëst de Maximum ass. Oder et wäert d'Auerwäerter iwwerpréiwen a mat der Auer synchroniséieren wann d'Auerwäerter méi grouss sinn. Dëst erlaabt Iech no Zäit ze organiséieren.

Nodeems hien d'Opnahm gemaach huet, geschitt e wichtege Moment. D'Auer ass am "MongoDB" a gëtt nëmme erhéicht am Fall vum Schreiwen op "Oplog". Dëst ass den Event deen den Zoustand vum System ännert. An absolut all klassesch Artikelen gëtt en Event ugesinn wann e Message op en Node trefft: de Message ass ukomm, dat heescht datt de System säin Zoustand geännert huet.

Dëst ass wéinst der Tatsaach, datt während der Fuerschung net ganz kloer ass wéi dëse Message interpretéiert gëtt. Mir wëssen sécher datt wann et net am "Oplog" reflektéiert gëtt, da gëtt et op kee Fall interpretéiert, an eng Ännerung vum Zoustand vum System ass nëmmen eng Entrée am "Oplog". Dëst vereinfacht alles fir eis: de Modell vereinfacht et, an erlaabt eis et an engem Replica-Set ze organiséieren, a vill aner nëtzlech Saachen.

De Wäert, dee schonn op den "Oplog" geschriwwe gëtt, gëtt zréckginn - mir wëssen datt den "Oplog" dëse Wäert scho enthält, a seng Zäit ass 12. Elo, soen, d'Liesen fänkt vun engem aneren Node un (Sekundär), an et iwwerdréit AfterClusterTime an de Message. Hie seet: "Ech brauch alles wat geschitt ass op d'mannst no 12 oder während zwielef" (kuckt d'Bild uewen).

Dëst ass wat Causal a consistent (CAT) genannt gëtt. Et gëtt esou e Konzept an der Theorie datt dëst e Stéck Zäit ass, wat u sech konsequent ass. An dësem Fall kënne mir soen datt dëst den Zoustand vum System ass deen zu der Zäit 12 observéiert gouf.

Elo gëtt et nach näischt hei, well dës Aart simuléiert d'Situatioun wann Dir de Secondaire braucht fir Daten aus dem Primär ze replizéieren. Hie waart ... An elo sinn d'Donnéeën ukomm - hien bréngt dës Wäerter zréck.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Dat ass zimlech wéi et alles funktionnéiert. Bal.

Wat heescht "bal"? Loosst eis unhuelen datt et eng Persoun ass déi gelies a verstanen huet wéi dëst alles funktionnéiert. Ech hu gemierkt datt all Kéier wann ClusterTime geschitt, et aktualiséiert déi intern logesch Auer, an dann erhéicht den nächsten Entrée ëm een. Dës Funktioun dauert 20 Linnen. Loosst eis soen datt dës Persoun déi gréisste 64-Bit Zuel iwwerdréit, minus een.

Firwat "Minus eent"? Well déi intern Auer an dëse Wäert ersat gëtt (natierlech ass dëst dee gréisste méiglech a méi grouss wéi déi aktuell Zäit), da wäert eng Entrée an "Oplog" geschéien, an d'Auer gëtt vun enger anerer Eenheet erhéicht - an et gëtt scho e Maximumwäert sinn (et ginn einfach all Unitéiten, et gëtt néierens soss ze goen), unsaint ints).

Et ass kloer, datt duerno de System fir näischt absolut onzougänglechen gëtt. Et kann nëmmen entlaascht a gebotzt ginn - vill manuell Aarbecht. Voll Disponibilitéit:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Ausserdeem, wann dëst anzwousch anescht replizéiert gëtt, da fällt de ganze Cluster einfach erof. Eng absolut inakzeptabel Situatioun déi jidderee ganz séier an einfach organiséieren kann! Dofir hu mir dëse Moment als ee vun de wichtegsten ugesinn. Wéi et ze verhënneren?

Eise Wee ass ClusterTime z'ënnerschreiwen

Esou gëtt et an der Noriicht iwwerdroen (virum bloen Text). Awer mir hunn och ugefaang eng Ënnerschrëft ze generéieren (bloen Text):

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

D'Ënnerschrëft gëtt vun engem Schlëssel generéiert deen an der Datebank gespäichert ass, an engem séchere Perimeter; selwer gëtt generéiert an aktualiséiert (Benotzer gesinn näischt doriwwer). En Hash gëtt generéiert, an all Message gëtt ënnerschriwwen wann se erstallt a validéiert wann se kritt.
D'Fro stellt sech wahrscheinlech an de Kapp vun de Leit: "Wéi vill verlangsamt dëst d'Saache?" Ech hunn Iech gesot datt et séier soll funktionnéieren, besonnesch an der Verontreiung vun dëser Feature.

Wat heescht et Causal Konsequenz an dësem Fall ze benotzen? Dëst ass fir den AfterClusterTime Parameter ze weisen. Ouni dëst wäert et souwisou einfach Wäerter passéieren. Klatsch, ab Versioun 3.6, funktionnéiert ëmmer.

Wa mir déi konstant Generatioun vun Ënnerschrëften verloossen, wäert et de System verlangsamen och an der Verontreiung vun enger Feature, déi eis Approche an Ufuerderungen net entsprécht. Also wat hu mir gemaach?

Maacht et séier!

Et ass eng zimlech einfach Saach, awer den Trick ass interessant - ech deelen et, vläicht wäert iergendeen interesséiert sinn.
Mir hunn en Hash deen déi ënnerschriwwen Donnéeën späichert. All Daten ginn duerch de Cache. De Cache ënnerschreift net déi spezifesch Zäit, awer de Range. Wann e puer Wäert ukomm ass, generéiere mir e Range, maskéieren déi lescht 16 Bits, a mir ënnerschreiwen dëse Wäert:

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Andeems mir esou eng Ënnerschrëft kréien, beschleunegen mir de System (relativ) 65 dausend Mol. Et funktionnéiert super: wa mir Experimenter gemaach hunn, ass d'Zäit tatsächlech ëm 10 dausend Mol erofgaang wa mir e sequentiellen Update haten. Et ass kloer datt wann se op d'Chance sinn, dëst net funktionnéiert. Awer am meeschte praktesche Fäll funktionnéiert et. D'Kombinatioun vun der Range Ënnerschrëft zesumme mat der Ënnerschrëft huet de Sécherheetsproblem geléist.

Wat hu mir geléiert?

Lektioune mir aus dësem geléiert:

  • Mir mussen Material, Geschichten, Artikelen liesen, well mir vill interessant Saachen hunn. Wa mir un e puer Feature schaffen (besonnesch elo, wa mir Transaktiounen gemaach hunn, asw.), Mir mussen liesen a verstoen. Et brauch Zäit, awer et ass tatsächlech ganz nëtzlech well et kloer mécht wou mir sinn. Mir schéngen näischt Neies ze kommen - mir hunn just d'Ingredienten geholl.

    Am Allgemengen gëtt et e gewëssenen Ënnerscheed am Denken wann et eng akademesch Konferenz ass (zum Beispill Sigmon) - jidderee konzentréiert sech op nei Iddien. Wat ass nei un eisem Algorithmus? Et gëtt näischt besonnesch Neies hei. D'Neiheet läit éischter an der Aart a Weis wéi mir existéierend Approche vermëschen. Dofir ass déi éischt Saach d'Klassiker ze liesen, ugefaange mat Lampart.

  • An der Produktioun sinn d'Ufuerderunge komplett anescht. Ech si sécher, datt vill vun iech net mat "kugelfërmeg" Datenbanken an engem abstrakte Vakuum konfrontéiert sinn, mee mat normale, reelle Saachen, déi Problemer mat der Disponibilitéit, der Latenz an der Fehltoleranz hunn.
  • Déi lescht Saach ass datt mir verschidden Iddien hu missen kucken a verschidde komplett verschidden Artikelen an eng Approche kombinéieren, zesummen. D'Iddi iwwer d'Ënnerschreiwe koum zum Beispill allgemeng aus engem Artikel, deen de Paxos-Protokoll betruecht huet, dee fir net-byzantinesch Fehler am Autorisatiounsprotokoll ass, fir byzantinesch - ausserhalb vum Autorisatiounsprotokoll ... Am Allgemengen ass dat genau wat mir schlussendlech maachen.

    Et gëtt absolut näischt Neies hei! Awer soubal mir alles zesumme gemëscht hunn ... Et ass d'selwecht wéi ze soen datt d'Olivier Zalot Rezept Blödsinn ass, well Eeër, Mayonnaise a Gurken schonn erfonnt ginn ... Et ass ongeféier déiselwecht Geschicht.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Ech wäert mat dëser fäerdeg. Merci!

Är Froen

Fro vum Publikum (nodréiglech B bezeechent): - Merci, Mikhail, fir de Bericht! D'Thema iwwer Zäit ass interessant. Dir benotzt Gossiping. Si soten datt jidderee seng eegen Zäit huet, jidderee weess seng lokal Zäit. Wéi ech et verstinn, hu mir e Chauffer - et kënne vill Cliente mat Chauffeuren sinn, och Query-Planer, och shards ... A wat kënnt de System op wa mir op eemol eng Diskrepanz hunn: een decidéiert datt et fir eng Minutt vir, een eng Minutt hannert? Wou wäerte mir ophalen?

MT: - Ganz flott Fro! Ech wollt just iwwer Schnéi schwätzen. Wann ech d'Fro richteg verstinn, hu mir déi folgend Situatioun: et gëtt Schnëtt 1 a Schnëtt 2, d'Liesen geschitt aus dësen zwee Schnëtt - si hunn eng Diskrepanz, si interagéieren net mateneen, well d'Zäit déi se wëssen ass anescht, besonnesch d'Zäit datt se an oplogs existéieren.
Loosst d'soen, datt shard 1 eng Millioun records gemaach, shard 2 huet näischt iwwerhaapt, an der Demande koum zu zwee shards. An déi éischt huet eng AfterClusterTime vun iwwer eng Millioun. An esou enger Situatioun, wéi ech erkläert hunn, wäert Shard 2 guer net reagéieren.

IN: - Ech wollt wëssen, wéi se synchroniséiert a wielt eng logesch Zäit?

MT: - Ganz einfach ze synchroniséieren. Shard, wann AfterClusterTime bei him kënnt an hien keng Zäit am "Oplog" fënnt, initiéiert keng guttgeheescht. Dat ass, hien hieft seng Zäit mat sengen Hänn op dëse Wäert. Dëst bedeit datt et keng Eventer huet déi dës Ufro passen. Hien kreéiert dëst Evenement kënschtlech a gëtt domat Causal Konsistent.

IN: - Wat wann duerno nach e puer aner Evenementer zu him kommen, déi iergendwou am Netz verluer sinn?

MT: - Shard ass sou entworf datt se net erëm kommen, well et en eenzege Meeschter ass. Wann hien sech schonn ugemellt huet, da kommen se net, mä kommen méi spéit. Et kann net geschéien datt eppes iergendwou festhält, da schreift hien net, an dann kommen dës Eventer - an d'Causal Konsequenz ass gebrach. Wann hien net schreift, sollten se all nächst kommen (hie wäert op si waarden).

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

IN: - Ech hu verschidde Froen iwwer d'Schlaangen. Causal Konsistenz gëtt ugeholl datt et eng spezifesch Schlaang vun Aktiounen ass, déi musse gemaach ginn. Wat geschitt wann ee vun eise Packagen verschwënnt? Hei kënnt den 10., 11. ... den 12. ass verschwonnen, an all déi aner waarden op et richteg. An op eemol ass eisen Auto gestuerwen, mir kënnen näischt maachen. Gëtt et eng maximal Längt vun der Schlaang déi accumuléiert ier se ausgefouert gëtt? Wat fatale Versoen geschitt wann ee Staat verluer ass? Ausserdeem, wa mir opschreiwen datt et e fréiere Staat ass, da sollte mir iergendwéi dovun ausgoen? Awer si hunn hien net ewechgedréckt!

MT: - Och eng grouss Fro! Wat maache mir? MongoDB huet d'Konzept vu Quorum schreift, Quorum liest. A wéi enge Fäll kann e Message verluer goen? Wann e Schreiwen net Quorum ass oder wann e Liesen net Quorum ass (eng Aart vu Gerempels kann och festhalen).
Wat d'Kausal Konsistenz ugeet, gouf e groussen experimentellen Test gemaach, d'Resultat vun deem war datt am Fall wou Schreiwen a Liesen net Quorum sinn, Verstouss géint d'Kausal Konsequenz geschitt. Genau wat Dir seet!

Eis Rotschléi: Benotzt op d'mannst Quorum Liesung wann Dir Causal Konsistenz benotzt. An dësem Fall geet näischt verluer, och wann de Quorum-Rekord verluer geet... Dëst ass eng orthogonal Situatioun: Wann de Benotzer keng Daten verluer wëllt, muss hien e Quorum-Rekord benotzen. Kausal Konsistenz garantéiert keng Haltbarkeet. D'Haltbarkeet ass garantéiert duerch Replikatioun an d'Maschinnen, déi mat Replikatioun verbonne sinn.

IN: - Wa mir eng Instanz kreéieren déi fir eis Sharding mécht (net Meeschter, mee Sklave, respektiv), hänkt op der Unix Zäit vu senger eegener Maschinn oder op der Zäit vum "Meeschter"; Synchroniséiert et fir d'éischte Kéier oder periodesch?

MT: - Ech wäert elo klären. Shard (dh horizontal Partition) - et gëtt ëmmer e Primär do. An e Shard kann e "Meeschter" hunn an et kann Repliken sinn. Awer de Shard ënnerstëtzt ëmmer Opnam, well et muss e puer Domain ënnerstëtzen (de Shard huet Primär).

IN: - Also alles hänkt reng vum "Meeschter" of? Gëtt Meeschtesch Zäit ëmmer benotzt?

MT: - Jo. Dir kënnt figurativ soen: d'Auer tickt wann en Entrée an de "Master", an den "Oplog" geschitt.

IN: - Mir hunn e Client dee verbënnt a brauch näischt iwwer d'Zäit ze wëssen?

MT: - Dir musst guer näischt wëssen! Wa mir schwätzen iwwer wéi et op de Client funktionnéiert: wann de Client kausal Konsequenz benotze wëllt, muss hien eng Sessioun opmaachen. Elo ass alles do: Transaktiounen an der Sessioun, an d'Rechter zréckzéien ... Eng Sessioun ass d'Bestellung vu logeschen Eventer, déi mam Client geschéien.

Wann hien dës Sessioun opmaacht an do seet datt hien Causal Konsistenz wëll (wann d'Sessioun Causal Konsequenz als Standard ënnerstëtzt), funktionnéiert alles automatesch. De Chauffeur erënnert dës Zäit an erhéicht se wann en en neie Message kritt. Et erënnert un wéi eng Äntwert déi virdru vum Server zréckkoum deen d'Donnéeën zréckginn. Déi nächst Ufro enthält AfterCluster ("Zäit méi wéi dëst").

De Client brauch absolut näischt ze wëssen! Dëst ass komplett opak fir him. Wann d'Leit dës Funktiounen benotzen, wat kënne se maachen? Als éischt kënnt Dir Secondaire sécher liesen: Dir kënnt op Primär schreiwen a vu geographesch replizéierte Secondaire liesen a sécher sinn datt et funktionnéiert. Zur selwechter Zäit kënnen Sessiounen, déi op Primär opgeholl goufen, souguer op de Secondaire transferéiert ginn, dh Dir kënnt net eng Sessioun benotzen, awer e puer.

IN: - Eng nei Schicht vun der Rechenwëssenschaft - CRDT (Konfliktfräi Replizéiert Datentypen) Datentypen - ass staark mam Thema Eventuell Konsistenz verbonnen. Hutt Dir geduecht dës Zorte vun Daten an d'Datebank z'integréieren a wat kënnt Dir doriwwer soen?

MT: - Gutt Fro! CRDT mécht Sënn fir schreiwen Konflikter: an MongoDB, eenzege Meeschter.

IN: - Ech hunn eng Fro vun den Devops. An der realer Welt ginn et sou jesuitesch Situatiounen, wann de byzantinesche Feeler geschitt, a béis Leit am geschützte Perimeter fänken un de Protokoll ze pochen, Handwierkspäck op eng speziell Manéier schécken?

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

MT: - Béis Leit am Perimeter si wéi en Trojanesche Päerd! Béis Leit am Perimeter kënne vill schlecht Saache maachen.

IN: – Et ass kloer, datt ongeféier e Lach am Server hannerloosst, duerch deen Dir en Zoo vun Elefanten setzt an de ganze Stärekoup fir ëmmer zesummebréngt... Et dauert Zäit fir manuell Erhuelung... Dëst, mild gesot, ass falsch. Op der anerer Säit ass dat interessant: am richtege Liewen, an der Praxis, ginn et Situatiounen, wou natierlech ähnlech intern Attacke geschéien?

MT: - Well ech selten Sécherheetsverstéiss am richtege Liewen begéinen, kann ech net soen ob se geschéien. Awer wa mir iwwer d'Entwécklungsphilosophie schwätzen, denken mir esou: Mir hunn e Perimeter, deen d'Jongen ubitt, déi Sécherheet maachen - dëst ass e Schlass, eng Mauer; an am Perimeter kënnt Dir maachen wat Dir wëllt. Et ass kloer datt et Benotzer mat der Fäegkeet sinn nëmmen ze gesinn, an et gi Benotzer mat der Fäegkeet de Verzeechnes ze läschen.

Ofhängeg vun de Rechter, kann de Schued deen d'Benotzer maache kënnen eng Maus sinn, oder et kann en Elefant sinn. Et ass kloer datt e Benotzer mat voller Rechter iwwerhaapt alles maache kann. E Benotzer mat limitéierten Rechter kann wesentlech manner Schued verursaachen. Besonnesch kann et de System net briechen.

IN: - Am geschützte Perimeter huet een probéiert onerwaart Protokoller fir de Server ze kreéieren fir de Server komplett ze zerstéieren, a wann Dir Gléck hutt, de ganze Cluster ... Kritt et jeemools sou "gutt"?

MT: "Ech hunn nach ni vun esou Saachen héieren." D'Tatsaach, datt Dir e Server op dës Manéier crasht ass kee Geheimnis. Fail bannen, aus dem Protokoll sinn, en autoriséierte Benotzer ze sinn deen esou eppes an der Noriicht schreiwen kann ... Tatsächlech ass et onméiglech, well et wäert nach ëmmer verifizéiert ginn. Et ass méiglech dës Authentifikatioun auszeschalten fir Benotzer déi et net wëllen - dann ass dat hire Problem; sie hunn grof geschwat d'Maueren selwer zerstéiert an du kanns en Elefant do dran drécken, deen trëppelt... Mee am allgemengen kann een sech als Reparatur verkleeden, kommt en erauszéien!

IN: - Merci fir de Bericht. Sergey (Yandex). Et gëtt eng Konstant am Mong déi d'Zuel vun de Wahlmemberen am Replica Set limitéiert, an dës Konstant ass 7 (siwen). Firwat ass dëst eng konstant? Firwat ass dat net eng Zort Parameter?

MT: - Mir hunn Replica Sets mat 40 Wirbelen. Et gëtt ëmmer eng Majoritéit. Ech weess net wéi eng Versioun ...

IN: – Am Replica Set kënnt Dir net-voting-Memberen lafen, mee et gi maximal 7 Stëmmen Memberen.Wéi kënne mir de Shutdown an dësem Fall iwwerliewen wann eise Replica-Set iwwer 3 Datenzenter verdeelt ass? Een Datenzenter kann einfach ausschalten, an eng aner Maschinn kann erausfalen.

MT: – Dat läit schonn e bëssen iwwer den Ëmfang vum Rapport eraus. Dëst ass eng allgemeng Fro. Vläicht kann ech Iech spéider doriwwer soen.

HighLoad++, Mikhail Tyulenev (MongoDB): Kausal Konsistenz: vun Theorie bis Praxis

Puer Annoncen 🙂

Merci datt Dir bei eis bleift. Hutt Dir eis Artikelen gär? Wëllt Dir méi interessant Inhalt gesinn? Ënnerstëtzt eis andeems Dir eng Bestellung maacht oder Frënn empfeelt, Cloud VPS fir Entwéckler vun $ 4.99, en eenzegaartegen Analog vun Entry-Level Serveren, dee vun eis fir Iech erfonnt gouf: Déi ganz Wourecht iwwer VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps vun $19 oder wéi een e Server deelt? (verfügbar mat RAID1 an RAID10, bis zu 24 Kären a bis zu 40GB DDR4).

Dell R730xd 2 Mol méi bëlleg an Equinix Tier IV Daten Zentrum zu Amsterdam? Nëmmen hei 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV vun $199 an Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vun $99! Liest iwwer Wéi bauen ech Infrastructure Corp. Klass mat der Benotzung vun Dell R730xd E5-2650 v4 Serveren Wäert 9000 Euro fir e Penny?

Source: will.com

Setzt e Commentaire