Keyingi HighLoad++ konferensiyasi 6 yilning 7 va 2020 aprel kunlari Sankt-Peterburgda bo‘lib o‘tadi.
Tafsilotlar va chiptalar . HighLoad++ Sibir 2019. "Krasnoyarsk" zali. 25-iyun, soat 12:00. Tezislar va .
Amaliy talablar nazariyaga zid keladi, bunda tijorat mahsuloti uchun muhim jihatlar hisobga olinmaydi. Ushbu ma'ruza tijorat mahsulotiga bo'lgan talablar asosida akademik tadqiqotlarga asoslangan Sebeb izchillik komponentlarini yaratish uchun turli yondashuvlarni tanlash va birlashtirish jarayonini taqdim etadi. Tinglovchilar mantiqiy soatlarga nisbatan mavjud nazariy yondashuvlar, qaramlikni kuzatish, tizim xavfsizligi, soat sinxronizatsiyasi va nima uchun MongoDB ma'lum echimlarga qaror qilgani haqida bilib oladi.
Mixail Tyulenev (bundan buyon matnda MT deb yuritiladi): – Men Causal izchillik haqida gapiraman - bu biz MongoDB da ishlagan xususiyatdir. Men taqsimlangan tizimlar guruhida ishlayman, biz buni taxminan ikki yil oldin qilganmiz.
Bu jarayonda men ko'plab akademik tadqiqotlar bilan tanishishim kerak edi, chunki bu xususiyat juda yaxshi o'rganilgan. Ma'lum bo'lishicha, har qanday ishlab chiqarish ilovasida mavjud bo'lgan juda aniq talablar tufayli biron bir maqola ishlab chiqarish ma'lumotlar bazasida talab qilinadigan narsalarga mos kelmaydi.
Biz, akademik tadqiqot iste'molchilari sifatida, undan qanday qilib foydalanishimiz qulay va xavfsiz bo'lgan tayyor taom sifatida foydalanuvchilarga taqdim etishimiz mumkin bo'lgan narsalarni tayyorlashimiz haqida gapiraman.
Sabab-oqibat izchilligi. Keling, tushunchalarni aniqlaylik
Boshlash uchun men umumiy ma'noda Causal izchillik nima ekanligini aytmoqchiman. Ikkita qahramon bor - Leonard va Penni ("Katta portlash nazariyasi" teleseriali):
Aytaylik, Penni Yevropada va Leonard unga kutilmagan ziyofat uyushtirmoqchi. Va u uni do'stlari ro'yxatidan chiqarib tashlashdan ko'ra yaxshiroq narsani o'ylay olmaydi: "Keling, Penni xursand qilaylik!" (u Evropada, uxlayotganida, u bularning hammasini ko'rmaydi va ko'ra olmaydi, chunki u erda yo'q). Oxir-oqibat, u hech narsani sezmasligi va janjal bo'lmasligi uchun ushbu postni o'chiradi, uni tasmadan o'chiradi va kirishni tiklaydi.
Bularning barchasi yaxshi va yaxshi, lekin keling, tizim taqsimlangan va ishlar biroz noto'g'ri ketdi deb faraz qilaylik. Masalan, agar voqealar sabab va ta'sir bilan bog'liq bo'lmasa, Pennyga kirishni cheklash ushbu post paydo bo'lgandan keyin sodir bo'lishi mumkin. Aslida, bu biznes funktsiyasini bajarish uchun sababiy izchillik talab qilinishiga misoldir (bu holda).
Aslida, bu ma'lumotlar bazasining juda ahamiyatsiz xususiyatlari - juda kam odam ularni qo'llab-quvvatlaydi. Keling, modellarga o'taylik.
Muvofiqlik modellari
Ma'lumotlar bazalarida izchillik modeli aynan nima? Bu taqsimlangan tizim mijoz qanday ma'lumotlarni va qanday ketma-ketlikda olishi mumkinligi haqida kafolatlarning ba'zilari.
Asosan, barcha izchillik modellari taqsimlangan tizim, masalan, noutbukda bitta tugunda ishlaydigan tizimga qanchalik o'xshashligi bilan bog'liq. Minglab geo-tarqatilgan "tugunlarda" ishlaydigan tizim noutbukga qanchalik o'xshash bo'lib, unda barcha xususiyatlar printsipial ravishda avtomatik ravishda amalga oshiriladi.
Shuning uchun izchillik modellari faqat taqsimlangan tizimlarga qo'llaniladi. Ilgari mavjud bo'lgan va bir xil vertikal masshtabda ishlaydigan barcha tizimlar bunday muammolarga duch kelmadi. Bitta bufer keshi bor edi va hamma narsa har doim undan o'qiladi.
Model kuchli
Aslida, birinchi model Kuchli (yoki tez-tez deyilganidek, ko'tarilish qobiliyati chizig'i). Bu izchillik modeli bo'lib, u sodir bo'lganligi tasdiqlangan har bir o'zgarish tizimning barcha foydalanuvchilariga ko'rinib turishini ta'minlaydi.
Bu ma'lumotlar bazasidagi barcha hodisalarning global tartibini yaratadi. Bu juda kuchli mustahkamlik xususiyati va u odatda juda qimmat. Biroq, u juda yaxshi qo'llab-quvvatlanadi. Bu juda qimmat va sekin - u juda kam ishlatiladi. Bu ko'tarilish qobiliyati deb ataladi.
Spanner-da qo'llab-quvvatlanadigan yana bir kuchli xususiyat mavjud - tashqi izchillik. Bu haqda biroz keyinroq gaplashamiz.
Sabab
Keyingisi Causal, bu men aytayotgan narsadir. Strong va Causal o'rtasida yana bir nechta kichik darajalar mavjud, ular haqida gapirmayman, lekin ularning barchasi Causalga tushadi. Bu muhim model, chunki u barcha modellarning eng kuchlisi, tarmoq yoki bo'limlar mavjudligida eng kuchli mustahkamlik.
Sabablar aslida hodisalar sabab-natija munosabati bilan bog'langan vaziyatdir. Ko'pincha ular mijoz nuqtai nazaridan sizning huquqlaringizni o'qing deb qabul qilinadi. Agar mijoz ba'zi qadriyatlarni kuzatgan bo'lsa, u o'tmishdagi qadriyatlarni ko'ra olmaydi. U allaqachon prefiks o'qishlarini ko'rishni boshladi. Hammasi bir xil narsaga tushadi.
Muvaffaqiyatlilik modeli sifatida sabablar serverdagi voqealarning qisman tartiblanishi bo'lib, unda barcha mijozlar voqealari bir xil ketma-ketlikda kuzatiladi. Bunday holda, Leonard va Penny.
Yakuniy
Uchinchi model - yakuniy izchillik. Bu mutlaqo barcha taqsimlangan tizimlarni qo'llab-quvvatlaydi, umuman mantiqiy bo'lgan minimal model. Bu quyidagilarni anglatadi: bizda ma'lumotlarda ba'zi o'zgarishlar bo'lsa, ular bir nuqtada izchil bo'ladi.
Bunday paytda u hech narsa demaydi, aks holda u tashqi izchillikka aylanadi - bu butunlay boshqacha hikoya bo'lar edi. Shunga qaramay, bu juda mashhur model, eng keng tarqalgan. Odatiy bo'lib, taqsimlangan tizimlarning barcha foydalanuvchilari Eventual Consistency-dan foydalanadilar.
Men bir nechta qiyosiy misollar keltirmoqchiman:
Bu o'qlar nimani anglatadi?
- Kechikish. Qat'iylik kuchi oshgani sayin, u aniq sabablarga ko'ra katta bo'ladi: siz ko'proq yozuvlar qilishingiz, klasterda ishtirok etadigan barcha xostlar va tugunlardan ma'lumotlar allaqachon mavjudligini tasdiqlashingiz kerak. Shunga ko'ra, yakuniy izchillik eng tezkor javobga ega, chunki u erda, qoida tariqasida, siz hatto uni xotiraga topshirishingiz mumkin va bu, qoida tariqasida, etarli bo'ladi.
- Mavjudligi. Agar biz buni tizimning tarmoq uzilishlari, bo'linishlari yoki biron bir nosozlik mavjud bo'lganda javob berish qobiliyati deb tushunadigan bo'lsak, barqarorlik modelining pasayishi bilan xatoga chidamlilik ortadi, chunki biz uchun bitta xostning yashashi va bir vaqtning o'zida bir xil bo'lishi kifoya. vaqt ba'zi ma'lumotlarni ishlab chiqaradi. Yakuniy izchillik ma'lumotlar haqida hech narsa kafolatlamaydi - bu har qanday bo'lishi mumkin.
- Anomaliyalar. Shu bilan birga, albatta, anomaliyalar soni ortadi. Kuchli izchillikda ular deyarli mavjud bo'lmasligi kerak, ammo yakuniy izchillikda ular hamma narsa bo'lishi mumkin. Savol tug'iladi: nima uchun odamlar anomaliyalarni o'z ichiga olsa, yakuniy izchillikni tanlaydilar? Javob: Oxir-oqibat izchillik modellari qo'llanilishi mumkin va anomaliyalar, masalan, qisqa vaqt ichida mavjud; izchil ma'lumotlarni o'qish va ko'p yoki kamroq o'qish uchun sehrgardan foydalanish mumkin; Ko'pincha kuchli mustahkamlik modellaridan foydalanish mumkin. Amalda bu ishlaydi va ko'pincha anomaliyalar soni vaqt bilan cheklangan.
CAP teoremasi
Muvofiqlik, mavjudlik so'zlarini ko'rganingizda - xayolingizga nima keladi? To'g'ri - CAP teoremasi! Endi men afsonani yo'q qilmoqchiman... Bu men emas - ajoyib maqola, ajoyib kitob yozgan Martin Kleppmann.
CAP teoremasi 2000-yillarda ishlab chiqilgan printsip bo'lib, izchillik, mavjudlik, bo'limlar: istalgan ikkitasini oling va uchtasini tanlay olmaysiz. Bu ma'lum bir printsip edi. Bu bir necha yil o'tgach, Gilbert va Linch tomonidan teorema sifatida isbotlangan. Keyin bu mantra sifatida ishlatila boshlandi - tizimlar CA, CP, AP va boshqalarga bo'linishni boshladi.
Bu teorema aslida quyidagi holatlar uchun isbotlangan... Birinchidan, Mavjudlik noldan yuzlabgacha bo‘lgan uzluksiz qiymat sifatida ko‘rib chiqilmagan (0 – tizim “o‘lgan”, 100 – tez javob beradi; biz buni shunday ko‘rib chiqishga odatlanganmiz) , lekin algoritmning xususiyati sifatida , bu uning barcha bajarilishi uchun ma'lumotlarni qaytarishini kafolatlaydi.
Javob vaqti haqida umuman so'z yo'q! 100 yildan keyin ma'lumotlarni qaytaradigan algoritm mavjud - bu CAP teoremasining bir qismi bo'lgan mutlaqo ajoyib mavjud algoritm.
Ikkinchidan: teorema bir xil kalit qiymatlaridagi o'zgarishlar uchun isbotlangan, garchi bu o'zgarishlar o'lchamini o'zgartirish mumkin. Bu shuni anglatadiki, aslida ular amalda qo'llanilmaydi, chunki modellar turli xil Oxir-oqibat mustahkamlik, kuchli izchillik (ehtimol).
Bularning barchasi nima uchun? Bundan tashqari, CAP teoremasi aniq isbotlangan shaklda amalda qo'llanilmaydi va kamdan-kam qo'llaniladi. Nazariy shaklda u qandaydir tarzda hamma narsani cheklaydi. Bu intuitiv ravishda to'g'ri bo'lgan, ammo umuman isbotlanmagan ma'lum bir printsip bo'lib chiqadi.
Sabab-oqibat izchilligi eng kuchli modeldir
Hozir sodir bo'layotgan narsa shundaki, siz uchta narsani olishingiz mumkin: Bo'limlar yordamida izchillik, mavjudlik. Xususan, Causal izchillik eng kuchli mustahkamlik modeli bo'lib, u hali ham Bo'limlar (tarmoqdagi tanaffuslar) mavjudligida ishlaydi. Shuning uchun bu juda katta qiziqish uyg'otadi va shuning uchun biz uni oldik.
Birinchidan, bu dastur ishlab chiquvchilarning ishini osonlashtiradi. Xususan, server tomonidan katta yordam mavjudligi: bitta mijoz ichida sodir bo'lgan barcha yozuvlar boshqa mijozga bir xil ketma-ketlikda kelishi kafolatlanganda. Ikkinchidan, u qismlarga bardosh beradi.
MongoDB ichki oshxonasi
Tushlik ekanligini eslab, oshxonaga o'tamiz. Men sizga tizim modeli haqida, ya'ni MongoDB nima ekanligini, bunday ma'lumotlar bazasi haqida birinchi marta eshitayotganlar uchun aytib beraman.
MongoDB (keyingi o'rinlarda "MongoDB" deb yuritiladi) - gorizontal o'lchovni, ya'ni shardingni qo'llab-quvvatlaydigan taqsimlangan tizim; va har bir parcha ichida u ma'lumotlarning ortiqchaligini, ya'ni replikatsiyani ham qo'llab-quvvatlaydi.
MongoDB-da sharding (relational ma'lumotlar bazasi emas) avtomatik balanslashni amalga oshiradi, ya'ni har bir hujjatlar to'plami (yoki "jadval" relyatsion ma'lumotlar bo'yicha) qismlarga bo'linadi va server ularni avtomatik ravishda parchalar o'rtasida o'tkazadi.
Mijoz uchun so'rovlarni tarqatuvchi Query Router - bu u orqali ishlaydigan mijoz. U allaqachon qaerda va qanday ma'lumotlar joylashganligini biladi va barcha so'rovlarni to'g'ri shardga yo'naltiradi.
Yana bir muhim jihat: MongoDB yagona master hisoblanadi. Bitta asosiy mavjud - u o'z ichiga olgan kalitlarni qo'llab-quvvatlaydigan yozuvlarni olishi mumkin. Multi-master yozishni amalga oshira olmaysiz.
Biz 4.2-ni chiqardik - u erda yangi qiziqarli narsalar paydo bo'ldi. Xususan, ular Lucene - qidiruv - ya'ni bajariladigan java-ni to'g'ridan-to'g'ri Mongo-ga kiritdilar va u erda Elastica-dagi kabi Lucene orqali qidiruvlarni amalga oshirish mumkin bo'ldi.
Va ular yangi mahsulotni yaratdilar - Grafiklar, u Atlasda ham mavjud (Mongoning o'z buluti). Ularning bepul darajasi bor - siz u bilan o'ynashingiz mumkin. Menga Grafiklar juda yoqdi - ma'lumotlarni vizualizatsiya qilish, juda intuitiv.
Ingredientlar Sababli mustahkamlik
Men ushbu mavzu bo'yicha nashr etilgan 230 ga yaqin maqolalarni sanab chiqdim - Lesli Lampertdan. Endi men xotiramdan ushbu materiallarning ba'zi qismlarini sizga etkazaman.
Hammasi Lesli Lampertning 1970-yillarda yozilgan maqolasi bilan boshlandi. Ko'rib turganingizdek, ushbu mavzu bo'yicha ba'zi tadqiqotlar hali ham davom etmoqda. Endi taqsimlangan tizimlarning rivojlanishi munosabati bilan Causal izchillik qiziqish uyg'otmoqda.
Cheklovlar
Qanday cheklovlar mavjud? Bu aslida asosiy fikrlardan biridir, chunki ishlab chiqarish tizimi qo'yadigan cheklovlar akademik maqolalarda mavjud bo'lgan cheklovlardan juda farq qiladi. Ko'pincha ular juda sun'iydir.
- Birinchidan, "MongoDB" - bu bitta master, men aytganimdek (bu juda soddalashtiradi).
- Biz tizim taxminan 10 ming shardni qo'llab-quvvatlashi kerak deb hisoblaymiz. Biz ushbu qiymatni aniq cheklaydigan hech qanday me'moriy qarorlar qabul qila olmaymiz.
- Bizda bulut bor, lekin biz ikkilik faylni yuklab olib, uni noutbukda ishga tushirganda va hamma narsa ajoyib ishlaganda, odam hali ham imkoniyatga ega bo'lishi kerak deb hisoblaymiz.
- Biz tadqiqot kamdan-kam hollarda taxmin qiladigan narsani taxmin qilamiz: tashqi mijozlar xohlagan narsani qilishlari mumkin. MongoDB ochiq manba hisoblanadi. Shunga ko'ra, mijozlar juda aqlli va g'azablangan bo'lishi mumkin - ular hamma narsani buzishni xohlashlari mumkin. Biz Vizantiya Feilors kelib chiqishi mumkin, deb taxmin.
- Perimetrdan tashqarida bo'lgan tashqi mijozlar uchun muhim cheklov mavjud: agar bu xususiyat o'chirilgan bo'lsa, unda ishlashning pasayishi kuzatilmasligi kerak.
- Yana bir nuqta, odatda, anti-akademik: oldingi va kelajakdagi versiyalarning muvofiqligi. Eski drayverlar yangi yangilanishlarni, ma'lumotlar bazasi esa eski drayverlarni qo'llab-quvvatlashi kerak.
Umuman olganda, bularning barchasi cheklovlarni keltirib chiqaradi.
Sabab-baza mustahkamlik komponentlari
Endi men ba'zi tarkibiy qismlar haqida gapiraman. Agar biz Causal izchilligini umuman ko'rib chiqsak, biz bloklarni tanlashimiz mumkin. Biz ma'lum bir blokga tegishli ishlardan tanladik: Qaramlikni kuzatish, soatlarni tanlash, bu soatlar bir-biri bilan qanday sinxronlashtirilishi va biz xavfsizlikni qanday ta'minlaymiz - bu men gaplashadigan narsalarning taxminiy tavsifi:
To'liq qaramlikni kuzatish
Nima uchun kerak? Shunday qilib, ma'lumotlar takrorlanganda, har bir yozuv, har bir ma'lumot o'zgarishi qanday o'zgarishlarga bog'liqligi haqida ma'lumotni o'z ichiga oladi. Birinchi va sodda o'zgarish - bu yozuvni o'z ichiga olgan har bir xabar oldingi xabarlar haqida ma'lumotni o'z ichiga oladi:
Bu misolda jingalak qavs ichidagi raqam rekord raqamlardir. Ba'zida qiymatlari bo'lgan ushbu yozuvlar hatto to'liq uzatiladi, ba'zan esa ba'zi versiyalar uzatiladi. Xulosa shuki, har bir o'zgarish avvalgisi haqida ma'lumotni o'z ichiga oladi (shubhasiz, bularning barchasini o'z ichiga oladi).
Nima uchun biz ushbu yondashuvdan foydalanmaslikka qaror qildik (to'liq kuzatish)? Shubhasiz, chunki bu yondashuv amaliy emas: ijtimoiy tarmoqdagi har qanday o'zgarish ushbu ijtimoiy tarmoqdagi barcha oldingi o'zgarishlarga, aytaylik, har bir yangilanishda Facebook yoki VKontakte-ga o'tkazishga bog'liq. Shunga qaramay, to'liq qaramlikni kuzatish bo'yicha ko'plab tadqiqotlar mavjud - bular ijtimoiy tarmoqlardan oldingi; ba'zi vaziyatlarda u haqiqatan ham ishlaydi.
Aniq qaramlikni kuzatish
Keyingisi ancha cheklangan. Bu erda ma'lumot uzatish ham ko'rib chiqiladi, lekin faqat aniq bog'liq bo'lgan narsa. Nimaga bog'liq, qoida tariqasida, Ilova tomonidan belgilanadi. Ma'lumotlar takrorlanganda, so'rov faqat oldingi bog'liqliklar qondirilganda, ya'ni ko'rsatilganda javoblarni qaytaradi. Bu Causal izchillik qanday ishlashining mohiyatidir.
U 5-yozuv 1, 2, 3, 4-yozuvlarga bog'liqligini ko'radi - shunga ko'ra, u mijoz Pennyning kirish qarori bilan kiritilgan o'zgarishlarga kirishini kutadi, chunki oldingi barcha o'zgarishlar ma'lumotlar bazasidan allaqachon o'tib ketgan.
Bu bizga ham to'g'ri kelmaydi, chunki hali juda ko'p ma'lumot bor va bu ishlarni sekinlashtiradi. Yana bir yondashuv bor ...
Lamport soati
Ular juda qari. Lamport soati bu bog'liqliklar Lamport soati deb ataladigan skalyar funksiyaga yig'ilganligini anglatadi.
Skayar funksiya - bu qandaydir mavhum son. Ko'pincha mantiqiy vaqt deb ataladi. Har bir hodisa bilan bu hisoblagich ortadi. Hozirda jarayonga ma'lum bo'lgan hisoblagich har bir xabarni yuboradi. Jarayonlar hamohang bo'lishi mumkinligi aniq, ular butunlay boshqacha vaqtga ega bo'lishi mumkin. Shunga qaramay, tizim qandaydir tarzda bunday xabarlar bilan soatni muvozanatlashtiradi. Bu holatda nima bo'ladi?
Aniqroq qilish uchun men bu katta bo‘lakni ikkiga bo‘ldim: Do‘stlar to‘plamning bir qismini o‘z ichiga olgan bitta tugunda, Feed esa ushbu to‘plamning bir qismini o‘z ichiga olgan boshqa tugunda yashashi mumkin. Qanday qilib ular chiziqdan chiqib ketishlari aniqmi? Avval tasma: “Replikatsiya qilingan”, keyin esa “Do‘stlar” deb aytadi. Agar tizim "Do'stlar" to'plamidagi "Do'stlarga" bog'liqliklari ham yetkazilmaguncha tasma ko'rsatilmasligiga qandaydir kafolat bermasa, bizda aynan men aytib o'tgan vaziyat bo'ladi.
Tasmadagi hisob vaqti mantiqiy ravishda qanday oshishini ko'rasiz:
Shunday qilib, ushbu Lamport soati va sababiy izchilligining asosiy xususiyati (Lamport soati orqali tushuntirilgan) quyidagilardir: agar bizda A va B hodisalari bo'lsa va B hodisasi A* hodisasiga bog'liq bo'lsa, A hodisasining mantiqiy vaqti dan kichik bo'ladi. B hodisasidan LogicalTime.
* Ba'zan ular A B dan oldin sodir bo'lgan, ya'ni A B dan oldin sodir bo'lgan deb ham aytishadi - bu umuman sodir bo'lgan barcha voqealar to'plamini qisman tartibga soluvchi ma'lum bir munosabat.
Buning aksi noto'g'ri. Bu aslida Lamport soatining asosiy kamchiliklaridan biri - qisman buyurtma. Bir vaqtning o'zida sodir bo'lgan hodisalar, ya'ni na (A B dan oldin sodir bo'lgan) va na (A B dan oldin sodir bo'lgan) hodisalar haqida tushuncha mavjud. Misol tariqasida Leonardning boshqa birovni do'st sifatida qo'shishi mumkin (masalan, Leonard emas, balki Sheldon).
Bu Lamport soatlari bilan ishlashda tez-tez ishlatiladigan xususiyatdir: ular funktsiyaga alohida qarashadi va shundan ular, ehtimol, bu hodisalar bog'liq degan xulosaga kelishadi. Chunki bitta yo'l to'g'ri: agar LogicalTime A LogicalTime B dan kichik bo'lsa, u holda B A dan oldin sodir bo'lishi mumkin emas; va agar ko'proq bo'lsa, ehtimol.
Vektorli soat
Lamport soatining mantiqiy rivojlanishi Vektorli soatdir. Ularning farqi shundaki, bu erda joylashgan har bir tugun o'zining alohida soatini o'z ichiga oladi va ular vektor sifatida uzatiladi.
Bunday holda, siz vektorning nol indeksi Feed uchun mas'ul ekanligini va vektorning birinchi indeksi Do'stlar uchun (bu tugunlarning har biri) ekanligini ko'rasiz. Va endi ular ko'payadi: yozishda "Ozuqa" ning nol ko'rsatkichi ortadi - 1, 2, 3:
Nima uchun Vektorli soat yaxshiroq? Chunki ular qaysi hodisalar bir vaqtning o'zida va turli tugunlarda qachon sodir bo'lishini aniqlashga imkon beradi. Bu MongoDB kabi sharding tizimi uchun juda muhim. Biroq, biz buni tanlamadik, garchi bu ajoyib narsa bo'lsa va u juda yaxshi ishlaydi va bu bizga mos kelishi mumkin ...
Agar bizda 10 ming parcha bo'lsa, biz 10 ming komponentni o'tkaza olmaymiz, hatto uni siqib qo'ysak yoki boshqa narsani o'ylab topsak ham - foydali yuk baribir ushbu vektorning hajmidan bir necha baravar kichik bo'ladi. Shuning uchun, biz yuragimizni va tishimizni g'ijirlatib, biz bu yondashuvdan voz kechdik va boshqasiga o'tdik.
TrueTime kaliti. Atom soati
Men Spanner haqida hikoya bo'lishini aytdim. Bu to'g'ridan-to'g'ri XNUMX-asrdan ajoyib narsa: atom soatlari, GPS sinxronizatsiyasi.
Qanday fikr bor? "Spanner" - bu Google tizimi bo'lib, u yaqinda odamlar uchun ham mavjud bo'ldi (ular unga SQL qo'shdilar). U erdagi har bir tranzaksiyada ma'lum vaqt belgisi mavjud. Vaqt sinxronlanganligi sababli*, har bir hodisaga ma'lum vaqt tayinlanishi mumkin - atom soatlari kutish vaqtiga ega, shundan so'ng boshqa vaqt "bo'lishi" kafolatlanadi.
Shunday qilib, oddiygina ma'lumotlar bazasiga yozish va bir muncha vaqt kutish orqali hodisaning ketma-ketligi avtomatik ravishda kafolatlanadi. Ular printsipial jihatdan tasavvur qilish mumkin bo'lgan eng kuchli Mustahkamlik modeliga ega - bu tashqi izchillik.
* Bu Lampart soatlarining asosiy muammosi - ular hech qachon taqsimlangan tizimlarda sinxronlashmaydi. Ular bir-biridan ajralib turishi mumkin; hatto NTP bilan ham ular juda yaxshi ishlamaydi. "Spanner" atom soatiga ega va sinxronizatsiya mikrosekundlarga o'xshaydi.
Nega biz tanlamadik? Bizning foydalanuvchilarimiz o'rnatilgan atom soatiga ega deb o'ylamaymiz. Ular paydo bo'lganda, har bir noutbukda o'rnatilgan bo'lsa, qandaydir super ajoyib GPS sinxronizatsiyasi bo'ladi - keyin ha... Lekin hozircha eng yaxshisi Amazon, Base Stations - fanatiklar uchun... Shuning uchun biz boshqa soatlardan foydalandik. .
Gibrid soat
Bu MongoDB-da Causal izchilligini ta'minlashda aniqlangan narsa. Qanday qilib ular gibrid? Gibrid skalyar qiymatdir, lekin u ikkita komponentdan iborat:
- Birinchisi, Unix davri ("kompyuter olamining boshlanishidan" necha soniya o'tdi).
- Ikkinchisi biroz o'sish, shuningdek, 32-bitli imzosiz int.
Hammasi shu, aslida. Bunday yondashuv mavjud: vaqt uchun mas'ul bo'lgan qism har doim soat bilan sinxronlashtiriladi; har safar yangilanish sodir bo'lganda, bu qism soat bilan sinxronlashtiriladi va vaqt har doim ko'proq yoki kamroq to'g'ri ekanligi ma'lum bo'ladi va o'sish bir vaqtning o'zida sodir bo'lgan voqealarni farqlash imkonini beradi.
Nima uchun bu MongoDB uchun muhim? Chunki bu sizga ma'lum bir vaqtning o'zida qandaydir zaxira restoranlarni yaratishga imkon beradi, ya'ni voqea vaqt bo'yicha indekslanadi. Bu muayyan hodisalar kerak bo'lganda muhimdir; Ma'lumotlar bazasi uchun hodisalar ma'lum vaqt oralig'ida sodir bo'lgan ma'lumotlar bazasidagi o'zgarishlardir.
Men sizga eng muhim sababni faqat sizga aytaman (iltimos, hech kimga aytmang)! Biz buni qildik, chunki MongoDB OpLog-da tartiblangan, indekslangan ma'lumotlar shunday ko'rinadi. OpLog - bu ma'lumotlar bazasidagi mutlaqo barcha o'zgarishlarni o'z ichiga olgan ma'lumotlar tuzilmasi: ular birinchi navbatda OpLog-ga o'tadilar, so'ngra takrorlangan sana yoki parcha bo'lsa, ular Saqlashning o'ziga qo'llaniladi.
Bu asosiy sabab edi. Shunga qaramay, ma'lumotlar bazasini ishlab chiqish uchun amaliy talablar ham mavjud, ya'ni u oddiy bo'lishi kerak - kichik kod, qayta yozish va sinab ko'rish kerak bo'lgan kamroq buzilgan narsalar. Bizning oploglarimiz gibrid soatlar tomonidan indekslanganligi ko'p yordam berdi va to'g'ri tanlov qilishimizga imkon berdi. Bu haqiqatan ham o'z samarasini berdi va qandaydir sehrli tarzda birinchi prototipda ishladi. Bu juda zo'r edi!
Soat sinxronizatsiyasi
Ilmiy adabiyotlarda tasvirlangan bir nechta sinxronlash usullari mavjud. Ikki xil shard mavjud bo'lganda, men sinxronizatsiya haqida gapiryapman. Agar bitta replika to'plami mavjud bo'lsa, hech qanday sinxronizatsiyaga hojat yo'q: bu "yagona usta"; bizda OpLog bor, unga barcha o'zgarishlar kiradi - bu holda, hamma narsa allaqachon "Oplog" ning o'zida ketma-ket tartiblangan. Ammo agar bizda ikki xil shard bo'lsa, bu erda vaqtni sinxronlashtirish muhimdir. Bu erda vektor soati ko'proq yordam berdi! Ammo bizda ular yo'q.
Ikkinchisi mos keladi - bu "Yurak urishi". Har bir vaqt birligida sodir bo'ladigan ba'zi signallarni almashish mumkin. Ammo yurak urishi juda sekin, biz mijozimizga kechikishni ta'minlay olmaymiz.
Haqiqiy vaqt, albatta, ajoyib narsa. Lekin, yana, bu, ehtimol, kelajakdir ... Atlasda allaqachon amalga oshirilishi mumkin bo'lsa-da, allaqachon tez "Amazon" vaqt sinxronizatorlari mavjud. Ammo u hamma uchun mavjud bo'lmaydi.
G'iybat - bu barcha xabarlar vaqtni o'z ichiga oladi. Bu biz ishlatadigan taxminan. Tugunlar orasidagi har bir xabar, drayver, ma'lumotlar tugunlari routeri, MongoDB uchun mutlaqo hamma narsa - bu qandaydir element, ishlaydigan soatni o'z ichiga olgan ma'lumotlar bazasi komponenti. Ular hamma joyda gibrid vaqtning ma'nosiga ega, u uzatiladi. 64 bit? Bu imkon beradi, bu mumkin.
Bularning barchasi birgalikda qanday ishlaydi?
Bu erda men buni biroz osonroq qilish uchun bitta replika to'plamini ko'rib chiqyapman. Birlamchi va ikkinchi darajali bor. Ikkilamchi replikatsiyani amalga oshiradi va har doim ham birlamchi bilan to'liq sinxronlashtirilmaydi.
"Birlamchi" ga ma'lum bir vaqt qiymati bilan kiritish sodir bo'ladi. Ushbu qo'shimcha ichki sonni 11 ga oshiradi, agar bu maksimal bo'lsa. Yoki u soat qiymatlarini tekshiradi va agar soat qiymatlari kattaroq bo'lsa, soat bilan sinxronlanadi. Bu sizga vaqt bo'yicha tartibga solish imkonini beradi.
U yozuvni amalga oshirgandan so'ng, muhim bir daqiqa sodir bo'ladi. Soat "MongoDB" da bo'lib, faqat "Oplog" ga yozilganda oshiriladi. Bu tizim holatini o'zgartiradigan hodisa. Mutlaqo barcha klassik maqolalarda xabar tugunga tushganda hodisa deb hisoblanadi: xabar keldi, ya'ni tizim o'z holatini o'zgartirdi.
Buning sababi, tadqiqot davomida ushbu xabar qanday talqin qilinishi to'liq aniq emas. Biz aniq bilamizki, agar u "Oplog" da aks ettirilmasa, u hech qanday talqin qilinmaydi va tizim holatining o'zgarishi faqat "Oplog" ga kirishdir. Bu biz uchun hamma narsani soddalashtiradi: model uni soddalashtiradi va uni bitta replika to'plami va boshqa ko'plab foydali narsalar ichida tartibga solish imkonini beradi.
"Oplog" ga allaqachon yozilgan qiymat qaytariladi - biz bilamizki, "Oplog" allaqachon ushbu qiymatni o'z ichiga oladi va uning vaqti 12. Endi, aytaylik, o'qish boshqa tugundan (Ikkinchi darajali) boshlanadi va u afterClusterTime ni ichida uzatadi. xabar. U shunday deydi: "Menga kamida 12 dan keyin yoki o'n ikkida sodir bo'lgan hamma narsa kerak" (yuqoridagi rasmga qarang).
Bu Causal a consent (CAT) deb ataladigan narsadir. Nazariyada shunday kontseptsiya mavjudki, bu o'z-o'zidan izchil bo'lgan vaqtning bir qismidir. Bunday holda, bu 12-daqiqada kuzatilgan tizimning holati deb aytishimiz mumkin.
Endi bu erda hali hech narsa yo'q, chunki bu turdagi birlamchi ma'lumotni takrorlash uchun ikkinchi darajali kerak bo'lgan vaziyatni simulyatsiya qiladi. U kutmoqda ... Va endi ma'lumotlar keldi - u bu qiymatlarni qaytaradi.
Hammasi shunday ishlaydi. Deyarli.
"Deyarli" nimani anglatadi? Faraz qilaylik, bularning barchasi qanday ishlashini o'qigan va tushungan odam bor. Men tushundimki, ClusterTime har safar paydo bo'lganda, u ichki mantiqiy soatni yangilaydi va keyin keyingi yozuv bittaga ko'payadi. Bu funksiya 20 qatorni oladi. Aytaylik, bu kishi eng katta 64 bitli raqamni, minus bittani uzatadi.
Nega "minus bir"? Ichki soat ushbu qiymatga almashtirilganligi sababli (aniqki, bu mumkin bo'lgan eng katta va joriy vaqtdan kattaroq), keyin "Oplog" da yozuv paydo bo'ladi va soat boshqa birlik bilan oshiriladi - va allaqachon mavjud. maksimal qiymat bo'ling (shunchaki barcha birliklar mavjud, boshqa boradigan joy yo'q) , unsaint ints).
Shundan so'ng tizim hech narsa uchun mutlaqo imkonsiz bo'lib qolishi aniq. Uni faqat tushirish va tozalash mumkin - juda ko'p qo'lda ish. To'liq mavjudligi:
Bundan tashqari, agar bu boshqa joyda takrorlansa, butun klaster shunchaki tushib ketadi. Har kim juda tez va oson tashkil qilishi mumkin bo'lgan mutlaqo qabul qilib bo'lmaydigan holat! Shuning uchun biz bu lahzani eng muhimlaridan biri deb hisobladik. Qanday qilib oldini olish mumkin?
Bizning yo'limiz clusterTime-ga imzo qo'yishdir
Xabarda shunday uzatiladi (ko'k matndan oldin). Ammo biz imzo (ko'k matn) yaratishni ham boshladik:
Imzo ma'lumotlar bazasi ichida, xavfsiz perimetr ichida saqlanadigan kalit tomonidan yaratiladi; o'zi yaratiladi va yangilanadi (foydalanuvchilar bu haqda hech narsa ko'rmaydilar). Xesh hosil bo'ladi va har bir xabar yaratilganda imzolanadi va qabul qilinganda tasdiqlanadi.
Ehtimol, odamlarning ongida savol tug'iladi: "Bu ishni qanchalik sekinlashtiradi?" Men sizga tez ishlashi kerakligini aytdim, ayniqsa bu xususiyat yo'q bo'lganda.
Bu holatda Causal izchillikdan foydalanish nimani anglatadi? Bu afterClusterTime parametrini ko'rsatish uchun. Busiz, u baribir qiymatlarni o'tkazadi. 3.6 versiyasidan boshlab g'iybat qilish har doim ishlaydi.
Imzolarning doimiy avlodini tark etadigan bo'lsak, u bizning yondashuv va talablarimizga javob bermaydigan xususiyat mavjud bo'lmagan taqdirda ham tizimni sekinlashtiradi. Xo'sh, biz nima qildik?
Tez qiling!
Bu juda oddiy narsa, lekin hiyla qiziq - men buni baham ko'raman, ehtimol kimdir qiziqadi.
Bizda imzolangan ma'lumotlarni saqlaydigan xesh mavjud. Barcha ma'lumotlar keshdan o'tadi. Kesh ma'lum vaqtni emas, balki diapazonni imzolaydi. Ba'zi qiymat kelganda, biz diapazonni yaratamiz, oxirgi 16 bitni maskalaymiz va biz ushbu qiymatni imzolaymiz:
Bunday imzoni olish orqali biz tizimni (nisbatan) 65 ming marta tezlashtiramiz. Bu juda yaxshi ishlaydi: biz tajribalar o'tkazganimizda, biz ketma-ket yangilanganimizda vaqt aslida 10 ming marta kamaydi. Ular qarama-qarshi bo'lganida, bu ishlamasligi aniq. Ammo ko'p amaliy holatlarda u ishlaydi. Imzo bilan Range imzosining kombinatsiyasi xavfsizlik muammosini hal qildi.
Biz nimani o'rgandik?
Bundan biz olgan saboqlar:
- Biz materiallar, hikoyalar, maqolalarni o'qishimiz kerak, chunki bizda juda ko'p qiziqarli narsalar bor. Biz biron bir xususiyat ustida ishlaganimizda (ayniqsa, hozir, biz tranzaktsiyalar qilganimizda va hokazo), biz o'qishimiz va tushunishimiz kerak. Bu vaqt talab etadi, lekin bu juda foydali, chunki bu bizning qayerda ekanligimizni aniq ko'rsatadi. Biz yangi hech narsa o'ylab topmadik - biz faqat ingredientlarni oldik.
Umuman olganda, akademik konferentsiya bo'lganda (masalan, Sigmon) fikrlashda ma'lum bir farq bor - har bir kishi yangi g'oyalarga e'tibor qaratadi. Bizning algoritmimizda nima yangilik? Bu erda ayniqsa yangi narsa yo'q. Yangilik ko'proq biz mavjud yondashuvlarni birlashtirganimizdadir. Shuning uchun, birinchi narsa, Lampartdan boshlab klassikalarni o'qishdir.
- Ishlab chiqarishda talablar butunlay boshqacha. Ishonchim komilki, sizlarning ko'pchiligingiz mavhum vakuumda "sferik" ma'lumotlar bazalari bilan emas, balki mavjudlik, kechikish va xatolarga chidamlilik bilan bog'liq muammolarga duch keladigan oddiy, haqiqiy narsalar bilan duch kelmoqdasiz.
- Oxirgi narsa shundaki, biz turli xil g'oyalarni ko'rib chiqishimiz va bir nechta mutlaqo boshqa maqolalarni bitta yondashuvga birlashtirishimiz kerak edi. Imzolash haqidagi g'oya, masalan, odatda Paxos protokolini ko'rib chiqqan maqoladan kelib chiqdi, bu Vizantiyalik bo'lmaganlar uchun avtorizatsiya protokoli ichida, Vizantiyaliklar uchun - avtorizatsiya protokolidan tashqarida ... Umuman olganda, biz aynan shu narsadir. qilish bilan yakunlandi.
Bu erda mutlaqo yangi narsa yo'q! Lekin biz hamma narsani aralashtirib yuborganimizdan so'ng ... Bu Olivier salatining retsepti bema'nilik ekanligini aytish bilan bir xil, chunki tuxum, mayonez va bodring allaqachon ixtiro qilingan ... Bu xuddi shu hikoya haqida.
Shu bilan tugataman. Rahmat!
Sizning savollaringiz
Tinglovchilar savoli (keyingi o'rinlarda B deb yuritiladi): - Rahmat, Mixail, hisobot uchun! Vaqt haqidagi mavzu qiziqarli. Siz G'iybatdan foydalanyapsiz. Ularning aytishicha, har kimning o'z vaqti bor, har kim o'z mahalliy vaqtini biladi. Men tushunganimdek, bizda haydovchi bor - haydovchilari bo'lgan mijozlar ko'p bo'lishi mumkin, so'rovlarni rejalashtiruvchilar ham, parchalar ham ... Va agar bizda to'satdan nomuvofiqlik paydo bo'lsa, tizim nimaga tushadi: kimdir buni bir kishi uchun deb qaror qiladi. daqiqa oldinda, kimdir bir daqiqa orqada? Biz qayerga kelamiz?
MT: - Haqiqatan ham ajoyib savol! Men shunchaki parchalar haqida gapirmoqchi edim. Agar men savolni to'g'ri tushunsam, bizda quyidagi holat mavjud: 1-qism va 2-qism bor, o'qish bu ikki parchadan sodir bo'ladi - ular bir-biriga mos kelmaydi, ular bir-biriga ta'sir qilmaydi, chunki ular biladigan vaqt har xil, ayniqsa, ular oploglarda mavjud bo'lgan vaqt.
Aytaylik, shard 1 millionlab yozuvlarni yaratdi, shard 2 hech narsa qilmadi va so'rov ikkita shardga keldi. Birinchisida esa milliondan ortiq AfterClusterTime bor. Bunday vaziyatda, men tushuntirganimdek, shard 2 hech qachon javob bermaydi.
Savol: - Men ular qanday sinxronlashayotganini va bitta mantiqiy vaqtni tanlashini bilmoqchi edim?
MT: - Sinxronizatsiya qilish juda oson. Shard, afterClusterTime unga kelganda va u "Oplog" da vaqt topa olmasa, hech qanday tasdiqlangan boshlash. Ya'ni, vaqtini qo'llari bilan shu qadriyatga ko'taradi. Bu shuni anglatadiki, unda ushbu so'rovga mos keladigan voqealar yo'q. U bu hodisani sun'iy ravishda yaratadi va shu tariqa Causal Consistent bo'ladi.
Savol: - Agar bundan keyin unga tarmoqning biron bir joyida yo'qolgan boshqa voqealar kelsa-chi?
MT: – Shard shunday yaratilganki, ular boshqa kelmaydi, chunki u bitta usta. Agar u allaqachon ro'yxatdan o'tgan bo'lsa, unda ular kelmaydi, lekin keyinroq keladi. Biror joyda biror narsa tiqilib qolishi mumkin emas, keyin u yozmaydi, keyin esa bu hodisalar keladi - va Causal izchillik buziladi. U hech qanday yozmasa, ularning hammasi keyingi kelishi kerak (u ularni kutadi).
Savol: – Navbatlar bo‘yicha bir qancha savollarim bor. Sabab-oqibat izchilligi, bajarilishi kerak bo'lgan harakatlarning o'ziga xos navbati mavjudligini taxmin qiladi. Agar paketlarimizdan biri yo'qolib qolsa nima bo'ladi? Mana, 10, 11... 12 g'oyib bo'ldi, qolganlar esa uning amalga oshishini kutmoqda. Va birdan mashinamiz halok bo'ldi, biz hech narsa qila olmaymiz. Amalga oshirishdan oldin to'planadigan navbatning maksimal uzunligi bormi? Har qanday davlat yo'qolganda qanday halokatli nosozlik yuz beradi? Bundan tashqari, agar biz oldingi holat borligini yozsak, unda qandaydir tarzda undan boshlash kerakmi? Ammo ular uni itarib yuborishmadi!
MT: - Shuningdek, ajoyib savol! Biz nima qilyapmiz? MongoDB kvorum yozadi, kvorum o'qiydi degan tushunchaga ega. Qanday hollarda xabar yo'qolishi mumkin? Agar yozish kvorum bo'lmasa yoki o'qish kvorum bo'lmasa (ba'zi bir axlat ham yopishib qolishi mumkin).
Sabab uyg'unligiga kelsak, katta eksperimental sinov o'tkazildi, natijada yozish va o'qishlar kvorum bo'lmagan taqdirda, Sabab uyg'unligining buzilishi sodir bo'ladi. Aynan siz aytganingiz!
Bizning maslahatimiz: Causal izchillikdan foydalanganda kamida kvorum o'qishidan foydalaning. Bunday holda, kvorum yozuvi yo'qolgan bo'lsa ham, hech narsa yo'qolmaydi... Bu ortogonal holat: agar foydalanuvchi ma'lumotlar yo'qolishini istamasa, u kvorum yozuvidan foydalanishi kerak. Sabablarning mustahkamligi chidamlilikni kafolatlamaydi. Chidamlilik replikatsiya va takrorlash bilan bog'liq mexanizmlar bilan kafolatlanadi.
Savol: – Biz uchun parchalanishni amalga oshiradigan misol yaratganimizda (mos ravishda master emas, balki qul), u o‘z mashinasining Unix vaqtiga yoki “master” vaqtiga tayanadi; U birinchi marta sinxronlanadimi yoki vaqti-vaqti bilanmi?
MT: - Hozir aniqlab beraman. Shard (ya'ni gorizontal bo'lim) - u erda har doim birlamchi mavjud. Va shardda "master" bo'lishi mumkin va u erda replikalar bo'lishi mumkin. Ammo parcha har doim yozib olishni qo'llab-quvvatlaydi, chunki u ba'zi domenlarni qo'llab-quvvatlashi kerak (shardda Asosiy mavjud).
Savol: - Demak, hamma narsa faqat "usta"ga bog'liqmi? Asosiy vaqt har doim ishlatiladimi?
MT: - Ha. Siz majoziy ma'noda aytishingiz mumkin: "master" ga, "Oplog" ga kirish sodir bo'lganda, soat chayqaladi.
Savol: - Bizda bog'langan mijoz bor va vaqt haqida hech narsa bilish shart emasmi?
MT: - Siz hech narsani bilishingiz shart emas! Agar mijozda qanday ishlashi haqida gapiradigan bo'lsak: mijoz Causal izchillikdan foydalanmoqchi bo'lganda, u sessiyani ochishi kerak. Endi hamma narsa bor: sessiyadagi tranzaksiyalar va huquqlarni olish... Seans - mijoz bilan sodir bo'ladigan mantiqiy hodisalarni tartibga solish.
Agar u ushbu seansni ochsa va u yerda Sabab uyg'unligini xohlashini aytsa (agar sessiya sukut bo'yicha Causal izchillikni qo'llab-quvvatlasa), hamma narsa avtomatik ravishda ishlaydi. Haydovchi bu vaqtni eslab qoladi va yangi xabar olganida uni oshiradi. Avvalgisi ma'lumotlarni qaytargan serverdan qanday javob qaytarganini eslab qoladi. Keyingi so'rovda afterCluster ("bundan kattaroq vaqt") bo'ladi.
Mijoz hech narsani bilishi shart emas! Bu uning uchun mutlaqo noaniq. Agar odamlar ushbu xususiyatlardan foydalansa, ular nima qilishlari mumkin? Birinchidan, siz ikkinchi darajali dasturlarni xavfsiz o'qishingiz mumkin: siz birlamchiga yozishingiz va geografik jihatdan takrorlangan ikkinchi darajali dasturlardan o'qishingiz va uning ishlashiga ishonch hosil qilishingiz mumkin. Shu bilan birga, birlamchida yozilgan seanslar hatto ikkinchi darajaga o'tkazilishi mumkin, ya'ni siz bitta emas, balki bir nechta seansdan foydalanishingiz mumkin.
Savol: – Hisoblash fanining yangi qatlami – CRDT (Conflict-free Replicated Data Types) ma’lumotlar turlari – yakuniy izchillik mavzusi bilan chambarchas bog‘liq. Ushbu turdagi ma'lumotlarni ma'lumotlar bazasiga integratsiyalashni o'ylab ko'rdingizmi va bu haqda nima deya olasiz?
MT: - Yaxshi savol! CRDT yozish mojarolari uchun mantiqiy: MongoDB da, bitta master.
Savol: – Menda devoplardan savolim bor. Haqiqiy dunyoda, Vizantiya muvaffaqiyatsizligi sodir bo'lganda va himoyalangan perimetr ichidagi yovuz odamlar protokolga kirishni, hunarmandchilik paketlarini maxsus tarzda jo'natishni boshlaganda shunday holatlar mavjudmi?
MT: - Perimetr ichidagi yovuz odamlar troyan otiga o'xshaydi! Perimetr ichidagi yovuz odamlar juda ko'p yomon ishlarni qilishlari mumkin.
Savol: – Aniqki, serverda, qo‘pol qilib aytganda, fillar bog‘ini qo‘yish va butun klasterni abadiy qulash mumkin bo‘lgan teshik qoldirib ketish... Qo‘lda tiklash uchun vaqt kerak bo‘ladi... Bu, yumshoq qilib aytganda, noto'g'ri. Boshqa tomondan, bu qiziq: haqiqiy hayotda, amalda, tabiiy ravishda shunga o'xshash ichki hujumlar sodir bo'lgan holatlar mavjudmi?
MT: - Haqiqiy hayotda men kamdan-kam hollarda xavfsizlik buzilishiga duch kelganim uchun, ular sodir bo'ladimi yoki yo'qligini ayta olmayman. Ammo rivojlanish falsafasi haqida gapiradigan bo'lsak, biz shunday deb o'ylaymiz: bizda xavfsizlikni ta'minlaydigan yigitlarni ta'minlaydigan perimetr bor - bu qal'a, devor; va perimetr ichida siz xohlagan narsani qilishingiz mumkin. Ko'rinib turibdiki, faqat ko'rish qobiliyatiga ega foydalanuvchilar va katalogni o'chirish qobiliyatiga ega foydalanuvchilar bor.
Huquqlarga qarab, foydalanuvchilarning zarari sichqoncha yoki fil bo'lishi mumkin. To'liq huquqqa ega foydalanuvchi hamma narsani qila olishi aniq. Cheklangan huquqlarga ega foydalanuvchi sezilarli darajada kamroq zarar etkazishi mumkin. Xususan, u tizimni buzolmaydi.
Savol: - Himoyalangan perimetrda kimdir serverni butunlay yo'q qilish uchun server uchun kutilmagan protokollarni yaratishga harakat qildi va agar omadingiz bo'lsa, butun klaster ... Hech qachon bu "yaxshi" bo'ladimi?
MT: "Men hech qachon bunday narsalarni eshitmaganman." Serverni shu tarzda ishdan chiqarishingiz hech kimga sir emas. Ichkarida muvaffaqiyatsiz bo'lish, protokoldan bo'lish, xabarda shunga o'xshash narsalarni yozishi mumkin bo'lgan vakolatli foydalanuvchi bo'lish ... Aslida, bu mumkin emas, chunki u hali ham tekshiriladi. Bu autentifikatsiyani istamagan foydalanuvchilar uchun o'chirib qo'yish mumkin - bu ularning muammosi; ular, qo'pol qilib aytganda, devorlarni o'zlari vayron qilishdi va siz u erda filni itarib yuborishingiz mumkin, u oyoq osti qiladi ... Lekin umuman olganda, siz ta'mirchi sifatida kiyinishingiz mumkin, keling va uni tortib oling!
Savol: - Hisobot uchun rahmat. Sergey (Yandex). Mongda Replika to'plamida ovoz beruvchi a'zolar sonini cheklovchi doimiy mavjud va bu doimiy 7 (etti) ga teng. Nima uchun bu doimiy? Nega bu qandaydir parametr emas?
MT: - Bizda 40 ta tugunli replika to'plamlari mavjud. Har doim ko'pchilik bo'ladi. Qaysi versiyani bilmayman ...
Savol: – Replika toʻplamida siz ovoz berish huquqiga ega boʻlmagan aʼzolarni ishga tushirishingiz mumkin, lekin koʻpi bilan 7 ta ovoz beruvchi aʼzolar mavjud. Agar replika toʻplamimiz 3 ta maʼlumot markazlarida tarqalgan boʻlsa, bu holatda yopilishdan qanday omon qolishimiz mumkin? Bitta ma'lumot markazi osongina o'chib ketishi mumkin va boshqa mashina tushib ketishi mumkin.
MT: - Bu allaqachon hisobot doirasidan biroz tashqarida. Bu umumiy savol. Balki bu haqda keyinroq aytib berarman.
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com