Kuidas vaadata Kassandrale silma ja mitte kaotada andmeid, stabiilsust ja usku NoSQL-i?

Öeldakse, et elus tasub kõike vähemalt kord proovida. Ja kui olete harjunud töötama relationaalsete andmebaasidega, siis on NoSQL-ga tutvumine alguses vähemalt üldiseks arenduseks vajalik. Praegu on selle tehnoloogia kiire arengu tõttu palju vastuolulisi arvamusi ja kuumi vaidlusi, mis toidavad huvi.
Kui süübida sellesse, siis võib näha, et vaidlused tekivad vale lähenemise tõttu. Need, kes kasutavad NoSQL andmebaase just seal, kus need on vajalikud, on rahul ja saavad selle lahenduse kõik plussid. Eksperimenteerijad, kes loodavad sellele tehnoloogiale imerohuna seal, kus see ei ole üldse rakendatav, kogevad pettumust, kaotades relationaalsete andmebaaside tugevused ilma olulisi eeliseid omandamata.

Räägin oma kogemusest lahenduse juurutamise osas, mis põhineb Cassandra andmebaasil: millega tuli silmitsi seista, kuidas keerulistes olukordades välja pääsesime, kas suutsime NoSQL kasutamisest kasu saada ja kuhu tuli lisada täiendavaid jõupingutusi/rahakulu.
Algne ülesanne oli luua süsteem, mis salvestab kõnesid mingisse salvestisse.

Süsteemi tööpõhimõte on järgmine. Sissetulevad failid sisaldavad teatud struktuuri, mis kirjeldab kõne struktuuri. Seejärel tagab rakendus selle struktuuri salvestamise vastavatesse veergudesse. Edasi salvestatud kõnesid kasutatakse – näiteks teabe kuvamiseks liiklustarbimise kohta abonentidele (tasud, kõned, saldo ajalugu).

Miks Cassandra valiti, on täiesti arusaadav – see kirjutab nagu kuulipildur, on lihtsalt skaleeritav ja talub rikkeid.

Nii et siin on see, mida kogemus meile andis

Jah, välja kukkunud sõlm ei ole tragöödia. See ongi Cassandra rikkeitaluvuse mõte. Aga sõlm võib olla elus, kuid sellegipoolest alandada oma jõudlust.. Nagu selgus, mõjutab see kohe kogu klastrite tootlikkust.

Cassandra ei kaitse seal, kus Oracle päästis oma piirangutega.. Ja kui rakenduse autor ei saanud sellest eelnevalt aru, siis jõudnud duubel Cassandra jaoks ei ole sugugi halvem originaalist. Kui tuli, siis paneme selle sisse.

Tasuta Cassandra „karbist väljas“ ei meeldinud Infotehnoloogiale: kasutajate tegevuse logimist ei ole, samuti ei ole õiguste piiramist.Kutsedega seotud teave kuulub isikuandmete hulka, mis tähendab, et kõik katsed selle taotlemiseks või muutmiseks peavad olema logitud võimalusega hilisema kontrolli jaoks. Samuti tuleb teadvustada vajadust jagada õigusi erinevatele tasanditele erinevate kasutajate jaoks. Lihtne tegevinsener ja superadmin, kes võib vabalt kustutada kogu keyspace'i – need on erinevad rollid, erinevad vastutused, erinevad kompetentsid. Ilma sellise ligipääsuõiguste eristamiseta seaduse ja andmete väärtus ning terviklikkus hakkavad kiiremini kahtluse alla minema kui ANY konsistentsitasemel.

Me ei arvestanud, et kõnede osas on vajalik nii tõsine analüüs kui ka perioodilised valikud väga erinevate tingimuste alusel. Kuna valitud kirjed tuleks hiljem eemaldada ja üle kirjutada (ülesande raames peame toetama andmete ajakohastamise protsessi algselt valeandmete saamise korral), ei sobi Cassandra meile siinkohal. Cassandra nagu seif – sinna on mugav asju panna, kuid seal ei saa hästi lugeda.

Oleme silmitsi seisnud andmete edastamise probleemiga testimisaladesse. (5 node'i testis vs 20 tootmises). Sel juhul ei saa dump'i kasutada.

Probleem rakenduse andmeskeemide värskendamisel, mis kirjutab Cassandrasse. Tagasivõtmine genereerib suure hulga mälestustahvleid, mis võib ettearvamatul viisil meie jõudlust mõjutada.Cassandra on optimeeritud kirjutamiseks ja enne kirjutamist ei mõtle ta palju. Iga olemasolevate andmete toiming on samuti kirjutamine. St, kustutades üleliigset, genereerime me lihtsalt veelgi rohkem kirjeid, millest ainult osa on tähistatud mälestustahvlitega.

Aegumised sisestamisel. Cassandra on kirjutamisel suurepärane, kuid mõnikord võib sissetulev voog seda tõsiselt segadusse ajada.See juhtub siis, kui rakendus hakkab ringi jooksma mitmete kirjetega, mida ei õnnestu mingil põhjusel sisestada. Ja meil on vaja tõelist DBA, kes jälgib gc.log, system ja debug logisid aeglaste päringute osas ning compaction pending'i mõõdikuid.

Mitu andmekeskust klastris. Kust lugeda ja kuhu kirjutada?
Kas on võimalik eraldada lugemis- ja kirjutamisprotsessid? Ja kui jah, siis peaks DC olema lähemal rakendusele kirjutamiseks või lugemiseks? Ja kas meil ei esine tõelist split brain'i, kui valime vale järjepidevuse tasandi? Täiesti palju küsimusi, palju uurimata seadeid ja võimalusi, mida tahaks proovida.

Kuidas me probleemi lahendasime

Kuna node'i jõudlus langes, lülitasime SWAPi välja. Nüüd, kui mälu on puudus, peaks node kokku kukkuma, mitte tekitama suuri gc pause.

Nii et me ei looda enam andmebaasi loogikale. Rakenduse arendajad õpivad ümber ja hakkavad aktiivselt enda koodis tagama. Ideaalne selge andmete salvestamise ja töötlemise jaotus.

Ostsime DataStaxi tuge. Karu pakendatud Cassandra arendamine on lõpetatud (viimane commit veebruaris 2018). Samas pakub Datastax suurepärast teenust ja palju täiustatud lahendusi, mis on kohandatud olemasolevatele infosüsteemidele.

Tahaksin veel märkida, et Cassandra ei ole väga mugav päringute tegemiseks. Loomulikult on CQL suur samm kasutajate suunas (võrreldes Thriftiga). Kuid kui teil on terved osakonnad, kes on harjunud selliste mugavate liitmisvõimalustega, vabade filtritega igasuguste väljade järgi ja päringute optimeerimise võimalustega, ning need osakonnad töötavad 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älja võtta.

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ügavus peretransformeerimise juhtumite jaoks). Siin nägin kohe järgmist probleemi: kui kirjutada sünkroonselt, kaotame kõik C*-ga seotud kiirused, kui asünkroonselt – pole garantiid, et kõik vajalikud kutsed üldse Oracle'i jõuavad. Üks suur pluss oli: töös jääb kasutusele tuttav PL/SQL Developer, see tähendab, et saame praktiliselt rakendada „Fassaadi“ 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üüsime, imetleme). Miinused: protsess osutub üsna mitmeastmeliseks ning lisaks puudub töötajatele kasutajaliides.

Kokkuvõttes jääme siiski teise variandi juurde. Erinevate purkide valikute jaoks kasutasime Apache Spark'i. Mehhanismi sisu kujunes Java-koodiks, mis määratletud võtmete (tellija, kõne toimumise aeg – sektsiooni võtmed) alusel toob andmed C*-st ning samuti vajalikud andmed rikastamiseks mistahes teisest andmebaasist. Pärast seda liidab need enda mällu ja kuvab tulemuse tulemuste tabelisse. Sparki peal joonistasime veebiliidese ja see osutus täiesti kasutatavaks.

Andmete uuendamise ülesande lahendamisel vaadati taas mitmeid lahendusviise. Nii Sstloaderi kaudu edasiviimise kui ka testimisalase klusteri jagamise variant, mis jaguneb kaheks osaks, millest kumbki siseneb vaheldumisi ühte klastrisse tootmisandmete jaoks, toites end seeläbi ära. Uuendamise käigus plaaniti nende vahetamist: osa, mis töötas testis, puhastatakse ja sisenetakse tootmisse, samas kui teine osa hakkab andmetega eraldi töötama. Siiski, peale veelkordset läbi mõtlemist hindasime ratsionaalsemalt, millised andmed väärivad edasiviimist ja mõistsime, et iseäranis on kutsed – testide jaoks konsistentsuseta entiteet, mis genereeritakse kiiresti vajadusel, ning tootmisandmete komplekt ei oma väärtust edasiviimiseks testides. On mitmeid kogumisobjekte, mida oleks mõistlik edastada, kuid see on sõna otseses mõttes paar tabelit, mis ei ole liiga rasked. Seetõttu tuli taas lahenduseks Spark, mille abil kirjutasime ja hakkasime aktiivselt kasutama andmete edastusskripti tabelite vahel tootmiste ja testide vahel.

Meie praegune juurutamise poliitika võimaldab meil töötada ilma tagasikeeramiseta. Enne tootmist toimub kohustuslik katsetus, kus viga ei ole nii kallis. Ebaõnne korral saab alati kaotada kiirusruumi ja taastada kogu skeemi algusest peale.

Kassandras pideva kättesaadavuse tagamiseks on vajalik DBA ja mitte ainult tema. Kõik, kes rakendusega töötavad, peavad mõistma, kus ja kuidas vaadata praegust olukorda ning kuidas aegsasti probleeme diagnoosida. Selleks kasutame aktiivselt DataStax OpsCenterit (töökoormuse haldamine ja jälgimine), Cassandra Driveri süsteemseid mõõdikuid (C* kirjutamise ajakulumiste arv, C* lugemise ajakulumiste arv, maksimaalne latentsus jne), jälgime ise rakenduse tööd, mis toimib koos Kassandraga.

Kui mõtlesime eelnevale küsimusele, sai selgeks, kus võib peituda põhirisk. Need on andmete kuvamisvormid, mis tõmbavad andmeid mitmest omavahel sõltumatust päringust andmehoidlas. Nii võime saada üsna ebajärjekindlat teavet. Kuid see probleem oleks sama aktuaalne ka siis, kui töötaksime ainult ühe andmekeskusega. Seega on mõistlikim siin luua andmete lugemise partii funktsioon kolmandas rakenduses, mis tagab andmete saamise ühes ajavahemikus. Mis puudutab lugemise ja kirjutamise eristamist tootlikkuse osas, siis takistas meid risk, et teatud ühenduse katkemisel andmekeskuste vahel võime saada kaks omavahel täiesti ebajärjekindlat klastrit.

Kokkuvõttes, hetkel otsustasime, et kirje jaoks on järjepidevuse tase EACH_QUORUM, lugemise jaoks – LOCAL_QUORUM

Küsimuste lühikesed muljed ja järeldused

Et hinnata saadud lahendust operatiivtoetuse ja edasise arengu perspektiivi seisukohalt, otsustasime mõelda, kus veel võiks seda arendust rakendada.

Kui võtta kohe, siis andmete skoorimine programmide jaoks nagu „Maksa, kui mugav” (laadime C* teavet, arvutame Sparkis), kaebuste arvestamine suunade kaupa ning rollide säilitamine ja õiguste ligikaudu arvutamine rollimaatriksis.

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

Isegi Cassandra väljaanne pakub võimalust horisontaalseks skaleerimiseks reaalajas, täiesti valutult lahendades andmete suurenemise küsimuse süsteemis. Meil õnnestus välja tuua eraldi kontuur väga suure koormusega mehhanism kõnede kokkuvõtete arvutamiseks ning eraldada rakenduse skeem ja loogika, vabanedes kohutavast praktikast kohandatud tööde ja objektide kirjutamisel ise andmebaasis. Saime võimaluse valida ja seadistada, et kiirendada, millistes andmekeskustes teeme arvutusi ja millistes kirjutame andmeid, valmistades end ette eraldiseisvate sõlmede ja ka üldiselt andmekeskuste kukkumiste korral.

Kasutades meie arhitektuuri uutes projektides ning olles juba kogunud natuke kogemusi, tahaks kohe arvestada eespool nimetud nüanssidega ja vältida teatud vigu, siluda teravaid nurki, mida alguses ei õnnestunud vältida.

Näiteks, õigeaegselt jälgida Kassandra värskendusi, kuna paljud probleemid, millega me silmitsi seisame, olid juba tuntud ja parandatud.

Mitte paigutada andmebaasi ja Spark'i samadele nodidele (või rangelt jagada lubatud ressursside kasutamise järgi), kuna Spark võib tarbida rohkem RAM-i, kui on lubatud, ja me saame kiiresti probleemi number 1 meie nimekirjast.

Parandada jälgimist ja operatiivsete oskuste taset juba projekti testimise etapis. Alguses arvestada maksimaalselt kõiki meie lahenduse potentsiaalseid kasutajaid, kuna just sellest sõltub lõpuks andmebaasi struktuur.

Mõningaid kordi uurida saadud skeemi võimaliku optimeerimise osas. Määrata, milliseid välju saab serialiseerida. Mõista, milliseid lisalaudu me peame tegema, et kõige korrektsemalt ja optimaalsemalt arvestada ning hiljem nõudmise korral vajalikku teavet edastada (näiteks eeldades, et samu andmeid saame hoida erinevates tabelites, arvestades erinevat jagunemist erinevate kriteeriumite järgi, saame märgatavalt säästa protsessoriaega lugemispäringute puhul).

Kena kohe planeerida TTL-i rakendamine ja aegunud andmete puhastamine.

Kassandra's andmete eksportimisel rakenduse loogika peaks töötama FETCH-i printsiibil, et mitte laadida kõiki ridu mällu korraga, vaid valida partii kaupa.

Soovitatav on enne projekti üleminekut kirjeldatud lahendusele kontrollida süsteemi tõrketaluvust, viies läbi madalatest testidest, nagu andmete kadumine ühes andmekeskuses, rikutud andmete taastamine mingi perioodi jooksul, võrgu langused andmekeskuste vahel. Sellised testid mitte ainult ei võimalda hinnata pakutava arhitektuuri plusse ja miinuseid, vaid annavad ka head harjutuspraktikat neile inseneridele, kes neid läbi viivad, ning omandatud oskus ei ole sugugi üleliigne, kui süsteemide tõrked korduvad tootmises.

Kui töötame olulise teabe, nagu näiteks arveldamiseks vajalikud andmed ja tellija võlgade arvestus, kallal, tasub pöörata tähelepanu ka tööriistadele, mis aitavad vähendada andmebaasi eripära tõttu tekkivaid riske. Näiteks võiks kasutada nodesync utiliiti (Datastax) ning välja töötada selle efektiivseks kasutamiseks optimaalse strateegia, et konsistentsuse nimel mitte tekitada üleliigset koormust Cassandrale ja kasutada seda vaid teatud tabelite puhul teatud ajavahemikel.

Noh, pärast poolteist aastat elamist Cassandra kõrval? Kokkuvõttes pole lahendamata probleeme. Suuri krahhe ja andmete kaotust me samuti ei lubanud. Jah, tuli mõelda, kuidas kompenseerida mõningaid varem esialgu mitte esinenud probleeme, kuid lõpuks ei varjutanud see oluliselt meie arhitektuurilahendust. Kui soovite ja ei karda proovida midagi uut, ja samal ajal ei taha tõsiselt pettuda, valmistuge selleks, et tasuta ei juhtu midagi. Peate rohkem tegelema, tutvuma dokumentatsiooniga ja leidma oma individuaalsed mured, kui vanas legacy lahenduses, ning ükski teooria ei ütle ette, millised mured just teid ootavad.

Allikas: habr.com