Nad ütlevad, et elus tasub kõike vähemalt korra proovida. Ja kui olete harjunud töötama relatsiooniliste DBMS-idega, siis tasub NoSQL-iga praktikas tutvuda ennekõike, vähemalt üldiseks arendamiseks. Nüüd on selle tehnoloogia kiire arengu tõttu sellel teemal palju vastakaid arvamusi ja tuliseid vaidlusi, mis eriti kütab huvi.
Kui süveneda kõigi nende vaidluste olemusse, on näha, et need tekivad vale lähenemise tõttu. Need, kes kasutavad NoSQL andmebaase täpselt seal, kus neid vaja on, on rahul ja saavad sellest lahendusest kõik eelised. Ja katsetajad, kes kasutavad seda tehnoloogiat kui imerohtu seal, kus seda üldse ei kasutata, on pettunud, kuna nad on kaotanud relatsiooniandmebaaside tugevad küljed ilma märkimisväärset kasu saamata.
Räägin teile oma kogemustest Cassandra DBMS-il põhineva lahenduse juurutamisel: millega pidime silmitsi seisma, kuidas keerulistest olukordadest välja tulime, kas saime NoSQL-i kasutamisest kasu ja kuhu pidime täiendavaid jõupingutusi/raha investeerima. .
Lähteülesanne on ehitada süsteem, mis salvestab kõned mingisugusesse salvestusruumi.
Süsteemi tööpõhimõte on järgmine. Sisend sisaldab spetsiifilise struktuuriga faile, mis kirjeldavad kõne struktuuri. Seejärel tagab rakendus selle struktuuri salvestamise vastavatesse veergudesse. Edaspidi kasutatakse salvestatud kõnede kaudu info kuvamiseks abonentide liiklustarbimise kohta (tasud, kõned, saldoajalugu).
On üsna selge, miks nad Cassandra valisid – ta kirjutab nagu kuulipilduja, on kergesti skaleeritav ja veakindel.
Nii, see on see, mida kogemus meile andis
Jah, ebaõnnestunud sõlm ei ole tragöödia. See on Cassandra veataluvuse olemus. Aga sõlm võib olla elus ja samal ajal hakata jõudluses kannatama. Nagu selgus, mõjutab see kohe kogu klastri jõudlust.
Cassandra ei kaitse teid seal, kus Oracle teid oma piirangutega päästis. Ja kui rakenduse autor sellest ette aru ei saanud, pole Cassandrale saabunud duubel originaalist halvem. Kui see on käes, paneme selle sisse.
IB-le ei meeldinud karbist välja võetud tasuta Cassandra väga: Puudub kasutaja toimingute logimine, õiguste eristamine. Teavet kõnede kohta käsitletakse isikuandmetena, mis tähendab, et kõik katsed seda mis tahes viisil nõuda/muuta tuleb logida hilisema auditeerimise võimalusega. Samuti peate olema teadlik vajadusest eraldada erinevate kasutajate õigused erinevatel tasanditel. Lihtne tööinsener ja superadministraator, kes saab vabalt kogu klahviruumi kustutada, on erinevad rollid, erinevad kohustused ja pädevused. Ilma sellise juurdepääsuõiguste diferentseerimiseta satub andmete väärtus ja terviklikkus kohe kiiremini kahtluse alla kui MIS TAHES järjepidevuse taseme puhul.
Me ei võtnud arvesse, et kõned nõuavad nii tõsist analüüsi kui ka perioodilist proovide võtmist erinevate tingimuste jaoks. Kuna valitud kirjed tuleb seejärel kustutada ja ümber kirjutada (ülesande osana peame toetama andmete värskendamise protsessi, kui andmed sisestasid algselt meie ahelasse valesti), pole Cassandra siin meie sõber. Cassandra on nagu hoiupõrsas – sinna on mugav asju panna, aga sellega arvestada ei saa.
Andmete testtsoonidesse ülekandmisel ilmnes probleem (5 sõlme testis versus 20 ballis). Sel juhul ei saa prügimäge kasutada.
Probleem Cassandrale kirjutava rakenduse andmeskeemi värskendamisega. Tagasivõtmine tekitab palju hauakivisid, mis võib põhjustada tootlikkuse langust ettearvamatul viisil.. Cassandra on salvestamiseks optimeeritud ega mõtle enne kirjutamist palju. Iga toiming olemasolevate andmetega on samuti salvestamine. See tähendab, et mittevajaliku kustutamisega toodame lihtsalt veelgi rohkem plaate ja ainult osa neist märgitakse hauakividega.
Ajalõpud sisestamisel. Cassandra on salvestusel ilus, aga mõnikord võib sissetulev vool teda märkimisväärselt segada. See juhtub siis, kui rakendus hakkab ringi käima mitmes kirjes, mida ei saa mingil põhjusel sisestada. Ja me vajame tõelist DBA-d, kes jälgib faili gc.log, aeglaste päringute jaoks süsteemi- ja silumisloge ning tihendamise ootel mõõdikuid.
Klastris mitu andmekeskust. Kust lugeda ja kuhu kirjutada?
Võib-olla jaguneb lugemiseks ja kirjutamiseks? Ja kui nii, siis kas kirjutamiseks või lugemiseks peaks rakendusele lähemal olema DC? Ja kas me ei lõpe tõelise ajuga, kui valime vale järjepidevuse taseme? Seal on palju küsimusi, palju tundmatuid seadeid, võimalusi, mille kallal tahaks väga nokitseda.
Kuidas me otsustasime
Sõlme uppumise vältimiseks keelati SWAP. Ja nüüd, kui mälu on puudu, peaks sõlm alla minema ja mitte tekitama suuri gc pause.
Niisiis, me ei tugine enam andmebaasi loogikale. Rakenduste arendajad koolitavad end ümber ja hakkavad oma koodi osas aktiivselt ettevaatusabinõusid rakendama. Ideaalne andmete salvestamise ja töötlemise selge eraldamine.
Ostsime DataStaxilt tuge. Boksiga Cassandra arendus on juba peatunud (viimane lubamine oli veebruaris 2018). Samal ajal pakub Datastax suurepärast teenindust ja suurt hulka muudetud ja kohandatud lahendusi olemasolevatele IP-lahendustele.
Samuti tahan märkida, et Cassandra pole valikupäringute jaoks eriti mugav. Loomulikult on CQL kasutajate jaoks suur samm edasi (võrreldes Triftiga). Kuid kui teil on terved osakonnad, kes on harjunud selliste mugavate liitumiste, tasuta filtreerimise ja päringute optimeerimise võimalustega ning need osakonnad tegelevad kaebuste ja õnnetuste lahendamisega, tundub Cassandra lahendus neile vaenulik ja rumal. Ja me hakkasime otsustama, kuidas meie kolleegid peaksid proove tegema.
Kaalusime kahte võimalust.Esimese variandi puhul kirjutame kõned mitte ainult C*-s, vaid ka arhiveeritud Oracle'i andmebaasis. Ainult erinevalt C*-st salvestab see andmebaas ainult jooksva kuu kõned (piisav kõnede salvestussügavus juhtumite laadimiseks). Siin nägime kohe järgmist probleemi: kui kirjutame sünkroonselt, siis kaotame kõik kiire sisestamisega kaasnevad C* eelised, asünkroonselt kirjutades pole garantiid, et kõik vajalikud kõned üldse Oracle'i said. Üks pluss oli, aga suur: tööks jääb seesama tuttav PL/SQL Developer ehk rakendame praktiliselt “Fassaadi” mustri.Alternatiivne võimalus. Rakendame mehhanismi, mis laadib C*-st kõned maha, tõmbab Oracle'i vastavatest tabelitest rikastamiseks mõned andmed, ühendab saadud näidised ja annab meile tulemuse, mida me siis kuidagi kasutame (kerime tagasi, kordame, analüüsime, imetleme). Miinused: protsess on üsna mitmeastmeline ja lisaks puudub operatiivtöötajatele liides.
Lõpuks leppisime teise variandiga. Erinevatest purkidest proovide võtmiseks kasutati Apache Sparki. Mehhanismi olemus on taandatud Java-koodiks, mis määratud võtmeid (abonent, kõneaeg - sektsiooniklahvid) kasutades tõmbab C*-st välja andmed, aga ka rikastamiseks vajalikud andmed mis tahes muust andmebaasist. Pärast seda ühendab see need oma mällu ja kuvab tulemuse saadud tabelis. Sädeme peale joonistasime veebinäo ja see sai päris kasutatav.
Tööstuslike katseandmete uuendamise probleemi lahendamisel kaalusime taas mitmeid lahendusi. Nii ülekanne Sstloaderi kaudu kui ka võimalus jagada testtsoonis olev klaster kaheks osaks, millest kumbki kuulub vaheldumisi reklaamiga samasse klastrisse, olles seega sellest toiteallikaks. Testi uuendamisel oli plaanis need omavahel ära vahetada: testis töötanud osa tühjendatakse ja sisestatakse tootmisse ning teine hakkab andmetega eraldi tööle. Pärast uuesti järelemõtlemist hindasime aga ratsionaalsemalt ülekandmist väärivaid andmeid ja saime aru, et kõned ise on testide jaoks ebaühtlane üksus, mis genereeritakse vajadusel kiiresti ja just reklaamandmete kogum ei oma väärtust ülekandmiseks. test. On mitmeid panipaiku, mida tasub teisaldada, kuid need on sõna otseses mõttes paar lauda ja mitte väga rasked. Seetõttu meie lahendusena tuli taas appi Spark, mille abil kirjutasime ja hakkasime aktiivselt kasutama skripti andmete tabelitevaheliseks edastamiseks, prom-test.
Meie praegune juurutamispoliitika võimaldab meil töötada ilma tagasivõtmisteta. Enne promo on kohustuslik proovisõit, kus eksimus nii kallis ei maksa. Ebaõnnestumise korral võite alati kastiruumi maha jätta ja kogu skeemi algusest peale rullida.
Cassandra pideva kättesaadavuse tagamiseks vajate dba-d ja mitte ainult teda. Kõik, kes rakendusega töötavad, peavad aru saama, kust ja kuidas hetkeolukorda vaadata ning kuidas probleeme õigel ajal diagnoosida. Selleks kasutame aktiivselt DataStax OpsCenterit (Töökoormuste administreerimine ja jälgimine), Cassandra Driveri süsteemimõõdikuid (C*-sse kirjutamise ajalõppude arv, C*-st lugemise ajalõpude arv, maksimaalne latentsus jne), jälgime toimimist. rakenduse enda, töötades koos Cassandraga.
Eelmisele küsimusele mõeldes mõistsime, kus võib peituda meie peamine risk. Need on andmete kuvamise vormid, mis kuvavad andmeid mitmest sõltumatust päringust salvestusruumi. Nii võime saada üsna ebaühtlast teavet. Kuid see probleem oleks sama asjakohane, kui töötaksime ainult ühe andmekeskusega. Nii et kõige mõistlikum on siin loomulikult luua kolmanda osapoole rakenduses andmete lugemiseks pakettfunktsioon, mis tagab andmete kättesaamise ühe aja jooksul. Mis puudutab jõudluse jaotust lugemiseks ja kirjutamiseks, siis siin peatas meid oht, et DC-de vahelise ühenduse mõningase katkemise korral võime saada kaks klastrit, mis on üksteisega täiesti vastuolus.
Selle tulemusena praegu peatus järjepidevuse tasemel EACH_QUORUM kirjutamisel, lugemisel - LOCAL_QUORUM
Lühikesed muljed ja järeldused
Et hinnata valminud lahendust tegevustoetuse ja edasise arengu väljavaadete seisukohalt, otsustasime mõelda, kus veel sellist arendust rakendada saaks.
Kohe kohe, seejärel andmete hindamine selliste programmide jaoks nagu "Maksa siis, kui see on mugav" (laadime teabe C*-sse, arvutame Sparki skripte), nõuete arvestamine piirkondade kaupa koondamisega, rollide salvestamine ja kasutajate juurdepääsuõiguste arvutamine rolli alusel. maatriks.
Nagu näha, on repertuaar lai ja mitmekesine. Ja kui valime NoSQL-i toetajate/vastaste leeri, siis ühineme toetajatega, kuna saime oma eelised kätte ja just seal, kus ootasime.
Isegi Cassandra valik võimaldab reaalajas horisontaalset skaleerimist, lahendades täiesti valutult süsteemi andmete suurendamise probleemi. Saime väga suure koormusega kõneagregaatide arvutamise mehhanismi teisaldada eraldi ahelasse ning eraldada ka rakendusskeemi ja loogika, vabanedes halvast tavast kirjutada kohandatud töid ja objekte andmebaasi endasse. Saime võimaluse valida ja seadistada, kiirendada, millistel DC-del arvutusi teeme ja millistele andmeid salvestame, kindlustasime end nii üksikute sõlmede kui ka kogu alalisvoolu kokkujooksmiste vastu.
Rakendades meie arhitektuuri uutele projektidele ja omades juba mõningast kogemust, soovin koheselt arvestada ülalkirjeldatud nüanssidega ning ennetada mõningaid vigu, siluda mõned teravad nurgad, mida esialgu ei saanud vältida.
Näiteks jälgige Cassandra värskendusi õigeaegseltsest paljud meie tekkinud probleemid olid juba teada ja parandatud.
Ärge asetage nii andmebaasi ennast kui ka Sparki samadele sõlmedele (või jagage rangelt lubatud ressursikasutusega), kuna Spark võib oodatust rohkem OP-d süüa ja saame kiiresti oma loendist probleemi number 1.
Parandage järelevalvet ja tegevuspädevust projekti testimise etapis. Esialgu võtke võimalikult palju arvesse kõiki meie lahenduse potentsiaalseid tarbijaid, sest sellest sõltub lõpuks andmebaasi struktuur.
Võimalikuks optimeerimiseks pöörake saadud vooluringi mitu korda. Valige, milliseid välju saab järjestada. Mõista, milliseid lisatabeleid peaksime tegema, et neid kõige õigemini ja optimaalselt arvesse võtta ning seejärel nõudmisel nõutud infot esitama (näiteks eeldades, et saame salvestada samu andmeid erinevatesse tabelitesse, võttes arvesse erinevaid jaotusi vastavalt erinevatele kriteeriumidele, saame lugemispäringute jaoks märkimisväärselt CPU aega säästa).
Pole halb Pakkuge kohe ette TTL-i lisamine ja vananenud andmete puhastamine.
Cassandrast andmete allalaadimisel Rakendusloogika peaks töötama FETCH põhimõttel, nii et kõiki ridu ei laadita mällu korraga, vaid valitakse partiidena.
Soovitav on enne projekti ülekandmist kirjeldatud lahendusele kontrollige süsteemi tõrketaluvust, viies läbi mitmeid kokkupõrketeste, näiteks andmekadu ühes andmekeskuses, kahjustatud andmete taastamine teatud aja jooksul, võrgu väljalangemine andmekeskuste vahel. Sellised testid ei võimalda mitte ainult hinnata kavandatava arhitektuuri plusse ja miinuseid, vaid annavad ka hea soojenduspraktika neid läbi viivatele inseneridele ning omandatud oskused pole kaugeltki üleliigsed, kui süsteemirikkeid tootmises taastoodetakse.
Kui töötame kriitilise teabega (näiteks andmed arveldamiseks, abonendi võla arvutamine), siis tasub pöörata tähelepanu ka tööriistadele, mis vähendavad DBMS-i omadustest tulenevaid riske. Näiteks kasutage nodesynci utiliiti (Datastax), olles välja töötanud selle kasutamiseks optimaalse strateegia järjepidevuse huvides ära tekita Cassandrale liigset koormust ja kasutada seda ainult teatud tabelite jaoks teatud perioodil.
Mis saab Cassandrast pärast kuuekuulist elu? Üldiselt pole lahendamata probleeme. Samuti ei lubanud me tõsiseid õnnetusi ega andmete kadumist. Jah, me pidime mõtlema mõningate probleemide kompenseerimisele, mida varem polnud tekkinud, kuid lõppkokkuvõttes see meie arhitektuurset lahendust väga ei ähmastanud. Kui tahad ja ei karda midagi uut proovida ning samas ei taha ka liialt pettuda, siis ole valmis selleks, et midagi pole tasuta. Peate rohkem aru saama, dokumentatsiooni süvenema ja oma individuaalse reha kokku panema rohkem kui vanas pärandlahenduses ning ükski teooria ei ütle teile ette, milline reha teid ootab.
Allikas: www.habr.com