Келесі HighLoad++ конференциясы 6 жылдың 7 және 2020 сәуірінде Санкт-Петербургте өтеді.
Мәліметтер мен билеттер . HighLoad++ Сибирь 2019. «Красноярск» залы. 25 маусым, 12:00. Тезистер және .
Коммерциялық өнім үшін маңызды аспектілер ескерілмейтін практикалық талаптар теорияға қайшы келеді. Бұл баяндама коммерциялық өнімнің талаптарына негізделген академиялық зерттеулерге негізделген Себептік сәйкестік құрамдастарын құрудың әртүрлі тәсілдерін таңдау және біріктіру процесін ұсынады. Тыңдаушылар логикалық сағаттарға, тәуелділікті қадағалауға, жүйе қауіпсіздігіне, сағатты синхрондауға қатысты қолданыстағы теориялық тәсілдер және MongoDB неліктен белгілі бір шешімдерге негізделгені туралы білетін болады.
Михаил Тюленев (бұдан әрі – М.Т.): – Мен Себептік жүйелілік туралы айтатын боламын – бұл MongoDB-те жұмыс істеген мүмкіндік. Мен бөлінген жүйелер тобында жұмыс істеймін, біз мұны шамамен екі жыл бұрын жасадық.
Бұл процесте мен көптеген академиялық зерттеулермен танысуға тура келді, өйткені бұл мүмкіндік өте жақсы зерттелген. Кез келген өндірістік қосымшада болуы мүмкін өте нақты талаптарға байланысты бірде-бір мақала өндірістік дерекқорда талап етілетін нәрсеге сәйкес келмейтіні белгілі болды.
Мен академиялық зерттеулерді тұтынушылар ретінде біз одан қалай бірдеңе дайындайтынымыз туралы сөйлесетін боламын, содан кейін біз пайдаланушыларға қолдануға ыңғайлы және қауіпсіз дайын тағам ретінде ұсына аламыз.
Себептік сәйкестік. Ұғымдарға анықтама берейік
Бастау үшін, мен Себептік консистенцияның не екенін жалпы түрде айтқым келеді. Екі кейіпкер бар - Леонард пен Пенни («Үлкен жарылыс теориясы» телехикаясы):
Пенни Еуропада және Леонард оған тосын кеш ұйымдастырғысы келеді делік. Ол оны достарының тізімінен шығарып тастап, барлық достарына арнаға: «Пенниді қуантайық!» деп жаңартуды жіберуден артық ештеңе ойламайды. (ол Еуропада, ұйықтап жатқанда, ол мұның бәрін көрмейді және көре алмайды, өйткені ол жоқ). Сайып келгенде, ол бұл жазбаны жояды, оны арнадан өшіреді және ештеңені байқамауы және жанжал болмауы үшін кіруді қалпына келтіреді.
Мұның бәрі жақсы және жақсы, бірақ жүйе таратылды және бәрі дұрыс емес деп есептейік. Мысалы, егер оқиғалар себеп пен салдарға байланысты болмаса, Пеннидің кіруге шектеуі осы жазба пайда болғаннан кейін орын алуы мүмкін. Іс жүзінде, бұл іскерлік функцияны орындау үшін (бұл жағдайда) Себеп-салдарлық сәйкестікті қажет ететін мысал.
Шындығында, бұл дерекқордың тривиальды емес қасиеттері - өте аз адамдар оларды қолдайды. Үлгілерге көшейік.
Жүйелілік үлгілері
Дерекқорлардағы сәйкестік моделі дегеніміз не? Бұл үлестірілген жүйе клиент қандай деректерді және қандай ретпен қабылдай алатыны туралы беретін кепілдіктердің кейбірі.
Негізінде, барлық консистенциялық модельдер бөлінген жүйенің, мысалы, ноутбуктің бір түйінінде жұмыс істейтін жүйеге қаншалықты ұқсас екеніне байланысты. Мыңдаған гео-таратылған «түйіндерде» жұмыс істейтін жүйе осы қасиеттердің барлығы автоматты түрде орындалатын ноутбукке ұқсас.
Сондықтан жүйелілік үлгілері тек бөлінген жүйелерге қолданылады. Бұрын бар және бірдей тік масштабтауда жұмыс істейтін барлық жүйелерде мұндай проблемалар болған жоқ. Бір буферлік кэш болды және бәрі әрқашан одан оқылатын.
Модель күшті
Шындығында, ең бірінші модель - Күшті (немесе көтерілу қабілеті сызығы, оны жиі атайды). Бұл орын алғаны расталғаннан кейін әрбір өзгеріс жүйенің барлық пайдаланушыларына көрінетінін қамтамасыз ететін жүйелілік үлгісі.
Бұл дерекқордағы барлық оқиғалардың ғаламдық тәртібін жасайды. Бұл өте күшті консистенция қасиеті және ол әдетте өте қымбат. Дегенмен, бұл өте жақсы қолдауға ие. Бұл өте қымбат және баяу - ол сирек қолданылады. Бұл көтерілу қабілеті деп аталады.
Spanner бағдарламасында қолдау көрсетілетін тағы бір күшті сипат бар - Сыртқы консистенция деп аталады. Бұл туралы сәл кейінірек айтамыз.
Себеп
Келесісі - Себептік, дәл мен айтқан нәрсе. Күшті және Себептер арасында мен айтпайтын тағы бірнеше ішкі деңгейлер бар, бірақ олардың барлығы Себептерге дейін қайнатылады. Бұл маңызды модель, себебі ол барлық модельдердің ең күштісі, желі немесе бөлімдер болған кезде ең күшті консистенциясы.
Себептер – бұл оқиғалардың себеп-салдар байланысы арқылы байланысқан жағдай. Көбінесе олар клиенттің көзқарасы бойынша сіздің құқықтарыңызды оқыңыз деп қабылданады. Егер клиент кейбір құндылықтарды байқаса, ол бұрынғы құндылықтарды көре алмайды. Ол қазірдің өзінде префикс көрсеткіштерін көре бастады. Мұның бәрі бір нәрсеге келіп тіреледі.
Жүйелілік моделі ретіндегі себептер сервердегі оқиғалардың ішінара реттелуі болып табылады, онда барлық клиенттердің оқиғалары бір реттілікпен байқалады. Бұл жағдайда Леонард пен Пенни.
Оқиғалық
Үшінші үлгі – соңғы консистенция. Бұл барлық таратылған жүйелерді қолдайтын нәрсе, мағынасы бар минималды модель. Бұл мынаны білдіреді: деректерде кейбір өзгерістер болған кезде, олар белгілі бір уақытта сәйкес келеді.
Мұндай сәтте ол ештеңе айтпайды, әйтпесе ол Сыртқы Консистенцияға айналады - бұл мүлдем басқа әңгіме болар еді. Дегенмен, бұл өте танымал модель, ең көп таралған. Әдепкі бойынша, таратылған жүйелердің барлық пайдаланушылары Eventual Consistency пайдаланады.
Мен салыстырмалы мысалдар келтіргім келеді:
Бұл көрсеткілер нені білдіреді?
- Кешігу. Консистенцияның күші артқан сайын ол айқын себептерге байланысты үлкейеді: сізге көбірек жазбалар жасау керек, кластерге қатысатын барлық хосттар мен түйіндерден деректердің бар екенін растау керек. Тиісінше, Түпкі консистенция ең жылдам жауап береді, өйткені ол жерде, әдетте, оны жадыға тапсыруға болады және бұл, негізінен, жеткілікті болады.
- Қол жетімділік. Егер біз мұны жүйенің желілік үзілістер, бөлімдер немесе қандай да бір ақаулар болған кезде жауап беру қабілеті деп түсінетін болсақ, консистенциялық модель азайған сайын ақауларға төзімділік артады, өйткені біз үшін бір хост өмір сүріп, бір уақытта өмір сүрсе жеткілікті. уақыт кейбір деректерді шығарады. Түпкілікті консистенциясы деректер туралы ештеңеге кепілдік бермейді - бұл кез келген нәрсе болуы мүмкін.
- Аномалиялар. Бұл ретте, әрине, аномалиялар саны артады. Күшті консистенцияда олар мүлдем болмауы керек, бірақ түпкілікті консистенцияда олар кез келген нәрсе болуы мүмкін. Сұрақ туындайды: егер ол аномалияларды қамтыса, адамдар неге Eventual Consistency таңдайды? Жауап мынада: Түпнұсқалық консистенциясы үлгілері қолдануға болады және аномалиялар, мысалы, қысқа уақыт аралығында болады; дәйекті деректерді оқу және азды-көпті оқу үшін шеберді пайдалануға болады; Күшті консистенциялық үлгілерді жиі қолдануға болады. Іс жүзінде бұл жұмыс істейді және жиі ауытқулар саны уақыт бойынша шектеледі.
CAP теоремасы
Жүйелілік, қолжетімділік деген сөздерді көргенде ойыңызға не келеді? Бұл дұрыс - CAP теоремасы! Енді мен аңызды жоққа шығарғым келеді... Бұл мен емес – тамаша мақала, тамаша кітап жазған Мартин Клепманн.
CAP теоремасы 2000-жылдары тұжырымдалған принцип: Жүйелілік, Қол жетімділік, Бөлімдер: кез келген екеуін алсаңыз, үшеуін таңдай алмайсыз. Бұл белгілі бір принцип болды. Оны бірнеше жылдан кейін Гилберт пен Линч теорема ретінде дәлелдеді. Содан кейін бұл мантра ретінде қолданыла бастады - жүйелер CA, CP, AP және т.б. болып бөліне бастады.
Бұл теорема шын мәнінде келесі жағдайлар үшін дәлелденді... Біріншіден, қол жетімділік нөлден жүздікке дейінгі үздіксіз мән ретінде қарастырылмады (0 - жүйе «өлі», 100 - жылдам жауап береді; біз оны осылай қарастыруға дағдыланғанбыз) , бірақ алгоритмнің қасиеті ретінде оның барлық орындалуы үшін деректерді қайтаратынына кепілдік береді.
Жауап беру уақыты туралы мүлдем сөз жоқ! 100 жылдан кейін деректерді қайтаратын алгоритм бар - бұл CAP теоремасының бөлігі болып табылатын өте керемет қолжетімді алгоритм.
Екіншіден: теорема бұл өзгерістердің өлшемін өзгертуге болатынына қарамастан, бір кілттің мәндерінің өзгеруі үшін дәлелденді. Бұл шын мәнінде олар іс жүзінде қолданылмайды дегенді білдіреді, өйткені модельдер әртүрлі Түпкі консистенция, күшті консистенциясы (мүмкін).
Мұның бәрі не үшін? Сонымен қатар, CAP теоремасы дәл дәлелденген нысанда іс жүзінде қолданылмайды және сирек қолданылады. Теориялық түрде ол әйтеуір бәрін шектейді. Бұл интуитивті түрде дұрыс, бірақ тұтастай алғанда дәлелденбеген белгілі бір принцип болып шығады.
Себеп-салдарлық сәйкестік - ең күшті үлгі
Қазір болып жатқан нәрсе мынада, сіз үш нәрсені де ала аласыз: Бөлімдерді пайдалану арқылы жүйелілік, қол жетімділік. Атап айтқанда, Себептік консистенция - бұл Бөлімдер (желідегі үзілістер) болған кезде жұмыс істейтін ең күшті консистенция моделі. Сондықтан бұл үлкен қызығушылық тудырады, сондықтан біз оны қабылдадық.
Біріншіден, бұл қосымша әзірлеушілердің жұмысын жеңілдетеді. Атап айтқанда, серверден үлкен қолдаудың болуы: бір клиенттің ішінде орын алатын барлық жазбалар басқа клиентке бірдей ретпен келетініне кепілдік берілгенде. Екіншіден, ол бөлімдерге төтеп береді.
MongoDB ішкі асханасы
Түскі ас екенін есіне түсіріп, ас үйге көшеміз. Мен сізге жүйе моделі туралы айтып беремін, дәлірек айтқанда, мұндай дерекқор туралы бірінші рет естіп жатқандар үшін MongoDB дегеніміз не.
MongoDB (бұдан әрі «MongoDB») көлденең масштабтауды, яғни бөлшектеуді қолдайтын бөлінген жүйе болып табылады; және әрбір үзіндіде ол деректердің артық болуын, яғни репликацияны қолдайды.
MongoDB-де бөлу (реляциялық дерекқор емес) автоматты теңгерімдеуді жүзеге асырады, яғни құжаттардың әрбір жинағы (немесе реляциялық деректер бойынша «кесте») бөліктерге бөлінеді және сервер оларды автоматты түрде бөліктер арасында жылжытады.
Сұраныстарды тарататын Сұрау маршрутизаторы клиент үшін ол жұмыс істейтін кейбір клиент болып табылады. Ол қай жерде және қандай деректер орналасқанын біледі және барлық сұрауларды дұрыс бөлікке бағыттайды.
Тағы бір маңызды мәселе: MongoDB - бұл жалғыз шебер. Бір Негізгі бар - ол құрамындағы кілттерді қолдайтын жазбаларды қабылдай алады. Multi-master жазбасын жасай алмайсыз.
Біз 4.2 шығарылымын жасадық - онда жаңа қызықты нәрселер пайда болды. Атап айтқанда, олар Lucene - іздеуді - нақты орындалатын Java-ны тікелей Mongo-ға енгізді және ол жерде Elastica-дағы сияқты Lucene арқылы іздеуді жүзеге асыру мүмкін болды.
Және олар жаңа өнімді жасады - Диаграммалар, ол Atlas-та да қол жетімді (Mongo-ның жеке бұлты). Олардың тегін деңгейі бар - онымен ойнай аласыз. Маған қатты ұнады Диаграммалар – деректерді визуализациялау, өте интуитивті.
Ингредиенттер Себептік консистенциясы
Мен осы тақырып бойынша жарияланған 230-ға жуық мақаланы санадым - Лесли Ламперттен. Енді мен өз есімнен осы материалдардың кейбір бөліктерін сіздерге жеткіземін.
Барлығы Лесли Ламперттің 1970 жылдары жазылған мақаласынан басталды. Көріп отырғаныңыздай, бұл тақырып бойынша кейбір зерттеулер әлі де жалғасуда. Қазір Себептік жүйелілік бөлінген жүйелердің дамуына байланысты қызығушылықты бастан кешіруде.
Шектеулер
Қандай шектеулер бар? Бұл шын мәнінде негізгі сәттердің бірі, өйткені өндіріс жүйесі енгізетін шектеулер академиялық мақалалардағы шектеулерден айтарлықтай ерекшеленеді. Олар көбінесе жасанды.
- Біріншіден, «MongoDB» - бұл жалғыз шебер, мен айтқанымдай (бұл айтарлықтай жеңілдетеді).
- Жүйе шамамен 10 мың сынықтарды қолдауы керек деп санаймыз. Біз бұл құндылықты анық шектейтін сәулет шешімдерін қабылдай алмаймыз.
- Бізде бұлт бар, бірақ біз екілік файлды жүктеп алған кезде, оны ноутбукта іске қосқанда және бәрі тамаша жұмыс істегенде, адамның әлі де мүмкіндігі болуы керек деп есептейміз.
- Біз зерттеу сирек қабылдайтын нәрсені болжаймыз: сыртқы клиенттер қалағанын жасай алады. MongoDB ашық көзі болып табылады. Тиісінше, клиенттер соншалықты ақылды және ашулы болуы мүмкін - олар бәрін бұзғысы келеді. Византия фейлорлары пайда болуы мүмкін деп болжаймыз.
- Периметрден тыс сыртқы клиенттер үшін маңызды шектеу бар: егер бұл мүмкіндік өшірілсе, өнімділіктің төмендеуі байқалмауы керек.
- Тағы бір мәселе, әдетте, антиакадемиялық: алдыңғы және болашақ нұсқалардың үйлесімділігі. Ескі драйверлер жаңа жаңартуларды, ал дерекқор ескі драйверлерді қолдауы керек.
Жалпы, мұның бәрі шектеулер қояды.
Себептік консистенциясы компоненттері
Енді мен кейбір компоненттер туралы айтатын боламын. Себептік сәйкестікті жалпы қарастырсақ, блоктарды таңдай аламыз. Біз белгілі бір блокқа жататын жұмыстардың ішінен таңдадық: Тәуелділікті қадағалау, сағаттарды таңдау, бұл сағаттарды бір-бірімен қалай синхрондауға болады және біз қауіпсіздікті қалай қамтамасыз етеміз - бұл мен айтатын нәрселердің шамамен сызбасы:
Толық тәуелділікті қадағалау
Ол не үшін қажет? Деректерді шағылыстыру кезінде әрбір жазба, әрбір деректер өзгерісі қандай өзгерістерге байланысты екендігі туралы ақпаратты қамтиды. Ең бірінші және аңғал өзгеріс жазбаны қамтитын әрбір хабардың алдыңғы хабарлар туралы ақпаратты қамтитын кезі болып табылады:
Бұл мысалда бұйра жақшадағы сан жазба сандар болып табылады. Кейде мәндері бар бұл жазбалар тіпті толығымен тасымалданады, кейде кейбір нұсқалар тасымалданады. Қорытындысы, әрбір өзгеріс алдыңғысы туралы ақпаратты қамтиды (осының бәрін өз ішінде алып жүретіні анық).
Неліктен біз бұл тәсілді (толық бақылау) қолданбауды шештік? Әлбетте, өйткені бұл тәсіл практикалық емес: әлеуметтік желідегі кез келген өзгеріс сол әлеуметтік желідегі барлық алдыңғы өзгерістерге байланысты, айталық, Facebook немесе ВКонтакте әр жаңартуда. Соған қарамастан, толық тәуелділікті бақылау бойынша көптеген зерттеулер бар - бұл әлеуметтік желілерге дейінгі; кейбір жағдайларда ол шынымен де жұмыс істейді.
Айқын тәуелділікті бақылау
Келесісі шектеулі. Бұл жерде ақпараттың берілуі де қарастырылады, бірақ тек анық тәуелді. Неге байланысты, әдетте, Қолданбамен анықталады. Деректер репликацияланған кезде, сұрау алдыңғы тәуелділіктер қанағаттандырылған, яғни көрсетілген кезде ғана жауаптарды қайтарады. Бұл Себептік консистенцияның қалай жұмыс істейтінінің мәні.
Ол 5 жазбаның 1, 2, 3, 4 жазбаларына байланысты екенін көреді - сәйкесінше, клиент Пеннидің рұқсат беру шешімімен енгізілген өзгертулерге қол жеткізгенше күтеді.
Бұл бізге де сәйкес келмейді, өйткені ақпарат әлі де көп және ол жұмысты баяулатады. Басқа тәсіл бар ...
Лампорт сағаты
Олар өте ескі. Lamport Clock бұл тәуелділіктердің Лампорт сағаты деп аталатын скалярлық функцияға бүктелгенін білдіреді.
Скалярлық функция дегеніміз абстрактілі сан. Оны көбінесе логикалық уақыт деп атайды. Әрбір оқиғамен бұл есептегіш артады. Қазіргі уақытта процеске белгілі есептегіш әрбір хабарламаны жібереді. Процестердің синхрондалмауы мүмкін екені анық, олардың уақыттары мүлдем басқаша болуы мүмкін. Соған қарамастан, жүйе қандай да бір түрде сағатты осындай хабар алмасумен теңестіреді. Бұл жағдайда не болады?
Түсінікті болу үшін мен бұл үлкен сынықты екіге бөлдім: достар жинақтың бір бөлігін қамтитын бір түйінде және арна осы жинақтың бір бөлігін қамтитын басқа түйінде тұра алады. Олардың сызықтан қалай шығатыны анық па? Алдымен арна: «Көшірілді», содан кейін Достар деп айтады. Егер жүйе Достар жинағындағы "Достар" тәуелділіктері жеткізілмейінше арна көрсетілмейтініне қандай да бір кепілдік бермесе, бізде мен айтқан жағдай болады.
Арнадағы қарсы уақыттың қалай қисынды түрде артқанын көресіз:
Сонымен, осы Lamport сағатының және себептік сәйкестігінің негізгі қасиеті (Lamport Clock арқылы түсіндіріледі) мынада: егер бізде A және B оқиғалары болса және В оқиғасы A* оқиғасына тәуелді болса, онда А оқиғасының логикалық уақыты мынадан аз болады. В оқиғасының логикалық уақыты.
* Кейде олар А-ның В-ға дейін болғанын, яғни А-ның В-ға дейін болғанын айтады - бұл жалпы болған оқиғалардың бүкіл жиынтығын ішінара реттейтін белгілі бір қатынас.
Керісінше дұрыс емес. Бұл шын мәнінде Lamport сағатының негізгі кемшіліктерінің бірі - ішінара тапсырыс. Бір мезгілдегі оқиғалар туралы түсінік бар, яғни (А В-ға дейін болған) да, (А-сы В-ға дейін болған) оқиғалар. Мысал ретінде Леонардтың басқа біреуді дос ретінде қосуы (тіпті Леонард емес, Шелдон) болуы мүмкін.
Бұл Lamport сағаттарымен жұмыс істегенде жиі қолданылатын қасиет: олар функцияны арнайы қарастырады және осыдан бұл оқиғалар тәуелді болуы мүмкін деген қорытындыға келеді. Өйткені бір жол ақиқат: егер LogicalTime A LogicalTime B мәнінен аз болса, онда B A дейін болуы мүмкін емес; ал егер көп болса, мүмкін.
Векторлық сағат
Lamport сағатының логикалық дамуы векторлық сағат болып табылады. Олар мұнда орналасқан әрбір түйінде өзінің жеке сағаты болуымен ерекшеленеді және олар вектор ретінде беріледі.
Бұл жағдайда вектордың нөлдік индексі Feed үшін жауап беретінін, ал вектордың бірінші индексі Friends (осы түйіндердің әрқайсысы) үшін екенін көресіз. Ал енді олар көбейеді: жазу кезінде «Жемнің» нөлдік көрсеткіші артады – 1, 2, 3:
Векторлық сағат неге жақсырақ? Өйткені олар қандай оқиғалардың бір мезгілде болатынын және әртүрлі түйіндерде қашан орын алатынын анықтауға мүмкіндік береді. Бұл MongoDB сияқты sharding жүйесі үшін өте маңызды. Дегенмен, біз мұны таңдаған жоқпыз, бірақ бұл керемет нәрсе және ол керемет жұмыс істейді және ол бізге сәйкес келетін шығар ...
Егер бізде 10 мың сынықтар болса, біз оны қыссақ немесе басқа нәрсе ойлап тапсақ та, 10 мың құрамдас бөлікті тасымалдай алмаймыз - пайдалы жүктеме бәрібір осы вектордың көлемінен бірнеше есе аз болады. Сондықтан жүрегіміз бен тісімізді қайрап, біз бұл әдісті тастап, басқаға көштік.
TrueTime кілті. Атомдық сағат
Мен Спаннер туралы әңгіме болатынын айттым. Бұл XNUMX ғасырдан шыққан керемет нәрсе: атомдық сағаттар, GPS синхрондауы.
Қандай идея? «Spanner» - бұл жақында адамдарға қолжетімді болған Google жүйесі (олар оған SQL қосты). Мұндағы әрбір транзакцияның белгілі бір уақыт белгісі болады. Уақыт синхрондалған* болғандықтан, әрбір оқиғаға белгілі бір уақыт тағайындалуы мүмкін - атомдық сағаттардың күту уақыты болады, содан кейін басқа уақыттың «болуына» кепілдік беріледі.
Осылайша, жай ғана дерекқорға жазу және белгілі бір уақыт кезеңін күту арқылы оқиғаның сериялану мүмкіндігіне автоматты түрде кепілдік беріледі. Оларда принципті түрде елестетуге болатын ең күшті Консистенция моделі бар - бұл Сыртқы консистенциясы.
* Бұл Lampart сағаттарының негізгі мәселесі - олар ешқашан таратылған жүйелерде синхронды емес. Олар әртүрлі болуы мүмкін; NTP болса да, олар әлі де жақсы жұмыс істемейді. «Spanner» атомдық сағаты және синхронизациясы бар, бұл микросекундтар сияқты.
Біз неге таңдамадық? Біз пайдаланушыларымызда орнатылған атомдық сағат бар деп ойламаймыз. Олар пайда болған кезде, әрбір ноутбукке кіріктірілген, өте керемет GPS синхрондауының бір түрі болады - содан кейін иә... Бірақ әзірге ең жақсысы - Amazon, Base Stations - фанаттар үшін... Сондықтан біз басқа сағаттарды қолдандық. .
Гибридті сағат
Бұл шын мәнінде Causal сәйкестігін қамтамасыз ету кезінде MongoDB-де белгіленетін нәрсе. Олар қалай гибридті? Гибрид - скалярлық мән, бірақ оның екі құрамдас бөлігі бар:
- Біріншісі - Unix дәуірі («компьютер әлемінің басынан» қанша секунд өтті).
- Екіншісі - кейбір өсу, сонымен қатар 32-биттік қол қойылмаған int.
Мұның бәрі, шын мәнінде. Мұндай тәсіл бар: уақытқа жауапты бөлік барлық уақытта сағатпен синхрондалады; жаңарту орын алған сайын бұл бөлік сағатпен синхрондалады және уақыт әрқашан азды-көпті дұрыс болып шығады, ал ұлғайту бір уақытта болған оқиғаларды ажыратуға мүмкіндік береді.
Бұл MongoDB үшін неліктен маңызды? Өйткені ол белгілі бір уақытта мейрамханалардың қандай да бір резервтік көшірмесін жасауға мүмкіндік береді, яғни оқиға уақыт бойынша индекстеледі. Бұл белгілі бір оқиғалар қажет болғанда маңызды; Дерекқор үшін оқиғалар белгілі бір уақыт аралықтарында орын алған дерекқордағы өзгерістер болып табылады.
Мен сізге ең маңызды себебін тек сізге айтамын (өтінемін, ешкімге айтпаңыз)! Біз мұны істедік, себебі MongoDB OpLog жүйесінде ұйымдастырылған, индекстелген деректер осылай көрінеді. OpLog – дерекқордағы барлық өзгерістерді қамтитын деректер құрылымы: олар алдымен OpLog қызметіне өтеді, содан кейін олар қайталанатын күн немесе үзінді болған жағдайда Сақтаудың өзіне қолданылады.
Бұл басты себеп болды. Десе де, дерекқорды әзірлеуге практикалық талаптар да бар, яғни ол қарапайым болуы керек - аз код, қайта жазылуы және тексерілуі қажет мүмкіндігінше аз бұзылған нәрселер. Біздің оплогтарымыздың гибридті сағаттармен индекстелгені көп көмектесті және дұрыс таңдау жасауға мүмкіндік берді. Бұл шынымен де өз жемісін берді және қандай да бір сиқырлы түрде бірінші прототипте жұмыс істеді. Бұл өте керемет болды!
Сағат синхрондау
Ғылыми әдебиеттерде сипатталған бірнеше синхрондау әдістері бар. Мен екі түрлі үзінділер болған кезде синхрондау туралы айтып отырмын. Егер бір көшірме жиыны болса, ешқандай синхрондау қажет емес: бұл «бір басты»; бізде OpLog бар, оған барлық өзгерістер енеді - бұл жағдайда бәрі «Oplog» ішінде ретімен реттелген. Бірақ егер бізде екі түрлі үзінді болса, мұнда уақыт синхрондауы маңызды. Бұл жерде векторлық сағат көбірек көмектесті! Бірақ бізде олар жоқ.
Екіншісі қолайлы - бұл «Жүректің соғуы». Әр уақыт бірлігінде болатын кейбір сигналдарды алмасуға болады. Бірақ жүрек соғысы тым баяу, біз клиентке кідіріс бере алмаймыз.
Шынайы уақыт, әрине, керемет нәрсе. Бірақ, тағы да айтамын, бұл болашақ шығар... Оны Атласта жасауға болатын болса да, қазірдің өзінде жылдам «Amazon» уақыт синхронизаторлары бар. Бірақ ол барлығына қол жетімді болмайды.
Өсек айту - бұл барлық хабарламаларға уақытты қосу. Бұл шамамен біз қолданатын нәрсе. Түйіндер арасындағы әрбір хабарлама, драйвер, деректер түйінінің маршрутизаторы, MongoDB үшін барлығы - бұл қандай да бір элемент түрі, жұмыс істейтін сағатты қамтитын дерекқор құрамдас бөлігі. Олар барлық жерде гибридті уақыт мағынасына ие, ол беріледі. 64 бит? Бұл мүмкіндік береді, бұл мүмкін.
Мұның бәрі бірге қалай жұмыс істейді?
Мұнда мен оны жеңілдету үшін бір көшірме жинағын қарап жатырмын. Бастапқы және қосымша болып бөлінеді. Қосалқы репликация жасайды және әрқашан Бастапқымен толығымен синхрондалмайды.
Кірістіру белгілі бір уақыт мәнімен «Бастауышқа» орын алады. Бұл кірістіру ішкі санды 11-ге арттырады, егер бұл максимум болса. Немесе ол сағат мәндерін тексереді және сағат мәндері үлкенірек болса, сағатпен синхрондалады. Бұл уақыт бойынша ұйымдастыруға мүмкіндік береді.
Ол жазбаны жасағаннан кейін маңызды сәт орын алады. Сағат "MongoDB" ішінде және тек "Oplog"-ке жазған жағдайда ғана ұлғаяды. Бұл жүйенің күйін өзгертетін оқиға. Барлық классикалық мақалаларда хабарлама түйінге түскен кезде оқиға болып саналады: хабарлама келді, яғни жүйе өз күйін өзгертті.
Себебі, зерттеу барысында бұл хабардың қалай түсіндірілетіні толық белгісіз. Егер ол «Оплогта» көрсетілмесе, онда ол ешқандай жолмен түсіндірілмейтінін және жүйе күйінің өзгеруі «Оплогтағы» жазба ғана екенін анық білеміз. Бұл біз үшін бәрін жеңілдетеді: модель оны жеңілдетеді және оны бір реплика жиынтығында және басқа да көптеген пайдалы нәрселерде ұйымдастыруға мүмкіндік береді.
«Оплогқа» әлдеқашан жазылған мән қайтарылды - біз «Oplog» құрамында бұл мән бар екенін білеміз және оның уақыты 12. Енді, айталық, оқу басқа түйіннен (Екінші) басталады және ол afterClusterTime ішінде жібереді. хабар. Ол: «Маған кем дегенде 12-ден кейін немесе он екіде болғанның бәрі керек» дейді (жоғарыдағы суретті қараңыз).
Бұл Causal a consent (CAT) деп аталатын нәрсе. Теорияда мұндай тұжырымдама бар, бұл өздігінен сәйкес келетін уақыттың бір бөлігі. Бұл жағдайда жүйенің 12-ші уақытта байқалған күйі деп айта аламыз.
Енді бұл жерде әлі ештеңе жоқ, себебі бұл түрі бастапқыдан деректерді көшіру үшін Қосымша қажет болған жағдайды имитациялайды. Ол күтеді... Енді деректер келді - ол осы мәндерді қайтарады.
Барлығы осылай жұмыс істейді. Шамамен.
«Дерлік» нені білдіреді? Мұның бәрі қалай жұмыс істейтінін оқып, түсінген адам бар делік. Мен ClusterTime пайда болған сайын, ол ішкі логикалық сағатты жаңартып, содан кейін келесі жазба біреуге көбейетінін түсіндім. Бұл функция 20 жолды алады. Айталық, бұл адам ең үлкен 64 биттік санды, бір минус жібереді.
Неліктен «минус бір»? Ішкі сағат осы мәнге ауыстырылатындықтан (бұл мүмкін болатын ең үлкен және ағымдағы уақыттан үлкенірек), содан кейін «Oplog» ішінде жазба пайда болады және сағат басқа бірлікке ұлғаяды - және қазірдің өзінде болады. максималды мән болуы (барлық бірліктер бар, басқа баратын жер жоқ) , unsaint ints).
Осыдан кейін жүйе ешнәрсе үшін мүлдем қолжетімсіз болып қалатыны анық. Оны тек түсіруге және тазалауға болады - қолмен жұмыс көп. Толық қолжетімділік:
Оның үстіне, егер бұл басқа жерде қайталанса, онда бүкіл кластер жай ғана құлап кетеді. Кез келген адам өте тез және оңай ұйымдастыра алатын мүлдем қолайсыз жағдай! Сондықтан біз бұл сәтті ең маңызды сәттердің бірі деп санадық. Оны қалай болдырмауға болады?
Біздің жолымыз - clusterTime
Хабарламада (көк мәтіннің алдында) осылай беріледі. Бірақ біз қолтаңбаны (көк мәтін) жасай бастадық:
Қолтаңба дерекқордың ішінде, қауіпсіз периметр ішінде сақталатын кілт арқылы жасалады; өзі жасалады және жаңартылады (пайдаланушылар бұл туралы ештеңе көрмейді). Хэш жасалады және әрбір хабарлама жасалған кезде қол қойылады және қабылданған кезде расталады.
Адамдардың ойында: «Бұл жағдайды қаншалықты бәсеңдетеді?» Деген сұрақ туындауы мүмкін. Мен сізге, әсіресе бұл мүмкіндік болмаған кезде тез жұмыс істеуі керек екенін айттым.
Бұл жағдайда Себептік сәйкестікті пайдалану нені білдіреді? Бұл afterClusterTime параметрін көрсету үшін. Онсыз ол бәрібір құндылықтарды өткізеді. 3.6 нұсқасынан бастап өсек айту әрқашан жұмыс істейді.
Қолтаңбалардың тұрақты генерациясын қалдырсақ, ол біздің көзқарастарымыз бен талаптарымызға сәйкес келмейтін функция болмаған кезде де жүйені баяулатады. Сонымен біз не істедік?
Тез жасаңыз!
Бұл өте қарапайым нәрсе, бірақ трюк қызықты - мен онымен бөлісемін, мүмкін біреу қызықтырады.
Бізде қол қойылған деректерді сақтайтын хэш бар. Барлық деректер кэш арқылы өтеді. Кэш белгілі бір уақытқа емес, Ауқымға қол қояды. Кейбір мән келгенде, біз Ауқымды жасаймыз, соңғы 16 битті жасырамыз және осы мәнге қол қоямыз:
Осындай қолтаңбаны алу арқылы біз жүйені (салыстырмалы түрде) 65 мың есе жеделдетеміз. Бұл керемет жұмыс істейді: біз эксперименттер жасаған кезде, біз дәйекті жаңарту болған кезде уақыт шын мәнінде 10 мың есе қысқарды. Олар қайшылықта болған кезде бұл жұмыс істемейтіні анық. Бірақ көп жағдайда ол жұмыс істейді. Диапазон қолтаңбасының қолтаңбамен тіркесімі қауіпсіздік мәселесін шешті.
Біз не үйрендік?
Бұдан алған тағылымы:
- Бізге материалдарды, әңгімелерді, мақалаларды оқу керек, өйткені бізде қызықты нәрселер көп. Біз қандай да бір функциямен жұмыс істегенде (әсіресе қазір, біз транзакциялар жасаған кезде және т.б.), біз оқып, түсінуіміз керек. Бұл уақытты қажет етеді, бірақ бұл өте пайдалы, өйткені ол біздің қай жерде екенімізді көрсетеді. Біз жаңа ештеңе ойлап таппадық – біз жай ғана ингредиенттерді алдық.
Жалпы, академиялық конференция болған кезде ойлаудың белгілі бір айырмашылығы бар (мысалы, Сигмон) - әркім жаңа идеяларға назар аударады. Алгоритмімізде қандай жаңалық бар? Мұнда ерекше жаңа ештеңе жоқ. Жаңашылдық бұрыннан бар тәсілдерді біріктіру жолында жатыр. Сондықтан, ең алдымен, Лампарттан бастап классиканы оқу керек.
- Өндірісте талаптар мүлдем басқаша. Сіздердің көпшілігіңіз абстрактілі вакуумдағы «сфералық» дерекқорлармен емес, қолжетімділік, кідіріс және ақауларға төзімділік мәселелері бар қалыпты, нақты нәрселермен бетпе-бет келгеніңізге сенімдімін.
- Соңғысы, біз әртүрлі идеяларды қарастырып, бірнеше мүлдем басқа мақалаларды бір тәсілге біріктіруіміз керек болды. Қол қою туралы идея, мысалы, әдетте Византиядан басқа сәтсіздіктер үшін рұқсат хаттамасының ішінде, византиялықтар үшін - рұқсат хаттамасынан тыс болатын Paxos хаттамасын қарастыратын мақаладан шыққан ... Жалпы алғанда, біз дәл осылай ойлаймыз. істеп бітті.
Мұнда мүлдем жаңа ештеңе жоқ! Бірақ біз бәрін араластыра салысымен... Оливье салатының рецепті нонсенс дегенмен бірдей, өйткені жұмыртқаны, майонезді және қиярды ойлап тапқан... Бұл бір әңгіме туралы.
Мен мұнымен аяқтаймын. Рақмет сізге!
Сіздің сұрақтарыңыз
Аудиторияның сұрағы (бұдан әрі – В): – Рахмет, Михаил, баяндамаңызға! Уақыт туралы тақырып қызық. Сіз өсек айтуды қолданасыз. Әркімнің өз уақыты бар, әркім өзінің жергілікті уақытын біледі деді. Менің түсінуімше, бізде драйвер бар - драйверлері бар көптеген клиенттер болуы мүмкін, сұранысты жоспарлаушылары да, сынықтары да бар... Ал егер бізде кенеттен сәйкессіздік пайда болса, жүйе немен аяқталады: біреу оны біреуге арналған деп шешеді. минут алға, біреу бір минут артта? Біз қайда боламыз?
МТ: – Тамаша сұрақ! Мен жай ғана сынықтар туралы айтқым келді. Егер мен сұрақты дұрыс түсінсем, бізде мынадай жағдай бар: 1-ші және 2-ші сынық бар, оқу осы екі сынықтан пайда болады - оларда сәйкессіздік бар, олар бір-бірімен араласпайды, өйткені олардың білетін уақыты әртүрлі, әсіресе олардың оплогтарда болатын уақыты.
Shard 1 миллион жазба жасады делік, shard 2 мүлдем ештеңе жасамады және сұрау екі шердке келді. Ал біріншісінде миллионнан асатын AfterClusterTime бар. Мұндай жағдайда, мен түсіндіргендей, shard 2 ешқашан жауап бермейді.
Q: – Мен олардың синхрондау және бір логикалық уақытты қалай таңдайтынын білгім келді?
МТ: - Синхрондау өте оңай. Shard, оған afterClusterTime келгенде және ол «Оплогта» уақыт таппағанда, мақұлданған жоқ. Яғни, уақытын қолымен осы құндылыққа көтереді. Бұл оның осы сұрауға сәйкес оқиғалары жоқ екенін білдіреді. Ол бұл оқиғаны жасанды түрде жасайды және осылайша Себептік Консистенцияға айналады.
Q: – Егер осыдан кейін желіде жоғалып кеткен басқа да оқиғалар оның басына түссе ше?
МТ: – Сынық бір ғана шебер болғандықтан, олар енді келмейтіндей етіп жасалған. Егер ол жазылып қойған болса, онда олар келмейді, бірақ кейінірек келеді. Бір жерде бірдеңе тұрып қалуы мүмкін емес, содан кейін ол жазбайды, содан кейін бұл оқиғалар келеді - және Себептік консистенция бұзылады. Ол жазбаған кезде, олардың бәрі келесі кезекте келуі керек (ол оларды күтеді).
Q: – Менің кезекке қатысты бірнеше сұрағым бар. Себеп-салдарлық жүйелілік орындауды қажет ететін әрекеттердің белгілі бір кезегі бар екенін болжайды. Біздің пакеттеріміздің бірі жоғалып кетсе не болады? Міне, 10-шы, 11-ші... 12-сі жоғалып кетті, қалғандары оның орындалуын күтуде. Кенеттен көлігіміз өлді, біз ештеңе істей алмаймыз. Орындау алдында жинақталатын кезектің максималды ұзындығы бар ма? Кез келген күй жоғалған кезде қандай өлімге әкелетін сәтсіздік орын алады? Оның үстіне бұрынғы күй бар деп жазсақ, әйтеуір осыдан бастау керек пе? Бірақ олар оны итеріп жібермеді!
МТ: – Сондай-ақ тамаша сұрақ! Біз не істеп жатырмыз? MongoDB-де кворум жазады, кворум оқиды деген ұғым бар. Қандай жағдайларда хабарлама жоғалуы мүмкін? Жазу кворум болмаған кезде немесе оқу кворум болмаған кезде (қоқыстардың кейбір түрлері де жабысып қалуы мүмкін).
Себеп-салдарлық сәйкестікке қатысты үлкен эксперименттік сынақ жүргізілді, оның нәтижесі жазулар мен оқулар кворум болмаған жағдайда Себептік жүйеліліктің бұзылуы орын алды. Дәл сіз айтқандай!
Біздің кеңес: Себептік сәйкестікті пайдалану кезінде кем дегенде кворум оқуын пайдаланыңыз. Бұл жағдайда кворум жазбасы жоғалса да ештеңе жоғалмайды... Бұл ортогональды жағдай: егер пайдаланушы деректердің жоғалуын қаламаса, оған кворум жазбасын пайдалану қажет. Себептік консистенция беріктікке кепілдік бермейді. Төзімділікке репликациямен және репликациямен байланысты техникамен кепілдік беріледі.
Q: – Біз үшін бөлшектеуді орындайтын дананы жасағанда (тиісінше шебер емес, құл), ол өз машинасының Unix уақытына немесе «шебердің» уақытына сүйенеді; Ол бірінші рет синхрондалады ма, әлде мерзімді ме?
МТ: – Қазір нақтылаймын. Shard (яғни, көлденең бөлім) – онда әрқашан Бастауыш болады. Ал сынықтың «шебері» болуы мүмкін және репликалар болуы мүмкін. Бірақ сынық әрқашан жазуды қолдайды, себебі ол кейбір доменді қолдауы керек (үзіндіде Негізгі бар).
Q: – Сонда бәрі тек «шеберге» байланысты ғой? Мастер уақыты әрқашан пайдаланылады ма?
МТ: - Иә. Сіз бейнелі түрде айта аласыз: «шеберге», «оплогқа» кіру орын алған кезде сағат қозғалады.
Q: – Бізде қосылатын және уақыт туралы ештеңе білудің қажеті жоқ клиент бар ма?
МТ: – Ештеңені білудің қажеті жоқ! Егер оның клиентте қалай жұмыс істейтіні туралы айтатын болсақ: клиент Себептік сәйкестікті пайдаланғысы келгенде, ол сеансты ашуы керек. Енді бәрі бар: сеанстағы транзакциялар және құқықтарды алу... Сеанс – клиентпен болатын логикалық оқиғаларды ретке келтіру.
Егер ол осы сеансты ашса және сол жерде Себептік сәйкестікті қалайтынын айтса (сеанс әдепкі бойынша Себептік сәйкестікті қолдаса), бәрі автоматты түрде жұмыс істейді. Жүргізуші бұл уақытты есіне алады және жаңа хабарлама алған кезде оны көбейтеді. Ол деректерді қайтарған серверден алдыңғысының қандай жауап қайтарғанын есте сақтайды. Келесі сұрауда afterCluster («бұдан артық уақыт») болады.
Клиент мүлдем ештеңе білудің қажеті жоқ! Бұл оған мүлдем түсініксіз. Егер адамдар осы мүмкіндіктерді пайдаланса, олар не істей алады? Біріншіден, қосымшаларды қауіпсіз оқуға болады: Бастапқыға жазуға және географиялық қайталанатын қосымшалардан оқуға және оның жұмыс істейтініне көз жеткізуге болады. Сонымен қатар, Бастапқыда жазылған сеанстарды тіпті Екіншіге ауыстыруға болады, яғни бір сеансты емес, бірнешеуін пайдалануға болады.
Q: – Есептеу ғылымының жаңа деңгейі – CRDT (Қақтығыссыз репликацияланған деректер түрлері) деректер түрлері – Түпнұсқа сәйкестік тақырыбымен қатты байланысты. Осы деректер түрлерін дерекқорға біріктіруді қарастырдыңыз ба және ол туралы не айта аласыз?
МТ: - Жақсы сұрақ! CRDT жазу қақтығыстары үшін мағынасы бар: MongoDB-де, жалғыз басты.
Q: – Девоптардан сұрағым бар. Шынайы әлемде Византия сәтсіздігі орын алған және қорғалған периметрдің ішіндегі зұлым адамдар хаттамаға кіріп, қолөнер пакеттерін ерекше жолмен жібере бастағанда осындай иезуиттік жағдайлар бар ма?
МТ: – Периметрдің ішіндегі зұлым адамдар троялық жылқыға ұқсайды! Периметрдің ішіндегі зұлым адамдар көп жамандық жасай алады.
Q: – Дөрекі айтқанда, серверде пілдердің хайуанаттар бағын салып, бүкіл кластерді біржола құлата алатын саңылау қалдыру анық... Қолмен қалпына келтіру үшін уақыт қажет... Бұл, жұмсақ тілмен айтқанда, қате. Екінші жағынан, бұл қызықты: нақты өмірде, іс жүзінде, табиғи түрде ұқсас ішкі шабуылдар орын алатын жағдайлар бар ма?
МТ: – Мен нақты өмірде қауіпсіздікті бұзуды сирек кездестіретіндіктен, олардың орын алғанын айта алмаймын. Бірақ даму философиясы туралы айтатын болсақ, біз былай ойлаймыз: бізде қауіпсіздікті қамтамасыз ететін жігіттерді қамтамасыз ететін периметр бар - бұл қамал, қабырға; және периметрдің ішінде сіз өзіңіз қалаған нәрсені жасай аласыз. Тек қарау мүмкіндігі бар пайдаланушылар бар және каталогты өшіру мүмкіндігі бар пайдаланушылар бар екені анық.
Құқықтарға байланысты пайдаланушылар жасай алатын зиян тінтуір немесе піл болуы мүмкін. Толық құқығы бар пайдаланушының барлығын жасай алатыны анық. Шектеулі құқықтары бар пайдаланушы айтарлықтай аз зиян келтіруі мүмкін. Атап айтқанда, ол жүйені бұза алмайды.
Q: – Қорғалған периметрде біреу серверді толығымен жою үшін сервер үшін күтпеген хаттамаларды жасауға тырысты, ал егер сәттілік болса, бүкіл кластер... Бұл «жақсы» бола ма?
МТ: «Мен мұндай нәрселер туралы ешқашан естіген емеспін». Серверді осылайша бұзып жіберуіңіз ешкімге құпия емес. Ішінде сәтсіздікке ұшырау, хаттамадан болу, хабарламада осындай нәрсені жаза алатын авторизацияланған пайдаланушы болу ... Шындығында, бұл мүмкін емес, өйткені ол әлі де тексерілетін болады. Оны қаламайтын пайдаланушылар үшін бұл аутентификацияны өшіруге болады - бұл олардың мәселесі; олар, дөрекі айтқанда, қабырғаларды өздері қиратып тастады, сонда сіз пілді итеріп жібере аласыз, ол таптап тастайды ... Бірақ жалпы алғанда, сіз жөндеуші болып киініп аласыз, келіңіз және тартып алыңыз!
Q: – Баяндама үшін рахмет. Сергей (Яндекс). Монгта Реплика жиынындағы дауыс беретін мүшелер санын шектейтін тұрақты мән бар және бұл тұрақты 7 (жеті). Неліктен бұл тұрақты? Неліктен бұл қандай да бір параметр емес?
МТ: – Бізде 40 түйіні бар реплика жиынтығы бар. Әрқашан көпшілік бар. Қай нұсқа екенін білмеймін...
Q: – Реплика жинағында дауыс беруге құқығы жоқ мүшелерді іске қосуға болады, бірақ ең көбі 7 дауыс беретін мүше бар. Егер біздің Replica Set 3 деректер орталығына таралған болса, бұл жағдайда өшіруден қалай аман қалуға болады? Бір деректер орталығы оңай өшуі мүмкін, ал басқа құрылғы құлап кетуі мүмкін.
МТ: – Бұл қазірдің өзінде баяндаманың шеңберінен сәл асып кетті. Бұл жалпы сұрақ. Мүмкін мен бұл туралы кейінірек айта аламын.
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com