Sakoma, kad viską gyvenime verta bent kartą išbandyti. O jei esate įpratę dirbti su reliacinėmis DBVS, tuomet su NoSQL verta susipažinti praktiškai, pirmiausia, bent jau bendram vystymuisi. Dabar, sparčiai tobulėjant šiai technologijai, šia tema pasigirsta daug prieštaringų nuomonių ir karštų diskusijų, o tai ypač skatina susidomėjimą.
Jeigu įsigilintumėte į visų šių ginčų esmę, pamatytumėte, kad jie kyla dėl netinkamo požiūrio. Tie, kurie NoSQL duomenų bazes naudoja būtent ten, kur jų reikia, yra patenkinti ir gauna visus šio sprendimo privalumus. O eksperimentuotojai, kurie remiasi šia technologija kaip panacėja ten, kur ji visai nepritaikoma, yra nusivylę, praradę reliacinių duomenų bazių privalumus ir negavęs didelės naudos.
Papasakosiu apie mūsų patirtį diegiant sprendimą, pagrįstą Cassandra DBVS: su kuo teko susidurti, kaip išėjome iš sudėtingų situacijų, ar galėjome pasinaudoti NoSQL naudojimu ir kur reikėjo investuoti papildomų pastangų/lėšų. .
Pradinė užduotis yra sukurti sistemą, kuri registruoja skambučius tam tikroje saugykloje.
Sistemos veikimo principas yra toks. Įvestis apima failus su specifine struktūra, kuri apibūdina skambučio struktūrą. Tada programa užtikrina, kad ši struktūra būtų saugoma atitinkamuose stulpeliuose. Ateityje išsaugoti skambučiai bus naudojami informacijai apie abonentų srautą rodyti (mokesčiai, skambučiai, balanso istorija).
Visiškai aišku, kodėl jie pasirinko Cassandra – ji rašo kaip kulkosvaidis, lengvai keičiasi ir yra atspari gedimams.
Taigi, štai ką mums davė patirtis
Taip, sugedęs mazgas nėra tragedija. Tai yra Cassandros kaltės tolerancijos esmė. Bet mazgas gali būti gyvas ir tuo pat metu pradėti kenkti jo veikimui. Kaip paaiškėjo, tai iš karto paveikia viso klasterio našumą.
Cassandra neapsaugos jūsų ten, kur Oracle jus išgelbėjo savo suvaržymais. Ir jei paraiškos autorius iš anksto to nesuprato, tada Cassandrai atvykęs dublis nėra prastesnis už originalą. Kai tik jis bus pristatytas, mes jį įdėsime.
IB labai nepatiko nemokama Cassandra iš dėžutės: Nėra vartotojo veiksmų registravimo, teisių diferencijavimo. Informacija apie skambučius yra laikoma asmens duomenimis, o tai reiškia, kad visi bandymai bet kokiu būdu jos prašyti/pakeisti turi būti registruojami su galimybe vėliau atlikti auditą. Be to, turite žinoti, kad skirtingiems vartotojams reikia atskirti skirtingų lygių teises. Paprastas operacijų inžinierius ir superadministratorius, galintis laisvai ištrinti visą klavišų sritį, atlieka skirtingus vaidmenis, skirtingas pareigas ir kompetencijas. Be tokio prieigos teisių diferencijavimo, duomenų vertė ir vientisumas iš karto kils greičiau nei esant BET KOKIO nuoseklumo lygiui.
Mes neatsižvelgėme į tai, kad skambinant reikia rimtos analizės ir periodinio atrankos įvairioms sąlygoms. Kadangi pasirinkti įrašai turėtų būti ištrinti ir perrašyti (kaip užduoties dalis, mes turime palaikyti duomenų atnaujinimo procesą, kai duomenys iš pradžių buvo įvesti neteisingai), Cassandra čia nėra mūsų draugas. „Cassandra“ yra kaip taupyklė - patogu dėti daiktus, bet negalite joje suskaičiuoti.
Perkeliant duomenis į bandomąsias zonas iškilo problema (5 mazgai teste, palyginti su 20 išleistuvių). Tokiu atveju sąvartyno naudoti negalima.
Problema, susijusi su programos, rašančios Cassandra, duomenų schemos atnaujinimu. Atšaukus, atsiras daug antkapių, o tai gali lemti nenuspėjamu būdu sumažėjusį produktyvumą.. Cassandra yra optimizuota įrašymui ir prieš rašydamas daug negalvoja.Bet kokia operacija su turimais duomenimis taip pat yra įrašymas. Tai yra, ištrynę nereikalingus, mes tiesiog pagaminsime dar daugiau įrašų ir tik dalis jų bus pažymėti antkapiais.
Laikas baigiasi įdėjus. Kasandra įraše graži, bet kartais įeinantis srautas gali ją gerokai sugluminti. Taip atsitinka, kai programa pradeda apeiti kelis įrašus, kurių dėl kokios nors priežasties negalima įterpti. Ir mums reikės tikro DBA, kuris stebės gc.log, sistemos ir derinimo žurnalus, kad gautų lėtas užklausas, laukiama sutankinimo metrikas.
Keli duomenų centrai klasteryje. Iš kur skaityti ir kur rašyti?
Galbūt skirstyti į skaitymą ir rašymą? Ir jei taip, ar DC turėtų būti arčiau programos rašymui ar skaitymui? Ir ar tikrai nesusiskaldys smegenys, jei pasirinksime netinkamą nuoseklumo lygį? Yra daug klausimų, daug nežinomų nustatymų, galimybių, su kuriomis tikrai norisi padirbėti.
Kaip mes nusprendėme
Kad mazgas nenugrimztų, SWAP buvo išjungtas. O dabar, jei trūksta atminties, mazgas turėtų nusileisti ir nedaryti didelių gc pauzių.
Taigi duomenų bazėje nebepasikliaujame logika. Programų kūrėjai persikvalifikuoja ir pradeda aktyviai imtis atsargumo priemonių savo kode. Idealus aiškus duomenų saugojimo ir apdorojimo atskyrimas.
Įsigijome palaikymą iš „DataStax“. Boksinės Cassandra kūrimas jau nutrūko (paskutinis įsipareigojimas buvo 2018 m. vasario mėn.). Tuo pačiu Datastax siūlo puikų aptarnavimą ir daugybę modifikuotų bei pritaikytų sprendimų esamiems IP sprendimams.
Taip pat noriu pastebėti, kad Cassandra nėra labai patogi atrankos užklausoms. Žinoma, CQL yra didelis vartotojų žingsnis į priekį (palyginti su Trift). Bet jei turite ištisus skyrius, kurie yra pripratę prie tokių patogių sujungimų, nemokamo filtravimo pagal bet kurį lauką ir užklausų optimizavimo galimybių, o šie skyriai stengiasi išspręsti skundus ir nelaimingus atsitikimus, tada Cassandra sprendimas jiems atrodo priešiškas ir kvailas. Ir mes pradėjome spręsti, kaip mūsų kolegos turėtų daryti pavyzdžius.
Svarstėme du variantus.Pirmuoju variantu skambučius rašome ne tik C*, bet ir archyvuojamoje Oracle duomenų bazėje. Tik, priešingai nei C*, šioje duomenų bazėje saugomi tik einamojo mėnesio skambučiai (pakankamas skambučių saugojimo gylis dėklų įkrovimui). Čia iš karto pamatėme tokią problemą: jei rašome sinchroniškai, tai prarandame visus C* privalumus, susijusius su greitu įterpimu, jei rašome asinchroniškai, nėra garantijos, kad visi reikalingi skambučiai iš viso pateko į Oracle. Buvo vienas pliusas, bet didelis: darbui lieka tas pats pažįstamas PL/SQL Developer, t.y. praktiškai įgyvendiname „Facade“ šabloną.Alternatyvus variantas. Įdiegiame mechanizmą, kuris iškrauna skambučius iš C*, iš atitinkamų „Oracle“ lentelių ištraukia tam tikrus duomenis, kad būtų galima praturtinti, sujungia gautus pavyzdžius ir pateikia mums rezultatą, kurį mes tada kažkaip naudojame (atsukame atgal, kartojame, analizuojame, žavimės). Suvart: procesas yra gana daugiapakopis, be to, nėra sąsajos operatyviniams darbuotojams.
Galiausiai apsistojome prie antrojo varianto. Apache Spark buvo naudojamas mėginiams iš skirtingų stiklainių. Mechanizmo esmė sumažinta iki Java kodo, kuris, naudodamas nurodytus raktus (abonento, skambučio laiko - sekcijos klavišus), ištraukia duomenis iš C*, taip pat reikiamus duomenis praturtinti iš bet kurios kitos duomenų bazės. Po to jis sujungia juos į savo atmintį ir parodo rezultatą gautoje lentelėje. Virš kibirkšties nupiešėme žiniatinklio veidą ir pasirodė, kad jį visai galima naudoti.
Spręsdami pramoninių bandymų duomenų atnaujinimo problemą, vėl apsvarstėme keletą sprendimų. Tiek perkėlimas per Sstloader, tiek galimybė padalyti klasterį bandomojoje zonoje į dvi dalis, kurių kiekviena pakaitomis priklauso tai pačiai klasteriui su reklamine, todėl yra maitinama jo. Atnaujinant testą buvo numatyta juos sukeisti: ta dalis, kuri veikė teste, išvaloma ir įtraukiama į gamybą, o kita pradeda dirbti su duomenimis atskirai. Tačiau dar kartą pagalvoję, racionaliau įvertinome duomenis, kuriuos verta perkelti, ir supratome, kad patys skambučiai yra nenuoseklus testų vienetas, prireikus greitai sugeneruojamas, o būtent reklaminis duomenų rinkinys neturi jokios vertės perduoti į bandymas. Yra keletas saugojimo objektų, kuriuos verta perkelti, tačiau tai tiesiog pora stalų, o ne labai sunkūs. Todėl mes kaip sprendimas vėl į pagalbą atėjo „Spark“, kurios pagalba rašėme ir pradėjome aktyviai naudoti scenarijų duomenų perdavimui tarp lentelių, prom-test.
Mūsų dabartinė diegimo politika leidžia dirbti be atšaukimų. Prieš akciją yra privalomas bandomasis važiavimas, kuriame klaida nėra tokia brangi. Gedimo atveju visada galite išmesti dėklą ir suvynioti visą schemą nuo pat pradžių.
Norint užtikrinti nuolatinį Cassandra prieinamumą, jums reikia dba, o ne tik jis. Kiekvienas dirbantis su programa turi suprasti, kur ir kaip pažvelgti į esamą situaciją ir kaip laiku diagnozuoti problemas. Tam aktyviai naudojame DataStax OpsCenter (darbo krūvių administravimas ir stebėjimas), Cassandra Driver sistemos metriką (rašymo į C* skirtojo laiko skaičius, skaitymo iš C* skirtojo laiko skaičius, didžiausia delsa ir kt.), stebime veikimą. pačios programos, dirbant su Cassandra.
Kai pagalvojome apie ankstesnį klausimą, supratome, kur gali slypėti pagrindinė mūsų rizika. Tai yra duomenų rodymo formos, rodančios duomenis iš kelių nepriklausomų užklausų į saugyklą. Tokiu būdu galime gauti gana nenuoseklią informaciją. Tačiau ši problema būtų tokia pat aktuali, jei dirbtume tik su vienu duomenų centru. Taigi protingiausia čia, žinoma, sukurti paketinę funkciją, skirtą duomenims nuskaityti trečiosios šalies programoje, kuri užtikrins, kad duomenys būtų gauti per vieną laikotarpį. Kalbant apie skirstymą į skaitymą ir rašymą pagal našumą, čia mus sustabdė rizika, kad praradę ryšį tarp nuolatinės srovės, galime susidaryti dvi klasteris, kurie visiškai nesuderinami vienas su kitu.
Dėl to kol kas sustojo ties nuoseklumo lygiu rašant EACH_QUORUM, skaitant - LOCAL_QUORUM
Trumpi įspūdžiai ir išvados
Siekdami įvertinti gautą sprendimą operatyvinės paramos ir tolesnės plėtros perspektyvų požiūriu, nusprendėme pagalvoti, kur dar būtų galima tokią plėtrą pritaikyti.
Iš karto, tada duomenų įvertinimas programoms, pvz., „Mokėkite, kai patogu“ (įkeliame informaciją į C*, skaičiuojame naudojant „Spark“ scenarijus), paraiškų apskaita su apibendrinimo pagal sritį, vaidmenų saugojimas ir vartotojo prieigos teisių apskaičiavimas pagal vaidmenį. matrica.
Kaip matote, repertuaras platus ir įvairus. O jei pasirinksime NoSQL šalininkų/priešininkų stovyklą, tai ir mes prisijungsime prie rėmėjų, nes gavome savo pranašumus ir būtent ten, kur tikėjomės.
Netgi „Cassandra“ parinktis leidžia atlikti horizontalų mastelį realiuoju laiku, visiškai neskausmingai išspręsdama sistemos duomenų padidėjimo problemą. Mes sugebėjome perkelti labai didelės apkrovos mechanizmą skambučių agregatų skaičiavimui į atskirą grandinę, taip pat atskirti programos schemą ir logiką, taip atsikratydami blogos praktikos rašyti pasirinktines užduotis ir objektus pačioje duomenų bazėje. Gavome galimybę pasirinkti ir konfigūruoti, paspartinti, kuriuose DC atliksime skaičiavimus ir kuriuose fiksuosime duomenis, apsidrausėme tiek nuo atskirų mazgų, tiek nuo visos DC gedimų.
Taikant mūsų architektūrą naujiems projektams ir jau turint tam tikrą patirtį, iš karto norėčiau atsižvelgti į aukščiau aprašytus niuansus ir užkirsti kelią kai kurioms klaidoms, išlyginti kai kuriuos aštrius kampus, kurių iš pradžių nepavyko išvengti.
Pavyzdžiui, laiku sekti Kasandros atnaujinimusnes nemažai problemų, kurias gavome, jau buvo žinomos ir išspręstos.
Nedėkite ir pačios duomenų bazės, ir „Spark“ į tuos pačius mazgus (arba griežtai padalinkite iš leistino išteklių naudojimo kiekio), nes „Spark“ gali suvalgyti daugiau OP, nei tikėtasi, ir mes greitai iš savo sąrašo gausime 1 problemą.
Tobulinti stebėseną ir veiklos kompetenciją projekto testavimo etape. Iš pradžių kiek įmanoma atsižvelkite į visus potencialius mūsų sprendimo vartotojus, nes nuo to galiausiai priklausys duomenų bazės struktūra.
Kelis kartus pasukite gautą grandinę, kad būtų galima optimizuoti. Pasirinkite, kuriuos laukus galima suskirstyti. Supraskite, kokias papildomas lenteles turėtume sudaryti, kad būtų teisingiausia ir optimaliausia atsižvelgti, o tada paprašius pateikti reikiamą informaciją (pvz., darant prielaidą, kad tuos pačius duomenis galime saugoti skirtingose lentelėse, atsižvelgiant į skirtingus suskirstymus pagal skirtingi kriterijai, galime žymiai sutaupyti procesoriaus laiko skaitymo užklausoms).
Ne blogai Nedelsdami numatykite prijungti TTL ir išvalyti pasenusius duomenis.
Atsisiunčiant duomenis iš Cassandra Taikymo logika turėtų veikti FETCH principu, kad ne visos eilutės būtų įkeliamos į atmintį iš karto, o būtų pasirenkamos partijomis.
Patartina prieš perkeliant projektą į aprašytą sprendimą patikrinkite sistemos atsparumą gedimams, atlikdami kelis smūgio testus, pavyzdžiui, duomenų praradimas viename duomenų centre, sugadintų duomenų atkūrimas per tam tikrą laikotarpį, tinklo nutrūkimas tarp duomenų centrų. Tokie testai ne tik leis įvertinti siūlomos architektūros privalumus ir trūkumus, bet ir suteiks gerą apšilimo praktiką juos atliekantiems inžinieriams, o įgyti įgūdžiai toli gražu nebus nereikalingi, jei sistemos gedimai bus atkartoti gamyboje.
Jei dirbame su svarbia informacija (pavyzdžiui, duomenys atsiskaitymui, abonento skolos apskaičiavimas), tuomet verta atkreipti dėmesį ir į įrankius, kurie sumažins riziką, kylančią dėl DBVS ypatybių. Pavyzdžiui, naudokite nodesync įrankį (Datastax), sukūrę optimalią jos naudojimo strategiją, kad dėl nuoseklumo nesukurkite pernelyg didelės apkrovos Kasandrai ir naudoti jį tik tam tikroms lentelėms tam tikru laikotarpiu.
Kas atsitiks Cassandrai po šešių gyvenimo mėnesių? Apskritai neišspręstų problemų nėra. Taip pat neleidome rimtų nelaimingų atsitikimų ar duomenų praradimo. Taip, turėjome galvoti apie kai kurių problemų, kurių anksčiau nebuvo, kompensavimą, bet galiausiai tai mūsų architektūrinio sprendimo labai neaptemdė. Jei norite ir nebijote išbandyti ką nors naujo, o tuo pačiu nenorite per daug nusivilti, tuomet pasiruoškite, kad nieko nėra nemokamai. Turėsite suprasti, įsigilinti į dokumentaciją ir surinkti savo individualų grėblį labiau nei sename sename sprendime, ir jokia teorija iš anksto nepasakys, koks grėblys jūsų laukia.
Šaltinis: www.habr.com