Kažu da sve u životu vrijedi probati barem jednom. A ako ste navikli raditi s relacijskim DBMS-ovima, onda je vrijedno upoznati se s NoSQL-om u praksi, prije svega, barem za opći razvoj. Sada, zbog brzog razvoja ove tehnologije, postoji mnogo oprečnih mišljenja i žestokih rasprava o ovoj temi, što posebno podgrijava interes.
Ako se uđe u bit svih ovih sporova, vidi se da nastaju zbog pogrešnog pristupa. Oni koji koriste NoSQL baze podataka upravo tamo gdje su potrebne, zadovoljni su i dobivaju sve prednosti ovog rješenja. Eksperimentatori koji se oslanjaju na ovu tehnologiju kao lijek za sve tamo gdje ona uopće nije primjenjiva razočarani su jer su izgubili prednosti relacijskih baza podataka bez dobivanja značajnih prednosti.
Reći ću vam o našem iskustvu u implementaciji rješenja temeljenog na Cassandra DBMS-u: s čime smo se morali suočiti, kako smo se izvukli iz teških situacija, jesmo li imali koristi od korištenja NoSQL-a i gdje smo morali uložiti dodatne napore/sredstva .
Početni zadatak je izgraditi sustav koji snima pozive u neku vrstu pohrane.
Princip rada sustava je sljedeći. Ulaz uključuje datoteke s specifičnom strukturom koja opisuje strukturu poziva. Aplikacija tada osigurava da je ova struktura pohranjena u odgovarajućim stupcima. Ubuduće se spremljeni pozivi koriste za prikaz podataka o potrošnji prometa za pretplatnike (troškovi, pozivi, povijest stanja).
Sasvim je jasno zašto su odabrali Cassandru - ona piše kao mitraljez, lako je skalabilna i tolerantna je na pogreške.
Dakle, ovo je ono što nam je iskustvo dalo
Da, neuspjeli čvor nije tragedija. Ovo je bit Cassandrine tolerancije na pogreške. Ali čvor može biti živ iu isto vrijeme početi patiti u izvedbi. Kako se pokazalo, to odmah utječe na performanse cijelog klastera.
Cassandra vas neće zaštititi tamo gdje vas je Oracle spasio svojim ograničenjima. A ako autor aplikacije to nije unaprijed shvatio, onda dvojnik koji je stigao za Cassandru nije ništa gori od originala. Kada stigne, stavit ćemo ga.
IB-u se nije svidjela besplatna Cassandra iz kutije: Nema zapisivanja radnji korisnika, nema razlikovanja prava. Informacije o pozivima smatraju se osobnim podacima, što znači da se svi pokušaji traženja/promjene istih na bilo koji način moraju evidentirati uz mogućnost naknadne revizije. Također, morate biti svjesni potrebe za odvajanjem prava na različitim razinama za različite korisnike. Jednostavan operativni inženjer i superadministrator koji može slobodno obrisati cijeli prostor ključeva različite su uloge, različite odgovornosti i kompetencije. Bez takve diferencijacije prava pristupa, vrijednost i cjelovitost podataka će odmah doći u pitanje brže nego kod BILO KOJE razine dosljednosti.
Nismo uzeli u obzir da pozivi zahtijevaju i ozbiljnu analitiku i periodično uzorkovanje za različite uvjete. Budući da se odabrani zapisi tada trebaju izbrisati i ponovno napisati (kao dio zadatka, moramo podržati proces ažuriranja podataka kada su podaci inicijalno netočno ušli u našu petlju), Cassandra ovdje nije naš prijatelj. Cassandra je poput kasice prasice - zgodno je staviti stvari u nju, ali ne možete računati u njoj.
Naišli smo na problem pri prijenosu podataka u testne zone (5 čvorova u testu naspram 20 u prom). U ovom slučaju, dump se ne može koristiti.
Problem s ažuriranjem podatkovne sheme aplikacije koja piše u Cassandru. Povratak će generirati veliki broj nadgrobnih ploča, što može dovesti do gubitka produktivnosti na nepredvidive načine.. Cassandra je optimizirana za snimanje i ne razmišlja puno prije pisanja.Svaka operacija s postojećim podacima u njoj također je snimanje. Odnosno, brisanjem nepotrebnog jednostavno ćemo proizvesti još više zapisa, a samo neki od njih bit će obilježeni nadgrobnim spomenicima.
Istek vremena prilikom umetanja. Cassandra je lijepa na snimci, ali ponekad je dolazni tok može značajno zbuniti. To se događa kada aplikacija počne kružiti oko nekoliko zapisa koji se iz nekog razloga ne mogu umetnuti. Trebat će nam i pravi DBA koji će nadzirati gc.log, zapisnike sustava i otklanjanja pogrešaka za spore upite, metriku o sažimanju na čekanju.
Nekoliko podatkovnih centara u klasteru. Odakle čitati, a gdje pisati?
Možda se dijeli na čitanje i pisanje? I ako je tako, treba li postojati DC bliže aplikaciji za pisanje ili čitanje? I nećemo li završiti sa stvarno podijeljenim mozgom ako odaberemo pogrešnu razinu dosljednosti? Ima puno pitanja, puno nepoznatih postavki, mogućnosti s kojima stvarno želite petljati.
Kako smo odlučili
Kako bi se spriječilo potonuće čvora, SWAP je onemogućen. I sada, ako postoji nedostatak memorije, čvor bi trebao pasti i ne stvarati velike gc pauze.
Dakle, više se ne oslanjamo na logiku u bazi podataka. Programeri aplikacija ponovno se obučavaju i počinju aktivno poduzimati mjere opreza u vlastitom kodu. Idealno jasno odvajanje pohrane i obrade podataka.
Kupili smo podršku od DataStaxa. Razvoj Cassandre u kutiji je već prekinut (posljednji commit je bio u veljači 2018.). Istodobno, Datastax nudi vrhunsku uslugu i velik broj modificiranih i prilagođenih rješenja za postojeća IP rješenja.
Također želim napomenuti da Cassandra nije baš prikladna za upite o odabiru. Naravno, CQL je veliki korak naprijed za korisnike (u usporedbi s Triftom). Ali ako imate čitave odjele koji su navikli na takva zgodna spajanja, besplatno filtriranje po bilo kojem polju i mogućnostima optimizacije upita, i ti odjeli rade na rješavanju pritužbi i nesreća, tada im se rješenje na Cassandri čini neprijateljskim i glupim. I počeli smo odlučivati kako će naši kolege napraviti uzorke.
Razmotrili smo dvije mogućnosti. U prvoj opciji zapisujemo pozive ne samo u C*, već iu arhiviranoj Oracle bazi podataka. Samo, za razliku od C*, ova baza podataka pohranjuje pozive samo za tekući mjesec (dovoljna dubina pohrane poziva za slučajeve dopune). Ovdje smo odmah uočili sljedeći problem: ako pišemo sinkrono, tada gubimo sve prednosti C* povezane s brzim umetanjem; ako pišemo asinkrono, nema jamstva da su svi potrebni pozivi uopće stigli u Oracle. Postojao je jedan plus, ali veliki: za rad ostaje isti poznati PL/SQL Developer, tj. praktično implementiramo obrazac "Fasada". Alternativna opcija. Implementiramo mehanizam koji istovaruje pozive iz C*, povlači neke podatke za obogaćivanje iz odgovarajućih tablica u Oracleu, spaja dobivene uzorke i daje nam rezultat, koji onda nekako koristimo (vratimo natrag, ponovimo, analiziramo, divimo se). Protiv: proces je prilično višestepeni, a osim toga, nema sučelja za operativne zaposlenike.
Na kraju smo se odlučili za drugu opciju. Apache Spark korišten je za uzorkovanje iz različitih staklenki. Suština mehanizma svedena je na Java kod koji pomoću zadanih ključeva (pretplatnik, vrijeme poziva - ključevi sekcija) izvlači podatke iz C*, kao i podatke potrebne za obogaćivanje iz bilo koje druge baze podataka. Nakon toga ih spaja u svojoj memoriji i prikazuje rezultat u rezultirajućoj tablici. Preko iskre smo nacrtali web lice i ispalo je sasvim upotrebljivo.
Prilikom rješavanja problema ažuriranja industrijskih testnih podataka ponovno smo razmotrili nekoliko rješenja. Kako prijenos preko Sstloadera, tako i mogućnost dijeljenja klastera u testnoj zoni na dva dijela, od kojih svaki naizmjenično pripada istom klasteru s promotivnim, pa se napaja iz njega. Prilikom ažuriranja testa planirano ih je zamijeniti: dio koji je radio u testu briše se i ulazi u proizvodnju, a drugi počinje zasebno raditi s podacima. Međutim, nakon ponovnog razmišljanja, racionalnije smo procijenili podatke koji su bili vrijedni prijenosa i shvatili da su sami pozivi nekonzistentna cjelina za testove, koja se brzo generira ako je potrebno, a promotivni skup podataka nema vrijednost za prijenos u test. Postoji nekoliko skladišnih predmeta koje vrijedi premjestiti, ali to je doslovno nekoliko stolova, i to ne baš teških. Stoga mi kao rješenje ponovno je priskočio u pomoć Spark uz pomoć kojeg smo napisali i počeli aktivno koristiti skriptu za prijenos podataka između tablica, prom-test.
Naša trenutna politika implementacije omogućuje nam rad bez vraćanja. Prije promocije je obavezna probna vožnja, gdje greška nije tako skupa. U slučaju neuspjeha, uvijek možete ispustiti casespace i pokrenuti cijelu shemu od početka.
Da biste osigurali stalnu dostupnost Cassandre, potreban vam je dba, a ne samo on. Svatko tko radi s aplikacijom mora razumjeti gdje i kako sagledati trenutnu situaciju i kako pravovremeno dijagnosticirati probleme. Da bismo to učinili, aktivno koristimo DataStax OpsCenter (Administracija i praćenje radnih opterećenja), metriku sustava Cassandra Driver (broj čekanja za pisanje u C*, broj čekanja za čitanje iz C*, maksimalnu latenciju itd.), pratimo rad same aplikacije, radeći s Cassandrom.
Kada smo razmišljali o prethodnom pitanju, shvatili smo gdje bi mogao biti naš glavni rizik. To su obrasci za prikaz podataka koji prikazuju podatke iz nekoliko neovisnih upita u pohranu. Na taj način možemo dobiti prilično nedosljedne informacije. Ali ovaj bi problem bio jednako relevantan da radimo samo s jednim podatkovnim centrom. Dakle, najrazumnije je ovdje, naravno, stvoriti skupnu funkciju za čitanje podataka na aplikaciji treće strane, koja će osigurati da podaci budu primljeni u jednom vremenskom razdoblju. Što se tiče podjele na čitanje i pisanje u smislu performansi, ovdje nas je zaustavio rizik da bismo s nekim gubitkom veze između DC-ova mogli završiti s dva klastera koji su potpuno nekonzistentni jedan s drugim.
Kao rezultat, za sada zaustavljen na razini dosljednosti za pisanje EACH_QUORUM, za čitanje - LOCAL_QUORUM
Kratki dojmovi i zaključci
Kako bismo procijenili dobiveno rješenje sa stajališta operativne podrške i izgleda za daljnji razvoj, odlučili smo razmisliti gdje bi se još takav razvoj mogao primijeniti.
Odmah na početku, zatim bodovanje podataka za programe kao što je "Plati kada je zgodno" (učitavamo informacije u C*, izračun pomoću Spark skripti), obračunavanje zahtjeva s agregacijom po području, pohranjivanje uloga i izračunavanje korisničkih prava pristupa na temelju uloge matrica.
Kao što vidite, repertoar je širok i raznovrstan. A ako izaberemo tabor pobornika/protivnika NoSQL-a, onda ćemo se pridružiti pobornicima, jer smo dobili svoje prednosti, i to upravo tamo gdje smo očekivali.
Čak i opcija Cassandra izvan kutije omogućuje horizontalno skaliranje u stvarnom vremenu, apsolutno bezbolno rješavajući problem povećanja podataka u sustavu. Uspjeli smo premjestiti vrlo opterećeni mehanizam za izračunavanje agregata poziva u zaseban krug, a također smo odvojili aplikacijsku shemu i logiku, riješivši se loše prakse pisanja prilagođenih poslova i objekata u samoj bazi podataka. Dobili smo priliku birati i konfigurirati, ubrzati, na kojim ćemo DC-ovima vršiti izračune i na kojim ćemo bilježiti podatke, osigurali smo se od rušenja kako pojedinačnih čvorova, tako i DC-a u cjelini.
Primjenjujući našu arhitekturu na nove projekte i već imajući neko iskustvo, želio bih odmah uzeti u obzir gore opisane nijanse i spriječiti neke pogreške, izgladiti neke oštre kutove koji se u početku nisu mogli izbjeći.
Na primjer, pravodobno pratite Cassandrina ažuriranjajer je dosta problema koje smo imali već poznato i riješeno.
Ne stavljajte i samu bazu podataka i Spark na iste čvorove (ili striktno podijeliti s količinom dopuštene upotrebe resursa), budući da Spark može pojesti više OP-a od očekivanog, i brzo ćemo dobiti problem broj 1 s našeg popisa.
Poboljšati praćenje i operativnu kompetenciju u fazi testiranja projekta. U početku uzmite u obzir što je više moguće sve potencijalne potrošače našeg rješenja, jer o tome će u konačnici ovisiti struktura baze podataka.
Rotirajte rezultirajući krug nekoliko puta radi moguće optimizacije. Odaberite koja se polja mogu serijalizirati. Razumjeti koje dodatne tablice trebamo izraditi kako bismo ih najispravnije i optimalno uzeli u obzir, a zatim pružiti tražene informacije na zahtjev (na primjer, uz pretpostavku da možemo pohraniti iste podatke u različite tablice, uzimajući u obzir različite raščlambe prema različitim kriterijima, možemo značajno uštedjeti CPU vrijeme za zahtjeve za čitanje).
Nije loše Odmah osigurati prilaganje TTL-a i čišćenje zastarjelih podataka.
Prilikom preuzimanja podataka s Cassandre Logika aplikacije bi trebala raditi na principu FETCH, tako da se svi redovi ne učitavaju u memoriju odjednom, već se biraju u serijama.
Preporučljivo je prije prijenosa projekta na opisano rješenje provjeriti otpornost sustava na pogreške provođenjem niza testova sudara, kao što je gubitak podataka u jednom podatkovnom centru, vraćanje oštećenih podataka tijekom određenog razdoblja, ispadanje mreže između podatkovnih centara. Takvi testovi ne samo da će omogućiti procjenu prednosti i mana predložene arhitekture, već će također pružiti dobru praksu zagrijavanja za inženjere koji ih provode, a stečena vještina neće biti suvišna ako se kvarovi sustava reproduciraju u proizvodnji.
Ako radimo s kritičnim informacijama (kao što su podaci za naplatu, izračun pretplatničkog duga), onda je također vrijedno obratiti pažnju na alate koji će smanjiti rizike koji nastaju zbog značajki DBMS-a. Na primjer, koristite uslužni program nodesync (Datastax), nakon što ste razvili optimalnu strategiju za njegovu upotrebu kako bi radi dosljednosti, nemojte stvarati pretjerano opterećenje za Cassandru i koristiti ga samo za određene tablice u određenom razdoblju.
Što se događa s Cassandrom nakon šest mjeseci života? Općenito, nema neriješenih problema. Također nismo dopustili ozbiljne nezgode ili gubitak podataka. Da, morali smo razmišljati o kompenzaciji nekih problema koji se ranije nisu pojavili, ali to u konačnici nije uvelike pomutilo naše arhitektonsko rješenje. Ako želite i ne bojite se isprobati nešto novo, a u isto vrijeme ne želite biti jako razočarani, onda se pripremite na činjenicu da ništa nije besplatno. Morat ćete razumjeti, zadubiti se u dokumentaciju i složiti svoj individualni rake više nego u starom legacy rješenju, a nikakva teorija vam neće unaprijed reći koji rake vas čeka.
Izvor: www.habr.com