{"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\/et\/blog\/administrirovanie\/kak-zaglyanut-v-glaza-kassandre-i-ne-poteryat-pri-etom-dannye-stabilnost-i-veru-v-nosql","title":{"rendered":"Kuidas vaadata Kassandrale silma ja mitte kaotada andmeid, stabiilsust ja usku NoSQL-i?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n<\/p>\n

\u00d6eldakse, et elus tasub k\u00f5ike v\u00e4hemalt kord proovida. Ja kui olete harjunud t\u00f6\u00f6tama relationaalsete andmebaasidega, siis on NoSQL-ga tutvumine alguses v\u00e4hemalt \u00fcldiseks arenduseks vajalik. Praegu on selle tehnoloogia kiire arengu t\u00f5ttu palju vastuolulisi arvamusi ja kuumi vaidlusi, mis toidavad huvi.
\nKui s\u00fc\u00fcbida sellesse, siis v\u00f5ib n\u00e4ha, et vaidlused tekivad vale l\u00e4henemise t\u00f5ttu. Need, kes kasutavad NoSQL andmebaase just seal, kus need on vajalikud, on rahul ja saavad selle lahenduse k\u00f5ik plussid. Eksperimenteerijad, kes loodavad sellele tehnoloogiale imerohuna seal, kus see ei ole \u00fcldse rakendatav, kogevad pettumust, kaotades relationaalsete andmebaaside tugevused ilma olulisi eeliseid omandamata.<\/p>\n

<\/p>\n

R\u00e4\u00e4gin oma kogemusest lahenduse juurutamise osas, mis p\u00f5hineb Cassandra andmebaasil: millega tuli silmitsi seista, kuidas keerulistes olukordades v\u00e4lja p\u00e4\u00e4sesime, kas suutsime NoSQL kasutamisest kasu saada ja kuhu tuli lisada t\u00e4iendavaid j\u00f5upingutusi\/rahakulu.
\nAlgne \u00fclesanne oli luua s\u00fcsteem, mis salvestab k\u00f5nesid mingisse salvestisse.<\/p>\n

<\/p>\n

S\u00fcsteemi t\u00f6\u00f6p\u00f5him\u00f5te on j\u00e4rgmine. Sissetulevad failid sisaldavad teatud struktuuri, mis kirjeldab k\u00f5ne struktuuri. Seej\u00e4rel tagab rakendus selle struktuuri salvestamise vastavatesse veergudesse. Edasi salvestatud k\u00f5nesid kasutatakse \u2013 n\u00e4iteks teabe kuvamiseks liiklustarbimise kohta abonentidele (tasud, k\u00f5ned, saldo ajalugu).<\/p>\n

\n\"Kuidas<\/p>\n

Miks Cassandra valiti, on t\u00e4iesti arusaadav \u2013 see kirjutab nagu kuulipildur, on lihtsalt skaleeritav ja talub rikkeid.<\/p>\n

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

Nii et siin on see, mida kogemus meile andis<\/h2>\n

<\/p>\n

Jah, v\u00e4lja kukkunud s\u00f5lm ei ole trag\u00f6\u00f6dia. See ongi Cassandra rikkeitaluvuse m\u00f5te. Aga s\u00f5lm v\u00f5ib olla elus, kuid sellegipoolest alandada oma j\u00f5udlust.<\/b>. Nagu selgus, m\u00f5jutab see kohe kogu klastrite tootlikkust.<\/p>\n

<\/p>\n

Cassandra ei kaitse seal, kus Oracle p\u00e4\u00e4stis oma piirangutega.<\/b>. Ja kui rakenduse autor ei saanud sellest eelnevalt aru, siis j\u00f5udnud duubel Cassandra jaoks ei ole sugugi halvem originaalist. Kui tuli, siis paneme selle sisse.<\/p>\n

<\/p>\n

Tasuta Cassandra \u201ekarbist v\u00e4ljas\u201c ei meeldinud Infotehnoloogiale: kasutajate tegevuse logimist ei ole, samuti ei ole \u00f5iguste piiramist.<\/b>Kutsedega seotud teave kuulub isikuandmete hulka, mis t\u00e4hendab, et k\u00f5ik katsed selle taotlemiseks v\u00f5i muutmiseks peavad olema logitud v\u00f5imalusega hilisema kontrolli jaoks. Samuti tuleb teadvustada vajadust jagada \u00f5igusi erinevatele tasanditele erinevate kasutajate jaoks. Lihtne tegevinsener ja superadmin, kes v\u00f5ib vabalt kustutada kogu keyspace'i \u2013 need on erinevad rollid, erinevad vastutused, erinevad kompetentsid. Ilma sellise ligip\u00e4\u00e4su\u00f5iguste eristamiseta seaduse ja andmete v\u00e4\u00e4rtus ning terviklikkus hakkavad kiiremini kahtluse alla minema kui ANY konsistentsitasemel. <\/p>\n

<\/p>\n

Me ei arvestanud, et k\u00f5nede osas on vajalik nii t\u00f5sine anal\u00fc\u00fcs kui ka perioodilised valikud v\u00e4ga erinevate tingimuste alusel. Kuna valitud kirjed tuleks hiljem eemaldada ja \u00fcle kirjutada (\u00fclesande raames peame toetama andmete ajakohastamise protsessi algselt valeandmete saamise korral), ei sobi Cassandra meile siinkohal. Cassandra nagu seif \u2013 sinna on mugav asju panna, kuid seal ei saa h\u00e4sti lugeda.<\/b><\/p>\n

<\/p>\n

Oleme silmitsi seisnud andmete edastamise probleemiga testimisaladesse.<\/b> (5 node'i testis vs 20 tootmises). Sel juhul ei saa dump'i kasutada.<\/p>\n

<\/p>\n

Probleem rakenduse andmeskeemide v\u00e4rskendamisel, mis kirjutab Cassandrasse. Tagasiv\u00f5tmine genereerib suure hulga m\u00e4lestustahvleid, mis v\u00f5ib ettearvamatul viisil meie j\u00f5udlust m\u00f5jutada.<\/b>Cassandra on optimeeritud kirjutamiseks ja enne kirjutamist ei m\u00f5tle ta palju. Iga olemasolevate andmete toiming on samuti kirjutamine. St, kustutades \u00fcleliigset, genereerime me lihtsalt veelgi rohkem kirjeid, millest ainult osa on t\u00e4histatud m\u00e4lestustahvlitega.<\/p>\n

<\/p>\n

Aegumised sisestamisel. Cassandra on kirjutamisel suurep\u00e4rane, kuid m\u00f5nikord v\u00f5ib sissetulev voog seda t\u00f5siselt segadusse ajada.<\/b>See juhtub siis, kui rakendus hakkab ringi jooksma mitmete kirjetega, mida ei \u00f5nnestu mingil p\u00f5hjusel sisestada. Ja meil on vaja t\u00f5elist DBA, kes j\u00e4lgib gc.log, system ja debug logisid aeglaste p\u00e4ringute osas ning compaction pending'i m\u00f5\u00f5dikuid.\n<\/p>\n

<\/p>\n

Mitu andmekeskust klastris. Kust lugeda ja kuhu kirjutada?<\/b>
\nKas on v\u00f5imalik eraldada lugemis- ja kirjutamisprotsessid? Ja kui jah, siis peaks DC olema l\u00e4hemal rakendusele kirjutamiseks v\u00f5i lugemiseks? Ja kas meil ei esine t\u00f5elist split brain'i, kui valime vale j\u00e4rjepidevuse tasandi? T\u00e4iesti palju k\u00fcsimusi, palju uurimata seadeid ja v\u00f5imalusi, mida tahaks proovida.\n<\/p>\n

<\/p>\n

Kuidas me probleemi lahendasime<\/h2>\n

<\/p>\n

Kuna node'i j\u00f5udlus langes, l\u00fclitasime SWAPi v\u00e4lja<\/b>. N\u00fc\u00fcd, kui m\u00e4lu on puudus, peaks node kokku kukkuma, mitte tekitama suuri gc pause.<\/p>\n

<\/p>\n

Nii et me ei looda enam andmebaasi loogikale. Rakenduse arendajad \u00f5pivad \u00fcmber ja hakkavad aktiivselt enda koodis tagama.<\/b> Ideaalne selge andmete salvestamise ja t\u00f6\u00f6tlemise jaotus.<\/p>\n

<\/p>\n

Ostsime DataStaxi tuge.<\/b> Karu pakendatud Cassandra arendamine on l\u00f5petatud (viimane commit veebruaris 2018). Samas pakub Datastax suurep\u00e4rast teenust ja palju t\u00e4iustatud lahendusi, mis on kohandatud olemasolevatele infos\u00fcsteemidele.<\/p>\n

<\/p>\n

Tahaksin veel m\u00e4rkida, et Cassandra ei ole v\u00e4ga mugav p\u00e4ringute tegemiseks. Loomulikult on CQL suur samm kasutajate suunas (v\u00f5rreldes Thriftiga). Kuid kui teil on terved osakonnad, kes on harjunud selliste mugavate liitmisv\u00f5imalustega, vabade filtritega igasuguste v\u00e4ljade j\u00e4rgi ja p\u00e4ringute optimeerimise v\u00f5imalustega, ning need osakonnad t\u00f6\u00f6tavad selle nimel, et lahendada pretensioone ja avariisid, siis tundub Cassandra lahendus neile vaenulik ja rumal. Ja me hakkasime vaatama, kuidas meie kolleegid saaksid andmeid v\u00e4lja v\u00f5tta. <\/p>\n

<\/p>\n

Kahe variandi vahel arutati. Esimeses variandis registreerime kutsed mitte ainult C*, vaid ka arhiivis olevasse Oracle andmebaasi. Ainult erinevalt C*-st hoitakse selle andmebaasis kutseid vaid jooksva kuu jooksul (kutsumise piisav salvestamise s\u00fcgavus peretransformeerimise juhtumite jaoks). Siin n\u00e4gin kohe j\u00e4rgmist probleemi: kui kirjutada s\u00fcnkroonselt, kaotame k\u00f5ik C*-ga seotud kiirused, kui as\u00fcnkroonselt \u2013 pole garantiid, et k\u00f5ik vajalikud kutsed \u00fcldse Oracle'i j\u00f5uavad. \u00dcks suur pluss oli: t\u00f6\u00f6s j\u00e4\u00e4b kasutusele tuttav PL\/SQL Developer, see t\u00e4hendab, et saame praktiliselt rakendada \u201eFassaadi\u201c mustrit. Alternatiivne variant. Rakendame mehhanismi, mis eksportib kutsed C*-st, toob vajalikud andmed neid rikastama Oracle'i vastavatest tabelitest, liidab saadud valikud ning annab meile tulemuse, mida me hiljem mingil moel kasutame (tagasi rullime, kordame, anal\u00fc\u00fcsime, imetleme). Miinused: protsess osutub \u00fcsna mitmeastmeliseks ning lisaks puudub t\u00f6\u00f6tajatele kasutajaliides.<\/p>\n

<\/p>\n

Kokkuv\u00f5ttes j\u00e4\u00e4me siiski teise variandi juurde. Erinevate purkide valikute jaoks kasutasime Apache Spark'i.<\/b> Mehhanismi sisu kujunes Java-koodiks, mis m\u00e4\u00e4ratletud v\u00f5tmete (tellija, k\u00f5ne toimumise aeg \u2013 sektsiooni v\u00f5tmed) alusel toob andmed C*-st ning samuti vajalikud andmed rikastamiseks mistahes teisest andmebaasist. P\u00e4rast seda liidab need enda m\u00e4llu ja kuvab tulemuse tulemuste tabelisse. Sparki peal joonistasime veebiliidese ja see osutus t\u00e4iesti kasutatavaks.<\/p>\n

\n\"Kuidas<\/p>\n

Andmete uuendamise \u00fclesande lahendamisel vaadati taas mitmeid lahendusviise. Nii Sstloaderi kaudu edasiviimise kui ka testimisalase klusteri jagamise variant, mis jaguneb kaheks osaks, millest kumbki siseneb vaheldumisi \u00fchte klastrisse tootmisandmete jaoks, toites end seel\u00e4bi \u00e4ra. Uuendamise k\u00e4igus plaaniti nende vahetamist: osa, mis t\u00f6\u00f6tas testis, puhastatakse ja sisenetakse tootmisse, samas kui teine osa hakkab andmetega eraldi t\u00f6\u00f6tama. Siiski, peale veelkordset l\u00e4bi m\u00f5tlemist hindasime ratsionaalsemalt, millised andmed v\u00e4\u00e4rivad edasiviimist ja m\u00f5istsime, et ise\u00e4ranis on kutsed \u2013 testide jaoks konsistentsuseta entiteet, mis genereeritakse kiiresti vajadusel, ning tootmisandmete komplekt ei oma v\u00e4\u00e4rtust edasiviimiseks testides. On mitmeid kogumisobjekte, mida oleks m\u00f5istlik edastada, kuid see on s\u00f5na otseses m\u00f5ttes paar tabelit, mis ei ole liiga rasked. Seet\u00f5ttu tuli taas lahenduseks Spark, mille abil kirjutasime ja hakkasime aktiivselt kasutama andmete edastusskripti tabelite vahel tootmiste ja testide vahel.<\/b><\/p>\n

<\/p>\n

Meie praegune juurutamise poliitika v\u00f5imaldab meil t\u00f6\u00f6tada ilma tagasikeeramiseta.<\/b> Enne tootmist toimub kohustuslik katsetus, kus viga ei ole nii kallis. Eba\u00f5nne korral saab alati kaotada kiirusruumi ja taastada kogu skeemi algusest peale.<\/p>\n

<\/p>\n

Kassandras pideva k\u00e4ttesaadavuse tagamiseks on vajalik DBA ja mitte ainult tema. K\u00f5ik, kes rakendusega t\u00f6\u00f6tavad, peavad m\u00f5istma, kus ja kuidas vaadata praegust olukorda ning kuidas aegsasti probleeme diagnoosida.<\/b> Selleks kasutame aktiivselt DataStax OpsCenterit (t\u00f6\u00f6koormuse haldamine ja j\u00e4lgimine), Cassandra Driveri s\u00fcsteemseid m\u00f5\u00f5dikuid (C* kirjutamise ajakulumiste arv, C* lugemise ajakulumiste arv, maksimaalne latentsus jne), j\u00e4lgime ise rakenduse t\u00f6\u00f6d, mis toimib koos Kassandraga.\n<\/p>\n

<\/p>\n

Kui m\u00f5tlesime eelnevale k\u00fcsimusele, sai selgeks, kus v\u00f5ib peituda p\u00f5hirisk. Need on andmete kuvamisvormid, mis t\u00f5mbavad andmeid mitmest omavahel s\u00f5ltumatust p\u00e4ringust andmehoidlas. Nii v\u00f5ime saada \u00fcsna ebaj\u00e4rjekindlat teavet. Kuid see probleem oleks sama aktuaalne ka siis, kui t\u00f6\u00f6taksime ainult \u00fche andmekeskusega. Seega on m\u00f5istlikim siin luua andmete lugemise partii funktsioon kolmandas rakenduses, mis tagab andmete saamise \u00fches ajavahemikus. Mis puudutab lugemise ja kirjutamise eristamist tootlikkuse osas, siis takistas meid risk, et teatud \u00fchenduse katkemisel andmekeskuste vahel v\u00f5ime saada kaks omavahel t\u00e4iesti ebaj\u00e4rjekindlat klastrit.<\/p>\n

<\/p>\n

Kokkuv\u00f5ttes, hetkel otsustasime, et kirje jaoks on j\u00e4rjepidevuse tase EACH_QUORUM, lugemise jaoks \u2013 LOCAL_QUORUM<\/b><\/p>\n

<\/p>\n

K\u00fcsimuste l\u00fchikesed muljed ja j\u00e4reldused<\/h2>\n

<\/p>\n

Et hinnata saadud lahendust operatiivtoetuse ja edasise arengu perspektiivi seisukohalt, otsustasime m\u00f5elda, kus veel v\u00f5iks seda arendust rakendada.<\/p>\n

<\/p>\n

Kui v\u00f5tta kohe, siis andmete skoorimine programmide jaoks nagu \u201eMaksa, kui mugav\u201d (laadime C* teavet, arvutame Sparkis), kaebuste arvestamine suunade kaupa ning rollide s\u00e4ilitamine ja \u00f5iguste ligikaudu arvutamine rollimaatriksis. <\/p>\n

<\/p>\n

Nagu n\u00e4eme, on repertuaar lai ja mitmekesine. Ja kui valida NoSQL pooldajate\/vastaste leer, siis liitume pooldajatega, sest oleme saanud oma eelised, just seal, kus ootasime.<\/p>\n

<\/p>\n

Isegi Cassandra v\u00e4ljaanne pakub v\u00f5imalust horisontaalseks skaleerimiseks reaalajas, t\u00e4iesti valutult lahendades andmete suurenemise k\u00fcsimuse s\u00fcsteemis. Meil \u00f5nnestus v\u00e4lja tuua eraldi kontuur v\u00e4ga suure koormusega mehhanism k\u00f5nede kokkuv\u00f5tete arvutamiseks ning eraldada rakenduse skeem ja loogika, vabanedes kohutavast praktikast kohandatud t\u00f6\u00f6de ja objektide kirjutamisel ise andmebaasis. Saime v\u00f5imaluse valida ja seadistada, et kiirendada, millistes andmekeskustes teeme arvutusi ja millistes kirjutame andmeid, valmistades end ette eraldiseisvate s\u00f5lmede ja ka \u00fcldiselt andmekeskuste kukkumiste korral.<\/p>\n

<\/p>\n

Kasutades meie arhitektuuri uutes projektides ning olles juba kogunud natuke kogemusi, tahaks kohe arvestada eespool nimetud n\u00fcanssidega ja v\u00e4ltida teatud vigu, siluda teravaid nurki, mida alguses ei \u00f5nnestunud v\u00e4ltida.<\/p>\n

<\/p>\n

N\u00e4iteks, \u00f5igeaegselt j\u00e4lgida Kassandra v\u00e4rskendusi<\/b>, kuna paljud probleemid, millega me silmitsi seisame, olid juba tuntud ja parandatud.<\/p>\n

<\/p>\n

Mitte paigutada andmebaasi ja Spark'i samadele nodidele<\/b> (v\u00f5i rangelt jagada lubatud ressursside kasutamise j\u00e4rgi), kuna Spark v\u00f5ib tarbida rohkem RAM-i, kui on lubatud, ja me saame kiiresti probleemi number 1 meie nimekirjast.<\/p>\n

<\/p>\n

Parandada j\u00e4lgimist ja operatiivsete oskuste taset juba projekti testimise etapis. <\/b>Alguses arvestada maksimaalselt k\u00f5iki meie lahenduse potentsiaalseid kasutajaid<\/b>, kuna just sellest s\u00f5ltub l\u00f5puks andmebaasi struktuur.<\/p>\n

<\/p>\n

M\u00f5ningaid kordi uurida saadud skeemi v\u00f5imaliku optimeerimise osas. M\u00e4\u00e4rata, milliseid v\u00e4lju saab serialiseerida. M\u00f5ista, milliseid lisalaudu me peame tegema, et k\u00f5ige korrektsemalt ja optimaalsemalt arvestada ning hiljem n\u00f5udmise korral vajalikku teavet edastada (n\u00e4iteks eeldades, et samu andmeid saame hoida erinevates tabelites, arvestades erinevat jagunemist erinevate kriteeriumite j\u00e4rgi, saame m\u00e4rgatavalt s\u00e4\u00e4sta protsessoriaega lugemisp\u00e4ringute puhul).<\/p>\n

<\/p>\n

Kena kohe planeerida TTL-i rakendamine ja aegunud andmete puhastamine.<\/b><\/p>\n

<\/p>\n

Kassandra's andmete eksportimisel rakenduse loogika peaks t\u00f6\u00f6tama FETCH-i printsiibil, et mitte laadida k\u00f5iki ridu m\u00e4llu korraga, vaid valida partii kaupa.<\/b><\/p>\n

<\/p>\n

Soovitatav on enne projekti \u00fcleminekut kirjeldatud lahendusele kontrollida s\u00fcsteemi t\u00f5rketaluvust, viies l\u00e4bi madalatest testidest<\/b>, nagu andmete kadumine \u00fches andmekeskuses, rikutud andmete taastamine mingi perioodi jooksul, v\u00f5rgu langused andmekeskuste vahel. Sellised testid mitte ainult ei v\u00f5imalda hinnata pakutava arhitektuuri plusse ja miinuseid, vaid annavad ka head harjutuspraktikat neile inseneridele, kes neid l\u00e4bi viivad, ning omandatud oskus ei ole sugugi \u00fcleliigne, kui s\u00fcsteemide t\u00f5rked korduvad tootmises.<\/p>\n

<\/p>\n

Kui t\u00f6\u00f6tame olulise teabe, nagu n\u00e4iteks arveldamiseks vajalikud andmed ja tellija v\u00f5lgade arvestus, kallal, tasub p\u00f6\u00f6rata t\u00e4helepanu ka t\u00f6\u00f6riistadele, mis aitavad v\u00e4hendada andmebaasi erip\u00e4ra t\u00f5ttu tekkivaid riske. N\u00e4iteks v\u00f5iks kasutada nodesync utiliiti (Datastax) ning v\u00e4lja t\u00f6\u00f6tada selle efektiivseks kasutamiseks optimaalse strateegia, et konsistentsuse nimel mitte tekitada \u00fcleliigset koormust Cassandrale<\/b> ja kasutada seda vaid teatud tabelite puhul teatud ajavahemikel.<\/p>\n

<\/p>\n

Noh, p\u00e4rast poolteist aastat elamist Cassandra k\u00f5rval? Kokkuv\u00f5ttes pole lahendamata probleeme. Suuri krahhe ja andmete kaotust me samuti ei lubanud. Jah, tuli m\u00f5elda, kuidas kompenseerida m\u00f5ningaid varem esialgu mitte esinenud probleeme, kuid l\u00f5puks ei varjutanud see oluliselt meie arhitektuurilahendust. Kui soovite ja ei karda proovida midagi uut, ja samal ajal ei taha t\u00f5siselt pettuda, valmistuge selleks, et tasuta ei juhtu midagi. Peate rohkem tegelema, tutvuma dokumentatsiooniga ja leidma oma individuaalsed mured, kui vanas legacy lahenduses, ning \u00fckski teooria ei \u00fctle ette, millised mured just teid ootavad.<\/p>\n

Allikas: 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\udd47Kuidas vaadata Cassandra silma ja samal ajal mitte kaotada andmeid, stabiilsust ja usku NoSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/et\/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":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/37585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=37585"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/37585\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/28210"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=37585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=37585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=37585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}