Ang susunod na HighLoad++ conference ay gaganapin sa Abril 6 at 7, 2020 sa St. Petersburg.
Mga detalye at tiket . HighLoad++ Siberia 2019. Hall "Krasnoyarsk". Hunyo 25, 12:00. Mga tesis at .
Nangyayari na ang mga praktikal na kinakailangan ay sumasalungat sa teorya, kung saan ang mga aspeto na mahalaga para sa isang komersyal na produkto ay hindi isinasaalang-alang. Ang pahayag na ito ay nagpapakita ng isang proseso para sa pagpili at pagsasama-sama ng iba't ibang mga diskarte sa paglikha ng Causal consistency component batay sa akademikong pananaliksik batay sa mga kinakailangan ng isang komersyal na produkto. Matututunan ng mga tagapakinig ang tungkol sa mga umiiral nang teoretikal na diskarte sa mga lohikal na orasan, pagsubaybay sa dependency, seguridad ng system, pag-synchronize ng orasan, at kung bakit nakipag-ayos ang MongoDB sa ilang partikular na solusyon.
Mikhail Tyulenev (mula rito ay tinutukoy bilang MT): – Pag-uusapan ko ang tungkol sa Causal consistency - ito ay isang feature na ginawa namin sa MongoDB. Nagtatrabaho ako sa isang grupo ng mga distributed system, ginawa namin ito mga dalawang taon na ang nakakaraan.
Sa proseso, kailangan kong maging pamilyar sa maraming akademikong pananaliksik, dahil ang tampok na ito ay pinag-aralan nang mabuti. Ito ay lumabas na walang isang artikulo ang umaangkop sa kung ano ang kinakailangan sa isang database ng produksyon dahil sa napaka-tiyak na mga kinakailangan na malamang na naroroon sa anumang application ng produksyon.
Pag-uusapan ko kung paano kami, bilang mga mamimili ng akademikong Pananaliksik, ay naghahanda ng isang bagay mula dito na maaari naming ipakita sa aming mga gumagamit bilang isang yari na ulam na maginhawa at ligtas na gamitin.
Ang pagkakapare-pareho ng sanhi. Tukuyin natin ang mga konsepto
Upang magsimula, gusto kong sabihin sa mga pangkalahatang tuntunin kung ano ang Causal consistency. Mayroong dalawang karakter - sina Leonard at Penny (serye sa TV na "The Big Bang Theory"):
Sabihin nating nasa Europe si Penny at gusto siyang ihagis ni Leonard ng surprise party. At wala siyang maisip na mas mahusay kaysa itapon siya sa listahan ng kanyang kaibigan, na magpadala sa lahat ng kanyang mga kaibigan ng update sa feed: "Pasayahin natin si Penny!" (Siya ay nasa Europa, habang siya ay natutulog, hindi niya nakikita ang lahat ng ito at hindi nakikita, dahil wala siya doon). Sa huli, dine-delete niya ang post na ito, binubura ito sa Feed at ni-restore ang access para wala siyang mapansin at walang iskandalo.
Lahat ng ito ay mabuti at mabuti, ngunit ipagpalagay natin na ang sistema ay ipinamahagi at ang mga bagay ay naging medyo mali. Maaaring, halimbawa, mangyari na ang paghihigpit sa pag-access ni Penny ay naganap pagkatapos lumitaw ang post na ito, kung ang mga kaganapan ay hindi nauugnay sa sanhi at epekto. Sa totoo lang, ito ay isang halimbawa kung kailan kinakailangan ang Causal consistency upang maisagawa ang isang function ng negosyo (sa kasong ito).
Sa katunayan, ang mga ito ay medyo di-maliit na katangian ng database - napakakaunting mga tao ang sumusuporta sa kanila. Lumipat tayo sa mga modelo.
Consistency Models
Ano nga ba ang isang modelo ng pagkakapare-pareho sa mga database? Ito ang ilan sa mga garantiya na ibinibigay ng isang distributed system tungkol sa kung anong data ang matatanggap ng kliyente at sa anong pagkakasunud-sunod.
Sa prinsipyo, ang lahat ng mga modelo ng pagkakapare-pareho ay kumukulo sa kung gaano kapareho ang isang distributed system sa isang sistema na tumatakbo, halimbawa, sa isang node sa isang laptop. At ito ay kung paano magkatulad ang isang sistema na tumatakbo sa libu-libong geo-distributed na "Mga Node" sa isang laptop, kung saan ang lahat ng mga pag-aari na ito ay awtomatikong gumanap sa prinsipyo.
Samakatuwid, ang mga modelo ng pagkakapare-pareho ay inilalapat lamang sa mga distributed system. Ang lahat ng mga system na dati nang umiral at nagpapatakbo sa parehong vertical scaling ay hindi nakaranas ng mga ganoong problema. Mayroong isang Buffer Cache, at lahat ay palaging binabasa mula dito.
Model Strong
Sa totoo lang, ang pinakaunang modelo ay Strong (o ang rise ability line, gaya ng madalas na tawag dito). Ito ay isang modelo ng pagkakapare-pareho na nagsisiguro na ang bawat pagbabago, kapag nakumpirma na ito ay naganap, ay makikita ng lahat ng mga gumagamit ng system.
Lumilikha ito ng isang pandaigdigang pagkakasunud-sunod ng lahat ng mga kaganapan sa database. Ito ay isang napakalakas na consistency property, at ito ay karaniwang napakamahal. Gayunpaman, ito ay lubos na sinusuportahan. Napakamahal lang at mabagal - bihira lang gamitin. Ito ay tinatawag na kakayahang tumaas.
May isa pa, mas malakas na property na sinusuportahan sa Spanner - tinatawag na External Consistency. Mamaya na lang natin pag-usapan.
Sanhi
Ang susunod ay Causal, na kung ano mismo ang aking pinag-uusapan. Mayroong ilang higit pang mga sub-level sa pagitan ng Strong at Causal na hindi ko pag-uusapan, ngunit lahat sila ay nagmumula sa Causal. Ito ay isang mahalagang modelo dahil ito ang pinakamalakas sa lahat ng mga modelo, ang pinakamatibay na pagkakapare-pareho sa pagkakaroon ng isang network o mga partisyon.
Ang mga sanhi ay talagang isang sitwasyon kung saan ang mga kaganapan ay konektado ng isang sanhi-at-bunga na relasyon. Kadalasan sila ay itinuturing na mga karapatan ng Read your on mula sa pananaw ng kliyente. Kung naobserbahan ng kliyente ang ilang mga halaga, hindi niya makikita ang mga halaga na nasa nakaraan. Nagsisimula na siyang makakita ng prefix readings. Ang lahat ay bumaba sa parehong bagay.
Ang mga sanhi bilang isang modelo ng pagkakapare-pareho ay isang bahagyang pag-order ng mga kaganapan sa server, kung saan ang mga kaganapan mula sa lahat ng mga kliyente ay sinusunod sa parehong pagkakasunud-sunod. Sa kasong ito, sina Leonard at Penny.
Panghuli
Ang pangatlong modelo ay ang Eventual Consistency. Ito ang ganap na sinusuportahan ng lahat ng mga distributed system, ang minimal na modelo na may katuturan sa lahat. Nangangahulugan ito ng sumusunod: kapag mayroon kaming ilang pagbabago sa data, sa isang punto ay nagiging pare-pareho ang mga ito.
Sa ganoong sandali ay wala siyang sinasabi, kung hindi, siya ay magiging External Consistency - ito ay magiging isang ganap na kakaibang kuwento. Gayunpaman, ito ay isang napaka-tanyag na modelo, ang pinakakaraniwan. Bilang default, lahat ng user ng mga distributed system ay gumagamit ng Eventual Consistency.
Nais kong magbigay ng ilang mga paghahambing na halimbawa:
Ano ang ibig sabihin ng mga arrow na ito?
- Latency Habang tumataas ang lakas ng pagkakapare-pareho, nagiging mas malaki ito para sa mga malinaw na dahilan: kailangan mong gumawa ng higit pang mga tala, kumuha ng kumpirmasyon mula sa lahat ng mga host at node na lumalahok sa cluster na ang data ay naroroon na. Alinsunod dito, ang Eventual Consistency ay may pinakamabilis na sagot, dahil doon, bilang isang panuntunan, maaari mo ring i-commit ito sa memorya at ito ay, sa prinsipyo, ay magiging sapat.
- Availability. Kung naiintindihan namin ito bilang ang kakayahan ng system na tumugon sa pagkakaroon ng mga break ng network, partition, o ilang uri ng pagkabigo, tataas ang fault tolerance habang bumababa ang consistency model, dahil sapat na para sa amin na ang isang host ay nabubuhay at kasabay nito. ang oras ay gumagawa ng ilang data. Ang Eventual Consistency ay hindi ginagarantiyahan ang anumang bagay tungkol sa data - maaari itong maging anuman.
- Anomalya. Kasabay nito, siyempre, ang bilang ng mga anomalya ay tumataas. Sa Strong Consistency halos hindi sila dapat umiral, ngunit sa Eventual Consistency maaari silang maging anuman. Ang tanong ay lumitaw: bakit pinipili ng mga tao ang Eventual Consistency kung naglalaman ito ng mga anomalya? Ang sagot ay ang mga modelo ng Eventual Consistency ay naaangkop at may mga anomalya, halimbawa, sa maikling panahon; posible na gamitin ang wizard upang magbasa at mas marami o mas kaunting magbasa ng pare-parehong data; Kadalasan ay posible na gumamit ng malakas na mga modelo ng pagkakapare-pareho. Sa pagsasagawa ito ay gumagana, at kadalasan ang bilang ng mga anomalya ay limitado sa oras.
CAP theorem
Kapag nakita mo ang mga salitang consistency, availability – ano ang naiisip mo? Tama iyon - CAP theorem! Ngayon gusto kong iwaksi ang alamat... Hindi ako - ito ay si Martin Kleppmann, na nagsulat ng isang kahanga-hangang artikulo, isang kahanga-hangang libro.
Ang CAP theorem ay isang prinsipyo na binuo noong 2000s na Consistency, Availability, Partitions: kumuha ng alinman sa dalawa, at hindi ka makakapili ng tatlo. Ito ay isang tiyak na prinsipyo. Ito ay napatunayan bilang isang teorama makalipas ang ilang taon nina Gilbert at Lynch. Pagkatapos ay nagsimula itong gamitin bilang isang mantra - nagsimulang nahahati ang mga sistema sa CA, CP, AP at iba pa.
Ang theorem na ito ay aktwal na napatunayan para sa mga sumusunod na kaso... Una, ang Availability ay itinuturing na hindi isang tuluy-tuloy na halaga mula zero hanggang daan-daan (0 - ang sistema ay "patay", 100 - mabilis na tumugon; nakasanayan na nating isaalang-alang ito sa ganoong paraan) , ngunit bilang isang pag-aari ng algorithm , na ginagarantiyahan na para sa lahat ng mga pagpapatupad nito ay nagbabalik ito ng data.
Walang anumang salita tungkol sa oras ng pagtugon! Mayroong isang algorithm na nagbabalik ng data pagkatapos ng 100 taon - isang ganap na kahanga-hangang magagamit na algorithm, na bahagi ng CAP theorem.
Pangalawa: ang theorem ay napatunayan para sa mga pagbabago sa mga halaga ng parehong susi, sa kabila ng katotohanan na ang mga pagbabagong ito ay maaaring baguhin. Nangangahulugan ito na sa katotohanan ang mga ito ay halos hindi ginagamit, dahil ang mga modelo ay magkaibang Eventual Consistency, Strong Consistency (siguro).
Para saan ang lahat ng ito? Bukod dito, ang CAP theorem sa eksaktong anyo kung saan ito napatunayan ay halos hindi naaangkop at bihirang ginagamit. Sa teoretikal na anyo, kahit papaano ay nililimitahan nito ang lahat. Ito ay lumiliko ang isang tiyak na prinsipyo na intuitively tama, ngunit sa pangkalahatan ay hindi napatunayan.
Ang pagkakapare-pareho ng sanhi ay ang pinakamatibay na modelo
Ang nangyayari ngayon ay makukuha mo ang lahat ng tatlong bagay: Consistency, Availability using Partitions. Sa partikular, ang pagkakapare-pareho ng sanhi ay ang pinakamatibay na modelo ng pagkakapare-pareho, na gumagana pa rin sa pagkakaroon ng Mga Partisyon (mga break sa network). Iyon ang dahilan kung bakit ito ay napakalaking interes, at iyon ang dahilan kung bakit namin ito kinuha.
Una, pinapasimple nito ang gawain ng mga developer ng application. Sa partikular, ang pagkakaroon ng mahusay na suporta mula sa server: kapag ang lahat ng mga talaan na nangyayari sa loob ng isang kliyente ay ginagarantiyahan na darating sa parehong pagkakasunud-sunod sa isa pang kliyente. Pangalawa, ito ay lumalaban sa mga partisyon.
MongoDB Panloob na Kusina
Nang maalala na tanghalian na, lumipat kami sa kusina. Sasabihin ko sa iyo ang tungkol sa modelo ng system, ibig sabihin, kung ano ang MongoDB para sa mga nakakarinig tungkol sa naturang database sa unang pagkakataon.
Ang MongoDB (mula rito ay tinutukoy bilang "MongoDB") ay isang distributed system na sumusuporta sa horizontal scaling, iyon ay, sharding; at sa loob ng bawat shard ay sinusuportahan din nito ang data redundancy, iyon ay, pagtitiklop.
Ang Sharding sa MongoDB (hindi isang relational database) ay nagsasagawa ng awtomatikong pagbabalanse, ibig sabihin, ang bawat koleksyon ng mga dokumento (o "talahanayan" sa mga tuntunin ng relational data) ay nahahati sa mga piraso, at ang server ay awtomatikong inililipat ang mga ito sa pagitan ng mga shards.
Ang Query Router, na namamahagi ng mga kahilingan, para sa isang kliyente ay ilang kliyente kung saan ito gumagana. Alam na nito kung saan at kung anong data ang matatagpuan at idinidirekta ang lahat ng mga kahilingan sa tamang shard.
Isa pang mahalagang punto: Ang MongoDB ay isang solong master. Mayroong isang Pangunahing - maaari itong tumagal ng mga talaan na sumusuporta sa mga susi na nilalaman nito. Hindi ka makakagawa ng Multi-master write.
Gumawa kami ng release 4.2 - lumitaw ang mga bagong kawili-wiling bagay doon. Sa partikular, ipinasok nila ang Lucene - paghahanap - katulad ng executable java nang direkta sa Mongo, at doon naging posible na magsagawa ng mga paghahanap sa pamamagitan ng Lucene, katulad ng sa Elastica.
At gumawa sila ng bagong produkto - Charts, available din ito sa Atlas (Mongo's own Cloud). Mayroon silang Libreng Tier - maaari mong paglaruan ito. Talagang nagustuhan ko ang Mga Chart - visualization ng data, napaka-intuitive.
Mga sangkap Ang pagkakapare-pareho ng sanhi
Nagbilang ako ng humigit-kumulang 230 artikulo na nai-publish sa paksang ito - mula kay Leslie Lampert. Ngayon mula sa aking alaala ay ihahatid ko sa iyo ang ilang bahagi ng mga materyales na ito.
Nagsimula ang lahat sa isang artikulo ni Leslie Lampert, na isinulat noong 1970s. Tulad ng nakikita mo, ang ilang pananaliksik sa paksang ito ay patuloy pa rin. Ngayon ang Causal consistency ay nakakaranas ng interes na may kaugnayan sa pagbuo ng mga distributed system.
Paghihigpit
Anong mga paghihigpit ang mayroon? Ito ay talagang isa sa mga pangunahing punto, dahil ang mga paghihigpit na ipinataw ng isang sistema ng produksyon ay ibang-iba sa mga paghihigpit na umiiral sa mga akademikong artikulo. Kadalasan sila ay medyo artipisyal.
- Una, ang "MongoDB" ay isang solong master, tulad ng nasabi ko na (ito ay lubos na nagpapadali).
- Naniniwala kami na dapat suportahan ng system ang humigit-kumulang 10 libong shards. Hindi kami makakagawa ng anumang mga desisyon sa arkitektura na tahasang maglilimita sa halagang ito.
- Mayroon kaming isang ulap, ngunit ipinapalagay namin na ang isang tao ay dapat pa ring magkaroon ng pagkakataon kapag nag-download siya ng binary, pinapatakbo ito sa kanyang laptop, at lahat ay gumagana nang mahusay.
- Ipinapalagay namin ang isang bagay na bihirang ipinapalagay ng Pananaliksik: maaaring gawin ng mga panlabas na kliyente ang anumang gusto nila. Ang MongoDB ay open source. Alinsunod dito, ang mga kliyente ay maaaring maging napakatalino at galit - maaari nilang gustuhing sirain ang lahat. Inaasahan namin na maaaring nagmula ang Byzantine Feilor.
- Para sa mga panlabas na kliyente na nasa labas ng perimeter, mayroong isang mahalagang limitasyon: kung hindi pinagana ang feature na ito, hindi dapat obserbahan ang pagkasira ng pagganap.
- Ang isa pang punto ay karaniwang kontra-akademiko: ang pagiging tugma ng mga nakaraang bersyon at mga hinaharap. Dapat suportahan ng mga lumang driver ang mga bagong update, at dapat suportahan ng database ang mga lumang driver.
Sa pangkalahatan, ang lahat ng ito ay nagpapataw ng mga paghihigpit.
Mga bahagi ng pagkakapare-pareho ng sanhi
Pag-uusapan ko ngayon ang tungkol sa ilan sa mga sangkap. Kung isasaalang-alang namin ang pagkakapare-pareho ng sanhi sa pangkalahatan, maaari kaming pumili ng mga bloke. Pumili kami mula sa mga gawa na kabilang sa isang partikular na bloke: Pagsubaybay sa Dependency, pagpili ng mga orasan, kung paano masi-synchronize ang mga orasan na ito sa isa't isa, at kung paano namin tinitiyak ang seguridad - ito ay isang magaspang na balangkas ng kung ano ang tatalakayin ko:
Buong Pagsubaybay sa Dependency
Bakit kailangan? Upang kapag ang data ay kinopya, ang bawat tala, ang bawat pagbabago ng data ay naglalaman ng impormasyon tungkol sa kung anong mga pagbabago ang nakasalalay dito. Ang pinaka-una at walang muwang na pagbabago ay kapag ang bawat mensahe na naglalaman ng talaan ay naglalaman ng impormasyon tungkol sa mga nakaraang mensahe:
Sa halimbawang ito, ang numero sa mga kulot na bracket ay ang mga record na numero. Minsan ang mga rekord na ito na may mga halaga ay inililipat pa sa kanilang kabuuan, kung minsan ang ilang mga bersyon ay inililipat. Ang ilalim na linya ay ang bawat pagbabago ay naglalaman ng impormasyon tungkol sa nauna (malinaw na dala ang lahat ng ito sa loob mismo).
Bakit kami nagpasya na huwag gamitin ang diskarteng ito (buong pagsubaybay)? Malinaw, dahil ang diskarte na ito ay hindi praktikal: ang anumang pagbabago sa isang social network ay nakasalalay sa lahat ng mga nakaraang pagbabago sa social network na iyon, paglilipat, sabihin, Facebook o VKontakte sa bawat pag-update. Gayunpaman, mayroong maraming pananaliksik sa Full Dependency Tracking - ito ay mga pre-social network; para sa ilang mga sitwasyon ito ay talagang gumagana.
Tiyak na Pagsubaybay sa Dependency
Ang susunod ay mas limitado. Ang paglipat ng impormasyon ay isinasaalang-alang din dito, ngunit ang malinaw na umaasa lamang. Ano ang nakasalalay sa kung ano, bilang panuntunan, ang tinutukoy ng Aplikasyon. Kapag ang data ay kinopya, ang query ay nagbabalik lamang ng mga tugon kapag ang mga nakaraang dependency ay nasiyahan, ibig sabihin, ipinapakita. Ito ang esensya kung paano gumagana ang Causal consistency.
Nakikita niya na ang rekord 5 ay nakasalalay sa mga talaan 1, 2, 3, 4 - nang naaayon, naghihintay siya bago makakuha ng access ang kliyente sa mga pagbabagong ginawa ng desisyon sa pag-access ni Penny, kapag ang lahat ng nakaraang pagbabago ay dumaan na sa database.
Hindi rin ito nababagay sa amin, dahil napakaraming impormasyon pa rin, at pabagalin nito ang mga bagay-bagay. May isa pang diskarte...
Lamport Clock
Matanda na sila. Ang Lamport Clock ay nangangahulugan na ang mga dependency na ito ay nakatiklop sa isang scalar function, na tinatawag na Lamport Clock.
Ang scalar function ay ilang abstract na numero. Madalas itong tinatawag na lohikal na oras. Sa bawat kaganapan, tumataas ang counter na ito. Ang Counter, na kasalukuyang kilala sa proseso, ay nagpapadala ng bawat mensahe. Ito ay malinaw na ang mga proseso ay maaaring hindi naka-sync, maaari silang magkaroon ng ganap na magkakaibang mga oras. Gayunpaman, binabalanse ng system ang orasan sa ganoong pagmemensahe. Ano ang mangyayari sa kasong ito?
Hinati ko ang malaking shard na iyon sa dalawa para maging malinaw: Ang mga kaibigan ay maaaring manirahan sa isang node, na naglalaman ng isang piraso ng koleksyon, at Feed ay maaaring mabuhay sa isa pang node, na naglalaman ng isang piraso ng koleksyon na ito. Malinaw ba kung paano sila makakaalis sa linya? Sasabihin ng Unang Feed: "Replicated", at pagkatapos ay Mga Kaibigan. Kung ang system ay hindi nagbibigay ng ilang uri ng garantiya na ang Feed ay hindi ipapakita hanggang ang mga dependency ng Mga Kaibigan sa koleksyon ng Mga Kaibigan ay naihatid din, kung gayon magkakaroon tayo ng eksaktong sitwasyon na aking nabanggit.
Nakikita mo kung paano lohikal na tumataas ang counter time sa Feed:
Kaya ang pangunahing pag-aari nitong Lamport Clock at Causal consistency (ipinaliwanag sa pamamagitan ng Lamport Clock) ay ito: kung mayroon tayong Events A at B, at ang Event B ay depende sa Event A*, pagkatapos ay sumusunod na ang LogicalTime ng Event A ay mas mababa sa LogicalTime mula sa Event B.
* Minsan sinasabi rin nila na nangyari ang A bago ang B, iyon ay, nangyari ang A bago ang B - ito ay isang tiyak na kaugnayan na bahagyang nag-uutos sa buong hanay ng mga kaganapan na nangyari sa pangkalahatan.
Ang kabaligtaran ay hindi tama. Ito ay talagang isa sa mga pangunahing disadvantages ng Lamport Clock - bahagyang pagkakasunud-sunod. Mayroong isang konsepto tungkol sa sabay-sabay na mga kaganapan, iyon ay, mga kaganapan kung saan hindi (A nangyari bago B) o (A nangyari bago B). Ang isang halimbawa ay ang parallel na pagdaragdag ni Leonard sa ibang tao bilang isang kaibigan (hindi kahit na si Leonard, ngunit si Sheldon, halimbawa).
Ito ang ari-arian na kadalasang ginagamit kapag nagtatrabaho sa mga orasan ng Lamport: partikular na tinitingnan nila ang pag-andar at mula dito napagpasyahan nila na marahil ang mga kaganapang ito ay nakasalalay. Dahil totoo ang isang paraan: kung ang LogicalTime A ay mas mababa sa LogicalTime B, hindi maaaring mangyari ang B bago ang A; at kung higit pa, kung gayon marahil.
Vector Clock
Ang lohikal na pag-unlad ng orasan ng Lamport ay ang Vector Clock. Nag-iiba ang mga ito sa bawat node na naririto ay naglalaman ng sarili nitong hiwalay na orasan, at ipinapadala sila bilang isang vector.
Sa kasong ito, makikita mo na ang zeroth index ng vector ay responsable para sa Feed, at ang unang index ng vector ay para sa Mga Kaibigan (bawat isa sa mga node na ito). At ngayon ay tataas sila: ang zero index ng "Feed" ay tumataas kapag nagsusulat - 1, 2, 3:
Bakit mas mahusay ang Vector Clock? Dahil pinapayagan ka nitong malaman kung aling mga kaganapan ang sabay-sabay at kapag nangyari ang mga ito sa iba't ibang mga node. Napakahalaga nito para sa isang sharding system tulad ng MongoDB. Gayunpaman, hindi namin ito pinili, kahit na ito ay isang kahanga-hangang bagay, at ito ay mahusay na gumagana, at ito ay malamang na angkop sa amin...
Kung mayroon kaming 10 libong shards, hindi kami makakapaglipat ng 10 libong mga bahagi, kahit na i-compress namin ito o magkaroon ng iba pa - ang kargamento ay magiging ilang beses na mas maliit kaysa sa dami ng buong vector na ito. Samakatuwid, sa pagngangalit ng aming mga puso at ngipin, tinalikuran namin ang diskarteng ito at lumipat sa isa pa.
Spanner TrueTime. Atomic na orasan
Sabi ko magkakaroon ng kwento tungkol kay Spanner. Ito ay isang cool na bagay, mula pa sa ika-XNUMX siglo: mga atomic na orasan, pag-synchronize ng GPS.
Ano ang ideya? Ang "Spanner" ay isang Google system na kamakailan ay naging available sa mga tao (idinagdag nila ang SQL dito). Ang bawat transaksyon doon ay may ilang time stamp. Dahil ang oras ay naka-synchronize*, ang bawat kaganapan ay maaaring magtalaga ng isang partikular na oras - ang mga atomic na orasan ay may oras ng paghihintay, pagkatapos nito ay garantisadong "mangyayari" ang ibang oras.
Kaya, sa pamamagitan lamang ng pagsulat sa database at paghihintay ng ilang panahon, ang Serializability ng kaganapan ay awtomatikong ginagarantiyahan. Mayroon silang pinakamatibay na modelo ng Consistency na maiisip sa prinsipyo - ito ay External Consistency.
* Ito ang pangunahing problema sa mga orasan ng Lampart - hindi sila kailanman magkakasabay sa mga distributed system. Maaari silang maghiwalay; kahit na may NTP, hindi pa rin sila gumagana nang maayos. Ang "Spanner" ay may atomic na orasan at ang pag-synchronize, tila, ay microseconds.
Bakit hindi tayo pumili? Hindi namin ipinapalagay na ang aming mga user ay may built-in na atomic na orasan. Kapag lumitaw ang mga ito, na binuo sa bawat laptop, magkakaroon ng isang uri ng sobrang cool na pag-synchronize ng GPS - pagkatapos ay oo... Ngunit sa ngayon ang pinakamahusay na posible ay ang Amazon, Mga Base Station - para sa mga panatiko... Kaya gumamit kami ng iba pang mga relo .
Hybrid na Orasan
Ito talaga ang tumatak sa MongoDB kapag tinitiyak ang pagkakapare-pareho ng Causal. Paano sila hybrid? Ang hybrid ay isang scalar value, ngunit mayroon itong dalawang bahagi:
- Ang una ay ang Unix epoch (ilang segundo ang lumipas mula noong "simula ng mundo ng computer").
- Ang pangalawa ay ilang pagtaas, isa ring 32-bit na unsigned int.
Iyon lang, actually. Mayroong ganitong diskarte: ang bahagi na responsable para sa oras ay naka-synchronize sa orasan sa lahat ng oras; sa tuwing may naganap na pag-update, ang bahaging ito ay naka-synchronize sa orasan at lumalabas na ang oras ay palaging higit pa o hindi gaanong tama, at ang pagdaragdag ay nagpapahintulot sa iyo na makilala ang mga kaganapan na naganap sa parehong punto ng oras.
Bakit ito mahalaga para sa MongoDB? Dahil pinapayagan ka nitong gumawa ng ilang uri ng mga backup na restaurant sa isang tiyak na punto ng oras, iyon ay, ang kaganapan ay na-index ng oras. Ito ay mahalaga kapag ang ilang mga kaganapan ay kinakailangan; Para sa isang database, ang mga kaganapan ay mga pagbabago sa database na naganap sa ilang mga agwat sa oras.
Sasabihin ko sa iyo ang pinakamahalagang dahilan sa iyo lamang (pakiusap, huwag sabihin sa sinuman)! Ginawa namin ito dahil ito ang hitsura ng organisado, na-index na data sa MongoDB OpLog. Ang OpLog ay isang istraktura ng data na naglalaman ng ganap na lahat ng mga pagbabago sa database: pumunta muna sila sa OpLog, at pagkatapos ay inilapat ang mga ito sa Storage mismo sa kaso kapag ito ay isang kinopya na petsa o shard.
Ito ang pangunahing dahilan. Gayunpaman, mayroon ding mga praktikal na kinakailangan para sa pagbuo ng isang database, na nangangahulugan na dapat itong maging simple - maliit na code, bilang ilang mga sirang bagay hangga't maaari na kailangang muling isulat at subukan. Ang katotohanan na ang aming mga oplog ay na-index ng mga hybrid na orasan ay nakatulong nang malaki at nagbigay-daan sa aming gumawa ng tamang pagpili. Talagang nagbunga ito at kahit papaano ay nakapagtrabaho sa pinakaunang prototype. Ito ay napaka-cool!
Pag-synchronize ng orasan
Mayroong ilang mga paraan ng pag-synchronize na inilarawan sa siyentipikong panitikan. Pinag-uusapan ko ang tungkol sa pag-synchronize kapag mayroon tayong dalawang magkaibang shards. Kung mayroong isang replica set, hindi na kailangan para sa anumang pag-synchronize: ito ay isang "single master"; mayroon kaming OpLog, kung saan nahuhulog ang lahat ng mga pagbabago - sa kasong ito, ang lahat ay nakaayos nang sunud-sunod sa "Oplog" mismo. Ngunit kung mayroon tayong dalawang magkaibang shards, mahalaga ang time synchronization dito. Dito mas nakatulong ang vector clock! Pero wala tayo sa kanila.
Ang pangalawa ay angkop - ito ay "Heartbeats". Posibleng makipagpalitan ng ilang signal na nangyayari sa bawat yunit ng oras. Ngunit masyadong mabagal ang Heartbeats, hindi kami makapagbibigay ng latency sa aming kliyente.
Ang totoong oras ay, siyempre, isang kahanga-hangang bagay. Ngunit, muli, malamang na ito ang hinaharap... Bagama't maaari na itong gawin sa Atlas, mayroon nang mabilis na "Amazon" time synchronizers. Ngunit hindi ito magiging available sa lahat.
Ang tsismis ay kapag ang lahat ng mga mensahe ay may kasamang oras. Ito ang tinatayang ginagamit namin. Ang bawat mensahe sa pagitan ng mga node, isang driver, isang data node router, ganap na lahat para sa MongoDB ay ilang uri ng elemento, isang bahagi ng database na naglalaman ng isang orasan na tumatakbo. Mayroon silang kahulugan ng hybrid na oras sa lahat ng dako, ito ay ipinadala. 64 bits? Ito ay nagpapahintulot, ito ay posible.
Paano ito gumagana nang magkasama?
Narito ako ay tumitingin sa isang replica set upang gawing mas madali ito. May Primary at Secondary. Gumagawa ng replikasyon ang Secondary at hindi palaging ganap na naka-synchronize sa Primary.
May naganap na pagpapasok sa "Primery" na may partikular na halaga ng oras. Ang insert na ito ay nagpapataas ng internal na bilang ng 11, kung ito ang maximum. O susuriin nito ang mga halaga ng orasan at i-sync sa orasan kung mas malaki ang mga halaga ng orasan. Ito ay nagpapahintulot sa iyo na ayusin ayon sa oras.
Pagkatapos niyang gawin ang pag-record, isang mahalagang sandali ang magaganap. Ang orasan ay nasa "MongoDB" at dinadagdagan lamang sa kaso ng pagsulat sa "Oplog". Ito ang kaganapan na nagbabago sa estado ng system. Sa ganap na lahat ng mga klasikong artikulo, ang isang kaganapan ay itinuturing na kapag ang isang mensahe ay tumama sa isang node: dumating na ang mensahe, na nangangahulugang binago ng system ang estado nito.
Ito ay dahil sa katotohanan na sa panahon ng pananaliksik ay hindi lubos na malinaw kung paano bibigyang-kahulugan ang mensaheng ito. Alam nating sigurado na kung hindi ito makikita sa "Oplog", hindi ito mabibigyang-kahulugan sa anumang paraan, at ang pagbabago sa estado ng system ay isang entry lamang sa "Oplog". Pinapasimple nito ang lahat para sa amin: pinapasimple ito ng modelo, at pinapayagan kaming ayusin ito sa loob ng isang set ng replica, at marami pang ibang kapaki-pakinabang na bagay.
Ang halaga na nakasulat na sa "Oplog" ay ibinalik - alam namin na ang "Oplog" ay naglalaman na ng halagang ito, at ang oras nito ay 12. Ngayon, sabihin nating, ang pagbabasa ay nagsisimula sa isa pang node (Secondary), at ito ay nagpapadala pagkatapos ngClusterTime sa ang mensahe. Sinabi niya: "Kailangan ko ang lahat ng nangyari pagkatapos ng 12 o sa panahon ng labindalawa" (tingnan ang larawan sa itaas).
Ito ang tinatawag na Causal a consistent (CAT). Mayroong isang konsepto sa teorya na ito ay ilang bahagi ng oras, na pare-pareho sa sarili nito. Sa kasong ito, maaari nating sabihin na ito ang estado ng sistema na naobserbahan sa oras na 12.
Ngayon ay wala pa rito, dahil ang ganitong uri ng simulates ang sitwasyon kapag kailangan mo ang Secondary upang kopyahin ang data mula sa Primary. Naghihintay siya... At ngayon dumating na ang data - ibinalik niya ang mga halagang ito pabalik.
Iyan ay halos kung paano gumagana ang lahat. halos.
Ano ang ibig sabihin ng "halos"? Ipagpalagay natin na mayroong ilang tao na nakabasa at nakaunawa kung paano ito gumagana. Napagtanto ko na sa tuwing nangyayari ang ClusterTime, ina-update nito ang panloob na lohikal na orasan, at pagkatapos ay ang susunod na entry ay tataas ng isa. Ang function na ito ay tumatagal ng 20 linya. Sabihin nating ang taong ito ay nagpapadala ng pinakamalaking 64-bit na numero, minus isa.
Bakit "minus one"? Dahil ang panloob na orasan ay papalitan sa halagang ito (malinaw naman, ito ang pinakamalaki at mas malaki kaysa sa kasalukuyang oras), kung gayon ang isang entry ay magaganap sa "Oplog", at ang orasan ay dadagdagan ng isa pang yunit - at magkakaroon na. maging isang maximum na halaga (mayroong lahat ng mga yunit, wala nang iba pang mapupuntahan) , unsaint ints).
Ito ay malinaw na pagkatapos nito ang sistema ay nagiging ganap na hindi naa-access para sa anumang bagay. Maaari lamang itong i-unload at linisin - maraming manu-manong trabaho. Buong kakayahang magamit:
Bukod dito, kung ito ay ginagaya sa ibang lugar, kung gayon ang buong kumpol ay bumagsak lamang. Isang ganap na hindi katanggap-tanggap na sitwasyon na maaaring ayusin ng sinuman nang napakabilis at madali! Samakatuwid, itinuring namin ang sandaling ito bilang isa sa pinakamahalaga. Paano ito maiiwasan?
Ang aming paraan ay ang pagpirma ng clusterTime
Ito ay kung paano ito ipinadala sa mensahe (bago ang asul na teksto). Ngunit nagsimula rin kaming bumuo ng isang lagda (asul na teksto):
Ang lagda ay nabuo sa pamamagitan ng isang susi na nakaimbak sa loob ng database, sa loob ng isang secure na perimeter; mismo ay nabuo at na-update (ang mga gumagamit ay walang nakikita tungkol dito). Ang isang hash ay nabuo, at ang bawat mensahe ay nilagdaan kapag ginawa at napatunayan kapag natanggap.
Ang tanong ay malamang na lumitaw sa isipan ng mga tao: "Gaano ito nagpapabagal sa mga bagay?" Sinabi ko sa iyo na dapat itong gumana nang mabilis, lalo na sa kawalan ng tampok na ito.
Ano ang ibig sabihin ng paggamit ng Causal consistency sa kasong ito? Ito ay upang ipakita ang afterClusterTime parameter. Kung wala ito, magpapasa pa rin ito ng mga halaga. Ang tsismis, simula sa bersyon 3.6, ay palaging gumagana.
Kung iiwan natin ang patuloy na henerasyon ng mga lagda, pabagalin nito ang system kahit na walang feature, na hindi nakakatugon sa ating mga diskarte at kinakailangan. So anong ginawa natin?
Gawin mo agad!
Ito ay isang medyo simpleng bagay, ngunit ang lansihin ay kawili-wili - ibabahagi ko ito, baka may interesado.
Mayroon kaming hash na nag-iimbak ng nilagdaang data. Ang lahat ng data ay dumadaan sa cache. Hindi nilalagdaan ng cache ang partikular na oras, ngunit ang Saklaw. Kapag dumating ang ilang value, bumubuo kami ng Range, tinatago ang huling 16 bits, at nilagdaan namin ang value na ito:
Sa pamamagitan ng pagtanggap ng naturang lagda, pinapabilis namin ang system (medyo) 65 libong beses. Gumagana ito nang mahusay: noong nagsagawa kami ng mga eksperimento, ang oras ay talagang nabawasan ng 10 libong beses noong nagkaroon kami ng sunud-sunod na pag-update. Malinaw na kapag nagkakasalungatan sila, hindi ito gumagana. Ngunit sa karamihan ng mga praktikal na kaso ito ay gumagana. Ang kumbinasyon ng pirma ng Range kasama ang lagda ay nalutas ang problema sa seguridad.
Ano ang natutunan natin?
Mga aral na natutunan natin dito:
- Kailangan nating magbasa ng mga materyales, kwento, artikulo, dahil marami tayong mga kawili-wiling bagay. Kapag gumagawa kami ng ilang feature (lalo na ngayon, kapag nagsagawa kami ng mga transaksyon, atbp.), kailangan naming basahin at unawain. Ito ay tumatagal ng oras, ngunit ito ay talagang lubhang kapaki-pakinabang dahil ginagawang malinaw kung nasaan tayo. Mukhang wala kaming naisip na bago - kinuha lang namin ang mga sangkap.
Sa pangkalahatan, mayroong isang tiyak na pagkakaiba sa pag-iisip kapag mayroong isang akademikong kumperensya (Sigmon, halimbawa) - lahat ay nakatuon sa mga bagong ideya. Ano ang bago sa aming algorithm? Walang partikular na bago dito. Ang bagong bagay sa halip ay nakasalalay sa paraan ng pinagsama-sama nating mga umiiral na diskarte. Samakatuwid, ang unang bagay ay basahin ang mga klasiko, simula sa Lampart.
- Sa produksyon, ang mga kinakailangan ay ganap na naiiba. Sigurado ako na marami sa inyo ay hindi nahaharap sa "spherical" na mga database sa abstract vacuum, ngunit sa mga normal, totoong bagay na may mga problema sa availability, latency at fault tolerance.
- Ang huling bagay ay kailangan naming isaalang-alang ang iba't ibang mga ideya at pagsamahin ang ilang ganap na magkakaibang mga artikulo sa isang diskarte, nang magkasama. Ang ideya tungkol sa pagpirma, halimbawa, sa pangkalahatan ay nagmula sa isang artikulong isinasaalang-alang ang Paxos protocol, na para sa mga hindi Byzantine Failors ay nasa loob ng authorization protocol, para sa Byzantine - sa labas ng authorization protocol... Sa pangkalahatan, ito mismo ang aming natapos ang paggawa.
Wala talagang bago dito! Ngunit sa sandaling pinaghalo namin ang lahat ... Ito ay katulad ng pagsasabi na ang Olivier salad recipe ay walang kapararakan, dahil ang mga itlog, mayonesa at mga pipino ay naimbento na ... Ito ay tungkol sa parehong kuwento.
Tatapusin ko na ito. Salamat!
mga katanungan
Tanong mula sa madla (mula rito ay tinutukoy bilang B): – Salamat, Mikhail, para sa ulat! Ang paksa tungkol sa oras ay kawili-wili. Gumagamit ka ng Gossiping. Sabi nila, lahat ay may kanya-kanyang oras, alam ng lahat ang kanilang lokal na oras. Sa pagkakaintindi ko, mayroon tayong driver - maaaring maraming kliyente na may mga driver, query-planner din, shards din... At ano ang binaba ng system kung bigla tayong magkaroon ng pagkakaiba: may nagpasya na ito ay para sa isang minuto sa unahan, may isang minuto sa likod? Saan tayo hahantong?
MT: - Napakagandang tanong talaga! Gusto ko lang magsalita tungkol sa mga shards. Kung naiintindihan ko nang tama ang tanong, mayroon tayong sumusunod na sitwasyon: mayroong shard 1 at shard 2, ang pagbabasa ay nangyayari mula sa dalawang shards na ito - mayroon silang pagkakaiba, hindi sila nakikipag-ugnayan sa isa't isa, dahil ang oras na alam nila ay magkaiba, lalo na yung time na nag e-exist sila sa oplogs.
Sabihin natin na ang shard 1 ay gumawa ng isang milyong record, ang shard 2 ay walang ginawa, at ang kahilingan ay umabot sa dalawang shard. At ang una ay may afterClusterTime na mahigit sa isang milyon. Sa ganoong sitwasyon, tulad ng ipinaliwanag ko, ang shard 2 ay hindi kailanman tutugon sa lahat.
SA: – Nais kong malaman kung paano sila nag-synchronize at pumili ng isang lohikal na oras?
MT: - Napakadaling i-synchronize. Shard, kapag dumating sa kanya ang afterClusterTime at hindi siya nakahanap ng oras sa "Oplog", hindi naaprubahan. Iyon ay, itinataas niya ang kanyang oras gamit ang kanyang mga kamay sa halagang ito. Nangangahulugan ito na wala itong mga kaganapan na tumutugma sa kahilingang ito. Nililikha niya ang kaganapang ito nang artipisyal at sa gayon ay nagiging Causal Consistent.
SA: – Paano kung pagkatapos nito ay dumating sa kanya ang iba pang mga kaganapan na nawala sa isang lugar sa network?
MT: – Ang Shard ay idinisenyo sa paraang hindi na sila babalik, dahil isa itong master. Kung nakapag-sign up na siya, hindi sila darating, ngunit darating mamaya. Hindi maaaring mangyari na ang isang bagay ay natigil sa isang lugar, pagkatapos ay hindi siya sumulat, at pagkatapos ay dumating ang mga kaganapang ito - at ang pagkakapare-pareho ng sanhi ay nasira. Kapag hindi siya sumulat, dapat silang lahat ay susunod (maghihintay siya para sa kanila).
SA: – Mayroon akong ilang mga katanungan tungkol sa mga pila. Ipinapalagay ng pagkakapare-pareho ng sanhi na mayroong isang partikular na pila ng mga aksyon na kailangang gawin. Ano ang mangyayari kung mawala ang isa sa aming mga pakete? Narito ang ika-10, ika-11... ang ika-12 ay nawala, at ang iba ay naghihintay na matupad ito. At biglang namatay ang sasakyan namin, wala kaming magawa. Mayroon bang maximum na haba ng pila na naiipon bago isagawa? Anong fatal failure ang nangyayari kapag nawala ang isang estado? Bukod dito, kung isusulat natin na mayroong ilang nakaraang estado, kung gayon dapat tayong magsimula mula dito? Ngunit hindi nila siya itinulak palayo!
MT: - Isang magandang tanong din! Anong gagawin natin? Ang MongoDB ay may konsepto ng quorum writes, quorum reads. Sa anong mga kaso maaaring mawala ang isang mensahe? Kapag hindi korum ang isang sulatin o kapag hindi korum ang isang nabasa (maaaring dumikit din ang ilang uri ng basura).
Tungkol sa pagkakapare-pareho ng sanhi, isang malaking pagsubok na pang-eksperimento ang isinagawa, ang resulta nito ay na sa kaso kapag ang pagsusulat at pagbabasa ay hindi korum, ang mga paglabag sa pagkakapare-pareho ng sanhi ay nangyayari. Eksakto sa sinasabi mo!
Ang aming payo: gumamit ng hindi bababa sa quorum reading kapag gumagamit ng Causal consistency. Sa kasong ito, walang mawawala, kahit na nawala ang tala ng korum... Ito ay isang orthogonal na sitwasyon: kung ayaw ng user na mawala ang data, kailangan niyang gumamit ng quorum record. Ang pagkakapare-pareho ng sanhi ay hindi ginagarantiyahan ang tibay. Ang tibay ay ginagarantiyahan ng pagtitiklop at ng makinarya na nauugnay sa pagtitiklop.
SA: – Kapag lumikha kami ng isang instance na nagsasagawa ng sharding para sa amin (hindi master, ngunit alipin, ayon sa pagkakabanggit), umaasa ito sa oras ng Unix ng sarili nitong makina o sa oras ng "master"; Nagsi-sync ba ito sa unang pagkakataon o pana-panahon?
MT: - Lilinawin ko ngayon. Shard (i.e. horizontal partition) – palaging mayroong Primary doon. At ang isang shard ay maaaring magkaroon ng "master" at maaaring mayroong mga replika. Ngunit palaging sinusuportahan ng shard ang pag-record, dahil dapat itong suportahan ang ilang domain (may Pangunahin ang shard).
SA: - Kaya ang lahat ay nakasalalay lamang sa "master"? Lagi bang ginagamit ang master time?
MT: - Oo. Maaari mong matalinhagang sabihin: ang orasan ay ticking kapag ang isang entry sa "master", sa "Oplog" ay nangyayari.
SA: – Mayroon kaming kliyente na kumokonekta at hindi kailangang malaman ang anumang bagay tungkol sa oras?
MT: - Hindi mo kailangang malaman ang anumang bagay! Kung pag-uusapan natin kung paano ito gumagana sa kliyente: kapag gusto ng kliyente na gumamit ng Causal consistency, kailangan niyang magbukas ng session. Ngayon nandoon na ang lahat: mga transaksyon sa session, at kunin ang mga karapatan... Ang session ay ang pag-order ng mga lohikal na kaganapan na nagaganap sa kliyente.
Kung bubuksan niya ang session na ito at sasabihin doon na gusto niya ang Causal consistency (kung sinusuportahan ng session ang Causal consistency bilang default), lahat ay awtomatikong gagana. Naaalala ng driver ang oras na ito at dinadagdagan ito kapag nakatanggap ito ng bagong mensahe. Naaalala nito kung anong tugon ang ibinalik ng nauna mula sa server na nagbalik ng data. Ang susunod na kahilingan ay maglalaman ng afterCluster("oras na mas malaki kaysa dito").
Hindi kailangang malaman ng kliyente ang anumang bagay! Ito ay ganap na malabo sa kanya. Kung gagamitin ng mga tao ang mga feature na ito, ano ang magagawa nila? Una, maaari mong ligtas na basahin ang mga sekundarya: maaari kang sumulat sa Primary at magbasa mula sa heograpikal na replicated na mga sekundarya at siguraduhing gumagana ito. Kasabay nito, ang mga session na naitala sa Primary ay maaari pang ilipat sa Secondary, ibig sabihin, hindi ka maaaring gumamit ng isang session, ngunit marami.
SA: – Isang bagong layer ng Compute science – CRDT (Conflict-free Replicated Data Types) na mga uri ng data – ay mahigpit na nauugnay sa paksa ng Eventual consistency. Naisip mo na bang isama ang mga ganitong uri ng data sa database at ano ang masasabi mo tungkol dito?
MT: - Magandang tanong! Ang CRDT ay may katuturan para sa pagsusulat ng mga salungatan: sa MongoDB, nag-iisang master.
SA: – Mayroon akong tanong mula sa mga devops. Sa totoong mundo, may mga ganitong sitwasyon ng Jesuitical kapag nangyari ang Byzantine Failure, at ang mga masasamang tao sa loob ng protektadong perimeter ay nagsimulang sundutin ang protocol, magpadala ng mga pakete ng bapor sa isang espesyal na paraan?
MT: – Ang masasamang tao sa loob ng perimeter ay parang Trojan horse! Ang masasamang tao sa loob ng perimeter ay maaaring gumawa ng maraming masamang bagay.
SA: – Malinaw na ang pag-alis, sa halos pagsasalita, ng isang butas sa server kung saan maaari mong itulak ang isang zoo ng mga elepante at tiklupin ang buong kumpol magpakailanman. mali. Sa kabilang banda, ito ay kawili-wili: sa totoong buhay, sa pagsasagawa, may mga sitwasyon kung saan nangyayari ang mga natural na katulad na panloob na pag-atake?
MT: – Dahil bihira akong makatagpo ng mga paglabag sa seguridad sa totoong buhay, hindi ko masasabi kung mangyayari ang mga ito. Ngunit kung pinag-uusapan natin ang pilosopiya ng pag-unlad, ganito ang iniisip natin: mayroon tayong perimeter na nagbibigay ng mga taong gumagawa ng seguridad - ito ay isang kastilyo, isang pader; at sa loob ng perimeter maaari mong gawin ang anumang gusto mo. Malinaw na may mga user na may kakayahang tingnan lamang, at may mga user na may kakayahang burahin ang direktoryo.
Depende sa mga karapatan, ang pinsala na maaaring gawin ng mga gumagamit ay maaaring isang mouse, o maaari itong maging isang elepante. Ito ay malinaw na ang isang gumagamit na may ganap na mga karapatan ay maaaring gumawa ng kahit ano. Ang isang gumagamit na may limitadong mga karapatan ay maaaring magdulot ng mas kaunting pinsala. Sa partikular, hindi nito masisira ang sistema.
SA: – Sa protektadong perimeter, sinubukan ng isang tao na lumikha ng mga hindi inaasahang protocol para sa server upang ganap na sirain ang server, at kung ikaw ay mapalad, ang buong cluster... Nakakakuha ba ito ng ganoong "maganda"?
MT: "Hindi pa ako nakarinig ng mga ganoong bagay." Ang katotohanan na maaari kang mag-crash ng isang server sa ganitong paraan ay hindi lihim. Fail inside, being from the protocol, being an authorized user who can write something like this in the message... Sa katunayan, imposible, dahil mabe-verify pa rin ito. Posibleng hindi paganahin ang pagpapatunay na ito para sa mga user na ayaw nito - kung gayon iyon ang kanilang problema; sila, halos nagsasalita, ang mismong nagwasak ng mga pader at maaari mong itulak ang isang elepante doon, na yuyurakan... Ngunit sa pangkalahatan, maaari kang magbihis bilang isang repairman, halika at bunutin ito!
SA: – Salamat sa ulat. Sergey (Yandex). Mayroong pare-pareho sa Mong na naglilimita sa bilang ng mga miyembro ng pagboto sa Replica Set, at ang pare-parehong ito ay 7 (pito). Bakit ito ay isang pare-pareho? Bakit hindi ito isang uri ng parameter?
MT: – Mayroon kaming Replica Sets na may 40 node. Laging may mayorya. hindi ko alam kung anong version...
SA: – Sa Replica Set maaari kang magpatakbo ng mga miyembrong hindi bumoboto, ngunit mayroong maximum na 7 miyembro ng pagboto. Paano tayo makakaligtas sa pagsasara sa kasong ito kung ang ating Replica Set ay kumalat sa 3 data center? Madaling i-off ang isang data center, at maaaring mahulog ang isa pang makina.
MT: – Medyo lampas na ito sa saklaw ng ulat. Ito ay isang pangkalahatang tanong. Baka mamaya ko na lang ikwento.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com