Thuhet se në jetë çdo gjë duhet provuar të paktën një herë. Dhe nëse jeni mësuar të punoni me DB-relacionale, atëherë është e rekomandueshme të njihet praktikisht me NoSQL, fillimisht për zhvillim të përgjithshëm. Tani, për shkak të zhvillimit të shpejtë të teknologjisë, ka shumë opinione të kundërta dhe debate të nxehta në lidhje me këtë temë, të cilat veçanërisht nxjerrin në pah interesin.
Nëse thellohesh në thelbin e të gjitha këtyre debateve, mund të shohësh se ato lindin nga një qasje e gabuar. Ata që përdorin bazat e të dhënave NoSQL atje ku janë të nevojshme janë të kënaqur dhe përfitojnë nga ky zgjidhje. Ndërsa eksperimentuesit, që besojnë në këtë teknologji si një ilaç për atje ku ajo nuk aplikohet asnjëherë, përjetojnë zhgënjim, duke humbur përfitimet e forta të bazave të të dhënave relacionale pa fituar ndonjë përfitim të rëndësishëm.
Do të flas për përvojën tonë në zbatimin e një zgjidhjeje, të bazuar në DB-në Cassandra: me çfarë jemi përballur, si kemi dalë nga situatat e vështira, nëse arritëm të përfitonim nga përdorimi i NoSQL dhe ku duhej të investonim përpjekje/shtëpi.
Detyra fillestare është ndërtimi i një sistemi për regjistrimin e thirrjeve në një ruajtje të caktuar.
Parimi i funksionimit tĂ« sistemit Ă«shtĂ« si nĂ« vijim. NĂ« hyrje vijnĂ« skedarĂ« me njĂ« strukturĂ« tĂ« caktuar, qĂ« pĂ«rshkruan strukturĂ«n e thirrjes. Pastaj aplikacioni siguron ruajtjen e kĂ«saj strukture nĂ« kolonat pĂ«rkatĂ«se. MĂ« pas, thirrjet e ruajtura pĂ«rdoren â pĂ«r tĂ« treguar informacionin mbi konsumimin e trafikut pĂ«r abonentĂ«t (lĂ«vizjet, thirrjet, historia e bilancit).
Pse zgjodhĂ«m Cassandra Ă«shtĂ« e qartĂ« â ajo regjistron si njĂ« mitraloz, Ă«shtĂ« lehtĂ« e shkallĂ«zueshme, e qĂ«ndrueshme ndaj dĂ«shtimeve.
Pra, ja çfarë na dhuroi përvoja.
Po, një nod i rënë nuk është një tragjedi. Kjo është thelbi i qëndrueshmërisë së Cassandra-s. Por nodi mund të jetë aktiv dhe në të njëjtën kohë të fillojë të bie në performancë.. Siç u zbulua, kjo ndikon menjëherë në performancën e tërë klasterit.
Cassandra nuk do të të ndihmojë atje ku Oracle shpëton me kufizimet e tij.. Dhe nëse autori i aplikacionit nuk e kuptoi këtë paraprakisht, atëherë dyfishimi i ardhur për Cassandra-n është njëlloj i mirë sa origjinali. Nëse ka ardhur, ne e fusim.
Cassandra falas "nga kutia" nuk i pĂ«lqeu aspak shumicĂ«s sĂ« informacionit pĂ«r tĂ« dhĂ«na: nuk ka regjistrim tĂ« veprimeve tĂ« pĂ«rdoruesve, as ndarjen e tĂ« drejtave gjithashtu.Informacioni nĂ« lidhje me thirrjet i pĂ«rket tĂ« dhĂ«nave personale, duke nĂ«nkuptuar se çdo pĂ«rpjekje pĂ«r ta kĂ«rkuar/ndryshuar atĂ« duhet tĂ« regjistrohet me mundĂ«sinĂ« e auditimit tĂ« mĂ«vonshĂ«m. Po ashtu, duhet tĂ« kuptohet nevoja pĂ«r tĂ« ndarĂ« tĂ« drejtat nĂ« nivele tĂ« ndryshme pĂ«r pĂ«rdorues tĂ« ndryshĂ«m. NjĂ« inxhinier i zakonshĂ«m i operimit dhe njĂ« superadmin, i cili mund tĂ« fshijĂ« gjithçka nĂ« keyspace â janĂ« role tĂ« ndryshme, me pĂ«rgjegjĂ«si dhe kompetenca tĂ« ndryshme. Pa njĂ« ndarje tĂ« tillĂ« tĂ« tĂ« drejtave tĂ« aksesit, vlera dhe integriteti i tĂ« dhĂ«nave menjĂ«herĂ« do tĂ« vihet nĂ« dyshim mĂ« shpejt se nĂ« nivelin e qĂ«ndrueshmĂ«risĂ« ANY.
Nuk e kemi marrĂ« parasysh se pĂ«r thirrjet kĂ«rkohet njĂ« analizĂ« serioze, si dhe mostra tĂ« pĂ«rkohshme sipas kushtesh tĂ« ndryshme. Duke pasur parasysh se regjistrimet e zgjedhura pastaj mendohet tĂ« fshihen dhe tĂ« rivendosen (nĂ« kuadĂ«r tĂ« detyrĂ«s duhet tĂ« mbajmĂ« procesin e aktualizimit tĂ« tĂ« dhĂ«nave pĂ«r tĂ« dhĂ«nat qĂ« fillimisht na janĂ« dĂ«rguar gabimisht), Cassandra kĂ«tu nuk na ndihmon. Cassandra, si njĂ« kasafortĂ« â Ă«shtĂ« e lehtĂ« tĂ« vendosĂ«sh gjĂ«ra atje, por nuk do tĂ« jesh nĂ« gjendje tĂ« bĂ«sh llogari.
Jemi ballafaquar me problemin e transferimit të të dhënave në zonat testuese. (5 nod në test në krahasim me 20 në prodhim). Në këtë rast, nuk do të mund të përdorim dump-in.
Problemi i pĂ«rditĂ«simeve tĂ« skemĂ«s sĂ« tĂ« dhĂ«nave tĂ« aplikacionit qĂ« shkruan nĂ« Cassandra. Rikthimi do tĂ« sjellĂ« njĂ« numĂ«r tĂ« madh varresh, qĂ« nĂ« mĂ«nyrĂ« tĂ« paparashikueshme mund tĂ« na ulin performancĂ«n.Cassandra Ă«shtĂ« optimizuar pĂ«r shkrim, dhe para se tĂ« shkruajĂ«, shumĂ« nuk mendon. Ădo operacion me tĂ« dhĂ«na ekzistuese atje Ă«shtĂ« gjithashtu njĂ« shkrim. DomethĂ«nĂ«, duke fshirĂ« tĂ« tepĂ«rta, ne thjesht do tĂ« krijojmĂ« mĂ« shumĂ« shkrime, dhe vetĂ«m njĂ« pjesĂ« prej tyre do tĂ« shĂ«nohet si varre.
Kohët e pritjes gjatë hyrjes. Cassandra është perfekte për shkrime, por ndonjëherë fluksi i hyrës mund ta shqetësojë atë ndjeshëm.Kjo ndodh kur aplikacioni fillon të ruajë disa regjistrime në një rreth që nuk mund të hynë për ndonjë arsye. Dhe na nevojitet një DBA i vërtetë, që do të monitorojë gc.log, log-et e sistemit dhe debug për query të ngadalta, metrikat për kompresimin e pritur.
Disa qendra të të dhënave në klaster. Nga ku të lexojmë dhe ku të shkruajmë?
A është e mundur të ndajmë mes leximit dhe shkrimit? Dhe nëse po, a duhet të jetë DCB afër aplikacionit për shkrim apo për lexim? A do të kemi një vërtetë "split brain" nëse zgjedhim gabim nivelin e koherencës? Ka shumë pyetje, shumë parametra të panjohur, mundësi që do të dëshironim t'i eksploronim.
Si e zgjidhëm
Për të mos rënë nodi, e çaktivizuam SWAP. Tani, kur ka mungesë të memories, nodi duhet të shkojë poshtë, e jo të prodhojë bllokime të mëdha GC.
Pra, tashmë nuk besojmë më në logjikën e DB. Zhvilluesit e aplikacionit po e rishikojnë dhe fillojnë të mbrohen aktivisht në kodin e tyre. Ndarje perfekte e qartë mes ruajtjes dhe përpunimit të të dhënave.
Kemi blerë mbështetje nga DataStax. Kassandran kutisë ka ndaluar së zhvilluari (komitimi i fundit në shkurt 2018). Megjithatë, Datastax ofron një shërbim të shkëlqyer dhe shumë zgjidhje të përmirësuara dhe të përshtatura sipas sistemeve ekzistuese.
Dua gjithashtu të theksoj se Kassandra nuk është shumë e përshtatshme për kërkesat e seleksionimit. Natyrisht, CQL është një hap i madh drejt përdoruesve (krahasuar me Thrift). Por, nëse keni departamente të tëra që janë mësuar me bashkime të tilla të përshtatshme, filtrime të lira sipas çdo fushe dhe mundësi optimizimi të kërkesave, atëherë zgjidhja në Kassandër duket për ta si një armik i padurueshëm dhe absurd. Dhe ne filluam të zgjidhim pyetjen se si mund t'i bëjmë seleksionet kolegëve tanë.
U shqyrtuar dy variante. NĂ« variantin e parĂ«, shkruajmĂ« thirrje jo vetĂ«m nĂ« C*, por edhe nĂ« bazĂ«n e tĂ« dhĂ«nave arkivore Oracle. MegjithatĂ«, ndryshe nga C*, nĂ« kĂ«tĂ« BDB ruhen thirrjet vetĂ«m pĂ«r muajin aktual (thellĂ«sia e mjaftueshme e ruajtjes sĂ« thirrjeve pĂ«r rastet e ri tarifimit). KĂ«tu u shfaq problemi tjetĂ«r: nĂ«se shkruajmĂ« nĂ« mĂ«nyrĂ« sinkrone, ne humbim tĂ« gjitha pĂ«rparĂ«sitĂ« e C*, lidhur me insertimin e shpejtĂ«; nĂ«se asinkrone â nuk ka garantim qĂ« tĂ« gjitha thirrjet e nevojshme do tĂ« pĂ«rfshihen gjithsesi nĂ« Oracle. NjĂ« pĂ«rparĂ«si e madhe ishte se pĂ«r pĂ«rdorim mbetet e njĂ«jta PL/SQL Developer, pra, praktikisht realizojmĂ« modelin "FasadĂ«". Variante alternative. RealizojmĂ« njĂ« mekanizĂ«m qĂ« nxjerr thirrjet nga C*, merr disa tĂ« dhĂ«na pĂ«r pasurimin nga tabelat pĂ«rkatĂ«se nĂ« Oracle, bashkon seleksionet e marra dhe na jep rezultatin e marrĂ«, qĂ« pastaj ne e pĂ«rdorim ndonjĂ«herĂ« (e kthejmĂ«, e ripĂ«rsĂ«risim, e analizojmĂ«, e admirojmĂ«). Disavantazhet: procesi bĂ«het mjaft shumĂ«-hapĂ«sh, dhe pĂ«r mĂ« tepĂ«r, nuk ka njĂ« ndĂ«rlidhje pĂ«r punonjĂ«sit e operimit.
NĂ« pĂ«rfundim, u ndalĂ«m nĂ« variantin e dytĂ«. PĂ«r seleksionet nga banka tĂ« ndryshme pĂ«rdorĂ«m Apache Spark. Esenca e mekanizmit u reduktua nĂ« njĂ« kod Java, i cili sipas çelĂ«save tĂ« caktuar (abonenti, koha e thirrjes â çelĂ«sat e seksionit) nxjerr tĂ« dhĂ«na nga C*, si dhe tĂ« dhĂ«nat e nevojshme pĂ«r pasurimin nga çdo BDB tjetĂ«r. Pas kĂ«saj, i bashkon ato nĂ« kujtesĂ«n e tij dhe jep rezultatin nĂ« tabelĂ«n pĂ«rfundimtare. PĂ«r Spark, krijuam njĂ« ndĂ«rfaqe web dhe rezultoi tĂ« ishte plotĂ«sisht e pĂ«rdorshme.
Në trajtimin e çështjes së azhurnimit të të dhënave, ne sërish shqyrtuam disa mënyra zgjidhjeje. Si kalimi përmes Sstloader, ashtu dhe varianti me ndarjen e klasterit në zonën e testimit në dy pjesë, ku secila herë hyn në një klaster me atë të prodhimit, duke u furnizuar në këtë mënyrë prej tij. Kur u planifikua azhurnimi i testit, ishte parashikuar të këmbenim vendet: ajo pjesë që punonte në test do të pastronte dhe do të hynte në prodhim, ndërsa tjetra fillonte të punonte me të dhëna ndaras. Megjithatë, duke e menduar përsëri, ne e vlerësuam më racionalisht të dhënat që duhet të transferohen dhe kuptuam se vetë thirrjet janë një entitet jo konsistent për testet, që krijohet shpejt në rast nevoje, dhe pikërisht grupi i të dhënave të prodhimit nuk ka vlerë për transferim në test. ka disa objekte-akumulatorë që duhet të transferohen, por kjo është për të thënë disa tabela, të cilat nuk janë shumë të rënda. Prandaj, ne si zgjidhje përsëri erdhi në ndihmë Spark, me të cilin ne shkruam dhe filluam të përdorim aktivisht skriptin për transferimin e të dhënave midis tabelave prodhim-test.
Politika jonë aktuale e deplojtimit na lejon të punojmë pa rregullime. Para prodhimit, ka një aplikuar obligativ në test, ku gabimi nuk është aq i kushtueshëm. Në rast dështimi, gjithmonë mund të fshijmë case-space dhe të aplikojmë tërë skemën nga fillimi.
Për të siguruar disponueshmërinë e vazhdueshme të Cassandra-s, nevojitet 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ë. Për këtë ne përdorim aktivisht DataStax OpsCenter (Administrimi dhe monitorimi i ngarkesave të punës), metrikat sistemike të Cassandra Driver (numri i kohëve të pritura për shkrim në C*, numri i kohëve të pritura për lexim nga C*, latenca maksimale etj.), monitorojmë punën e vetë aplikacionit, që punon me Cassandra.
Kur kërkuam përgjigje për pyetjen e mëparshme, e kuptuam se ku mund të fshihet rreziku kryesor. Ky është formati i shfaqjes së të dhënave, i cili nxjerr të dhëna nga disa kërkesa të pavarura njëra nga tjetra në depo. Kështu mund të marrim informacione mjaft të papajtueshme. Por kjo problematikë do të ishte e pranishme edhe në rastin nëse do të punonim vetëm me një qendër të dhënash. Prandaj, e vetmja zgjidhje logjike këtu është të krijojmë një funksion grupor për leximin e të dhënave në një aplikacion të jashtëm, i cili do të garantojë marrjen e të dhënave në një periudhë të vetme kohore. Sa i përket ndarjes së leximit dhe shkruajtjes në planin e performancës, këtu u ndalëm nga rreziku se, në rast të humbjes së lidhjes midis QDC-ve, mund të marrim dy klasterë krejtësisht të papajtueshëm me njëri-tjetrin.
Si pĂ«rfundim, deri nĂ« kĂ«tĂ« moment u ndaluam nĂ« nivelin e pajtueshmĂ«risĂ« pĂ«r shkruaj EACH_QUORUM, pĂ«r leximin â LOCAL_QUORUM
Përmbledhje dhe përfundime të shkurtra
Për të vlerësuar zgjidhjen e arritur nga pikëpamja e mbështetjes funksionale dhe perspektivave për zhvillimin e mëtejshëm, vendosëm të mendojmë se ku mund të aplikojmë një zhvillim të tillë.
Nëse flasim shpejt, ndihma e të dhënave për programe si "Paguaj, kur të dëshirosh" (ngarko informacionin në S*, llogaritje në skenarët Spark), llogaria e kërkesave me agregimin sipas drejtimeve, ruajtja e roleve dhe llogaritja sipas matricës së rolit për të drejtat e qasjes së përdoruesve.
Siç e shohim, repertori është i gjerë dhe i larmishëm. Dhe nëse duhet të zgjedhim anën e mbështetësve/kundërshtarëve të NoSQL, ne do të anojmë kah mbështetësit, pasi kemi arritur përfitime, dhe pikërisht aty ku e prisnim.
Madje, varianti Cassandra nga kuti lejon të bëhet shkallëzim horizontal në kohë reale, duke zgjidhur pa dhimbje çështjen e rritjes së të dhënave në sistem. Arritëm të ndajmë një mekanizëm shumë me ngarkesë për llogaritjen e agregateve për thirrjet në një kontur të veçantë, si dhe të ndajmë skemën dhe logjikën e aplikacionit, duke u liruar nga praktika e keqe e shkruarjes së punëve dhe objekteve të personalizuara në vetë DB. Kemi fituar mundësinë të zgjedhim dhe konfigurojmë, për shpejtësi, në cilat QDC do të bëjmë llogaritjen dhe në cilat do të shkruajmë të dhënat, duke u mbrojtur ndaj rënieve si të nyjeve të veçanta, ashtu edhe në përgjithësi të QDC.
Duke përdorim arkitekturën tonë për projektet e reja, dhe, duke pasur tashmë disa përvojë, do të doja që menjëherë të marrim parasysh nuancat e përmendura më sipër dhe të shmangim disa gabime, duke zbutur disa këndvështrime të ashpra që nuk arritëm t'i evitojmë fillimisht.
Për shembull, të monitorojmë në kohë përditësimet e Cassandra-s, sepse shumë nga problemet që kemi pasur, ishin tashmë të njohura dhe ishin rregulluar.
Të mos vendosim si bazën e të dhënave ashtu edhe Spark në të njëjtat nodet. (ose të ndahen rreptësisht sipas sasisë së përdorimit të lejuar të burimeve), pasi Spark mund të konsumojë më shumë RAM sesa e lejuar, dhe ne do të kemi shpejt problemin numër 1 nga lista jonë.
Të zhvillojmë monitorimin dhe kompetencën e operimit edhe në fazën e testimit të projektit. Fillimisht të kemi sa më shumë parasysh të gjithë konsumatorët e mundshëm të zgjidhjes sonë, sepse pikërisht nga kjo do të varet struktura e bazës së të dhënave në fund.
Të rrokim disa herë diagramin e rezultuar për mundësitë e optimizimit. Të përcaktojmë cilat fusha mund të serializohen. Të kuptojmë cilat tabela të tjera duhet të krijojmë, në mënyrë që të marrim informacionin e kërkuar sa më saktë dhe optimalisht (p.sh., duke supozuar se të dhënat e njëjta mund të ruhen në tabela të ndryshme, duke marrë parasysh ndarjen e ndryshme sipas kritereve të ndryshme, mund të kursenim ndjeshëm kohën e procesorit gjatë kërkesave të leximit).
Nuk do të ishte keq të parashikohet menjëherë ndarja e TTL dhe pastrimi i të dhënave të skaduara.
Gjatë eksportit të të dhënave nga Cassandra logjika e aplikacionit duhet të funksionojë sipas parimit FETCH, në mënyrë që jo të gjitha rreshtat të ngarkohen në memorie njëherësh, por të zgjidhen në grupe.
ĂshtĂ« e dĂ«shirueshme qĂ« para kalimit tĂ« projektit nĂ« zgjidhjen e pĂ«rshkruar tĂ« kontrollohet qĂ«ndrueshmĂ«ria e sistemit, duke kryer njĂ« seri testesh crash, si humbja e tĂ« dhĂ«nave nĂ« njĂ« QendrĂ«n e tĂ« DhĂ«nave, rikuperimi i tĂ« dhĂ«nave tĂ« dĂ«mtuara pĂ«r njĂ« periudhĂ« tĂ« caktuar, ngadalĂ«simi i rrjetit midis Qendrave tĂ« tĂ« DhĂ«nave. KĂ«to teste jo vetĂ«m qĂ« do tĂ« lejojnĂ« vlerĂ«simin e avantazheve dhe disavantazheve tĂ« arkitekturĂ«s sĂ« propozuar, por gjithashtu do t'u japin inxhinierĂ«ve qĂ« i realizojnĂ« ato njĂ« praktikĂ« tĂ« mirĂ«, dhe aftĂ«sia e fituar nuk do tĂ« jetĂ« aspak e tepĂ«rt nĂ«se dĂ«shtimet e sistemit ndodhin nĂ« prodhim.
Nëse po punojmë me informacion kritik (siç janë të dhënat për faturim, llogaritjen e borxhit të klientit), ka kuptim të kushtohet vëmendje mjeteve që do të lejojnë uljen e rreziqeve që lindin për shkak të veçorive të DBMS. Për shembull, përdorimi i utilitarit nodesync (Datastax), duke zhvilluar një strategji optimale të përdorimit të tij, në mënyrë që për shkak të konsistencës të mos formohet një ngarkesë tepër në Cassandra dhe ta përdorim vetëm për tabela të caktuara në periudha të caktuara.
ĂfarĂ« ndodhi pas gjashtĂ« muajve me Cassandra? NĂ« pĂ«rgjithĂ«si, nuk ka probleme tĂ« zgjidhura. Nuk kemi lejuar as shpĂ«rthime serioze dhe as humbje tĂ« tĂ« dhĂ«nave. Po, ishte e nevojshme tĂ« mendohej pĂ«r kompenzimin e disa problemeve qĂ« nuk ishin shfaqur mĂ« parĂ«, por nĂ« fund kjo nuk e rĂ«ndoi shumĂ« zgjidhjen tonĂ« arkitekturore. NĂ«se dĂ«shiron dhe nuk ke frikĂ« tĂ« provosh diçka tĂ« re, dhe nĂ« tĂ« njĂ«jtĂ«n kohĂ« nuk dĂ«shiron tĂ« zhgĂ«njehesh shumĂ«, pĂ«rgatitu pĂ«r faktin se asgjĂ« nuk Ă«shtĂ« falas. Do tĂ« duhet tĂ« merresh me detaje, tĂ« thellohet nĂ« dokumentacion dhe tĂ« mbledhĂ«sh gropat e tua individuale mĂ« tepĂ«r se me zgjidhjen e vjetĂ«r legacy dhe asnjĂ« teori nuk do tĂ« tĂ« japĂ« informacion paraprak pĂ«r ato gropa qĂ« tĂ« presin.
Burimi: habr.com
