Pravijo, da je vse v življenju vredno poskusiti vsaj enkrat. In če ste navajeni delati z relacijskimi DBMS, potem se je vredno seznaniti z NoSQL v praksi, najprej vsaj za splošen razvoj. Zdaj, zaradi hitrega razvoja te tehnologije, je na to temo veliko nasprotujočih si mnenj in burnih razprav, kar še posebej podžiga zanimanje.
Če se poglobite v bistvo vseh teh sporov, lahko ugotovite, da nastajajo zaradi napačnega pristopa. Tisti, ki uporabljajo podatkovne baze NoSQL točno tam, kjer jih potrebujejo, so zadovoljni in prejmejo vse prednosti te rešitve. Eksperimentatorji, ki se zanašajo na to tehnologijo kot na zdravilo, kjer sploh ni uporabna, so razočarani, saj so izgubili prednosti relacijskih baz podatkov, ne da bi pridobili pomembne koristi.
Povedal vam bom o naših izkušnjah pri implementaciji rešitve, ki temelji na Cassandra DBMS: s čim smo se morali soočiti, kako smo se rešili iz težkih situacij, ali nam je uporaba NoSQL koristila in kam smo morali vložiti dodatne napore/sredstva .
Začetna naloga je zgraditi sistem, ki snema klice v nekakšno shrambo.
Načelo delovanja sistema je naslednje. Vhod vključuje datoteke z določeno strukturo, ki opisuje strukturo klica. Aplikacija nato zagotovi, da je ta struktura shranjena v ustreznih stolpcih. V prihodnje se shranjeni klici uporabljajo za prikaz podatkov o porabi prometa za naročnike (stroški, klici, zgodovina stanja).
Povsem jasno je, zakaj so izbrali Cassandro - piše kot mitraljez, je enostavno prilagodljiva in odporna na napake.
Torej, to so nam dale izkušnje
Da, neuspelo vozlišče ni tragedija. To je bistvo Cassandrine tolerance napak. Ampak vozlišče je lahko živo in hkrati začne trpeti pri delovanju. Kot se je izkazalo, to takoj vpliva na delovanje celotnega grozda.
Cassandra vas ne bo zaščitila tam, kjer vas je rešil Oracle s svojimi omejitvami. In če avtor aplikacije tega ni razumel vnaprej, potem dvojnik, ki je prispel za Cassandro, ni nič slabši od izvirnika. Ko bo prispel, ga bomo vstavili.
IB-ju ni bila všeč brezplačna Cassandra iz škatle: Ni beleženja uporabniških dejanj, ni razlikovanja pravic. Podatki o klicih se štejejo za osebne podatke, kar pomeni, da morajo biti vsi poskusi zahteve/spreminjanja le-teh na kakršen koli način zabeleženi z možnostjo naknadne revizije. Prav tako se morate zavedati potrebe po ločevanju pravic na različnih ravneh za različne uporabnike. Preprost operacijski inženir in superskrbnik, ki lahko poljubno izbriše celoten prostor ključev, imata različne vloge, različne odgovornosti in kompetence. Brez takšnega razlikovanja pravic dostopa bosta vrednost in celovitost podatkov takoj hitreje prišli pod vprašaj kot pri KAKRŠNI KOLI stopnji doslednosti.
Nismo upoštevali, da klici zahtevajo tako resno analitiko kot občasno vzorčenje za različne pogoje. Ker naj bi izbrane zapise nato izbrisali in ponovno zapisali (kot del naloge moramo podpirati proces posodabljanja podatkov, ko so podatki prvotno nepravilno vstopili v našo zanko), Cassandra tukaj ni naš prijatelj. Cassandra je kot prašiček - stvari je priročno vložiti, vendar vanjo ne morete računati.
Pri prenosu podatkov v testna območja smo naleteli na težavo (5 vozlišč v testu proti 20 v prom). V tem primeru odlagališča ni mogoče uporabiti.
Težava s posodabljanjem podatkovne sheme aplikacije, ki piše v Cassandro. Povratek bo ustvaril veliko število nagrobnikov, kar lahko na nepredvidljive načine povzroči izgubo produktivnosti.. Cassandra je optimizirana za snemanje in pred pisanjem ne razmišlja veliko, vsaka operacija z obstoječimi podatki v njej je tudi snemanje. Se pravi, da bomo z brisanjem nepotrebnega preprosto proizvedli še več zapisov, le nekateri pa bodo označeni z nagrobniki.
Časovne omejitve pri vstavljanju. Cassandra je posnetku lepa, a včasih jo lahko dohodni tok močno zmede. To se zgodi, ko začne aplikacija krožiti okoli več zapisov, ki jih iz nekega razloga ni mogoče vstaviti. Potrebovali bomo pravega skrbnika baze podatkov, ki bo spremljal gc.log, sistemske dnevnike in dnevnike odpravljanja napak za počasne poizvedbe, meritve o stiskanju v teku.
Več podatkovnih centrov v gruči. Od kod brati in kam pisati?
Morda delitev na branje in pisanje? In če ja, bi moral biti DC bližje aplikaciji za pisanje ali branje? In ali ne bomo imeli resnično razcepljenih možganov, če izberemo napačno stopnjo doslednosti? Obstaja veliko vprašanj, veliko neznanih nastavitev, možnosti, s katerimi se res želite poigrati.
Kako smo se odločili
Da bi preprečili potopitev vozlišča, je bil SWAP onemogočen. In zdaj, če primanjkuje pomnilnika, bi moralo vozlišče ugasniti in ne ustvarjati velikih gc pavz.
Tako se ne zanašamo več na logiko v bazi podatkov. Razvijalci aplikacij se prekvalificirajo in začenjajo aktivno sprejemati previdnostne ukrepe v lastni kodi. Idealno jasno ločevanje shranjevanja in obdelave podatkov.
Podporo smo kupili pri DataStaxu. Razvoj škatlaste Cassandre je že ustavljen (zadnja commit je bila februarja 2018). Hkrati Datastax ponuja odlično storitev in veliko število modificiranih in prilagojenih rešitev za obstoječe IP rešitve.
Prav tako želim opozoriti, da Cassandra ni zelo primerna za izbirne poizvedbe. Seveda je CQL velik korak naprej za uporabnike (v primerjavi s Triftom). Toda če imate cele oddelke, ki so navajeni tako priročnih združevanj, brezplačnega filtriranja po poljubnem polju in zmožnosti optimizacije poizvedb, in ti oddelki delajo na reševanju pritožb in nesreč, potem se jim rešitev na Cassandri zdi sovražna in neumna. In začeli smo se odločati, kako naj naši kolegi naredijo vzorce.
Razmislili smo o dveh možnostih.Pri prvi možnosti zapisujemo klice ne samo v C*, ampak tudi v arhivirano bazo Oracle. Le da ta baza za razliko od C* shranjuje klice samo za tekoči mesec (zadostna globina shranjevanja klicev za primere polnjenja). Tu smo takoj opazili naslednjo težavo: če pišemo sinhrono, izgubimo vse prednosti C*, povezane s hitrim vstavljanjem; če pišemo asinhrono, ni nobenega zagotovila, da so vsi potrebni klici sploh prišli v Oracle. Bil je en plus, a velik: za delovanje ostaja isti znani razvijalec PL/SQL, torej praktično izvajamo vzorec "Fasada". Alternativna možnost. Implementiramo mehanizem, ki razbremeni klice iz C*, potegne nekaj podatkov za obogatitev iz pripadajočih tabel v Oraclu, združi nastale vzorce in nam da rezultat, ki ga nato nekako uporabimo (vrnemo nazaj, ponavljamo, analiziramo, občudujemo). Proti: postopek je precej večstopenjski, poleg tega pa ni vmesnika za operativne zaposlene.
Na koncu smo se odločili za drugo možnost. Apache Spark je bil uporabljen za vzorčenje iz različnih kozarcev. Bistvo mehanizma se je zreduciralo na kodo Java, ki s pomočjo določenih ključev (naročnik, čas klica - ključi odsekov) potegne podatke iz C*, kakor tudi potrebne podatke za obogatitev iz katere koli druge baze. Nato jih združi v svojem pomnilniku in prikaže rezultat v nastali tabeli. Čez iskrico smo narisali spletno ploskev in izkazalo se je kar uporabno.
Pri reševanju problema posodabljanja industrijskih testnih podatkov smo ponovno upoštevali več rešitev. Tako prenos preko Sstloaderja kot tudi možnost razdelitve gruče v testni coni na dva dela, ki izmenično pripadata istemu grozdu s promocijskim in se tako napajata iz njega. Pri posodobitvi testa je bilo načrtovano, da jih zamenjamo: del, ki je deloval v testu, se očisti in vnese v proizvodnjo, drugi pa začne ločeno delati s podatki. Vendar smo po ponovnem premisleku bolj racionalno ocenili podatke, ki so bili vredni prenosa, in ugotovili, da so klici sami testno nekonsistentna entiteta, ki se hitro generira, če je treba, in je promocijski nabor podatkov tisti, ki nima vrednosti za prenos v test. Obstaja več predmetov za shranjevanje, ki jih je vredno premakniti, vendar je to dobesedno nekaj miz in ne zelo težkih. Zato mi kot rešitev je spet priskočil na pomoč Spark, s pomočjo katerega smo napisali in začeli aktivno uporabljati skripto za prenos podatkov med tabelami, prom-test.
Naša trenutna politika uvajanja nam omogoča delo brez povrnitev. Pred promocijo je obvezen test, kjer napaka ni tako draga. V primeru neuspeha lahko vedno izpustite casespace in zavrtite celotno shemo od začetka.
Za zagotavljanje stalne razpoložljivosti Cassandre potrebujete dba in ne samo njega. Vsakdo, ki dela z aplikacijo, mora razumeti, kje in kako pogledati trenutno stanje ter kako pravočasno diagnosticirati težave. Za to aktivno uporabljamo DataStax OpsCenter (Administracija in spremljanje delovnih obremenitev), sistemske metrike Cassandra Driver (število časovnih omejitev za pisanje v C*, število časovnih omejitev za branje iz C*, največjo zakasnitev itd.), spremljamo delovanje same aplikacije, delo s Cassandro.
Ko smo razmišljali o prejšnjem vprašanju, smo ugotovili, kje je naše glavno tveganje. To so obrazci za prikaz podatkov, ki v shrambo prikazujejo podatke iz več neodvisnih poizvedb. Tako lahko dobimo precej neenotne informacije. Toda ta problem bi bil enako pomemben, če bi delali samo z enim podatkovnim centrom. Zato je tukaj seveda najbolj smiselno ustvariti paketno funkcijo za branje podatkov na aplikaciji tretje osebe, ki bo zagotovila prejem podatkov v enem samem časovnem obdobju. Kar zadeva delitev na branje in pisanje glede zmogljivosti, nas je tu ustavilo tveganje, da bi z nekaj izgube povezave med DC-ji lahko na koncu dobili dva grozda, ki sta med seboj popolnoma neskladna.
Kot rezultat, za zdaj ustavljeno na ravni doslednosti za pisanje EACH_QUORUM, za branje - LOCAL_QUORUM
Kratki vtisi in zaključki
Da bi ovrednotili nastalo rešitev z vidika operativne podpore in možnosti za nadaljnji razvoj, smo se odločili razmisliti, kje bi takšen razvoj še lahko uporabili.
Takoj na začetku, nato točkovanje podatkov za programe, kot je »Plačaj, ko je primerno« (naložimo informacije v C*, izračun s skripti Spark), obračunavanje zahtevkov z združevanjem po področjih, shranjevanje vlog in izračun pravic dostopa uporabnikov na podlagi vloge matrica.
Kot vidite, je repertoar širok in raznolik. In če izberemo tabor zagovornikov/nasprotnikov NoSQL, potem se bomo pridružili zagovornikom, saj smo dobili svoje prednosti in točno tam, kjer smo pričakovali.
Celo takojšnja možnost Cassandra omogoča vodoravno skaliranje v realnem času, kar popolnoma neboleče rešuje vprašanje povečanja podatkov v sistemu. Uspelo nam je premakniti zelo visoko obremenjen mehanizem za izračun agregatov klicev v ločeno vezje in prav tako ločiti shemo in logiko aplikacije, s čimer smo se znebili slabe prakse pisanja opravil in objektov po meri v sami bazi podatkov. Dobili smo možnost izbire in konfiguracije, pospeševanja, na katerih DC-jih bomo izvajali izračune in na katerih bomo zapisovali podatke, zavarovali smo se pred zrušitvami tako posameznih vozlišč kot DC-ja kot celote.
Z uporabo naše arhitekture pri novih projektih in že z nekaj izkušnjami bi rad takoj upošteval zgoraj opisane nianse in preprečil nekatere napake, zgladil nekatere ostre vogale, ki se jim na začetku ni bilo mogoče izogniti.
Na primer, pravočasno spremljajte Cassandrine posodobitveker je bilo kar nekaj težav, ki smo jih dobili, že znanih in odpravljenih.
Ne postavljajte same baze podatkov in Spark na ista vozlišča (ali strogo delite s količino dovoljene uporabe virov), saj lahko Spark poje več OP, kot je bilo pričakovano, in hitro bomo dobili problem številka 1 z našega seznama.
Izboljšajte spremljanje in operativno usposobljenost v fazi testiranja projekta. Na začetku čim bolj upoštevajte vse potencialne uporabnike naše rešitve, ker bo od tega na koncu odvisna struktura baze podatkov.
Večkrat zavrtite nastalo vezje za morebitno optimizacijo. Izberite, katera polja je mogoče serializirati. Razumeti, katere dodatne tabele bi morali izdelati, da bi kar najbolj pravilno in optimalno upoštevali, nato pa na zahtevo posredovati zahtevane podatke (na primer s predpostavko, da lahko iste podatke hranimo v različnih tabelah, pri čemer upoštevamo različne razčlenitve glede na različnih kriterijih, lahko znatno prihranimo čas procesorja za zahteve za branje).
Ni slabo Takoj poskrbeti za pripenjanje TTL in čiščenje zastarelih podatkov.
Pri prenosu podatkov iz Cassandre Logika aplikacije naj bi delovala po principu FETCH, tako da se vse vrstice ne nalagajo v pomnilnik naenkrat, ampak se izbirajo v paketih.
Priporočljivo je pred prenosom projekta na opisano rešitev preverite toleranco sistema na napake z izvedbo serije testov trčenja, kot je izguba podatkov v enem podatkovnem centru, obnovitev poškodovanih podatkov v določenem obdobju, izpad omrežja med podatkovnimi centri. Takšni testi ne bodo le omogočili oceniti prednosti in slabosti predlagane arhitekture, temveč bodo zagotovili tudi dobro prakso ogrevanja za inženirje, ki jih izvajajo, pridobljena spretnost pa še zdaleč ne bo odveč, če se sistemske napake reproducirajo v proizvodnji.
Če delamo s kritičnimi informacijami (kot so podatki za obračunavanje, izračun naročniškega dolga), potem je vredno biti pozoren tudi na orodja, ki bodo zmanjšala tveganja, ki nastanejo zaradi lastnosti DBMS. Uporabite na primer pripomoček nodesync (Datastax), pri čemer ste razvili optimalno strategijo za njegovo uporabo, da zaradi doslednosti ne ustvarjajte pretirane obremenitve Cassandre in ga uporabljajte samo za določene tabele v določenem obdobju.
Kaj se zgodi s Cassandro po šestih mesecih življenja? Na splošno ni nerešenih problemov. Prav tako nismo dovolili hujših nesreč ali izgube podatkov. Da, morali smo razmišljati o kompenzaciji nekaterih težav, ki se prej niso pojavile, vendar to na koncu ni močno zameglilo naše arhitekturne rešitve. Če želite in vas ni strah poskusiti nekaj novega, hkrati pa ne želite biti preveč razočarani, potem se pripravite na dejstvo, da nič ni zastonj. Bolj kot v stari legacy rešitvi boste morali razumeti, se poglobiti v dokumentacijo in sestaviti svoje individualne grablje in nobena teorija vam ne bo vnaprej povedala, katere grablje vas čakajo.
Vir: www.habr.com