Konferensi HighLoad++ sabanjure bakal dianakake tanggal 6 lan 7 April 2020 ing St.
Rincian lan karcis . HighLoad++ Siberia 2019. Hall "Krasnoyarsk". 25 Juni, 12:00. Tesis lan .
Iku kedadeyan yen syarat praktis bertentangan karo teori, ing ngendi aspek penting kanggo produk komersial ora dianggep. Dhiskusi iki nyedhiyakake proses kanggo milih lan nggabungake pendekatan sing beda kanggo nggawe komponen konsistensi Causal adhedhasar riset akademik adhedhasar syarat produk komersial. Para pamireng bakal sinau babagan pendekatan teoritis sing ana kanggo jam logis, pelacakan dependensi, keamanan sistem, sinkronisasi jam, lan ngapa MongoDB mapan ing solusi tartamtu.
Mikhail Tyulenev (sabanjuré diarani MT): - Aku bakal ngomong babagan konsistensi Causal - iki minangka fitur sing digarap ing MongoDB. Aku makarya ing klompok sistem mbagekke, kita nindakake babagan rong taun kepungkur.
Ing proses kasebut, aku kudu sinau akeh riset akademik, amarga fitur iki wis disinaoni kanthi apik. Pranyata ora ana artikel siji-sijine sing cocog karo sing dibutuhake ing basis data produksi amarga syarat sing spesifik banget sing bisa uga ana ing aplikasi produksi apa wae.
Aku bakal ngomong babagan carane kita, minangka konsumen Riset akademik, nyiapake soko saka iku sing banjur bisa kita saiki kedhaftar minangka sajian siap-digawe sing trep lan aman kanggo nggunakake.
Konsistensi sabab. Ayo nemtokake konsep
Kanggo miwiti, aku arep ngomong kanthi umum apa konsistensi Causal. Ana rong karakter - Leonard lan Penny (seri TV "The Big Bang Theory"):
Contone, Penny ana ing Eropa lan Leonard pengin nggawe pesta kejutan. Lan dheweke ora bisa mikir apa-apa sing luwih apik tinimbang mbuwang dheweke saka dhaptar kanca, ngirim kabeh kanca-kancane nganyari feed: "Ayo nggawe Penny seneng!" (dheweke ana ing Eropa, nalika dheweke turu, dheweke ora weruh kabeh iki lan ora bisa ndeleng, amarga dheweke ora ana ing kono). Pungkasane, dheweke mbusak kiriman iki, mbusak saka Feed lan mulihake akses supaya dheweke ora weruh apa-apa lan ora ana skandal.
Iki kabeh apik lan apik, nanging ayo nganggep manawa sistem kasebut disebarake lan ana sing salah. Contone, bisa kedadeyan yen watesan akses Penny kedadeyan sawise kiriman iki muncul, yen acara kasebut ora ana hubungane karo sebab lan akibat. Bener, iki minangka conto nalika konsistensi Causal dibutuhake kanggo nindakake fungsi bisnis (ing kasus iki).
Nyatane, iki minangka sifat database sing ora pati penting - sawetara wong sing ndhukung. Ayo dadi pindhah menyang model.
Model Konsistensi
Apa persis model konsistensi ing basis data? Iki minangka sawetara jaminan sing diwenehake dening sistem sing disebarake babagan data apa sing bisa ditampa klien lan ing urutan apa.
Ing asas, kabeh model konsistensi mudhun kanggo carane padha sistem mbagekke kanggo sistem sing mlaku, contone, ing siji simpul ing laptop. Lan iki minangka sistem sing padha karo ewu "Node" sing disebarake geo ing laptop, sing kabeh sifat kasebut ditindakake kanthi otomatis.
Mulane, model konsistensi mung ditrapake kanggo sistem sing disebarake. Kabeh sistem sing sadurunge ana lan dioperasikake ing skala vertikal sing padha ora ngalami masalah kasebut. Ana siji Buffer Cache, lan kabeh tansah diwaca saka iku.
Model Strong
Bener, model sing pisanan yaiku Strong (utawa garis kemampuan munggah, kaya sing asring diarani). Iki minangka model konsistensi sing mesthekake yen saben owah-owahan, yen dikonfirmasi wis kedadeyan, katon kanggo kabeh pangguna sistem kasebut.
Iki nggawe urutan global kabeh acara ing database. Iki minangka properti konsistensi sing kuwat banget, lan umume larang banget. Nanging, iku banget uga didhukung. Iku mung banget larang lan alon - iku mung arang digunakake. Iki diarani kemampuan munggah.
Ana liyane, properti kuwat sing didhukung ing Spanner - disebut Konsistensi njaba. Kita bakal ngomong babagan iki mengko.
Saring
Sabanjure yaiku Causal, sing persis kaya sing dakkandhakake. Ana sawetara sub-tingkat liyane antarane Strong lan Causal sing aku ora bakal ngomong bab, nanging kabeh godhok mudhun kanggo Causal. Iki minangka model sing penting amarga paling kuat ing kabeh model, konsistensi paling kuat ing ngarsane jaringan utawa partisi.
Sebab-sebab iku sejatine kahanan kang ana gegayutane karo sebab-akibat. Kerep banget dheweke dianggep minangka Waca hak sampeyan saka sudut pandang klien. Yen klien wis mirsani sawetara nilai, dheweke ora bisa ndeleng nilai-nilai sing ana ing jaman kepungkur. Dheweke wis wiwit ndeleng wacan awalan. Iku kabeh teka mudhun kanggo bab sing padha.
Causals minangka model konsistensi minangka urutan acara ing server, ing ngendi acara saka kabeh klien diamati ing urutan sing padha. Ing kasus iki, Leonard lan Penny.
Pungkasane
Model kaping telu yaiku Konsistensi Akhir. Iki pancen kabeh ndhukung sistem sing didistribusikake, model minimal sing bisa dingerteni. Iku tegese ing ngisor iki: nalika kita duwe sawetara owah-owahan ing data, ing sawetara titik padha dadi konsisten.
Ing wayahe, dheweke ora ngomong apa-apa, yen ora, dheweke bakal dadi Konsistensi Eksternal - bakal dadi crita sing beda. Nanging, iki minangka model sing paling populer, sing paling umum. Kanthi gawan, kabeh pangguna sistem sing disebarake nggunakake Konsistensi Akhir.
Aku pengin menehi sawetara conto komparatif:
Apa tegese panah iki?
- Latensi. Nalika kekuatan konsistensi mundhak, dadi luwih gedhe kanggo alasan ketok: sampeyan kudu nggawe liyane cathetan, njaluk konfirmasi saka kabeh sarwa dumadi lan kelenjar sing melu kluster sing data wis ana. Patut, Konsistensi Akhir duwe jawaban paling cepet, amarga ana, minangka aturan, sampeyan bisa uga tundhuk ing memori lan iki bakal, ing asas, cukup.
- Kasedhiyan. Yen kita ngerti iki minangka kemampuan sistem kanggo nanggapi ing ngarsane jaringan break, sekat, utawa sawetara jenis Gagal, toleransi fault mundhak minangka model konsistensi sudo, awit iku cukup kanggo kita sing siji inang urip lan ing padha. wektu mrodhuksi sawetara data. Konsistensi Akhir ora njamin apa-apa babagan data - bisa apa wae.
- anomali. Ing wektu sing padha, mesthi, jumlah anomali mundhak. Ing Konsistensi Kuwat meh ora ana, nanging ing Konsistensi Akhire bisa dadi apa wae. Pitakonan muncul: kenapa wong milih Konsistensi Akhire yen ngemot anomali? Jawaban iki yaiku model Konsistensi Akhire bisa ditrapake lan ana anomali, contone, ing wektu sing cendhak; bisa nggunakake tuntunan kanggo maca lan luwih utawa kurang maca data konsisten; Asring bisa nggunakake model konsistensi sing kuat. Ing laku iki bisa, lan asring nomer anomali diwatesi ing wektu.
Teorema CAP
Yen sampeyan ndeleng tembung konsistensi, kasedhiyan - apa sing sampeyan pikirake? Sing bener - teorema CAP! Saiki aku pengin ngilangi mitos kasebut ... Ora aku - Martin Kleppmann, sing nulis artikel sing apik banget, buku sing apik banget.
Teorema CAP minangka prinsip sing dirumusake ing taun 2000-an sing Konsistensi, Kasedhiyan, Partisi: njupuk loro, lan sampeyan ora bisa milih telu. Iku prinsip tartamtu. Iki dibuktekake minangka teorema sawetara taun sabanjure dening Gilbert lan Lynch. Banjur iki wiwit digunakake minangka mantra - sistem wiwit dipérang dadi CA, CP, AP lan ing.
Teorema iki bener-bener kabukten ing kasus-kasus ing ngisor iki ... Kaping pisanan, Kasedhiyan dianggep ora minangka nilai terus-terusan saka nol nganti atusan (0 - sistem "mati", 100 - nanggapi kanthi cepet; kita wis biasa nganggep kaya ngono) , nanging minangka properti saka algoritma , sing njamin yen kanggo kabeh eksekusi kasebut ngasilake data.
Ora ana tembung babagan wektu nanggepi! Ana algoritma sing ngasilake data sawise 100 taun - algoritma sing kasedhiya banget, yaiku bagean saka teorema CAP.
Kapindho: teorema kasebut kabukten kanggo owah-owahan ing nilai-nilai kunci sing padha, sanajan owah-owahan kasebut bisa diowahi ukurane. Iki tegese ing kasunyatan padha praktis ora digunakake, amarga model beda Konsistensi Akhire, Konsistensi Kuwat (mungkin).
Apa kabeh iki kanggo? Kajaba iku, téoréma CAP kanthi persis ing wangun sing wis kabukten praktis ora bisa ditrapake lan arang digunakake. Ing wangun teoritis, piye wae mbatesi kabeh. Pranyata prinsip tartamtu sing intuisi bener, nanging umume durung kabukten.
Konsistensi sebab-akibat minangka model sing paling kuat
Apa sing kedadeyan saiki yaiku sampeyan bisa entuk kabeh telung perkara: Konsistensi, Kasedhiyan nggunakake Partisi. Utamane, konsistensi Causal minangka model konsistensi sing paling kuat, sing isih bisa digunakake ing ngarsane Partisi (break ing jaringan). Pramila kapentingan kasebut banget, lan mula kita njupuk.
Kaping pisanan, nyederhanakake karya pangembang aplikasi. Utamane, ana dhukungan gedhe saka server: nalika kabeh rekaman sing kedadeyan ing siji klien dijamin bakal teka ing urutan sing padha ing klien liyane. Kapindho, tahan partisi.
Pawon Internal MongoDB
Ngeling-eling yen wis nedha awan, banjur pindhah menyang pawon. Aku bakal pitutur marang kowe bab model sistem, yaiku, apa MongoDB kanggo wong-wong sing krungu bab database kuwi kanggo pisanan.
MongoDB (sabanjuré diarani "MongoDB") minangka sistem sing disebarake sing ndhukung skala horisontal, yaiku, sharding; lan ing saben shard uga ndhukung redundansi data, yaiku, replikasi.
Sharding ing MongoDB (dudu database relasional) nindakake imbangan otomatis, yaiku, saben koleksi dokumen (utawa "tabel" ing syarat-syarat data relasional) dipérang dadi bêsik, lan server kanthi otomatis mindhah antarane pecahan.
Router Query, sing nyebarake panjaluk, kanggo klien yaiku sawetara klien sing bisa digunakake. Iku wis ngerti ngendi lan apa data dumunung lan ngarahake kabeh panjalukan kanggo shard bener.
Titik penting liyane: MongoDB minangka master tunggal. Ana siji Primary - bisa njupuk cathetan sing ndhukung tombol sing ngemot. Sampeyan ora bisa nindakake Multi-master nulis.
Kita nggawe rilis 4.2 - barang anyar sing menarik muncul ing kana. Utamane, dheweke nglebokake Lucene - telusuran - yaiku java sing bisa dieksekusi langsung menyang Mongo, lan ing kana bisa nggoleki telusuran liwat Lucene, padha karo Elastica.
Lan padha nggawe produk anyar - Charts, uga kasedhiya ing Atlas (Mongo dhewe Cloud). Padha duwe undakan Free - sampeyan bisa muter watara karo. Aku pancene disenengi Charts - visualisasi data, banget intuisi.
Ingredients Konsistensi sabab
Aku ngetung babagan 230 artikel sing wis diterbitake babagan topik iki - saka Leslie Lampert. Saiki saka pangeling-eling, aku bakal ngandhani sawetara bagean saka bahan kasebut.
Iku kabeh diwiwiti kanthi artikel dening Leslie Lampert, sing ditulis ing taun 1970-an. Kaya sing sampeyan ngerteni, sawetara riset babagan topik iki isih ditindakake. Saiki konsistensi Causal ngalami kapentingan sing ana hubungane karo pangembangan sistem sing disebarake.
Watesan
Watesan apa ana? Iki sejatine minangka salah sawijining titik utama, amarga watesan sing ditindakake sistem produksi beda banget karo watesan sing ana ing artikel akademik. Padha asring cukup gawean.
- Kaping pisanan, "MongoDB" minangka master tunggal, kaya sing wis dakkandhakake (iki luwih gampang).
- Kita pitados bilih sistem kudu ndhukung bab 10 ewu shards. Kita ora bisa nggawe keputusan arsitektur sing bakal mbatesi nilai kasebut kanthi jelas.
- Kita duwe awan, nanging kita nganggep manawa wong isih kudu duwe kesempatan nalika ngundhuh binar, mbukak ing laptop, lan kabeh kerjane apik.
- Kita nganggep soko sing jarang dianggep Riset: klien eksternal bisa nindakake apa wae sing dikarepake. MongoDB minangka sumber terbuka. Mulane, klien bisa dadi pinter lan nesu - bisa uga pengin ngilangi kabeh. Kita spekulasi manawa Feilor Bizantium bisa uga asale.
- Kanggo klien eksternal sing ana ing njaba keliling, ana watesan penting: yen fitur iki dipateni, mula ora ana degradasi kinerja sing kudu diamati.
- Titik liyane umume anti-akademik: kompatibilitas versi sadurunge lan sing bakal teka. Pembalap lawas kudu ndhukung nganyari anyar, lan basis data kudu ndhukung pembalap lawas.
Umumé, kabeh iki ngetrapake watesan.
Komponen konsistensi sabab
Saiki aku bakal ngomong babagan sawetara komponen. Yen kita nimbang konsistensi Causal ing umum, kita bisa milih pamblokiran. Kita milih saka karya sing kalebu ing blok tartamtu: Nelusuri Ketergantungan, milih jam, carane jam kasebut bisa disinkronake, lan carane njamin keamanan - iki minangka garis kasar babagan apa sing bakal dakkandhakake:
Nelusuri Ketergantungan Lengkap
Kenapa perlu? Supaya nalika data ditiru, saben rekaman, saben owah-owahan data ngemot informasi babagan owah-owahan sing gumantung. Owah-owahan sing pisanan lan naif yaiku nalika saben pesen sing ngemot rekaman ngemot informasi babagan pesen sadurunge:
Ing conto iki, angka ing kurung kriting minangka nomer rekaman. Kadhangkala cathetan kasebut kanthi nilai malah ditransfer kabeh, kadhangkala sawetara versi ditransfer. Ing ngisor iki yaiku saben owah-owahan ngemot informasi babagan sing sadurunge (temenan nggawa kabeh iki ing awake dhewe).
Napa kita mutusake ora nggunakake pendekatan iki (pelacakan lengkap)? Temenan, amarga pendekatan iki ora praktis: owah-owahan apa wae ing jaringan sosial gumantung marang kabeh owah-owahan sadurunge menyang jaringan sosial kasebut, nransfer, ucapake, Facebook utawa VKontakte ing saben nganyari. Nanging, ana akeh riset babagan Pelacakan Ketergantungan Lengkap - iki minangka jaringan pra-sosial; kanggo sawetara kahanan, pancen bisa digunakake.
Nelusuri Ketergantungan Eksplisit
Sabanjure luwih winates. Transfer informasi uga dianggep ing kene, nanging mung sing jelas gumantung. Apa gumantung apa, minangka aturan, ditemtokake dening Aplikasi. Nalika data ditiron, pitakonan mung ngasilake respon nalika dependensi sadurungé wis wareg, sing ditampilake. Iki minangka inti saka cara kerjane konsistensi Causal.
Dheweke weruh yen rekaman 5 gumantung ing cathetan 1, 2, 3, 4 - mulane, dheweke ngenteni sadurunge klien entuk akses menyang owah-owahan sing digawe dening keputusan akses Penny, nalika kabeh owah-owahan sadurunge wis liwat database.
Iki uga ora cocog karo kita, amarga isih akeh informasi, lan bakal alon-alon. Ana pendekatan liyane ...
Jam Lampor Kab
Dheweke wis tuwa banget. Jam Lamport tegese dependensi kasebut dilebokake dadi fungsi skalar, sing diarani Jam Lamport.
Fungsi skalar minangka sawetara nomer abstrak. Iku asring disebut wektu logis. Kanthi saben acara, counter iki mundhak. Counter, sing saiki dikenal kanggo proses, ngirim saben pesen. Cetha yen pangolahan bisa ora sinkron, bisa uga beda-beda. Nanging, sistem kasebut ngimbangi jam kanthi olahpesen kasebut. Apa sing kedadeyan ing kasus iki?
Aku pamisah sing beling amba dadi loro kanggo nggawe cetha: Kanca bisa manggon ing siji simpul, kang ngandhut Piece saka koleksi, lan Feed bisa manggon ing simpul liyane, kang ngemot Piece saka koleksi iki. Apa cetha carane bisa metu saka baris? First Feed bakal ngomong: "Replicated", lan banjur Friends. Yen sistem ora menehi jaminan manawa Feed ora bakal ditampilake nganti dependensi Kanca ing koleksi Kanca uga dikirim, mula kita bakal duwe kahanan sing dakkandhakake.
Sampeyan ndeleng carane wektu counter ing Feed mundhak logis:
Dadi properti utama saka Jam Lamport lan konsistensi Causal iki (diterangake liwat Jam Lamport) yaiku: yen kita duwe Acara A lan B, lan Acara B gumantung ing Acara A *, mula Wektu Logis saka Acara A kurang saka Wektu Logis saka Acara B.
* Kadhangkala dheweke uga ujar manawa A kedadeyan sadurunge B, yaiku, A kedadeyan sadurunge B - iki minangka hubungan tartamtu sing sebagian ngatur kabeh acara sing kedadeyan umume.
Kosok baline ora bener. Iki bener salah siji saka cacat utama Jam Lamport - urutan sebagean. Ana konsep babagan acara simultan, yaiku acara sing ora ana (A kedadeyan sadurunge B) utawa (A kedadeyan sadurunge B). Conto bakal tambahan podo Leonard saka wong liya minangka kanca (malah ora Leonard, nanging Sheldon, contone,).
Iki minangka properti sing asring digunakake nalika nggarap jam Lamport: padha katon khusus ing fungsi kasebut lan mula dheweke nyimpulake manawa acara kasebut gumantung. Amarga salah siji cara bener: yen LogicalTime A kurang saka LogicalTime B, banjur B ora bisa kelakon sadurunge A; lan yen luwih, banjur Mungkin.
Jam Vektor
Perkembangan logis saka jam Lamport yaiku Jam Vektor. Padha beda-beda ing saben simpul sing ana ing kene ngemot jam dhewe, lan ditularake minangka vektor.
Ing kasus iki, sampeyan ndeleng yen indeks zeroth saka vektor tanggung jawab kanggo Feed, lan indeks pisanan saka vektor kanggo Friends (saben kelenjar iki). Lan saiki bakal nambah: indeks nol "Feed" mundhak nalika nulis - 1, 2, 3:
Napa Jam Vektor luwih apik? Amarga ngidini sampeyan ngerteni acara sing bebarengan lan nalika kedadeyan ing kelenjar sing beda. Iki penting banget kanggo sistem sharding kaya MongoDB. Nanging, kita ora milih iki, sanajan iku apik banget, lan kerjane apik, lan mbokmenawa bakal cocog karo kita ...
Yen kita duwe 10 ewu pecahan, kita ora bisa nransfer 10 ewu komponen, sanajan kita compress utawa nggawe liyane - payload isih bakal kaping pirang-pirang luwih cilik tinimbang volume kabeh vektor iki. Mulane, gritting ati lan untu, kita nilar pendekatan iki lan pindhah menyang liyane.
Spanner TrueTime. Jam atom
Aku ngandika bakal ana crita bab Spanner. Iki pancen keren, langsung saka abad XNUMXst: jam atom, sinkronisasi GPS.
Apa ide? "Spanner" minangka sistem Google sing bubar kasedhiya kanggo wong (padha nambahake SQL). Saben transaksi ana sawetara prangko wektu. Wiwit wektu disinkronake *, saben acara bisa diwenehi wektu tartamtu - jam atom duwe wektu nunggu, sawise wektu sing beda dijamin "kedadeyan".
Mangkono, kanthi mung nulis menyang database lan ngenteni sawetara wektu, Serializability acara kasebut kanthi otomatis dijamin. Dheweke duwe model Konsistensi sing paling kuat sing bisa dibayangake kanthi prinsip - yaiku Konsistensi Eksternal.
* Iki masalah utama karo jam Lampart - padha ora tau sinkron ing sistem mbagekke. Dheweke bisa beda-beda; sanajan nganggo NTP, dheweke isih ora bisa digunakake kanthi apik. "Spanner" duwe jam atom lan sinkronisasi, misale jek microseconds.
Napa kita ora milih? Kita ora nganggep manawa pangguna duwe jam atom sing dibangun. Nalika katon, dibangun ing saben laptop, bakal ana sawetara jinis sinkronisasi GPS sing super keren - banjur ya ... Nanging saiki sing paling apik yaiku Amazon, Base Stations - kanggo fanatik ... Dadi kita nggunakake jam tangan liyane. .
Jam Hibrida
Iki sejatine sing ana ing MongoDB nalika njamin konsistensi Causal. Carane padha hibrida? Hibrida minangka nilai skalar, nanging nduweni rong komponen:
- Kapisan yaiku jaman Unix (pira detik wis liwati wiwit "wiwit jagad komputer").
- Kapindho sawetara tambahan, uga 32-bit unsigned int.
Sing kabeh, bener. Ana pendekatan iki: bagean sing tanggung jawab kanggo wektu diselarasake karo jam kabeh wektu; saben-saben ana nganyari, bagean iki diselarasake karo jam lan dadi metu sing wektu tansah luwih utawa kurang bener, lan nambah ngijini sampeyan kanggo mbedakake antarane acara sing kedaden ing wektu sing padha.
Napa iki penting kanggo MongoDB? Amarga ngidini sampeyan nggawe sawetara restoran serep ing wektu tartamtu, yaiku, acara kasebut diindeks kanthi wektu. Iki penting nalika acara tartamtu dibutuhake; Kanggo database, acara minangka owah-owahan ing basis data sing kedadeyan ing interval wektu tartamtu.
Aku bakal ngandhani alesan sing paling penting mung kanggo sampeyan (mangga, aja ngomong sapa wae)! Kita nindakake iki amarga iki sing diatur, data sing diindeks katon ing MongoDB OpLog. OpLog punika struktur data sing ngemot pancen kabeh owah-owahan ing database: padha pisanan menyang OpLog, lan banjur padha Applied kanggo Storage dhewe ing kasus nalika tanggal replicated utawa shard.
Iki minangka alesan utama. Nanging, ana uga syarat praktis kanggo ngembangake basis data, tegese kudu gampang - kode cilik, sawetara barang sing rusak sing kudu ditulis maneh lan diuji. Kasunyatan manawa oplog kita diindeks dening jam hibrida mbantu akeh lan ngidini kita nggawe pilihan sing tepat. Iku pancene mbayar mati lan piye wae gaib makarya ing prototipe banget pisanan. Iku banget kelangan!
Sinkronisasi jam
Ana sawetara cara sinkronisasi sing diterangake ing literatur ilmiah. Aku ngomong bab sinkronisasi nalika kita duwe rong shards beda. Yen ana siji replika pesawat, ora perlu kanggo sinkronisasi: iki "master tunggal"; kita duwe OpLog, ing ngendi kabeh owah-owahan tiba - ing kasus iki, kabeh wis diurutake kanthi urutan ing "Oplog" dhewe. Nanging yen kita duwe rong pecahan beda, sinkronisasi wektu penting ing kene. Iki ngendi jam vektor mbantu luwih! Nanging kita ora duwe.
Sing nomer loro cocok - iki "Detak Jantung". Sampeyan bisa ngganti sawetara sinyal sing kedadeyan saben unit wektu. Nanging Heartbeats alon banget, kita ora bisa nyedhiyani latensi kanggo klien kita.
Wektu sing bener, mesthi, iku sawijining perkara sing apik banget. Nanging, maneh, iki mbokmenawa mangsa ngarep ... Sanajan wis bisa ditindakake ing Atlas, wis ana sinkronisasi wektu "Amazon" sing cepet. Nanging ora bakal kasedhiya kanggo kabeh wong.
Gosip yaiku nalika kabeh pesen kalebu wektu. Iki kira-kira sing kita gunakake. Saben pesen antarane simpul, driver, router simpul data, pancen kabeh kanggo MongoDB sawetara jenis unsur, komponèn database sing ngemot jam sing mlaku. Dheweke duwe makna wektu hibrida ing endi wae, ditularake. 64 bit? Iki ngidini, iki bisa.
Carane kabeh bisa bebarengan?
Ing kene aku ndeleng siji set replika supaya luwih gampang. Ana Primary lan Secondary. Sekunder nindakake replikasi lan ora mesthi disinkronake kanthi lengkap karo Utama.
Penyisipan ana ing "Primy" kanthi nilai wektu tartamtu. sisipan iki nambah count internal 11, yen iki maksimum. Utawa bakal mriksa nilai jam lan nyelarasake menyang jam yen nilai jam luwih gedhe. Iki ngidini sampeyan ngatur kanthi wektu.
Sawise dheweke nggawe rekaman, ana wayahe penting. Jam kasebut ana ing "MongoDB" lan mung ditambahake yen ditulis menyang "Oplog". Iki minangka acara sing ngganti kahanan sistem. Ing kabeh artikel klasik, acara dianggep minangka nalika pesen tekan simpul: pesen wis teka, sing tegese sistem wis diganti negara.
Iki amarga kasunyatan sing sajrone riset ora sakabehe cetha carane pesen iki bakal diinterpretasikake. Kita ngerti manawa yen ora katon ing "Oplog", mula ora bakal ditafsirake kanthi cara apa wae, lan owah-owahan ing negara sistem mung minangka entri ing "Oplog". Iki nyederhanakake kabeh kanggo kita: model nyederhanakake, lan ngidini kita ngatur ing siji set replika, lan akeh liyane sing migunani.
Nilai sing wis ditulis menyang "Oplog" bali - kita ngerti yen "Oplog" wis ngemot nilai iki, lan wektu iku 12. Saiki, ngomong, maca wiwit saka simpul liyane (Secondary), lan ngirim afterClusterTime ing. pesen. Dheweke kandha: "Aku butuh kabeh sing kedadeyan paling ora sawise 12 utawa sajrone rolas" (ndeleng gambar ing ndhuwur).
Iki sing diarani Causal a konsisten (CAT). Ana konsep ing teori sing iki sawetara irisan wektu, kang konsisten ing dhewe. Ing kasus iki, kita bisa ngomong yen iki minangka negara sistem sing diamati ing wektu 12.
Saiki durung ana apa-apa, amarga iki simulasi kahanan nalika sampeyan butuh Secondary kanggo niru data saka Primary. Dheweke ngenteni ... Lan saiki data wis teka - dheweke ngasilake nilai kasebut.
Sing meh kabeh cara kerjane. meh.
Apa tegese "meh"? Ayo nganggep manawa ana sawetara wong sing wis maca lan ngerti kepiye cara iki. Aku temen maujud sing saben wektu ClusterTime occurs, nganyari jam logis internal, lan banjur entri sabanjuré mundhak siji. Fungsi iki njupuk 20 baris. Contone, wong iki ngirim nomer 64-bit paling gedhe, kurang siji.
Kenapa "minus one"? Amarga jam internal bakal diganti menyang nilai iki (temenan, iki paling gedhe lan luwih gedhe tinimbang wektu saiki), banjur ana entri ing "Oplog", lan jam kasebut bakal ditambah karo unit liyane - lan wis ana. dadi nilai maksimum (ana mung kabeh unit, ora ana liya kanggo pindhah), unsaint ints).
Cetha yen sawise iki sistem dadi pancen ora bisa diakses kanggo apa wae. Sampeyan mung bisa dibongkar lan di resiki - akeh karya manual. kasedhiyan lengkap:
Kajaba iku, yen iki ditiru ing papan liya, kabeh kluster mung ambruk. Kahanan sing pancen ora bisa ditampa sing bisa ditindakake sapa wae kanthi cepet lan gampang! Mulane, kita nganggep wayahe iki minangka salah sawijining sing paling penting. Carane nyegah?
Cara kita yaiku mlebu clusterTime
Iki minangka cara sing ditularake ing pesen (sadurunge teks biru). Nanging kita uga wiwit nggawe teken (teks biru):
Teken digawe dening tombol sing disimpen ing database, ing keliling aman; dhewe kui lan dianyari (pangguna ora weruh apa-apa bab iku). A hash digawe, lan saben pesen ditandatangani nalika digawe lan divalidasi nalika ditampa.
Pitakonan bisa uga muncul ing pikirane wong: "Pinten iki alon-alon?" Aku marang sing kudu bisa cepet, utamané ing anané fitur iki.
Apa tegese nggunakake konsistensi Causal ing kasus iki? Iki kanggo nuduhake parameter afterClusterTime. Tanpa iki, mung bakal ngliwati nilai. Gossiping, wiwit saka versi 3.6, tansah bisa.
Yen kita ninggalake generasi pancet tandha, iku bakal alon mudhun sistem sanajan ora ana fitur, kang ora ketemu pendekatan lan syarat kita. Dadi apa sing kita lakoni?
Tindakake kanthi cepet!
Iku cukup prasaja, nanging trik kasebut menarik - aku bakal nuduhake, bisa uga ana sing bakal kasengsem.
Kita duwe hash sing nyimpen data sing ditandatangani. Kabeh data dadi liwat cache. Cache ora mlebu wektu tartamtu, nanging Range. Nalika sawetara nilai teka, kita ngasilake Range, nutupi 16 bit pungkasan, lan kita mlebu nilai iki:
Kanthi nampa tandha kasebut, kita nyepetake sistem (relatif) 65 ewu kaping. Kerjane apik banget: nalika kita nindakake eksperimen, wektu nyatane suda 10 ewu kaping nalika kita duwe nganyari urutan. Cetha yen lagi ana ing rintangan, iki ora bisa. Nanging ing kasus sing paling praktis, bisa digunakake. Kombinasi teken Range bebarengan karo teken ngrampungake masalah keamanan.
Apa sing wis kita sinau?
Piwulang sing kita sinau saka iki:
- Kita kudu maca bahan, crita, artikel, amarga kita duwe akeh perkara sing menarik. Nalika kita nggarap sawetara fitur (utamane saiki, nalika nindakake transaksi, lsp), kita kudu maca lan ngerti. Butuh wektu, nanging sejatine migunani banget amarga wis jelas ing ngendi kita. Kita koyone ora teka munggah karo apa-apa anyar - kita mung njupuk úa.
Umumé, ana prabédan tartamtu ing pamikiran nalika ana konferensi akademik (Sigmon, contone) - kabeh wong fokus ing gagasan anyar. Apa sing anyar babagan algoritma kita? Ora ana anyar khusus ing kene. Kebaruan kasebut dumunung ing cara kita nggabungake pendekatan sing wis ana. Mula, sing sepisanan yaiku maca klasik, diwiwiti karo Lampart.
- Ing produksi, syarat sing beda-beda. Aku manawa akeh sing ora ngadhepi karo database "bunder" ing vakum abstrak, nanging karo normal, iku nyata sing duwe masalah karo kasedhiyan, latensi lan toleransi fault.
- Sing terakhir yaiku kita kudu ndeleng macem-macem ide lan nggabungake sawetara artikel sing beda-beda dadi siji pendekatan, bebarengan. Gagasan babagan tandha, umpamane, umume teka saka artikel sing dianggep protokol Paxos, sing kanggo Gagal non-Bizantium ana ing njero protokol wewenang, kanggo Bizantium - ing njaba protokol wewenang ... Umumé, iki persis apa sing kita lakoni. rampung nglakoni.
Pancen ora ana sing anyar ing kene! Nanging sanalika kita nyampur kabeh ... Iku padha karo ngomong yen resep salad Olivier iku omong kosong, amarga endhog, mayonnaise lan cucumbers wis nemokke ... Iku bab crita padha.
Aku bakal rampung karo iki. Matur nuwun!
Pitakonan
Pitakonan saka pamirsa (sabanjuré diarani B): – Matur nuwun, Mikhail, kanggo laporan! Topik babagan wektu menarik. Sampeyan nggunakake Gossiping. Dheweke ujar manawa saben wong duwe wektu dhewe, kabeh wong ngerti wektu lokal. Nalika aku ngerti, kita duwe driver - bisa uga akeh klien karo pembalap, query-planners banget, shards banget ... Lan apa sistem teka mudhun yen kita dumadakan duwe bedo: wong mutusaké sing iku kanggo a menit ahead, wong siji menit konco? Ing ngendi kita bakal mungkasi?
MT: – Pitakonan apik tenan! Aku mung pengin ngomong babagan pecahan. Yen aku ngerti pitakonan kanthi bener, kita duwe kahanan ing ngisor iki: ana beling 1 lan beling 2, maca kedadeyan saka rong beling iki - padha duwe bedo, ora sesambungan, amarga wektu sing padha ngerti beda, utamané wektu sing padha ana ing oplogs.
Ayo dadi ngomong sing beling 1 nggawe yuta cathetan, beling 2 ora nindakake apa-apa, lan panjalukan teka loro shards. Lan sing pisanan duwe afterClusterTime luwih saka yuta. Ing kahanan kaya mengkono, kaya sing dakkandhakake, shard 2 ora bakal nanggapi.
IN: – Aku wanted kanggo ngerti carane padha nyinkronake lan milih siji wektu logis?
MT: - Gampang banget kanggo nyinkronake. Shard, nalika afterClusterTime teka dheweke lan ora nemokake wektu ing "Oplog", miwiti ora disetujoni. Yaiku, dheweke ngunggahake wektu kanthi tangane menyang nilai kasebut. Iki tegese ora ana acara sing cocog karo panyuwunan iki. Dheweke nggawe acara iki sacara artifisial lan kanthi mangkono dadi Konsisten Penyebab.
IN: – Apa yen sawise iki sawetara acara liyane teka wong sing ilang nang endi wae ing jaringan?
MT: – Shard dirancang ing cara sing padha ora bakal teka maneh, awit iku master siji. Yen wis mlebu, dheweke ora bakal teka, nanging mengko. Ora bisa kedadeyan yen ana sing macet nang endi wae, banjur ora nulis, banjur kedadeyan kasebut - lan konsistensi Causal rusak. Nalika dheweke ora nulis, dheweke kudu teka sabanjure (dheweke bakal ngenteni).
IN: – Aku duwe sawetara pitakonan bab antrian. Konsistensi sabab nganggep yen ana antrian tartamtu saka tumindak sing kudu ditindakake. Apa sing kedadeyan yen salah sijine paket kita ilang? Iki tanggal 10, 11 ... tanggal 12 wis ilang, lan wong liya ngenteni kedadeyan kasebut. Lan dumadakan mobil kita mati, kita ora bisa nindakake apa-apa. Apa ana dawa maksimum antrian sing nglumpukake sadurunge dieksekusi? Gagal fatal apa sing kedadeyan nalika salah siji negara ilang? Menapa malih, yen kita nulis mudhun sing ana sawetara negara sadurungé, banjur kita kudu piye wae miwiti saka iku? Nanging dheweke ora nyurung dheweke!
MT: – Uga pitakonan gedhe! Apa sing kita tindakake? MongoDB duwe konsep nulis kuorum, maca kuorum. Ing kasus apa pesen bisa ilang? Nalika nulis ora quorum utawa nalika maca ora quorum (sawetara jenis sampah uga bisa nempel).
Babagan konsistensi Causal, tes eksperimen gedhe ditindakake, sing asile yen nulis lan maca ora quorum, pelanggaran konsistensi Causal dumadi. Persis apa sing sampeyan ucapake!
Saran kita: gunakake paling ora maca kuorum nalika nggunakake konsistensi Causal. Ing kasus iki, ora ana sing bakal ilang, sanajan cathetan kuorum ilang ... Iki minangka kahanan ortogonal: yen pangguna ora pengin data ilang, dheweke kudu nggunakake rekaman kuorum. Konsistensi sabab ora njamin kekiatan. Daya tahan dijamin kanthi replikasi lan mesin sing ana gandhengane karo replikasi.
IN: - Nalika kita nggawe conto sing nindakake sharding kanggo kita (dudu master, nanging abdi, mungguh), gumantung ing wektu Unix mesin dhewe utawa ing wektu "master"; Apa sinkronisasi pisanan utawa sacara periodik?
MT: - Aku bakal njlentrehake saiki. Shard (yaiku partisi horisontal) - tansah ana Primary ana. Lan shard bisa duwe "master" lan bisa uga ana replika. Nanging shard tansah ndhukung rekaman, amarga kudu ndhukung sawetara domain (shard nduweni Utama).
IN: – Dadi kabeh gumantung sejatine sifate ing "master"? Apa wektu master tansah digunakake?
MT: - Ya. Sampeyan bisa figuratively ngomong: jam wis ticking nalika entri menyang "master", menyang "Oplog" ana.
IN: - We duwe klien sing nyambung lan ora perlu ngerti apa-apa bab wektu?
MT: - Sampeyan ora perlu ngerti apa-apa! Yen kita ngomong babagan cara kerjane ing klien: nalika klien pengin nggunakake konsistensi Causal, dheweke kudu mbukak sesi. Saiki kabeh wis ana: transaksi ing sesi, lan njupuk hak ... Sesi minangka urutan acara logis sing kedadeyan karo klien.
Yen mbukak sesi iki lan ngandika ana sing pengin konsistensi Causal (yen sesi ndhukung konsistensi Causal minangka standar), kabeh bisa kanthi otomatis. Pembalap ngelingi wektu iki lan nambah nalika nampa pesen anyar. Iku ngelingi apa respon sing sadurunge bali saka server sing ngasilake data. Panjaluk sabanjure bakal ngemot afterCluster ("wektu luwih saka iki").
Klien ora perlu ngerti apa-apa! Iki pancen opaque kanggo dheweke. Yen wong nggunakake fitur kasebut, apa sing bisa ditindakake? Pisanan, sampeyan bisa maca sekunder kanthi aman: sampeyan bisa nulis menyang Primer lan maca saka sekunder sing ditiru sacara geografis lan priksa manawa bisa digunakake. Ing wektu sing padha, sesi sing direkam ing Primary malah bisa ditransfer menyang Secondary, yaiku sampeyan ora bisa nggunakake siji sesi, nanging sawetara.
IN: - Lapisan anyar ilmu Komputasi - jinis data CRDT (Tipe Data Replika Bebas Konflik) - gegandhengan banget karo topik konsistensi Akhire. Apa sampeyan wis nimbang nggabungake jinis data kasebut menyang basis data lan apa sing bisa dikandhakake babagan iki?
MT: - Pitakonan apik! CRDT masuk akal kanggo nulis konflik: ing MongoDB, master tunggal.
IN: – Aku duwe pitakonan saka devops. Ing donya nyata, ana kahanan Jesuitical kuwi nalika Gagal Bizantium, lan wong ala ing keliling dilindhungi wiwit poke menyang protokol, ngirim paket pakaryan ing cara khusus?
MT: – Wong ala ing njero perimeter kaya jaran Trojan! Wong-wong jahat sing ana ing njero perimeter bisa nindakake akeh tumindak ala.
IN: - Cetha yen ninggalake, kira-kira, bolongan ing server sing bisa dilebokake kebon binatang gajah lan ambruk kabeh kluster ing salawas-lawase... Bakal butuh wektu kanggo pemulihan manual ... Iki, kanthi gampang, yaiku salah. Ing sisih liya, iki menarik: ing urip nyata, ing praktik, ana kahanan nalika serangan internal sing padha?
MT: - Amarga aku jarang nemoni pelanggaran keamanan ing urip nyata, aku ora bisa ngomong yen kedadeyan kasebut. Nanging yen kita pirembagan bab filosofi pembangunan, kita mikir kaya iki: kita duwe keliling sing nyedhiyani wong lanang sing nindakake keamanan - iki Bèntèng, tembok; lan nang keliling sampeyan bisa nindakake apa wae sing dikarepake. Cetha yen ana pangguna sing mung bisa ndeleng, lan ana pangguna sing bisa mbusak direktori kasebut.
Gumantung ing hak, karusakan sing bisa ditindakake pangguna bisa dadi mouse, utawa bisa uga gajah. Cetha manawa pangguna kanthi hak lengkap bisa nindakake apa wae. Pangguna sing duwe hak winates bisa nyebabake cilaka sing luwih sithik. Utamane, ora bisa ngrusak sistem.
IN: - Ing keliling dilindhungi, wong nyoba kanggo nggawe protokol sing ora dikarepke kanggo server supaya rampung numpes server, lan yen sampeyan lagi bejo, kabeh kluster ... Apa iku tau njaluk sing "apik"?
MT: "Aku durung tau krungu bab kaya ngono." Kasunyatan manawa sampeyan bisa nabrak server kanthi cara iki ora dadi rahasia. Gagal ing njero, saka protokol, dadi pangguna sing sah sing bisa nulis kaya iki ing pesen ... Nyatane, ora mungkin, amarga isih bakal diverifikasi. Sampeyan bisa mateni otentikasi iki kanggo pangguna sing ora pengin - banjur masalahe; padha, kira-kira ngandika, numpes tembok piyambak lan sampeyan bisa push gajah ing kono, kang bakal trample ... Nanging ing umum, sampeyan bisa macak minangka repairman, teka lan narik metu!
IN: – Matur nuwun kanggo laporan. Sergey (Yandex). Ana konstanta ing Mong sing mbatesi jumlah anggota voting ing Replika Set, lan pancet iki 7 (pitu). Kenapa iki konstan? Napa iki ora sawetara jinis parameter?
MT: - Kita duwe Set Replica kanthi 40 simpul. Ana tansah mayoritas. Aku ora ngerti versi sing ...
IN: - Ing Replika Set sampeyan bisa mbukak anggota non-voting, nanging ana maksimal anggota voting 7. Kepiye carane bisa urip mati ing kasus iki yen Replika Set kita nyebar ing 3 pusat data? Siji pusat data bisa gampang dipateni, lan mesin liyane bisa tiba.
MT: – Iki wis sethitik ngluwihi orane katrangan saka laporan. Iki minangka pitakonan umum. Muga-muga aku bisa ngomong babagan iki mengko.
Sawetara iklan 🙂
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com