Кийинки HighLoad++ конференциясы 6-жылдын 7 жана 2020-апрелинде Санкт-Петербургда өтөт.
Толук маалымат жана билеттер . HighLoad++ Сибирь 2019. Зал "Красноярск". 25-июнь, 12:00. Тезистер жана .
Практикалык талаптар теория менен карама-каршы келет, мында коммерциялык продукт үчүн маанилүү аспектилер эске алынбайт. Бул баяндама коммерциялык продуктунун талаптарынын негизинде академиялык изилдөөлөрдүн негизинде Себептик ырааттуулук компоненттерин түзүүгө ар кандай ыкмаларды тандоо жана айкалыштыруу процессин көрсөтөт. Угармандар логикалык сааттарга болгон теориялык ыкмалар, көз карандылыкка көз салуу, системанын коопсуздугу, сааттарды синхрондоштуруу жана эмне үчүн MongoDB айрым чечимдерге таянганын билишет.
Михаил Тюленев (мындан ары - М.Т.): – Мен Causal ырааттуулугу жөнүндө сүйлөшөм - бул MongoDBде иштеген функция. Мен бөлүштүрүлгөн системалардын тобунда иштейм, биз муну эки жыл мурун жасаганбыз.
Процесстин жүрүшүндө мен көптөгөн академиялык изилдөөлөр менен таанышууга туура келди, анткени бул өзгөчөлүк абдан жакшы изилденген. Көрсө, бир дагы макала өндүрүштүк маалымат базасында талап кылынган нерсеге туура келбейт, анткени кандайдыр бир өндүрүштүк тиркемеде болушу мүмкүн.
Мен академиялык изилдөөнүн керектөөчүлөрү катары биз андан кандайча даярдай турганыбыз жөнүндө айтып берем, аны андан кийин колдонуучуларыбызга колдонууга ыңгайлуу жана коопсуз даяр тамак катары тартуулай алабыз.
Себептүү ырааттуулук. Келгиле, түшүнүктөрдү аныктайлы
Баштоо үчүн, мен Каузалдык ырааттуулук деген эмне экенин жалпысынан айткым келет. Эки каарман бар - Леонард жана Пенни ("Чоң жарылуу теориясы" телесериалы):
Пенни Европада жана Леонард ага сюрприз той өткөргүсү келет дейли. Ал аны досторунун тизмесинен чыгарып, бардык досторуна каналга жаңыртуу жөнөтүүдөн артык эч нерсе ойлоп таба албайт: "Келгиле, Пенни бактылуу кылалы!" (ал Европада, уктап жатканда мунун баарын көрбөйт жана көрө албайт, анткени ал жерде жок). Акыр-аягы, ал бул постту жок кылат, аны түрмөктөн өчүрөт жана эч нерсени байкабашы жана чатак болбошу үчүн кирүү мүмкүнчүлүгүн калыбына келтирет.
Мунун баары жакшы жана жакшы, бирок система бөлүштүрүлүп, бир аз туура эмес болуп кетти деп коёлу. Мисалы, Пеннинин мүмкүнчүлүктөрүн чектөө ушул билдирүү пайда болгондон кийин пайда болушу мүмкүн, эгерде окуялар себеп-натыйжа менен байланышпаса. Чынында, бул бизнес функциясын аткаруу үчүн Каузалдык ырааттуулук талап кылынган мисал (бул учурда).
Чынында, бул маалыматтар базасынын анча маанилүү эмес касиеттери - өтө аз адамдар аларды колдойт. Келгиле, моделдерге өтөбүз.
Консистенция моделдери
Маалыматтар базасындагы ырааттуулук модели деген эмне? Бул бөлүштүрүлгөн система кардар кандай маалыматтарды жана кандай ырааттуулукта ала тургандыгы жөнүндө кепилдиктердин кээ бирлери.
Негизи, бардык ырааттуулук моделдери бөлүштүрүлгөн системанын, мисалы, ноутбуктун бир түйүндө иштеген системага канчалык окшош экендигине байланыштуу. Миңдеген гео-бөлүштүрүлгөн "Түйүндөрдүн" тутумунда иштеген тутумдун баары принцибинде автоматтык түрдө аткарылган ноутбукка окшош.
Демек, ырааттуулук моделдери бөлүштүрүлгөн системаларга гана колдонулат. Мурда бир вертикалдуу масштабда иштеген жана иштеген бардык системалар мындай көйгөйлөргө туш болгон эмес. Бул жерде бир буфер кэш бар болчу жана бардыгы дайыма андан окулчу.
Model Strong
Чындыгында, эң биринчи модели Күчтүү (же көтөрүлүш жөндөмү сызыгы, ал көп учурда деп аталат). Бул ырааттуулук модели, ар бир өзгөрүү болгондугу тастыкталгандан кийин системанын бардык колдонуучуларына көрүнүп турушун камсыз кылат.
Бул маалымат базасындагы бардык окуялардын глобалдык тартибин түзөт. Бул абдан күчтүү ырааттуулук касиети болуп саналат, жана бул жалпысынан абдан кымбат. Бирок, бул абдан жакшы колдоого алынат. Бул жөн гана абдан кымбат жана жай - бул сейрек колдонулат. Бул көтөрүлүү жөндөмдүүлүгү деп аталат.
Спаннерде колдоого алынган дагы бир күчтүү касиет бар - тышкы ырааттуулук деп аталат. Бул тууралуу бир аздан кийин сүйлөшөбүз.
Себеп
Кийинкиси - Себеп, бул мен айтып жаткан нерсе. Күчтүү жана Себептин ортосунда дагы бир нече суб-деңгээлдер бар, алар жөнүндө мен айтпай эле коёюн, бирок алардын баары Каузалга чейин кайнайт. Бул маанилүү модель, анткени ал бардык моделдердин эң күчтүүсү, тармактын же бөлүмдөрдүн катышуусунда эң күчтүү ырааттуулук.
Себептер – бул, чынында, окуялар себеп-натыйжа байланышы менен байланышкан кырдаал. Көбүнчө алар кардардын көз карашы боюнча сиздин укуктарыңызды окуу деп кабыл алынат. кардар кээ бир баалуулуктарды байкаган болсо, анда ал өткөн баалуулуктарды көрө албайт. Ал мурунтан эле префикстердин окууларын көрө баштады. Мунун баары бир эле нерсеге келет.
Себептер ырааттуулук модели катары сервердеги окуялардын жарым-жартылай иреттелиши, мында бардык кардарлардын окуялары бирдей ырааттуулукта байкалат. Бул учурда, Леонард жана Пенни.
Окуялар
Үчүнчү модель - акыры ырааттуулук. Бул таптакыр бардык бөлүштүрүлгөн системаларды колдогон нерсе, дегеле мааниси бар минималдуу модель. Бул төмөнкүлөрдү билдирет: бизде маалыматтарда кандайдыр бир өзгөрүүлөр болгондо, алар кандайдыр бир учурда ырааттуу болуп калат.
Мындай учурда ал эч нерсе дебейт, антпесе ал тышкы ырааттуулукка айланат - бул таптакыр башка окуя болмок. Ошентсе да, бул абдан популярдуу модели, абдан таралган. Демейки боюнча, бөлүштүрүлгөн системалардын бардык колдонуучулары Eventual Consistency колдонушат.
Мен кээ бир салыштырмалуу мисалдарды келтиргим келет:
Бул жебелер эмнени билдирет?
- Кечигип калуу. Ыкчамдуулуктун күчү жогорулаган сайын, ал белгилүү себептерден улам чоңоюп барат: көбүрөөк жазууларды жасашыңыз керек, кластерге катышкан бардык хосттордон жана түйүндөрдөн маалыматтар бар экенин ырастооңуз керек. Демек, Акыры Консистенция эң тез жооп берет, анткени ал жерде, эреже катары, сиз аны эс тутумга тапшырсаңыз болот жана бул, негизинен, жетиштүү болот.
- Болушу. Эгерде биз муну системанын тармактын үзгүлтүккө учурашы, бөлүктөрүнүн же кандайдыр бир бузулуулар болгон учурда жооп кайтаруу жөндөмдүүлүгү деп түшүнсөк, ырааттуулук модели азайган сайын ката толеранттуулук жогорулайт, анткени биз үчүн бир хосттун жашап, ошол эле учурда жашаганы жетиштүү. убакыт кээ бир маалыматтарды чыгарат. Акыр-аягы ырааттуулугу маалыматтар жөнүндө эч нерсеге кепилдик бербейт - ал каалаган нерсе болушу мүмкүн.
- Аномалиялар. Ошол эле учурда, албетте, аномалиялардын саны көбөйөт. Күчтүү ырааттуулукта алар дээрлик такыр болбошу керек, бирок Акыры Консистенцияда алар каалаган нерсе болушу мүмкүн. Суроо туулат: эмне үчүн адамдар анда аномалияларды камтыса, Eventual Consistency тандашат? Жооп: Акыры Консистенция моделдери колдонулушу мүмкүн жана аномалиялар, мисалы, кыска убакыттын ичинде бар; ырааттуу маалыматтарды окуу жана аздыр-көптүр окуу үчүн устаны колдонууга болот; Көп учурда күчтүү ырааттуулук моделдерин колдонууга болот. Иш жүзүндө бул иштейт, жана көбүнчө аномалиялардын саны убакыт менен чектелет.
CAP теоремасы
Ишенимдүүлүк, жеткиликтүүлүк деген сөздөрдү көргөндө оюңузга эмне келет? Бул туура - CAP теоремасы! Эми мен мифти жок кылгым келет... Бул мен эмес – бул Мартин Клепманн, ал сонун макала, сонун китеп жазган.
CAP теоремасы 2000-жылдары формулировкаланган принцип болуп саналат, ырааттуулук, жеткиликтүүлүк, бөлүктөр: каалаган экөөнү алсаңыз, үчөөнү тандай албайсыз. Бул белгилүү бир принцип болчу. Ал бир нече жылдан кийин Гилберт жана Линч тарабынан теорема катары далилденген. Андан кийин бул мантра катары колдонула баштады - системалар CA, CP, AP жана башкаларга бөлүнө баштады.
Бул теорема чындыгында төмөнкү учурларда далилденген... Биринчиден, Жеткиликтүүлүк нөлдөн жүздүктөргө чейинки үзгүлтүксүз маани катары эмес деп эсептелген (0 - система "өлгөн", 100 - тез жооп берет; биз аны ушундай карап көнүп калганбыз) , бирок алгоритмдин касиети катары, анын бардык аткарылышы үчүн ал маалыматтарды кайтарып бере тургандыгына кепилдик берет.
Жооп убактысы жөнүндө такыр сөз жок! 100 жылдан кийин маалыматтарды кайтарып турган алгоритм бар - бул CAP теоремасынын бир бөлүгү болуп саналган эң сонун жеткиликтүү алгоритм.
Экинчиден: теорема бул өзгөртүүлөр өлчөмүн өзгөртүүгө карабастан, ошол эле ачкычтын баалуулуктарынын өзгөрүшү үчүн далилденген. Бул чындыгында алар иш жүзүндө колдонулбайт дегенди билдирет, анткени моделдер ар кандай Акырында Консистенция, Күчтүү Консистенция (мүмкүн).
Мунун баары эмне үчүн? Мындан тышкары, CAP теоремасы дал далилденген формада иш жүзүндө колдонулбайт жана сейрек колдонулат. Теориялык түрдө ал кандайдыр бир жол менен баарын чектейт. Бул интуитивдик туура, бирок жалпысынан далилденген эмес, белгилүү бир принцип чыгат.
Себептик ырааттуулук эң күчтүү модель
Азыр эмне болуп жатат, сиз үч нерсени тең ала аласыз: Бөлүмдөрдүн жардамы менен ырааттуулук, жеткиликтүүлүк. Атап айтканда, Causal ырааттуулугу - бул эң күчтүү ырааттуулук модели, ал Бөлүмдөрдүн (тармактагы үзгүлтүктөр) катышуусунда дагы иштейт. Ошон үчүн бул абдан чоң кызыгууну жаратат, ошондуктан биз аны колго алдык.
Биринчиден, бул тиркемени иштеп чыгуучулардын ишин жеңилдетет. Атап айтканда, серверден чоң колдоонун болушу: бир кардар ичинде пайда болгон бардык жазуулар башка кардарга бирдей ырааттуулукта келүүгө кепилдик болгондо. Экинчиден, ал бөлүктөргө туруштук берет.
MongoDB ички ашканасы
Түшкү тамак экенин эстеп, ашканага өттүк. Мен сизге системанын модели жөнүндө айтып берем, тактап айтканда, мындай маалымат базасы жөнүндө биринчи жолу угуп жаткандар үчүн MongoDB деген эмне.
MongoDB (мындан ары "MongoDB" деп аталат) горизонталдуу масштабдоону, башкача айтканда, бөлүштүрүүнү колдогон бөлүштүрүлгөн система; жана ар бир сынык ичинде ал маалыматтардын ашыкча болушун, башкача айтканда, репликациялоону да колдойт.
MongoDBдеги Sharding (реляциялык маалымат базасы эмес) автоматтык түрдө тең салмактуулукту жүзөгө ашырат, башкача айтканда, документтердин ар бир коллекциясы (же реляциялык маалыматтар боюнча “таблица”) бөлүктөргө бөлүнөт жана сервер аларды автоматтык түрдө сыныктардын ортосунда жылдырат.
Сурамдарды таратуучу Query Router кардар үчүн ал иштеген кээ бир кардар болуп саналат. Ал мурунтан эле кайда жана кандай маалыматтар жайгашканын билет жана бардык суроо-талаптарды туура сыныкка багыттайт.
Дагы бир маанилүү жагдай: MongoDB бир мастер болуп саналат. Бир Негизги бар - ал камтыган ачкычтарды колдогон жазууларды ала алат. Сиз Мульти-мастер жазууну кыла албайсыз.
Биз 4.2 чыгарууну жасадык - ал жерде жаңы кызыктуу нерселер пайда болду. Тактап айтканда, алар Lucene - издөөнү - тактап айтканда, аткарылуучу Java-ны түздөн-түз Mongo-га киргизишти жана ал жерде Elasticaдагыдай эле Lucene аркылуу издөөлөрдү жүргүзүү мүмкүн болду.
Жана алар жаңы продуктуну жасашты - Диаграммалар, ал Атласта да бар (Монгонун өзүнүн Cloud). Алардын акысыз деңгээли бар - сиз аны менен ойной аласыз. Мага Диаграммалар абдан жакты - маалыматтарды визуалдаштыруу, абдан интуитивдик.
Ингредиенттер Себептүү ырааттуулук
Мен бул темада жарыяланган 230га жакын макаланы санадым - Лесли Ламперттен. Эми өзүмдүн эсимден бул материалдардын айрым бөлүктөрүн сиздерге жеткирем.
Мунун баары Лесли Ламперттин 1970-жылдары жазылган макаласынан башталды. Көрүнүп тургандай, бул тема боюнча кээ бир изилдөөлөр дагы эле уланууда. Азыр Causal ырааттуулугу бөлүштүрүлгөн системалардын өнүгүшүнө байланыштуу кызыгууну сезип жатат.
чектөөлөр
Кандай чектөөлөр бар? Бул чындыгында негизги пункттардын бири, анткени өндүрүш системасы киргизген чектөөлөр академиялык макалалардагы чектөөлөрдөн такыр башкача. Алар көбүнчө жасалма болуп саналат.
- Биринчиден, "MongoDB" - бул жалгыз мастер, мен айткандай (бул абдан жөнөкөйлөтөт).
- Биз система болжол менен 10 миң сыныктарды колдоо керек деп эсептейбиз. Бул баалуулукту ачык эле чектей турган архитектуралык чечимдерди кабыл ала албайбыз.
- Бизде булут бар, бирок биз адам экиликти жүктөөдө, аны ноутбукта иштеткенде дагы эле мүмкүнчүлүгүнө ээ болушу керек деп ойлойбуз жана баары сонун иштейт.
- Биз изилдөө сейрек ойлогон нерсени болжолдойбуз: тышкы кардарлар каалаганын кыла алышат. MongoDB ачык булак болуп саналат. Демек, кардарлар ушунчалык акылдуу жана ачуулуу болушу мүмкүн - алар баарын сындыргысы келет. Византиялык фейлорлор келип чыгышы мүмкүн деп ойлойбуз.
- Периметрден тышкаркы тышкы кардарлар үчүн маанилүү чектөө бар: эгерде бул функция өчүрүлгөн болсо, анда өндүрүмдүүлүктүн начарлашы байкалбашы керек.
- Дагы бир жагдай жалпысынан антиакадемиялык: мурунку жана келечектеги версиялардын шайкештиги. Эски драйверлер жаңы жаңыртууларды, ал эми маалымат базасы эски драйверлерди колдоого алышы керек.
Жалпысынан мунун баары чектөөлөрдү киргизет.
Себептик ырааттуулуктун компоненттери
Мен азыр кээ бир компоненттери тууралуу айтып берейин. Эгерде биз Себептик ырааттуулукту жалпысынан эске алсак, блокторду тандай алабыз. Биз белгилүү бир блокко тиешелүү иштердин ичинен тандап алдык: Көз карандылыкты көзөмөлдөө, сааттарды тандоо, бул сааттар бири-бири менен синхрондоштуруу жана коопсуздукту кантип камсыз кылуу - бул мен сүйлөшө турган нерселердин болжолдуу схемасы:
Толук көз карандылыкты көзөмөлдөө
Бул эмне үчүн керек? Ошентип, маалыматтар репликацияланганда, ар бир жазуу, ар бир маалымат өзгөрүшү кандай өзгөрүүлөрдөн көз каранды экендиги жөнүндө маалыматты камтыйт. Эң биринчи жана жөнөкөй өзгөрүү - бул жазууну камтыган ар бир билдирүү мурунку билдирүүлөр жөнүндө маалыматты камтыйт:
Бул мисалда тармал кашаадагы сан рекорддук сандар болуп саналат. Кээде баалуулуктары бар бул жазуулар толугу менен өткөрүлүп берилет, кээде кээ бир версиялар өткөрүлүп берилет. Жыйынтык: ар бир өзгөртүү мурункусу жөнүндө маалыматты камтыйт (албетте мунун баарын өзүнө камтыйт).
Эмне үчүн биз бул ыкманы колдонбоону чечтик (толук байкоо)? Албетте, бул ыкма практикалык эмес болгондуктан: социалдык тармакка кандайдыр бир өзгөртүү ар бир жаңыртууда, айталы, Фейсбук же ВКонтакте аркылуу ошол социалдык тармакка мурунку бардык өзгөртүүлөрдөн көз каранды. Ошого карабастан, Толук көз карандылыкты көзөмөлдөө боюнча көптөгөн изилдөөлөр бар - бул социалдык тармактарга чейинки; кээ бир учурларда ал чындап эле иштейт.
Ачык көз карандылыкты көзөмөлдөө
Кийинкиси көбүрөөк чектелген. Бул жерде маалымат берүү да каралат, бирок так көз каранды болгон нерсе гана. Эмнеден көз каранды, эреже катары, Колдонмо тарабынан аныкталат. Берилиштер репликацияланганда, суроо жоопторду мурунку көз карандылыктар канааттандырылганда гана кайтарат, башкача айтканда, көрсөтүлгөн. Бул Каузалдык ырааттуулуктун ишинин маңызы.
Ал 5 рекорду 1, 2, 3, 4 жазуулардан көз каранды экенин көрөт - ошого жараша ал кардардын Пеннинин кирүү чечими менен киргизилген өзгөртүүлөргө кирүү мүмкүнчүлүгүнө ээ болгуча күтөт, качан мурунку бардык өзгөртүүлөр маалымат базасынан өткөн.
Бул бизге да туура келбейт, анткени маалымат дагы эле көп жана ал ишти жайлатат. Башка ыкма бар ...
Лампорт сааты
Алар абдан эски. Lamport Clock бул көз карандылыктын Lamport Clock деп аталган скалярдык функцияга бүктөлгөндүгүн билдирет.
Скалярдык функция – бул кандайдыр бир абстракттуу сан. Ал көбүнчө логикалык убакыт деп аталат. Ар бир окуя менен бул эсептегич көбөйөт. Учурда процесске белгилүү болгон эсептегич ар бир билдирүүнү жөнөтөт. Процесстер синхрондобой калышы мүмкүн экени түшүнүктүү, алар такыр башка убакыттарга ээ болушу мүмкүн. Ошентсе да, система кандайдыр бир жол менен мындай билдирүүлөр менен саатты тең салмактайт. Бул учурда эмне болот?
Түшүнүктүү болушу үчүн мен ал чоң сыныкты экиге бөлдүм: Достор коллекциянын бир бөлүгүн камтыган бир түйүндө жашай алат, ал эми Feed бул коллекциянын бир бөлүгүн камтыган башка түйүндө жашай алат. Алар сызыктан кантип чыга турганы түшүнүктүүбү? Алгач түрмөк: "Репликацияланган", андан кийин Достор дейт. Эгерде система Достор коллекциясындагы Досторго көз карандылыктары жеткирилмейинче, канал көрсөтүлбөйт деп кандайдыр бир кепилдик бербесе, анда бизде мен айткан жагдай болот.
Түрмөктөгү каршы убакыт логикалык түрдө кантип көбөйгөнүн көрүп жатасыз:
Ошентип, бул Лампорт саатынын жана Себептик ырааттуулуктун негизги касиети (Лампорт Сааты аркылуу түшүндүрүлөт) бул: эгерде бизде А жана В окуялары болсо, ал эми В окуясы А окуясынан көз каранды болсо, анда А окуясынын Логикалык Убакыты төмөнкүдөн аз болот. B окуясынан LogicalTime.
* Кээде алар А Бга чейин болгон деп да айтышат, б.а. А В чейин болгон - бул жалпы болуп өткөн окуялардын бүтүндөй жыйындысын жарым-жартылай буйрук кылган белгилүү бир байланыш.
Мунун тескериси туура эмес. Бул, чынында, Lamport Clock негизги кемчиликтеринин бири болуп саналат - жарым-жартылай тартиби. Бир убакта болгон окуялар, башкача айтканда (А Бга чейин болгон) да, (А Бга чейин болгон эмес) деген түшүнүк бар. Мисал катары Леонарддын башка бирөөнү дос катары кошушу мүмкүн (ал тургай Леонард эмес, бирок Шелдон, мисалы).
Бул Lamport сааттары менен иштөөдө көп колдонулган касиет: алар функцияны атайын карашат жана ушундан улам, балким, бул окуялар көз каранды деген тыянакка келишет. Себеби бир жолу туура: эгерде LogicalTime A LogicalTime Bдан аз болсо, анда В Ага чейин боло албайт; жана көбүрөөк болсо, анда мүмкүн.
Вектордук саат
Lamport саатынын логикалык өнүгүшү Вектордук саат болуп саналат. Алар бул жерде жайгашкан ар бир түйүн өзүнүн өзүнчө саатын камтышы менен айырмаланат жана алар вектор катары берилет.
Бул учурда, сиз вектордун нөлдүк индекси Feed үчүн жооптуу экенин, ал эми вектордун биринчи индекси Достор үчүн (бул түйүндөрдүн ар бири) экенин көрөсүз. Эми алар көбөйөт: “Жемдин” нөлдүк индекси жазууда көбөйөт – 1, 2, 3:
Эмне үчүн Vector Clock жакшыраак? Анткени алар кайсы окуялар бир эле учурда жана алар ар кандай түйүндөрдө пайда болгонун аныктоого мүмкүндүк берет. Бул MongoDB сыяктуу sharding системасы үчүн абдан маанилүү. Бирок, биз муну тандаган жокпуз, бирок бул эң сонун нерсе, ал абдан жакшы иштейт, балким, бизге туура келет...
Эгерде бизде 10 миң сынык болсо, биз 10 миң компонентти которо албайбыз, аны кысып же башка нерсе ойлоп тапсак да - пайдалуу жүк баары бир бул вектордун көлөмүнөн бир нече эсе аз болот. Ошондуктан, тишибизди кычыратып, бул ыкманы таштап, башкага өттүк.
Spanner TrueTime. Атомдук саат
Мен Спаннер тууралуу окуя болот дедим. Бул 21-кылымдан чыккан сонун нерсе: атомдук сааттар, GPS синхрондоштуруу.
Кандай идея? "Spanner" бул Google тутуму, ал жакында эле адамдарга жеткиликтүү болуп калды (алар ага SQL кошушту). Ар бир транзакцияда кандайдыр бир убакыт белгиси бар. Убакыт синхрондоштуруу* болгондуктан, ар бир окуяга белгилүү бир убакыт ыйгарылышы мүмкүн - атомдук сааттарда күтүү убактысы бар, андан кийин башка убакыттын "болушуна" кепилдик берилет.
Ошентип, жөн гана маалымат базасына жазуу жана бир нече убакыт күтүү менен, окуянын Сериялаштырууга автоматтык түрдө кепилдик берилет. Аларда принципиалдуу түрдө элестете турган эң күчтүү Консистенция модели бар - бул тышкы ырааттуулук.
* Бул Lampart сааттарынын негизги көйгөйү - алар бөлүштүрүлгөн системаларда эч качан синхрондуу болбойт. Алар айырмаланышы мүмкүн; NTP менен да, алар дагы деле жакшы иштебейт. "Spanner" атомдук сааты жана синхрондоштуруусу бар, сыягы, микросекунддар.
Эмне үчүн тандаган жокпуз? Биздин колдонуучуларда атомдук саат бар деп ойлобойбуз. Алар пайда болгондо, ар бир ноутбукка орнотулуп, кандайдыр бир супер сонун GPS синхрондоштуруусу болот - анда ооба... Бирок азыр эң жакшысы Amazon, Base Stations - фанаттар үчүн... Ошентип, биз башка сааттарды колдондук. .
Гибриддик саат
Бул чындыгында MongoDBде Causal ырааттуулугун камсыз кылган нерсе. Алар кандайча гибрид? Гибрид скалярдык маани, бирок анын эки компоненти бар:
- Биринчиси - Unix доору («компьютер дүйнөсүнүн башталышынан» канча секунд өттү).
- Экинчиси - кээ бир өсүү, ошондой эле 32-бит кол коюлбаган int.
Чындыгында, баары ушул. Мындай мамиле бар: убакыт үчүн жооптуу бөлүк ар дайым саат менен синхрондолуп турат; сайын жаңыртуу пайда болгондо, бул бөлүк саат менен синхрондолуп турат жана убакыт ар дайым аздыр-көптүр туура экени көрүнүп турат, ал эми өсүү бир эле учурда болгон окуяларды айырмалоого мүмкүндүк берет.
Эмне үчүн бул MongoDB үчүн маанилүү? Анткени ал белгилүү бир убакта кандайдыр бир резервдик ресторандарды жасоого мүмкүндүк берет, башкача айтканда, окуя убакыт боюнча индекстелет. Бул белгилүү бир окуялар керек болгондо маанилүү; Маалыматтар базасы үчүн окуялар - бул белгилүү бир убакыт аралыгында болгон маалымат базасындагы өзгөрүүлөр.
Мен сизге эң негизги себебин сизге гана айтам (эч кимге айтпаңыз)! Биз муну жасадык, анткени MongoDB OpLog ичинде уюшулган, индекстелген маалыматтар ушундай көрүнөт. OpLog – бул маалымат структурасы, анда маалымат базасындагы таптакыр бардык өзгөрүүлөр камтылган: алар алгач OpLog'ка барышат, андан кийин алар репликацияланган дата же сынык болгон учурда Сактагычтын өзүнө колдонулат.
Бул негизги себеп болду. Ошентсе да, маалымат базасын иштеп чыгуу үчүн практикалык талаптар да бар, бул жөнөкөй болушу керек дегенди билдирет - кичинекей код, мүмкүн болушунча азыраак сынган нерселер, аларды кайра жазуу жана текшерүү керек. Биздин оплогдорубуздун гибриддик сааттар менен индекстелгендиги көп жардам берди жана туура тандоо жасоого мүмкүндүк берди. Бул чындап эле өзүн актады жана кандайдыр бир сыйкырдуу түрдө эң биринчи прототипте иштеди. Бул абдан сонун болду!
Саатты синхрондоштуруу
Илимий адабиятта сүрөттөлгөн бир нече синхрондоштуруу ыкмалары бар. Мен эки башка сыныктарыбыз болгондо синхрондоштуруу жөнүндө айтып жатам. Эгерде бир реплика топтому бар болсо, анда эч кандай синхрондоштуруунун кереги жок: бул "жалгыз мастер"; бизде OpLog бар, ага бардык өзгөртүүлөр кирет - бул учурда баары "Oplog" өзүндө ырааттуу түрдө иреттелген. Бирок бизде эки башка сынык болсо, анда убакыт синхрондоштуруу бул жерде маанилүү. Бул жерде вектордук саат көбүрөөк жардам берди! Бирок бизде алар жок.
Экинчиси ылайыктуу - бул "Жүрөктүн согушу". Ар бир убакыт бирдигинде пайда болгон кээ бир сигналдарды алмаштырууга болот. Бирок жүрөктүн согушу өтө жай, биз кардарыбызга кечигүү мүмкүнчүлүгүн бере албайбыз.
Чыныгы убакыт, албетте, кереметтүү нерсе. Бирок, дагы бир жолу, бул, балким, келечек... Бул буга чейин Атласта жасалышы мүмкүн болсо да, буга чейин эле тез "Amazon" убакыт синхронизаторлор бар. Бирок ал баарына жеткиликтүү боло бербейт.
Ушак - бул бардык билдирүүлөр убакытты камтыйт. Бул болжол менен биз колдонгон нерсе. Түйүндөрдүн ортосундагы ар бир билдирүү, драйвер, маалымат түйүнүнүн роутери, MongoDB үчүн бардыгы - бул кандайдыр бир элемент, иштеген саатты камтыган маалымат базасынын компоненти. Алар бардык жерде гибриддик убакыттын мааниси бар, ал берилет. 64 бит? Бул мүмкүндүк берет, бул мүмкүн.
Мунун баары кантип чогуу иштейт?
Бул жерде мен бир аз жеңилдетүү үчүн бир реплика топтомун карап жатам. Негизги жана орто деген бар. Экинчилик репликацияны ишке ашырат жана дайыма Негизги менен толук синхрондошо бербейт.
Кыстаруу белгилүү бир убакыт мааниси менен "Примерге" пайда болот. Бул кыстарма ички эсепти 11ге көбөйтөт, эгерде бул максималдуу болсо. Же ал сааттын маанилерин текшерип, сааттын мааниси чоңураак болсо, саатка шайкештештирилет. Бул убакыт боюнча уюштурууга мүмкүндүк берет.
Ал жаздыргандан кийин маанилүү учур болот. Саат "MongoDB" ичинде жана "Оплогго" жазганда гана көбөйөт. Бул системанын абалын өзгөрткөн окуя. Бардык классикалык макалаларда билдирүү түйүнгө тийгенде окуя болуп эсептелет: кабар келди, демек система өзүнүн абалын өзгөрттү.
Бул изилдөө учурунда бул билдирүү кандай чечмеленет толугу менен ачык-айкын эмес экенине байланыштуу. Биз анык билебиз, эгерде ал “Оплогдо” чагылдырылбаса, анда ал эч кандай түшүндүрүлбөйт жана системанын абалынын өзгөрүшү “Оплогдо” гана жазуу болуп саналат. Бул биз үчүн бардыгын жөнөкөйлөтөт: модель аны жөнөкөйлөтөт жана аны бир реплика топтомунун жана башка көптөгөн пайдалуу нерселердин ичинде уюштурууга мүмкүндүк берет.
"Оплогго" мурунтан эле жазылган маани кайтарылды - биз билебиз "Oplog" мурунтан эле бул маанини камтыйт жана анын убактысы 12. Эми, айталы, окуу башка түйүндөн (Экинчи) башталат жана ал AfterClusterTime ичинде өткөрөт. билдирүү. Ал мындай дейт: «Мага жок дегенде 12ден кийин же он экиде болгондун баары керек» (жогорку сүрөттү караңыз).
Бул Causal ырааттуу (CAT) деп аталат. Теорияда бул өзүнчө ырааттуу болгон кандайдыр бир убакыт кесимдиги деген түшүнүк бар. Бул учурда, биз 12 убакта байкалган системанын абалы деп айта алабыз.
Азыр бул жерде азырынча эч нерсе жок, анткени бул биринчиликтен берилиштерди көчүрүү үчүн экинчилик керек болгон кырдаалды симуляциялайт. Ал күтөт... Эми маалыматтар келди - ал бул баалуулуктарды кайра кайтарат.
Баары ушундай иштейт. Дээрлик.
"Дээрлик" деген эмнени билдирет? Мунун баары кантип иштээрин окуп, түшүнгөн бирөө бар деп ойлойлу. Мен ClusterTime пайда болгон сайын, ал ички логикалык саатты жаңыртып, андан кийин кийинки жазуу бир көбөйөрүн түшүндүм. Бул функция 20 сапты алат. Келгиле, бул адам эң чоң 64 биттик санды, минус бирди өткөрөт дейли.
Эмне үчүн "минус бир"? Анткени ички саат бул мааниге алмаштырылат (албетте, бул мүмкүн болгон эң чоң жана учурдагы убакыттан чоңураак), андан кийин "Oplog" ичинде жазуу пайда болот, ал эми саат башка бирдикке көбөйөт - ансыз деле болот максималдуу маани болуңуз (бардык бирдиктер бар, башка барар жер жок) , unsaint ints).
Андан кийин система эч нерсеге таптакыр жеткиликсиз болуп калаары анык. Аны түшүрүп, тазалоого гана болот - кол менен иштөө көп. Толук жеткиликтүүлүгү:
Анын үстүнө, бул башка жерде кайталанса, анда бүт кластер жөн эле кулайт. Кимдир бирөө абдан тез жана оңой уюштура турган таптакыр кабыл алынгыс кырдаал! Ошондуктан биз бул учурду эң маанилүү учурлардын бири катары эсептедик. Кантип алдын алса болот?
Биздин жол clusterTime кол коюу болуп саналат
Билдирүүдө (көк тексттин алдында) ушинтип берилет. Бирок биз кол тамга (көк текст) түзө баштадык:
Кол коюу маалымат базасында, коопсуз периметрдин ичинде сакталган ачкыч тарабынан түзүлөт; өзү түзүлөт жана жаңыртылат (колдонуучулар бул жөнүндө эч нерсе көрүшпөйт). Хеш түзүлөт жана ар бир билдирүү түзүлгөндө кол коюлат жана кабыл алынганда текшерилет.
Адамдардын оюнда: «Бул ишти канчалык басаңдатат?» деген суроо жаралса керек. Айрыкча, бул өзгөчөлүк жок болгондо, ал тез иштеши керек деп айттым.
Бул учурда Каузалдык ырааттуулукту колдонуу эмнени билдирет? Бул afterClusterTime параметрин көрсөтүү үчүн. Ансыз, ал баары бир баалуулуктарды өткөрүп берет. Ушак, 3.6 версиясынан баштап, ар дайым иштейт.
Эгерде биз кол коюулардын тынымсыз генерациясын калтыра турган болсок, ал биздин мамилеге жана талаптарга жооп бербеген өзгөчөлүк жок болгон учурда да системаны жайлатат. Анда биз эмне кылдык?
Тез жаса!
Бул абдан жөнөкөй нерсе, бирок айла кызыктуу - мен аны менен бөлүшөм, балким, кимдир бирөө кызыкдар болот.
Бизде кол коюлган маалыматтарды сактаган хэш бар. Бардык маалыматтар кэштен өтөт. Кэш белгилүү бир убакытка эмес, диапазонго кол коёт. Кандайдыр бир маани келгенде, биз Диапазону жаратып, акыркы 16 битти жашырып, бул мааниге кол коёбуз:
Мындай колду алуу менен биз системаны (салыштырмалуу) 65 миң эсе ылдамдатабыз. Бул сонун иштейт: биз эксперименттерди жүргүзгөндө, ырааттуу жаңыртуу болгондо, убакыт чындыгында 10 миң эсеге кыскарды. Алар бири-бирине карама-каршы келгенде, бул ишке ашпай турганы түшүнүктүү. Бирок көпчүлүк практикалык учурларда ал иштейт. Кол коюу менен бирге Range колунун айкалышы коопсуздук маселесин чечти.
Биз эмнени үйрөндүк?
Мындан биз алган сабактар:
- Материалдарды, аңгемелерди, макалаларды окуу керек, анткени бизде кызыктуу нерселер көп. Биз кандайдыр бир функциянын үстүндө иштегенде (өзгөчө азыр, биз транзакцияларды жасаганда ж.б.) окуп, түшүнүшүбүз керек. Бул убакытты талап кылат, бирок бул чындыгында абдан пайдалуу, анткени ал биздин кайда экенибизди айкын кылат. Биз жаңы эч нерсе ойлоп тапкан жокпуз – жөн гана ингредиенттерди алдык.
Жалпысынан алганда, академиялык конференция болгондо (мисалы, Сигмон) ой жүгүртүүдө белгилүү бир айырмачылык бар – ар бир адам жаңы идеяларга көңүл бурат. Алгоритмибизде эмне жаңылык? Бул жерде өзгөчө жаңы эч нерсе жок. Жаңылык, тескерисинче, биз учурдагы ыкмаларды аралаштырганыбызда. Ошондуктан, биринчи кезекте Лампарттан баштап, классиканы окуу керек.
- Өндүрүштө талаптар такыр башкача. Силердин көбүңөр абстракттуу вакуумда “сфералык” маалымат базаларына эмес, жеткиликтүүлүк, күтүү жана каталарга чыдамкайлык менен көйгөйлөрү бар кадимки, реалдуу нерселерге туш болуп жатканына ишенем.
- Акыркы нерсе, биз ар кандай идеяларды карап, бир нече такыр башка макалаларды бир ыкмага бириктиришибиз керек болчу. Маселен, кол коюу идеясы негизинен Византиядан башкалары үчүн авторизация протоколунун ичинде, византиялыктар үчүн – авторизация протоколунан тышкары болгон Паксос протоколун караган макаладан келип чыккан... Жалпысынан алганда, биз дал ушул нерсебиз. кылып бүттү.
Бул жерде таптакыр жаңы эч нерсе жок! Бирок бардыгын аралаштырганыбыз менен... Бул Оливье салатынын рецепти куру сөз дегенге барабар, анткени жумуртка, майонез жана бадыраң буга чейин эле ойлоп табылган... Бул бир эле окуя жөнүндө.
Муну менен бүтүрөм. Рахмат!
суроолор
Аудиториянын суроосу (мындан ары - В): – Рахмат, Михаил, отчет үчүн! Убакыт темасы кызыктуу. Сиз ушакчылыкты колдонуп жатасыз. Ар кимдин өз убактысы бар, ар ким өзүнүн жергиликтүү убактысын билет дешти. Мен түшүнгөндөй, бизде айдоочу бар - айдоочулары бар көптөгөн кардарлар болушу мүмкүн, суроо-пландоочулар да, сыныктар да... Жана эгер бизде күтүлбөгөн жерден келишпестик пайда болуп калса, система эмнеге алып келет: кимдир-бирөө ал үчүн деп чечет. бир мүнөт алдыда, кимдир бирөө бир мүнөт артта? Биз кайда барабыз?
MT: – Чынында эле сонун суроо! Мен жөн гана сыныктар жөнүндө айткым келди. Мен суроону туура түшүнсөм, бизде төмөнкүдөй абал бар: сынык 1 жана сынык 2, окуу бул эки сыныктан пайда болот - аларда карама-каршылык бар, бири-бири менен байланышпайт, анткени алар билген убакыт башка, айрыкча, алар оплогдордо бар болгон учур.
Шард 1 миллион жазууларды жасады дейли, 2 эч нерсе кылган жок, өтүнүч эки сыныкка келди. Ал эми биринчисинде бир миллиондон ашык AfterClusterTime бар. Мындай кырдаалда, мен түшүндүргөндөй, shard 2 эч качан жооп бербейт.
IN: – Мен алардын кантип синхрондоп, бир логикалык убакытты тандаарын билгим келди?
MT: - Синхрондоштуруу үчүн абдан жеңил. Shard, ага afterClusterTime келгенде жана ал "Oplog" дан убакыт таппай калганда, эч кандай жактырылган демилге бербейт. Башкача айтканда, убактысын колу менен ушул баалуулукка көтөрөт. Бул бул сурамга дал келген окуялар жок дегенди билдирет. Ал бул окуяны жасалма түрдө жаратат жана ошону менен Себептик Консистентке айланат.
IN: – Ошондон кийин ага тармактын бир жеринде жоголуп кеткен башка окуялар келип калсачы?
MT: – Шард бир эле кожоюн болгондуктан кайра келбей тургандай жасалган. Эгер ал буга чейин эле жазылган болсо, анда алар келбейт, бирок кийин келет. Бир нерсе тыгылып калышы мүмкүн эмес, андан кийин ал эч нерсе жазбайт, анан бул окуялар келип чыгат - жана Себептүү ырааттуулук бузулат. Ал эч нерсе жазбаганда, алардын баары кийинкиге келиши керек (ал аларды күтөт).
IN: – Кезек боюнча бир нече суроолорум бар. Себептүү ырааттуулук аткарылышы керек болгон иш-аракеттердин белгилүү бир кезеги бар экенин болжолдойт. Биздин пакеттердин бири жок болуп кетсе эмне болот? Мына, 10, 11... 12си жок болуп кетти, калгандары анын ишке ашышын күтүп жатышат. Анан күтүлбөгөн жерден машинабыз өлүп калды, биз эч нерсе кыла албайбыз. Аткаруу алдында топтолгон кезектин максималдуу узундугу барбы? Кайсы бир мамлекет жоголгондо кандай өлүмгө дуушар болот? Анын үстүнө мурунку абал бар деп жазсак, анда кандайдыр бир жол менен андан башташ керекпи? Бирок алар аны түртүшкөн жок!
MT: – Ошондой эле сонун суроо! Биз эмне кылып жатабыз? MongoDB кворум жазат, кворум окуйт деген түшүнүккө ээ. Кандай учурларда билдирүү жоголуп кетиши мүмкүн? Жазууда кворум жок болгондо же окуу кворум болбосо (кандайдыр бир таштанды жабышып калышы мүмкүн).
Себептүү ырааттуулукка карата чоң эксперименталдык тест жүргүзүлдү, анын жыйынтыгында жазуулар жана окуулар кворум болбогон учурда Себептүү ырааттуулуктун бузулушуна алып келди. Сиз айткандай так!
Биздин кеңеш: Себептүү ырааттуулукту колдонууда жок дегенде кворумду окууну колдонуңуз. Бул учурда, кворум жазуусу жоголсо да, эч нерсе жоголбойт... Бул ортогоналдык абал: эгерде колдонуучу маалыматтардын жоголушун каалабаса, анда ал кворумдун жазуусун колдонушу керек. Себептүү ырааттуулук туруктуулукка кепилдик бербейт. Узактыгы репликация жана репликация менен байланышкан техника менен кепилденет.
IN: – Биз үчүн сындырууну аткарган инстанцияны түзгөнүбүздө (тиешелүүлүгүнө жараша кожоюн эмес, кул), ал өзүнүн машинасынын Unix убактысына же “кожоюндун” убактысына таянат; Ал биринчи жолу шайкештештирилеби же мезгил-мезгили мененби?
MT: – Мен азыр тактайм. Shard (б.а. горизонталдуу бөлүү) - ал жерде ар дайым Негизги бар. Ал эми сыныкта "кожоюн" болушу мүмкүн жана репликалар болушу мүмкүн. Бирок сынык жазууну ар дайым колдойт, анткени ал кандайдыр бир доменди колдоого алышы керек (сыныкта Негизги бар).
IN: – Демек, баары “кожоюндан” көз карандыбы? Мастер убакыт дайыма колдонулабы?
MT: - Ооба. Сиз каймана мааниде айта аласыз: "мастерге", "Оплогго" киргенде, сааттын жебеси өтүп жатат.
IN: – Бизде байланыштыруучу кардар бар жана убакыт жөнүндө эч нерсе билүүнүн кереги жок?
MT: – Дегеле эч нерсени билиштин кереги жок! Эгерде биз анын кардарда кандай иштеши жөнүндө айта турган болсок: кардар Себептүү ырааттуулукту колдонгусу келгенде, сессияны ачуу керек. Эми баары бар: сессияда транзакциялар жана укуктарды алуу... Сеанс – кардар менен болгон логикалык окуяларды иретке келтирүү.
Эгерде ал бул сеансты ачып, ошол жерден Себептик ырааттуулукту каалай турганын айтса (эгерде сеанс демейки боюнча Себептүү ырааттуулукту колдосо), баары автоматтык түрдө иштейт. Айдоочу бул убакытты эстеп, жаңы билдирүү келгенде аны көбөйтөт. Ал мурунку серверден дайындарды кайтарган кандай жооп кайтарганын эстейт. Кийинки сурамда afterCluster ("убакыт мындан чоңураак") камтылат.
кардар таптакыр эч нерсе билиши керек эмес! Бул ага таптакыр түшүнүксүз. Эгер адамдар бул мүмкүнчүлүктөрдү колдонсо, алар эмне кыла алат? Биринчиден, сиз кошумча программаларды коопсуз окуй аласыз: сиз Негизгиге жазып, географиялык жактан кайталанган кошумча программалардан окуп, анын иштегенине ишене аласыз. Ошол эле учурда, Негизгиде жазылган сеанстарды ал тургай, экинчиликке өткөрсө болот, б.а. сиз бир сеансты эмес, бир нече сессияны колдоно аласыз.
IN: – Эсептөө илиминин жаңы катмары – CRDT (Чыр-чатактарсыз репликацияланган берилиштер түрлөрү) маалымат түрлөрү – “Акыркы ырааттуулук” темасы менен тыгыз байланышта. Берилиштердин бул түрлөрүн маалымат базасына интеграциялоону ойлондуңуз беле жана бул тууралуу эмне айта аласыз?
MT: - Жакшы суроо! CRDT жазуу чыр-чатактары үчүн мааниси бар: MongoDBде, жалгыз мастер.
IN: – Мен дин өкүлдөрүнөн суроом бар. Чыныгы дүйнөдө ушундай иезуиттик жагдайлар бар, качан Византиянын бузулушу пайда болуп, корголгон периметрдин ичиндеги жаман адамдар протоколго кирип, кол өнөрчүлүк пакеттерин өзгөчө жол менен жөнөтө башташат?
MT: – Периметрдин ичиндеги жаман адамдар трояндык атка окшош! Периметрдин ичиндеги жаман адамдар көп жаман иштерди кыла алышат.
IN: – Серверде тешик калтыруу, болжол менен айтканда, пилдердин зоопаркын салып, бүтүндөй кластерди биротоло кыйрата турган тешик калтырары түшүнүктүү... Кол менен калыбына келтирүүгө убакыт керек... Бул, жумшак айтканда, туура эмес. Башка жагынан алганда, бул кызыктуу: чыныгы жашоодо, иш жүзүндө, табигый окшош ички чабуулдар пайда болгон жагдайлар бар?
MT: – Чыныгы жашоодо коопсуздуктун бузулушуна чанда жолуккандыктан, алар болобу, айта албайм. Бирок өнүгүү философиясы жөнүндө айта турган болсок, биз мындай деп ойлойбуз: бизде коопсуздукту камсыз кылган жигиттердин периметри бар – бул сепил, дубал; жана периметрдин ичинде сиз каалаган нерсени кыла аласыз. Жалаң гана көрүү мүмкүнчүлүгү бар колдонуучулар, каталогду өчүрүү мүмкүнчүлүгү бар колдонуучулар бар экени түшүнүктүү.
Укуктарга жараша колдонуучулардын зыяны чычкан же пил болушу мүмкүн. Толук укугу бар колдонуучу дегеле бардыгын жасай ала турганы түшүнүктүү. Чектелген укуктары бар колдонуучу кыйла азыраак зыян келтириши мүмкүн. Тактап айтканда, системаны буза албайт.
IN: – Корголгон периметрде кимдир бирөө серверди толугу менен жок кылуу үчүн күтүлбөгөн протоколдорду түзүүгө аракет кылды, эгер бактылуу болсоңуз, бүткүл кластер... Бул «жакшы» болуп калабы?
MT: "Мен мындай нерселерди уккан эмесмин." Мындай жол менен серверди бузуп алсаңыз болот, бул эч кимге жашыруун эмес. Ичинде иштебей калуу, протоколдон болуу, билдирүүгө ушул сыяктуу нерсени жаза турган ыйгарым укуктуу колдонуучу болуу ... Чынында, бул мүмкүн эмес, анткени ал дагы эле текшерилет. Аны каалабаган колдонуучулар үчүн бул аутентификацияны өчүрүү мүмкүн - анда бул алардын көйгөйү; алар, орой сөз менен айтканда, дубалдарды өздөрү талкалап салышты жана ал жерге пилди түртүп салсаңар болот, ал тебелеп кетет... Бирок, жалпысынан, ремонтчу болуп кийинип ал, келип тарт!
IN: – Баяндама үчүн рахмат. Сергей (Яндекс). Монгдо Реплика топтомундагы добуш берүүчү мүчөлөрдүн санын чектеген константа бар жана бул туруктуу 7 (жети). Эмне үчүн бул туруктуу? Эмне үчүн бул кандайдыр бир параметр эмес?
MT: – Бизде 40 түйүн менен Replica Sets бар. Ар дайым көпчүлүк бар. Кайсы версиясын билбейм...
IN: – Реплика топтомунда сиз добуш берүүгө укугу жок мүчөлөрдү иштете аласыз, бирок эң көп дегенде 7 добуш берүүчү мүчө бар. Эгерде биздин Replica Set 3 маалымат борборлоруна жайылган болсо, бул учурда өчүрүүдөн кантип аман калабыз? Бир маалымат борбору оңой эле өчүп, башка машина кулап калышы мүмкүн.
MT: - Бул отчеттун алкагынан бир аз чыгып кетти. Бул жалпы суроо. Балким, бул тууралуу кийинчерээк айта алам.
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com