Кажу да све у животу вреди покушати бар једном. А ако сте навикли да радите са релационим ДБМС-овима, онда је вредно да се упознате са НоСКЛ-ом у пракси, пре свега, барем за општи развој. Сада, због брзог развоја ове технологије, постоји много опречних мишљења и жестоких дебата на ову тему, што посебно подстиче интересовање.
Ако се удубите у суштину свих ових спорова, можете видети да они настају због погрешног приступа. Они који користе НоСКЛ базе података тачно тамо где су потребне, задовољни су и добијају све предности овог решења. И експериментатори који се ослањају на ову технологију као на лек тамо где она уопште није применљива, разочарани су, јер су изгубили снагу релационих база података, а да нису добили значајне користи.
Рећи ћу вам о нашем искуству у имплементацији решења заснованог на Цассандра ДБМС: са чиме смо се морали суочити, како смо се извукли из тешких ситуација, да ли смо могли да извучемо корист од коришћења НоСКЛ-а и где смо морали да уложимо додатне напоре/финансијска средства .
Почетни задатак је да се изгради систем који снима позиве у неку врсту складишта.
Принцип рада система је следећи. Улаз укључује датотеке са специфичном структуром која описује структуру позива. Апликација затим осигурава да се ова структура чува у одговарајућим колонама. Убудуће, сачувани позиви се користе за приказ информација о потрошњи саобраћаја за претплатнике (наплате, позиви, историја стања).
Сасвим је јасно зашто су изабрали Касандру - она пише као митраљез, лако је прилагодљива и толерантна је на грешке.
Дакле, ово је оно што нам је искуство дало
Да, неуспели чвор није трагедија. Ово је суштина Касандрине толеранције на грешке. Али чвор може бити жив и истовремено почети да пати у перформансама. Како се испоставило, то одмах утиче на перформансе читавог кластера.
Цассандра вас неће заштитити тамо где вас је Орацле спасио својим ограничењима. А ако аутор апликације ово није унапред разумео, онда дупликат који је стигао за Касандру није ништа гори од оригинала. Када стигне, ставићемо га.
ИБ-у се јако није свидела слободна Цассандра из кутије: Нема евидентирања радњи корисника, нема диференцијације права. Информације о позивима се сматрају личним подацима, што значи да се сви покушаји да се на било који начин захтевају/промене морају евидентирати уз могућност накнадне ревизије. Такође, морате бити свесни потребе да се права одвоје на различитим нивоима за различите кориснике. Инжењер једноставног рада и супер администратор који може слободно да брише цео простор кључева су различите улоге, различите одговорности и надлежности. Без такве диференцијације права приступа, вредност и интегритет података ће одмах доћи у питање брже него са БИЛО КОЈИМ нивоом доследности.
Нисмо узели у обзир да позиви захтевају и озбиљну аналитику и периодично узорковање за различите услове. Пошто би изабрани записи тада требало да буду обрисани и преписани (као део задатка, морамо да подржимо процес ажурирања података када су подаци у почетку погрешно ушли у нашу петљу), Касандра овде није наш пријатељ. Касандра је као касица прасица - згодно је ставити ствари, али не можете рачунати у њу.
Наишли смо на проблем при преносу података у тестне зоне (5 чворова у тесту наспрам 20 на матури). У овом случају, думп се не може користити.
Проблем са ажурирањем шеме података апликације која пише у Цассандру. Враћање ће створити велики број надгробних споменика, што може довести до губитка продуктивности на непредвидиве начине.. Цассандра је оптимизована за снимање, и не размишља много пре писања.Свака операција са постојећим подацима у њој је такође снимање. Односно, брисањем непотребних једноставно ћемо произвести још више записа, а само неки од њих ће бити обележени надгробним споменицима.
Временска ограничења приликом уметања. Касандра је лепа на снимку, али понекад је долазни ток може значајно збунити. Ово се дешава када апликација почне да кружи око неколико записа који се из неког разлога не могу убацити. И биће нам потребан прави ДБА који ће надгледати гц.лог, системске евиденције и евиденције отклањања грешака за споре упите, метрике о сажимању на чекању.
Неколико центара података у кластеру. Одакле читати и где писати?
Можда поделити на читање и писање? И ако јесте, да ли треба да постоји ДЦ ближе апликацији за писање или читање? И зар нећемо завршити са правим подељеним мозгом ако изаберемо погрешан ниво доследности? Постоји много питања, много непознатих подешавања, могућности са којима заиста желите да се позабавите.
Како смо одлучили
Да бисмо спречили да чвор потоне, онемогућили смо СВАП. А сада, ако постоји недостатак меморије, чвор треба да се спусти и не ствара велике гц паузе.
Дакле, више се не ослањамо на логику у бази података. Програмери апликација се поново обучавају и почињу да активно предузимају мере предострожности у свом сопственом коду. Идеално јасно раздвајање складиштења и обраде података.
Купили смо подршку од ДатаСтак-а. Развој Бокед Цассандре је већ престао (последње урезивање је било у фебруару 2018.). Истовремено, Датастак нуди одличну услугу и велики број модификованих и прилагођених решења за постојећа ИП решења.
Такође желим да приметим да Касандра није баш згодна за упите о избору. Наравно, ЦКЛ је велики корак напред за кориснике (у поређењу са Трифтом). Али ако имате читава одељења која су навикла на тако згодна спајања, бесплатно филтрирање према било ком пољу и могућности оптимизације упита, а ова одељења раде на решавању притужби и незгода, онда им решење о Касандри делује непријатељски и глупо. И почели смо да одлучујемо како би наше колеге требало да праве узорке.
Размотрили смо две опције.У првој опцији пишемо позиве не само у Ц*, већ иу архивираној Орацле бази података. Само, за разлику од Ц*, ова база података чува позиве само за текући месец (довољна дубина складиштења позива за случајеве допуне). Овде смо одмах видели следећи проблем: ако пишемо синхроно, онда губимо све предности Ц* повезане са брзим уметањем; ако пишемо асинхроно, нема гаранције да су сви потребни позиви уопште доспели у Орацле. Постојао је један плус, али велики: за рад остаје исти познати ПЛ/СКЛ Девелопер, односно практично имплементирамо шаблон „Фацаде” Алтернативна опција. Имплементирамо механизам који ослобађа позиве из Ц*, извлачи неке податке за обогаћивање из одговарајућих табела у Орацле-у, спаја резултујуће узорке и даје нам резултат, који ми онда некако користимо (повратимо, поновимо, анализирамо, дивимо се). Против: процес је прилично вишестепени, а поред тога, нема интерфејса за запослене у операцији.
На крају смо се одлучили на другу опцију. Апацхе Спарк је коришћен за узорковање из различитих тегли. Суштина механизма је сведена на Јава код, који коришћењем наведених кључева (претплатник, време позива - кључеви секције) извлачи податке из Ц*, као и потребне податке за обогаћивање из било које друге базе података. Након тога их спаја у својој меморији и приказује резултат у резултујућој табели. Нацртали смо веб лице преко искре и показало се прилично употребљиво.
Приликом решавања проблема ажурирања података о индустријским тестовима, поново смо размотрили неколико решења. И пренос преко Сстлоадер-а и могућност поделе кластера у тест зони на два дела, од којих сваки наизменично припада истом кластеру са промотивним, тако да се њиме напаја. Приликом ажурирања теста планирано је да се они замене: део који је радио у тесту се брише и улази у производњу, а други почиње да ради са подацима одвојено. Међутим, након поновног размишљања, рационалније смо проценили податке које је вредело пренети и схватили да су сами позиви неконзистентан ентитет за тестове, који се по потреби брзо генерише, а промотивни скуп података нема вредност за пренос у тест. Постоји неколико складишних објеката које вреди померити, али ово је буквално неколико столова, и то не баш тешких. Стога ми као решење поново је прискочио у помоћ Спарк, уз помоћ којег смо написали и почели активно да користимо скрипту за пренос података између табела, пром-тест.
Наша тренутна политика примене нам омогућава да радимо без враћања. Пре промоције, постоји обавезна пробна вожња, где грешка није тако скупа. У случају неуспеха, увек можете да испустите простор за случај и да окренете целу шему од почетка.
Да бисте осигурали сталну доступност Цассандре, потребан вам је дба и не само он. Сви који раде са апликацијом морају да разумеју где и како да сагледају тренутну ситуацију и како да на време дијагностикују проблеме. Да бисмо то урадили, активно користимо ДатаСтак ОпсЦентер (Администрација и праћење радних оптерећења), системске метрике Цассандра Дривер (број временских ограничења за писање на Ц*, број тајм-аута за читање са Ц*, максимално кашњење, итд.), пратимо рад саме апликације, радећи са Касандром.
Када смо размишљали о претходном питању, схватили смо где би могао да лежи наш главни ризик. Ово су обрасци за приказ података који приказују податке из неколико независних упита до складишта. На овај начин можемо добити прилично недоследне информације. Али овај проблем би био једнако релевантан када бисмо радили само са једним дата центром. Дакле, овде је најразумније, наравно, креирати батцх функцију за читање података на апликацији треће стране, која ће обезбедити да се подаци примају у једном временском периоду. Што се тиче поделе на читање и писање по перформансама, овде нас је зауставио ризик да би уз извесни губитак везе између ДЦ-а могли да добијемо два кластера који су међусобно потпуно неусаглашени.
Као резултат, за сада заустављен на нивоу доследности за писање ЕАЦХ_КУОРУМ, за читање - ЛОЦАЛ_КУОРУМ
Кратки утисци и закључци
Да бисмо проценили добијено решење са становишта оперативне подршке и перспективе даљег развоја, одлучили смо да размислимо о томе где би се још могао применити такав развој.
Одмах, затим бодовање података за програме као што је „Плати када је згодно“ (информације учитавамо у Ц*, израчунавање помоћу Спарк скрипти), обрачун захтева са агрегацијом по областима, чување улога и израчунавање права приступа корисника на основу улоге матрица.
Као што видите, репертоар је широк и разноврстан. А ако изаберемо табор присталица/противника НоСКЛ-а, онда ћемо се придружити присталицама, пошто смо добили своје предности, и то тачно тамо где смо очекивали.
Чак и опција Цассандра ван кутије омогућава хоризонтално скалирање у реалном времену, апсолутно безболно решавајући проблем повећања података у систему. Успели смо да преместимо механизам са веома великим оптерећењем за израчунавање агрегата позива у засебно коло, а такође одвојимо шему и логику апликације, ослобађајући се лоше праксе писања прилагођених послова и објеката у самој бази података. Добили смо могућност да бирамо и конфигуришемо, да убрзамо, на којим ДЦ-овима ћемо вршити прорачуне и на које ћемо снимати податке, осигурали смо се од кварова како појединачних чворова тако и ДЦ-а у целини.
Примењујући нашу архитектуру на нове пројекте, а већ имам одређено искуство, желео бих да одмах узмем у обзир горе описане нијансе и спречим неке грешке, изгладим неке оштре углове који се у почетку нису могли избећи.
На пример, благовремено пратите Касандрина ажурирањајер је доста проблема које смо добили већ познато и отклоњено.
Немојте стављати и саму базу података и Спарк на исте чворове (или стриктно поделити са количином дозвољеног коришћења ресурса), пошто Спарк може да поједе више ОП-а него што се очекивало, и брзо ћемо добити проблем број 1 са наше листе.
Побољшати надзор и оперативну компетенцију у фази тестирања пројекта. У почетку, узмите у обзир што је више могуће све потенцијалне потрошаче нашег решења, јер је то оно од чега ће структура базе података на крају зависити.
Окрените резултујуће коло неколико пута за могућу оптимизацију. Изаберите која поља могу бити серијализована. Разумети које додатне табеле треба да направимо да бисмо што тачније и оптималније узели у обзир, а затим дајте потребне информације на захтев (на пример, под претпоставком да можемо да складиштимо исте податке у различитим табелама, узимајући у обзир различите рашчлањености према различитим критеријумима, можемо значајно уштедети ЦПУ време за захтеве за читање).
Није лоше Одмах обезбедите прикључивање ТТЛ-а и чишћење застарелих података.
Приликом преузимања података са Цассандре Логика апликације треба да ради на принципу ФЕТЦХ, тако да се сви редови не учитавају у меморију одједном, већ се бирају у групама.
Препоручљиво је пре преношења пројекта на описано решење проверите толеранцију грешака система спровођењем серије тестова судара, као што је губитак података у једном дата центру, обнављање оштећених података током одређеног периода, прекид мреже између дата центара. Такви тестови не само да ће омогућити да се процени предности и недостаци предложене архитектуре, већ ће такође пружити добру праксу загревања за инжењере који их спроводе, а стечена вештина ће бити далеко од сувишне ако се системски кварови репродукују у производњи.
Ако радимо са критичним информацијама (као што су подаци за наплату, обрачун дуга претплатника), онда је вредно обратити пажњу и на алате који ће смањити ризике који настају због карактеристика ДБМС-а. На пример, користите услужни програм за синхронизацију чворова (Датастак), након што сте развили оптималну стратегију за његову употребу како бисте ради доследности, не стварајте претерано оптерећење на Касандри и користити га само за одређене табеле у одређеном периоду.
Шта се дешава са Касандром после шест месеци живота? Генерално, нема нерешених проблема. Такође нисмо дозволили озбиљне незгоде или губитак података. Да, морали смо да размишљамо о компензацији неких проблема који се раније нису јављали, али то на крају није много помутило наше архитектонско решење. Ако желите и не плашите се да пробате нешто ново, а у исто време не желите да будете превише разочарани, онда се припремите на чињеницу да ништа није бесплатно. Мораћете више да разумете, удубите се у документацију и саставите свој индивидуални раке него у старом решењу, и ниједна теорија вам неће унапред рећи који раке вас чека.
Извор: ввв.хабр.цом