Esaten dute bizitzan dena merezi duela behinik behin probatzea. Eta DBMS erlazionalekin lan egitera ohituta bazaude, merezi du praktikan NoSQL ezagutzea, lehenik eta behin, garapen orokorrerako behintzat. Orain, teknologia honen garapen azkarra dela eta, iritzi kontrajarriak eta eztabaida sutsuak daude gai honen inguruan, eta horrek bereziki interesa pizten du.
Gatazka horien guztien funtsean sakontzen baduzu, ikuspegi okerraren ondorioz sortzen direla ikus dezakezu. NoSQL datu-baseak behar diren tokian zehatz-mehatz erabiltzen dituztenak pozik daude eta irtenbide honen abantaila guztiak jasotzen dituzte. Eta batere aplikagarria ez den teknologia hori panazea gisa oinarritzen duten esperimentatzaileak etsita daude, datu-base erlazionalen indarguneak galdu baitituzte onura nabarmenik lortu gabe.
Cassandra DBMSn oinarritutako soluzio bat ezartzean dugun esperientzia kontatuko dizut: zer egin behar izan genuen aurre, nola atera ginen egoera zailetatik, ea NoSQL erabiltzeari etekina atera genion eta non inbertitu behar izan genituen ahalegin/funts gehigarriak. .
Hasierako zeregina deiak nolabaiteko biltegian erregistratzen dituen sistema eraikitzea da.
Sistemaren funtzionamendu-printzipioa honakoa da. Sarrerak deiaren egitura deskribatzen duen egitura zehatza duten fitxategiak biltzen ditu. Ondoren, aplikazioak egitura hori zutabe egokietan gordetzen dela ziurtatzen du. Etorkizunean, gordetako deiak harpidedunen trafiko-kontsumoari buruzko informazioa bistaratzeko erabiliko dira (komisioak, deiak, saldoaren historia).
Nahiko argi dago Cassandra zergatik aukeratu zuten: metrailadore bat bezala idazten du, erraz eskalagarria da eta akatsekiko tolerantzia.
Beraz, hau da esperientziak eman diguna
Bai, huts egin duen nodo bat ez da tragedia. Hau da Cassandraren erru-tolerantziaren funtsa. Baina nodo bat bizirik egon daiteke eta, aldi berean, errendimenduan sufritzen has daiteke. Ikusten denez, horrek berehala eragiten du kluster osoaren errendimenduan.
Cassandrak ez zaitu babestuko Oraclek bere murrizketekin salbatu zaituen tokian. Eta aplikazioaren egileak aldez aurretik ulertu ez bazuen, Cassandrarentzat iritsi zen bikoitza ez da jatorrizkoa baino okerragoa. Behin iritsita, sartuko dugu.
IBk ez zuen oso gustuko Cassandra librea kutxatik kanpo: Ez dago erabiltzaileen ekintzen erregistrorik, ez eskubideen bereizketarik. Deiei buruzko informazioa datu pertsonaltzat hartzen da, hau da, edozein modutan eskatzeko/aldatzeko saiakera guztiak erregistratu behar dira gero auditoretza egiteko aukerarekin. Gainera, erabiltzaile ezberdinentzako eskubideak maila ezberdinetan bereizteko beharraz jabetu behar duzu. Funtzio-ingeniari soil bat eta gako-espazio osoa libreki ezaba dezaketen super administratzaile bat rol desberdinak, erantzukizunak eta gaitasun desberdinak dira. Sarbide-eskubideen bereizketa hori gabe, datuen balioa eta osotasuna berehala zalantzan jarriko dira EDOZEIN koherentzia-mailarekin baino azkarrago.
Ez dugu kontuan hartu deiek analisi serioak eta aldizkako laginketak eskatzen dituztela hainbat baldintzatarako. Aukeratutako erregistroak ezabatu eta berridatzi behar direnez gero (zereginaren zati gisa, datuak eguneratzeko prozesua onartu behar dugu hasiera batean datuak gure begizta gaizki sartzen zirenean), Cassandra ez da gure laguna hemen. Cassandra txerritxo bat bezalakoa da - gauzak jartzea komeni da, baina ezin duzu zenbatu.
Arazo bat izan dugu datuak proba guneetara transferitzeko (5 nodo proban versus 20 prom). Kasu honetan, zabortegia ezin da erabili.
Cassandra-ri idazten duen aplikazio baten datu-eskema eguneratzeko arazoa. Atzera egiteak hilarri asko sortuko ditu, eta horrek produktibitate-galerak eragin ditzake ezusteko moduetan.. Cassandra grabatzeko optimizatuta dago, eta ez du asko pentsatzen idatzi baino lehen. Dauden datuak dituen edozein eragiketa ere grabaketa bat da. Hau da, beharrezkoa ez dena ezabatuz gero, are disko gehiago sortuko ditugu, eta horietako batzuk soilik hilarriekin markatuko dira.
Txertatzean denbora-muga. Cassandra ederra da grabazioan, baina batzuetan, sarrerako fluxuak nabarmen harritu dezake. Hau gertatzen da aplikazioa arrazoiren batengatik txertatu ezin diren hainbat erregistroren inguruan ibiltzen hasten denean. Eta benetako DBA bat beharko dugu, gc.log, sistema eta arazketa erregistroak kontrolatuko dituena kontsulta moteletarako, trinkotze-neurriak zain dauden.
Hainbat datu-zentro kluster batean. Nondik irakurri eta non idatzi?
Irakurketa eta idazketan banatuta agian? Eta hala bada, DC bat egon beharko litzateke idazteko edo irakurtzeko aplikaziotik gertuago? Eta ez al dugu benetako garun zatitu batekin amaituko koherentzia maila okerra aukeratzen badugu? Galdera asko daude, ezarpen ezezagun asko, benetan moldatu nahi dituzun aukerak.
Nola erabaki genuen
Nodoa hondora ez dadin, SWAP desgaitu egin da. Eta orain, memoria falta bada, nodoak behera egin beharko luke eta ez du gc pausa handiak sortu.
Beraz, jada ez gara datu-baseko logikan oinarritzen. Aplikazioen garatzaileak beren burua birziklatzen ari dira eta aktiboki neurriak hartzen hasi dira beren kodean. Datuen biltegiratze eta prozesamenduaren bereizketa garbi aproposa.
DataStax-en laguntza erosi dugu. Cassandra kutxaren garapena jada eten egin da (azken konpromisoa 2018ko otsailean izan zen). Aldi berean, Datastax-ek zerbitzu bikaina eta lehendik dauden IP soluzioetarako soluzio aldatu eta egokitu ugari eskaintzen ditu.
Kontuan izan nahi dut Cassandra ez dela oso erosoa hautapen kontsultak egiteko. Jakina, CQL aurrerapauso handia da erabiltzaileentzat (Trift-ekin alderatuta). Baina horrelako elkartze erosoetara ohituta dauden sail osoak badituzu, edozein eremuren arabera iragazteko doako iragazketa eta kontsultak optimizatzeko gaitasunak badituzu, eta sail hauek kexak eta istripuak konpontzeko lanean ari badira, Cassandraren konponbidea etsai eta ergela dirudi. Eta gure lankideek laginak nola egin behar zituzten erabakitzen hasi ginen.
Bi aukera kontuan hartu ditugu.Lehenengo aukeran, C*n ez ezik, artxibatutako Oracle datu-basean ere idazten ditugu deiak. Bakarrik, C* ez bezala, datu-base honek uneko hilabeteko deiak bakarrik gordetzen ditu (behar adina deiak gordetzeko sakonera birkargatzeko kasuetarako). Hemen berehala ikusi genuen arazo hau: sinkronoki idazten badugu, txertatze azkarrarekin lotutako C*-ren abantaila guztiak galduko ditugu; modu asinkronoan idazten badugu, ez dago bermatzen beharrezko dei guztiak Oraclera sartuko direnik. Bazen abantaila bat, baina handia: funtzionamendurako PL/SQL Garatzaile ezagun bera geratzen da, hau da, ia "Fatxada" eredua inplementatzen dugu. Aukera alternatibo bat. C*-tik deiak deskargatzen dituen mekanismo bat inplementatzen dugu, Oracle-n dagozkien tauletatik aberasteko datu batzuk atera, sortzen diren laginak batzen ditu eta emaitza ematen digu, gero nolabait erabiltzen dugun (atzera egin, errepikatu, aztertu, miresteko). Alde txarrak: prozesua nahiko urrats anitzekoa da, eta gainera, ez dago funtzionamenduko langileentzako interfazerik.
Azkenean, bigarren aukerarekin finkatu ginen. Apache Spark pote ezberdinetatik lagintzeko erabili zen. Mekanismoaren funtsa Java kodera murriztu da, zeinak, zehaztutako gakoak erabiliz (harpideduna, dei-denbora - ataleko teklak), C*-tik datuak ateratzen ditu, baita beste edozein datu-baseetatik aberasteko beharrezko datuak ere. Ondoren, memorian batzen ditu eta emaitza taulan bistaratzen du. Txinpartaren gainean sare-aurpegia marraztu genuen eta nahiko erabilgarria atera zen.
Proba industrialaren datuak eguneratzeko arazoa ebaztean, berriro ere hainbat irtenbide hartu ditugu kontuan. Biak Sstloader bidez transferitzea eta proba eremuko klusterra bi zatitan banatzeko aukera, bakoitza txandaka sustapeneko kluster berean dagokiola, eta horrela elikatzen da. Proba eguneratzean, horiek trukatzea aurreikusi zen: proban lan egin zuen zatia garbitu eta produkzioan sartzen da, eta bestea datuekin bereizita lantzen hasten da. Hala ere, berriro pentsatu ondoren, arrazionalki baloratu genuen transferitzea merezi zuten datuak, eta konturatu ginen deiak beraiek probak egiteko entitate koherenteak direla, behar izanez gero azkar sortzen direnak, eta sustapen-datu multzoa dela transferentziarako baliorik ez duena. proba. Hainbat biltegiratze-objektu daude mugitzea merezi dutenak, baina hauek literalki mahai pare bat dira, eta ez oso astunak. Horregatik guk irtenbide gisa, Spark berriro erreskatatu zen, zeinaren laguntzarekin idatzi eta aktiboki erabiltzen hasi ginen taulen artean datuak transferitzeko script bat, prom-test.
Gure egungo hedatze-politikak atzera egin gabe lan egiteko aukera ematen digu. Promozioaren aurretik, derrigorrezko proba bat dago, non akats bat hain garestia ez den. Porrotaren kasuan, beti jar dezakezu kasu-espazioa eta hasieratik eskema osoa jaurti dezakezu.
Cassandraren etengabeko erabilgarritasuna bermatzeko, dba behar duzu eta ez bera bakarrik. Aplikazioarekin lan egiten duen orok ulertu behar du non eta nola begiratu egungo egoera eta nola diagnostikatu arazoak garaiz. Horretarako, aktiboki erabiltzen dugu DataStax OpsCenter (lan-kargen administrazioa eta jarraipena), Cassandra Driver sistemaren neurketak (C*-ra idazteko denbora-muga kopurua, C*-tik irakurtzeko denbora-muga kopurua, latentzia maximoa, etab.), funtzionamendua kontrolatu. aplikazioaren beraren, Cassandrarekin lanean.
Aurreko galderari buruz pentsatu genuenean, gure arrisku nagusia non egon zitekeen konturatu ginen. Datuak bistaratzeko inprimakiak dira, hainbat kontsulta independentetako datuak biltegiratzera bistaratzen dituztenak. Horrela nahiko informazio koherentea lor dezakegu. Baina arazo hau bezain garrantzitsua litzateke datu-zentro bakarrarekin lan egingo bagenu. Beraz, hemen arrazoizkoena, noski, hirugarrenen aplikazio batean datuak irakurtzeko sorta funtzio bat sortzea da, eta horrek datuak denbora-tarte bakarrean jasotzen direla bermatuko du. Errendimenduari dagokionez irakurketa eta idazketa zatiketari dagokionez, hemen DC-en arteko konexioa galduz gero, elkarren artean guztiz inkoherenteak diren bi klusterrekin bukatzeko arriskua gelditu zaigu.
Ondorioz, oraingoz koherentzia mailan gelditu da EACH_QUORUM idazteko, irakurtzeko - LOCAL_QUORUM
Inpresio eta ondorio laburrak
Sortutako irtenbidea euskarri operatiboaren eta garapen gehiagorako aurreikuspenen ikuspuntutik ebaluatzeko, garapen hori beste nondik nora aplikatu zitekeen pentsatzea erabaki genuen.
Lehenik eta behin, "Ordaindu komeni denean" bezalako programen datuen puntuazioa (informazioa C*-n kargatzen dugu, Spark script-en bidez kalkulatzen dugu), erreklamazioak eremuka batutatuz, rolak gorde eta erabiltzaileen sarbide-eskubideak kalkulatzen ditugu rolaren arabera. matrizea.
Ikusten denez, errepertorioa zabala eta askotarikoa da. Eta NoSQL-ren aldeko/aurkarien kanpamendua aukeratzen badugu, jarraitzaileekin bat egingo dugu, gure abantailak jaso baikenituen eta zehazki espero genuen lekuan.
Kutxatik kanpo dagoen Cassandra aukerak denbora errealean eskalatze horizontala ahalbidetzen du, sistemako datuak handitzearen arazoa erabat minez konponduz. Dei-agregatuak kalkulatzeko oso karga handiko mekanismo bat zirkuitu bereizi batera eraman ahal izan genuen, eta aplikazioaren eskema eta logika ere bereizi genituen, datu-basean bertan lan pertsonalizatuak eta objektuak idazteko praktika txarra kenduz. Aukeratu eta konfiguratzeko aukera izan genuen, bizkortzeko, zein DCtan egingo ditugun kalkuluak eta zeintzuetan erregistratuko ditugun datuak, nodo indibidualen eta DC osoaren hutsegiteen aurka ziurtatu genuen.
Gure arkitektura proiektu berriei aplikatuz, eta dagoeneko esperientzia pixka bat izanda, lehen deskribatutako ñabardurak berehala hartu nahi nituzke kontuan, eta akats batzuk saihestu, hasieran saihestu ezin ziren ertz zorrotz batzuk leundu.
Esate baterako, egin Cassandraren eguneratzeen jarraipena garaizizan ere, lortu genituen arazo dezente ezagutzen eta konponduta zeuden.
Ez jarri datu-basea bera eta Spark nodo berdinetan (edo zorrozki zatitu baimendutako baliabideen erabilera kopuruaren arabera), Sparkek espero baino OP gehiago jan dezakeelako eta 1 zenbakiko arazoa azkar lortuko dugu gure zerrendatik.
Proiektuaren proba fasean jarraipen- eta operazio-gaitasuna hobetzea. Hasieran, gure irtenbidearen kontsumitzaile potentzial guztiak ahalik eta gehien kontuan hartu, horren araberakoa izango baita azken finean datu-basearen egitura.
Biratu ondoriozko zirkuitua hainbat aldiz optimizazio posible izateko. Hautatu zein eremu serializatu daitezkeen. Ulertzea zer taula gehigarri egin behar ditugun ondoen eta hobekien kontuan hartzeko, eta ondoren eskatutako informazioa eman (adibidez, datu berdinak taula ezberdinetan gorde ditzakegula suposatuz, matxura desberdinak kontuan hartuta. irizpide ezberdinetan, PUZaren denbora nabarmen aurreztu dezakegu irakurketa-eskaeretarako).
Ez da txarra Eman berehala TTL eransteko eta zaharkitutako datuak garbitzeko.
Cassandraren datuak deskargatzean Aplikazio-logikak FETCH printzipioaren arabera funtzionatu behar du, errenkada guztiak memorian kargatu ez daitezen aldi berean, loteka hauta daitezen.
Gomendagarria da proiektua deskribatutako soluziora transferitu aurretik egiaztatu sistemaren akatsen tolerantzia kraskadura proba batzuk eginez, hala nola, datu-zentro batean datuak galtzea, kaltetutako datuak epe jakin batean leheneratzea, datu-zentroen arteko sarea uztea. Proba horiei esker, proposatutako arkitekturaren alde onak eta txarrak ebaluatzeaz gain, beroketa praktika onak ere emango dizkiete burutzen ari diren ingeniariei, eta lortutako trebetasuna ez da soberan egongo, ekoizpenean sistemaren akatsak errepikatzen badira.
Informazio kritikoarekin lan egiten badugu (adibidez, fakturaziorako datuak, harpidedunen zorraren kalkulua), orduan DBMSaren ezaugarriengatik sortutako arriskuak murrizten dituzten tresnei ere arreta jartzea merezi du. Adibidez, erabili nodesync utilitatea (Datastax), bere erabilerarako estrategia optimoa garatu ondoren koherentziaren mesedetan, ez sortu Cassandraren gehiegizko kargarik eta epe jakin batean taula jakin batzuetarako soilik erabili.
Zer gertatzen zaio Cassandreri sei hilabete bizitzaren ondoren? Oro har, ez dago konpondu gabeko arazorik. Ez dugu istripu larririk edo datu-galerarik ere onartu. Bai, aurretik sortu gabeko arazo batzuk konpentsatzea pentsatu behar izan genuen, baina azkenean horrek ez zuen asko lausotu gure konponbide arkitektonikoa. Zerbait berria probatu nahi baduzu eta beldurrik ez baduzu, eta, aldi berean, gehiegi etsita egon nahi ez baduzu, prest egon ezer dohainik ez dagoelako. Ulertu, dokumentazioan murgildu eta zure banakako rastrilloa muntatu beharko duzu ondarearen soluzio zaharrean baino gehiago, eta inolako teoriarik ez dizu aldez aurretik esango zein rake dagoen zure zain.
Iturria: www.habr.com