{"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\/sk\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","title":{"rendered":"Ako pohladi\u0165 do o\u010d\u00ed Kassandre a pritom nestrati\u0165 d\u00e1ta, stabilitu a vieru v NoSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Ako
\n<\/p>\n

Hovor\u00ed sa, \u017ee v \u017eivote treba v\u0161etko vysk\u00fa\u0161a\u0165 aspo\u0148 raz. A ak ste zvyknut\u00ed pracova\u0165 s rela\u010dn\u00fdmi datab\u00e1zami, odpor\u00fa\u010da sa obozn\u00e1mi\u0165 sa prakticky s NoSQL predov\u0161etk\u00fdm pre v\u0161eobecn\u00fd rozvoj. Vzh\u013eadom na r\u00fdchly rozvoj tejto technol\u00f3gie existuje mnoho rozporupln\u00fdch n\u00e1zorov a horliv\u00fdch diskusi\u00ed na t\u00fato t\u00e9mu, \u010do zvl\u00e1\u0161\u0165 podnecuje z\u00e1ujem.
\nAk sa hlb\u0161ie zamysl\u00edme nad podstatou t\u00fdchto diskusi\u00ed, uk\u00e1\u017ee sa, \u017ee vznikaj\u00fa z nespr\u00e1vneho pr\u00edstupu. T\u00ed, ktor\u00ed pou\u017e\u00edvaj\u00fa NoSQL datab\u00e1zy presne tam, kde s\u00fa potrebn\u00e9, s\u00fa spokojn\u00ed a z\u00edskavaj\u00fa zo tohto rie\u0161enia v\u0161etky jeho v\u00fdhody. Naopak, experiment\u00e1tori, ktor\u00ed d\u00fafaj\u00fa v tuto technol\u00f3giu ako v z\u00e1zrak tam, kde nie je v\u00f4bec vhodn\u00e1, za\u017e\u00edvaj\u00fa sklamanie, preto\u017ee prich\u00e1dzaj\u00fa o siln\u00e9 str\u00e1nky rela\u010dn\u00fdch datab\u00e1z bez zisku zoh\u013eadnite\u013en\u00fdch v\u00fdhod.<\/p>\n

<\/p>\n

Podel\u00edm sa o na\u0161u sk\u00fasenos\u0165 s implement\u00e1ciou rie\u0161enia zalo\u017een\u00e9ho na datab\u00e1ze Cassandra: s \u010d\u00edm sme sa stretli, ako sme sa dostali z \u0165a\u017ek\u00fdch situ\u00e1ci\u00ed, \u010di sme dok\u00e1zali z\u00edska\u0165 v\u00fdhodu z pou\u017e\u00edvania NoSQL a kde sme museli investova\u0165 \u010fal\u0161ie \u00fasilie\/financie.
\nP\u00f4vodn\u00e1 \u00faloha sa t\u00fdkala vytvorenia syst\u00e9mu, ktor\u00fd zaznamen\u00e1va hovory do ur\u010dit\u00e9ho \u00falo\u017eiska.<\/p>\n

<\/p>\n

Princ\u00edp fungovania syst\u00e9mu je nasleduj\u00faci. Na vstup prich\u00e1dzaj\u00fa s\u00fabory s ur\u010ditou \u0161trukt\u00farou, ktor\u00e1 popisuje \u0161trukt\u00faru hovoru. N\u00e1sledne aplik\u00e1cia zabezpe\u010duje ukladanie tejto \u0161trukt\u00fary do pr\u00edslu\u0161n\u00fdch st\u013apcov. Ulo\u017een\u00e9 hovory sa n\u00e1sledne vyu\u017e\u00edvaj\u00fa \u2013 na zobrazenie inform\u00e1ci\u00ed o vyu\u017eit\u00ed d\u00e1t pre \u00fa\u010dastn\u00edkov (\u00fa\u010dtovanie, hovory, hist\u00f3ria zostatku).<\/p>\n

\n\"Ako<\/p>\n

Pre\u010do sme si vybrali Cassandru je celkom jasn\u00e9 \u2014 p\u00ed\u0161e ako gu\u013eomet, \u013eahko sa \u0161k\u00e1luje, je odoln\u00e1 vo\u010di chyb\u00e1m.<\/p>\n

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

Tak\u017ee, tu je to, \u010do n\u00e1m pon\u00fakla sk\u00fasenos\u0165<\/h2>\n

<\/p>\n

\u00c1no, vyleteln\u00e1 uzol nie je katastrofa. V tom spo\u010d\u00edva odolnos\u0165 Cassandry. Ale uzol m\u00f4\u017ee by\u0165 \u017eiv\u00fd a z\u00e1rove\u0148 za\u010da\u0165 poklesa\u0165 po v\u00fdkonnosti<\/b>. Ako sa uk\u00e1zalo, to ihne\u010f ovplyv\u0148uje v\u00fdkonnos\u0165 cel\u00e9ho klastra.<\/p>\n

<\/p>\n

Cassandra neochr\u00e1ni tam, kde Oracle udr\u017eoval pomocou svojich obmedzen\u00ed<\/b>. A ak autor aplik\u00e1cie to dopredu nepochopil, tak zaslan\u00fd duplik\u00e1t pre Cassandru nie je o ni\u010d hor\u0161\u00ed ako origin\u00e1l. Ak pri\u0161iel, teda ho vlo\u017e\u00edme.<\/p>\n

<\/p>\n

Bezplatn\u00e1 Cassandra \"z krabice\" sa n\u00e1hle nep\u00e1\u010dila IT bezpe\u010dnosti: neexistuje logovanie akci\u00ed pou\u017e\u00edvate\u013eov, ani rozdelenie pr\u00e1v<\/b>. Inform\u00e1cie o hovoroch sa t\u00fdkaj\u00fa osobn\u00fdch \u00fadajov, a to znamen\u00e1, \u017ee v\u0161etky pokusy o ich po\u017eiadanie\/zmenu musia by\u0165 zaznamenan\u00e9 s mo\u017enos\u0165ou n\u00e1sledn\u00e9ho auditu. Tie\u017e je potrebn\u00e9 si uvedomi\u0165 nutnos\u0165 rozde\u013eova\u0165 pr\u00e1va na r\u00f4zne \u00farovne pre r\u00f4znych pou\u017e\u00edvate\u013eov. Obvykl\u00fd in\u017einier prev\u00e1dzky a superadministr\u00e1tor, ktor\u00fd m\u00f4\u017ee slobodne odstr\u00e1ni\u0165 cel\u00fd keyspace \u2013 to s\u00fa r\u00f4zne role, r\u00f4zna zodpovednos\u0165, kompetencia. Bez tak\u00e9hoto rozdelenia pr\u00edstupov\u00fdch pr\u00e1v sa hodnota a integrita d\u00e1t okam\u017eite dostan\u00fa pod ot\u00e1zku r\u00fdchlej\u0161ie, ne\u017e pri \u00farovni konzistencie ANY. <\/p>\n

<\/p>\n

Nehovorili sme o tom, \u017ee pre hovory je potrebn\u00e1 ako v\u00e1\u017ena analytika, tak aj periodick\u00e9 v\u00fdbery pod\u013ea r\u00f4znych podmienok. Ke\u010f\u017ee vybran\u00e9 z\u00e1znamy sa potom predpokladaj\u00fa na odstr\u00e1nenie a prep\u00edsanie (v r\u00e1mci \u00falohy mus\u00edme podporova\u0165 proces aktualiz\u00e1cie d\u00e1t pri p\u00f4vodne nespr\u00e1vne doru\u010den\u00fdch d\u00e1tach do na\u0161eho prostredia), Cassandra nie je na\u0161\u00edm spolo\u010dn\u00edkom. Cassandra, ako pokladnica \u2013 je pohodln\u00e9 do nej skladova\u0165, ale ned\u00e1 sa z nej po\u010d\u00edta\u0165.<\/b><\/p>\n

<\/p>\n

Stretli sme sa s probl\u00e9mom prenosu d\u00e1t do testovac\u00edch z\u00f3n<\/b> (5 uzlov v teste oproti 20 v produkcii). Dump v tomto pr\u00edpade nebude mo\u017en\u00e9 pou\u017ei\u0165.<\/p>\n

<\/p>\n

Probl\u00e9m s aktualiz\u00e1ciou sch\u00e9my d\u00e1t aplik\u00e1cie, ktor\u00e1 zapisuje do Cassandry. Rollback vytvor\u00ed obrovsk\u00e9 mno\u017estvo nadrob\u00ed, \u010do m\u00f4\u017ee nepredv\u00eddate\u013en\u00fdm sp\u00f4sobom zn\u00ed\u017ei\u0165 v\u00fdkon<\/b>. Cassandra je optimalizovan\u00e1 pre z\u00e1pis a pred z\u00e1pisom sa ve\u013ea nezam\u00fd\u0161\u013ea. Ak\u00e1ko\u013evek oper\u00e1cia s existuj\u00facimi d\u00e1tami je tie\u017e z\u00e1pis. T. j. odstr\u00e1nen\u00edm zbyto\u010dn\u00e9ho len vytvor\u00edme e\u0161te viac z\u00e1znamov, a len \u010das\u0165 z nich bude ozna\u010den\u00e1 ako nadrobia.<\/p>\n

<\/p>\n

\u010casov\u00e9 obmedzenia pri vkladan\u00ed. Cassandra je v z\u00e1pise skvel\u00e1, ale niekedy prich\u00e1dzaj\u00faci tok ju m\u00f4\u017ee zna\u010dn\u011b zneisti\u0165<\/b>. To sa st\u00e1va, ke\u010f aplik\u00e1cia za\u010d\u00edna s nieko\u013ek\u00fdmi z\u00e1znamami, ktor\u00e9 sa nedaj\u00fa vlo\u017ei\u0165 z nejak\u00e9ho d\u00f4vodu. A budeme potrebova\u0165 skuto\u010dn\u00e9ho DBA, ktor\u00fd bude sledova\u0165 gc.log, logy system a debug kv\u00f4li pomal\u00fdm dotazom, metrik\u00e1m na comapction pending.\n<\/p>\n

<\/p>\n

Nieko\u013eko d\u00e1tov\u00fdch centier v klastri. Odkia\u013e \u010d\u00edta\u0165 a kam zapisova\u0165?<\/b>
\nJe mo\u017en\u00e9 rozdeli\u0165 na \u010d\u00edtanie a z\u00e1pis? A ak \u00e1no, mal by by\u0165 DC bli\u017e\u0161ie k aplik\u00e1cii pre z\u00e1pis alebo pre \u010d\u00edtanie? A nez\u00edska\u0165 tak naozajstn\u00fd split brain, ak nespr\u00e1vne vyberieme \u00farove\u0148 konzistencie? Ve\u013ea ot\u00e1zok, ve\u013ea nepresk\u00faman\u00fdch nastaven\u00ed a mo\u017enost\u00ed, ktor\u00e9 by sme chceli vysk\u00fa\u0161a\u0165.\n<\/p>\n

<\/p>\n

Ako sme sa rozhodli<\/h2>\n

<\/p>\n

Aby n\u00f3d neskolaboval, vypnuli sme SWAP<\/b>. A teraz, pri nedostatku pam\u00e4te, by n\u00f3d mal spadn\u00fa\u0165, a nie produkova\u0165 dlh\u00e9 gc pauzy.<\/p>\n

<\/p>\n

Tak\u017ee na logiku v DB u\u017e viac ned\u00fafame. V\u00fdvoj\u00e1ri aplik\u00e1cie sa pre\u0161ko\u013euj\u00fa a za\u010d\u00ednaj\u00fa sa akt\u00edvne chr\u00e1ni\u0165 vo vlastnom k\u00f3de.<\/b> Ide\u00e1lne jasn\u00e9 oddelenie uchov\u00e1vania a spracovania d\u00e1t.<\/p>\n

<\/p>\n

K\u00fapili sme podporu od DataStax.<\/b> Krabicov\u00e1 Cassandra u\u017e prestala by\u0165 vyv\u00edjan\u00e1 (posledn\u00fd commit v febru\u00e1ri 2018). Z\u00e1rove\u0148 v\u0161ak Datastax pon\u00faka vynikaj\u00facu slu\u017ebu a mno\u017estvo vylep\u0161en\u00fdch a prisp\u00f4soben\u00fdch rie\u0161en\u00ed pre existuj\u00face IS.<\/p>\n

<\/p>\n

E\u0161te chcem poznamena\u0165, \u017ee Cassandra nie je ve\u013emi pohodln\u00e1 na dotazy na v\u00fdber. Samozrejme, CQL je ve\u013ek\u00fd krok v \u00fastrety pou\u017e\u00edvate\u013eom (v porovnan\u00ed s Thriftom). Ale ak m\u00e1te cel\u00e9 oddelenia, ktor\u00e9 s\u00fa zvyknut\u00e9 na tak\u00e9to pohodln\u00e9 joins, vo\u013en\u00e9 filtrovanie pod\u013ea ak\u00e9hoko\u013evek po\u013ea a mo\u017enosti optimaliz\u00e1cie dotazu, a tieto oddelenia pracuj\u00fa na uzatv\u00e1ran\u00ed s\u0165a\u017enost\u00ed a hav\u00e1ri\u00ed, tak im rie\u0161enie na Cassandre pripad\u00e1 nepriate\u013esk\u00e9 a hl\u00fape. A za\u010dali sme rie\u0161i\u0165 ot\u00e1zku, ako na\u0161i kolegovia robia v\u00fdbery. <\/p>\n

<\/p>\n

Zva\u017eovali sme dve mo\u017enosti. V prvej mo\u017enosti zapisujeme volania nielen do C*, ale aj do arch\u00edvnej datab\u00e1zy Oracle. Rozdiel je v tom, \u017ee v tejto datab\u00e1ze s\u00fa ulo\u017een\u00e9 volania iba za aktu\u00e1lny mesiac (dostato\u010dn\u00e1 h\u013abka uchov\u00e1vania volan\u00ed pre pr\u00edpady prehodnocovania). Tu sa ihne\u010f objavila nasleduj\u00faca probl\u00e9m: ak zapisujeme synchronne, strat\u00edme v\u0161etky v\u00fdhody C*, s\u00favisiace s r\u00fdchlym vkladan\u00edm, ak asynchr\u00f3nne \u2013 nie je zaru\u010den\u00e9, \u017ee v\u0161etky potrebn\u00e9 volania sa v\u00f4bec dostan\u00fa do Oracle. Jedinou v\u00fdhodou bol jeden, ale v\u00fdznamn\u00fd bod: na prev\u00e1dzku zost\u00e1va st\u00e1le rovnak\u00fd zn\u00e1my PL\/SQL Developer, teda prakticky realizujeme vzor \u201eFas\u00e1da\u201c. Alternat\u00edvna mo\u017enos\u0165. Realizujeme mechanizmus, ktor\u00fd vy\u0165ahuje volania z C*, \u0165ah\u00e1 nejak\u00e9 \u00fadaje na obohatenie z pr\u00edslu\u0161n\u00fdch tabuliek v Oracle, spoj\u00ed z\u00edskan\u00e9 v\u00fdbery a poskytne n\u00e1m v\u00fdsledok, ktor\u00fd potom nejako pou\u017eijeme (vr\u00e1time, opakujeme, analyzujeme, obdivujeme). Nev\u00fdhody: proces sa st\u00e1va dos\u0165 viacf\u00e1zov\u00fdm, a okrem toho ch\u00fdba rozhranie pre zamestnancov prev\u00e1dzky.<\/p>\n

<\/p>\n

Nakoniec sme sa predsa len rozhodli pre druh\u00fa mo\u017enos\u0165. Na v\u00fdbery z r\u00f4znych datab\u00e1z sme pou\u017eili Apache Spark.<\/b> Podstata mechanizmu spo\u010d\u00edvala v Java k\u00f3de, ktor\u00fd na z\u00e1klade zadan\u00fdch k\u013e\u00fa\u010dov (abonent, \u010das volania \u2013 k\u013e\u00fa\u010de sekcie) vy\u0165ahoval \u00fadaje z C*, ako aj potrebn\u00e9 \u00fadaje na obohatenie z akejko\u013evek inej datab\u00e1zy. Potom ich spojil vo svojej pam\u00e4ti a zobrazil v\u00fdsledok v v\u00fdslednej tabu\u013eke. Nad Sparkom sme nakreslili webov\u00e9 rozhranie a v\u00fdsledok bol celkom vhodn\u00fd na prev\u00e1dzku.<\/p>\n

\n\"Ako<\/p>\n

Pri rie\u0161en\u00ed \u00falohy s aktualiz\u00e1ciou d\u00e1t op\u00e4\u0165 zv\u00e1\u017eili nieko\u013eko sp\u00f4sobov rie\u0161enia. Ako prenos cez Sstloader, tak aj mo\u017enos\u0165 rozdelenia klastru v testovacej z\u00f3ne na dve \u010dasti, pri\u010dom ka\u017ed\u00e1 z nich striedavo vstupuje do jedn\u00e9ho klastru s produk\u010dn\u00fdm, \u010derpaj\u00fac tak od neho. Pri aktualiz\u00e1cii testu sa pl\u00e1novalo meni\u0165 ich miestami: t\u00e1 \u010das\u0165, ktor\u00e1 pracovala v teste, sa vy\u010dist\u00ed a zav\u00e1dza do produkcie, zatia\u013e \u010do druh\u00e1 sa za\u010dne zaobera\u0165 d\u00e1tami oddelene. Av\u0161ak, po \u010fal\u0161om zv\u00e1\u017een\u00ed sme racion\u00e1lnej\u0161ie pos\u00fadili tie \u00fadaje, ktor\u00e9 stoj\u00ed za to pren\u00e1\u0161a\u0165, a pochopili sme, \u017ee samotn\u00e9 v\u00fdzvy \u2013 nekonzistentn\u00e1 entita pre testy, r\u00fdchlo generovan\u00e1 v pr\u00edpade potreby, a pr\u00e1ve produk\u010dn\u00fd s\u00fabor d\u00e1t nem\u00e1 hodnotu na prenos do testu. Existuje nieko\u013eko objektov-zhroma\u017e\u010fova\u010dov, ktor\u00e9 stoj\u00ed za to pren\u00e1\u0161a\u0165, ale to s\u00fa doslova len dve tabu\u013eky, pri\u010dom nie s\u00fa ve\u013emi n\u00e1ro\u010dn\u00e9. Preto n\u00e1m ako rie\u0161enie op\u00e4\u0165 pomohol Spark, pomocou ktor\u00e9ho sme nap\u00edsali a za\u010dali akt\u00edvne pou\u017e\u00edva\u0165 skript na prenos d\u00e1t medzi tabu\u013ekami produkcia-test.<\/b><\/p>\n

<\/p>\n

Na\u0161a aktu\u00e1lna politika nasadzovania n\u00e1m umo\u017e\u0148uje pracova\u0165 bez n\u00e1vratov.<\/b> Pred produkciou prebieha povinn\u00e9 nasadenie na test, kde je chyba menej n\u00e1kladn\u00e1. V pr\u00edpade ne\u00faspechu je v\u017edy mo\u017en\u00e9 zmaza\u0165 keyspace a nasadi\u0165 cel\u00fa sch\u00e9mu od za\u010diatku.<\/p>\n

<\/p>\n

Na zabezpe\u010denie nepokra\u010duj\u00facej dostupnosti Cassandry je potrebn\u00fd DBA a nie len on. V\u0161etci, ktor\u00ed pracuj\u00fa s aplik\u00e1ciou, musia ch\u00e1pa\u0165, kde a ako sledova\u0165 aktu\u00e1lnu situ\u00e1ciu a ako v\u010das diagnostikova\u0165 probl\u00e9my.<\/b> Na to akt\u00edvne pou\u017e\u00edvame DataStax OpsCenter (Spr\u00e1va a monitorovanie pracovn\u00fdch z\u00e1\u0165a\u017e\u00ed), syst\u00e9mov\u00e9 metriky Cassandra Driver (po\u010det timeoutov na z\u00e1pis do C*, po\u010det timeoutov na \u010d\u00edtanie z C*, maxim\u00e1lna latencia at\u010f.), monitorujeme \u010dinnos\u0165 samotnej aplik\u00e1cie, ktor\u00e1 pr\u00e1ve pracuje s Cassandrou.\n<\/p>\n

<\/p>\n

Ke\u010f sme sa zamysleli nad predch\u00e1dzaj\u00facou ot\u00e1zkou, uvedomili sme si, kde m\u00f4\u017ee by\u0165 n\u00e1\u0161 hlavn\u00fd riziko. T\u00fdm s\u00fa formy zobrazenia d\u00e1t, ktor\u00e9 vy\u0165ahuj\u00fa \u00fadaje z nieko\u013ek\u00fdch navz\u00e1jom nez\u00e1visl\u00fdch po\u017eiadaviek na \u00falo\u017eisko. Takto m\u00f4\u017eeme z\u00edska\u0165 pomerne nekonzistentn\u00e9 inform\u00e1cie. Av\u0161ak tento probl\u00e9m by bol rovnako aktu\u00e1lny aj v pr\u00edpade, keby sme pracovali iba s jedn\u00fdm d\u00e1tov\u00fdm centrom. Tak\u017ee najrozumnej\u0161ie by bolo, samozrejme, vytvori\u0165 d\u00e1vkov\u00fa funkciu \u010d\u00edtania \u00fadajov v externom aplik\u00e1cii, ktor\u00e1 zabezpe\u010d\u00ed z\u00edskanie d\u00e1t v jednotnom \u010dasovom obdob\u00ed. Pokia\u013e ide o rozdelenie na \u010d\u00edtanie a z\u00e1pis z h\u013eadiska v\u00fdkonu, tu n\u00e1s zastavil riziko, \u017ee pri ur\u010dit\u00fdch strat\u00e1ch spojenia medzi d\u00e1tov\u00fdmi centrami m\u00f4\u017eeme z\u00edska\u0165 dva \u00faplne nekonzistentn\u00e9 clustery.<\/p>\n

<\/p>\n

Nakoniec, v s\u00fa\u010dasnosti sme sa rozhodli pre \u00farove\u0148 konzistencie pre z\u00e1pis EACH_QUORUM, pre \u010d\u00edtanie \u2013 LOCAL_QUORUM<\/b><\/p>\n

<\/p>\n

Kr\u00e1tke dojmy a z\u00e1very<\/h2>\n

<\/p>\n

Aby sme ocenili vyvinut\u00e9 rie\u0161enie z h\u013eadiska prev\u00e1dzky a perspekt\u00edvy \u010fal\u0161ieho rozvoja, rozhodli sme sa zamyslie\u0165, kde e\u0161te m\u00f4\u017eeme aplikova\u0165 tak\u00fato technol\u00f3giu.<\/p>\n

<\/p>\n

Ak hne\u010f, tak scoring d\u00e1t pre programy typu \u201ePla\u0165, ke\u010f ti to vyhovuje\u201c (nahr\u00e1vame do S* inform\u00e1cie, v\u00fdpo\u010dty na skriptoch Spark), sledovanie reklam\u00e1ci\u00ed s agreg\u00e1ciou pod\u013ea smerov, uchov\u00e1vanie rol\u00ed a v\u00fdpo\u010dty pod\u013ea rolov\u00e9ho matice pr\u00edstupov\u00fdch pr\u00e1v pou\u017e\u00edvate\u013eov. <\/p>\n

<\/p>\n

Ako vid\u00edme, reperto\u00e1r je \u0161irok\u00fd a rozmanit\u00fd. A ak by sme mali vybra\u0165 t\u00e1bor priaznivcov\/odporky\u0148 NoSQL, pripoj\u00edme sa k priaznivcom, preto\u017ee sme z\u00edskali svoje v\u00fdhody, a to presne tam, kde sme o\u010dak\u00e1vali.<\/p>\n

<\/p>\n

Aj variant Cassandra z krabice umo\u017e\u0148uje horizont\u00e1lne \u0161k\u00e1lovanie v re\u00e1lnom \u010dase, bezprobl\u00e9movo rie\u0161i ot\u00e1zku zvy\u0161ovania \u00fadajov v syst\u00e9me. Podarilo sa n\u00e1m vy\u010dleni\u0165 do samostatn\u00e9ho kont\u00faru ve\u013emi za\u0165a\u017een\u00fd mechanizmus na v\u00fdpo\u010det agreg\u00e1tov z hovorov, ako aj rozdeli\u0165 sch\u00e9mu a logiku aplik\u00e1cie, zbaviac sa zle o\u010dividnej praxe p\u00edsania vlastn\u00fdch \u00faloh a objektov v samotnej datab\u00e1ze. Z\u00edskali sme mo\u017enos\u0165 vybera\u0165 a nastavova\u0165, pre ur\u00fdchlenie, na ktor\u00fdch d\u00e1tov\u00fdch centr\u00e1ch budeme robi\u0165 v\u00fdpo\u010dty a na ktor\u00fdch zapisova\u0165 d\u00e1ta, \u010d\u00edm sme sa chr\u00e1nili pred zlyhaniami jednotliv\u00fdch uzlov, ako aj celkovo d\u00e1tov\u00e9ho centra.<\/p>\n

<\/p>\n

Pri aplik\u00e1cii na\u0161ej architekt\u00fary na nov\u00e9 projekty, pri\u010dom u\u017e m\u00e1me ur\u010dit\u00fa sk\u00fasenos\u0165, by sme mali hne\u010f zoh\u013eadni\u0165 vy\u0161\u0161ie pop\u00edsan\u00e9 nuansy a predi\u0165 niektor\u00fdm chyb\u00e1m, vyhladi\u0165 ur\u010dit\u00e9 ostr\u00e9 hrany, ktor\u00fdm sme sa p\u00f4vodne nevyhli.<\/p>\n

<\/p>\n

Napr\u00edklad, v\u010das sledova\u0165 aktualiz\u00e1cie samotnej Cassandry.<\/b>, preto\u017ee mno\u017estvo probl\u00e9mov, ktor\u00e9 sme za\u017eili, u\u017e bolo zn\u00e1mych a opraven\u00fdch.<\/p>\n

<\/p>\n

Nesadit samotn\u00fa datab\u00e1zu a Spark na rovnak\u00e9 uzly.<\/b> (alebo pr\u00edsne rozli\u0161ova\u0165 pod\u013ea po\u010dtu povolen\u00e9ho vyu\u017eitia zdrojov), preto\u017ee Spark m\u00f4\u017ee spotrebova\u0165 viac pam\u00e4te, ne\u017e je povolen\u00e9, a r\u00fdchlo sa dostaneme k probl\u00e9mu \u010d\u00edslo 1 z n\u00e1\u0161ho zoznamu.<\/p>\n

<\/p>\n

Zlep\u0161i\u0165 monitoring a odborn\u00e9 zru\u010dnosti v oblasti prev\u00e1dzky u\u017e v etape testovania projektu. <\/b>P\u00f4vodne zoh\u013eadni\u0165 maxim\u00e1lne v\u0161etk\u00fdch potenci\u00e1lnych pou\u017e\u00edvate\u013eov n\u00e1\u0161ho rie\u0161enia,<\/b>preto\u017ee pr\u00e1ve od toho bude nakoniec z\u00e1visie\u0165 \u0161trukt\u00fara datab\u00e1zy.<\/p>\n

<\/p>\n

Nieko\u013ekokr\u00e1t prehodnoti\u0165 z\u00edskan\u00fa sch\u00e9mu z poh\u013eadu mo\u017enej optimaliz\u00e1cie. Ur\u010di\u0165, ktor\u00e9 polia je mo\u017en\u00e9 serializova\u0165. Pochopi\u0165, ak\u00e9 \u010fal\u0161ie tabu\u013eky potrebujeme vytvori\u0165, aby sme \u010do najpresnej\u0161ie a optim\u00e1lne zoh\u013eadnili a nesk\u00f4r poskytli po\u017eadovan\u00e9 inform\u00e1cie (napr\u00edklad, ak predpoklad\u00e1me, \u017ee rovnak\u00e9 \u00fadaje m\u00f4\u017eeme uchov\u00e1va\u0165 v r\u00f4znych tabu\u013ek\u00e1ch s r\u00f4znym rozdelen\u00edm pod\u013ea r\u00f4znych krit\u00e9ri\u00ed, m\u00f4\u017eeme v\u00fdrazne u\u0161etri\u0165 procesorov\u00fd \u010das pri \u010d\u00edtac\u00edch dopytoch).<\/p>\n

<\/p>\n

Nie je zl\u00e9 ihne\u010f predpoklada\u0165 zavedenie TTL a \u010distenie zastaran\u00fdch \u00fadajov.<\/b><\/p>\n

<\/p>\n

Pri exportovan\u00ed \u00fadajov z Cassandry, logika aplik\u00e1cie by mala fungova\u0165 na princ\u00edpe FETCH, aby sa v\u0161etky riadky nena\u010d\u00edtali do pam\u00e4te naraz, ale vyberali sa po d\u00e1vkach.<\/b><\/p>\n

<\/p>\n

Odpor\u00fa\u010da sa pred prechodom projektu na op\u00edsan\u00e9 rie\u0161enie skontrolova\u0165 odolnos\u0165 syst\u00e9mu vykonan\u00edm s\u00e9rie crash-testov,<\/b>, ako je strata \u00fadajov v jednom d\u00e1tovom centre, obnova po\u0161koden\u00fdch \u00fadajov za ur\u010dit\u00fd \u010das, pokles siete medzi d\u00e1tov\u00fdmi centrami. Tieto testy nielen umo\u017enia oceni\u0165 v\u00fdhody a nev\u00fdhody navrhnutej architekt\u00fary, ale poskytn\u00fa aj dobr\u00fa rozcvi\u010dku in\u017einierom, ktor\u00ed ich vykon\u00e1vaj\u00fa, a z\u00edskan\u00e1 zru\u010dnos\u0165 sa uk\u00e1\u017ee ako ve\u013emi u\u017eito\u010dn\u00e1, ak sa poruchy syst\u00e9mu bud\u00fa v praxi opakova\u0165.<\/p>\n

<\/p>\n

Ak pracujeme s kritick\u00fdmi inform\u00e1ciami (ako s\u00fa \u00fadaje na faktur\u00e1ciu, v\u00fdpo\u010det dlhu z\u00e1kazn\u00edka), je d\u00f4le\u017eit\u00e9 venova\u0165 pozornos\u0165 n\u00e1strojom, ktor\u00e9 pom\u00f4\u017eu zn\u00ed\u017ei\u0165 rizik\u00e1 vypl\u00fdvaj\u00face z vlastnost\u00ed DBMS. Napr\u00edklad je mo\u017en\u00e9 pou\u017ei\u0165 n\u00e1stroj nodesync (Datastax) a vypracova\u0165 optim\u00e1lnu strat\u00e9giu jeho pou\u017e\u00edvania, aby sa pre konzistenciu nevytvorila nadmern\u00e1 z\u00e1\u0165a\u017e na Cassandre<\/b> a pou\u017e\u00edva\u0165 ho len pre ur\u010dit\u00e9 tabu\u013eky v ur\u010dit\u00fdch obdobiach.<\/p>\n

<\/p>\n

\u010co sa stalo po \u0161iestich mesiacoch \u017eivota s Cassandrou? Celkovo sme nemali nevyrie\u0161en\u00e9 probl\u00e9my. Z\u00e1va\u017en\u00e9 hav\u00e1rie a strata \u00fadajov sa tie\u017e nevyskytli. \u00c1no, bolo potrebn\u00e9 zamyslie\u0165 sa nad kompenz\u00e1ciou niektor\u00fdch probl\u00e9mov, ktor\u00e9 predt\u00fdm nevznikali, ale nakoniec to na\u0161u architektonick\u00fa rozhodnutie v\u00fdrazne neovplyvnilo. Ak chcete a neboj\u00edte sa vysk\u00fa\u0161a\u0165 nie\u010do nov\u00e9, z\u00e1rove\u0148 si ne\u017eel\u00e1te by\u0165 pr\u00edli\u0161 sklaman\u00ed, pripravte sa na to, \u017ee ni\u010d nie je zadarmo. Bude potrebn\u00e9 sa ponori\u0165 do dokument\u00e1cie a zhroma\u017edi\u0165 si svoje vlastn\u00e9 sk\u00fasenosti viac ako pri star\u00fdch rie\u0161eniach legacy a \u017eiadna te\u00f3ria v\u00e1m vopred nepovie, ak\u00e9 prek\u00e1\u017eky \u010dakaj\u00fa pr\u00e1ve na v\u00e1s.<\/p>\n

Zdroj: 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\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\udd47Ako nahliadnu\u0165 do o\u010d\u00ed Cassandre a pritom nestrati\u0165 d\u00e1ta, stabilitu a d\u00f4veru v NoSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sk\/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":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/37585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=37585"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/37585\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/28210"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=37585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=37585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=37585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}