Thonë se në jetën duhet provuar gjithçka të paktën një herë. Dhe nëse jeni mësuar të punoni me DB të relacionit, është e vlefshme të njihni në praktikë NoSQL, së paku për zhvillim të përgjithshëm. Tani, për shkak të zhvillimit të shpejtë të kësaj te technologie, ka shumë mendime kontradiktore dhe debate të zjarrta në këtë temë, që veçanërisht nxisin interesin.
Nëse shqyrtojmë thelbin e të gjitha këtyre debateve, mund të shohim se ato lindin nga një qasje e gabuar. Ata që i përdorin bazat e të dhënave NoSQL aty ku nevojiten, janë të kënaqur dhe fitojnë të gjitha avantazhet e këtij zgjidhjeje. Ndërsa eksperimentuesit, që shpresojnë në këtë teknologji si një panace prej aty ku ajo nuk është e aplikueshme fare, ndiejnë zhgënjim, duke humbur pikat e forta të bazave të relacionit pa fituar përfitime të rëndësishme.
Unë do të tregoj për përvojën tonë në implementimin e një zgjidhjeje të bazuar në DB-në Cassandra: për çfarë na është dashur të përballemi, si kemi gjetur zgjidhje në situata të vështira, nëse kemi arritur të fitojmë nga përdorimi i NoSQL, dhe ku na është dashur të investojmë përpjekje/fonde shtesë.
Detyra fillestare është ndërtimi i një sistemi që regjistron thirrjet në një depo.
Principi i punës së sistemit është si vjen. Në hyrje vijnë skedarë me një strukturë të caktuar, që përshkruan strukturën e thirrjes. Më pas, aplikacioni siguron ruajtjen e kësaj strukture në kolonat përkatëse. Në vazhdim, thirrjet e ruajtura përdoren - për të shfaqur informacionin mbi konsumimin e trafikut për abonentët (akumulime, thirrje, historia e bilancit).
Pse u zgjodh Cassandra është e qartë - ajo shkruan si një mitraloz, është lehtësisht e shkallëzueshme dhe e qëndrueshme ndaj dështimeve.
Pra, ja çfarë na ofroi eksperienca
Po, një nod i rënë - nuk është tragjedi. Kjo është thelbi i qëndrueshmërisë së dështimit të Cassandrës. Por noda mund të jetë aktive dhe megjithatë të fillojë të bjerë në performancë.Siç rezultoi, kjo reflektohet menjëherë në performancën e gjithë klasterit.
Cassandra nuk do të ofrojë siguri atje ku Oracle shpëtonte me kufizimet e tij.Dhe nëse autori i aplikacionit nuk e kuptoi këtë paraprakisht, atëherë një dublim i ardhur për Cassandrën nuk është aspak më keq se origjinali. Po erdhi, atëherë le t'i vendosim.
Cassandra pa pagesĂ« "nga kutia" me tĂ« vĂ«rtetĂ« nuk i pĂ«lqeu SigurisĂ« sĂ« InformatĂ«s: nuk ka regjistrim tĂ« veprimeve tĂ« pĂ«rdoruesve, as ndarje tĂ« tĂ« drejtave.. Informacioni mbi thirrjet i pĂ«rket tĂ« dhĂ«nave personale, qĂ« do tĂ« thotĂ« se tĂ« gjitha pĂ«rpjekjet pĂ«r ta kĂ«rkuar/ndryshuar atĂ« duhet tĂ« regjistrohen me mundĂ«sinĂ« e auditimit tĂ« mĂ«vonshĂ«m. Gjithashtu, duhet tĂ« kuptohet nevoja pĂ«r tĂ« ndarĂ« tĂ« drejtat nĂ« nivele tĂ« ndryshme pĂ«r pĂ«rdorues tĂ« ndryshme. NjĂ« inxhiner i zakonshĂ«m i operacioneve dhe njĂ« superadmin, i cili mund tĂ« fshijĂ« tĂ« gjithĂ« keyspace pa asnjĂ« problem â janĂ« role tĂ« ndryshme, me pĂ«rgjegjĂ«si dhe kompetenca tĂ« ndryshme. Pa kĂ«tĂ« ndarje tĂ« tĂ« drejtave tĂ« aksesit, vlera dhe integriteti i tĂ« dhĂ«nave do tĂ« vihet shpejt nĂ« pikĂ«pyetje, mĂ« shpejt se nĂ« nivelin e qĂ«ndrushmĂ«risĂ« ANY.
Nuk e kemi marrĂ« parasysh se pĂ«r thirrjet nevojiten analiza serioze, si dhe mostra periodike sipas kushteve tĂ« ndryshme. Duke qenĂ« se regjistrimet e zgjedhura priten tĂ« fshihen dhe ripĂ«rshkruhen (nĂ« kuadĂ«r tĂ« detyrĂ«s ne duhet tĂ« mbajmĂ« procesin e aktulizimit tĂ« tĂ« dhĂ«nave pĂ«r tĂ« dhĂ«nat qĂ« fillimisht na kanĂ« ardhur gabim), atĂ«here Kassandra nuk Ă«shtĂ« ndihmuese kĂ«tu. Kassandra, si njĂ« kasafortĂ« â Ă«shtĂ« e pĂ«rshtatshme pĂ«r tĂ« ruajtur, por nuk Ă«shtĂ« e mundur tĂ« numĂ«rosh brenda saj.
Natyra e përballjes me problemin e transferimit të të dhënave në zonat e testimit. (5 nod në test në përballje me 20 në prodhim). Në këtë rast, nuk do të mund ta përdorim dump-in.
Problemi i azhurnimeve tĂ« skemĂ«s sĂ« tĂ« dhĂ«nave tĂ« aplikacionit qĂ« shkruan nĂ« Cassandra. Rivendosja do tĂ« sjellĂ« njĂ« numĂ«r tĂ« madh varresh, qĂ« nĂ« njĂ« mĂ«nyrĂ« tĂ« paparashikueshme mund tĂ« ndikojĂ« nĂ« performancĂ«n tonĂ«.. Cassandra Ă«shtĂ« optimizuar pĂ«r shkrimin, dhe para se tĂ« shkruajĂ«, nuk mendon shumĂ«. Ădo operacion me tĂ« dhĂ«na ekzistuese nĂ« tĂ« Ă«shtĂ« gjithashtu njĂ« shkrim. Pra, duke fshirĂ« tĂ« tepĂ«rat, thjesht do tĂ« krijojmĂ« mĂ« shumĂ« shkrime, dhe vetĂ«m njĂ« pjesĂ« e tyre do tĂ« shĂ«nohen si varre.
Kohët e pritjes gjatë inserimit. Cassandra është e shkëlqyer në shkrim, por ndonjëherë rrjedha e ardhshme mund ta çudisë atë shumë.. Kjo ndodh kur aplikacioni fillon të rrotullon disa shkrime që nuk mund të inserohen për ndonjë arsye. Dhe do të na nevojitet një DBA i vërtetë, i cili do të monitorojë gc.log, log-et e sistemit dhe debug për kërkesa të ngadalta, metrikat mbi compaction pending.
Disa qendra të dhënash në klaster. Nga ku të lexojmë dhe ku të shkruajmë?
A mund të ndahet në lexim dhe shkrim? Dhe nëse po, duhet të ketë DC për shkrimin apo për leximin afër aplikacionit? A do të kemi një vërtetë split brain nëse zgjedhim gabim nivelin e koherencës? Ka shumë pyetje, shumë konfiguracione dhe mundësi të panjohura që dëshirojmë t'i eksplorojmë.
Si e zgjidhëm
Për të mos lejuar që noda të bjerë, ndaluam SWAP. Dhe tani, në rast se mungon memorie, noda duhet të bjerë, e jo të krijojë pauza të mëdha gc.
Prandaj, nuk mbështetemi më në logjikën në DB. Zhvilluesit e aplikacionit po rishkruajnë dhe fillojnë të sigurohen aktivisht në kodin e tyre. Ndarje e përsosur e qartë e ruajtjes dhe përpunimit të të dhënave.
Blemë mbështetje nga DataStax. Kassandër e paketuar tashmë nuk po zhvillohet më (komiti i fundit në shkurt 2018). Në të njëjtën kohë, Datastax ofron një shërbim të shkëlqyer dhe një numër të madh zgjidhjesh të punuara dhe të adaptuara për sistemet ekzistuese.
Dëshiroj të theksoj se Cassandra nuk është shumë e përshtatshme për kërkesat e të dhënave. Natyrisht, CQL është një hap i madh drejt lehtësimit për përdoruesit (krahasuar me Trift). Por nëse keni të tëra departamente që janë mësuar me ndërlikime të tilla të lehta, filtrimin e lirë në çdo fushë dhe mundësitë e optimizimit të kërkesave, dhe këto departamente punojnë për të zgjidhur pretendimet dhe emergjencat, atëherë një zgjidhje në Cassandra duket si një vendim armiqësor dhe i padijshëm. Dhe ne filluam të zgjidhnim se si kolegët tanë mund të bëjnë seleksione.
Kemi shqyrtuar dy mundĂ«si. NĂ« mundĂ«sinĂ« e parĂ« shkruajmĂ« thirrjet jo vetĂ«m nĂ« C*, por edhe nĂ« bazĂ«n e tĂ« dhĂ«nave arkivore Oracle. Ndryshe nga C*, nĂ« kĂ«tĂ« bazĂ« tĂ« tĂ« dhĂ«nave ruhen thirrjet vetĂ«m pĂ«r muajin aktual (njĂ« thellĂ«si e mjaftueshme ruajtjeje pĂ«r rastet e ri-ndarjes). KĂ«tu shikohet menjĂ«herĂ« problemi i mĂ«poshtĂ«m: nĂ«se shkruajmĂ« nĂ« mĂ«nyrĂ« sinkrone, humbasim tĂ« gjitha avantazhet e C*, tĂ« lidhura me inserimin e shpejtĂ«; nĂ«se asinkrone â nuk ka garanci qĂ« tĂ« gjitha thirrjet e nevojshme do tĂ« pĂ«rfshihen nĂ« Oracle. NjĂ« plus kishte, por tĂ« madh: pĂ«r shpĂ«rndarjen mbetet e njĂ«jta zhvillues i njohur PL/SQL, pra praktikisht zbatojmĂ« modelin "Facada". MundĂ«si alternative. ZbatojmĂ« njĂ« mekanizĂ«m qĂ« nxjerr thirrjet nga C*, merr disa tĂ« dhĂ«na pĂ«r pasurimin nga tabelat pĂ«rkatĂ«se nĂ« Oracle, bashkon grumbujt e marra dhe na jep rezultatin e marrĂ«, tĂ« cilin mĂ« pas e pĂ«rdorim ndonjĂ«herĂ« (e rrotullojmĂ«, e ripĂ«rsĂ«risim, e analizojmĂ«, e admirojmĂ«). Minuse: procesi rezulton tĂ« jetĂ« mjaft shumĂ«-shkallor, dhe pĂ«r mĂ« tepĂ«r, mungon njĂ« ndĂ«rfaqe pĂ«r punonjĂ«sit e shpĂ«rndarjes.
NĂ« fund, u ndalĂ«m nĂ« versionin e dytĂ«. PĂ«r grumbujt nga banka tĂ« ndryshme, kemi pĂ«rdorur Apache Spark. Natyra e mekanizmit Ă«shtĂ« reduktuar nĂ« kodin Java, i cili duke u mbĂ«shtetur nĂ« çelĂ«sat e pĂ«rcaktuar (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 DB tjetĂ«r. MĂ« pas, i bashkon ato nĂ« memorje dhe jep rezultatin nĂ« tabelĂ«n pĂ«rfundimtare. NjĂ« ndĂ«rfaqe web-u Ă«shtĂ« krijuar mbi Spark dhe rezultati Ă«shtĂ« mjaft i pĂ«rdorshĂ«m.
Gjatë zgjidhjes së problemit me përditësimin e të dhënave, ekipi i testimit përsëri shqyrtoi disa alternativa për zgjidhjen. Si migrimi përmes Sstloader, ashtu edhe opsioni për ndarjen e grupit në zonën e testit në dy pjesë, secila prej të cilave hyn alternuar në një grup me atë të prodhimit, duke u furnizuar në këtë mënyrë prej tij. Gjatë përditësimit të testit, ishte planifikuar që t'i ndryshonim vendet: pjesa që punonte në test hiqej dhe futeshin në prodhim, ndërsa tjetra fillonte të punonte me të dhënat veçmas. Megjithatë, duke menduar një herë tjetër, ne e vlerësuam më rasionalisht ato të dhëna që duhej të transferonin dhe kuptuam se thirrjet vetë ishin një entitet jo-konsistent për testet, të gjeneruara shpejt në rast nevoje, dhe pikërisht grupi i të dhënave të prodhimit nuk kishte vlerë për t'u transferuar në test. Ka disa objekte-ruajtës që vlen të transferohen, por janë dosje të pakta, madje, jo të rënda. Prandaj, ne përsëri e gjetëm zgjidhjen në Spark, me ndihmën e të cilit e shkruam dhe filluam ta përdorim aktivisht skriptin për transferimin e të dhënave midis tabelave të prodhimit dhe të testit.
Politika jonë aktuale e shpërndarjes na lejon të punojmë pa rikthime. Para fillimin e promocionit, ka një test të detyrueshëm, ku gabimi nuk është aq i kushtueshëm. Në rast dështimi, gjithmonë mund të heqim case space dhe të riformatojmë të gjithë skemën nga e para.
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ë monitorojnë situatën aktuale dhe si të diagnostikojnë problemet në kohë. Për këtë, ne përdorim aktivisht DataStax OpsCenter (administrim dhe monitorim i ngarkesave të punës), metrikat sistemore të Cassandra Driver (numri i kohëve të shkurtimit në shkrim në C*, numri i kohëve të shkurtimit në lexim nga C*, latenca maksimale, etj.), dhe monitorojmë funksionimin e vetë aplikacionit që punon me Cassandra.
Kur të mendonim për pyetjen e mëparshme, kuptuam se ku mund të fshihet rreziku kryesor. Kjo është forma e paraqitjes së të dhënave, e cila nxjerr të dhëna nga disa kërkesa të pavarura nga njëra-tjetra ndaj depozitës. Në këtë mënyrë, mund të marrim informacione mjaft të papajtueshme. Por ky problem do të ishte po aq i rëndësishëm edhe nëse do të punonim vetëm me një qendër të dhënash. Prandaj, më e arsyeshme do të ishte, natyrisht, të krijonim një funksion përgatitor për leximin e të dhënave në një program të jashtëm, i cili do të sigurojë marrjen e të dhënave në një periudhë të vetme kohe. Sa i përket ndarjes për lexim dhe shkruaj në aspektin e performancës, na ndali rreziku se gjatë ndonjë humbjeje të lidhjes midis qendrave të dhënash, mund të kemi dy klasterë tërësisht të papajtueshëm me njëri-tjetrin.
Si rezultat, pĂ«r momentin ndalĂ«m nĂ« nivelin e pajtueshmĂ«risĂ« pĂ«r shkruim EACH_QUORUM, pĂ«r lexim â LOCAL_QUORUM
Impresionet dhe përfundimet e shkurtra
Për të vlerësuar zgjidhjen e arritur nga këndvështrimi i mbështetjes operative dhe perspektivave për zhvillim të mëtejshëm, vendosëm të mendojmë se ku mund të aplikohet një zhvillim i tillë.
Nëse flasim në përgjithësi, atëherë vlerësimi i të dhënave për programe të tipit "Paguaj kur të përshtatet" (ngarkojmë në S* informacion, llogaritja në skriptet Spark), mbajtja e ankesave me agregimin sipas drejtimeve, ruajtja e roleve dhe llogaritja sipas matricës rol për të drejtat e qasjes së përdoruesve.
Siç e shohim, repertori është i gjerë dhe i larmishëm. Dhe nëse duam të zgjedhim anën e mbështetjes/ kundërshtimit të NoSQL, ne do të jemi në anën e mbështetjes, pasi kemi fituar avantazhe dhe sidomos aty ku prisnim.
Edhe varianti Cassandra nga paketa e saj lejon të bëhet shkallëzim horizontal në kohë reale, duke zgjidhur pa dhimbje çështjen e rritjes së të dhënave në sistem. Ne arritëm të nxjerrim në një kontur të veçantë një mekanizëm shumë me ngarkesë për llogaritjen e agregateve për thirrjet, si dhe të ndajmë skemën dhe logjikën e aplikacionit, duke u liruar nga praktikat e gabuara të krijimit të punëve dhe objekteve në vetë bazën e të dhënave. Ne patëm mundësinë të zgjidhim dhe të konfigurojmë, për të përshpejtuar, se në cilat DC do të bëjmë llogaritjen dhe në cilat do të regjistrojmë të dhënat, duke u mbrojtur për rëniet e mundshme, si të nodeve të veçanta, ashtu edhe të përgjithshmeve DC.
Duke aplikoni arkitekturën tonë në projektet e reja, duke pasur njëfarë përvoje, dëshirojmë të marrim parasysh nuancat e përmendura më parë dhe të shmangim disa gabime, për të lehtësuar disa këndvështrime që nuk arritëm t'i shmangim në fillim.
Për shembull, të ndjekim në kohë azhurnimet që vijnë nga Cassandra, sepse shumë nga problemet që kemi hasur ishin tashmë të njohura dhe ishin rregulluar.
Të mos vendosim as bazën e të dhënave dhe as Spark në të njëjtat node ose të ndarë rreptësisht sipas numrit të burimeve të lejuara, pasi Spark mund të konsumojë më shumë RAM sesa pranohet, dhe ne do të përballemi shpejt me problemin numër 1 nga lista jonë.
Të përmirësojmë monitorimin dhe kompetencat e operacionit edhe gjatë fazës së testimit të projektit. Të kemi parasysh sa më shumë potenciale konsumatorë të zgjidhjes sonë që në fillim, sepse pikërisht nga kjo do të varet më në fund struktura e bazës së të dhënave.
Disa disa rrotulloni skemën e marrë për të parë mundësitë e optimizimit. Identifikoni cilat fushat mund të serializohen. Kuptoni cilat tabela shtesë duhet të krijojmë për të menaxhuar më saktë dhe optimalisht informacionin e nevojshëm dhe për ta kthyer sipas kërkesës (për shembull, duke pranuar që të dhëna të njëjta mund të ruhen në tabela të ndryshme, duke marrë parasysh ndarjen e ndryshme sipas kritereve të ndryshme, mund të kursejmë ndjeshëm kohën e procesorëve gjatë kërkesave për lexim).
Nuk është keq të parashikohet menjëherë vendosja e TTL dhe pastrimi i të dhënave të skaduara.
Në nxjerrjen e të dhënave nga Cassandra logjika e aplikacionit duhet të funksionojë sipas parimit FETCH, në mënyrë që të mos ngarkohen të gjitha rreshtat në memorie njëherësh, por të zgjidhen në grupe.
Preferohet para kalimit të projektit në solucionin përshkruar të kontrollohet qëndrueshmëria e sistemit duke kryer një seri testesh crash, duket si humbje të dhënash në një data center, rikuperimi i të dhënave të dëmtuara për një periudhë të caktuar, rëniet e rrjetit midis data center-ave. Këto teste jo vetëm që do të vlerësojnë përfitimet dhe disavantazhet e arkitekturës së propozuar, por gjithashtu do të ofrojnë një praktikë të mirë për inxhinierët që i realizojnë ato, dhe aftësitë e fituara do të jenë të dobishme në rast se ndodhin dështime në sistem.
Nëse po punojmë me informacion kritik (si të dhënat për faturimin, llogaritjen e borxhit të abonentit), duhet gjithashtu të kushtojmë vëmendje mjeteve që do të ndihmojnë të reduktojmë rreziqet që lindin për shkak të veçorive të DBMS. Për shembull, të përdorim mjete si nodesync (Datastax), duke zhvilluar një strategji optimale për përdorimin e saj, që për konsistencën të mos krijojë ngarkesë të tepërt në Cassandra dhe ta përdorim atë vetëm për tabela të caktuara në një periudhë të caktuar.
Pas mĂ« shumĂ« se gjashtĂ« muaj me Kassandra? NĂ« pĂ«rgjithĂ«si, nuk ka probleme tĂ« pazgjidhura. Nuk kemi pasur as aksidente serioze dhe as humbje tĂ« tĂ« dhĂ«nave. Po, duhej tĂ« mendohej pĂ«r kompensimin e disa problemeve qĂ« nuk ishin shfaqur mĂ« parĂ«, por pĂ«rfundimisht kjo nuk e prishi shumĂ« zgjidhjen tonĂ« arkitektonike. NĂ«se dĂ«shironi dhe nuk keni frikĂ« tĂ« provoni diçka tĂ« re, dhe pĂ«rveç kĂ«saj nuk doni tĂ« zhgĂ«njeheni shumĂ«, pĂ«rgatituni qĂ« asgjĂ« nuk vjen falas. Do tâju duhet tĂ« shqyrtoni, tĂ« ofroni dokumentacionin dhe tĂ« krijoni gabimet tuaja individuale mĂ« shumĂ« se me zgjidhjet e lashta dhe asnjĂ« teori nuk do tâju tregojĂ« paraprakisht se cilat gabime ju presin juve.
Burimi: habr.com
