{"id":37585,"date":"2019-10-31T22:18:27","date_gmt":"2019-10-31T19:18:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql\/"},"modified":"2019-10-31T22:18:27","modified_gmt":"2019-10-31T19:18:27","slug":"kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","title":{"rendered":"Si t\u2019i shoh\u00ebsh Cassandra-s n\u00eb sy pa humbur t\u00eb dh\u00ebnat, stabilitetin dhe besimin te NoSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\n<\/p>\n

Thuhet se n\u00eb jet\u00eb \u00e7do gj\u00eb duhet provuar t\u00eb pakt\u00ebn nj\u00eb her\u00eb. Dhe n\u00ebse jeni m\u00ebsuar t\u00eb punoni me DB-relacionale, at\u00ebher\u00eb \u00ebsht\u00eb e rekomandueshme t\u00eb njihet praktikisht me NoSQL, fillimisht p\u00ebr zhvillim t\u00eb p\u00ebrgjithsh\u00ebm. Tani, p\u00ebr shkak t\u00eb zhvillimit t\u00eb shpejt\u00eb t\u00eb teknologjis\u00eb, ka shum\u00eb opinione t\u00eb kund\u00ebrta dhe debate t\u00eb nxehta n\u00eb lidhje me k\u00ebt\u00eb tem\u00eb, t\u00eb cilat ve\u00e7an\u00ebrisht nxjerrin n\u00eb pah interesin.
\nN\u00ebse thellohesh n\u00eb thelbin e t\u00eb gjitha k\u00ebtyre debateve, mund t\u00eb shoh\u00ebsh se ato lindin nga nj\u00eb qasje e gabuar. Ata q\u00eb p\u00ebrdorin bazat e t\u00eb dh\u00ebnave NoSQL atje ku jan\u00eb t\u00eb nevojshme jan\u00eb t\u00eb k\u00ebnaqur dhe p\u00ebrfitojn\u00eb nga ky zgjidhje. Nd\u00ebrsa eksperimentuesit, q\u00eb besojn\u00eb n\u00eb k\u00ebt\u00eb teknologji si nj\u00eb ila\u00e7 p\u00ebr atje ku ajo nuk aplikohet asnj\u00ebher\u00eb, p\u00ebrjetojn\u00eb zhg\u00ebnjim, duke humbur p\u00ebrfitimet e forta t\u00eb bazave t\u00eb t\u00eb dh\u00ebnave relacionale pa fituar ndonj\u00eb p\u00ebrfitim t\u00eb r\u00ebnd\u00ebsish\u00ebm.<\/p>\n

<\/p>\n

Do t\u00eb flas p\u00ebr p\u00ebrvoj\u00ebn ton\u00eb n\u00eb zbatimin e nj\u00eb zgjidhjeje, t\u00eb bazuar n\u00eb DB-n\u00eb Cassandra: me \u00e7far\u00eb jemi p\u00ebrballur, si kemi dal\u00eb nga situatat e v\u00ebshtira, n\u00ebse arrit\u00ebm t\u00eb p\u00ebrfitonim nga p\u00ebrdorimi i NoSQL dhe ku duhej t\u00eb investonim p\u00ebrpjekje\/sht\u00ebpi.
\nDetyra fillestare \u00ebsht\u00eb nd\u00ebrtimi i nj\u00eb sistemi p\u00ebr regjistrimin e thirrjeve n\u00eb nj\u00eb ruajtje t\u00eb caktuar.<\/p>\n

<\/p>\n

Parimi i funksionimit t\u00eb sistemit \u00ebsht\u00eb si n\u00eb vijim. N\u00eb hyrje vijn\u00eb skedar\u00eb me nj\u00eb struktur\u00eb t\u00eb caktuar, q\u00eb p\u00ebrshkruan struktur\u00ebn e thirrjes. Pastaj aplikacioni siguron ruajtjen e k\u00ebsaj strukture n\u00eb kolonat p\u00ebrkat\u00ebse. M\u00eb pas, thirrjet e ruajtura p\u00ebrdoren \u2013 p\u00ebr t\u00eb treguar informacionin mbi konsumimin e trafikut p\u00ebr abonent\u00ebt (l\u00ebvizjet, thirrjet, historia e bilancit).<\/p>\n

\n\"Si<\/p>\n

Pse zgjodh\u00ebm Cassandra \u00ebsht\u00eb e qart\u00eb \u2013 ajo regjistron si nj\u00eb mitraloz, \u00ebsht\u00eb leht\u00eb e shkall\u00ebzueshme, e q\u00ebndrueshme ndaj d\u00ebshtimeve.<\/p>\n

\n<\/a><\/noindex><\/p>\n

Pra, ja \u00e7far\u00eb na dhuroi p\u00ebrvoja.<\/h2>\n

<\/p>\n

Po, nj\u00eb nod i r\u00ebn\u00eb nuk \u00ebsht\u00eb nj\u00eb tragjedi. Kjo \u00ebsht\u00eb thelbi i q\u00ebndrueshm\u00ebris\u00eb s\u00eb Cassandra-s. Por nodi mund t\u00eb jet\u00eb aktiv dhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb t\u00eb filloj\u00eb t\u00eb bie n\u00eb performanc\u00eb.<\/b>. Si\u00e7 u zbulua, kjo ndikon menj\u00ebher\u00eb n\u00eb performanc\u00ebn e t\u00ebr\u00eb klasterit.<\/p>\n

<\/p>\n

Cassandra nuk do t\u00eb t\u00eb ndihmoj\u00eb atje ku Oracle shp\u00ebton me kufizimet e tij.<\/b>. Dhe n\u00ebse autori i aplikacionit nuk e kuptoi k\u00ebt\u00eb paraprakisht, at\u00ebher\u00eb dyfishimi i ardhur p\u00ebr Cassandra-n \u00ebsht\u00eb nj\u00eblloj i mir\u00eb sa origjinali. N\u00ebse ka ardhur, ne e fusim.<\/p>\n

<\/p>\n

Cassandra falas \"nga kutia\" nuk i p\u00eblqeu aspak shumic\u00ebs s\u00eb informacionit p\u00ebr t\u00eb dh\u00ebna: nuk ka regjistrim t\u00eb veprimeve t\u00eb p\u00ebrdoruesve, as ndarjen e t\u00eb drejtave gjithashtu.<\/b>Informacioni n\u00eb lidhje me thirrjet i p\u00ebrket t\u00eb dh\u00ebnave personale, duke n\u00ebnkuptuar se \u00e7do p\u00ebrpjekje p\u00ebr ta k\u00ebrkuar\/ndryshuar at\u00eb duhet t\u00eb regjistrohet me mund\u00ebsin\u00eb e auditimit t\u00eb m\u00ebvonsh\u00ebm. Po ashtu, duhet t\u00eb kuptohet nevoja p\u00ebr t\u00eb ndar\u00eb t\u00eb drejtat n\u00eb nivele t\u00eb ndryshme p\u00ebr p\u00ebrdorues t\u00eb ndrysh\u00ebm. Nj\u00eb inxhinier i zakonsh\u00ebm i operimit dhe nj\u00eb superadmin, i cili mund t\u00eb fshij\u00eb gjith\u00e7ka n\u00eb keyspace \u2013 jan\u00eb role t\u00eb ndryshme, me p\u00ebrgjegj\u00ebsi dhe kompetenca t\u00eb ndryshme. Pa nj\u00eb ndarje t\u00eb till\u00eb t\u00eb t\u00eb drejtave t\u00eb aksesit, vlera dhe integriteti i t\u00eb dh\u00ebnave menj\u00ebher\u00eb do t\u00eb vihet n\u00eb dyshim m\u00eb shpejt se n\u00eb nivelin e q\u00ebndrueshm\u00ebris\u00eb ANY. <\/p>\n

<\/p>\n

Nuk e kemi marr\u00eb parasysh se p\u00ebr thirrjet k\u00ebrkohet nj\u00eb analiz\u00eb serioze, si dhe mostra t\u00eb p\u00ebrkohshme sipas kushtesh t\u00eb ndryshme. Duke pasur parasysh se regjistrimet e zgjedhura pastaj mendohet t\u00eb fshihen dhe t\u00eb rivendosen (n\u00eb kuad\u00ebr t\u00eb detyr\u00ebs duhet t\u00eb mbajm\u00eb procesin e aktualizimit t\u00eb t\u00eb dh\u00ebnave p\u00ebr t\u00eb dh\u00ebnat q\u00eb fillimisht na jan\u00eb d\u00ebrguar gabimisht), Cassandra k\u00ebtu nuk na ndihmon. Cassandra, si nj\u00eb kasafort\u00eb \u2013 \u00ebsht\u00eb e leht\u00eb t\u00eb vendos\u00ebsh gj\u00ebra atje, por nuk do t\u00eb jesh n\u00eb gjendje t\u00eb b\u00ebsh llogari.<\/b><\/p>\n

<\/p>\n

Jemi ballafaquar me problemin e transferimit t\u00eb t\u00eb dh\u00ebnave n\u00eb zonat testuese.<\/b> (5 nod n\u00eb test n\u00eb krahasim me 20 n\u00eb prodhim). N\u00eb k\u00ebt\u00eb rast, nuk do t\u00eb mund t\u00eb p\u00ebrdorim dump-in.<\/p>\n

<\/p>\n

Problemi i p\u00ebrdit\u00ebsimeve t\u00eb skem\u00ebs s\u00eb t\u00eb dh\u00ebnave t\u00eb aplikacionit q\u00eb shkruan n\u00eb Cassandra. Rikthimi do t\u00eb sjell\u00eb nj\u00eb num\u00ebr t\u00eb madh varresh, q\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb paparashikueshme mund t\u00eb na ulin performanc\u00ebn.<\/b>Cassandra \u00ebsht\u00eb optimizuar p\u00ebr shkrim, dhe para se t\u00eb shkruaj\u00eb, shum\u00eb nuk mendon. \u00c7do operacion me t\u00eb dh\u00ebna ekzistuese atje \u00ebsht\u00eb gjithashtu nj\u00eb shkrim. Dometh\u00ebn\u00eb, duke fshir\u00eb t\u00eb tep\u00ebrta, ne thjesht do t\u00eb krijojm\u00eb m\u00eb shum\u00eb shkrime, dhe vet\u00ebm nj\u00eb pjes\u00eb prej tyre do t\u00eb sh\u00ebnohet si varre.<\/p>\n

<\/p>\n

Koh\u00ebt e pritjes gjat\u00eb hyrjes. Cassandra \u00ebsht\u00eb perfekte p\u00ebr shkrime, por ndonj\u00ebher\u00eb fluksi i hyr\u00ebs mund ta shqet\u00ebsoj\u00eb at\u00eb ndjesh\u00ebm.<\/b>Kjo ndodh kur aplikacioni fillon t\u00eb ruaj\u00eb disa regjistrime n\u00eb nj\u00eb rreth q\u00eb nuk mund t\u00eb hyn\u00eb p\u00ebr ndonj\u00eb arsye. Dhe na nevojitet nj\u00eb DBA i v\u00ebrtet\u00eb, q\u00eb do t\u00eb monitoroj\u00eb gc.log, log-et e sistemit dhe debug p\u00ebr query t\u00eb ngadalta, metrikat p\u00ebr kompresimin e pritur.\n<\/p>\n

<\/p>\n

Disa qendra t\u00eb t\u00eb dh\u00ebnave n\u00eb klaster. Nga ku t\u00eb lexojm\u00eb dhe ku t\u00eb shkruajm\u00eb?<\/b>
\nA \u00ebsht\u00eb e mundur t\u00eb ndajm\u00eb mes leximit dhe shkrimit? Dhe n\u00ebse po, a duhet t\u00eb jet\u00eb DCB af\u00ebr aplikacionit p\u00ebr shkrim apo p\u00ebr lexim? A do t\u00eb kemi nj\u00eb v\u00ebrtet\u00eb \"split brain\" n\u00ebse zgjedhim gabim nivelin e koherenc\u00ebs? Ka shum\u00eb pyetje, shum\u00eb parametra t\u00eb panjohur, mund\u00ebsi q\u00eb do t\u00eb d\u00ebshironim t'i eksploronim.\n<\/p>\n

<\/p>\n

Si e zgjidh\u00ebm<\/h2>\n

<\/p>\n

P\u00ebr t\u00eb mos r\u00ebn\u00eb nodi, e \u00e7aktivizuam SWAP<\/b>. Tani, kur ka munges\u00eb t\u00eb memories, nodi duhet t\u00eb shkoj\u00eb posht\u00eb, e jo t\u00eb prodhoj\u00eb bllokime t\u00eb m\u00ebdha GC.<\/p>\n

<\/p>\n

Pra, tashm\u00eb nuk besojm\u00eb m\u00eb n\u00eb logjik\u00ebn e DB. Zhvilluesit e aplikacionit po e rishikojn\u00eb dhe fillojn\u00eb t\u00eb mbrohen aktivisht n\u00eb kodin e tyre.<\/b> Ndarje perfekte e qart\u00eb mes ruajtjes dhe p\u00ebrpunimit t\u00eb t\u00eb dh\u00ebnave.<\/p>\n

<\/p>\n

Kemi bler\u00eb mb\u00ebshtetje nga DataStax.<\/b> Kassandran kutis\u00eb ka ndaluar s\u00eb zhvilluari (komitimi i fundit n\u00eb shkurt 2018). Megjithat\u00eb, Datastax ofron nj\u00eb sh\u00ebrbim t\u00eb shk\u00eblqyer dhe shum\u00eb zgjidhje t\u00eb p\u00ebrmir\u00ebsuara dhe t\u00eb p\u00ebrshtatura sipas sistemeve ekzistuese.<\/p>\n

<\/p>\n

Dua gjithashtu t\u00eb theksoj se Kassandra nuk \u00ebsht\u00eb shum\u00eb e p\u00ebrshtatshme p\u00ebr k\u00ebrkesat e seleksionimit. Natyrisht, CQL \u00ebsht\u00eb nj\u00eb hap i madh drejt p\u00ebrdoruesve (krahasuar me Thrift). Por, n\u00ebse keni departamente t\u00eb t\u00ebra q\u00eb jan\u00eb m\u00ebsuar me bashkime t\u00eb tilla t\u00eb p\u00ebrshtatshme, filtrime t\u00eb lira sipas \u00e7do fushe dhe mund\u00ebsi optimizimi t\u00eb k\u00ebrkesave, at\u00ebher\u00eb zgjidhja n\u00eb Kassand\u00ebr duket p\u00ebr ta si nj\u00eb armik i paduruesh\u00ebm dhe absurd. Dhe ne filluam t\u00eb zgjidhim pyetjen se si mund t'i b\u00ebjm\u00eb seleksionet koleg\u00ebve tan\u00eb. <\/p>\n

<\/p>\n

U shqyrtuar dy variante. N\u00eb variantin e par\u00eb, shkruajm\u00eb thirrje jo vet\u00ebm n\u00eb C*, por edhe n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave arkivore Oracle. Megjithat\u00eb, ndryshe nga C*, n\u00eb k\u00ebt\u00eb BDB ruhen thirrjet vet\u00ebm p\u00ebr muajin aktual (thell\u00ebsia e mjaftueshme e ruajtjes s\u00eb thirrjeve p\u00ebr rastet e ri tarifimit). K\u00ebtu u shfaq problemi tjet\u00ebr: n\u00ebse shkruajm\u00eb n\u00eb m\u00ebnyr\u00eb sinkrone, ne humbim t\u00eb gjitha p\u00ebrpar\u00ebsit\u00eb e C*, lidhur me insertimin e shpejt\u00eb; n\u00ebse asinkrone \u2013 nuk ka garantim q\u00eb t\u00eb gjitha thirrjet e nevojshme do t\u00eb p\u00ebrfshihen gjithsesi n\u00eb Oracle. Nj\u00eb p\u00ebrpar\u00ebsi e madhe ishte se p\u00ebr p\u00ebrdorim mbetet e nj\u00ebjta PL\/SQL Developer, pra, praktikisht realizojm\u00eb modelin \"Fasad\u00eb\". Variante alternative. Realizojm\u00eb nj\u00eb mekaniz\u00ebm q\u00eb nxjerr thirrjet nga C*, merr disa t\u00eb dh\u00ebna p\u00ebr pasurimin nga tabelat p\u00ebrkat\u00ebse n\u00eb Oracle, bashkon seleksionet e marra dhe na jep rezultatin e marr\u00eb, q\u00eb pastaj ne e p\u00ebrdorim ndonj\u00ebher\u00eb (e kthejm\u00eb, e rip\u00ebrs\u00ebrisim, e analizojm\u00eb, e admirojm\u00eb). Disavantazhet: procesi b\u00ebhet mjaft shum\u00eb-hap\u00ebsh, dhe p\u00ebr m\u00eb tep\u00ebr, nuk ka nj\u00eb nd\u00ebrlidhje p\u00ebr punonj\u00ebsit e operimit.<\/p>\n

<\/p>\n

N\u00eb p\u00ebrfundim, u ndal\u00ebm n\u00eb variantin e dyt\u00eb. P\u00ebr seleksionet nga banka t\u00eb ndryshme p\u00ebrdor\u00ebm Apache Spark.<\/b> Esenca e mekanizmit u reduktua n\u00eb nj\u00eb kod Java, i cili sipas \u00e7el\u00ebsave t\u00eb caktuar (abonenti, koha e thirrjes \u2013 \u00e7el\u00ebsat e seksionit) nxjerr t\u00eb dh\u00ebna nga C*, si dhe t\u00eb dh\u00ebnat e nevojshme p\u00ebr pasurimin nga \u00e7do BDB tjet\u00ebr. Pas k\u00ebsaj, i bashkon ato n\u00eb kujtes\u00ebn e tij dhe jep rezultatin n\u00eb tabel\u00ebn p\u00ebrfundimtare. P\u00ebr Spark, krijuam nj\u00eb nd\u00ebrfaqe web dhe rezultoi t\u00eb ishte plot\u00ebsisht e p\u00ebrdorshme.<\/p>\n

\n\"Si<\/p>\n

N\u00eb trajtimin e \u00e7\u00ebshtjes s\u00eb azhurnimit t\u00eb t\u00eb dh\u00ebnave, ne s\u00ebrish shqyrtuam disa m\u00ebnyra zgjidhjeje. Si kalimi p\u00ebrmes Sstloader, ashtu dhe varianti me ndarjen e klasterit n\u00eb zon\u00ebn e testimit n\u00eb dy pjes\u00eb, ku secila her\u00eb hyn n\u00eb nj\u00eb klaster me at\u00eb t\u00eb prodhimit, duke u furnizuar n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb prej tij. Kur u planifikua azhurnimi i testit, ishte parashikuar t\u00eb k\u00ebmbenim vendet: ajo pjes\u00eb q\u00eb punonte n\u00eb test do t\u00eb pastronte dhe do t\u00eb hynte n\u00eb prodhim, nd\u00ebrsa tjetra fillonte t\u00eb punonte me t\u00eb dh\u00ebna ndaras. Megjithat\u00eb, duke e menduar p\u00ebrs\u00ebri, ne e vler\u00ebsuam m\u00eb racionalisht t\u00eb dh\u00ebnat q\u00eb duhet t\u00eb transferohen dhe kuptuam se vet\u00eb thirrjet jan\u00eb nj\u00eb entitet jo konsistent p\u00ebr testet, q\u00eb krijohet shpejt n\u00eb rast nevoje, dhe pik\u00ebrisht grupi i t\u00eb dh\u00ebnave t\u00eb prodhimit nuk ka vler\u00eb p\u00ebr transferim n\u00eb test. ka disa objekte-akumulator\u00eb q\u00eb duhet t\u00eb transferohen, por kjo \u00ebsht\u00eb p\u00ebr t\u00eb th\u00ebn\u00eb disa tabela, t\u00eb cilat nuk jan\u00eb shum\u00eb t\u00eb r\u00ebnda. Prandaj, ne si zgjidhje p\u00ebrs\u00ebri erdhi n\u00eb ndihm\u00eb Spark, me t\u00eb cilin ne shkruam dhe filluam t\u00eb p\u00ebrdorim aktivisht skriptin p\u00ebr transferimin e t\u00eb dh\u00ebnave midis tabelave prodhim-test.<\/b><\/p>\n

<\/p>\n

Politika jon\u00eb aktuale e deplojtimit na lejon t\u00eb punojm\u00eb pa rregullime.<\/b> Para prodhimit, ka nj\u00eb aplikuar obligativ n\u00eb test, ku gabimi nuk \u00ebsht\u00eb aq i kushtuesh\u00ebm. N\u00eb rast d\u00ebshtimi, gjithmon\u00eb mund t\u00eb fshijm\u00eb case-space dhe t\u00eb aplikojm\u00eb t\u00ebr\u00eb skem\u00ebn nga fillimi.<\/p>\n

<\/p>\n

P\u00ebr t\u00eb siguruar disponueshm\u00ebrin\u00eb e vazhdueshme t\u00eb Cassandra-s, nevojitet nj\u00eb DBA dhe jo vet\u00ebm ai. T\u00eb gjith\u00eb ata q\u00eb punojn\u00eb me aplikacionin duhet t\u00eb kuptojn\u00eb se ku dhe si t\u00eb shikojn\u00eb situat\u00ebn aktuale dhe si t\u00eb diagnostikojn\u00eb problemet n\u00eb koh\u00eb.<\/b> P\u00ebr k\u00ebt\u00eb ne p\u00ebrdorim aktivisht DataStax OpsCenter (Administrimi dhe monitorimi i ngarkesave t\u00eb pun\u00ebs), metrikat sistemike t\u00eb Cassandra Driver (numri i koh\u00ebve t\u00eb pritura p\u00ebr shkrim n\u00eb C*, numri i koh\u00ebve t\u00eb pritura p\u00ebr lexim nga C*, latenca maksimale etj.), monitorojm\u00eb pun\u00ebn e vet\u00eb aplikacionit, q\u00eb punon me Cassandra.\n<\/p>\n

<\/p>\n

Kur k\u00ebrkuam p\u00ebrgjigje p\u00ebr pyetjen e m\u00ebparshme, e kuptuam se ku mund t\u00eb fshihet rreziku kryesor. Ky \u00ebsht\u00eb formati i shfaqjes s\u00eb t\u00eb dh\u00ebnave, i cili nxjerr t\u00eb dh\u00ebna nga disa k\u00ebrkesa t\u00eb pavarura nj\u00ebra nga tjetra n\u00eb depo. K\u00ebshtu mund t\u00eb marrim informacione mjaft t\u00eb papajtueshme. Por kjo problematik\u00eb do t\u00eb ishte e pranishme edhe n\u00eb rastin n\u00ebse do t\u00eb punonim vet\u00ebm me nj\u00eb qend\u00ebr t\u00eb dh\u00ebnash. Prandaj, e vetmja zgjidhje logjike k\u00ebtu \u00ebsht\u00eb t\u00eb krijojm\u00eb nj\u00eb funksion grupor p\u00ebr leximin e t\u00eb dh\u00ebnave n\u00eb nj\u00eb aplikacion t\u00eb jasht\u00ebm, i cili do t\u00eb garantoj\u00eb marrjen e t\u00eb dh\u00ebnave n\u00eb nj\u00eb periudh\u00eb t\u00eb vetme kohore. Sa i p\u00ebrket ndarjes s\u00eb leximit dhe shkruajtjes n\u00eb planin e performanc\u00ebs, k\u00ebtu u ndal\u00ebm nga rreziku se, n\u00eb rast t\u00eb humbjes s\u00eb lidhjes midis QDC-ve, mund t\u00eb marrim dy klaster\u00eb krejt\u00ebsisht t\u00eb papajtuesh\u00ebm me nj\u00ebri-tjetrin.<\/p>\n

<\/p>\n

Si p\u00ebrfundim, deri n\u00eb k\u00ebt\u00eb moment u ndaluam n\u00eb nivelin e pajtueshm\u00ebris\u00eb p\u00ebr shkruaj EACH_QUORUM, p\u00ebr leximin \u2013 LOCAL_QUORUM<\/b><\/p>\n

<\/p>\n

P\u00ebrmbledhje dhe p\u00ebrfundime t\u00eb shkurtra<\/h2>\n

<\/p>\n

P\u00ebr t\u00eb vler\u00ebsuar zgjidhjen e arritur nga pik\u00ebpamja e mb\u00ebshtetjes funksionale dhe perspektivave p\u00ebr zhvillimin e m\u00ebtejsh\u00ebm, vendos\u00ebm t\u00eb mendojm\u00eb se ku mund t\u00eb aplikojm\u00eb nj\u00eb zhvillim t\u00eb till\u00eb.<\/p>\n

<\/p>\n

N\u00ebse flasim shpejt, ndihma e t\u00eb dh\u00ebnave p\u00ebr programe si \"Paguaj, kur t\u00eb d\u00ebshirosh\" (ngarko informacionin n\u00eb S*, llogaritje n\u00eb skenar\u00ebt Spark), llogaria e k\u00ebrkesave me agregimin sipas drejtimeve, ruajtja e roleve dhe llogaritja sipas matric\u00ebs s\u00eb rolit p\u00ebr t\u00eb drejtat e qasjes s\u00eb p\u00ebrdoruesve. <\/p>\n

<\/p>\n

Si\u00e7 e shohim, repertori \u00ebsht\u00eb i gjer\u00eb dhe i larmish\u00ebm. Dhe n\u00ebse duhet t\u00eb zgjedhim an\u00ebn e mb\u00ebshtet\u00ebsve\/kund\u00ebrshtar\u00ebve t\u00eb NoSQL, ne do t\u00eb anojm\u00eb kah mb\u00ebshtet\u00ebsit, pasi kemi arritur p\u00ebrfitime, dhe pik\u00ebrisht aty ku e prisnim.<\/p>\n

<\/p>\n

Madje, varianti Cassandra nga kuti lejon t\u00eb b\u00ebhet shkall\u00ebzim horizontal n\u00eb koh\u00eb reale, duke zgjidhur pa dhimbje \u00e7\u00ebshtjen e rritjes s\u00eb t\u00eb dh\u00ebnave n\u00eb sistem. Arrit\u00ebm t\u00eb ndajm\u00eb nj\u00eb mekaniz\u00ebm shum\u00eb me ngarkes\u00eb p\u00ebr llogaritjen e agregateve p\u00ebr thirrjet n\u00eb nj\u00eb kontur t\u00eb ve\u00e7ant\u00eb, si dhe t\u00eb ndajm\u00eb skem\u00ebn dhe logjik\u00ebn e aplikacionit, duke u liruar nga praktika e keqe e shkruarjes s\u00eb pun\u00ebve dhe objekteve t\u00eb personalizuara n\u00eb vet\u00eb DB. Kemi fituar mund\u00ebsin\u00eb t\u00eb zgjedhim dhe konfigurojm\u00eb, p\u00ebr shpejt\u00ebsi, n\u00eb cilat QDC do t\u00eb b\u00ebjm\u00eb llogaritjen dhe n\u00eb cilat do t\u00eb shkruajm\u00eb t\u00eb dh\u00ebnat, duke u mbrojtur ndaj r\u00ebnieve si t\u00eb nyjeve t\u00eb ve\u00e7anta, ashtu edhe n\u00eb p\u00ebrgjith\u00ebsi t\u00eb QDC.<\/p>\n

<\/p>\n

Duke p\u00ebrdorim arkitektur\u00ebn ton\u00eb p\u00ebr projektet e reja, dhe, duke pasur tashm\u00eb disa p\u00ebrvoj\u00eb, do t\u00eb doja q\u00eb menj\u00ebher\u00eb t\u00eb marrim parasysh nuancat e p\u00ebrmendura m\u00eb sip\u00ebr dhe t\u00eb shmangim disa gabime, duke zbutur disa k\u00ebndv\u00ebshtrime t\u00eb ashpra q\u00eb nuk arrit\u00ebm t'i evitojm\u00eb fillimisht.<\/p>\n

<\/p>\n

P\u00ebr shembull, t\u00eb monitorojm\u00eb n\u00eb koh\u00eb p\u00ebrdit\u00ebsimet e Cassandra-s<\/b>, sepse shum\u00eb nga problemet q\u00eb kemi pasur, ishin tashm\u00eb t\u00eb njohura dhe ishin rregulluar.<\/p>\n

<\/p>\n

T\u00eb mos vendosim si baz\u00ebn e t\u00eb dh\u00ebnave ashtu edhe Spark n\u00eb t\u00eb nj\u00ebjtat nodet.<\/b> (ose t\u00eb ndahen rrept\u00ebsisht sipas sasis\u00eb s\u00eb p\u00ebrdorimit t\u00eb lejuar t\u00eb burimeve), pasi Spark mund t\u00eb konsumoj\u00eb m\u00eb shum\u00eb RAM sesa e lejuar, dhe ne do t\u00eb kemi shpejt problemin num\u00ebr 1 nga lista jon\u00eb.<\/p>\n

<\/p>\n

T\u00eb zhvillojm\u00eb monitorimin dhe kompetenc\u00ebn e operimit edhe n\u00eb faz\u00ebn e testimit t\u00eb projektit. <\/b>Fillimisht t\u00eb kemi sa m\u00eb shum\u00eb parasysh t\u00eb gjith\u00eb konsumator\u00ebt e mundsh\u00ebm t\u00eb zgjidhjes son\u00eb<\/b>, sepse pik\u00ebrisht nga kjo do t\u00eb varet struktura e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave n\u00eb fund.<\/p>\n

<\/p>\n

T\u00eb rrokim disa her\u00eb diagramin e rezultuar p\u00ebr mund\u00ebsit\u00eb e optimizimit. T\u00eb p\u00ebrcaktojm\u00eb cilat fusha mund t\u00eb serializohen. T\u00eb kuptojm\u00eb cilat tabela t\u00eb tjera duhet t\u00eb krijojm\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb marrim informacionin e k\u00ebrkuar sa m\u00eb sakt\u00eb dhe optimalisht (p.sh., duke supozuar se t\u00eb dh\u00ebnat e nj\u00ebjta mund t\u00eb ruhen n\u00eb tabela t\u00eb ndryshme, duke marr\u00eb parasysh ndarjen e ndryshme sipas kritereve t\u00eb ndryshme, mund t\u00eb kursenim ndjesh\u00ebm koh\u00ebn e procesorit gjat\u00eb k\u00ebrkesave t\u00eb leximit).<\/p>\n

<\/p>\n

Nuk do t\u00eb ishte keq t\u00eb parashikohet menj\u00ebher\u00eb ndarja e TTL dhe pastrimi i t\u00eb dh\u00ebnave t\u00eb skaduara.<\/b><\/p>\n

<\/p>\n

Gjat\u00eb eksportit t\u00eb t\u00eb dh\u00ebnave nga Cassandra logjika e aplikacionit duhet t\u00eb funksionoj\u00eb sipas parimit FETCH, n\u00eb m\u00ebnyr\u00eb q\u00eb jo t\u00eb gjitha rreshtat t\u00eb ngarkohen n\u00eb memorie nj\u00ebher\u00ebsh, por t\u00eb zgjidhen n\u00eb grupe.<\/b><\/p>\n

<\/p>\n

\u00cbsht\u00eb e d\u00ebshirueshme q\u00eb para kalimit t\u00eb projektit n\u00eb zgjidhjen e p\u00ebrshkruar t\u00eb kontrollohet q\u00ebndrueshm\u00ebria e sistemit, duke kryer nj\u00eb seri testesh crash<\/b>, si humbja e t\u00eb dh\u00ebnave n\u00eb nj\u00eb Qendr\u00ebn e t\u00eb Dh\u00ebnave, rikuperimi i t\u00eb dh\u00ebnave t\u00eb d\u00ebmtuara p\u00ebr nj\u00eb periudh\u00eb t\u00eb caktuar, ngadal\u00ebsimi i rrjetit midis Qendrave t\u00eb t\u00eb Dh\u00ebnave. K\u00ebto teste jo vet\u00ebm q\u00eb do t\u00eb lejojn\u00eb vler\u00ebsimin e avantazheve dhe disavantazheve t\u00eb arkitektur\u00ebs s\u00eb propozuar, por gjithashtu do t'u japin inxhinier\u00ebve q\u00eb i realizojn\u00eb ato nj\u00eb praktik\u00eb t\u00eb mir\u00eb, dhe aft\u00ebsia e fituar nuk do t\u00eb jet\u00eb aspak e tep\u00ebrt n\u00ebse d\u00ebshtimet e sistemit ndodhin n\u00eb prodhim.<\/p>\n

<\/p>\n

N\u00ebse po punojm\u00eb me informacion kritik (si\u00e7 jan\u00eb t\u00eb dh\u00ebnat p\u00ebr faturim, llogaritjen e borxhit t\u00eb klientit), ka kuptim t\u00eb kushtohet v\u00ebmendje mjeteve q\u00eb do t\u00eb lejojn\u00eb uljen e rreziqeve q\u00eb lindin p\u00ebr shkak t\u00eb ve\u00e7orive t\u00eb DBMS. P\u00ebr shembull, p\u00ebrdorimi i utilitarit nodesync (Datastax), duke zhvilluar nj\u00eb strategji optimale t\u00eb p\u00ebrdorimit t\u00eb tij, n\u00eb m\u00ebnyr\u00eb q\u00eb p\u00ebr shkak t\u00eb konsistenc\u00ebs t\u00eb mos formohet nj\u00eb ngarkes\u00eb tep\u00ebr n\u00eb Cassandra<\/b> dhe ta p\u00ebrdorim vet\u00ebm p\u00ebr tabela t\u00eb caktuara n\u00eb periudha t\u00eb caktuara.<\/p>\n

<\/p>\n

\u00c7far\u00eb ndodhi pas gjasht\u00eb muajve me Cassandra? N\u00eb p\u00ebrgjith\u00ebsi, nuk ka probleme t\u00eb zgjidhura. Nuk kemi lejuar as shp\u00ebrthime serioze dhe as humbje t\u00eb t\u00eb dh\u00ebnave. Po, ishte e nevojshme t\u00eb mendohej p\u00ebr kompenzimin e disa problemeve q\u00eb nuk ishin shfaqur m\u00eb par\u00eb, por n\u00eb fund kjo nuk e r\u00ebndoi shum\u00eb zgjidhjen ton\u00eb arkitekturore. N\u00ebse d\u00ebshiron dhe nuk ke frik\u00eb t\u00eb provosh di\u00e7ka t\u00eb re, dhe n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb nuk d\u00ebshiron t\u00eb zhg\u00ebnjehesh shum\u00eb, p\u00ebrgatitu p\u00ebr faktin se asgj\u00eb nuk \u00ebsht\u00eb falas. Do t\u00eb duhet t\u00eb merresh me detaje, t\u00eb thellohet n\u00eb dokumentacion dhe t\u00eb mbledh\u00ebsh gropat e tua individuale m\u00eb tep\u00ebr se me zgjidhjen e vjet\u00ebr legacy dhe asnj\u00eb teori nuk do t\u00eb t\u00eb jap\u00eb informacion paraprak p\u00ebr ato gropa q\u00eb t\u00eb presin.<\/p>\n

Burimi: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0413\u043e\u0432\u043e\u0440\u044f\u0442, \u0432 \u0436\u0438\u0437\u043d\u0438 \u0432\u0441\u0435 \u0441\u0442\u043e\u0438\u0442 \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0440\u0430\u0437. \u0418 \u0435\u0441\u043b\u0438 \u0432\u044b \u043f\u0440\u0438\u0432\u044b\u043a\u043b\u0438 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0441 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u044b\u043c\u0438 \u0421\u0423\u0411\u0414, \u0442\u043e \u043f\u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u043d\u0430 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0435 \u0441 NoSQL \u0441\u0442\u043e\u0438\u0442 \u0432 \u043f\u0435\u0440\u0432\u0443\u044e \u043e\u0447\u0435\u0440\u0435\u0434\u044c \u0445\u043e\u0442\u044f \u0431\u044b \u0434\u043b\u044f \u043e\u0431\u0449\u0435\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 \u0432 \u0441\u0438\u043b\u0443 \u0431\u0443\u0440\u043d\u043e\u0433\u043e \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u044d\u0442\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0442\u0438\u0432\u043e\u0440\u0435\u0447\u0438\u0432\u044b\u0445 \u043c\u043d\u0435\u043d\u0438\u0439 \u0438 \u0433\u043e\u0440\u044f\u0447\u0438\u0445 \u0441\u043f\u043e\u0440\u043e\u0432 \u043d\u0430 \u044d\u0442\u0443 \u0442\u0435\u043c\u0443, \u0447\u0442\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u043e\u0434\u043e\u0433\u0440\u0435\u0432\u0430\u0435\u0442 \u0438\u043d\u0442\u0435\u0440\u0435\u0441. \u0415\u0441\u043b\u0438 \u0432\u043d\u0438\u043a\u043d\u0443\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28210,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37585","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Si t\u00eb shikosh n\u00eb syt\u00eb e Cassandra-s dhe t\u00eb mos humbas\u00ebsh t\u00eb dh\u00ebnat, stabilitetin dhe besimin n\u00eb NoSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u0433\u043b\u044f\u043d\u0443\u0442\u044c \u0432 \u0433\u043b\u0430\u0437\u0430 \u041a\u0430\u0441\u0441\u0430\u043d\u0434\u0440\u0435 \u0438 \u043d\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u0442\u044c \u043f\u0440\u0438 \u044d\u0442\u043e\u043c \u0434\u0430\u043d\u043d\u044b\u0435, \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u0432\u0435\u0440\u0443 \u0432 NoSQL | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:27+00:00","article:modified_time":"2019-10-31T19:18:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37585","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:29:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:06:01","updated":"2026-01-23 18:29:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/37585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=37585"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/37585\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/28210"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=37585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=37585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=37585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}