Ili diras, ke ĉio en la vivo indas provi almenaŭ unufoje. Kaj se vi kutimas labori kun interrilataj DBMS-oj, tiam indas konatiĝi kun NoSQL praktike, antaŭ ĉio, almenaŭ por ĝenerala disvolviĝo. Nun, pro la rapida disvolviĝo de ĉi tiu teknologio, ekzistas multaj konfliktaj opinioj kaj ekscititaj debatoj pri ĉi tiu temo, kiu precipe nutras intereson.
Se vi enprofundiĝas en la esencon de ĉiuj ĉi tiuj disputoj, vi povas vidi, ke ili ŝprucas pro malĝusta aliro. Tiuj, kiuj uzas NoSQL-datumbazon ĝuste kie ili estas bezonataj, estas kontentaj kaj ricevas ĉiujn avantaĝojn de ĉi tiu solvo. Kaj eksperimentantoj, kiuj fidas je ĉi tiu teknologio kiel panaceo, kie ĝi tute ne aplikeblas, estas seniluziigitaj, perdinte la fortojn de interrilataj datumbazoj sen akiri gravajn avantaĝojn.
Mi rakontos al vi pri nia sperto pri efektivigo de solvo bazita sur la Cassandra DBMS: kion ni devis alfronti, kiel ni eliris el malfacilaj situacioj, ĉu ni povis profiti de uzado de NoSQL kaj kie ni devis investi pliajn klopodojn/fondaĵojn. .
La komenca tasko estas konstrui sistemon kiu registras vokojn en iu speco de stokado.
La funkcia principo de la sistemo estas kiel sekvas. La enigo inkluzivas dosierojn kun specifa strukturo, kiu priskribas la strukturon de la voko. La aplikaĵo tiam certigas, ke ĉi tiu strukturo estas konservita en la taŭgaj kolumnoj. Estontece, la konservitaj alvokoj estas uzataj por montri informojn pri trafika konsumo por abonantoj (kostoj, vokoj, bilanco-historio).
Estas sufiĉe klare, kial ili elektis Cassandra - ŝi skribas kiel maŝinpafilo, estas facile skalebla kaj mistolerema.
Do, jen kion la sperto donis al ni
Jes, malsukcesa nodo ne estas tragedio. Jen la esenco de la faŭltoleremo de Kasandra. Sed nodo povas esti viva kaj samtempe komenci suferi en rendimento. Kiel evidentiĝis, ĉi tio tuj influas la agadon de la tuta areto.
Kasandra ne protektos vin kie Orakolo savis vin per siaj limoj. Kaj se la aŭtoro de la aplikaĵo ne komprenis ĉi tion anticipe, tiam la duoblo, kiu alvenis por Cassandra, ne estas pli malbona ol la originalo. Post kiam ĝi alvenos, ni enmetos ĝin.
IB forte malŝatis la liberan Kasandra el la skatolo: Ne estas protokolado de uzantaj agoj, neniu diferencigo de rajtoj. Informoj pri alvokoj estas konsiderataj personaj datumoj, kio signifas, ke ĉiuj provoj peti/ŝanĝi ĝin iel ajn devas esti registritaj kun la ebleco de posta revizio. Ankaŭ, vi devas esti konscia pri la bezono apartigi rajtojn je malsamaj niveloj por malsamaj uzantoj. Simpla operacia inĝeniero kaj superadministranto, kiu povas libere forigi la tutan ŝlosilspacon, estas malsamaj roloj, malsamaj respondecoj kaj kompetentecoj. Sen tia diferencigo de alirrajtoj, la valoro kaj integreco de la datumoj tuj demandos pli rapide ol kun la IUJ-konsekvenca nivelo.
Ni ne konsideris, ke vokoj postulas kaj seriozan analizon kaj periodan specimenigon por diversaj kondiĉoj. Ĉar la elektitaj registroj tiam supozeble estas forigitaj kaj reverkitaj (kiel parto de la tasko, ni devas subteni la procezon de ĝisdatigo de datumoj kiam la datumoj komence eniris nian buklon malĝuste), Cassandra ne estas nia amiko ĉi tie. Kasandra estas kiel ŝparbanko - estas oportune enmeti aferojn, sed vi ne povas kalkuli en ĝi.
Ni renkontis problemon pri transdono de datumoj al testaj zonoj (5 nodoj en la testo kontraŭ 20 en la finbalo). En ĉi tiu kazo, la rubejo ne povas esti uzata.
La problemo pri ĝisdatigo de la datumskemo de aplikaĵo skribanta al Cassandra. Retroiĝo generos multajn tomboŝtonojn, kiuj povas konduki al produktiveco perdoj en neantaŭvideblaj manieroj.. Cassandra estas optimumigita por registrado, kaj ne multe pensas antaŭ skribi.Ĉiu operacio kun ekzistantaj datumoj en ĝi ankaŭ estas registrado. Tio estas, per forigo de la nenecesa, ni simple produktos eĉ pli da rekordoj, kaj nur kelkaj el ili estos markitaj per tomboŝtonoj.
Tempoj dum enmetado. Kasandra estas bela en la registrado, sed foje la envenanta fluo povas signife konfuzi ŝin. Ĉi tio okazas kiam la aplikaĵo komencas cirkuli ĉirkaŭ pluraj rekordoj, kiuj ial ne povas esti enmetitaj. Kaj ni bezonos veran DBA, kiu kontrolos gc.log, sistemajn kaj sencimigajn protokolojn por malrapidaj demandoj, mezuroj pri kompaktado atendataj.
Pluraj datumcentroj en areto. De kie legi kaj kie skribi?
Eble dividita en legado kaj skribo? Kaj se jes, ĉu estu DC pli proksima al la aplikaĵo por skribi aŭ legado? Kaj ĉu ni ne finos kun vera dividita cerbo, se ni elektos la malĝustan konsekvencan nivelon? Estas multaj demandoj, multaj nekonataj agordoj, eblecoj, kiujn vi vere volas tuŝi.
Kiel ni decidis
Por malhelpi la nodon sinki, SWAP estis malŝaltita. Kaj nun, se mankas memoro, la nodo devus malsupreniri kaj ne krei grandajn gc-paŭzojn.
Do, ni ne plu fidas sur logiko en la datumbazo. Programistoj de aplikaĵoj retrejnas sin kaj komencas aktive preni antaŭzorgojn en sia propra kodo. Ideala klara apartigo de datumstokado kaj prilaborado.
Ni aĉetis subtenon de DataStax. La disvolviĝo de boksita Kasandra jam ĉesis (la lasta kompromiso estis en februaro 2018). Samtempe, Datastax ofertas bonegan servon kaj grandan nombron da modifitaj kaj adaptitaj solvoj por ekzistantaj IP-solvoj.
Mi ankaŭ volas rimarki, ke Kasandra ne estas tre oportuna por elektodemandoj. Kompreneble, CQL estas granda paŝo antaŭen por uzantoj (kompare kun Trift). Sed se vi havas tutajn fakojn, kiuj estas alkutimiĝintaj al tiaj oportunaj kuniĝoj, senpaga filtrado laŭ iu ajn kampo kaj demandaj optimumigo-kapabloj, kaj ĉi tiuj fakoj laboras por solvi plendojn kaj akcidentojn, tiam la solvo sur Cassandra ŝajnas malamika kaj stulta al ili. Kaj ni komencis decidi kiel niaj kolegoj devus fari specimenojn.
Ni konsideris du eblojn.En la unua opcio, ni skribas vokojn ne nur en C*, sed ankaŭ en la arkivita Oracle-datumbazo. Nur, male al C*, ĉi tiu datumbazo stokas vokojn nur por la nuna monato (sufiĉa profundeco de stokado de vokoj por reŝargado de kazoj). Ĉi tie ni tuj vidis la sekvan problemon: se ni skribas sinkrone, tiam ni perdas ĉiujn avantaĝojn de C* asociitaj kun rapida enmeto; se ni skribas nesinkrone, ne estas garantio, ke ĉiuj necesaj alvokoj entute eniris Oracle. Estis unu pluso, sed granda: por funkciado restas la sama konata PL/SQL-Ellaboranto, t.e. ni praktike efektivigas la ŝablonon "Fasado". Alternativa opcio. Ni efektivigas mekanismon kiu malŝarĝas alvokojn de C*, tiras kelkajn datumojn por riĉigo de la respondaj tabeloj en Oracle, kunigas la rezultajn specimenojn kaj donas al ni la rezulton, kiun ni tiam iel uzas (reruli, ripeti, analizi, admiri). Malavantaĝoj: la procezo estas sufiĉe plurpaŝa, kaj krome ne ekzistas interfaco por operaciaj dungitoj.
En la fino, ni decidis por la dua opcio. Apache Spark kutimis specimeni el malsamaj vazoj. La esenco de la mekanismo estis reduktita al Java-kodo, kiu, uzante la specifitajn klavojn (abonanto, tempo de voko - sekciaj klavoj), eltiras datumojn el C*, same kiel la necesajn datumojn por riĉigo de iu ajn alia datumbazo. Post tio ĝi kunigas ilin en sia memoro kaj montras la rezulton en la rezulta tabelo. Ni desegnis retan vizaĝon super la fajrero kaj ĝi montriĝis sufiĉe uzebla.
Solvante la problemon ĝisdatigi industriajn testajn datumojn, ni denove pripensis plurajn solvojn. Ambaŭ translokigo per Sstloader kaj la opcio dividi la areton en la testzono en du partojn, ĉiu el kiuj alterne apartenas al la sama areto kun la reklama, tiel funkciigita de ĝi. Ĝisdatigante la teston, oni planis interŝanĝi ilin: la parto, kiu funkciis en la testo, estas forigita kaj enigita en produktadon, kaj la alia komencas labori kun la datumoj aparte. Tamen, repensinte, ni pli racie taksis la datumojn, kiuj indas transdoni, kaj rimarkis, ke la alvokoj mem estas malkonsekvenca ento por testoj, rapide generitaj se necese, kaj ĝi estas la varba datumaro kiu ne havas valoron por translokigo al la testo. Estas pluraj stokaj objektoj, kiuj indas movi, sed ĉi tiuj estas laŭvorte kelkaj tabloj, kaj ne tre pezaj. Tial ni kiel solvo, Spark denove venis al la rekupero, kun la helpo de kiu ni skribis kaj komencis aktive uzi skripton por transdoni datumojn inter tabloj, prom-testo.
Nia nuna deploja politiko ebligas al ni labori sen retrovojoj. Antaŭ la promocio, estas deviga provo, kie eraro ne estas tiom multekosta. En kazo de malsukceso, vi ĉiam povas faligi la kazspacon kaj ruliĝi la tutan skemon de la komenco.
Por certigi daŭran haveblecon de Cassandra, vi bezonas dba kaj ne nur lin. Ĉiuj, kiuj laboras kun la aplikaĵo, devas kompreni kie kaj kiel rigardi la nunan situacion kaj kiel diagnozi problemojn ĝustatempe. Por fari tion, ni aktive uzas DataStax OpsCenter (Administrado kaj monitorado de laborŝarĝoj), Cassandra Driver-sistema metriko (nombro da tempodaŭroj por skribi al C*, nombro da tempodaŭro por legado de C*, maksimuma latenteco, ktp.), monitori la operacion. de la aplikaĵo mem, laborante kun Cassandra.
Kiam ni pensis pri la antaŭa demando, ni komprenis, kie povus kuŝi nia ĉefa risko. Ĉi tiuj estas datummontraj formoj, kiuj montras datumojn de pluraj sendependaj demandoj al la stokado. Tiel ni povas akiri sufiĉe malkonsekvencan informon. Sed ĉi tiu problemo estus same grava se ni laborus kun nur unu datumcentro. Do la plej racia afero ĉi tie estas, kompreneble, krei grupan funkcion por legi datumojn sur triaparta aplikaĵo, kiu certigos, ke la datumoj estas ricevitaj en ununura tempodaŭro. Koncerne la dividon en legado kaj skribo laŭ agado, ĉi tie ni estis haltigitaj de la risko, ke kun iu perdo de konekto inter la DC-oj, ni povus fini kun du aretoj kiuj estas tute malkongruaj unu kun la alia.
Kiel rezulto, nuntempe haltis ĉe la konsekvenca nivelo por skribi EACH_QUORUM, por legado - LOCAL_QUORUM
Mallongaj impresoj kaj konkludoj
Por taksi la rezultan solvon el la vidpunkto de operacia subteno kaj perspektivoj por plua evoluo, ni decidis pensi pri kie alie tia evoluo povus esti aplikita.
Tuj dekomence, tiam datumo-poentado por programoj kiel "Pagu kiam estas oportune" (ni ŝargas informojn en C*, kalkulon per Spark-skriptoj), kalkuli asertojn kun agregado laŭ areo, stokante rolojn kaj kalkulante uzantajn alirrajtojn laŭ la rolo. matrico.
Kiel vi povas vidi, la repertuaro estas vasta kaj varia. Kaj se ni elektos la tendaron de subtenantoj/kontraŭuloj de NoSQL, tiam ni aliĝos al la subtenantoj, ĉar ni ricevis niajn avantaĝojn, kaj ĝuste kie ni atendis.
Eĉ la opcio Cassandra el la skatolo ebligas horizontalan skalon en reala tempo, absolute sendolore solvante la problemon de kreskantaj datumoj en la sistemo. Ni povis movi tre altan ŝarĝan mekanismon por kalkuli alvokajn agregatojn en apartan cirkviton, kaj ankaŭ apartigi la aplikaĵskemon kaj logikon, forigi la malbonan praktikon verki kutimajn laborojn kaj objektojn en la datumbazo mem. Ni ricevis la ŝancon elekti kaj agordi, akceli, pri kiuj PK ni faros kalkulojn kaj pri kiuj ni registros datumojn, ni certigis nin kontraŭ kraŝoj de ambaŭ individuaj nodoj kaj la PK entute.
Aplikante nian arkitekturon al novaj projektoj, kaj jam havante iom da sperto, mi ŝatus tuj konsideri la supre priskribitajn nuancojn, kaj malhelpi iujn erarojn, glatigi iujn akrajn angulojn, kiujn oni ne povus eviti komence.
Ekzemple, konservi trakon de la ĝisdatigoj de Cassandra ĝustatempeĉar sufiĉe multaj el la problemoj, kiujn ni ricevis, estis jam konataj kaj solvitaj.
Ne metu kaj la datumbazon mem kaj Spark sur la samajn nodojn (aŭ strikte dividu per la kvanto de permesebla rimedo-uzo), ĉar Spark povas manĝi pli da OP ol atendite, kaj ni rapide ricevos problemon numeron 1 el nia listo.
Plibonigu monitoradon kaj operacian kompetentecon ĉe la projekta prova stadio. Komence, konsideru kiel eble plej multe ĉiujn eblajn konsumantojn de nia solvo, ĉar de tio finfine dependos la datumbaza strukturo.
Turnu la rezultan cirkviton plurajn fojojn por ebla optimumigo. Elektu kiuj kampoj povas esti seriigitaj. Komprenu, kiajn pliajn tabelojn ni faru por plej ĝuste kaj optimume konsideri, kaj poste liveri la bezonatajn informojn laŭpeto (ekzemple, supozante, ke ni povas konservi la samajn datumojn en malsamaj tabeloj, konsiderante malsamajn malfunkciojn laŭ malsamaj kriterioj, ni povas ŝpari signife CPU-tempon por legaj petoj).
Ne malbona Tuj zorgu alfiksi TTL kaj purigi malmodernajn datumojn.
Dum elŝuto de datumoj de Cassandra La aplika logiko devus funkcii laŭ la FETCH-principo, tiel ke ne ĉiuj vicoj estas ŝarĝitaj en memoron samtempe, sed estas elektitaj en aroj.
Estas rekomendinde antaŭ ol transdoni la projekton al la priskribita solvo kontrolu la faŭltoleremon de la sistemo farante serion de kraŝtestoj, kiel ekzemple datumperdo en unu datumcentro, restarigo de difektitaj datumoj dum certa periodo, reto-forlaso inter datumcentroj. Tiaj provoj ne nur permesos al oni taksi la avantaĝojn kaj malavantaĝojn de la proponita arkitekturo, sed ankaŭ provizos bonan varmigan praktikon por la inĝenieroj kondukantaj ilin, kaj la akirita lerteco estos malproksima de superflua se sistemaj misfunkciadoj estas reproduktitaj en produktado.
Se ni laboras kun kritikaj informoj (kiel datumoj por fakturado, kalkulo de ŝuldo de abonantoj), tiam ankaŭ indas atenti ilojn, kiuj reduktos la riskojn aperantajn pro la trajtoj de la DBMS. Ekzemple, uzu la nodesync ilo (Datastax), evoluiginte optimuman strategion por ĝia uzo en ordo pro konsistenco, ne kreu troan ŝarĝon sur Kasandra kaj uzu ĝin nur por certaj tabeloj en certa periodo.
Kio okazas al Kasandra post ses monatoj de vivo? Ĝenerale, ne estas nesolvitaj problemoj. Ni ankaŭ ne permesis iujn ajn gravajn akcidentojn aŭ perdon de datumoj. Jes, ni devis pensi pri kompenso de iuj problemoj, kiuj antaŭe ne aperis, sed fine tio ne multe nubigis nian arkitekturan solvon. Se vi volas kaj ne timas provi ion novan, kaj samtempe ne volas esti tro seniluziigita, tiam pretiĝu por la fakto, ke nenio estas senpaga. Vi devos kompreni, enprofundiĝi en la dokumentadon kaj kunmeti vian propran individuan rastilon pli ol en la malnova hereda solvo, kaj neniu teorio diros al vi antaŭe, kiu rastilo atendas vin.
fonto: www.habr.com