Следећа ХигхЛоад++ конференција биће одржана 6. и 7. априла 2020. године у Санкт Петербургу.
Детаљи и карте . ХигхЛоад++ Сибир 2019. Хала "Краснојарск". 25. јун, 12:00. Тезе и .
Дешава се да су практични захтеви у сукобу са теоријом, при чему се не узимају у обзир аспекти важни за комерцијални производ. Овај говор представља процес одабира и комбиновања различитих приступа стварању компоненти узрочне конзистентности заснованих на академском истраживању заснованом на захтевима комерцијалног производа. Слушаоци ће научити о постојећим теоријским приступима логичким сатовима, праћењу зависности, безбедности система, синхронизацији часовника и зашто се МонгоДБ определио за одређена решења.
Михаил Тјулењев (у даљем тексту МТ): – Говорићу о каузалној доследности – ово је карактеристика на којој смо радили у МонгоДБ-у. Радим у групи дистрибуираних система, урадили смо то пре две године.
У том процесу, морао сам да се упознам са много академских истраживања, јер је ова карактеристика прилично добро проучавана. Показало се да се ниједан чланак не уклапа у оно што је потребно у производној бази података због врло специфичних захтева који су вероватно присутни у било којој производној апликацији.
Говорићу о томе како ми, као потрошачи академских истраживања, од тога припремамо нешто што можемо да представимо нашим корисницима као готово јело које је згодно и безбедно за употребу.
Узрочна доследност. Хајде да дефинишемо појмове
За почетак, желим да кажем уопштено шта је узрочна доследност. Постоје два лика - Леонард и Пени (ТВ серија "Теорија великог праска"):
Рецимо да је Пени у Европи и Леонард жели да јој приреди забаву изненађења. И не може смислити ништа боље од тога да је избаци са своје листе пријатеља, шаљући свим својим пријатељима ажурирање на феед-у: „Хајде да учинимо Пени срећном!“ (она је у Европи, док спава, она све ово не види и не може да види, јер је нема). На крају, она брише овај пост, брише га из Феед-а и враћа приступ тако да ништа не примети и да нема скандала.
Ово је све у реду, али претпоставимо да је систем дистрибуиран и да су ствари кренуле мало по злу. Може се, на пример, десити да је Пеннино ограничење приступа дошло након што се овај пост појавио, ако догађаји нису повезани узрочно-последично. Заправо, ово је пример када је потребна узрочна доследност да би се обављала пословна функција (у овом случају).
У ствари, ово су прилично нетривијална својства базе података - врло мало људи их подржава. Пређимо на моделе.
Модели конзистентности
Шта је тачно модел конзистентности у базама података? Ово су неке од гаранција које дистрибуирани систем даје о томе које податке клијент може да прими и којим редоследом.
У принципу, сви модели доследности се своде на то колико је дистрибуирани систем сличан систему који ради, на пример, на једном чвору на лаптопу. И овако је сличан систем који ради на хиљадама гео-дистрибуираних „чворова“ лаптопу, у којем се сва ова својства у принципу изводе аутоматски.
Стога се модели конзистентности примењују само на дистрибуиране системе. Сви системи који су раније постојали и радили на истом вертикалном скалирању нису имали такве проблеме. Постојао је један кеш бафера и из њега се увек све читало.
Модел Стронг
Заправо, први модел је Стронг (или линија способности пораста, како се често назива). Ово је модел конзистентности који обезбеђује да свака промена, када се једном потврди да се догодила, буде видљива свим корисницима система.
Ово ствара глобални поредак свих догађаја у бази података. Ово је веома јака својства конзистенције и генерално је веома скупа. Међутим, то је веома добро подржано. Само је веома скуп и спор - само се ретко користи. Ово се зове способност успона.
Постоји још једно, јаче својство које је подржано у Спаннер-у - названо Екстерна конзистентност. Причаћемо о томе мало касније.
Каузални
Следећи је Узрочно, о чему сам управо говорио. Постоји још неколико поднивоа између Јаког и Узрочног о којима нећу да говорим, али се сви своде на Узрочно. Ово је важан модел јер је најјачи од свих модела, најјача доследност у присуству мреже или партиција.
Узроци су заправо ситуација у којој су догађаји повезани узрочно-последичном везом. Врло често се доживљавају као Читајте своја права са становишта клијента. Ако је клијент уочио неке вредности, он не може да види вредности које су биле у прошлости. Већ почиње да види очитавања префикса. Све се своди на исто.
Узроци као модел конзистентности су делимични редослед догађаја на серверу, у коме се догађаји од свих клијената посматрају у истом редоследу. У овом случају, Леонард и Пени.
Евентуално
Трећи модел је Евентуална конзистентност. То је оно што подржавају апсолутно сви дистрибуирани системи, минимални модел који уопште има смисла. То значи следеће: када имамо неке промене у подацима, оне у неком тренутку постају конзистентне.
У таквом тренутку она ништа не говори, иначе би се претворила у Спољну доследност – то би била сасвим друга прича. Ипак, ово је веома популаран модел, најчешћи. Подразумевано, сви корисници дистрибуираних система користе Евентуал Цонсистенци.
Желим да дам неке упоредне примере:
Шта значе ове стрелице?
- Латентност. Како се снага конзистентности повећава, она постаје већа из очигледних разлога: потребно је да направите више записа, добијете потврду од свих хостова и чворова који учествују у кластеру да су подаци већ тамо. Сходно томе, Евентуална доследност има најбржи одговор, јер тамо, по правилу, можете чак и да га запамтите и то ће у принципу бити довољно.
- Доступност. Ако ово схватимо као способност система да реагује у присуству прекида мреже, партиција или неке врсте квара, толеранција грешака се повећава како се модел конзистентности смањује, јер нам је довољно да један хост живи и да истовремено време производи неке податке. Евентуална доследност уопште не гарантује ништа у вези са подацима - може бити било шта.
- Аномалије. Истовремено се, наравно, повећава број аномалија. У јакој доследности скоро да уопште не би требало да постоје, али у коначној доследности могу бити било шта. Поставља се питање: зашто људи бирају Евентуал Цонсистент ако садржи аномалије? Одговор је да су модели Евентуалне конзистентности применљиви и да аномалије постоје, на пример, у кратком временском периоду; могуће је користити чаробњак за читање и мање или више конзистентне податке; Често је могуће користити моделе јаке конзистенције. У пракси ово функционише, а често је број аномалија временски ограничен.
ЦАП теорема
Када видите речи доследност, доступност – шта вам пада на памет? Тако је - ЦАП теорема! Сада желим да развејем мит... Нисам ја - то је Мартин Клеппманн, који је написао диван чланак, дивну књигу.
ЦАП теорема је принцип формулисан 2000-их да конзистентност, доступност, партиције: узмите било која два, а не можете изабрати три. То је био одређени принцип. То су као теорему доказали неколико година касније Гилберт и Линч. Онда је ово почело да се користи као мантра - системи су почели да се деле на ЦА, ЦП, АП и тако даље.
Ова теорема је заправо доказана за следеће случајеве... Прво, доступност се не сматра континуираном вредношћу од нуле до стотине (0 – систем је „мртав“, 100 – брзо реагује; навикли смо да га тако сматрамо) , већ као својство алгоритма , које гарантује да за сва своја извршавања враћа податке.
О времену одговора уопште нема ни речи! Постоји алгоритам који враћа податке након 100 година - апсолутно диван доступан алгоритам, који је део ЦАП теореме.
Друго: теорема је доказана за промене вредности истог кључа, упркос чињеници да се ове промене могу променити. То значи да се у стварности практично не користе, јер су модели различити Евентуална конзистенција, Стронг Цонсистенци (можда).
чему све ово? Штавише, ЦАП теорема у управо оном облику у коме је доказана практично није применљива и ретко се користи. У теоријској форми, то некако све ограничава. Испоставља се одређени принцип који је интуитивно тачан, али генерално није доказан.
Узрочна доследност је најјачи модел
Оно што се сада дешава је да можете добити све три ствари: конзистентност, доступност користећи партиције. Конкретно, узрочна конзистентност је најјачи модел конзистентности, који и даље ради у присуству партиција (прекиди у мрежи). Зато је то тако велико интересовање, и зато смо је преузели.
Прво, то поједностављује рад програмера апликација. Конкретно, присуство велике подршке са сервера: када сви записи који се јављају унутар једног клијента гарантовано стижу у истом редоследу на другом клијенту. Друго, издржава преграде.
МонгоДБ Унутрашња кухиња
Сетивши се да је ручак, крећемо у кухињу. Рећи ћу вам о моделу система, наиме, шта је МонгоДБ за оне који први пут чују за такву базу података.
МонгоДБ (у даљем тексту „МонгоДБ“) је дистрибуирани систем који подржава хоризонтално скалирање, односно разбијање; а унутар сваког шарда подржава и редундантност података, односно репликацију.
Схардинг у МонгоДБ-у (а не релационој бази података) врши аутоматско балансирање, то јест, свака колекција докумената (или „табела“ у смислу релационих података) је подељена на делове, а сервер их аутоматски премешта између делова.
Куери Роутер, који дистрибуира захтеве, за клијента је неки клијент преко кога ради. Већ зна где и који подаци се налазе и све захтеве усмерава на исправан шард.
Још једна важна тачка: МонгоДБ је један мастер. Постоји један примарни - може да узима записе који подржавају кључеве које садржи. Не можете да урадите Мулти-мастер писање.
Направили смо издање 4.2 - појавиле су се нове занимљиве ствари. Конкретно, убацили су Луцене – претрагу – односно извршну јава директно у Монго, и тамо је постало могуће извршити претраге кроз Луцене, исто као у Еластица-у.
И направили су нови производ - Цхартс, доступан је и на Атласу (Монгов сопствени облак). Имају бесплатни ниво - можете се играти са њим. Заиста ми се допао графикон – визуелизација података, веома интуитивна.
Састојци Узрочна конзистенција
Избројао сам око 230 чланака који су објављени на ову тему - од Леслие Ламперт. Сада ћу вам по свом сећању пренети неке делове ових материјала.
Све је почело са чланком Лесли Ламперт, који је написан 1970-их. Као што видите, нека истраживања на ову тему су још увек у току. Сада каузална доследност доживљава интересовање у вези са развојем дистрибуираних система.
Ограничења
Која ограничења постоје? Ово је заправо једна од главних тачака, јер се ограничења која производни систем намеће веома разликују од ограничења која постоје у академским чланцима. Често су прилично вештачки.
- Прво, „МонгоДБ“ је један мастер, као што сам већ рекао (ово у великој мери поједностављује).
- Сматрамо да систем треба да подржи око 10 хиљада комада. Не можемо доносити никакве архитектонске одлуке које ће експлицитно ограничити ову вредност.
- Имамо облак, али претпостављамо да би човек ипак требало да има прилику када преузме бинарни програм, покрене га на свом лаптопу и све ради одлично.
- Претпостављамо нешто што Ресеарцх ретко претпоставља: спољни клијенти могу да раде шта год желе. МонгоДБ је отвореног кода. Сходно томе, клијенти могу бити толико паметни и љути - могу пожелети да разбију све. Нагађамо да би могли да потичу византијски Феилори.
- За спољне клијенте који се налазе изван периметра постоји важно ограничење: ако је ова функција онемогућена, онда не треба приметити смањење перформанси.
- Друга тачка је генерално антиакадемска: компатибилност претходних и будућих верзија. Стари управљачки програми морају подржавати нова ажурирања, а база података мора подржавати старе управљачке програме.
Генерално, све ово намеће ограничења.
Компоненте узрочне конзистенције
Сада ћу говорити о неким компонентама. Ако узмемо у обзир узрочну доследност уопште, можемо изабрати блокове. Бирали смо између радова који припадају одређеном блоку: Праћење зависности, бирање сатова, како ови сатови могу да се синхронизују један са другим и како обезбеђујемо безбедност - ово је груби приказ онога о чему ћу говорити:
Потпуно праћење зависности
Зашто је то потребно? Тако да када се подаци реплицирају, сваки запис, свака промена података садржи информације о томе од којих промена зависи. Прва и наивна промена је када свака порука која садржи запис садржи информације о претходним порукама:
У овом примеру, број у витичастим заградама је број записа. Понекад се ови записи са вредностима чак преносе у целини, понекад се преносе неке верзије. Суштина је да свака промена садржи информације о претходној (очигледно носи све ово у себи).
Зашто смо одлучили да не користимо овај приступ (потпуно праћење)? Очигледно, зато што је овај приступ непрактичан: свака промена друштвене мреже зависи од свих претходних промена на тој друштвеној мрежи, преносећи, рецимо, Фацебоок или ВКонтакте у сваком ажурирању. Ипак, постоји много истраживања о потпуном праћењу зависности – ово су преддруштвене мреже; у неким ситуацијама то заиста функционише.
Експлицитно праћење зависности
Следећи је ограниченији. Овде се такође разматра пренос информација, али само оних који су јасно зависни. Шта зависи од чега се, по правилу, утврђује Пријава. Када се подаци реплицирају, упит враћа одговоре само када су претходне зависности задовољене, односно приказане. Ово је суштина како узрочна доследност функционише.
Она види да запис 5 зависи од записа 1, 2, 3, 4 - сходно томе, она чека пре него што клијент добије приступ променама које је донела Пенина одлука о приступу, када су све претходне промене већ прошле кроз базу података.
Ни ово нам не одговара, јер још увек има превише информација и то ће успорити ствари. Постоји још један приступ...
Лампорт Цлоцк
Они су веома стари. Лампортов сат значи да су ове зависности пресавијене у скаларну функцију, која се зове Лампортов сат.
Скаларна функција је неки апстрактни број. Често се назива логичним временом. Са сваким догађајем, овај бројач се повећава. Бројач, који је тренутно познат процесу, шаље сваку поруку. Јасно је да процеси могу бити несинхронизовани, могу имати потпуно различита времена. Ипак, систем некако балансира сат са таквим порукама. Шта се дешава у овом случају?
Поделио сам тај велики део на два дела да би било јасно: Пријатељи могу да живе у једном чвору, који садржи део колекције, а Феед може да живи у другом чвору, који садржи део ове колекције. Да ли је јасно како могу да изађу из реда? Први феед ће рећи: „Реплицирано“, а затим Пријатељи. Ако систем не пружи неку врсту гаранције да се Феед неће приказати све док се не испоруче и зависности од пријатеља у колекцији Пријатељи, онда ћемо имати управо ситуацију коју сам поменуо.
Видите како се време бројача на фиду логично повећава:
Дакле, главно својство овог Лампортовог сата и узрочне доследности (објашњено кроз Лампортов сат) је ово: ако имамо догађаје А и Б, а догађај Б зависи од догађаја А*, онда следи да је логичко време догађаја А мање од Логично време из догађаја Б.
* Понекад кажу и да се А догодило пре Б, односно да се А догодило пре Б – то је одређена релација која делимично наређује читав низ догађаја који су се уопште десили.
Супротно је нетачно. Ово је заправо један од главних недостатака Лампортовог сата - делимичан ред. Постоји концепт симултаних догађаја, односно догађаја у којима се ни (А се догодило пре Б) ни (А се догодило пре Б) није. Пример би био да Леонард истовремено додаје неког другог као пријатеља (чак не Леонарда, већ Шелдона, на пример).
Ово је својство које се често користи када се ради са Лампорт сатовима: они посебно гледају на функцију и из тога закључују да су ти догађаји можда зависни. Јер један начин је тачан: ако је логичко време А мање од логичког времена Б, онда се Б не може догодити пре А; а ако више, онда можда.
Вецтор Цлоцк
Логичан развој Лампортовог сата је векторски сат. Разликују се по томе што сваки чвор који се налази овде садржи свој посебан сат, и они се преносе као вектор.
У овом случају видите да је нулти индекс вектора одговоран за Феед, а први индекс вектора је за пријатеље (сваки од ових чворова). А сада ће се повећати: нулти индекс „Феед“-а се повећава приликом писања - 1, 2, 3:
Зашто је векторски сат бољи? Зато што вам омогућавају да схватите који су догађаји истовремени и када се дешавају на различитим чворовима. Ово је веома важно за систем шардирања као што је МонгоДБ. Међутим, ми нисмо изабрали ово, иако је то дивна ствар, и одлично функционише, и вероватно би нам одговарало...
Ако имамо 10 хиљада фрагмената, не можемо да пренесемо 10 хиљада компоненти, чак и ако га компримујемо или смислимо нешто друго – носивост ће и даље бити неколико пута мања од запремине целог овог вектора. Стога смо, стиснувши срце и зубе, напустили овај приступ и прешли на други.
Спаннер ТруеТиме. Атомски сат
Рекао сам да ће бити прича о Спаннеру. Ово је кул ствар, право из XNUMX. века: атомски сатови, ГПС синхронизација.
Која је идеја? „Спаннер“ је Гоогле систем који је недавно чак постао доступан људима (додали су му СКЛ). Свака трансакција тамо има неку временску ознаку. Пошто је време синхронизовано*, сваком догађају се може доделити одређено време - атомски сатови имају време чекања, након чега се гарантује да ће се „догодити“ друго време.
Дакле, једноставним писањем у базу података и чекањем одређеног временског периода, серијалабилност догађаја је аутоматски загарантована. Они имају најјачи модел конзистентности који се у принципу може замислити – то је екстерна конзистентност.
* Ово је главни проблем са Лампарт сатовима - они никада нису синхрони на дистрибуираним системима. Могу се разликовати; чак и са НТП-ом, они и даље не функционишу добро. „Шпанер” има атомски сат и синхронизација је, чини се, микросекунди.
Зашто нисмо изабрали? Не претпостављамо да наши корисници имају уграђен атомски сат. Када се појаве, уграђени у сваки лаптоп, биће нека врста супер кул ГПС синхронизације - онда да... Али за сада најбоље што је могуће је Амазон, базне станице - за фанатике... Тако да смо користили друге сатове .
Хибридни сат
То је у ствари оно што куца у МонгоДБ-у када се обезбеђује каузална доследност. Како су хибридни? Хибрид је скаларна вредност, али има две компоненте:
- Прва је Уник епоха (колико је секунди прошло од „почетка компјутерског света“).
- Други је неки инкремент, такође 32-битни непотписани инт.
То је све, заправо. Постоји овакав приступ: део који је одговоран за време је све време синхронизован са сатом; сваки пут када дође до ажурирања, овај део се синхронизује са сатом и испоставља се да је време увек мање-више тачно, а инкремент вам омогућава да разликујете догађаје који су се десили у истом тренутку.
Зашто је ово важно за МонгоДБ? Зато што вам омогућава да направите неку врсту резервних ресторана у одређеном тренутку, то јест, догађај је индексиран по времену. Ово је важно када су потребни одређени догађаји; За базу података, догађаји су промене у бази података које су се десиле у одређеним временским интервалима.
Најважнији разлог ћу вам рећи само вама (молим вас, немојте никоме рећи)! Ово смо урадили јер овако изгледају организовани, индексирани подаци у МонгоДБ ОпЛог-у. ОпЛог је структура података која садржи апсолутно све промене у бази података: оне прво иду у ОпЛог, а затим се примењују на сам Стораге у случају када је у питању реплицирани датум или шард.
Ово је био главни разлог. Ипак, постоје и практични захтеви за развој базе података, што значи да она треба да буде једноставна - мало кода, што мање покварених ствари које треба преписати и тестирати. Чињеница да су наши оплогови били индексирани хибридним часовницима је много помогла и омогућила нам да направимо прави избор. Заиста се исплатило и некако је магично функционисало на првом прототипу. Било је јако кул!
Синхронизација сата
У научној литератури је описано неколико метода синхронизације. Говорим о синхронизацији када имамо два различита шарда. Ако постоји један скуп реплика, нема потребе за било каквом синхронизацијом: ово је „један мастер“; имамо ОпЛог, у који падају све промене - у овом случају, све је већ секвенцијално поређано у самом „Оплогу“. Али ако имамо два различита дела, временска синхронизација је овде важна. Овде је векторски сат више помогао! Али ми их немамо.
Други је погодан - ово је „Откуцаји срца“. Могућа је размена неких сигнала који се јављају у свакој јединици времена. Али откуцаји срца су преспоро, не можемо да обезбедимо кашњење нашем клијенту.
Право време је, наравно, дивна ствар. Али, опет, ово је вероватно будућност... Иако то већ може да се уради у Атласу, већ постоје брзи „амазонски“ синхронизатори времена. Али неће бити доступан свима.
Оговарање је када све поруке укључују време. Ово је отприлике оно што користимо. Свака порука између чворова, драјвер, рутер чвора података, апсолутно све за МонгоДБ је нека врста елемента, компоненте базе података која садржи сат који ради. Свуда имају значење хибридног времена, преноси се. 64 бита? Ово дозвољава, ово је могуће.
Како то све функционише заједно?
Овде гледам једну реплику да би било мало лакше. Постоје примарни и секундарни. Секундарни врши репликацију и није увек потпуно синхронизован са примарним.
Долази до уметања у „Примери“ са одређеном временском вредношћу. Овај уметак повећава интерни број за 11, ако је ово максимум. Или ће проверити вредности сата и синхронизовати се са сатом ако су вредности сата веће. Ово вам омогућава да организујете по времену.
Након што он направи снимак, дешава се важан тренутак. Сат је у "МонгоДБ" и повећава се само ако је уписан у "Оплог". Ово је догађај који мења стање система. У апсолутно свим класичним чланцима, догађајем се сматра када порука удари у чвор: порука је стигла, што значи да је систем променио своје стање.
То је због чињенице да током истраживања није сасвим јасно како ће се ова порука тумачити. Поуздано знамо да ако се то не одрази у „Оплогу“, онда то неће бити ни на који начин протумачено, а промена стања система је само унос у „Оплог“. Ово нам све поједностављује: модел га поједностављује и омогућава нам да га организујемо у оквиру једног скупа реплика и многе друге корисне ствари.
Враћа се вредност која је већ записана у „Оплог“ – знамо да „Оплог“ већ садржи ову вредност, а њено време је 12. Сада, рецимо, читање почиње од другог чвора (секундарног) и преноси афтерЦлустерТиме у порука. Каже: „Треба ми све што се десило најмање после 12 или током дванаест” (види слику изнад).
То је оно што се назива Узрочно доследан (ЦАТ). У теорији постоји такав концепт да је то неки одсек времена, који је сам по себи конзистентан. У овом случају можемо рећи да је ово стање система које је уочено у тренутку 12.
Сада овде још нема ничега, јер ова врста симулира ситуацију када вам је потребно да секундар реплицира податке из примарног. Он чека... И сада су стигли подаци - враћа ове вредности назад.
Тако отприлике све функционише. Скоро.
Шта значи "скоро"? Претпоставимо да постоји нека особа која је прочитала и разумела како све ово функционише. Схватио сам да сваки пут када се ЦлустерТиме појави, ажурира унутрашњи логички сат, а затим се следећи унос повећава за један. Ова функција заузима 20 редова. Рецимо да ова особа преноси највећи 64-битни број, минус један.
Зашто "минус један"? Пошто ће унутрашњи сат бити замењен овом вредношћу (очигледно, ово је највећа могућа и већа од тренутног времена), тада ће се појавити унос у „Оплог“, а сат ће бити увећан за другу јединицу - и већ ће бити максимална вредност (једноставно постоје све јединице, нема где друго да се иде) , несвети интс).
Јасно је да после овога систем постаје апсолутно недоступан ни за шта. Може се само истоварити и очистити - пуно ручног рада. Потпуна доступност:
Штавише, ако се ово понови негде другде, онда цео кластер једноставно пада. Апсолутно неприхватљива ситуација коју свако може веома брзо и лако да организује! Стога смо овај тренутак сматрали једним од најважнијих. Како то спречити?
Наш начин је да потпишемо цлустерТиме
Овако се преноси у поруци (пре плавог текста). Али такође смо почели да генеришемо потпис (плави текст):
Потпис се генерише помоћу кључа који се чува унутар базе података, унутар безбедног периметра; сама се генерише и ажурира (корисници не виде ништа о томе). Генерише се хеш, а свака порука се потписује када се креира и потврђује када је примљена.
У главама људи вероватно се поставља питање: „Колико ово успорава ствари?“ Рекао сам вам да би требало да ради брзо, посебно у одсуству ове функције.
Шта значи користити узрочну доследност у овом случају? Ово је за приказ параметра афтерЦлустерТиме. Без овога, ионако ће једноставно пренети вредности. Оговарање, почевши од верзије 3.6, увек функционише.
Ако оставимо константно генерисање потписа, то ће успорити систем чак и у одсуству неке функције, која не испуњава наше приступе и захтеве. Па шта смо урадили?
Уради то брзо!
То је прилично једноставна ствар, али трик је занимљив - поделићу га, можда ће неко бити заинтересован.
Имамо хеш који чува потписане податке. Сви подаци пролазе кроз кеш меморију. Кеш не потписује одређено време, већ опсег. Када нека вредност стигне, генеришемо опсег, маскирамо последњих 16 битова и потписујемо ову вредност:
Добијањем таквог потписа убрзавамо систем (релативно) 65 хиљада пута. Одлично функционише: када смо изводили експерименте, време се заправо смањило за 10 хиљада пута када смо имали секвенцијално ажурирање. Јасно је да када су у завади, то не иде. Али у већини практичних случајева ради. Комбинација потписа Ранге заједно са потписом решила је безбедносни проблем.
Шта смо научили?
Лекције које смо научили из овога:
- Морамо да читамо материјале, приче, чланке, јер имамо много занимљивих ствари. Када радимо на некој функцији (нарочито сада, када смо радили трансакције итд.), морамо да читамо и разумемо. Потребно је време, али је заправо веома корисно јер јасно показује где смо. Чинило се да нисмо смислили ништа ново - само смо узели састојке.
Генерално, постоји одређена разлика у размишљању када је академска конференција (Сигмон, на пример) – сви се фокусирају на нове идеје. Шта је ново у нашем алгоритму? Овде нема ничег посебно новог. Новина пре лежи у начину на који смо спојили постојеће приступе заједно. Стога је прва ствар читати класике, почевши од Лампарта.
- У производњи су захтеви потпуно другачији. Сигуран сам да се многи од вас не суочавају са „сферичним“ базама података у апстрактном вакууму, већ са нормалним, стварним стварима које имају проблема са доступношћу, кашњењем и толеранцијом грешака.
- Последња ствар је да смо морали да погледамо различите идеје и да комбинујемо неколико потпуно различитих чланака у један приступ, заједно. Идеја о потписивању, на пример, генерално је потекла из чланка који је разматрао Пакос протокол, који је за невизантијске неуспешнике унутар ауторизационог протокола, за византијске – изван ауторизационог протокола... Уопште, то је управо оно што ми завршили радећи.
Овде нема апсолутно ништа ново! Али чим смо све то помешали... То је исто као да кажете да је рецепт за салату Оливије глупост, јер су јаја, мајонез и краставци већ измишљени... О истој причи.
Завршићу са овим. Хвала вам!
pitanja
Питање из публике (у даљем тексту Б): – Хвала, Михаиле, на извештају! Занимљива је тема о времену. Користите Госсипинг. Рекли су да свако има своје време, свако зна своје локално време. Колико сам разумео, имамо драјвер – може да буде много клијената са драјверима, планерима упита, такође и шардовима... А на шта се систем своди ако одједном имамо несклад: неко одлучи да је за минут испред, неко минут иза? Где ћемо завршити?
МТ: – Заиста одлично питање! Хтео сам само да причам о крхотинама. Ако сам добро разумео питање, имамо следећу ситуацију: постоји део 1 и део 2, читање се дешава из ове две крхотине - оне имају неслагање, не комуницирају једна са другом, јер је време које знају је различито, посебно време када постоје у оплозима.
Рецимо да је 1. део направио милион записа, 2. део није урадио ништа, а захтев је стигао до два дела. А први има афтерЦлустерТиме од преко милион. У таквој ситуацији, као што сам објаснио, шард 2 никада неће реаговати.
ИН: – Хтео сам да знам како се синхронизују и бирају једно логично време?
МТ: - Врло лако се синхронизује. Схард, када афтерЦлустерТиме дође до њега и не нађе времена у „Оплогу“, иницира без одобрења. То јест, он својим рукама подиже своје време на ову вредност. То значи да нема догађаја који одговарају овом захтеву. Он вештачки ствара овај догађај и тако постаје Каузално доследан.
ИН: – Шта ако му после овога дођу неки други догађаји који су изгубљени негде у мрежи?
МТ: – Шард је дизајниран тако да више неће доћи, јер је један мајстор. Ако се већ пријавио, онда неће доћи, већ ће доћи касније. Не може се десити да се нешто негде заглави, онда он не пише, а онда стигну ови догађаји - и узрочна конзистентност се наруши. Када не пише, сви они треба да дођу следећи (он ће их сачекати).
ИН: – Имам неколико питања у вези са редовима. Узрочна доследност претпоставља да постоји одређени ред радњи које треба извршити. Шта се дешава ако један од наших пакета нестане? Ево долази 10., 11.... 12. је нестао, а сви остали чекају да се оствари. И одједном нам је ауто умро, не можемо ништа. Да ли постоји максимална дужина реда који се акумулира пре него што се изврши? Који фатални неуспех настаје када се изгуби било која држава? Штавише, ако запишемо да постоји неко претходно стање, онда би некако требало да кренемо од њега? Али га нису одгурнули!
МТ: – Такође одлично питање! Шта ми радимо? МонгоДБ има концепт кворума пише, кворум чита. У којим случајевима порука може бити изгубљена? Када писање није кворум или када читање није кворум (нека врста смећа такође може остати).
Што се тиче узрочне конзистентности, спроведен је велики експериментални тест чији је резултат био да у случају када писање и читање није кворум, долази до кршења каузалне доследности. Тачно оно што кажете!
Наш савет: користите бар читање кворума када користите узрочну доследност. У овом случају ништа неће бити изгубљено, чак и ако се изгуби запис кворума... Ово је ортогонална ситуација: ако корисник не жели да се подаци изгубе, треба да користи запис кворума. Узрочна доследност не гарантује трајност. Трајност је загарантована репликацијом и машинама које су повезане са репликацијом.
ИН: – Када креирамо инстанцу која за нас врши шардовање (не мастер, већ славе, респективно), она се ослања на Уник време своје сопствене машине или на време „мастера“; Да ли се синхронизује први пут или периодично?
МТ: – Сад ћу да разјасним. Схард (тј. хоризонтална партиција) – ту је увек Примари. А крхотина може имати „мајстора“ и могу постојати реплике. Али део увек подржава снимање, јер мора да подржава неки домен (део има примарни).
ИН: – Значи све зависи чисто од „мајстора”? Да ли се увек користи мастер време?
МТ: - Да. Можете фигуративно рећи: сат откуцава када дође до уласка у „мастер“, у „Оплог“.
ИН: – Имамо клијента који се повезује и не мора ништа да зна о времену?
МТ: – Не морате ништа да знате! Ако говоримо о томе како то функционише на клијента: када клијент жели да користи каузалну доследност, треба да отвори сесију. Сада је све ту: трансакције у сесији и преузимање права... Сесија је редослед логичких догађаја који се дешавају са клијентом.
Ако отвори ову сесију и тамо каже да жели узрочну доследност (ако сесија подразумевано подржава узрочну доследност), све ради аутоматски. Возач памти ово време и повећава га када прими нову поруку. Памти какав је одговор претходни вратио са сервера који је вратио податке. Следећи захтев ће садржати афтерЦлустер("време веће од овог").
Клијент не мора да зна апсолутно ништа! Ово је за њега потпуно непрозирно. Ако људи користе ове функције, шта могу да ураде? Прво, можете безбедно да читате секундарне садржаје: можете да пишете у Примари и читате са географски реплицираних секундарних садржаја и будите сигурни да ради. Истовремено, сесије које су снимљене на Примарном могу се чак пренети на Секундарни, односно можете користити не једну сесију, већ неколико.
ИН: – Нови слој рачунарства – ЦРДТ (Цонфлицт-фрее Реплицатед Дата Типес) типови података – уско је повезан са темом Евентуалне доследности. Да ли сте размишљали о интеграцији ове врсте података у базу података и шта можете рећи о томе?
МТ: - Добро питање! ЦРДТ има смисла за сукобе писања: у МонгоДБ-у, један мастер.
ИН: – Имам питање од девопса. У стварном свету постоје такве језуитске ситуације када дође до византијског неуспеха, а зли људи унутар заштићеног периметра почну да гурају у протокол, шаљу занатске пакете на посебан начин?
МТ: – Зли људи унутар периметра су као тројански коњ! Зли људи унутар периметра могу учинити много лоших ствари.
ИН: – Јасно је да оставите, грубо речено, рупу на серверу кроз коју можете да убаците зоолошки врт слонова и заувек срушите цео кластер... Биће потребно време за ручни опоравак... Ово је, најблаже речено, погрешно. С друге стране, ово је занимљиво: у стварном животу, у пракси, постоје ситуације када се дешавају природно слични унутрашњи напади?
МТ: – Пошто се ретко сусрећем са кршењем безбедности у стварном животу, не могу да кажем да ли се дешавају. Али ако говоримо о филозофији развоја, мислимо овако: имамо периметар који обезбеђује момке који обезбеђују – ово је замак, зид; а унутар периметра можете радити шта год желите. Јасно је да постоје корисници са могућношћу само прегледа, а постоје корисници са могућношћу брисања директоријума.
У зависности од права, штета коју корисници могу да направе може бити миш, а може бити и слон. Јасно је да корисник са пуним правима може да уради било шта. Корисник са ограниченим правима може нанети знатно мање штете. Конкретно, не може да разбије систем.
ИН: – У заштићеном периметру неко је покушао да направи неочекиване протоколе за сервер како би у потпуности уништио сервер, а ако имате среће и цео кластер... Да ли икада буде толико „добро“?
МТ: "Никад нисам чуо за такве ствари." Чињеница да можете срушити сервер на овај начин није никаква тајна. Фаил унутра, бити из протокола, бити овлашћени корисник који може да напише овако нешто у поруци... У ствари, немогуће је, јер ће ипак бити верификовано. Могуће је онемогућити ову аутентификацију за кориснике који је не желе - онда је то њихов проблем; они су, грубо речено, сами порушили зидове и ту можете угурати слона, који ће газити... Али генерално, можете да се обучете као мајстор, дођите и извуците га!
ИН: – Хвала на извештају. Сергеј (Иандек). Постоји константа у Монгу која ограничава број чланова са правом гласа у скупу реплика, а ова константа је 7 (седам). Зашто је ово константа? Зашто ово није нека врста параметра?
МТ: – Имамо скупове реплика са 40 чворова. Увек постоји већина. Не знам која верзија...
ИН: – У скупу реплика можете покренути чланове који немају право гласа, али има највише 7 чланова са правом гласа. Како да преживимо гашење у овом случају ако је наш скуп реплика распоређен у 3 дата центра? Један дата центар може лако да се искључи, а друга машина може да испадне.
МТ: – Ово је већ мало ван оквира извештаја. Ово је опште питање. Можда вам могу рећи о томе касније.
Неки огласи 🙂
Хвала вам што сте остали са нама. Да ли вам се свиђају наши чланци? Желите да видите још занимљивијег садржаја? Подржите нас тако што ћете наручити или препоручити пријатељима, , јединствени аналог сервера почетног нивоа, који смо ми измислили за вас: (доступно са РАИД1 и РАИД10, до 24 језгра и до 40 ГБ ДДР4).
Делл Р730кд 2 пута јефтинији у Екуиник Тиер ИВ дата центру у Амстердаму? Само овде у Холандији! Делл Р420 - 2к Е5-2430 2.2Гхз 6Ц 128ГБ ДДР3 2к960ГБ ССД 1Гбпс 100ТБ - од 99 долара! Читали о
Извор: ввв.хабр.цом