{"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 vaatama Kassandra silmadesse ja samal ajal andmeid, stabiilsust ja usku NoSQL-i mitte kaotada","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

R\u00e4\u00e4gitakse, et elus tasub proovida k\u00f5ike v\u00e4hemalt korra. Ja kui olete harjunud t\u00f6\u00f6tama relationaalsete andmebaasidega, siis tasub NoSQL-iga praktikas tutvuda, v\u00e4hemalt \u00fcldiseks arendamiseks. Praegu, t\u00e4nu selle tehnoloogia kiirele arengule, on palju vastuolulisi arvamusi ja teravaid arutelusid, mis ainult suurendavad huvi.
\nKui s\u00fcveneda nende arutelude tuumasse, saab n\u00e4ha, et need tulenevad vale l\u00e4henemisviisist. Need, kes kasutavad NoSQL-andmebaase seal, kus need on vajalikud, on rahul ja saavad sellest lahendusest k\u00f5ik selle eelised. Kuid eksperimenteerijad, kes loodavad sellele tehnoloogiale ligip\u00e4\u00e4setavuse nimel seal, kus see ei ole sobiv, tunnevad pettumust, kaotades relationaalsete andmebaaside tugevused ilma oluliste kasudeta.<\/p>\n

<\/p>\n

R\u00e4\u00e4gin meie kogemustest lahenduse rakendamisel, mis p\u00f5hineb Cassandra andmebaasil: millega pidime silmitsi seisma, kuidas me raskest olukorrast v\u00e4lja tulime, kas suutsime NoSQL-i kasutamisest kasu saada ja kus pidime lisama t\u00e4iendavaid pingutusi\/vahendeid.
\nAlgne \u00fclesanne on ehitada s\u00fcsteem, mis salvestab k\u00f5nesid mingi salvestusruumi.<\/p>\n

<\/p>\n

S\u00fcsteemi t\u00f6\u00f6p\u00f5him\u00f5te on j\u00e4rgmine. Sissetulevad failid vastavad kindlale struktuurile, mis kirjeldab kutse struktuuri. Seej\u00e4rel tagab rakendus, et see struktuur salvestatakse vastavatesse veergudesse. Hiljem salvestatud kutseid kasutatakse \u2013 teabe kuvamiseks kasutajate andmeside tarbimise kohta (arveldused, k\u00f5ned, saldo ajalugu).<\/p>\n

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

Miks Cassandra on valitud, on t\u00e4iesti arusaadav \u2014 see kirjutab nagu kuulipilduja, on kergesti skaleeritav ja t\u00f5rkeotsustav.<\/p>\n

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

Nii et siin on, mida me kogemuselt saime<\/h2>\n

<\/p>\n

Jah, v\u00e4lja kukkunud s\u00f5lme ei ole trag\u00f6\u00f6dia. See ongi Cassandra t\u00f5rketaluvuse olemus. Kuid s\u00f5lm v\u00f5ib olla aktiivne ja samas j\u00f5udluses madalseisus<\/b>. Selgub, et see peegeldub kohe kogu klastrite j\u00f5udlusele.<\/p>\n

<\/p>\n

Cassandra ei kaitse seal, kus Oracle p\u00e4\u00e4stis oma piirangutega<\/b>. Ja kui rakenduse autor ei saanud seda ette, siis Cassandra jaoks saabunud duplikaat ei ole sugugi halvem originaalist. Kui see on saabunud, siis lisame selle.<\/p>\n

<\/p>\n

Tasuta Cassandra \"v\u00e4lja kastist\" ei meeldinud turvaekspertidele: kasutajate tegevuste logimist pole, \u00f5iguste piiramist samuti ei ole.<\/b>. \u00dchendusandmete info kuulub isikuandmete alla, seega k\u00f5ik katsed seda mingil viisil k\u00fcsida v\u00f5i muuta peavad olema logitud koos v\u00f5imalusega hilisemaks auditiks. Samuti tuleb m\u00f5ista vajadust erinevate tasemete \u00f5iguste eraldamiseks erinevatele kasutajatele. Tavaline opereeriv insener ja superadmin, kes v\u00f5ib vabalt kustutada kogu keyspace'i \u2013 need on erinevad rollid, erinev vastutus ja p\u00e4devus. Ilma selliste \u00f5iguste eristamiseta kahtluse alla, kas andmete v\u00e4\u00e4rtus ja terviklikkus p\u00fcsivad, t\u00f5useb kiiremini, kui konsistentsi tase ANY. <\/p>\n

<\/p>\n

Me ei arvestanud, et k\u00f5nede kohta on vajalik nii t\u00f5sine anal\u00fc\u00fcs kui ka perioodilised valikud v\u00e4ga erinevate tingimuste j\u00e4rgi. Kuna valitud kirjed on p\u00e4rast m\u00f5eldud kustutamiseks ja \u00fcle kirjutamiseks (me peame toetama andmete v\u00e4rskendamise protsessi valeandmete esialgsete sissevoolude korral), ei ole Cassandra siin meie s\u00f5ber. Cassandra on nagu kogumise konteiner \u2013 sinna on mugav asju panna, kuid seal ei saa tulemusi arvutada.<\/b><\/p>\n

<\/p>\n

Oleme silmitsi seisnud probleemiga andmete edastamisel testimisaladesse.<\/b> (5 s\u00f5lme testis versus 20 tootmises). Sellisel juhul ei saa dump'i kasutada.<\/p>\n

<\/p>\n

Probleem rakenduse andmebaasi skeemi uuendustega, mis kirjutab Cassandra'sse. Tagasiv\u00f5tt v\u00f5ib genereerida hulga hauakive, mis v\u00f5ib ettearvamatult meie j\u00f5udlust m\u00f5jutada.<\/b>Cassandra on kirjutamiseks optimeeritud, ja enne kirjutamist ei m\u00f5tle ta palju. Iga olemasolevate andmete operatsioon on samuti kirjutamine. Ehkki kustutades \u00fcleliigseid andmeid, genereerime me lihtsalt veelgi rohkem kirjeid ning ainult osa neist j\u00e4\u00e4b hauakividena.<\/p>\n

<\/p>\n

Sisestamise aegumine. Cassandra on kirjutamisel suurep\u00e4rane, kuid m\u00f5nikord v\u00f5ib sisenev voog teda oluliselt segadusse ajada.<\/b>See juhtub siis, kui rakendus hakkab mitmeid kirjeid ringlusse saatma, mida ei \u00f5nnestu mingil p\u00f5hjusel sisestada. Ja meil on t\u00f5eliselt vajalik DBA, kes j\u00e4lgib gc.log'i, s\u00fcsteemi logisid ja debug logisid aeglase p\u00e4ringu korral, kompaktimise ootel olevate m\u00f5\u00f5dikute osas.\n<\/p>\n

<\/p>\n

Mitmed andmekeskused klastris. Kust lugeda ja kuhu kirjutada?<\/b>
\nKas on v\u00f5imalik jagada lugemiseks ja kirjutamiseks? Ja kui jah, siis peaks DC olema kirjutamiseks v\u00f5i lugemiseks l\u00e4hemal rakendusele? Kas ei teki meil t\u00f5elist split brain'i, kui valime vale koosk\u00f5lastamisastme? Palju k\u00fcsimusi, palju avastamata seadistusi ja v\u00f5imalusi, millega nii tahaks m\u00e4ngida.\n<\/p>\n

<\/p>\n

Kuidas me lahendasime<\/h2>\n

<\/p>\n

Et node ei langeks, l\u00fclitasime SWAP'i v\u00e4lja<\/b>. Ja n\u00fc\u00fcd, kui m\u00e4lu on v\u00e4he, peaks node kokku kukkuma, mitte et tekitama suuri gc pause.<\/p>\n

<\/p>\n

Nii et me ei looda enam SQL loogikale. Rakenduse arendajad \u00f5pivad \u00fcmber ja hakkavad oma koodis aktiivselt ennast kindlustama.<\/b> Ideaalne selge andmete salvestamise ja t\u00f6\u00f6tlemise lahknevus.<\/p>\n

<\/p>\n

Ostsid tuge DataStaxilt.<\/b> Kastist v\u00e4ljaspool Cassandra on arendamine l\u00f5petatud (viimane commit veebruaris 2018). Samas pakub Datastax suurep\u00e4rast teenust ja rohkesti t\u00e4iustatud ning olemasolevatele IS-dele kohandatud lahendusi.<\/p>\n

<\/p>\n

Tahan veel m\u00e4rkida, et Cassandra ei ole liiga mugav p\u00e4ringute jaoks. Loomulikult on CQL suur samm kasutajate suunas (v\u00f5rreldes Triftiga). Kuid kui teil on tervet osakonda, mis on harjunud mugavate join'idega, vaba filtreerimisega igasuguste v\u00e4ljade j\u00e4rgi ja p\u00e4ringu optimeerimise v\u00f5imalustega, ning need osakonnad tegelevad v\u00e4idete ja avariide lahendamisega, siis tundub neile otsus liikuda Cassandra peale vaenulik ja rumal. Oleme hakanud arutama, kuidas meie kolleege aitada andmete valimisega. <\/p>\n

<\/p>\n

Kaalusime kahte varianti. Esimeses variandis kirjutame kutsed mitte ainult C*-sse, vaid ka arhiivi Oracle andmebaasi. Erinevalt C*-st salvestatakse aga selles andmebaasis kutsed vaid jooksva kuu jooksul (piisav salvestus s\u00fcgavus peretiifimise juhtumite jaoks). Siin ilmus kohe j\u00e4rgmine probleem: kui kirjutada s\u00fcnkroonselt, siis kaotame k\u00f5ik C*-ga seotud eelised, mis tulenevad kiirest sisestamisest; kui as\u00fcnkroonselt, siis ei ole kindel, et k\u00f5ik vajalikud kutsed j\u00f5uavad Oracle'i. \u00dcks pluss siiski oli, aga suur: t\u00f6\u00f6ks j\u00e4\u00e4b endiselt tuttav PL\/SQL Developer, st me saame praktiliselt rakendada \u201eFassaadi\u201d mustrit. Alternatiivne variant. Rakendame mehhanismi, mis v\u00e4ljendab kutsed C*-st, t\u00f5mbab teatud andmeid rikastamiseks vastavatest tabelitest Oracle'is, \u00fchendab saadud valikud ja esitab meile saavutatud tulemuse, mida me hiljem mingil moel kasutame (tagasi kerime, kordame, anal\u00fc\u00fcsime, imetleme). Miinused: protsess on \u00fcsna mitmeastmeline ja peale selle puudub t\u00f6\u00f6tajatele kasutajaliides.<\/p>\n

<\/p>\n

L\u00f5puks j\u00e4\u00e4me siiski teise variandi juurde. Erinevate pankade valikute jaoks kasutasime Apache Spark.<\/b> Mehhanismi sisu tuleneb Java-koodist, mis vastavalt m\u00e4\u00e4ratud v\u00f5tmetele (tellija, k\u00f5ne toimumise aeg \u2013 jaotuse v\u00f5tmed) v\u00f5tab andmed C*-st, samuti vajalikud andmed rikastamiseks mistahes muust andmebaasist. P\u00e4rast seda liitub nende andmed oma m\u00e4llu ja kuvab tulemuse tulemustabelisse. Sparkile joonistati veebiliides ja see osutus t\u00e4iesti kasutamiseks sobivaks.<\/p>\n

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

Andmete uuendamise \u00fclesande lahendamisel vaatasime taas \u00fcle mitu v\u00f5imalust. Nii Sstloaderi kaudu edastamine kui ka katsetsoonis klastrite jagamine kaheks osaks, millest iga\u00fcks vaheldumisi \u00fchendub tootmisklastriga, saades seel\u00e4bi toite. Testimise k\u00e4igus oli plaanis neid omavahel vahetada: see osa, mis t\u00f6\u00f6tas testis, puhastatakse ja viiakse tootmisesse, samas kui teine hakkab t\u00f6\u00f6tama andmetega eraldi. Ent p\u00e4rast uuesti kaalumist hindasime ratsionaalsemalt, milliseid andmeid tasub \u00fcle kanda, ja m\u00f5istsime, et kutsete iseenesest m\u00f5istetav olemus testides, mis genereeritakse kiiresti vajaduse korral, ja tootmisandmestiku komplekt ei oma v\u00e4\u00e4rtust testimisse edastamiseks. On mitmeid kogumisohtlikke objekte, mida tasub \u00fcle kanda, kuid need on vaid m\u00f5ned tabelid, mis ei ole v\u00e4ga suured. Seet\u00f5ttu tuli lahendusena taas appi Spark, mille abil kirjutasime ja hakkasime aktiivselt kasutama andmete \u00fclekandmise skripti tabelite vahel tootmisest testimiseks.<\/b><\/p>\n

<\/p>\n

Meie praegune juurutamispoliitika v\u00f5imaldab meil t\u00f6\u00f6tada ilma tagasiv\u00f5tmisteta.<\/b> Enne reklaami algust toimub kohustuslik testimine, kus vead ei ole nii kulukad. Eba\u00f5nnestumise korral on alati v\u00f5imalik kukutada juhtumiruumi ja alustada kogu skeemi uuesti.<\/p>\n

<\/p>\n

Kassandri pideva k\u00e4ttesaadavuse tagamiseks on vajalik andmebaasi administreerimine ja mitte ainult see. Kogu rakendusega t\u00f6\u00f6tav personal peab m\u00f5istma, kus ja kuidas j\u00e4lgida praegust olukorda ning kuidas probleemide \u00f5igeaegse diagnoosimise l\u00e4bi viia.<\/b> Selleks kasutame aktiivselt DataStax OpsCenterit (t\u00f6\u00f6koormuse haldamine ja j\u00e4lgimine), Cassandra Driveri s\u00fcsteemimetriikat (C* kirjutamise ajav\u00e4ljaj\u00e4tmiste arv, C* lugemise ajav\u00e4ljaj\u00e4tmiste arv, maksimaalne latentsus jne), ning j\u00e4lgime rakenduse t\u00f6\u00f6d, mis suhtleb Kassandraga.\n<\/p>\n

<\/p>\n

Kuna m\u00f5tleme eelnevale k\u00fcsimusele, saame aru, kus v\u00f5ib peituda peamine risk. See on andmete kuvamise vormid, mis t\u00f5ukuvad mitmest omavahel s\u00f5ltumatust p\u00e4ringust salvestusele. Seega v\u00f5ime saada \u00fcsna eba\u00fchtlast teavet. Kuid see probleem oleks samuti aktuaalne, isegi kui t\u00f6\u00f6taksime ainult \u00fche andmekeskusega. Seega on k\u00f5ige m\u00f5istlikum koostada batch-funktsioon andmete lugemiseks v\u00e4lises rakenduses, mis tagab andmete saamise \u00fchtlasel ajaperioodil. Mis puutub lugemise ja kirjutamise eraldamisse j\u00f5udluse aspektist, siis peatab meid risk, et andmekeskuste vaheline \u00fchenduse katkemise korral v\u00f5ime saada kaks omavahel t\u00e4iesti eba\u00fchtlast klastrit.<\/p>\n

<\/p>\n

Seet\u00f5ttu, hetkel otsustasime, et kirjutamise j\u00e4rjepidevuse tase on EACH_QUORUM, lugemise puhul \u2013 LOCAL_QUORUM<\/b><\/p>\n

<\/p>\n

L\u00fchikesed muljed ja j\u00e4reldused<\/h2>\n

<\/p>\n

Selleks, et hinnata saavutatud lahendust ekspluateerimise toetuse ja edasise arengu perspektiivi seisukohalt, otsustasime m\u00f5elda, kus veel saaks sellist arengut rakendada.<\/p>\n

<\/p>\n

Kui m\u00f5elda kiiresti, siis andmete skoorimine selliste programmide jaoks nagu \u00abMaksa, kui sobib\u00bb (laadime S* teavet, arvutamine Spark skriptide p\u00f5hjal), n\u00f5uete arvestus suunade kaupa, rollide s\u00e4ilitamine ja \u00f5iguste ligip\u00e4\u00e4su kasutajatele arvutamine rollide maatriksi j\u00e4rgi. <\/p>\n

<\/p>\n

Nagu n\u00e4eme, on repertuaar lai ja mitmekesine. Ja kui valida toetajate\/ vastaste laager NoSQL-i osas, siis liitume toetajatega, kuna oleme saanud oma eelised, just seal, kus ootasime.<\/p>\n

<\/p>\n

Ieven Kassandra kastist v\u00e4lja v\u00f5imaldab reaalajas horisontaalset skaleerimist, lahendades andmete suurendamise s\u00fcsteemis t\u00e4iesti probleemideta. Oleme suutnud viia eraldi kontuuris v\u00e4lja v\u00e4ga koormatud mehhanismi k\u00f5nede koguste arvutamiseks, samuti jagada rakenduse skeemi ja loogika, vabanedes pahest praktikast kirjutada kohandatud t\u00f6\u00f6lisi ja objekte andmebaasis. Oleme saanud valida ja seadistada, et kiirendamiseks m\u00e4\u00e4rata, millistes andmekeskustes arvutamine toimuda, ja millistes andmed salvestada, kaitstes end nii \u00fcksikute nodede kui ka kogu andmekeskuse t\u00f5rkeohtude eest.<\/p>\n

<\/p>\n

Uute projektide jaoks meie arhitektuuri rakendades, olles mingisuguse kogemuse juba omandanud, tahaksime kohe arvesse v\u00f5tta eespool kirjeldatud n\u00fcansse, et v\u00e4ltida teatud vigu ja siluda teravaid nurki, millest algselt ei saanud \u00fcle.<\/p>\n

<\/p>\n

N\u00e4iteks, aeg-ajalt j\u00e4lgida Kassandra uuendusi<\/b>, sest paljusid probleeme, millega me silmitsi seisame, on juba teada ja need on parandatud.<\/p>\n

<\/p>\n

\u00c4rge paigaldage nii andmebaasi kui ka Spark'i samadele nodedele<\/b> v\u00f5i piirake rangelt lubatud ressursside kasutamist, sest Spark v\u00f5ib kasutada rohkem m\u00e4lu, kui lubatud, ja me saame kiiresti esimese probleemi meie nimekirjas.<\/p>\n

<\/p>\n

Tugevdage j\u00e4lgimist ja k\u00e4itamise oskusi juba projekti testimise etapis. <\/b>Alates algusest arvestama maksimaalselt k\u00f5iki meie lahenduse v\u00f5imalikke tarbijaid<\/b>, sest just sellest s\u00f5ltub l\u00f5puks andmebaasi struktuur.<\/p>\n

<\/p>\n

M\u00f5elge korra veel saadud skeemi optimeerimise v\u00f5imalustele. T\u00f5stke esile, milliseid v\u00e4lju saab serialiseerida. Uuringu k\u00e4igus selgitage, milliseid t\u00e4iendavaid tabeleid on vaja luua, et k\u00f5ige t\u00e4psemalt ja optimaalsemalt andmeid arvesse v\u00f5tta ning seej\u00e4rel vastata soovitud teabega (n\u00e4iteks arvestades, et samu andmeid saame salvestada erinevates tabelites, arvestades erinevat jaotust erinevate kriteeriumide j\u00e4rgi, saame oluliselt s\u00e4\u00e4sta protsessori aega lugemisp\u00e4ringute korral).<\/p>\n

<\/p>\n

Hea kohe ette n\u00e4ha TTL-i m\u00e4\u00e4ramise ja aegunud andmete puhastamise.<\/b><\/p>\n

<\/p>\n

Andmete eksportimisel Kassandra-st rakenduse loogika peab toimima FETCH p\u00f5him\u00f5ttel, et mitte k\u00f5iki ridu korraga m\u00e4lu laadida, vaid valida need partiide kaupa.<\/b><\/p>\n

<\/p>\n

Soovitav on enne projekti \u00fcleviimist kirjeldatud lahendusele kontrollida s\u00fcsteemi katkestuskindlust, viies l\u00e4bi seeria krahhiteste.<\/b>, and possibly data loss in one data center, recovery of corrupted data over a certain period, network drops between data centers. Such tests will not only help assess the advantages and disadvantages of the proposed architecture but will also provide excellent practice for the engineers conducting them, and the skills acquired will prove valuable should system failures occur in production.<\/p>\n

<\/p>\n

If we are handling critical information (such as data for billing, calculating subscriber debts), we should also pay attention to tools that can help mitigate risks arising from the peculiarities of the DBMS. For instance, using the nodesync utility (Datastax), we can develop an optimal strategy for its usage to ensure consistency without creating excessive load on Cassandra<\/b> and use it only for specific tables during specific periods.<\/p>\n

<\/p>\n

Mis siis, kuue kuu jooksul koos Cassandra'ga? \u00dcldiselt pole lahendamata probleeme. T\u00f5siseid katkemisi ja andmekadu me samuti ei lubanud. Jah, tuli m\u00f5elda teatud varasemate probleemide kompenseerimisele, kuid l\u00f5ppkokkuv\u00f5ttes ei varjutanud see oluliselt meie arhitektuurilist lahendust. Kui soovite ja ei karda proovida midagi uut, ning samal ajal ei taha tugevalt pettuda, siis valmistuge selleks, et tasuta ei ole midagi. Te peate rohkem s\u00fcvenema dokumentatsiooni ja koguma oma individuaalsed augud kui vanas legacy lahenduses, ning miski teooria ei \u00fctle ette, millised augud 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 Cassandrale silma ja samal ajal mitte kaotada andmeid, stabiilsust ja usku NoSQL-i | 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}]}}