Ata thonë se çdo gjë në jetë ia vlen të provohet të paktën një herë. Dhe nëse jeni mësuar të punoni me DBMS relacionale, atëherë ia vlen të njiheni me NoSQL në praktikë, para së gjithash, të paktën për zhvillimin e përgjithshëm. Tani, për shkak të zhvillimit të shpejtë të kësaj teknologjie, ka shumë mendime kontradiktore dhe debate të nxehta për këtë temë, gjë që ngjall veçanërisht interes.
Nëse thelloheni në thelbin e të gjitha këtyre mosmarrëveshjeve, mund të shihni se ato lindin për shkak të qasjes së gabuar. Ata që përdorin bazat e të dhënave NoSQL pikërisht aty ku nevojiten janë të kënaqur dhe marrin të gjitha avantazhet nga kjo zgjidhje. Dhe eksperimentuesit që mbështeten në këtë teknologji si një ilaç, ku ajo nuk është aspak e zbatueshme, janë të zhgënjyer, pasi kanë humbur pikat e forta të bazave të të dhënave relacionale pa fituar përfitime të rëndësishme.
Unë do t'ju tregoj për përvojën tonë në zbatimin e një zgjidhjeje të bazuar në DBMS Cassandra: me çfarë duhej të përballeshim, si dolëm nga situatat e vështira, nëse ishim në gjendje të përfitonim nga përdorimi i NoSQL dhe ku duhej të investonim përpjekje/fonde shtesë .
Detyra fillestare është të ndërtohet një sistem që regjistron thirrjet në një lloj ruajtjeje.
Parimi i funksionimit të sistemit është si më poshtë. Hyrja përfshin skedarë me një strukturë specifike që përshkruan strukturën e thirrjes. Më pas aplikacioni siguron që kjo strukturë të ruhet në kolonat e duhura. Në të ardhmen, telefonatat e ruajtura përdoren për të shfaqur informacione mbi konsumin e trafikut për abonentët (tarifat, thirrjet, historiku i bilancit).
Është mjaft e qartë pse ata zgjodhën Kasandrën - ajo shkruan si një mitraloz, është lehtësisht e shkallëzueshme dhe tolerante ndaj gabimeve.
Pra, kjo është ajo që na dha përvoja
Po, një nyje e dështuar nuk është një tragjedi. Ky është thelbi i tolerancës së fajit të Kasandrës. Por një nyje mund të jetë e gjallë dhe në të njëjtën kohë të fillojë të vuajë në performancë. Siç doli, kjo ndikon menjëherë në performancën e të gjithë grupit.
Cassandra nuk do t'ju mbrojë atje ku Oracle ju shpëtoi me kufizimet e saj. Dhe nëse autori i aplikacionit nuk e ka kuptuar këtë paraprakisht, atëherë dyfishi që mbërriti për Cassandra nuk është më i keq se origjinali. Sapo të arrijë, do ta vendosim.
IB nuk i pëlqeu shumë Cassandra e lirë jashtë kutisë: Nuk ka regjistrime të veprimeve të përdoruesit, nuk ka diferencim të të drejtave. Informacioni rreth thirrjeve konsiderohet të dhëna personale, që do të thotë se të gjitha përpjekjet për ta kërkuar/ndryshuar atë në çfarëdo mënyre duhet të regjistrohen me mundësinë e auditimit të mëvonshëm. Gjithashtu, duhet të jeni të vetëdijshëm për nevojën për të ndarë të drejtat në nivele të ndryshme për përdorues të ndryshëm. Një inxhinier i thjeshtë operimi dhe një super administrator që mund të fshijë lirisht të gjithë hapësirën kyçe janë role të ndryshme, përgjegjësi dhe kompetenca të ndryshme. Pa një diferencim të tillë të të drejtave të aksesit, vlera dhe integriteti i të dhënave do të vihet menjëherë në pikëpyetje më shpejt se sa me CDO nivel konsistence.
Nuk kemi marrë parasysh që telefonatat kërkojnë analiza serioze dhe kampionime periodike për një sërë kushtesh. Meqenëse të dhënat e zgjedhura supozohet se më pas do të fshihen dhe rishkruhen (si pjesë e detyrës, ne duhet të mbështesim procesin e përditësimit të të dhënave kur të dhënat fillimisht kanë hyrë gabimisht në qarkun tonë), Cassandra nuk është miku ynë këtu. Cassandra është si një bankë derrkucësh - është e përshtatshme të futësh gjërat, por nuk mund të llogarisësh në të.
Kemi hasur një problem me transferimin e të dhënave në zonat e testimit (5 nyje në test kundrejt 20 në prom). Në këtë rast, deponia nuk mund të përdoret.
Problemi me përditësimin e skemës së të dhënave të një aplikacioni që shkruan në Cassandra. Një rikthim do të gjenerojë shumë gurë varresh, të cilat mund të çojnë në humbje të produktivitetit në mënyra të paparashikueshme.. Cassandra është e optimizuar për regjistrim dhe nuk mendon shumë para se të shkruajë.Çdo operacion me të dhëna ekzistuese në të është gjithashtu një regjistrim. Domethënë, duke fshirë të panevojshmet, thjesht do të prodhojmë edhe më shumë regjistrime dhe vetëm disa prej tyre do të shënohen me gurë varri.
Afatet gjatë futjes. Kasandra është e bukur në regjistrim, por ndonjëherë fluksi i hyrjes mund ta shqetësojë ndjeshëm atë. Kjo ndodh kur aplikacioni fillon të qarkullojë rreth disa regjistrimeve që nuk mund të futen për ndonjë arsye. Dhe ne do të kemi nevojë për një DBA të vërtetë që do të monitorojë regjistrat e gc.log, sistemit dhe korrigjimit për pyetje të ngadalta, metrika në pritje të ngjeshjes.
Disa qendra të dhënash në një grup. Nga të lexoni dhe ku të shkruani?
Ndoshta ndahet në lexim dhe shkrim? Dhe nëse po, a duhet të ketë një DC më afër aplikacionit për shkrim apo lexim? Dhe a nuk do të përfundojmë me një tru të vërtetë të ndarë nëse zgjedhim nivelin e gabuar të qëndrueshmërisë? Ka shumë pyetje, shumë cilësime të panjohura, mundësi me të cilat vërtet dëshironi të ndërhyni.
Si vendosëm
Për të parandaluar fundosjen e nyjës, SWAP u çaktivizua. Dhe tani, nëse ka mungesë memorie, nyja duhet të zbresë dhe të mos krijojë pauza të mëdha gc.
Pra, ne nuk mbështetemi më në logjikën në bazën e të dhënave. Zhvilluesit e aplikacioneve po rikualifikojnë veten dhe kanë filluar të marrin masa paraprake në kodin e tyre. Ndarje ideale e qartë e ruajtjes dhe përpunimit të të dhënave.
Ne kemi blerë mbështetje nga DataStax. Zhvillimi i Cassandra-s së boksit tashmë ka pushuar (kryerja e fundit ishte në shkurt 2018). Në të njëjtën kohë, Datastax ofron shërbime të shkëlqyera dhe një numër të madh zgjidhjesh të modifikuara dhe të përshtatura për zgjidhjet ekzistuese IP.
Dua të vërej gjithashtu se Cassandra nuk është shumë e përshtatshme për pyetjet e përzgjedhjes. Sigurisht, CQL është një hap i madh përpara për përdoruesit (krahasuar me Trift). Por nëse keni departamente të tëra që janë mësuar me bashkime kaq të përshtatshme, filtrim falas sipas çdo fushe dhe aftësi të optimizimit të pyetjeve, dhe këto departamente po punojnë për të zgjidhur ankesat dhe aksidentet, atëherë zgjidhja për Cassandra u duket armiqësore dhe budallaqe. Dhe ne filluam të vendosim se si kolegët tanë duhet të bëjnë mostra.
Shqyrtuam dy opsione: Në opsionin e parë, ne shkruajmë thirrje jo vetëm në C*, por edhe në bazën e të dhënave të Oracle të arkivuar. Vetëm, ndryshe nga C*, kjo bazë të dhënash ruan thirrjet vetëm për muajin aktual (thellësi e mjaftueshme e ruajtjes së thirrjeve për rastet e rimbushjes). Këtu pamë menjëherë problemin e mëposhtëm: nëse shkruajmë në mënyrë sinkrone, atëherë humbim të gjitha avantazhet e C* që lidhen me futjen e shpejtë; nëse shkruajmë në mënyrë asinkrone, nuk ka asnjë garanci që të gjitha thirrjet e nevojshme të hyjnë fare në Oracle. Kishte një plus, por një të madh: për funksionim mbetet i njëjti Zhvillues i njohur PL/SQL, pra ne praktikisht zbatojmë modelin "Fasada". Një opsion alternativ. Ne zbatojmë një mekanizëm që shkarkon thirrjet nga C*, tërheq disa të dhëna për pasurim nga tabelat përkatëse në Oracle, bashkon mostrat që rezultojnë dhe na jep rezultatin, të cilin më pas e përdorim disi (rikthehemi, përsërisim, analizojmë, admirojmë). Kundër: procesi është mjaft me shumë hapa, dhe përveç kësaj, nuk ka asnjë ndërfaqe për punonjësit e operimit.
Në fund, u vendosëm në opsionin e dytë. Apache Spark u përdor për të mostrave nga kavanoza të ndryshme. Thelbi i mekanizmit është reduktuar në kodin Java, i cili, duke përdorur çelësat e specifikuar (abonenti, koha e thirrjes - çelësat e seksionit), nxjerr të dhëna nga C*, si dhe të dhënat e nevojshme për pasurim nga çdo bazë të dhënash tjetër. Pas së cilës i bashkon ato në kujtesën e tij dhe e shfaq rezultatin në tabelën që rezulton. Ne vizatuam një faqe rrjeti mbi shkëndijë dhe doli mjaft e përdorshme.
Kur zgjidhëm problemin e azhurnimit të të dhënave të provës industriale, ne konsideruam përsëri disa zgjidhje. Transferimi përmes Sstloader dhe opsioni i ndarjes së grupit në zonën e provës në dy pjesë, secila prej të cilave në mënyrë alternative i përket të njëjtit grup me atë promovues, duke u mundësuar kështu prej tij. Gjatë azhurnimit të testit, ishte planifikuar t'i ndërronin ato: pjesa që funksionoi në provë pastrohet dhe futet në prodhim, dhe tjetra fillon të punojë me të dhënat veçmas. Sidoqoftë, pasi u menduam përsëri, ne vlerësuam në mënyrë më racionale të dhënat që ia vlente të transferoheshin dhe kuptuam se vetë thirrjet janë një entitet jokonsistent për teste, të gjeneruara shpejt nëse është e nevojshme, dhe është grupi i të dhënave promocionale që nuk ka vlerë për t'u transferuar në provë. Ka disa objekte magazinimi që ia vlen të lëvizin, por këto janë fjalë për fjalë disa tavolina, dhe jo shumë të rënda. Prandaj ne Si zgjidhje, Spark përsëri erdhi në shpëtim, me ndihmën e të cilit ne shkruajmë dhe filluam të përdorim në mënyrë aktive një skript për transferimin e të dhënave midis tabelave, prom-test.
Politika jonë aktuale e vendosjes na lejon të punojmë pa kthim prapa. Para promovimit, ka një test të detyrueshëm, ku një gabim nuk është aq i shtrenjtë. Në rast dështimi, gjithmonë mund të hiqni hapësirën e rasteve dhe të rrotulloni të gjithë skemën që nga fillimi.
Për të siguruar disponueshmërinë e vazhdueshme të Cassandra, ju duhet një dba dhe jo vetëm ai. Të gjithë ata që punojnë me aplikacionin duhet të kuptojnë se ku dhe si të shikojnë situatën aktuale dhe si të diagnostikojnë problemet në kohën e duhur. Për ta bërë këtë, ne përdorim në mënyrë aktive DataStax OpsCenter (Administrimi dhe monitorimi i ngarkesave të punës), matjet e sistemit Cassandra Driver (numri i afateve për të shkruar në C*, numri i afateve për leximin nga C*, vonesa maksimale, etj.), monitorojmë funksionimin të vetë aplikacionit, duke punuar me Cassandra.
Kur menduam për pyetjen e mëparshme, kuptuam se ku mund të qëndronte rreziku ynë kryesor. Këto janë forma të shfaqjes së të dhënave që shfaqin të dhëna nga disa pyetje të pavarura në ruajtje. Në këtë mënyrë mund të marrim informacione mjaft të paqëndrueshme. Por ky problem do të ishte po aq i rëndësishëm nëse do të punonim vetëm me një qendër të dhënash. Pra, gjëja më e arsyeshme këtu është, natyrisht, krijimi i një funksioni grumbull për leximin e të dhënave në një aplikacion të palës së tretë, i cili do të sigurojë që të dhënat të merren në një periudhë të vetme kohore. Sa i përket ndarjes në lexim dhe shkrim për sa i përket performancës, këtu na ndaloi rreziku që me një farë humbjeje të lidhjes midis DC-ve, mund të përfundojmë me dy grupime që janë krejtësisht të papajtueshme me njëri-tjetrin.
Si rezultat, tani për tani ndaloi në nivelin e qëndrueshmërisë për të shkruar EACH_QUORUM, për lexim - LOCAL_QUORUM
Përshtypjet dhe përfundimet e shkurtra
Për të vlerësuar zgjidhjen që rezulton nga pikëpamja e mbështetjes operacionale dhe perspektivat për zhvillim të mëtejshëm, vendosëm të mendojmë se ku tjetër mund të zbatohet një zhvillim i tillë.
Fillimisht, më pas vlerësimi i të dhënave për programe si "Paguaj kur është e përshtatshme" (ne ngarkojmë informacionin në C*, llogaritjen duke përdorur skriptet Spark), llogaritja e pretendimeve me grumbullim sipas zonës, ruajtja e roleve dhe llogaritja e të drejtave të aksesit të përdoruesit bazuar në rolin matricë.
Siç mund ta shihni, repertori është i gjerë dhe i larmishëm. Dhe nëse zgjedhim kampin e mbështetësve/kundërshtarëve të NoSQL, atëherë do t'u bashkohemi mbështetësve, pasi i kemi marrë avantazhet tona, dhe pikërisht aty ku prisnim.
Edhe opsioni Cassandra jashtë kutisë lejon shkallëzimin horizontal në kohë reale, duke zgjidhur absolutisht pa dhimbje problemin e rritjes së të dhënave në sistem. Ne ishim në gjendje të zhvendosnim një mekanizëm me ngarkesë shumë të lartë për llogaritjen e agregateve të thirrjeve në një qark të veçantë, dhe gjithashtu të veçonim skemën dhe logjikën e aplikacionit, duke hequr qafe praktikën e keqe të shkrimit të punëve dhe objekteve të personalizuara në vetë bazën e të dhënave. Ne morëm mundësinë për të zgjedhur dhe konfiguruar, për të përshpejtuar, në cilat DC do të kryejmë llogaritjet dhe në cilat do të regjistrojmë të dhënat, u siguruam nga përplasjet e të dy nyjeve individuale dhe DC në tërësi.
Duke aplikuar arkitekturën tonë në projekte të reja, dhe tashmë duke pasur një përvojë, do të doja të merrja menjëherë parasysh nuancat e përshkruara më sipër dhe të shmangja gabimet, të lëmoj disa qoshe të mprehta që nuk mund të shmangeshin në radhë të parë.
Për shembull, mbani gjurmët e përditësimeve të Cassandra në kohën e duhursepse mjaft nga problemet që kemi marrë ishin tashmë të njohura dhe të rregulluara.
Mos i vendosni vetë bazën e të dhënave dhe Spark në të njëjtat nyje (ose ndani rreptësisht me sasinë e përdorimit të burimit të lejuar), pasi Spark mund të hajë më shumë OP sesa pritej, dhe ne do të marrim shpejt problemin numër 1 nga lista jonë.
Përmirësimi i kompetencës monitoruese dhe operacionale në fazën e testimit të projektit. Fillimisht, merrni parasysh sa më shumë të jetë e mundur të gjithë konsumatorët e mundshëm të zgjidhjes sonë, sepse kjo është ajo nga e cila do të varet përfundimisht struktura e bazës së të dhënave.
Rrotulloni qarkun që rezulton disa herë për optimizim të mundshëm. Zgjidhni cilat fusha mund të serializohen. Kuptoni se cilat tabela shtesë duhet të bëjmë në mënyrë që të marrim parasysh sa më saktë dhe në mënyrë optimale, dhe më pas jepni informacionin e kërkuar sipas kërkesës (për shembull, duke supozuar se mund të ruajmë të njëjtat të dhëna në tabela të ndryshme, duke marrë parasysh ndarjet e ndryshme sipas kritere të ndryshme, ne mund të kursejmë ndjeshëm kohën e CPU-së për kërkesat e leximit).
Mesatar Siguroni menjëherë lidhjen e TTL dhe pastrimin e të dhënave të vjetruara.
Kur shkarkoni të dhëna nga Cassandra Logjika e aplikacionit duhet të funksionojë në parimin FETCH, në mënyrë që jo të gjitha rreshtat të ngarkohen menjëherë në memorie, por të zgjidhen në grupe.
Këshillohet përpara transferimit të projektit në zgjidhjen e përshkruar kontrolloni tolerancën e gabimeve të sistemit duke kryer një sërë testesh përplasjeje, të tilla si humbja e të dhënave në një qendër të dhënash, rivendosja e të dhënave të dëmtuara gjatë një periudhe të caktuar, braktisja e rrjetit midis qendrave të të dhënave. Teste të tilla jo vetëm që do të lejojnë që dikush të vlerësojë të mirat dhe të këqijat e arkitekturës së propozuar, por gjithashtu do të sigurojë praktikë të mirë ngrohjeje për inxhinierët që i kryejnë ato, dhe aftësia e fituar nuk do të jetë aspak e tepërt nëse dështimet e sistemit riprodhohen në prodhim.
Nëse punojmë me informacione kritike (siç janë të dhënat për faturimin, llogaritja e borxhit të pajtimtarit), atëherë ia vlen t'i kushtojmë vëmendje edhe mjeteve që do të zvogëlojnë rreziqet që lindin për shkak të veçorive të DBMS. Për shembull, përdorni mjetin nodesync (Datastax), pasi keni zhvilluar një strategji optimale për përdorimin e tij në mënyrë për hir të konsistencës, mos krijoni një ngarkesë të tepruar në Cassandra dhe e përdorin atë vetëm për tabela të caktuara në një periudhë të caktuar.
Çfarë ndodh me Kasandrën pas gjashtë muajsh jetë? Në përgjithësi, nuk ka probleme të pazgjidhura. Ne gjithashtu nuk lejuam asnjë aksident serioz ose humbje të të dhënave. Po, duhej të mendonim për kompensimin e disa problemeve që nuk ishin shfaqur më parë, por në fund kjo nuk e turbulloi shumë zgjidhjen tonë arkitekturore. Nëse dëshironi dhe nuk keni frikë të provoni diçka të re, dhe në të njëjtën kohë nuk dëshironi të jeni shumë të zhgënjyer, atëherë përgatituni për faktin se asgjë nuk është falas. Ju do të duhet të kuptoni, të gërmoni në dokumentacion dhe të grumbulloni grabitjen tuaj individuale më shumë sesa në zgjidhjen e vjetër të trashëgimisë, dhe asnjë teori nuk do t'ju tregojë paraprakisht se cila raketë ju pret.
Burimi: www.habr.com