Kuidas vaatama Kassandra silmadesse ja samal ajal andmeid, stabiilsust ja usku NoSQL-i mitte kaotada

Räägitakse, et elus tasub proovida kõike vähemalt korra. Ja kui olete harjunud töötama relationaalsete andmebaasidega, siis tasub NoSQL-iga praktikas tutvuda, vähemalt üldiseks arendamiseks. Praegu, tänu selle tehnoloogia kiirele arengule, on palju vastuolulisi arvamusi ja teravaid arutelusid, mis ainult suurendavad huvi.
Kui süveneda nende arutelude tuumasse, saab näha, et need tulenevad vale lähenemisviisist. Need, kes kasutavad NoSQL-andmebaase seal, kus need on vajalikud, on rahul ja saavad sellest lahendusest kõik selle eelised. Kuid eksperimenteerijad, kes loodavad sellele tehnoloogiale ligipääsetavuse nimel seal, kus see ei ole sobiv, tunnevad pettumust, kaotades relationaalsete andmebaaside tugevused ilma oluliste kasudeta.

Räägin meie kogemustest lahenduse rakendamisel, mis põhineb Cassandra andmebaasil: millega pidime silmitsi seisma, kuidas me raskest olukorrast välja tulime, kas suutsime NoSQL-i kasutamisest kasu saada ja kus pidime lisama täiendavaid pingutusi/vahendeid.
Algne ülesanne on ehitada süsteem, mis salvestab kõnesid mingi salvestusruumi.

Süsteemi tööpõhimõte on järgmine. Sissetulevad failid vastavad kindlale struktuurile, mis kirjeldab kutse struktuuri. Seejärel tagab rakendus, et see struktuur salvestatakse vastavatesse veergudesse. Hiljem salvestatud kutseid kasutatakse – teabe kuvamiseks kasutajate andmeside tarbimise kohta (arveldused, kõned, saldo ajalugu).

Miks Cassandra on valitud, on täiesti arusaadav — see kirjutab nagu kuulipilduja, on kergesti skaleeritav ja tõrkeotsustav.

Nii et siin on, mida me kogemuselt saime

Jah, välja kukkunud sõlme ei ole tragöödia. See ongi Cassandra tõrketaluvuse olemus. Kuid sõlm võib olla aktiivne ja samas jõudluses madalseisus. Selgub, et see peegeldub kohe kogu klastrite jõudlusele.

Cassandra ei kaitse seal, kus Oracle päästis oma piirangutega. 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.

Tasuta Cassandra "välja kastist" ei meeldinud turvaekspertidele: kasutajate tegevuste logimist pole, õiguste piiramist samuti ei ole.. Ühendusandmete info kuulub isikuandmete alla, seega kõik katsed seda mingil viisil küsida või muuta peavad olema logitud koos võimalusega hilisemaks auditiks. Samuti tuleb mõista vajadust erinevate tasemete õiguste eraldamiseks erinevatele kasutajatele. Tavaline opereeriv insener ja superadmin, kes võib vabalt kustutada kogu keyspace'i – need on erinevad rollid, erinev vastutus ja pädevus. Ilma selliste õiguste eristamiseta kahtluse alla, kas andmete väärtus ja terviklikkus püsivad, tõuseb kiiremini, kui konsistentsi tase ANY.

Me ei arvestanud, et kõnede kohta on vajalik nii tõsine analüüs kui ka perioodilised valikud väga erinevate tingimuste järgi. Kuna valitud kirjed on pärast mõeldud kustutamiseks ja üle kirjutamiseks (me peame toetama andmete värskendamise protsessi valeandmete esialgsete sissevoolude korral), ei ole Cassandra siin meie sõber. Cassandra on nagu kogumise konteiner – sinna on mugav asju panna, kuid seal ei saa tulemusi arvutada.

Oleme silmitsi seisnud probleemiga andmete edastamisel testimisaladesse. (5 sõlme testis versus 20 tootmises). Sellisel juhul ei saa dump'i kasutada.

Probleem rakenduse andmebaasi skeemi uuendustega, mis kirjutab Cassandra'sse. Tagasivõtt võib genereerida hulga hauakive, mis võib ettearvamatult meie jõudlust mõjutada.Cassandra on kirjutamiseks optimeeritud, ja enne kirjutamist ei mõtle ta palju. Iga olemasolevate andmete operatsioon on samuti kirjutamine. Ehkki kustutades üleliigseid andmeid, genereerime me lihtsalt veelgi rohkem kirjeid ning ainult osa neist jääb hauakividena.

Sisestamise aegumine. Cassandra on kirjutamisel suurepärane, kuid mõnikord võib sisenev voog teda oluliselt segadusse ajada.See juhtub siis, kui rakendus hakkab mitmeid kirjeid ringlusse saatma, mida ei õnnestu mingil põhjusel sisestada. Ja meil on tõeliselt vajalik DBA, kes jälgib gc.log'i, süsteemi logisid ja debug logisid aeglase päringu korral, kompaktimise ootel olevate mõõdikute osas.

Mitmed andmekeskused klastris. Kust lugeda ja kuhu kirjutada?
Kas on võimalik jagada lugemiseks ja kirjutamiseks? Ja kui jah, siis peaks DC olema kirjutamiseks või lugemiseks lähemal rakendusele? Kas ei teki meil tõelist split brain'i, kui valime vale kooskõlastamisastme? Palju küsimusi, palju avastamata seadistusi ja võimalusi, millega nii tahaks mängida.

Kuidas me lahendasime

Et node ei langeks, lülitasime SWAP'i välja. Ja nüüd, kui mälu on vähe, peaks node kokku kukkuma, mitte et tekitama suuri gc pause.

Nii et me ei looda enam SQL loogikale. Rakenduse arendajad õpivad ümber ja hakkavad oma koodis aktiivselt ennast kindlustama. Ideaalne selge andmete salvestamise ja töötlemise lahknevus.

Ostsid tuge DataStaxilt. Kastist väljaspool Cassandra on arendamine lõpetatud (viimane commit veebruaris 2018). Samas pakub Datastax suurepärast teenust ja rohkesti täiustatud ning olemasolevatele IS-dele kohandatud lahendusi.

Tahan veel märkida, et Cassandra ei ole liiga mugav päringute jaoks. Loomulikult on CQL suur samm kasutajate suunas (võrreldes Triftiga). Kuid kui teil on tervet osakonda, mis on harjunud mugavate join'idega, vaba filtreerimisega igasuguste väljade järgi ja päringu optimeerimise võimalustega, ning need osakonnad tegelevad väidete ja avariide lahendamisega, siis tundub neile otsus liikuda Cassandra peale vaenulik ja rumal. Oleme hakanud arutama, kuidas meie kolleege aitada andmete valimisega.

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ügavus peretiifimise juhtumite jaoks). Siin ilmus kohe järgmine probleem: kui kirjutada sünkroonselt, siis kaotame kõik C*-ga seotud eelised, mis tulenevad kiirest sisestamisest; kui asünkroonselt, siis ei ole kindel, et kõik vajalikud kutsed jõuavad Oracle'i. Üks pluss siiski oli, aga suur: tööks jääb endiselt tuttav PL/SQL Developer, st me saame praktiliselt rakendada „Fassaadi” mustrit. Alternatiivne variant. Rakendame mehhanismi, mis väljendab kutsed C*-st, tõmbab teatud andmeid rikastamiseks vastavatest tabelitest Oracle'is, ühendab saadud valikud ja esitab meile saavutatud tulemuse, mida me hiljem mingil moel kasutame (tagasi kerime, kordame, analüüsime, imetleme). Miinused: protsess on üsna mitmeastmeline ja peale selle puudub töötajatele kasutajaliides.

Lõpuks jääme siiski teise variandi juurde. Erinevate pankade valikute jaoks kasutasime Apache Spark. Mehhanismi sisu tuleneb Java-koodist, mis vastavalt määratud võtmetele (tellija, kõne toimumise aeg – jaotuse võtmed) võtab andmed C*-st, samuti vajalikud andmed rikastamiseks mistahes muust andmebaasist. Pärast seda liitub nende andmed oma mällu ja kuvab tulemuse tulemustabelisse. Sparkile joonistati veebiliides ja see osutus täiesti kasutamiseks sobivaks.

Andmete uuendamise ülesande lahendamisel vaatasime taas üle mitu võimalust. Nii Sstloaderi kaudu edastamine kui ka katsetsoonis klastrite jagamine kaheks osaks, millest igaüks vaheldumisi ühendub tootmisklastriga, saades seeläbi toite. Testimise käigus oli plaanis neid omavahel vahetada: see osa, mis töötas testis, puhastatakse ja viiakse tootmisesse, samas kui teine hakkab töötama andmetega eraldi. Ent pärast uuesti kaalumist hindasime ratsionaalsemalt, milliseid andmeid tasub üle kanda, ja mõistsime, et kutsete iseenesest mõistetav olemus testides, mis genereeritakse kiiresti vajaduse korral, ja tootmisandmestiku komplekt ei oma väärtust testimisse edastamiseks. On mitmeid kogumisohtlikke objekte, mida tasub üle kanda, kuid need on vaid mõned tabelid, mis ei ole väga suured. Seetõttu tuli lahendusena taas appi Spark, mille abil kirjutasime ja hakkasime aktiivselt kasutama andmete ülekandmise skripti tabelite vahel tootmisest testimiseks.

Meie praegune juurutamispoliitika võimaldab meil töötada ilma tagasivõtmisteta. Enne reklaami algust toimub kohustuslik testimine, kus vead ei ole nii kulukad. Ebaõnnestumise korral on alati võimalik kukutada juhtumiruumi ja alustada kogu skeemi uuesti.

Kassandri pideva kättesaadavuse tagamiseks on vajalik andmebaasi administreerimine ja mitte ainult see. Kogu rakendusega töötav personal peab mõistma, kus ja kuidas jälgida praegust olukorda ning kuidas probleemide õigeaegse diagnoosimise läbi viia. Selleks kasutame aktiivselt DataStax OpsCenterit (töökoormuse haldamine ja jälgimine), Cassandra Driveri süsteemimetriikat (C* kirjutamise ajaväljajätmiste arv, C* lugemise ajaväljajätmiste arv, maksimaalne latentsus jne), ning jälgime rakenduse tööd, mis suhtleb Kassandraga.

Kuna mõtleme eelnevale küsimusele, saame aru, kus võib peituda peamine risk. See on andmete kuvamise vormid, mis tõukuvad mitmest omavahel sõltumatust päringust salvestusele. Seega võime saada üsna ebaühtlast teavet. Kuid see probleem oleks samuti aktuaalne, isegi kui töötaksime ainult ühe andmekeskusega. Seega on kõige mõistlikum koostada batch-funktsioon andmete lugemiseks välises rakenduses, mis tagab andmete saamise ühtlasel ajaperioodil. Mis puutub lugemise ja kirjutamise eraldamisse jõudluse aspektist, siis peatab meid risk, et andmekeskuste vaheline ühenduse katkemise korral võime saada kaks omavahel täiesti ebaühtlast klastrit.

Seetõttu, hetkel otsustasime, et kirjutamise järjepidevuse tase on EACH_QUORUM, lugemise puhul – LOCAL_QUORUM

Lühikesed muljed ja järeldused

Selleks, et hinnata saavutatud lahendust ekspluateerimise toetuse ja edasise arengu perspektiivi seisukohalt, otsustasime mõelda, kus veel saaks sellist arengut rakendada.

Kui mõelda kiiresti, siis andmete skoorimine selliste programmide jaoks nagu «Maksa, kui sobib» (laadime S* teavet, arvutamine Spark skriptide põhjal), nõuete arvestus suunade kaupa, rollide säilitamine ja õiguste ligipääsu kasutajatele arvutamine rollide maatriksi järgi.

Nagu näeme, 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.

Ieven Kassandra kastist välja võimaldab reaalajas horisontaalset skaleerimist, lahendades andmete suurendamise süsteemis täiesti probleemideta. Oleme suutnud viia eraldi kontuuris välja väga koormatud mehhanismi kõnede koguste arvutamiseks, samuti jagada rakenduse skeemi ja loogika, vabanedes pahest praktikast kirjutada kohandatud töölisi ja objekte andmebaasis. Oleme saanud valida ja seadistada, et kiirendamiseks määrata, millistes andmekeskustes arvutamine toimuda, ja millistes andmed salvestada, kaitstes end nii üksikute nodede kui ka kogu andmekeskuse tõrkeohtude eest.

Uute projektide jaoks meie arhitektuuri rakendades, olles mingisuguse kogemuse juba omandanud, tahaksime kohe arvesse võtta eespool kirjeldatud nüansse, et vältida teatud vigu ja siluda teravaid nurki, millest algselt ei saanud üle.

Näiteks, aeg-ajalt jälgida Kassandra uuendusi, sest paljusid probleeme, millega me silmitsi seisame, on juba teada ja need on parandatud.

Ärge paigaldage nii andmebaasi kui ka Spark'i samadele nodedele või piirake rangelt lubatud ressursside kasutamist, sest Spark võib kasutada rohkem mälu, kui lubatud, ja me saame kiiresti esimese probleemi meie nimekirjas.

Tugevdage jälgimist ja käitamise oskusi juba projekti testimise etapis. Alates algusest arvestama maksimaalselt kõiki meie lahenduse võimalikke tarbijaid, sest just sellest sõltub lõpuks andmebaasi struktuur.

Mõelge korra veel saadud skeemi optimeerimise võimalustele. Tõstke esile, milliseid välju saab serialiseerida. Uuringu käigus selgitage, milliseid täiendavaid tabeleid on vaja luua, et kõige täpsemalt ja optimaalsemalt andmeid arvesse võtta ning seejärel vastata soovitud teabega (näiteks arvestades, et samu andmeid saame salvestada erinevates tabelites, arvestades erinevat jaotust erinevate kriteeriumide järgi, saame oluliselt säästa protsessori aega lugemispäringute korral).

Hea kohe ette näha TTL-i määramise ja aegunud andmete puhastamise.

Andmete eksportimisel Kassandra-st rakenduse loogika peab toimima FETCH põhimõttel, et mitte kõiki ridu korraga mälu laadida, vaid valida need partiide kaupa.

Soovitav on enne projekti üleviimist kirjeldatud lahendusele kontrollida süsteemi katkestuskindlust, viies läbi seeria krahhiteste., 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.

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 and use it only for specific tables during specific periods.

Mis siis, kuue kuu jooksul koos Cassandra'ga? Üldiselt pole lahendamata probleeme. Tõsiseid katkemisi ja andmekadu me samuti ei lubanud. Jah, tuli mõelda teatud varasemate probleemide kompenseerimisele, kuid lõppkokkuvõttes 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üvenema dokumentatsiooni ja koguma oma individuaalsed augud kui vanas legacy lahenduses, ning miski teooria ei ütle ette, millised augud just teid ootavad.

Allikas: habr.com