La sekva HighLoad++-konferenco okazos la 6-an kaj 7-an de aprilo 2020 en Sankt-Peterburgo.
Detaloj kaj biletoj . HighLoad++ Siberio 2019. Salono "Krasnojarsk". 25 junio, 12:00. Tezoj kaj .
Okazas, ke praktikaj postuloj konfliktas kun teorio, kie aspektoj gravaj por komerca produkto ne estas konsiderataj. Ĉi tiu prelego prezentas procezon por elekti kaj kombini malsamajn alirojn al kreado de Kaŭzaj konsistenckomponentoj bazitaj sur akademia esplorado bazita sur la postuloj de komerca produkto. Aŭskultantoj lernos pri ekzistantaj teoriaj aliroj al logikaj horloĝoj, dependecspurado, sistema sekureco, horloĝsinkronado, kaj kial MongoDB decidis por certaj solvoj.
Miĥail Tyulenev (ĉi-poste nomata MT): – Mi parolos pri Kaŭza konsistenco - ĉi tio estas trajto pri kiu ni laboris en MongoDB. Mi laboras en grupo de distribuitaj sistemoj, ni faris ĝin antaŭ proksimume du jaroj.
En la procezo, mi devis alkutimigi min kun multe da akademia esplorado, ĉar ĉi tiu funkcio estis sufiĉe bone studita. Montriĝis, ke eĉ ne unu artikolo konvenas al tio, kio estas postulata en produktada datumbazo pro tre specifaj postuloj, kiuj verŝajne ĉeestas en iu ajn produktada aplikaĵo.
Mi parolos pri kiel ni, kiel konsumantoj de akademia Esploro, preparas ion el ĝi, kiun ni tiam povas prezenti al niaj uzantoj kiel pretan pladon, kiu estas oportuna kaj sekura uzi.
Kaŭza konsistenco. Ni difinu la konceptojn
Komence, mi volas diri ĝenerale, kio estas Kaŭza konsistenco. Estas du karakteroj - Leonard kaj Penny (televido-serio "The Big Bang Theory"):
Ni diru, ke Penny estas en Eŭropo kaj Leonard volas organizi al ŝi surprizfeston. Kaj li ne povas pensi pri io pli bona ol forĵeti ŝin de sia amiklisto, sendante al ĉiuj siaj amikoj ĝisdatigon pri nutrado: "Ni feliĉigu Penny!" (ŝi estas en Eŭropo, dum ŝi dormas, ŝi ne vidas ĉion ĉi kaj ne povas vidi ĝin, ĉar ŝi ne estas tie). Finfine, ŝi forigas ĉi tiun afiŝon, forigas ĝin de la Fluo kaj restarigas aliron por ke ŝi ne rimarku ion ajn kaj ne estu skandalo.
Ĉi tio ĉio estas bona kaj bona, sed ni supozu, ke la sistemo estas distribuita kaj aferoj iom misfunkciis. Povas, ekzemple, okazi, ke la alirlimigo de Penny okazis post kiam ĉi tiu afiŝo aperis, se la eventoj ne rilatas laŭ kaŭzo kaj efiko. Efektive, ĉi tio estas ekzemplo de kiam Kaŭza konsistenco estas postulata por plenumi komercan funkcion (en ĉi tiu kazo).
Fakte, ĉi tiuj estas tute ne-trivialaj trajtoj de la datumbazo - tre malmultaj homoj subtenas ilin. Ni transiru al la modeloj.
Konsekvencaj Modeloj
Kio ĝuste estas konsekvenca modelo en datumbazoj? Ĉi tiuj estas kelkaj el la garantioj, kiujn distribua sistemo donas pri kiaj datumoj la kliento povas ricevi kaj en kiu sinsekvo.
Principe, ĉiuj konsekvencaj modeloj dependas de kiom simila distribuata sistemo estas al sistemo, kiu funkcias, ekzemple, sur unu nodo sur tekkomputilo. Kaj jen kiom similas sistemo, kiu funkcias per miloj da geodistribuitaj "Nodoj", al tekkomputilo, en kiu ĉiuj ĉi tiuj proprietoj principe plenumas aŭtomate.
Tial, konsekvencaj modeloj estas aplikataj nur al distribuitaj sistemoj. Ĉiuj sistemoj, kiuj antaŭe ekzistis kaj funkciis ĉe la sama vertikala skalo, ne spertis tiajn problemojn. Estis unu Buffer Cache, kaj ĉio estis ĉiam legita el ĝi.
Modelo Forta
Efektive, la plej unua modelo estas Forta (aŭ la altkapablo-linio, kiel ĝi estas ofte nomata). Ĉi tio estas konsekvenca modelo, kiu certigas, ke ĉiu ŝanĝo, unufoje konfirmita, ke ĝi okazis, estas videbla por ĉiuj uzantoj de la sistemo.
Ĉi tio kreas tutmondan ordon de ĉiuj eventoj en la datumbazo. Ĉi tio estas tre forta konsekvenca posedaĵo, kaj ĝi estas ĝenerale tre multekosta. Tamen ĝi estas tre bone subtenata. Ĝi estas nur tre multekosta kaj malrapida - ĝi estas nur malofte uzata. Ĉi tio nomiĝas altiĝokapablo.
Ekzistas alia, pli forta posedaĵo kiu estas subtenata en Spanner - nomita Ekstera Konsistenco. Ni parolos pri ĝi iom poste.
Kaŭzo
La sekva estas Kaŭza, kio estas ĝuste pri kio mi parolis. Estas pluraj pliaj subniveloj inter Forta kaj Kaŭza, pri kiuj mi ne parolos, sed ili ĉiuj resumiĝas al Kaŭza. Ĉi tio estas grava modelo ĉar ĝi estas la plej forta el ĉiuj modeloj, la plej forta konsistenco en la ĉeesto de reto aŭ sekcioj.
Kaŭzoj estas fakte situacio en kiu eventoj estas ligitaj per kaŭzo-efekta rilato. Tre ofte ili estas perceptitaj kiel Legu viajn rajtojn el la vidpunkto de la kliento. Se la kliento observis iujn valorojn, li ne povas vidi valorojn, kiuj estis en la pasinteco. Li jam komencas vidi prefiksajn legaĵojn. Ĉio venas al la sama afero.
Kaŭzoj kiel konsekvenca modelo estas parta ordigo de okazaĵoj sur la servilo, en kiu okazaĵoj de ĉiuj klientoj estas observitaj en la sama sinsekvo. En ĉi tiu kazo, Leonard kaj Penny.
Eventuale
La tria modelo estas Eventual Consistency. Jen kion absolute ĉiuj distribuitaj sistemoj subtenas, la minimuma modelo, kiu entute havas sencon. Ĝi signifas la jenon: kiam ni havas iujn ŝanĝojn en la datumoj, iam ili fariĝas konsekvencaj.
En tia momento ŝi nenion diras, alie ŝi transformus en Eksteran Konsistencon — estus tute alia historio. Tamen ĉi tio estas tre populara modelo, la plej ofta. Defaŭlte, ĉiuj uzantoj de distribuitaj sistemoj uzas Eventual Consistency.
Mi volas doni kelkajn komparajn ekzemplojn:
Kion signifas ĉi tiuj sagoj?
- Latenteco. Ĉar la konsistencforto pliiĝas, ĝi iĝas pli granda pro evidentaj kialoj: vi devas fari pli da rekordoj, ricevi konfirmon de ĉiuj gastigantoj kaj nodoj kiuj partoprenas en la areto, ke la datumoj jam estas tie. Sekve, Eventual Consistency havas la plej rapidan respondon, ĉar tie, kiel regulo, oni eĉ povas memorigi ĝin kaj ĉi tio principe sufiĉos.
- Havebleco. Se ni komprenas tion kiel la kapablon de la sistemo respondi en la ĉeesto de retaj rompoj, sekcioj aŭ ia misfunkciado, misfunkciadotoleremo pliiĝas dum la konsistenca modelo malpliiĝas, ĉar sufiĉas por ni, ke unu gastiganto vivas kaj samtempe. tempo produktas iujn datumojn. Eventual Consistency tute ne garantias ion pri la datumoj - ĝi povas esti io ajn.
- Anomalioj. Samtempe, kompreneble, la nombro da anomalioj pliiĝas. En Forta Konsistenco ili preskaŭ tute ne devus ekzisti, sed en Eventual Consistency ili povas esti io ajn. Estiĝas la demando: kial homoj elektas Eventual Consistency se ĝi enhavas anomaliojn? La respondo estas ke Eventual Consistency-modeloj estas aplikeblaj kaj anomalioj ekzistas, ekzemple, en mallonga tempodaŭro; eblas uzi la sorĉiston por legi kaj pli-malpli legi konsekvencajn datumojn; Ofte eblas uzi fortajn konsekvencajn modelojn. En praktiko tio funkcias, kaj ofte la nombro da anomalioj estas limigita en tempo.
CAP-teoremo
Kiam vi vidas la vortojn konsistenco, havebleco - kio venas al via menso? Ĝuste - ĈAP-teoremo! Nun mi volas dispeli la miton... Ne estas mi - estas Martin Kleppmann, kiu verkis mirindan artikolon, mirindan libron.
La CAP-teoremo estas principo formulita en la 2000-aj jaroj, ke Konsistenco, Havebleco, Dispartigoj: prenu iujn ajn du, kaj vi ne povas elekti tri. Ĝi estis certa principo. Ĝi estis pruvita kiel teoremo kelkajn jarojn poste fare de Gilbert kaj Lynch. Tiam ĉi tio komencis esti uzata kiel mantro - sistemoj komencis esti dividitaj en CA, CP, AP ktp.
Tiu ĉi teoremo estis efektive pruvita por la sekvaj kazoj... Unue, Havebleco estis konsiderata ne kiel kontinua valoro de nulo ĝis centoj (0 - la sistemo estas "mortinta", 100 - respondas rapide; ni kutimas konsideri ĝin tiel) , sed kiel posedaĵo de la algoritmo , kiu garantias ke por ĉiuj ĝiaj ekzekutoj ĝi resendas datumojn.
Pri responda tempo tute ne estas vorto! Estas algoritmo, kiu resendas datumojn post 100 jaroj - absolute mirinda disponebla algoritmo, kiu estas parto de la CAP-teoremo.
Due: la teoremo estis pruvita por ŝanĝoj en la valoroj de la sama ŝlosilo, malgraŭ la fakto, ke ĉi tiuj ŝanĝoj estas regrandeblaj. Ĉi tio signifas, ke ili fakte ne estas uzataj, ĉar la modeloj estas malsamaj Eventual Consistency, Strong Consistency (eble).
Por kio estas ĉio ĉi? Krome, la CAP-teoremo en precize la formo en kiu ĝi estis pruvita estas praktike ne aplikebla kaj malofte estas uzata. En teoria formo, ĝi iel limigas ĉion. Rezultas certa principo, kiu intuicie ĝusta, sed ĝenerale ne estis pruvita.
Kaŭza konsistenco estas la plej forta modelo
Kio okazas nun estas ke vi povas akiri ĉiujn tri aferojn: Konsekvenco, Havebleco uzante Dispartigojn. Aparte, Kaŭza konsistenco estas la plej forta konsekvenca modelo, kiu ankoraŭ funkcias en ĉeesto de Dispartigoj (rompoj en la reto). Tial ĝi estas de tiom granda intereso, kaj tial ni prenis ĝin.
Unue, ĝi simpligas la laboron de programistoj de aplikaĵoj. Aparte, la ĉeesto de granda subteno de la servilo: kiam ĉiuj rekordoj kiuj okazas ene de unu kliento estas garantiita alveni en la sama sekvenco sur alia kliento. Due, ĝi eltenas sekciojn.
MongoDB Interna Kuirejo
Memorante, ke estas tagmanĝo, ni moviĝas al la kuirejo. Mi rakontos al vi pri la sistema modelo, nome, kio estas MongoDB por tiuj, kiuj aŭdas pri tia datumbazo unuafoje.
MongoDB (ĉi-poste nomata "MongoDB") estas distribuita sistemo, kiu subtenas horizontalan skalon, tio estas, sharding; kaj ene de ĉiu shard ĝi ankaŭ subtenas datuman redundon, tio estas, reproduktadon.
Sharding en MongoDB (ne rilata datumbazo) faras aŭtomatan ekvilibron, tio estas, ĉiu kolekto de dokumentoj (aŭ "tabelo" laŭ interrilataj datumoj) estas dividita en pecojn, kaj la servilo aŭtomate movas ilin inter pecetoj.
La Demanda Enkursigilo, kiu distribuas petojn, por kliento estas iu kliento per kiu ĝi funkcias. Ĝi jam scias kie kaj kiaj datumoj troviĝas kaj direktas ĉiujn petojn al la ĝusta peceto.
Alia grava punkto: MongoDB estas ununura majstro. Estas unu Primara - ĝi povas preni rekordojn kiuj subtenas la ŝlosilojn kiujn ĝi enhavas. Vi ne povas fari plur-majstran skribadon.
Ni faris eldonon 4.2 - novaj interesaj aferoj aperis tie. Precipe oni enmetis Lucene - serĉon - nome efektivigeblan java rekte en Mongo, kaj tie eblis fari serĉojn per Lucene, same kiel en Elastica.
Kaj ili faris novan produkton - Charts, ĝi ankaŭ haveblas ĉe Atlas (la propra Nubo de Mongo). Ili havas Senpagan Nivelon - vi povas ludi kun ĝi. Mi tre ŝatis Charts - datuma bildigo, tre intuicia.
Ingrediencoj Kaŭza konsistenco
Mi nombris ĉirkaŭ 230 artikolojn kiuj estis publikigitaj pri tiu ĉi temo - de Leslie Lampert. Nun el mia memoro mi transdonos al vi kelkajn partojn de tiuj ĉi materialoj.
Ĉio komenciĝis per artikolo de Leslie Lampert, kiu estis verkita en la 1970-aj jaroj. Kiel vi povas vidi, iuj esploroj pri ĉi tiu temo ankoraŭ daŭras. Nun Kaŭza konsistenco spertas intereson lige kun la disvolviĝo de distribuitaj sistemoj.
Restriktoj
Kiuj limigoj estas? Ĉi tio efektive estas unu el la ĉefaj punktoj, ĉar la limigoj, kiujn produktadsistemo trudas, estas tre malsamaj de la limigoj, kiuj ekzistas en akademiaj artikoloj. Ili ofte estas sufiĉe artefaritaj.
- Unue, "MongoDB" estas ununura majstro, kiel mi jam diris (ĉi tio multe simpligas).
- Ni kredas, ke la sistemo devus subteni ĉirkaŭ 10 mil pecetojn. Ni ne povas fari iujn ajn arkitekturajn decidojn, kiuj eksplicite limigos ĉi tiun valoron.
- Ni havas nubon, sed ni supozas, ke persono ankoraŭ havu la ŝancon kiam li elŝutas binaron, rulas ĝin sur sia tekkomputilo, kaj ĉio funkcias bonege.
- Ni supozas ion, kion Esplorado malofte supozas: eksteraj klientoj povas fari kion ajn ili volas. MongoDB estas malferma fonto. Sekve, klientoj povas esti tiel inteligentaj kaj koleraj - ili povas voli rompi ĉion. Ni konjektas ke bizancaj Feilors povas origini.
- Por eksteraj klientoj kiuj estas ekster la perimetro, ekzistas grava limigo: se ĉi tiu funkcio estas malŝaltita, tiam neniu rendimento-degradado devas esti observita.
- Alia punkto estas ĝenerale kontraŭakademia: la kongruo de antaŭaj versioj kaj estontaj. Malnovaj ŝoforoj devas subteni novajn ĝisdatigojn, kaj la datumbazo devas subteni malnovajn ŝoforojn.
Ĝenerale, ĉio ĉi trudas limigojn.
Kaŭzaj konsekvencaj komponantoj
Mi nun parolos pri iuj el la komponantoj. Se ni konsideras Kaŭzan konsistencon ĝenerale, ni povas elekti blokojn. Ni elektis el verkoj kiuj apartenas al certa bloko: Dependeco-Spurado, elektado de horloĝoj, kiel ĉi tiuj horloĝoj povas esti sinkronigitaj unu kun la alia, kaj kiel ni garantias sekurecon - jen malglata skizo de tio, pri kio mi parolos:
Plena Dependeco-Spurado
Kial ĝi estas bezonata? Tiel ke kiam datumoj estas reproduktitaj, ĉiu rekordo, ĉiu datumŝanĝo enhavas informojn pri kiaj ŝanĝoj ĝi dependas. La unua kaj naiva ŝanĝo estas kiam ĉiu mesaĝo kiu enhavas rekordon enhavas informojn pri antaŭaj mesaĝoj:
En ĉi tiu ekzemplo, la nombro en krampoj estas la rekordaj nombroj. Kelkfoje ĉi tiuj rekordoj kun valoroj eĉ estas transdonitaj en sia tutaĵo, foje iuj versioj estas translokigitaj. La fundo estas, ke ĉiu ŝanĝo enhavas informojn pri la antaŭa (evidente portas ĉion ĉi en si).
Kial ni decidis ne uzi ĉi tiun aliron (plena spurado)? Evidente, ĉar ĉi tiu aliro estas nepraktika: ĉiu ŝanĝo al socia reto dependas de ĉiuj antaŭaj ŝanĝoj al tiu socia reto, transdonante, ekzemple, Facebook aŭ VKontakte en ĉiu ĝisdatigo. Tamen, estas multe da esplorado pri Plena Dependa Spurado - ĉi tiuj estas antaŭsociaj retoj; por iuj situacioj ĝi vere funkcias.
Eksplicita Dependeco-Spurado
La sekva estas pli limigita. La transdono de informoj ankaŭ estas konsiderata ĉi tie, sed nur tio, kio estas klare dependa. Kio dependas de kio, kiel regulo, estas determinita de la Apliko. Kiam datumoj estas reproduktitaj, la demando nur resendas respondojn kiam antaŭaj dependecoj estis kontentigitaj, tio estas, montritaj. Ĉi tio estas la esenco de kiel funkcias Kaŭza konsistenco.
Ŝi vidas, ke rekordo 5 dependas de rekordoj 1, 2, 3, 4 - sekve, ŝi atendas antaŭ ol la kliento havas aliron al la ŝanĝoj faritaj per la alirdecido de Penny, kiam ĉiuj antaŭaj ŝanĝoj jam trapasis la datumbazon.
Ankaŭ ĉi tio ne konvenas al ni, ĉar ankoraŭ estas tro da informoj, kaj ĝi malrapidigos la aferojn. Estas alia aliro...
Lampport Horloĝo
Ili estas tre maljunaj. Lamport Clock signifas ke ĉi tiuj dependecoj estas falditaj en skalaran funkcion, kiu estas nomita Lamport Clock.
Skala funkcio estas iu abstrakta nombro. Ĝi estas ofte nomata logika tempo. Kun ĉiu evento, ĉi tiu nombrilo pliiĝas. Nombrilo, kiu estas nuntempe konata al la procezo, sendas ĉiun mesaĝon. Estas klare, ke procezoj povas esti malsinkronigitaj, ili povas havi tute malsamajn tempojn. Tamen, la sistemo iel ekvilibrigas la horloĝon kun tia mesaĝado. Kio okazas en ĉi tiu kazo?
Mi disigis tiun grandan peceton en du por klarigi ĝin: Amikoj povas vivi en unu nodo, kiu enhavas pecon de la kolekto, kaj Feed povas vivi en alia nodo, kiu enhavas pecon de ĉi tiu kolekto. Ĉu estas klare kiel ili povas eliri el vico? Unua Fluo diros: "Replikita", kaj poste Amikoj. Se la sistemo ne provizas ian garantion, ke la Fluo ne estos montrita ĝis la Amikoj-dependoj en la kolekto de Amikoj ankaŭ estos liveritaj, tiam ni havos ĝuste la situacion, kiun mi menciis.
Vi vidas kiel la nombrilo en Feed logike pliiĝas:
Do la ĉefa eco de ĉi tiu Lamport-Holoĝo kaj Kaŭza konsistenco (klarigita per Lamport-Holoĝo) estas jena: se ni havas Eventojn A kaj B, kaj Evento B dependas de Event A*, tiam sekvas, ke la LogicalTime de Event A estas malpli ol ol. LogicalTime de Evento B.
* Iafoje oni diras ankaŭ, ke A okazis antaŭ B, tio estas, A okazis antaŭ B - tio estas certa rilato, kiu parte ordigas la tutan aron de okazintaj ĝenerale.
La malo estas malĝusta. Ĉi tio estas fakte unu el la ĉefaj malavantaĝoj de Lamport Clock - parta ordo. Estas koncepto pri samtempaj eventoj, tio estas, eventoj en kiuj nek (A okazis antaŭ B) nek (A okazis antaŭ B). Ekzemplo estus la paralela aldono de Leonard de iu alia kiel amiko (eĉ ne Leonard, sed Sheldon, ekzemple).
Ĉi tiu estas la posedaĵo, kiu estas ofte uzata kiam oni laboras kun Lamport-horloĝoj: ili rigardas specife la funkcion kaj el tio ili konkludas, ke eble tiuj eventoj estas dependaj. Ĉar unu maniero estas vera: se LogicalTime A estas malpli ol LogicalTime B, tiam B ne povas okazi antaŭ A; kaj se pli, tiam eble.
Vektora Horloĝo
La logika evoluo de la Lamport-horloĝo estas la Vektora Horloĝo. Ili malsamas en tio, ke ĉiu nodo kiu estas ĉi tie enhavas sian propran apartan horloĝon, kaj ili estas elsenditaj kiel vektoro.
En ĉi tiu kazo, vi vidas, ke la nula indekso de la vektoro respondecas pri Feed, kaj la unua indekso de la vektoro estas por Amikoj (ĉiu el ĉi tiuj nodoj). Kaj nun ili pliiĝos: la nula indekso de "Feed" pliiĝas skribante - 1, 2, 3:
Kial Vektora Horloĝo estas pli bona? Ĉar ili permesas vin eltrovi, kiuj eventoj estas samtempaj kaj kiam ili okazas sur malsamaj nodoj. Ĉi tio estas tre grava por sharding-sistemo kiel MongoDB. Tamen, ni ne elektis ĉi tion, kvankam ĝi estas mirinda afero, kaj ĝi funkcias bonege, kaj ĝi verŝajne konvenus al ni...
Se ni havas 10 mil pecetojn, ni ne povas transdoni 10 mil komponantojn, eĉ se ni kunpremas ĝin aŭ elpensas ion alian - la utila ŝarĝo ankoraŭ estos plurajn fojojn pli malgranda ol la volumeno de ĉi tiu tuta vektoro. Tial, kunpreminte niajn korojn kaj dentojn, ni forlasis ĉi tiun aliron kaj transiris al alia.
Ŝlosilo TrueTime. Atoma horloĝo
Mi diris, ke estos rakonto pri Spanner. Ĉi tio estas bonega afero, rekte el la XNUMX-a jarcento: atomhorloĝoj, GPS-sinkronigo.
Kio estas la ideo? "Spanner" estas Guglo-sistemo, kiu lastatempe eĉ fariĝis disponebla por homoj (ili aldonis SQL al ĝi). Ĉiu transakcio tie havas iom da tempomarko. Ĉar la tempo estas sinkronigita*, al ĉiu evento oni povas asigni specifan tempon - atomaj horloĝoj havas atendan tempon, post kiu malsama tempo estas garantiita "okazi".
Tiel, simple skribante al la datumbazo kaj atendante iom da tempo, la Seriigigeblo de la evento estas aŭtomate garantiita. Ili havas la plej fortan Konsekvencan modelon, kiun oni povas principe imagi - ĝi estas Ekstera Konsistenco.
* Ĉi tio estas la ĉefa problemo pri Lampart-horloĝoj - ili neniam estas sinkronaj ĉe distribuitaj sistemoj. Ili povas diverĝi; eĉ kun NTP, ili ankoraŭ ne funkcias tre bone. "Spanner" havas atoman horloĝon kaj sinkronigado, ŝajnas, estas mikrosekundoj.
Kial ni ne elektis? Ni ne supozas, ke niaj uzantoj havas enkonstruitan atoman horloĝon. Kiam ili aperos, enkonstruitaj en ĉiu tekokomputilo, estos ia bonega sinkronigado de GPS - tiam jes... Sed nuntempe la plej bona kiu eblas estas Amazon, Bazstacioj - por fanatikuloj... Do ni uzis aliajn horloĝojn. .
Hibrida Horloĝo
Ĉi tio efektive estas kio tiktas en MongoDB kiam certigas Kaŭzan konsistencon. Kiel ili estas hibridaj? Hibrido estas skalara valoro, sed ĝi havas du komponentojn:
- La unua estas la epoko de Unikso (kiom da sekundoj pasis ekde la "komenco de la komputila mondo").
- La dua estas iu pliigo, ankaŭ 32-bita sensigna int.
Tio estas ĉio, fakte. Estas ĉi tiu aliro: la parto kiu respondecas pri tempo estas sinkronigita kun la horloĝo la tutan tempon; ĉiufoje kiam okazas ĝisdatigo, ĉi tiu parto estas sinkronigita kun la horloĝo kaj rezultas, ke la tempo ĉiam estas pli-malpli ĝusta, kaj pliigo permesas distingi inter eventoj okazintaj en la sama momento.
Kial ĉi tio estas grava por MongoDB? Ĉar ĝi permesas al vi fari ian rezervajn restoraciojn en certa tempo, tio estas, la evento estas indeksita laŭ tempo. Ĉi tio estas grava kiam certaj eventoj estas bezonataj; Por datumbazo, okazaĵoj estas ŝanĝoj en la datumbazo kiuj okazis je certaj intervaloj en tempo.
Mi diros al vi la plej gravan kialon nur al vi (bonvolu, diru al neniu)! Ni faris tion ĉar tiel aspektas organizitaj, indeksitaj datumoj en MongoDB OpLog. OpLog estas datumstrukturo kiu enhavas absolute ĉiujn ŝanĝojn en la datumbazo: ili unue iras al OpLog, kaj poste ili estas aplikataj al Stokado mem en la kazo kiam ĝi estas reproduktita dato aŭ fragmento.
Ĉi tio estis la ĉefa kialo. Tamen, ekzistas ankaŭ praktikaj postuloj por disvolvi datumbazon, kio signifas, ke ĝi estu simpla - malmulte da kodo, kiel eble plej malmultaj rompitaj aferoj, kiuj devas esti reverkitaj kaj provitaj. La fakto, ke niaj oplogs estis indeksitaj per hibridaj horloĝoj multe helpis kaj permesis al ni fari la ĝustan elekton. Ĝi vere pagis kaj iel magie funkciis sur la plej unua prototipo. Ĝi estis tre mojosa!
Sinkronigado de horloĝo
Ekzistas pluraj sinkronigaj metodoj priskribitaj en la scienca literaturo. Mi parolas pri sinkronigo, kiam ni havas du malsamajn pecetojn. Se ekzistas unu kopiaro, ne necesas ia sinkronigo: ĉi tio estas "ununura majstro"; ni havas OpLog, en kiu falas ĉiuj ŝanĝoj - ĉi-kaze ĉio jam estas sinsekve ordigita en la "Oplog" mem. Sed se ni havas du malsamajn pecetojn, temposinkronigado estas grava ĉi tie. Jen kie la vektora horloĝo pli helpis! Sed ni ne havas ilin.
La dua taŭgas - ĉi tio estas "Korbatoj". Eblas interŝanĝi iujn signalojn, kiuj okazas ĉiun unuon de tempo. Sed Korbatoj estas tro malrapidaj, ni ne povas doni latentecon al nia kliento.
Vera tempo estas, kompreneble, mirinda afero. Sed, denove, ĉi tio verŝajne estas la estonteco... Kvankam ĝi jam povas esti farita en Atlaso, jam ekzistas rapidaj "Amazonaj" temposinkroniloj. Sed ĝi ne estos disponebla por ĉiuj.
Klaĉado estas kiam ĉiuj mesaĝoj inkluzivas tempon. Ĉi tio estas proksimume kion ni uzas. Ĉiu mesaĝo inter nodoj, ŝoforo, datumnoda enkursigilo, absolute ĉio por MongoDB estas ia elemento, datumbaza komponanto, kiu enhavas horloĝon, kiu funkcias. Ili havas la signifon de hibrida tempo ĉie, ĝi estas transdonita. 64 bitoj? Ĉi tio permesas, ĉi tio eblas.
Kiel ĉio funkcias kune?
Ĉi tie mi rigardas unu kopion por fari ĝin iomete pli facila. Estas Primaraj kaj Sekundaraj. Sekundara faras reproduktadon kaj ne ĉiam estas tute sinkronigita kun Primara.
Enmeto okazas en la "Primary" kun certa tempovaloro. Ĉi tiu enigaĵo pliigas la internan kalkulon je 11, se ĉi tio estas la maksimumo. Aŭ ĝi kontrolos la horloĝajn valorojn kaj sinkronigos al la horloĝo se la horloĝaj valoroj estas pli grandaj. Ĉi tio permesas vin organizi laŭ tempo.
Post kiam li faras la registradon, okazas grava momento. La horloĝo estas en "MongoDB" kaj estas pliigita nur en kazo de skribado al "Oplog". Ĉi tiu estas la evento, kiu ŝanĝas la staton de la sistemo. En absolute ĉiuj klasikaj artikoloj, evento estas konsiderata kiam mesaĝo trafas nodon: la mesaĝo alvenis, kio signifas, ke la sistemo ŝanĝis sian staton.
Ĉi tio estas pro la fakto, ke dum esplorado ne estas tute klare kiel ĉi tiu mesaĝo estos interpretita. Ni scias certe, ke se ĝi ne estas reflektita en la "Oplog", tiam ĝi ne estos interpretita neniel, kaj ŝanĝo en la stato de la sistemo estas nur eniro en la "Oplog". Ĉi tio simpligas ĉion por ni: la modelo simpligas ĝin, kaj permesas al ni organizi ĝin ene de unu kopiaro, kaj multaj aliaj utilaj aferoj.
La valoro kiu estas jam skribita al la "Oplog" estas resendita - ni scias ke la "Oplog" jam enhavas ĉi tiun valoron, kaj ĝia tempo estas 12. Nun, ekzemple, legado komenciĝas de alia nodo (Sekundara), kaj ĝi transdonas post ClusterTime en la mesaĝo. Li diras: "Mi bezonas ĉion, kio okazis almenaŭ post 12 aŭ dum dek du" (vidu bildon supre).
Ĉi tio estas nomata Kaŭza konsekvenca (CAT). Estas tia koncepto en teorio, ke ĉi tio estas iom da tempo, kiu estas konsekvenca en si mem. En ĉi tiu kazo, ni povas diri, ke ĉi tiu estas la stato de la sistemo, kiu estis observita en la tempo 12.
Nun ankoraŭ estas nenio ĉi tie, ĉar ĉi tiu speco de simulas la situacion kiam vi bezonas la Malĉefajn por reprodukti datumojn de la Primara. Li atendas... Kaj nun la datumoj alvenis - li redonas ĉi tiujn valorojn.
Preskaŭ tiel ĉio funkcias. Preskaŭ.
Kion signifas "preskaŭ"? Ni supozu, ke ekzistas iu homo, kiu legis kaj komprenis kiel ĉi tio ĉio funkcias. Mi rimarkis, ke ĉiufoje kiam ClusterTime okazas, ĝi ĝisdatigas la internan logikan horloĝon, kaj tiam la sekva eniro pliiĝas je unu. Ĉi tiu funkcio prenas 20 liniojn. Ni diru, ke ĉi tiu persono transdonas la plej grandan 64-bitan nombron, minus unu.
Kial "minus unu"? Ĉar la interna horloĝo estos anstataŭigita en ĉi tiun valoron (evidente, ĉi tio estas la plej granda ebla kaj pli granda ol la nuna tempo), tiam enskribo okazos en "Oplog", kaj la horloĝo estos pliigita per alia unuo - kaj jam estos estu maksimuma valoro (estas simple ĉiuj unuoj, nenie alie iri) , unsaint ints).
Estas klare, ke post tio la sistemo fariĝas absolute neatingebla por io ajn. Ĝi povas esti nur malŝarĝita kaj purigita - multe da manlaboro. Plena havebleco:
Krome, se ĉi tio estas reproduktita aliloke, tiam la tuta areto simple falas. Situacio absolute neakceptebla, kiun ĉiu povas organizi tre rapide kaj facile! Tial ni konsideris ĉi tiun momenton kiel unu el la plej gravaj. Kiel malhelpi ĝin?
Nia maniero estas subskribi clusterTime
Tiel ĝi estas transdonita en la mesaĝo (antaŭ la blua teksto). Sed ni ankaŭ komencis generi subskribon (blua teksto):
La subskribo estas generita per ŝlosilo kiu estas konservita ene de la datumbazo, ene de sekura perimetro; mem estas generita kaj ĝisdatigita (uzantoj vidas nenion pri ĝi). Hash estas generita, kaj ĉiu mesaĝo estas subskribita kiam kreita kaj validigita kiam ricevita.
La demando probable ŝprucas en la mensoj de homoj: "Kiom tio malrapidigas aferojn?" Mi diris al vi, ke ĝi devus funkcii rapide, precipe en la foresto de ĉi tiu funkcio.
Kion signifas uzi Kaŭzan konsistencon en ĉi tiu kazo? Ĉi tio estas por montri la parametron afterClusterTime. Sen ĉi tio, ĝi ĉiuokaze simple transdonos valorojn. Klaĉado, ekde versio 3.6, ĉiam funkcias.
Se ni forlasas la konstantan generacion de subskriboj, ĝi malrapidigos la sistemon eĉ en foresto de trajto, kiu ne plenumas niajn alirojn kaj postulojn. Kion do ni faris?
Faru ĝin rapide!
Ĝi estas sufiĉe simpla afero, sed la lertaĵo estas interesa - mi dividos ĝin, eble iu interesiĝos.
Ni havas hash kiu stokas la subskribitajn datumojn. Ĉiuj datumoj trairas la kaŝmemoron. La kaŝmemoro ne subskribas la specifan tempon, sed la Gamon. Kiam iu valoro alvenas, ni generas Gamon, maskas la lastajn 16 bitojn, kaj ni subskribas ĉi tiun valoron:
Ricevante tian subskribon, ni rapidigas la sistemon (relative) 65 mil fojojn. Ĝi funkcias bonege: kiam ni faris eksperimentojn, la tempo efektive malpliiĝis je 10 mil fojojn kiam ni havis sinsekvan ĝisdatigon. Estas klare, ke kiam ili estas en konflikto, ĉi tio ne funkcias. Sed en la plej multaj praktikaj kazoj ĝi funkcias. La kombinaĵo de la Range-signaturo kune kun la subskribo solvis la sekurecproblemon.
Kion ni lernis?
Lecionoj ni lernis el ĉi tio:
- Ni bezonas legi materialojn, rakontojn, artikolojn, ĉar ni havas multajn interesajn aferojn. Kiam ni laboras pri iu funkcio (precipe nun, kiam ni faris transakciojn, ktp.), ni devas legi kaj kompreni. Ĝi bezonas tempon, sed ĝi efektive estas tre utila ĉar ĝi klarigas kie ni estas. Ni ne ŝajnis elpensi ion novan - ni nur prenis la ingrediencojn.
Ĝenerale, estas certa diferenco en pensado kiam estas akademia konferenco (Sigmon, ekzemple) - ĉiuj koncentriĝas pri novaj ideoj. Kio estas nova pri nia algoritmo? Estas nenio aparte nova ĉi tie. La noveco prefere kuŝas en la maniero kiel ni miksis ekzistantajn alirojn kune. Sekve, la unua afero estas legi la klasikaĵojn, komencante per Lampart.
- En produktado, la postuloj estas tute malsamaj. Mi certas, ke multaj el vi ne alfrontas "sferajn" datumbazojn en abstrakta vakuo, sed kun normalaj, realaj aferoj, kiuj havas problemojn kun havebleco, latenteco kaj misfunkciado.
- La lasta afero estas, ke ni devis konsideri malsamajn ideojn kaj kombini plurajn tute malsamajn artikolojn en unu aliron, kune. La ideo pri subskribo, ekzemple, ĝenerale devenis el artikolo, kiu konsideris la protokolon Paxos, kiu por nebizancaj malsukcesuloj estas ene de la rajtiga protokolo, por bizancaj - ekster la rajtiga protokolo... Ĝenerale, ĝuste tio ni estas. finis farante.
Estas absolute nenio nova ĉi tie! Sed tuj kiam ni miksis ĉion... Same diri, ke la recepto de la salato Olivier estas sensencaĵo, ĉar ovoj, majonezo kaj kukumoj jam estas inventitaj... Temas pri la sama historio.
Mi finos kun ĉi tio. Dankon!
Viaj demandoj
Demando de la spektantaro (ĉi-poste nomata B): – Dankon, Miĥail, pro la raporto! La temo pri tempo estas interesa. Vi uzas Klaĉadon. Ili diris, ke ĉiu havas sian propran tempon, ĉiu scias sian lokan tempon. Laŭ mia kompreno, ni havas ŝoforon - povas esti multaj klientoj kun ŝoforoj, ankaŭ konsultplanistoj, ankaŭ fragmentoj... Kaj al kio la sistemo venas se ni subite havas diferencon: iu decidas, ke ĝi estas por iu. minuto anta, iu minuton malanta? Kie ni finos?
MT: – Vere bonega demando! Mi volis nur paroli pri pecetoj. Se mi ĝuste komprenas la demandon, ni havas la jenan situacion: estas peceto 1 kaj peceto 2, legado okazas el ĉi tiuj du pecetoj - ili havas diferencon, ili ne interagas unu kun la alia, ĉar la tempo, kiun ili konas, estas malsama, precipe la tempo, ke ili ekzistas en oplogs.
Ni diru, ke peceto 1 faris milionon da rekordoj, peceto 2 tute nenion faris, kaj la peto venis al du pecetoj. Kaj la unua havas postClusterTime de pli ol miliono. En tia situacio, kiel mi klarigis, shard 2 neniam respondos.
En: – Mi volis scii kiel ili sinkronigas kaj elektas unu logikan tempon?
MT: - Tre facile sinkronigi. Shard, kiam postClusterTime venas al li kaj li ne trovas tempon en la "Oplog", iniciatas neniun aprobita. Tio estas, li levas sian tempon per siaj manoj al ĉi tiu valoro. Ĉi tio signifas, ke ĝi ne havas eventojn kongruajn kun ĉi tiu peto. Li kreas ĉi tiun okazaĵon artefarite kaj tiel iĝas Causal Consistent.
En: – Kaj se post tio venos al li iuj aliaj eventoj, kiuj perdiĝis ie en la reto?
MT: – Shard estas desegnita tiel, ke ili ne revenos, ĉar ĝi estas ununura majstro. Se li jam aliĝis, tiam ili ne venos, sed venos poste. Ne povas okazi, ke io blokiĝas ie, tiam li ne skribas, kaj tiam ĉi tiuj eventoj alvenas - kaj la Kaŭza konsistenco rompiĝas. Kiam li ne skribas, ili ĉiuj devus veni poste (li atendos ilin).
En: – Mi havas plurajn demandojn pri la vicoj. Kaŭza konsistenco supozas ke ekzistas specifa atendovico de agoj kiuj devas esti faritaj. Kio okazas se unu el niaj pakaĵoj malaperas? Jen venas la 10-a, 11-a... la 12-a malaperis, kaj ĉiuj aliaj atendas, ke ĝi realiĝos. Kaj subite nia aŭto mortis, ni nenion povas fari. Ĉu ekzistas maksimuma longeco de la atendovico, kiu akumuliĝas antaŭ esti ekzekutita? Kia fatala fiasko okazas kiam iu ŝtato estas perdita? Cetere, se ni skribas, ke ekzistas ia antaŭa stato, tiam ni devus iel komenci de ĝi? Sed ili ne forpuŝis lin!
MT: – Ankaŭ bonega demando! Kion ni faras? MongoDB havas la koncepton de kvorumaj skriboj, kvorumaj legadoj. En kiuj kazoj mesaĝo povas esti perdita? Kiam skribo ne estas kvorumo aŭ kiam legado ne estas kvorumo (ankaŭ ia rubo povas algluiĝi).
Pri Kaŭza konsistenco, granda eksperimenta testo estis farita, kies rezulto estis, ke en la kazo, kiam skribas kaj legas estas nekvorumaj, okazas malobservoj de Kaŭza konsistenco. Ĝuste kion vi diras!
Nia konsilo: uzu almenaŭ kvoruman legadon kiam vi uzas Kaŭzan konsekvencon. Ĉi-kaze nenio perdiĝos, eĉ se la kvorumo-registro estas perdita... Ĉi tio estas orta situacio: se la uzanto ne volas, ke datumoj estu perditaj, li bezonas uzi kvoruman registron. Kaŭza konsistenco ne garantias fortikecon. Fortikeco estas garantiita per reproduktado kaj la maŝinaro asociita kun reproduktado.
En: – Kiam ni kreas ekzemplon, kiu plenumas sharding por ni (ne majstro, sed sklavo, respektive), ĝi dependas de la Unikso-tempo de sia propra maŝino aŭ de la tempo de la "mastro"; Ĉu ĝi sinkronigas unuafoje aŭ periode?
MT: – Mi klarigos nun. Breĉeto (t.e. horizontala vando) - ĉiam estas Primara tie. Kaj peceto povas havi "majstron" kaj povas ekzisti kopioj. Sed la peceto ĉiam subtenas registradon, ĉar ĝi devas subteni iun domajnon (la peceto havas Primaran).
En: – Do ĉio dependas pure de la “majstro”? Ĉu majstra tempo estas ĉiam uzata?
MT: - Jes. Vi povas figure diri: la horloĝo tiktakos kiam okazas eniro en la "majstro", en la "Oplog".
En: – Ĉu ni havas klienton, kiu konektas kaj ne bezonas scii ion pri la tempo?
MT: – Vi tute ne bezonas scii ion ajn! Se ni parolas pri kiel ĝi funkcias ĉe la kliento: kiam la kliento volas uzi Kaŭzan konsistencon, li devas malfermi sesion. Nun ĉio estas tie: transakcioj en la sesio, kaj rekuperi rajtojn... Sesio estas la ordigo de logikaj eventoj okazantaj kun la kliento.
Se li malfermas ĉi tiun sesion kaj diras tie, ke li volas Kaŭzan konsistencon (se la sesio subtenas Kaŭzan konsistencon defaŭlte), ĉio funkcias aŭtomate. La ŝoforo memoras ĉi tiun tempon kaj pliigas ĝin kiam ĝi ricevas novan mesaĝon. Ĝi memoras kian respondon la antaŭa revenis de la servilo kiu resendis la datumojn. La sekva peto enhavos afterCluster ("tempo pli granda ol ĉi").
La kliento ne bezonas scii absolute ion ajn! Ĉi tio estas tute maldiafana por li. Se homoj uzas ĉi tiujn funkciojn, kion ili povas fari? Unue, vi povas sekure legi sekundarojn: vi povas skribi al Primaraj kaj legi el geografie reproduktitaj sekundaroj kaj certigi ke ĝi funkcias. Samtempe, sesioj kiuj estis registritaj sur Primara eĉ povas esti translokigitaj al Sekundara, t.e. vi povas uzi ne unu sesion, sed plurajn.
En: - Nova tavolo de Komputika scienco - CRDT (Konflikt-liberaj Replikitaj Datumoj-Tipoj) datumtipoj - estas forte rilata al la temo de Eventuala konsistenco. Ĉu vi pripensis integri ĉi tiujn tipojn de datumoj en la datumbazon kaj kion vi povas diri pri ĝi?
MT: - Bona demando! CRDT havas sencon por skribkonfliktoj: en MongoDB, ununura majstro.
En: – Mi havas demandon de la devopoj. En la reala mondo, ekzistas tiaj jezuitaj situacioj kiam la Bizanca Fiasko okazas, kaj malbonaj homoj ene de la protektita perimetro komencas piki en la protokolon, sendi metiajn pakaĵojn en speciala maniero?
MT: – Malbonaj homoj ene de la perimetro estas kiel troja ĉevalo! Malbonaj homoj ene de la perimetro povas fari multajn malbonajn aferojn.
En: – Estas klare, ke lasante, proksimume, truon en la servilo, tra kiu vi povas meti zoon de elefantoj kaj disfali la tutan areton por ĉiam... Necesos tempo por mana reakiro... Ĉi tio, milde, estas malĝuste. Aliflanke, tio estas interesa: en la reala vivo, en la praktiko, estas situacioj, kiam nature similaj internaj atakoj okazas?
MT: – Ĉar mi malofte renkontas sekurecrompojn en la reala vivo, mi ne povas diri ĉu ili okazas. Sed se ni parolas pri la disvolva filozofio, ni pensas tiel: ni havas perimetron, kiu provizas la ulojn kiuj faras sekurecon - ĉi tio estas kastelo, muro; kaj ene de la perimetro vi povas fari kion ajn vi volas. Estas klare, ke ekzistas uzantoj kun la kapablo nur vidi, kaj estas uzantoj kun la kapablo forigi la dosierujon.
Depende de la rajtoj, la damaĝo kiun uzantoj povas fari povas esti muso, aŭ ĝi povas esti elefanto. Estas klare, ke uzanto kun plenaj rajtoj povas fari ion ajn. Uzanto kun limigitaj rajtoj povas kaŭzi signife malpli da damaĝo. Precipe ĝi ne povas rompi la sistemon.
En: – En la protektita perimetro iu provis krei neatenditajn protokolojn por la servilo por tute detrui la servilon, kaj se vi bonŝancas, la tutan areton... Ĉu ĝi iam ricevas tiun "bonon"?
MT: "Mi neniam aŭdis pri tiaj aferoj." La fakto, ke vi povas kraŝi servilon tiamaniere, ne estas sekreto. Malsukcesi interne, esti de la protokolo, esti rajtigita uzanto kiu povas skribi ion tian en la mesaĝo... Fakte, ĝi estas neebla, ĉar ĝi ankoraŭ estos kontrolita. Eblas malŝalti ĉi tiun aŭtentikigon por uzantoj, kiuj ne volas ĝin - do tio estas ilia problemo; ili, malglate, detruis mem la murojn kaj oni povas enpuŝi tien elefanton, kiu piedpremos... Sed ĝenerale oni povas vesti sin kiel riparisto, venu kaj eltiri ĝin!
En: – Dankon pro la raporto. Sergey (Yandex). Estas konstanto en Mong kiu limigas la nombron da voĉdonantaj membroj en la Replica Aro, kaj ĉi tiu konstanto estas 7 (sep). Kial ĉi tio estas konstanto? Kial ĉi tio ne estas ia parametro?
MT: – Ni havas Kopiajn Arojn kun 40 nodoj. Ĉiam estas plimulto. Mi ne scias, kiu versio...
En: – En Replica Set vi povas ruli nevoĉdonajn membrojn, sed estas maksimume 7 voĉdonantaj membroj.Kiel ni povas travivi la ĉesigon en ĉi tiu kazo se nia Replica Set estas disvastigita tra 3 datumcentroj? Unu datumcentro povas facile malŝalti, kaj alia maŝino povas elfali.
MT: – Ĉi tio jam iom preterpasas la amplekson de la raporto. Ĉi tio estas ĝenerala demando. Eble mi povos rakonti al vi pri tio poste.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com