Kažu da sve u životu vrijedi pokušati 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 debata na ovu temu, što posebno podstiče interesovanje.
Ako se udubite u suštinu svih ovih sporova, možete vidjeti da oni nastaju zbog pogrešnog pristupa. Oni koji koriste NoSQL baze podataka tačno tamo gde su potrebne, zadovoljni su i dobijaju sve prednosti ovog rešenja. I eksperimentatori koji se oslanjaju na ovu tehnologiju kao na lijek tamo gdje ona uopće nije primjenjiva, razočarani su jer su izgubili prednosti relacijskih baza podataka, a da nisu ostvarili značajne prednosti.
Reći ću vam o našem iskustvu u implementaciji rješenja baziranog na Cassandra DBMS: sa čime smo se morali suočiti, kako smo se izvukli iz teških situacija, da li smo mogli imati koristi od korištenja NoSQL-a i gdje smo morali uložiti dodatne napore/finansijska sredstva .
Početni zadatak je da se izgradi sistem koji snima pozive u neku vrstu skladišta.
Princip rada sistema je sledeći. Ulaz uključuje datoteke sa specifičnom strukturom koja opisuje strukturu poziva. Aplikacija tada osigurava da je ova struktura pohranjena u odgovarajućim stupcima. Ubuduće, sačuvani pozivi se koriste za prikaz informacija o potrošnji saobraćaja za pretplatnike (naplate, pozivi, istorija stanja).
Sasvim je jasno zašto su odabrali Cassandru - ona piše kao mitraljez, lako je skalabilna i tolerantna na greške.
Dakle, ovo nam je iskustvo dalo
Da, neuspjeli čvor nije tragedija. Ovo je suština Kasandrine tolerancije na greške. Ali čvor može biti živ i istovremeno početi patiti u performansama. Kako se ispostavilo, to odmah utič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 razumio unaprijed, onda duplikat koji je stigao za Cassandru nije ništa gori od originala. Kada stigne, stavićemo ga.
IB-u se jako nije svidjela slobodna Cassandra iz kutije: Nema evidentiranja radnji korisnika, nema diferencijacije prava. Informacija o pozivima se smatra ličnim podacima, što znači da se svi pokušaji traženja/promjene na bilo koji način moraju evidentirati uz mogućnost naknadne revizije. Također, morate biti svjesni potrebe za odvajanjem prava na različitim nivoima za različite korisnike. Inženjer jednostavnog rada i super administrator koji može slobodno izbrisati cijeli prostor ključeva različite su uloge, različite odgovornosti i kompetencije. Bez takve diferencijacije prava pristupa, vrijednost i integritet podataka će odmah doći u pitanje brže nego sa BILO KOJIM nivoom konzistentnosti.
Nismo uzeli u obzir da pozivi zahtevaju i ozbiljnu analitiku i periodično uzorkovanje za različite uslove. Budući da se odabrani zapisi tada trebaju izbrisati i ponovo napisati (kao dio zadatka, moramo podržati proces ažuriranja podataka kada su podaci inicijalno pogrešno ušli u našu petlju), Cassandra ovdje nije naš prijatelj. Kasandra je poput kasice-prasice - zgodno je staviti stvari, ali ne možete računati u nju.
Naišli smo na problem pri prijenosu podataka u testne zone (5 čvorova u testu naspram 20 na maturalnoj). U ovom slučaju, dump se ne može koristiti.
Problem sa ažuriranjem šeme podataka aplikacije koja piše u Cassandru. Vraćanje će stvoriti veliki broj nadgrobnih spomenika, š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 sa postojećim podacima u njoj je također snimanje. Odnosno, brisanjem nepotrebnih jednostavno ćemo proizvesti još više zapisa, a samo neki od njih će biti označeni nadgrobnim spomenicima.
Istek vremena prilikom umetanja. Kasandra je prelepa na snimku, ali ponekad je dolazni tok može značajno zbuniti. Ovo se dešava kada aplikacija počne da kruži oko nekoliko zapisa koji se iz nekog razloga ne mogu umetnuti. I trebat će nam pravi DBA koji će nadgledati gc.log, sistemske i debug dnevnike za spore upite, metriku na čekanju sažimanja.
Nekoliko data centara u klasteru. Odakle čitati i gdje pisati?
Možda podijeliti 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 pravim podijeljenim mozgom ako odaberemo pogrešan nivo postojanosti? Puno je pitanja, puno nepoznatih postavki, mogućnosti sa kojima zaista želite da se pozabavite.
Kako smo odlučili
Da bi se spriječilo potonuće čvora, SWAP je onemogućen. A sada, ako postoji nedostatak memorije, čvor treba da se spusti i ne stvara velike gc pauze.
Dakle, više se ne oslanjamo na logiku u bazi podataka. Programeri aplikacija se preobučavaju i počinju aktivno poduzeti mjere opreza u svom vlastitom kodu. Idealno jasno razdvajanje skladištenja i obrade podataka.
Kupili smo podršku od DataStaxa. Razvoj Boxed Cassandre je već zaustavljen (poslednje uređivanje je bilo u februaru 2018.). Istovremeno, Datastax nudi odličnu uslugu i veliki broj modificiranih i prilagođenih rješenja za postojeća IP rješenja.
Također želim napomenuti da Cassandra nije baš zgodna za upite za odabir. Naravno, CQL je veliki korak naprijed za korisnike (u poređenju sa Triftom). Ali ako imate čitava odjeljenja koja su navikla na tako zgodno spajanje, besplatno filtriranje prema bilo kojem polju i mogućnosti optimizacije upita, a ti odjeli rade na rješavanju pritužbi i nesreća, onda im se rješenje o Cassandri čini neprijateljskim i glupim. I počeli smo da odlučujemo kako bi naše kolege trebalo da prave uzorke.
Razmotrili smo dvije opcije.U prvoj opciji pišemo pozive ne samo u C*, već iu arhiviranu Oracle bazu podataka. Samo, za razliku od C*, ova baza podataka čuva pozive samo za tekući mjesec (dovoljna dubina skladištenja poziva za slučajeve dopune). Ovdje smo odmah uočili sljedeći problem: ako pišemo sinhrono, onda gubimo sve prednosti C* povezane s brzim umetanjem; ako pišemo asinhrono, nema garancije da su svi potrebni pozivi uopće dospjeli u Oracle. Postojao je jedan plus, ali veliki: za rad ostaje isti poznati PL/SQL Developer, odnosno praktično implementiramo obrazac „Facade“, alternativna opcija. Implementiramo mehanizam koji oslobađa pozive iz C*, izvlači neke podatke za obogaćivanje iz odgovarajućih tabela u Oracleu, spaja rezultujuće uzorke i daje nam rezultat, koji onda nekako koristimo (povratimo, ponovimo, analiziramo, divimo se). Protiv: proces je prilično višestruki, a osim toga, nema interfejsa za operativne zaposlene.
Na kraju smo se odlučili na drugu opciju. Apache Spark je korišten za uzorkovanje iz različitih tegli. Suština mehanizma je svedena na Java kod, koji pomoću navedenih ključeva (pretplatnik, vrijeme poziva - ključevi sekcije) 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 tabeli. Nacrtali smo web lice preko iskre i pokazalo se prilično upotrebljivo.
Prilikom rješavanja problema ažuriranja podataka industrijskih testova ponovo smo razmotrili nekoliko rješenja. I transfer putem Sstloader-a i mogućnost podjele klastera u test zoni na dva dijela, od kojih svaki naizmjenično pripada istom klasteru sa promotivnim, te se na taj način napaja od njega. Prilikom ažuriranja testa planirano je njihovo zamjenjivanje: dio koji je radio u testu se briše i ulazi u proizvodnju, a drugi počinje odvojeno raditi s podacima. Međutim, nakon ponovnog razmišljanja, racionalnije smo procijenili podatke koje je vrijedilo prenijeti i shvatili da su sami pozivi nekonzistentan entitet za testove, koji se po potrebi brzo generira, a promotivni skup podataka nema vrijednost za prijenos na test. Postoji nekoliko skladišnih objekata koje vrijedi premjestiti, ali ovo je doslovno par stolova, i to ne baš teških. Stoga mi Kao rješenje, opet je u pomoć priskočio 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 nam omogućava da radimo bez vraćanja. Prije promocije slijedi obavezna probna vožnja, gdje greška nije tako skupa. U slučaju neuspjeha, uvijek možete ispustiti casespace i pokrenuti cijelu šemu od početka.
Da biste osigurali stalnu dostupnost Cassandre, potreban vam je dba i ne samo on. Svi koji rade sa aplikacijom moraju razumjeti gdje i kako gledati na trenutnu situaciju i kako na vrijeme dijagnosticirati probleme. Da bismo to uradili, aktivno koristimo DataStax OpsCenter (Administracija i praćenje radnih opterećenja), sistemske metrike Cassandra Driver (broj vremenskih čekanja za pisanje na C*, broj vremenskih ograničenja za čitanje sa C*, maksimalna latencija, itd.), pratimo rad same aplikacije, radeći sa Cassandrom.
Kada smo razmišljali o prethodnom pitanju, shvatili smo gdje bi mogao biti naš glavni rizik. Ovo su obrasci za prikaz podataka koji prikazuju podatke iz nekoliko nezavisnih upita do skladišta. Na ovaj način možemo dobiti prilično nedosljedne informacije. Ali ovaj problem bi bio jednako relevantan da radimo samo sa jednim data centrom. Dakle, najrazumnije je, naravno, kreirati batch funkciju za čitanje podataka na aplikaciji treće strane, koja će osigurati da podaci budu primljeni u jednom vremenskom periodu. Što se tiče podjele na čitanje i pisanje u smislu performansi, ovdje nas je zaustavio rizik da bi sa nekim gubitkom veze između DC-a mogli završiti sa dva klastera koji su međusobno potpuno neusklađeni.
Kao rezultat, za sada zaustavljeno na nivou konzistentnosti za pisanje EACH_QUORUM, za čitanje - LOCAL_QUORUM
Kratki utisci i zaključci
Kako bismo procijenili rezultirajuće rješenje sa stanovišta operativne podrške i perspektiva daljeg razvoja, odlučili smo razmisliti gdje bi se još takav razvoj mogao primijeniti.
Odmah nakon toga, ocjenjivanje podataka za programe poput „Plati kada je zgodno“ (informacije učitavamo u C*, izračunavanje pomoću Spark skripte), obračunavanje potraživanja sa agregacijom po oblastima, pohranjivanje uloga i izračunavanje prava pristupa korisnika na osnovu uloge matrica.
Kao što vidite, repertoar je širok i raznovrstan. A ako izaberemo tabor pristalica/protivnika NoSQL-a, onda ćemo se pridružiti pristalicama, pošto smo svoje prednosti primili, i to upravo tamo gdje smo očekivali.
Čak i Cassandra opcija izvan kutije omogućava horizontalno skaliranje u realnom vremenu, apsolutno bezbolno rješavajući problem povećanja podataka u sistemu. Uspeli smo da premestimo mehanizam sa velikim opterećenjem za izračunavanje agregata poziva u zasebno kolo, a takođe odvojimo šemu i logiku aplikacije, oslobodivši se loše prakse pisanja prilagođenih poslova i objekata u samoj bazi podataka. Dobili smo priliku da biramo i konfiguriramo, da ubrzamo, na kojim DC-ovima ćemo vršiti proračune i na koje ćemo snimati podatke, osigurali smo se od kvarova kako pojedinačnih čvorova tako i DC-a u cjelini.
Primjenjujući našu arhitekturu na nove projekte, a već imam određeno iskustvo, želio bih odmah uzeti u obzir gore opisane nijanse i spriječiti neke greške, izgladiti neke oštre uglove koji se u početku nisu mogli izbjeći.
Na primjer, pratite Cassandrina ažuriranja na vrijemejer je dosta problema koje smo dobili već poznato i otklonjeno.
Nemojte stavljati i samu bazu podataka i Spark na iste čvorove (ili striktno podijeliti s količinom dozvoljenog korištenja resursa), budući da Spark može pojesti više OP-a nego što se očekivalo, i brzo ćemo dobiti problem broj 1 sa naše liste.
Poboljšati nadzor 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 je to ono o čemu će struktura baze podataka u konačnici ovisiti.
Okrenite rezultujući krug nekoliko puta za moguću optimizaciju. Odaberite koja polja se mogu serijalizirati. Shvatite koje dodatne tabele treba da napravimo da bismo što tačnije i optimalnije uzeli u obzir, a zatim dajte potrebne informacije na zahtev (na primer, uz pretpostavku da iste podatke možemo pohraniti u različite tabele, uzimajući u obzir različite raščlanjenosti prema različitim kriterijima, možemo značajno uštedjeti CPU vrijeme za zahtjeve za čitanje).
Nije loše Odmah osigurajte priključivanje TTL-a i čišćenje zastarjelih podataka.
Prilikom preuzimanja podataka sa Cassandre Logika aplikacije treba da radi na principu FETCH, tako da se svi redovi ne učitavaju u memoriju odjednom, već se biraju u grupama.
Preporučljivo je prije prenošenja projekta na opisano rješenje provjerite toleranciju grešaka sistema provodeći niz testova sudara, kao što je gubitak podataka u jednom data centru, obnavljanje oštećenih podataka u određenom periodu, prekid mreže između data centara. Takvi testovi ne samo da će omogućiti da se procijene prednosti i nedostaci predložene arhitekture, već će također pružiti dobru praksu zagrijavanja za inženjere koji ih sprovode, a stečena vještina će biti daleko od suvišne ako se kvarovi sistema reproduciraju u proizvodnji.
Ako radimo sa kritičnim informacijama (kao što su podaci za naplatu, obračun pretplatničkog duga), onda je vrijedno obratiti pažnju i na alate koji će smanjiti rizike koji nastaju zbog karakteristika DBMS-a. Na primjer, koristite uslužni program nodesync (Datastax), nakon što ste razvili optimalnu strategiju za njegovu upotrebu kako biste radi dosljednosti, nemojte stvarati pretjerano opterećenje na Kasandru i koristiti ga samo za određene tabele u određenom periodu.
Šta se dešava sa Kasandrom nakon šest meseci života? Generalno, nema neriješenih problema. Takođe nismo dozvolili ozbiljne nezgode ili gubitak podataka. Da, morali smo razmišljati o kompenziranju nekih problema koji se ranije nisu javljali, ali to na kraju nije mnogo pomutilo naše arhitektonsko rješenje. Ako želite i ne plašite se isprobati nešto novo, a u isto vrijeme ne želite biti previše razočarani, onda se pripremite na činjenicu da ništa nije besplatno. Morat ćete razumjeti, udubiti se u dokumentaciju i sastaviti svoj individualni rake više nego u starom naslijeđenom rješenju, a nijedna teorija vam neće unaprijed reći koji rake vas čeka.
izvor: www.habr.com