Kongamano lijalo la HighLoad++ litafanyika tarehe 6 na 7 Aprili 2020 huko St. Petersburg.
Maelezo na tikiti . HighLoad ++ Siberia 2019. Ukumbi "Krasnoyarsk". Juni 25, 12:00. Hizi na .
Inatokea kwamba mahitaji ya vitendo yanapingana na nadharia, ambapo vipengele muhimu kwa bidhaa za kibiashara hazizingatiwi. Mazungumzo haya yanawasilisha mchakato wa kuchagua na kuchanganya mbinu tofauti za kuunda vipengele vya uthabiti wa Sababu kulingana na utafiti wa kitaaluma kulingana na mahitaji ya bidhaa ya kibiashara. Wasikilizaji watajifunza kuhusu mbinu zilizopo za kinadharia za saa za kimantiki, ufuatiliaji wa utegemezi, usalama wa mfumo, usawazishaji wa saa, na kwa nini MongoDB ilitatua masuluhisho fulani.
Mikhail Tyulenev (hapa anajulikana kama MT): - Nitazungumza kuhusu uthabiti wa Sababu - hiki ni kipengele tulichofanyia kazi katika MongoDB. Ninafanya kazi katika kikundi cha mifumo iliyosambazwa, tulifanya kama miaka miwili iliyopita.
Katika mchakato huo, ilibidi nijitambulishe na utafiti mwingi wa kitaaluma, kwa sababu kipengele hiki kimesomwa vizuri kabisa. Ilibadilika kuwa hakuna nakala moja inayolingana na kile kinachohitajika katika hifadhidata ya uzalishaji kwa sababu ya mahitaji maalum ambayo labda yapo katika programu yoyote ya uzalishaji.
Nitazungumza kuhusu jinsi sisi, kama watumiaji wa Utafiti wa kitaaluma, tunatayarisha kitu kutoka humo ambacho tunaweza kuwasilisha kwa watumiaji wetu kama sahani iliyo tayari ambayo ni rahisi na salama kutumia.
Uthabiti wa sababu. Hebu tufafanue dhana
Kuanza, nataka kusema kwa jumla ni nini uthabiti wa Sababu. Kuna wahusika wawili - Leonard na Penny (mfululizo wa TV "The Big Bang Theory"):
Wacha tuseme Penny yuko Ulaya na Leonard anataka kumfanyia karamu ya kushtukiza. Na hawezi kufikiria chochote bora zaidi kuliko kumtupa nje ya orodha ya marafiki zake, akiwatumia marafiki zake wote sasisho kwenye malisho: "Hebu tufurahishe Penny!" (yuko Uropa, wakati analala, haoni haya yote na haoni, kwa sababu hayupo). Hatimaye, yeye hufuta chapisho hili, huifuta kutoka kwa Milisho na kurejesha ufikiaji ili asitambue chochote na hakuna kashfa.
Hii yote ni sawa na nzuri, lakini wacha tuchukue kuwa mfumo unasambazwa na mambo yalikwenda vibaya. Inaweza, kwa mfano, kutokea kwamba kizuizi cha ufikiaji cha Penny kilitokea baada ya chapisho hili kuonekana, ikiwa matukio hayahusiani na sababu na athari. Kwa kweli, hii ni mfano wa wakati uthabiti wa Causal unahitajika ili kufanya kazi ya biashara (katika kesi hii).
Kwa kweli, hizi ni mali zisizo za kawaida za hifadhidata - watu wachache sana wanawaunga mkono. Wacha tuendelee kwenye mifano.
Mifano ya Uthabiti
Ni nini hasa mfano wa uthabiti katika hifadhidata? Hizi ni baadhi ya hakikisho ambazo mfumo uliosambazwa hutoa kuhusu data ambayo mteja anaweza kupokea na kwa mlolongo upi.
Kimsingi, mifano yote ya uthabiti inakuja kwa jinsi mfumo uliosambazwa unavyofanana na mfumo unaoendesha, kwa mfano, kwenye nodi moja kwenye kompyuta ndogo. Na hivi ndivyo mfumo unaofanana na maelfu ya "Node" zilizosambazwa kijiografia kwa kompyuta ndogo, ambayo mali hizi zote hufanywa kiatomati kwa kanuni.
Kwa hiyo, mifano ya uthabiti hutumiwa tu kwa mifumo iliyosambazwa. Mifumo yote ambayo ilikuwepo hapo awali na kufanya kazi kwa kiwango sawa cha wima haikupata shida kama hizo. Kulikuwa na Buffer Cache moja, na kila kitu kilisomwa kutoka humo kila mara.
Mfano Nguvu
Kweli, mfano wa kwanza kabisa ni Nguvu (au mstari wa uwezo wa kupanda, kama unavyoitwa mara nyingi). Huu ni mfano wa uthabiti ambao unahakikisha kwamba kila mabadiliko, mara moja yamethibitishwa kuwa yametokea, yanaonekana kwa watumiaji wote wa mfumo.
Hii inaunda mpangilio wa kimataifa wa matukio yote kwenye hifadhidata. Hii ni mali ya uthabiti yenye nguvu sana, na kwa ujumla ni ghali sana. Hata hivyo, inaungwa mkono vizuri sana. Ni ghali sana na polepole - hutumiwa tu mara chache. Hii inaitwa uwezo wa kupanda.
Kuna mali nyingine, yenye nguvu zaidi ambayo inaungwa mkono katika Spanner - inayoitwa Uthabiti wa Nje. Tutazungumza juu yake baadaye kidogo.
Sababu
Inayofuata ni Causal, ambayo ndio hasa nilikuwa nikizungumza. Kuna viwango vidogo zaidi kati ya Nguvu na Sababu ambavyo sitavizungumza, lakini vyote vinapungua hadi Causal. Huu ni mfano muhimu kwa sababu ni nguvu zaidi ya mifano yote, uthabiti wenye nguvu zaidi mbele ya mtandao au partitions.
Sababu kwa kweli ni hali ambayo matukio yanaunganishwa na uhusiano wa sababu-na-athari. Mara nyingi hutambuliwa kama Soma haki zako kutoka kwa maoni ya mteja. Ikiwa mteja amezingatia maadili fulani, hawezi kuona maadili ambayo yalikuwa hapo awali. Tayari ameanza kuona usomaji wa viambishi awali. Yote inakuja kwa kitu kimoja.
Sababu kama modeli ya uthabiti ni mpangilio wa sehemu ya matukio kwenye seva, ambayo matukio kutoka kwa wateja wote huzingatiwa kwa mlolongo sawa. Katika kesi hii, Leonard na Penny.
Mwishowe
Mfano wa tatu ni Uthabiti wa Mwisho. Hivi ndivyo mifumo yote iliyosambazwa inasaidia, mfano mdogo ambao una maana kabisa. Inamaanisha yafuatayo: tunapokuwa na mabadiliko fulani katika data, wakati fulani huwa sawa.
Kwa wakati kama huo hasemi chochote, vinginevyo angegeuka kuwa Uthabiti wa Nje - itakuwa hadithi tofauti kabisa. Walakini, hii ni mfano maarufu sana, wa kawaida zaidi. Kwa chaguo-msingi, watumiaji wote wa mifumo iliyosambazwa hutumia Uthabiti wa Hatimaye.
Nataka kutoa mifano ya kulinganisha:
Je, mishale hii ina maana gani?
- Kuchelewa. Nguvu ya uthabiti inapoongezeka, inakuwa kubwa kwa sababu za wazi: unahitaji kufanya rekodi zaidi, kupata uthibitisho kutoka kwa majeshi na nodi zote zinazoshiriki kwenye nguzo kwamba data tayari iko. Ipasavyo, Uthabiti wa Mwisho una jibu la haraka sana, kwa sababu huko, kama sheria, unaweza hata kuiweka kwenye kumbukumbu na hii, kimsingi, itatosha.
- Upatikanaji. Ikiwa tunaelewa hii kama uwezo wa mfumo kujibu mbele ya mapumziko ya mtandao, sehemu, au aina fulani ya kutofaulu, uvumilivu wa makosa huongezeka kadiri mtindo wa uthabiti unavyopungua, kwani inatosha kwetu kwamba mwenyeji mmoja anaishi na wakati huo huo. wakati hutoa data fulani. Uthabiti wa Hatima hauhakikishi chochote kuhusu data hata kidogo - inaweza kuwa chochote.
- Makosa. Wakati huo huo, bila shaka, idadi ya anomalies huongezeka. Katika Uthabiti Nguvu karibu hawapaswi kuwepo kabisa, lakini katika Uthabiti wa Hatimaye wanaweza kuwa chochote. Swali linatokea: kwa nini watu huchagua Uthabiti wa Hatimaye ikiwa ina hitilafu? Jibu ni kwamba mifano ya Uthabiti wa Hatimaye inatumika na hitilafu zipo, kwa mfano, katika muda mfupi; inawezekana kutumia mchawi kusoma na zaidi au chini ya kusoma data thabiti; Mara nyingi inawezekana kutumia mifano kali ya uthabiti. Katika mazoezi hii inafanya kazi, na mara nyingi idadi ya makosa ni mdogo kwa wakati.
Nadharia ya CAP
Unapoona maneno uthabiti, upatikanaji - nini kinakuja akilini mwako? Hiyo ni kweli - nadharia ya CAP! Sasa nataka kufuta hadithi ... Sio mimi - ni Martin Kleppmann, ambaye aliandika makala ya ajabu, kitabu cha ajabu.
Nadharia ya CAP ni kanuni iliyotungwa katika miaka ya 2000 kwamba Uthabiti, Upatikanaji, Sehemu: chukua mbili zozote, na huwezi kuchagua tatu. Ilikuwa kanuni fulani. Ilithibitishwa kama nadharia miaka michache baadaye na Gilbert na Lynch. Kisha hii ilianza kutumika kama mantra - mifumo ilianza kugawanywa katika CA, CP, AP na kadhalika.
Nadharia hii kwa hakika ilithibitishwa kwa visa vifuatavyo... Kwanza, Upatikanaji haukuzingatiwa kama thamani inayoendelea kutoka sifuri hadi mamia (0 - mfumo "umekufa", 100 - hujibu haraka; tumezoea kuzingatia hivyo) , lakini kama mali ya algorithm , ambayo inahakikisha kwamba kwa utekelezaji wake wote inarudisha data.
Hakuna neno kuhusu wakati wa kujibu hata kidogo! Kuna algorithm ambayo inarudisha data baada ya miaka 100 - algorithm ya ajabu kabisa inayopatikana, ambayo ni sehemu ya theorem ya CAP.
Pili: theorem ilithibitishwa kwa mabadiliko katika maadili ya ufunguo huo huo, licha ya ukweli kwamba mabadiliko haya yanaweza kubadilishwa tena. Hii ina maana kwamba katika hali halisi hazitumiki, kwa sababu mifano ni tofauti ya Uthabiti wa Mwisho, Uthabiti Nguvu (labda).
Haya yote ni ya nini? Kwa kuongezea, nadharia ya CAP katika fomu ambayo ilithibitishwa haitumiki na haitumiki sana. Kwa fomu ya kinadharia, kwa namna fulani hupunguza kila kitu. Inageuka kanuni fulani ambayo ni intuitively sahihi, lakini kwa ujumla haijathibitishwa.
Uthabiti wa sababu ni mfano wa nguvu zaidi
Kinachofanyika sasa ni kwamba unaweza kupata vitu vyote vitatu: Uthabiti, Upatikanaji kwa kutumia Sehemu. Hasa, uthabiti wa Causal ni mfano wa uthabiti wenye nguvu zaidi, ambao bado unafanya kazi mbele ya Partitions (mapumziko kwenye mtandao). Ndiyo maana inapendeza sana, na ndiyo maana tukaichukua.
Kwanza, hurahisisha kazi ya watengenezaji wa programu. Hasa, uwepo wa usaidizi mkubwa kutoka kwa seva: wakati rekodi zote zinazotokea ndani ya mteja mmoja zimehakikishiwa kufika kwa mlolongo sawa kwa mteja mwingine. Pili, ni kuhimili partitions.
Jiko la Ndani la MongoDB
Kukumbuka kuwa ni chakula cha mchana, tunahamia jikoni. Nitakuambia juu ya mfano wa mfumo, yaani, MongoDB ni nini kwa wale ambao wanasikia juu ya hifadhidata kama hiyo kwa mara ya kwanza.
MongoDB (hapa inajulikana kama "MongoDB") ni mfumo uliosambazwa ambao unaauni upanuzi wa mlalo, yaani, kugawa; na ndani ya kila shard pia inasaidia upunguzaji wa data, yaani, urudufishaji.
Sharding katika MongoDB (sio hifadhidata ya uhusiano) hufanya kusawazisha kiotomatiki, ambayo ni, kila mkusanyiko wa hati (au "meza" kwa suala la data ya uhusiano) imegawanywa vipande vipande, na seva huwahamisha moja kwa moja kati ya shards.
Njia ya Maswali, ambayo inasambaza maombi, kwa mteja ni mteja fulani ambayo inafanya kazi. Tayari inajua wapi na ni data gani iko na inaelekeza maombi yote kwa shard sahihi.
Jambo lingine muhimu: MongoDB ni bwana mmoja. Kuna Msingi mmoja - inaweza kuchukua rekodi zinazotumia funguo zilizomo. Huwezi kufanya uandishi wa Multi-master.
Tulifanya toleo 4.2 - vitu vipya vya kupendeza vilionekana hapo. Hasa, waliingiza Lucene - tafuta - ambayo ni java inayoweza kutekelezwa moja kwa moja kwenye Mongo, na hapo ikawa inawezekana kufanya utafutaji kupitia Lucene, sawa na katika Elastica.
Na walitengeneza bidhaa mpya - Chati, inapatikana pia kwenye Atlas (Wingu la Mongo mwenyewe). Wana Kiwango cha Bure - unaweza kucheza nacho. Nilipenda sana Chati - taswira ya data, angavu sana.
Viungo Uthabiti wa sababu
Nilihesabu nakala 230 ambazo zimechapishwa juu ya mada hii - kutoka kwa Leslie Lampert. Sasa kutoka kwa kumbukumbu yangu nitawasilisha kwako baadhi ya sehemu za nyenzo hizi.
Yote ilianza na makala ya Leslie Lampert, ambayo iliandikwa katika miaka ya 1970. Kama unaweza kuona, baadhi ya utafiti juu ya mada hii bado unaendelea. Sasa uthabiti wa Causal unakabiliwa na riba kuhusiana na maendeleo ya mifumo iliyosambazwa.
Vikwazo
Kuna vikwazo gani? Hii ni kweli mojawapo ya pointi kuu, kwa sababu vikwazo ambavyo mfumo wa uzalishaji huweka ni tofauti sana na vikwazo vilivyopo katika makala za kitaaluma. Mara nyingi ni bandia kabisa.
- Kwanza, "MongoDB" ni bwana mmoja, kama nilivyokwisha sema (hii hurahisisha sana).
- Tunaamini kwamba mfumo unapaswa kuunga mkono takriban shards elfu 10. Hatuwezi kufanya maamuzi yoyote ya usanifu ambayo yataweka kikomo thamani hii.
- Tuna wingu, lakini tunadhani kwamba mtu bado anapaswa kuwa na fursa wakati anapakua binary, anaendesha kwenye kompyuta yake ya mkononi, na kila kitu kinafanya kazi vizuri.
- Tunadhania kitu ambacho Utafiti haufikirii mara chache: wateja wa nje wanaweza kufanya chochote wanachotaka. MongoDB ni chanzo wazi. Ipasavyo, wateja wanaweza kuwa na busara na hasira - wanaweza kutaka kuvunja kila kitu. Tunakisia kwamba Feilors za Byzantine zinaweza kutokea.
- Kwa wateja wa nje walio nje ya mzunguko, kuna kizuizi muhimu: ikiwa kipengele hiki kimezimwa, basi hakuna uharibifu wa utendaji unapaswa kuzingatiwa.
- Jambo lingine kwa ujumla ni dhidi ya kitaaluma: utangamano wa matoleo ya awali na yajayo. Viendeshi vya zamani lazima visaidie masasisho mapya, na hifadhidata lazima iunge mkono viendeshi vya zamani.
Kwa ujumla, hii yote inaweka vikwazo.
Vipengele vya uthabiti wa sababu
Sasa nitazungumza juu ya baadhi ya vipengele. Ikiwa tunazingatia uwiano wa Causal kwa ujumla, tunaweza kuchagua vitalu. Tulichagua kutoka kwa kazi ambazo ni za kizuizi fulani: Ufuatiliaji wa Utegemezi, kuchagua saa, jinsi saa hizi zinaweza kusawazishwa na kila mmoja, na jinsi tunavyohakikisha usalama - huu ni muhtasari mbaya wa kile nitazungumza juu yake:
Ufuatiliaji Kamili wa Utegemezi
Kwa nini inahitajika? Ili data inaporudiwa, kila rekodi, kila mabadiliko ya data huwa na habari kuhusu mabadiliko yanayotegemea. Badiliko la kwanza kabisa na la ujinga ni wakati kila ujumbe ulio na rekodi una taarifa kuhusu jumbe za awali:
Katika mfano huu, nambari katika mabano ya curly ni nambari za rekodi. Wakati mwingine rekodi hizi zilizo na maadili huhamishwa hata kwa ukamilifu, wakati mwingine matoleo kadhaa huhamishwa. Jambo la msingi ni kwamba kila badiliko lina habari kuhusu ile iliyotangulia (kwa wazi hubeba haya yote ndani yake).
Kwa nini tuliamua kutotumia njia hii (ufuatiliaji kamili)? Kwa wazi, kwa sababu njia hii haiwezekani: mabadiliko yoyote kwenye mtandao wa kijamii inategemea mabadiliko yote ya awali kwenye mtandao huo wa kijamii, kuhamisha, kusema, Facebook au VKontakte katika kila sasisho. Walakini, kuna utafiti mwingi juu ya Ufuatiliaji Kamili wa Utegemezi - hii ni mitandao ya kijamii ya mapema; kwa hali zingine inafanya kazi kweli.
Ufuatiliaji wa Utegemezi wa Dhahiri
Inayofuata ni mdogo zaidi. Uhamisho wa habari pia unazingatiwa hapa, lakini tu ambayo inategemea wazi. Inategemea nini, kama sheria, imedhamiriwa na Maombi. Data inaporudiwa, swala hurejesha majibu tu wakati utegemezi wa awali umeridhika, yaani, umeonyeshwa. Hiki ndicho kiini cha jinsi uthabiti wa Causal unavyofanya kazi.
Anaona kwamba rekodi 5 inategemea rekodi 1, 2, 3, 4 - ipasavyo, anasubiri kabla ya mteja kupata mabadiliko yaliyofanywa na uamuzi wa upatikanaji wa Penny, wakati mabadiliko yote ya awali tayari yamepitia hifadhidata.
Hii haifai sisi pia, kwa sababu bado kuna habari nyingi, na itapunguza mambo. Kuna mbinu nyingine...
Saa ya Lamport
Ni wazee sana. Saa ya Lamport inamaanisha kuwa tegemezi hizi zimekunjwa kuwa kazi ya scalar, inayoitwa Saa ya Lamport.
Kitendaji cha scalar ni nambari fulani isiyoeleweka. Mara nyingi huitwa wakati wa mantiki. Kwa kila tukio, counter hii huongezeka. Counter, ambayo kwa sasa inajulikana kwa mchakato, hutuma kila ujumbe. Ni wazi kwamba michakato inaweza kuwa nje ya usawazishaji, inaweza kuwa na nyakati tofauti kabisa. Hata hivyo, mfumo kwa namna fulani husawazisha saa na ujumbe kama huo. Nini kinatokea katika kesi hii?
Niligawanya kipande hicho kikubwa mara mbili ili kuifanya iwe wazi: Marafiki wanaweza kuishi katika nodi moja, ambayo ina kipande cha mkusanyiko, na Feed inaweza kuishi katika nodi nyingine, ambayo ina kipande cha mkusanyiko huu. Je, ni wazi jinsi wanaweza kutoka nje ya mstari? Mlisho wa Kwanza utasema: "Imerudiwa", na kisha Marafiki. Ikiwa mfumo hautoi dhamana ya aina fulani kwamba Mlisho hautaonyeshwa hadi utegemezi wa Marafiki katika mkusanyiko wa Marafiki pia utolewe, basi tutakuwa na hali ile niliyotaja.
Unaona jinsi muda wa kaunta kwenye Mipasho unavyoongezeka kimantiki:
Kwa hivyo mali kuu ya Saa hii ya Lamport na uthabiti wa Sababu (iliyoelezewa kupitia Saa ya Lamport) ni hii: ikiwa tunayo Matukio A na B, na Tukio B inategemea Tukio A *, basi inafuata kwamba Muda wa Mantiki wa Tukio A ni chini ya Muda wa Mantiki kutoka kwa Tukio B.
* Wakati mwingine pia wanasema kwamba A ilitokea kabla ya B, ambayo ni, A ilitokea kabla ya B - huu ni uhusiano fulani ambao huamuru kwa sehemu seti nzima ya matukio ambayo yalitokea kwa ujumla.
Kinyume chake si sahihi. Hii ni kweli moja ya hasara kuu za Lamport Clock - utaratibu wa sehemu. Kuna dhana kuhusu matukio ya wakati mmoja, yaani, matukio ambayo (A ilitokea kabla ya B) au (A ilifanyika kabla ya B). Mfano unaweza kuwa nyongeza ya Leonard ya mtu mwingine kama rafiki (hata Leonard, lakini Sheldon, kwa mfano).
Hii ndiyo mali ambayo hutumiwa mara nyingi wakati wa kufanya kazi na saa za Lamport: wanaangalia hasa kazi na kutoka kwa hili wanahitimisha kuwa labda matukio haya yanategemea. Kwa sababu njia moja ni kweli: ikiwa LogicalTime A ni chini ya LogicalTime B, basi B haiwezi kutokea kabla ya A; na ikiwa zaidi, basi labda.
Saa ya Vector
Ukuzaji wa kimantiki wa saa ya Lamport ni Saa ya Vector. Zinatofautiana kwa kuwa kila nodi iliyo hapa ina saa yake tofauti, na hupitishwa kama vekta.
Katika kesi hii, unaona kwamba index ya sifuri ya vector inawajibika kwa Kulisha, na index ya kwanza ya vector ni kwa Marafiki (kila moja ya nodes hizi). Na sasa wataongezeka: index ya sifuri ya "Kulisha" inaongezeka wakati wa kuandika - 1, 2, 3:
Kwa nini Saa ya Vector ni bora? Kwa sababu hukuruhusu kujua ni matukio gani yanayotokea wakati huo huo na yanapotokea kwenye nodi tofauti. Hii ni muhimu sana kwa mfumo wa kugawanyika kama MongoDB. Walakini, hatukuchagua hii, ingawa ni jambo la kushangaza, na inafanya kazi vizuri, na labda ingetufaa ...
Ikiwa tuna shards elfu 10, hatuwezi kuhamisha vipengele elfu 10, hata ikiwa tutaikandamiza au kuja na kitu kingine - mzigo wa malipo bado utakuwa mdogo mara kadhaa kuliko kiasi cha vector hii yote. Kwa hivyo, tukiuma mioyo na meno yetu, tuliacha njia hii na tukahamia nyingine.
Spanner TrueTime. Saa ya atomiki
Nilisema kutakuwa na hadithi kuhusu Spanner. Hili ni jambo zuri, moja kwa moja la karne ya XNUMX: saa za atomiki, maingiliano ya GPS.
Wazo ni nini? "Spanner" ni mfumo wa Google ambao hivi karibuni ulipatikana kwa watu (waliongeza SQL kwake). Kila muamala kuna muhuri wa muda. Kwa kuwa wakati umesawazishwa*, kila tukio linaweza kugawiwa wakati maalum - saa za atomiki zina wakati wa kungojea, baada ya hapo wakati tofauti "kutokea".
Kwa hivyo, kwa kuandika tu kwa hifadhidata na kungojea kwa muda fulani, Udhibiti wa tukio unahakikishwa kiatomati. Wana mfano wa Uthabiti wenye nguvu zaidi ambao unaweza kufikiria kwa kanuni - ni Uthabiti wa Nje.
* Hili ndilo tatizo kuu la saa za Lampart - hazifananishwi kwenye mifumo iliyosambazwa. Wanaweza kutofautiana; hata kwa NTP, bado hawafanyi kazi vizuri. "Spanner" ina saa ya atomiki na maingiliano, inaonekana, ni microseconds.
Kwa nini hatukuchagua? Hatuchukui kuwa watumiaji wetu wana saa ya atomiki iliyojengewa ndani. Zinapoonekana, zikijengwa ndani ya kila kompyuta ndogo, kutakuwa na aina fulani ya upatanishi wa GPS wa hali ya juu sana - basi ndio... Lakini kwa sasa bora zaidi inayowezekana ni Amazon, Vituo vya Msingi - kwa washabiki... Kwa hivyo tulitumia saa zingine. .
Saa ya Mseto
Kwa kweli hii ndio inayoonekana katika MongoDB wakati wa kuhakikisha uthabiti wa Causal. Je, wao ni mseto? Mseto ni thamani ya scalar, lakini ina vipengele viwili:
- Ya kwanza ni enzi ya Unix (sekunde ngapi zimepita tangu "mwanzo wa ulimwengu wa kompyuta").
- Ya pili ni nyongeza, pia int 32-bit ambayo haijasainiwa.
Hiyo ndiyo yote, kwa kweli. Kuna njia hii: sehemu inayohusika na wakati inasawazishwa na saa kila wakati; kila wakati sasisho linapotokea, sehemu hii inasawazishwa na saa na inabadilika kuwa wakati huwa sahihi zaidi au kidogo, na ongezeko hukuruhusu kutofautisha kati ya matukio yaliyotokea kwa wakati mmoja.
Kwa nini hii ni muhimu kwa MongoDB? Kwa sababu hukuruhusu kutengeneza aina fulani ya mikahawa ya chelezo kwa wakati fulani, yaani, tukio linaorodheshwa kulingana na wakati. Hii ni muhimu wakati matukio fulani yanahitajika; Kwa hifadhidata, matukio ni mabadiliko katika hifadhidata ambayo yalitokea kwa vipindi fulani kwa wakati.
Nitakuambia sababu muhimu zaidi kwako tu (tafadhali, usiambie mtu yeyote)! Tulifanya hivi kwa sababu hii ndio iliyopangwa, data iliyoorodheshwa inaonekana kama katika MongoDB OpLog. OpLog ni muundo wa data ambao una mabadiliko yote kwenye hifadhidata: kwanza huenda kwa OpLog, na kisha hutumiwa kwa Uhifadhi yenyewe katika kesi wakati ni tarehe iliyorudiwa au shard.
Hii ilikuwa sababu kuu. Bado, kuna mahitaji ya vitendo ya kuunda hifadhidata, ambayo inamaanisha kwamba inapaswa kuwa rahisi - nambari ndogo, vitu vichache vilivyovunjika iwezekanavyo ambavyo vinahitaji kuandikwa upya na kujaribiwa. Ukweli kwamba ologs zetu zilionyeshwa na saa za mseto zilisaidia sana na kuturuhusu kufanya chaguo sahihi. Ililipa sana na kwa njia fulani ilifanya kazi kwa uchawi kwenye mfano wa kwanza kabisa. Ilikuwa poa sana!
Usawazishaji wa saa
Kuna njia kadhaa za maingiliano zilizoelezewa katika fasihi ya kisayansi. Ninazungumza juu ya maingiliano wakati tuna shards mbili tofauti. Ikiwa kuna seti moja ya replica, hakuna haja ya maingiliano yoyote: hii ni "bwana mmoja"; tunayo OpLog, ambayo mabadiliko yote huanguka - katika kesi hii, kila kitu tayari kimeamriwa kwa mpangilio katika "Oplog" yenyewe. Lakini ikiwa tuna shards mbili tofauti, usawazishaji wa wakati ni muhimu hapa. Hapa ndipo saa ya vekta ilisaidia zaidi! Lakini hatuna.
Ya pili inafaa - hii ni "Mapigo ya Moyo". Inawezekana kubadilishana baadhi ya ishara zinazotokea kila kitengo cha wakati. Lakini Mapigo ya Moyo ni ya polepole sana, hatuwezi kutoa muda wa kusubiri kwa mteja wetu.
Wakati wa kweli, bila shaka, ni jambo la ajabu. Lakini, tena, hii labda ni siku zijazo ... Ingawa inaweza tayari kufanywa katika Atlas, tayari kuna maingiliano ya haraka ya "Amazon". Lakini haitapatikana kwa kila mtu.
Kusengenya ni wakati ujumbe wote unajumuisha wakati. Hii ni takriban kile tunachotumia. Kila ujumbe kati ya nodi, kiendeshi, kipanga njia cha nodi ya data, kila kitu kwa MongoDB ni aina fulani ya kipengele, sehemu ya hifadhidata ambayo ina saa inayoendesha. Wana maana ya wakati wa mseto kila mahali, hupitishwa. Biti 64? Hii inaruhusu, hii inawezekana.
Yote hufanyaje kazi pamoja?
Hapa ninaangalia seti moja ya nakala ili kuifanya iwe rahisi kidogo. Kuna Shule ya Msingi na Sekondari. Sekondari hufanya urudufishaji na si mara zote husawazishwa kabisa na Msingi.
Uingizaji hutokea kwenye "Primery" kwa thamani fulani ya wakati. Ingizo hili huongeza hesabu ya ndani kwa 11, ikiwa hiki ndicho cha juu zaidi. Au itaangalia maadili ya saa na kusawazisha kwa saa ikiwa maadili ya saa ni makubwa zaidi. Hii inakuwezesha kupanga kwa wakati.
Baada ya kufanya rekodi, wakati muhimu hutokea. Saa iko kwenye "MongoDB" na inaongezwa tu ikiwa itaandikwa kwa "Oplog". Hili ni tukio ambalo linabadilisha hali ya mfumo. Katika nakala zote za kawaida, tukio linachukuliwa kuwa wakati ujumbe unapiga node: ujumbe umefika, ambayo inamaanisha kuwa mfumo umebadilisha hali yake.
Hii ni kutokana na ukweli kwamba wakati wa utafiti haijulikani kabisa jinsi ujumbe huu utakavyotafsiriwa. Tunajua kwa hakika kwamba ikiwa haijaonyeshwa kwenye "Oplog", basi haitatafsiriwa kwa njia yoyote, na mabadiliko katika hali ya mfumo ni kuingia tu kwenye "Oplog". Hii hurahisisha kila kitu kwetu: mfano hurahisisha, na huturuhusu kuipanga ndani ya seti moja ya nakala, na vitu vingine vingi muhimu.
Thamani ambayo tayari imeandikwa kwa "Oplog" imerejeshwa - tunajua kwamba "Oplog" tayari ina thamani hii, na wakati wake ni 12. Sasa, sema, kusoma huanza kutoka nodi nyingine (Sekondari), na inasambaza afterClusterTime katika ujumbe. Anasema: "Ninahitaji kila kitu kilichotokea angalau baada ya 12 au wakati wa kumi na mbili" (tazama picha hapo juu).
Hii ndio inaitwa Causal a consistent (CAT). Kuna dhana kama hii katika nadharia kwamba hii ni kipande cha wakati, ambayo ni thabiti yenyewe. Katika kesi hii, tunaweza kusema kwamba hii ndio hali ya mfumo ambayo ilizingatiwa wakati wa 12.
Sasa hakuna kitu hapa bado, kwa sababu aina hii ya kuiga hali wakati unahitaji Sekondari kuiga data kutoka kwa Msingi. Anangoja ... Na sasa data imefika - anarudisha maadili haya.
Hiyo ni jinsi yote inavyofanya kazi. Karibu.
Je, "karibu" inamaanisha nini? Wacha tuchukue kuwa kuna mtu ambaye amesoma na kuelewa jinsi hii yote inavyofanya kazi. Niligundua kuwa kila wakati ClusterTime inapotokea, inasasisha saa ya ndani ya mantiki, na kisha ingizo linalofuata linaongezeka kwa moja. Kazi hii inachukua mistari 20. Wacha tuseme mtu huyu anasambaza nambari kubwa zaidi ya 64, toa moja.
Kwa nini "ondoa moja"? Kwa sababu saa ya ndani itabadilishwa kuwa thamani hii (ni wazi, hii ndiyo kubwa zaidi na kubwa kuliko wakati wa sasa), basi ingizo litatokea katika "Oplog", na saa itaongezwa na kitengo kingine - na tayari kuwa na dhamana ya juu (kuna vitengo vyote tu, hakuna mahali pengine pa kwenda) , ints zisizofaa).
Ni wazi kwamba baada ya hii mfumo unakuwa hauwezekani kabisa kwa chochote. Inaweza tu kupakuliwa na kusafishwa - kazi nyingi za mwongozo. Upatikanaji kamili:
Kwa kuongezea, ikiwa hii inaigwa mahali pengine, basi nguzo nzima huanguka chini. Hali isiyokubalika kabisa ambayo mtu yeyote anaweza kuandaa haraka sana na kwa urahisi! Kwa hivyo, tulizingatia wakati huu kama moja ya muhimu zaidi. Jinsi ya kuizuia?
Njia yetu ni kusaini clusterTime
Hivi ndivyo inavyopitishwa katika ujumbe (kabla ya maandishi ya bluu). Lakini pia tulianza kutoa saini (maandishi ya bluu):
Sahihi inatolewa na ufunguo ambao umehifadhiwa ndani ya hifadhidata, ndani ya eneo salama; yenyewe inazalishwa na kusasishwa (watumiaji hawaoni chochote kuhusu hilo). Heshi huzalishwa, na kila ujumbe hutiwa saini unapoundwa na kuthibitishwa unapopokelewa.
Swali pengine linatokea katika akili za watu: "Hii inapunguza kasi kiasi gani?" Nilikuambia kwamba inapaswa kufanya kazi haraka, hasa kwa kutokuwepo kwa kipengele hiki.
Inamaanisha nini kutumia uthabiti wa Causal katika kesi hii? Hii ni kuonyesha parameta ya afterClusterTime. Bila hii, itapitisha maadili hata hivyo. Kusengenya, kuanzia toleo la 3.6, hufanya kazi kila wakati.
Ikiwa tutaacha kizazi cha mara kwa mara cha saini, itapunguza kasi ya mfumo hata kwa kutokuwepo kwa kipengele, ambacho hakikidhi mbinu na mahitaji yetu. Kwa hiyo tulifanya nini?
Fanya haraka!
Ni jambo rahisi sana, lakini hila ni ya kuvutia - nitashiriki, labda mtu atapendezwa.
Tuna heshi inayohifadhi data iliyosainiwa. Data zote hupitia kache. Cache haisaini wakati maalum, lakini Masafa. Thamani fulani inapofika, tunatoa Masafa, kuficha biti 16 za mwisho, na tunatia sahihi thamani hii:
Kwa kupokea saini kama hiyo, tunaharakisha mfumo (kiasi) mara 65. Inafanya kazi vizuri: tulipofanya majaribio, wakati ulipungua kwa mara elfu 10 tulipokuwa na sasisho la mfululizo. Ni wazi kwamba wanapotofautiana, hii haifanyi kazi. Lakini katika hali nyingi za vitendo hufanya kazi. Mchanganyiko wa sahihi ya Masafa pamoja na sahihi ulisuluhisha tatizo la usalama.
Tumejifunza nini?
Mafunzo tuliyopata kutokana na hili:
- Tunahitaji kusoma nyenzo, hadithi, makala, kwa sababu tuna mambo mengi ya kuvutia. Tunapofanyia kazi kipengele fulani (hasa sasa, tulipofanya miamala, n.k.), tunahitaji kusoma na kuelewa. Inachukua muda, lakini ni muhimu sana kwa sababu inaweka wazi tulipo. Hatukuonekana kuja na kitu chochote kipya - tulichukua viungo.
Kwa ujumla, kuna tofauti fulani katika kufikiri wakati kuna mkutano wa kitaaluma (Sigmon, kwa mfano) - kila mtu anazingatia mawazo mapya. Ni nini kipya kuhusu algorithm yetu? Hakuna kitu kipya hasa hapa. Upya badala yake unatokana na jinsi tulivyochanganya mbinu zilizopo pamoja. Kwa hiyo, jambo la kwanza ni kusoma classics, kuanzia na Lampart.
- Katika uzalishaji, mahitaji ni tofauti kabisa. Nina hakika kwamba wengi wenu hawakabiliwi na hifadhidata za "spherical" katika utupu wa kawaida, lakini kwa mambo ya kawaida, halisi ambayo yana matatizo na upatikanaji, latency na uvumilivu wa makosa.
- Jambo la mwisho ni kwamba tulipaswa kuangalia mawazo tofauti na kuchanganya makala kadhaa tofauti kabisa katika mbinu moja, pamoja. Wazo la kusaini, kwa mfano, kwa ujumla lilitoka kwa nakala iliyozingatia itifaki ya Paxos, ambayo kwa Washindwa wasio wa Byzantine iko ndani ya itifaki ya idhini, kwa wale wa Byzantine - nje ya itifaki ya idhini ... Kwa ujumla, hii ndio hasa aliishia kufanya.
Hakuna jipya kabisa hapa! Lakini mara tu tulipochanganya yote pamoja ... Ni sawa na kusema kwamba kichocheo cha saladi ya Olivier ni upuuzi, kwa sababu mayai, mayonnaise na matango tayari yamezuliwa ... Ni kuhusu hadithi sawa.
Nitamaliza na hili. Asante!
maswali
Swali kutoka kwa hadhira (hapa inajulikana kama B): - Asante, Mikhail, kwa ripoti! Mada kuhusu wakati ni ya kuvutia. Unatumia Umbea. Walisema kwamba kila mtu ana wakati wake, kila mtu anajua wakati wake wa ndani. Kama ninavyoelewa, tuna dereva - kunaweza kuwa na wateja wengi na madereva, wapangaji wa maswali pia, shards pia ... Na mfumo unakuja nini ikiwa tuna tofauti ghafla: mtu anaamua kuwa ni kwa dakika mbele, kuna mtu nyuma kwa dakika? Tutaishia wapi?
MT: - Swali kubwa kweli! Nilitaka tu kuzungumza juu ya vijiti. Ikiwa ninaelewa swali kwa usahihi, tuna hali ifuatayo: kuna shard 1 na shard 2, kusoma hutokea kutoka kwa shards hizi mbili - zina tofauti, haziingiliani na kila mmoja, kwa sababu wakati wanaojua ni tofauti, hasa wakati ambao zipo katika logi.
Hebu tuseme kwamba shard 1 ilifanya rekodi milioni, shard 2 haikufanya chochote, na ombi lilikuja kwa shards mbili. Na ya kwanza ina afterClusterTime ya zaidi ya milioni moja. Katika hali kama hii, kama nilivyoelezea, shard 2 haitajibu kamwe.
Katika: - Nilitaka kujua jinsi wanavyosawazisha na kuchagua wakati mmoja wa kimantiki?
MT: - Rahisi sana kusawazisha. Shard, afterClusterTime inapomjia na asipate muda katika "Oplog", huanzisha hakuna kibali. Hiyo ni, anainua wakati wake kwa mikono yake kwa thamani hii. Hii ina maana kwamba haina matukio yanayolingana na ombi hili. Anaunda tukio hili kwa njia ya uwongo na hivyo kuwa Sababu thabiti.
Katika: - Je, ikiwa baada ya haya matukio mengine yatakuja kwake ambayo yamepotea mahali fulani kwenye mtandao?
MT: - Shard imeundwa kwa namna ambayo hawatakuja tena, kwa kuwa ni bwana mmoja. Ikiwa tayari amejiandikisha, basi hawatakuja, lakini watakuja baadaye. Haiwezi kutokea kwamba kitu kinakwama mahali pengine, basi haandiki, na kisha matukio haya yanafika - na msimamo wa Causal umevunjwa. Asipoandika, wote wafuate (atawasubiri).
Katika: - Nina maswali kadhaa kuhusu foleni. Uthabiti wa sababu huchukulia kuwa kuna foleni maalum ya vitendo vinavyohitaji kufanywa. Nini kitatokea ikiwa moja ya vifurushi vyetu vitatoweka? Hapa inakuja ya 10, ya 11 ... ya 12 imetoweka, na kila mtu mwingine anasubiri kuwa kweli. Na ghafla gari letu lilikufa, hatuwezi kufanya chochote. Je, kuna urefu wa juu zaidi wa foleni ambao hujilimbikiza kabla ya kutekelezwa? Ni kushindwa gani mbaya hutokea wakati jimbo lolote linapotea? Zaidi ya hayo, ikiwa tunaandika kwamba kuna hali fulani ya awali, basi tunapaswa kuanza kutoka kwayo? Lakini hawakumsukuma mbali!
MT: - Pia swali kubwa! Tunafanya nini? MongoDB ina dhana ya akidi inaandika, akidi inasomwa. Ni katika hali gani ujumbe unaweza kupotea? Wakati maandishi sio akidi au wakati kusoma sio akidi (aina fulani ya taka inaweza pia kushikamana).
Kuhusu uwiano wa Causal, mtihani mkubwa wa majaribio ulifanyika, matokeo yake ni kwamba katika kesi wakati anaandika na kusoma sio quorum, ukiukwaji wa uthabiti wa Causal hutokea. Hasa unachosema!
Ushauri wetu: tumia angalau usomaji wa akidi unapotumia uthabiti wa Kisababishi. Katika kesi hii, hakuna kitu kitakachopotea, hata ikiwa rekodi ya akidi itapotea ... Hii ni hali ya orthogonal: ikiwa mtumiaji hataki data kupotea, anahitaji kutumia rekodi ya quorum. Uthabiti wa sababu hauhakikishi uimara. Uimara unahakikishwa na urudufu na mashine inayohusishwa na urudufishaji.
Katika: - Tunapounda mfano ambao hutufanyia sharding (sio bwana, lakini mtumwa, mtawaliwa), inategemea wakati wa Unix wa mashine yake mwenyewe au wakati wa "bwana"; Je, inasawazisha kwa mara ya kwanza au mara kwa mara?
MT: - Nitafafanua sasa. Shard (yaani kizigeu cha mlalo) - daima kuna Msingi huko. Na shard inaweza kuwa na "bwana" na kunaweza kuwa na nakala. Lakini shard daima inasaidia kurekodi, kwa sababu lazima isaidie kikoa fulani (shard ina Msingi).
Katika: - Kwa hivyo kila kitu kinategemea tu "bwana"? Je, wakati mkuu hutumiwa kila wakati?
MT: - Ndiyo. Unaweza kusema kwa mfano: saa inaashiria wakati kuingia kwa "bwana", kwenye "Oplog" hutokea.
Katika: - Tuna mteja anayeunganisha na hahitaji kujua chochote kuhusu wakati?
MT: - Huna haja ya kujua chochote! Ikiwa tunazungumzia jinsi inavyofanya kazi kwa mteja: wakati mteja anataka kutumia uthabiti wa Causal, anahitaji kufungua kikao. Sasa kila kitu kipo: miamala katika kipindi, na kupata haki... Kipindi ni mpangilio wa matukio ya kimantiki yanayotokea na mteja.
Ikiwa atafungua kikao hiki na kusema hapo kwamba anataka uthabiti wa Causal (ikiwa kikao kinaunga mkono uthabiti wa Causal kwa chaguo-msingi), kila kitu hufanya kazi kiatomati. Dereva anakumbuka wakati huu na huongeza wakati anapokea ujumbe mpya. Inakumbuka ni jibu gani la awali lilirudi kutoka kwa seva iliyorudisha data. Ombi linalofuata litakuwa na afterCluster("muda mkubwa kuliko huu").
Mteja hahitaji kujua chochote kabisa! Hii ni opaque kabisa kwake. Ikiwa watu watatumia vipengele hivi, wanaweza kufanya nini? Kwanza, unaweza kusoma sekondari kwa usalama: unaweza kuandikia Shule ya Msingi na kusoma kutoka kwa sekondari zilizoigwa kijiografia na uhakikishe kuwa inafanya kazi. Wakati huo huo, vipindi ambavyo vilirekodiwa kwenye Msingi vinaweza hata kuhamishiwa kwa Sekondari, i.e. huwezi kutumia kikao kimoja, lakini kadhaa.
Katika: - Safu mpya ya aina za data za Kokotoo - CRDT (Aina za Data Zilizojirudia zisizo na migogoro) - inahusiana sana na mada ya Uthabiti wa Hatimaye. Umefikiria kuunganisha aina hizi za data kwenye hifadhidata na unaweza kusema nini juu yake?
MT: - Swali nzuri! CRDT inaleta maana kwa uandishi wa migogoro: katika MongoDB, bwana mmoja.
Katika: - Nina swali kutoka kwa washiriki. Katika ulimwengu wa kweli, kuna hali kama hizi za Jesuitical wakati Kushindwa kwa Byzantine kunatokea, na watu waovu ndani ya eneo lililolindwa wanaanza kuingia kwenye itifaki, kutuma vifurushi vya ufundi kwa njia maalum?
MT: - Watu waovu ndani ya eneo ni kama farasi wa Trojan! Watu waovu ndani ya mzunguko wanaweza kufanya mambo mengi mabaya.
Katika: - Ni wazi kwamba kuacha, kwa kusema, shimo kwenye seva ambayo unaweza kuweka zoo ya tembo na kuangusha nguzo nzima milele... Itachukua muda kupona kwa mikono... Hii, ili kuiweka kwa upole, ni vibaya. Kwa upande mwingine, hii ni ya kuvutia: katika maisha halisi, katika mazoezi, kuna hali wakati mashambulizi ya kawaida ya ndani yanayofanana hutokea?
MT: - Kwa kuwa mimi hukutana na ukiukaji wa usalama katika maisha halisi mara chache, siwezi kusema ikiwa hutukia. Lakini ikiwa tunazungumza juu ya falsafa ya maendeleo, tunafikiria hivi: tunayo eneo ambalo hutoa watu wanaofanya usalama - hii ni ngome, ukuta; na ndani ya eneo unaweza kufanya chochote unachotaka. Ni wazi kuwa kuna watumiaji wenye uwezo wa kutazama tu, na kuna watumiaji wenye uwezo wa kufuta saraka.
Kulingana na haki, uharibifu ambao watumiaji wanaweza kufanya unaweza kuwa panya, au inaweza kuwa tembo. Ni wazi kuwa mtumiaji aliye na haki kamili anaweza kufanya chochote. Mtumiaji aliye na haki chache anaweza kusababisha madhara kidogo sana. Hasa, haiwezi kuvunja mfumo.
Katika: - Katika mzunguko uliolindwa, mtu alijaribu kuunda itifaki zisizotarajiwa kwa seva ili kuharibu kabisa seva, na ikiwa una bahati, kikundi kizima ... Je, inawahi kupata "nzuri" hiyo?
MT: "Sijawahi kusikia mambo kama haya." Ukweli kwamba unaweza kuharibu seva kwa njia hii sio siri. Kushindwa ndani, kuwa kutoka kwa itifaki, kuwa mtumiaji aliyeidhinishwa ambaye anaweza kuandika kitu kama hiki katika ujumbe ... Kwa kweli, haiwezekani, kwa sababu bado itathibitishwa. Inawezekana kuzima uthibitishaji huu kwa watumiaji ambao hawataki - basi hiyo ndiyo shida yao; wao, kwa kusema, waliharibu kuta wenyewe na unaweza kusukuma tembo huko, ambayo itakanyaga ... Lakini kwa ujumla, unaweza kuvaa kama mtu wa kurekebisha, njoo uitoe!
Katika: - Asante kwa ripoti. Sergey (Yandex). Kuna mara kwa mara katika Mong ambayo inaweka kikomo idadi ya washiriki wa kupiga kura katika Seti ya Replica, na hii mara kwa mara ni 7 (saba). Kwa nini hii ni mara kwa mara? Kwa nini hii sio aina fulani ya parameta?
MT: - Tuna Seti za Replica zilizo na nodi 40. Siku zote kuna wengi. Sijui ni toleo gani...
Katika: - Katika Seti ya Replica unaweza kuendesha washiriki wasiopiga kura, lakini kuna idadi isiyozidi washiriki 7. Tunawezaje kustahimili kuzima kwa kesi hii ikiwa Replica Set yetu imeenea kwenye vituo 3 vya data? Kituo kimoja cha data kinaweza kuzima kwa urahisi, na mashine nyingine inaweza kuanguka.
MT: - Hii tayari ni zaidi ya upeo wa ripoti. Hili ni swali la jumla. Labda naweza kukuambia kuhusu hilo baadaye.
Baadhi ya matangazo π
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com