Se sizze dat alles yn it libben is it wurdich te besykjen op syn minst ien kear. En as jo wend binne om te wurkjen mei relasjonele DBMS's, dan is it de muoite wurdich om yn 'e praktyk kennis te meitsjen mei NoSQL, earst fan alle, op syn minst foar algemiene ûntwikkeling. No, troch de rappe ûntwikkeling fan dizze technology, binne d'r in protte tsjinstridige mieningen en heulende debatten oer dit ûnderwerp, dy't benammen ynteresse stimulearje.
As jo dûke yn 'e essinsje fan al dizze skelen, kinne jo sjen dat se ûntsteane troch de ferkearde oanpak. Dejingen dy't NoSQL-databases brûke krekt wêr't se nedich binne binne tefreden en krije alle foardielen fan dizze oplossing. En eksperiminten dy't op dizze technology fertrouwe as in panacea wêr't it hielendal net fan tapassing is, binne teloarsteld, nei't se de sterke punten fan relasjonele databases ferlern hawwe sûnder signifikante foardielen te krijen.
Ik sil jo fertelle oer ús ûnderfining by it ymplementearjen fan in oplossing basearre op 'e Cassandra DBMS: wat wy te krijen hawwe, hoe't wy út drege situaasjes kamen, oft wy profitearje koene fan it brûken fan NoSQL en wêr't wy ekstra ynspanningen / fûnsen moasten ynvestearje .
De earste taak is om in systeem te bouwen dat petearen opnimt yn in soarte fan opslach.
It bestjoeringssysteem prinsipe fan it systeem is as folget. De ynfier befettet triemmen mei in spesifike struktuer dy't de struktuer fan 'e oprop beskriuwt. De applikaasje soarget dan derfoar dat dizze struktuer wurdt opslein yn 'e passende kolommen. Yn 'e takomst wurde de bewarre oproppen brûkt om ynformaasje te werjaan oer ferkearskonsumpsje foar abonnees (kosten, oproppen, balânsskiednis).
It is dúdlik wêrom't se Cassandra keazen hawwe - se skriuwt as in masinegewear, is maklik skalberber en fouttolerant.
Dat, dit is wat ûnderfining ús joech
Ja, in mislearre knooppunt is gjin trageedzje. Dit is de essinsje fan Cassandra's skuldtolerânsje. Mar in knooppunt kin libje en tagelyk begjinne te lijen yn prestaasjes. Sa die bliken, dit hat fuortendaliks ynfloed op de prestaasjes fan it hiele kluster.
Cassandra sil jo net beskermje wêr't Oracle jo bewarre hat mei syn beheiningen. En as de skriuwer fan 'e applikaasje dit net fan tefoaren begriep, dan is de dûbele dy't Cassandra oankaam net slimmer as it orizjineel. Sadree't it is oankommen, sette wy it yn.
IB hie de frije Cassandra út 'e doaze sterk: D'r is gjin logging fan brûkersaksjes, gjin differinsjaasje fan rjochten. Ynformaasje oer petearen wurdt beskôge as persoanlike gegevens, wat betsjut dat alle besykjen om it op ien of oare manier oan te freegjen/feroarje moatte wurde ynlogd mei de mooglikheid fan folgjende kontrôle. Jo moatte ek bewust wêze fan 'e needsaak om rjochten op ferskate nivo's te skieden foar ferskate brûkers. In ienfâldige operaasje-yngenieur en in superadmin dy't de hiele kaairomte frij kinne wiskje binne ferskate rollen, ferskate ferantwurdlikheden en kompetinsjes. Sûnder sa'n differinsjaasje fan tagongsrjochten komme de wearde en yntegriteit fan 'e gegevens daliks flugger yn fraach as by it ELKE konsistinsjenivo.
Wy hawwe net rekken holden dat oproppen sawol serieuze analytyk as periodike sampling nedich binne foar in ferskaat oan betingsten. Om't de selekteare records dan moatte wurde wiske en opnij skreaun (as diel fan 'e taak moatte wy it proses fan it bywurkjen fan gegevens stypje as de gegevens yn earste ynstânsje ferkeard yn ús lus ynfierd binne), is Cassandra hjir net ús freon. Cassandra is as in piggy bank - it is handich om dingen yn te setten, mar jo kinne der net yn rekkenje.
Wy hawwe in probleem tsjinkaam by it oerdragen fan gegevens nei testsônes (5 knopen yn 'e test tsjin 20 yn' e prom). Yn dit gefal kin de dump net brûkt wurde.
It probleem mei it bywurkjen fan it gegevensskema fan in applikaasje dy't skriuwt nei Cassandra. In rollback sil in protte grêfstiennen generearje, wat kin liede ta produktiviteitsferlies op ûnfoarspelbere manieren.. Cassandra is optimalisearre foar opname, en tinkt net folle foar it skriuwen. Elke operaasje mei besteande gegevens deryn is ek in opname. Dat is, troch it wiskjen fan it ûnnedige, sille wy gewoan noch mear records produsearje, en allinich guon fan har sille wurde markearre mei grêfstiennen.
Timeouts by it ynfoegjen. Cassandra is moai yn de opname, mar soms kin de ynkommende stream har signifikant puzzle. Dit bart as de applikaasje begjint te fytsen om ferskate records dy't om ien of oare reden net kinne wurde ynfoege. En wy sille in echte DBA nedich wêze dy't gc.log, systeem- en debug-logs sil kontrolearje foar trage queries, metriken oer komprimearjen yn ôfwachting.
Ferskate datasintra yn in kluster. Wêr te lêzen en wêr te skriuwen?
Miskien splitst yn lêzen en skriuwen? En as dat sa is, moat der dan in DC tichter by de oanfraach komme foar skriuwen of lêzen? En sille wy net einigje mei in echte split harsens as wy kieze it ferkearde gearhing nivo? D'r binne in protte fragen, in protte ûnbekende ynstellings, mooglikheden wêr't jo echt mei tinke wolle.
Hoe hawwe wy besletten
Om foar te kommen dat it knooppunt sinkt, hawwe wy SWAP útskeakele. En no, as d'r in gebrek oan ûnthâld is, moat de knoop nei ûnderen gean en gjin grutte gc-pauzes meitsje.
Dat, wy fertrouwe net mear op logika yn 'e database. Applikaasje-ûntwikkelders leare harsels op en begjinne aktyf foarsoarchsmaatregels te nimmen yn har eigen koade. Ideal dúdlike skieding fan gegevens opslach en ferwurking.
Wy kochten stipe fan DataStax. De ûntwikkeling fan boxed Cassandra is al ophâlden (de lêste commit wie yn febrewaris 2018). Tagelyk biedt Datastax poerbêste service en in grut oantal oanpaste en oanpaste oplossingen foar besteande IP-oplossingen.
Ik wol ek opmerke dat Cassandra net heul handich is foar seleksjefragen. Fansels is CQL in grutte stap foarút foar brûkers (ferlike mei Trift). Mar as jo folsleine ôfdielingen hawwe dy't wend binne oan sokke handige joins, fergees filterjen troch elk fjild en query-optimisaasjemooglikheden, en dizze ôfdielingen wurkje om klachten en ûngemakken op te lossen, dan liket de oplossing op Cassandra har fijannich en dom. En wy begûnen te besluten hoe't ús kollega's samples meitsje moatte.
Wy hawwe twa opsjes beskôge: Yn 'e earste opsje skriuwe wy net allinich yn C *, mar ek yn' e argivearre Oracle-database. Allinnich, yn tsjinstelling ta C *, bewarret dizze databank oproppen allinich foar de aktuele moanne (genôch opslachdjipte foar opladen fan gefallen). Hjir seagen wy daliks it folgjende probleem: as wy synchroon skriuwe, dan ferlieze wy alle foardielen fan C * ferbûn mei rappe ynfoegje; as wy asynchronysk skriuwe, is d'r gjin garânsje dat alle nedige oproppen hielendal yn Oracle kamen. D'r wie ien plus, mar in grut: foar operaasje bliuwt deselde fertroude PL/SQL-ûntwikkelder, d.w.s. wy implementearje it patroan "Facade" praktysk. In alternative opsje. Wy ymplementearje in meganisme dat oproppen fan C * unloads, lûkt wat gegevens foar ferriking fan 'e oerienkommende tabellen yn Oracle, slút oan by de resultearjende samples en jout ús it resultaat, dat wy dan op ien of oare manier brûke (weromrolje, werhelje, analysearje, bewûnderje). Cons: it proses is frij multi-stap, en boppedat, der is gjin ynterface foar operaasje meiwurkers.
Uteinlik hawwe wy fêststeld op 'e twadde opsje. Apache Spark waard brûkt om te stekken út ferskate potten. De essinsje fan it meganisme is fermindere ta Java-koade, dy't mei de oantsjutte kaaien (abonnee, tiid fan oprop - seksjekaaien) gegevens út C * lûkt, lykas de nedige gegevens foar ferriking út elke oare database. Wêrnei't it by har yn har ûnthâld komt en it resultaat toant yn 'e resultearjende tabel. Wy tekenen in webgesicht oer de fonk en it waard frij brûkber.
By it oplossen fan it probleem fan it bywurkjen fan yndustriële testgegevens, hawwe wy wer ferskate oplossingen beskôge. Sawol oerdracht fia Sstloader en de opsje fan splitsing it kluster yn de test sône yn twa dielen, elk fan dy ôfwikseljend heart ta deselde kluster mei de promosjonele ien, dus wurdt oandreaun troch it. By it bywurkjen fan de test wie it pland om se te wikseljen: it diel dat wurke yn 'e test wurdt wiske en yn produksje ynfierd, en de oare begjint te wurkjen mei de gegevens apart. Lykwols, nei it tinken wer, wy mear rasjoneel beoardiele de gegevens dy't wie it wurdich oerdracht, en realisearre dat de oproppen sels binne in ynkonsistente entiteit foar tests, gau oanmakke as it nedich is, en it is de promoasjegegevens set dy't hat gjin wearde foar oerdracht nei de toets. D'r binne ferskate opslachobjekten dy't it wurdich binne te ferpleatsen, mar dit binne letterlik in pear tafels, en net heul swier. Dêrom wy as in oplossing, Spark wer kaam ta de rêding, mei help fan dat wy skreau en begûn aktyf te brûken in skript foar it oerdragen fan gegevens tusken tabellen, prom-test.
Us hjoeddeistige ynsetbelied lit ús wurkje sûnder rollbacks. Foar de promo is d'r in ferplichte testrun, wêr't in flater net sa djoer is. Yn gefal fan mislearring, kinne jo altyd falle de casespace en rôlje it hiele skema fan it begjin ôf.
Om te garandearjen trochgeande beskikberens fan Cassandra, Jo moatte in dba en net allinnich him. Elkenien dy't mei de applikaasje wurket, moat begripe wêr't en hoe te sjen nei de hjoeddeistige situaasje en hoe't problemen op 'e tiid kinne diagnoaze. Om dit te dwaan, brûke wy aktyf DataStax OpsCenter (Bestjoer en tafersjoch op wurkloads), Cassandra Driver-systeemmetriken (oantal time-outs foar skriuwen nei C *, oantal time-outs foar lêzen fan C *, maksimale latency, ensfh.), kontrolearje de operaasje fan 'e applikaasje sels, wurkje mei Cassandra.
Doe't wy oer de foarige fraach tochten, realisearren wy wêr't ús wichtichste risiko lizze soe. Dit binne formulieren foar werjaan fan gegevens dy't gegevens werjaan fan ferskate ûnôfhinklike fragen nei de opslach. Op dizze manier kinne wy frij inkonsistinte ynformaasje krije. Mar dit probleem soe krekt sa relevant wêze as wy mei mar ien datasintrum wurken. Dat it meast ridlike ding hjir is fansels om in batchfunksje te meitsjen foar it lêzen fan gegevens op in applikaasje fan tredden, dy't derfoar soarget dat gegevens yn ien inkelde perioade ûntfongen wurde. Wat de opdieling yn it lêzen en skriuwen oangiet op it mêd fan prestaasjes, hjir waard it risiko tsjinholden dat wy by wat ferbiningsferlies tusken de DC's útrinne koene op twa klusters dy't folslein ynkonsistint binne mei inoar.
As gefolch, foar no stoppe op it konsistinsjenivo foar it skriuwen fan EACH_QUORUM, foar it lêzen - LOCAL_QUORUM
Koarte yndrukken en konklúzjes
Om de oplossing te evaluearjen út it eachpunt fan operasjonele stipe en perspektyf foar fierdere ûntwikkeling, hawwe wy besletten om nei te tinken wêr't sa'n ûntwikkeling oars tapast wurde koe.
Rjochts fan 'e bat, dan gegevens skoare foar programma's lykas "Betelje as it handich is" (wy laden ynformaasje yn C *, berekkening mei Spark-skripts), rekkening foar oanspraken mei aggregaasje per gebiet, opslaan fan rollen en berekkenjen fan tagongsrjochten fan brûkers basearre op 'e rol matrix.
Sa't jo sjen kinne, it repertoire is breed en fariearre. En as wy kieze foar it kamp fan supporters / tsjinstanners fan NoSQL, dan sille wy meidwaan oan de supporters, sûnt wy krigen ús foardielen, en krekt wêr't wy ferwachte.
Sels de Cassandra-opsje út 'e doaze lit horizontale skaalfergrutting yn realtime mooglik meitsje, it probleem fan tanimmende gegevens yn it systeem absolút pynlik op te lossen. Wy wienen by steat om te ferpleatsen in hiel hege-load meganisme foar it berekkenjen fan oprop aggregaten yn in apart circuit, en ek skiede de applikaasje skema en logika, it kwytreitsje fan 'e minne praktyk fan in skriuwen oanpaste banen en objekten yn de databank sels. Wy krigen de kâns om te kiezen en te konfigurearjen, om te fersnellen, op hokker DC's wy berekkeningen sille útfiere en op hokker wy gegevens sille opnimme, wy fersekere ússels tsjin crashes fan sawol yndividuele knooppunten as de DC as gehiel.
Us arsjitektuer tapasse op nije projekten, en al wat ûnderfining hawwe, wol ik fuortendaliks rekken hâlde mei de hjirboppe beskreaune nuânses, en foarkomme wat flaters, glêd út wat skerpe hoeken dy't yn earste ynstânsje net kinne wurde foarkommen.
Bygelyks, hâld de updates fan Cassandra op 'e tiid byom't nochal in pear fan 'e problemen dy't wy krigen wiene al bekend en fêst.
Set sawol de databank sels as Spark net op deselde knopen (of strang diele troch it bedrach fan tastiene boarne gebrûk), sûnt Spark kin ite mear OP as ferwachte, en wy sille gau krije probleem nûmer 1 út ús list.
Ferbetterje tafersjoch en operasjonele kompetinsje yn 'e projektteststadium. Nim yn earste ynstânsje safolle mooglik rekken mei alle potensjele konsuminten fan ús oplossing, om't dit is wêr't de databankstruktuer úteinlik fan ôfhingje sil.
Rotearje it resultearjende circuit ferskate kearen foar mooglike optimalisaasje. Selektearje hokker fjilden kinne wurde serialized. Begripe hokker oanfoljende tabellen wy meitsje moatte om it meast korrekt en optimaal yn 'e rekken te hâlden, en dan op oanfraach de nedige ynformaasje leverje (bygelyks troch oan te nimmen dat wy deselde gegevens yn ferskate tabellen opslaan kinne, rekken hâldend mei ferskate ferdielingen neffens ferskillende kritearia, kinne wy signifikant besparje CPU-tiid foar lêsoanfragen).
Net min Soarch direkt foar taheakjen fan TTL en skjinmeitsjen fan ferâldere gegevens.
By it ynladen fan gegevens fan Cassandra De applikaasjelogika moat wurkje op it FETCH-prinsipe, sadat net alle rigen tagelyk yn it ûnthâld laden wurde, mar yn batches selektearre wurde.
It is oan te rieden om it projekt oer te setten nei de beskreaune oplossing kontrolearje de fouttolerânsje fan it systeem troch in searje crashtests út te fieren, lykas gegevensferlies yn ien datasintrum, restauraasje fan beskeadige gegevens oer in bepaalde perioade, netwurkferlies tusken datasintra. Sokke tests sille net allinich de foar- en neidielen fan 'e foarstelde arsjitektuer kinne evaluearje, mar sille ek in goede opwaarmingspraktyk leverje foar de yngenieurs dy't se útfiere, en de oanhelle feardigens sil fier fan oerstallich wêze as systeemfalen wurde reprodusearre yn produksje.
As wy wurkje mei krityske ynformaasje (lykas gegevens foar fakturearring, berekkening fan abonneeskuld), dan is it ek wurdich omtinken te jaan oan ark dy't de risiko's sille ferminderje dy't ûntsteane troch de funksjes fan 'e DBMS. Brûk bygelyks it nodesync-hulpprogramma (Datastax), nei't jo in optimale strategy ûntwikkele hawwe foar it gebrûk yn 'e oarder omwille fan konsistinsje, meitsje gjin oerstallige lading op Cassandra en brûk it allinnich foar bepaalde tabellen yn in bepaalde perioade.
Wat bart der mei Cassandra nei seis moannen fan it libben? Yn 't algemien binne d'r gjin ûnoploste problemen. Wy hawwe ek gjin serieuze ûngelokken of gegevensferlies talitten. Ja, wy moasten tinke oer it kompensearjen fan guon problemen dy't net earder ûntstien wiene, mar dit hat ús arsjitektoanyske oplossing op it lêst net folle bewolkt. As jo wolle en net bang binne om wat nijs te besykjen, en tagelyk net te teloarsteld wolle, meitsje jo dan klear foar it feit dat neat fergees is. Jo moatte begripe, ferdjipje yn 'e dokumintaasje en sammelje jo eigen yndividuele rake mear as yn' e âlde legacy-oplossing, en gjin teory sil jo fan tefoaren fertelle hokker rake op jo wachtet.
Boarne: www.habr.com