Maen nhw'n dweud bod popeth mewn bywyd yn werth rhoi cynnig arno o leiaf unwaith. Ac os ydych chi wedi arfer gweithio gyda DBMSs perthynol, yna mae'n werth dod yn gyfarwydd â NoSQL yn ymarferol, yn gyntaf oll, o leiaf ar gyfer datblygiad cyffredinol. Nawr, oherwydd datblygiad cyflym y dechnoleg hon, mae yna lawer o safbwyntiau croes a dadleuon brwd ar y pwnc hwn, sy'n arbennig o danio diddordeb.
Os byddwch yn ymchwilio i hanfod yr holl anghydfodau hyn, gallwch weld eu bod yn codi oherwydd y dull anghywir. Mae'r rhai sy'n defnyddio cronfeydd data NoSQL yn union lle mae eu hangen yn fodlon ac yn derbyn holl fanteision y datrysiad hwn. Ac mae arbrofwyr sy'n dibynnu ar y dechnoleg hon fel ateb i bob problem lle nad yw'n berthnasol o gwbl yn siomedig, ar ôl colli cryfderau cronfeydd data perthynol heb ennill buddion sylweddol.
Dywedaf wrthych am ein profiad o roi datrysiad ar waith yn seiliedig ar y DBMS Cassandra: yr hyn yr oedd yn rhaid inni ei wynebu, sut y daethom allan o sefyllfaoedd anodd, a oeddem yn gallu elwa o ddefnyddio NoSQL a lle bu’n rhaid i ni fuddsoddi ymdrechion/arian ychwanegol .
Y dasg gychwynnol yw adeiladu system sy'n cofnodi galwadau mewn rhyw fath o storfa.
Mae egwyddor gweithredu'r system fel a ganlyn. Mae'r mewnbwn yn cynnwys ffeiliau gyda strwythur penodol sy'n disgrifio strwythur yr alwad. Yna mae'r cais yn sicrhau bod y strwythur hwn yn cael ei storio yn y colofnau priodol. Yn y dyfodol, defnyddir y galwadau a arbedir i arddangos gwybodaeth am ddefnydd traffig ar gyfer tanysgrifwyr (taliadau, galwadau, hanes cydbwysedd).
Mae'n eithaf amlwg pam y dewison nhw Cassandra - mae hi'n ysgrifennu fel gwn peiriant, mae'n hawdd ei graddio, ac yn gallu goddef diffygion.
Felly, dyma beth roddodd profiad inni
Ydy, nid yw nod a fethwyd yn drasiedi. Dyma hanfod goddefgarwch bai Cassandra. Ond gall nod fod yn fyw ac ar yr un pryd yn dechrau dioddef mewn perfformiad. Fel y digwyddodd, mae hyn yn effeithio'n syth ar berfformiad y clwstwr cyfan.
Ni fydd Cassandra yn eich amddiffyn lle gwnaeth Oracle eich achub gyda'i gyfyngiadau. Ac os nad oedd awdur y cais yn deall hyn ymlaen llaw, yna nid yw'r dwbl a gyrhaeddodd Cassandra yn waeth na'r gwreiddiol. Unwaith y bydd wedi cyrraedd, byddwn yn ei roi i mewn.
Nid oedd IB yn hoff iawn o'r Cassandra rhad ac am ddim allan o'r bocs: Nid oes unrhyw logio o weithredoedd defnyddwyr, dim gwahaniaethu hawliau. Mae gwybodaeth am alwadau’n cael ei hystyried yn ddata personol, sy’n golygu bod yn rhaid i bob ymgais i wneud cais amdano/ei newid mewn unrhyw ffordd gael ei gofnodi gyda’r posibilrwydd o archwiliad dilynol. Hefyd, mae angen i chi fod yn ymwybodol o'r angen i wahanu hawliau ar wahanol lefelau ar gyfer gwahanol ddefnyddwyr. Mae peiriannydd gweithredu syml ac uwch weinyddwr sy'n gallu dileu'r gofod allwedd cyfan yn rhydd yn rolau gwahanol, gwahanol gyfrifoldebau, a chymwyseddau. Heb wahaniaethau o'r fath mewn hawliau mynediad, bydd gwerth a chywirdeb y data yn cael eu cwestiynu ar unwaith yn gynt na chydag UNRHYW lefel cysondeb.
Ni wnaethom ystyried bod galwadau yn gofyn am ddadansoddiad difrifol a samplu cyfnodol ar gyfer amrywiaeth o amodau. Gan fod y cofnodion a ddewiswyd wedyn i fod i gael eu dileu a'u hailysgrifennu (fel rhan o'r dasg, mae'n rhaid i ni gefnogi'r broses o ddiweddaru data pan aeth y data i mewn i'n dolen yn anghywir i ddechrau), nid Cassandra yw ein ffrind yma. Mae Cassandra fel banc mochyn - mae'n gyfleus i roi pethau ynddo, ond ni allwch gyfrif ynddo.
Daethom ar draws problem wrth drosglwyddo data i barthau prawf (5 nod yn y prawf yn erbyn 20 yn y prom). Yn yr achos hwn, ni ellir defnyddio'r domen.
Y broblem gyda diweddaru sgema data cais yn ysgrifennu at Cassandra. Bydd dychwelyd yn cynhyrchu llawer iawn o gerrig beddi, a all arwain at golledion cynhyrchiant mewn ffyrdd anrhagweladwy.. Mae Cassandra wedi'i optimeiddio ar gyfer cofnodi, ac nid yw'n meddwl llawer cyn ysgrifennu Mae unrhyw weithrediad gyda data sy'n bodoli ynddo hefyd yn recordiad. Hynny yw, trwy ddileu'r diangen, byddwn yn cynhyrchu hyd yn oed mwy o gofnodion, a dim ond rhai ohonynt fydd yn cael eu marcio â beddfeini.
Goramser wrth fewnosod. Mae Cassandra yn hardd yn y recordiad, ond weithiau mae'r llif sy'n dod i mewn yn gallu peri penbleth iddi. Mae hyn yn digwydd pan fydd y cais yn dechrau cylchredeg o amgylch sawl cofnod na ellir eu mewnosod am ryw reswm. A bydd angen DBA go iawn arnom a fydd yn monitro gc.log, logiau system a dadfygio ar gyfer ymholiadau araf, metrigau ar gywasgu yn yr arfaeth.
Sawl canolfan ddata mewn clwstwr. O ble i ddarllen ac o ble i ysgrifennu?
Efallai ei rannu i ddarllen ac ysgrifennu? Ac os felly, a ddylai fod DC yn nes at y cais ar gyfer ysgrifennu neu ddarllen? Ac oni fydd gennym ymennydd hollt gwirioneddol os byddwn yn dewis y lefel gysondeb anghywir? Mae yna lawer o gwestiynau, llawer o leoliadau anhysbys, posibiliadau rydych chi wir eisiau tinceri gyda nhw.
Sut wnaethon ni benderfynu
Er mwyn atal y nod rhag suddo, analluogwyd SWAP. Ac yn awr, os oes diffyg cof, dylai'r nod fynd i lawr a pheidio â chreu seibiau gcc mawr.
Felly, nid ydym bellach yn dibynnu ar resymeg yn y gronfa ddata. Mae datblygwyr cymwysiadau yn ailhyfforddi eu hunain ac yn dechrau cymryd rhagofalon yn eu cod eu hunain. Gwahaniad clir delfrydol o storio a phrosesu data.
Fe brynon ni gefnogaeth gan DataStax. Mae datblygiad Cassandra mewn bocs eisoes wedi dod i ben (roedd yr ymrwymiad diwethaf ym mis Chwefror 2018). Ar yr un pryd, mae Datastax yn cynnig gwasanaeth rhagorol a nifer fawr o atebion wedi'u haddasu a'u haddasu ar gyfer datrysiadau IP presennol.
Rwyf hefyd am nodi nad yw Cassandra yn gyfleus iawn ar gyfer ymholiadau dethol. Wrth gwrs, mae CQL yn gam mawr ymlaen i ddefnyddwyr (o'i gymharu â Trift). Ond os oes gennych adrannau cyfan sy'n gyfarwydd ag ymuniadau cyfleus o'r fath, hidlo am ddim gan unrhyw faes a galluoedd optimeiddio ymholiad, a bod yr adrannau hyn yn gweithio i ddatrys cwynion a damweiniau, yna mae'r ateb ar Cassandra yn ymddangos yn elyniaethus ac yn dwp iddynt. A dechreuon ni benderfynu sut y dylai ein cydweithwyr wneud samplau.
Fe wnaethom ystyried dau opsiwn: Yn yr opsiwn cyntaf, rydym yn ysgrifennu galwadau nid yn unig yn C*, ond hefyd yn y gronfa ddata Oracle sydd wedi'i harchifo. Dim ond, yn wahanol i C*, mae'r gronfa ddata hon yn storio galwadau am y mis cyfredol yn unig (digon o ddyfnder storio galwadau ar gyfer achosion ailwefru). Yma gwelsom y broblem ganlynol ar unwaith: os ydym yn ysgrifennu'n gydamserol, yna rydym yn colli holl fanteision C * sy'n gysylltiedig â mewnosod cyflym; os byddwn yn ysgrifennu'n asyncronig, nid oes unrhyw sicrwydd bod yr holl alwadau angenrheidiol wedi cyrraedd Oracle o gwbl. Roedd un fantais, ond un mawr: ar gyfer gweithrediad mae'r un Datblygwr PL/SQL cyfarwydd yn parhau, h.y. rydym yn ymarferol yn gweithredu'r patrwm “Ffacade”. Rydyn ni'n gweithredu mecanwaith sy'n dadlwytho galwadau o C *, yn tynnu rhywfaint o ddata ar gyfer cyfoethogi o'r tablau cyfatebol yn Oracle, yn ymuno â'r samplau canlyniadol ac yn rhoi'r canlyniad i ni, y byddwn ni'n ei ddefnyddio rywsut wedyn (rholio'n ôl, ailadrodd, dadansoddi, edmygu). Anfanteision: mae'r broses yn eithaf aml-gam, ac yn ogystal, nid oes rhyngwyneb ar gyfer gweithwyr gweithrediad.
Yn y diwedd, fe wnaethom setlo ar yr ail opsiwn. Defnyddiwyd Apache Spark i samplu o wahanol jariau. Mae hanfod y mecanwaith wedi'i leihau i god Java, sydd, gan ddefnyddio'r allweddi penodedig (tanysgrifiwr, amser galw - allweddi adran), yn tynnu data o C *, yn ogystal â'r data angenrheidiol ar gyfer cyfoethogi o unrhyw gronfa ddata arall. Ar ôl hynny mae'n ymuno â nhw yn ei gof ac yn arddangos y canlyniad yn y tabl canlyniadol. Tynnodd ni wyneb gwe dros y sbarc ac fe drodd allan yn eithaf defnyddiadwy.
Wrth ddatrys y broblem o ddiweddaru data prawf diwydiannol, fe wnaethom eto ystyried sawl ateb. Mae'r ddau yn trosglwyddo trwy Sstloader a'r opsiwn o rannu'r clwstwr yn y parth prawf yn ddwy ran, y mae pob un ohonynt bob yn ail yn perthyn i'r un clwstwr â'r un hyrwyddo, ac felly'n cael ei bweru ganddo. Wrth ddiweddaru'r prawf, y bwriad oedd eu cyfnewid: mae'r rhan a weithiodd yn y prawf yn cael ei glirio a'i gynhyrchu, ac mae'r llall yn dechrau gweithio gyda'r data ar wahân. Fodd bynnag, ar ôl meddwl eto, fe wnaethom asesu’n fwy rhesymegol y data a oedd yn werth ei drosglwyddo, a sylweddoli bod y galwadau eu hunain yn endid anghyson ar gyfer profion, yn cael eu cynhyrchu’n gyflym os oes angen, ac mai’r set ddata hyrwyddo nad oes ganddi unrhyw werth i’w drosglwyddo i’r prawf. Mae yna nifer o wrthrychau storio sy'n werth eu symud, ond mae'r rhain yn llythrennol yn ddau fwrdd, ac nid yn rhai trwm iawn. Felly rydym ni fel ateb, daeth Spark eto i'r adwy, gyda chymorth yr ydym yn ysgrifennu ac yn dechrau defnyddio sgript yn weithredol ar gyfer trosglwyddo data rhwng tablau, prom-brawf.
Mae ein polisi lleoli presennol yn ein galluogi i weithio heb unrhyw newid. Cyn y promo, mae rhediad prawf gorfodol, lle nad yw camgymeriad mor ddrud. Mewn achos o fethiant, gallwch chi bob amser ollwng y gofod achos a rholio'r cynllun cyfan o'r dechrau.
Er mwyn sicrhau bod Cassandra ar gael yn barhaus, mae angen dba arnoch chi ac nid ef yn unig. Rhaid i bawb sy'n gweithio gyda'r cais ddeall ble a sut i edrych ar y sefyllfa bresennol a sut i wneud diagnosis o broblemau mewn modd amserol. I wneud hyn, rydym yn mynd ati i ddefnyddio DataStax OpsCenter (Gweinyddu a monitro llwythi gwaith), metrigau system Gyrwyr Cassandra (nifer y seibiannau ar gyfer ysgrifennu at C*, nifer y seibiannau ar gyfer darllen o C*, yr hwyrni mwyaf, ac ati), monitro'r gweithrediad o'r cais ei hun, yn gweithio gyda Cassandra.
Pan feddylion ni am y cwestiwn blaenorol, fe wnaethon ni sylweddoli beth yw ein prif risg. Ffurflenni arddangos data yw'r rhain sy'n dangos data o sawl ymholiad annibynnol i'r storfa. Fel hyn gallwn gael gwybodaeth eithaf anghyson. Ond byddai'r broblem hon yr un mor berthnasol pe baem yn gweithio gydag un ganolfan ddata yn unig. Felly y peth mwyaf rhesymol yma, wrth gwrs, yw creu swyddogaeth swp ar gyfer darllen data ar gais trydydd parti, a fydd yn sicrhau bod data yn cael ei dderbyn mewn un cyfnod o amser. O ran y rhaniad i ddarllen ac ysgrifennu o ran perfformiad, yma cawsom ein hatal gan y risg, gyda rhywfaint o golli cysylltiad rhwng y DCs, y gallem gael dau glwstwr sy'n gwbl anghyson â'i gilydd yn y pen draw.
O ganlyniad, am y tro stopio ar y lefel cysondeb ar gyfer ysgrifennu EACH_QUORUM, ar gyfer darllen - LOCAL_QUORUM
Argraffiadau a chasgliadau byr
Er mwyn gwerthuso'r datrysiad a ddeilliodd o hynny o safbwynt cefnogaeth weithredol a rhagolygon ar gyfer datblygiad pellach, penderfynwyd meddwl ble arall y gellid cymhwyso datblygiad o'r fath.
Oddi ar yr ystlum, yna sgorio data ar gyfer rhaglenni fel “Talu pan mae'n gyfleus” (rydym yn llwytho gwybodaeth i C*, cyfrifo gan ddefnyddio sgriptiau Spark), cyfrifo hawliadau gyda chyfuniad fesul ardal, storio rolau a chyfrifo hawliau mynediad defnyddwyr yn seiliedig ar y rôl matrics.
Fel y gwelwch, mae'r repertoire yn eang ac amrywiol. Ac os byddwn yn dewis y gwersyll o gefnogwyr / gwrthwynebwyr NoSQL, yna byddwn yn ymuno â'r cefnogwyr, ers i ni dderbyn ein manteision, ac yn union lle roeddem yn disgwyl.
Mae hyd yn oed opsiwn Cassandra allan o'r blwch yn caniatáu graddio llorweddol mewn amser real, gan ddatrys y mater o gynyddu data yn y system yn gwbl ddi-boen. Roeddem yn gallu symud mecanwaith llwyth uchel iawn ar gyfer cyfrifo agregau galwadau i gylched ar wahân, a hefyd gwahanu'r sgema a'r rhesymeg cymhwysiad, gan gael gwared ar yr arfer gwael o ysgrifennu tasgau a gwrthrychau arferol yn y gronfa ddata ei hun. Cawsom y cyfle i ddewis a ffurfweddu, i gyflymu, pa DCs y byddwn yn gwneud cyfrifiadau arnynt a pha rai y byddwn yn cofnodi data arnynt, fe wnaethom yswirio ein hunain rhag damweiniau yn y ddau nod unigol a'r DC yn ei gyfanrwydd.
Gan gymhwyso ein pensaernïaeth i brosiectau newydd, a chael rhywfaint o brofiad eisoes, hoffwn gymryd i ystyriaeth ar unwaith y naws a ddisgrifir uchod, ac atal rhai camgymeriadau, llyfnhau rhai corneli miniog na ellid eu hosgoi i ddechrau.
Er enghraifft, cadw golwg ar ddiweddariadau Cassandra mewn modd amseroloherwydd roedd cryn dipyn o'r problemau a gawsom eisoes yn hysbys ac wedi'u datrys.
Peidiwch â rhoi'r gronfa ddata ei hun a Spark ar yr un nodau (neu ei rannu'n llym â faint o ddefnydd adnoddau a ganiateir), oherwydd gall Spark fwyta mwy o OP na'r disgwyl, a byddwn yn cael problem rhif 1 yn gyflym o'n rhestr.
Gwella monitro a chymhwysedd gweithredol yn ystod cam profi'r prosiect. I ddechrau, ystyriwch gymaint â phosibl holl ddefnyddwyr posibl ein datrysiad, oherwydd dyma beth fydd strwythur y gronfa ddata yn dibynnu arno yn y pen draw.
Cylchdroi'r cylched canlyniadol sawl gwaith ar gyfer optimeiddio posibl. Dewiswch pa feysydd y gellir eu cyfresoli. Deall pa dablau ychwanegol y dylem eu gwneud er mwyn eu cymryd i ystyriaeth fwyaf cywir ac optimaidd, ac yna darparu’r wybodaeth ofynnol ar gais (er enghraifft, trwy dybio y gallwn storio’r un data mewn tablau gwahanol, gan ystyried dadansoddiadau gwahanol yn ôl meini prawf gwahanol, gallwn arbed amser CPU yn sylweddol ar gyfer ceisiadau darllen).
Ddim yn wael Darparu ar unwaith ar gyfer atodi TTL a glanhau hen ddata.
Wrth lawrlwytho data o Cassandra Dylai rhesymeg y cymhwysiad weithio ar yr egwyddor FETCH, fel nad yw pob rhes yn cael ei llwytho i'r cof ar unwaith, ond yn cael eu dewis mewn sypiau.
Fe'ch cynghorir cyn trosglwyddo'r prosiect i'r datrysiad a ddisgrifir gwirio goddefgarwch bai'r system trwy gynnal cyfres o brofion damwain, megis colli data mewn un ganolfan ddata, adfer data difrodi dros gyfnod penodol, rhwydwaith gollwng rhwng canolfannau data. Bydd profion o'r fath nid yn unig yn caniatáu i un werthuso manteision ac anfanteision y bensaernïaeth arfaethedig, ond bydd hefyd yn darparu arfer cynhesu da i'r peirianwyr sy'n eu cynnal, a bydd y sgil a gaffaelwyd ymhell o fod yn ddiangen os bydd methiannau system yn cael eu hatgynhyrchu wrth gynhyrchu.
Os byddwn yn gweithio gyda gwybodaeth hanfodol (fel data ar gyfer bilio, cyfrifo dyled tanysgrifiwr), yna mae hefyd yn werth talu sylw i offer a fydd yn lleihau'r risgiau sy'n codi oherwydd nodweddion y DBMS. Er enghraifft, defnyddiwch y cyfleustodau nodesync (Datastax), ar ôl datblygu strategaeth optimaidd ar gyfer ei ddefnyddio mewn trefn er mwyn cysondeb, peidiwch â chreu llwyth gormodol ar Cassandra a'i ddefnyddio ar gyfer tablau penodol yn unig mewn cyfnod penodol.
Beth sy'n digwydd i Cassandra ar ôl chwe mis o fywyd? Yn gyffredinol, nid oes unrhyw broblemau heb eu datrys. Ni wnaethom ychwaith ganiatáu unrhyw ddamweiniau difrifol na cholli data. Do, bu'n rhaid i ni feddwl am wneud iawn am rai problemau nad oeddent wedi codi o'r blaen, ond yn y diwedd nid oedd hyn yn cymylu ein datrysiad pensaernïol yn fawr. Os ydych chi eisiau ac nad ydych chi'n ofni rhoi cynnig ar rywbeth newydd, ac ar yr un pryd ddim eisiau bod yn rhy siomedig, yna paratowch ar gyfer y ffaith nad oes dim yn rhad ac am ddim. Bydd yn rhaid i chi ddeall, ymchwilio i'r ddogfennaeth a chydosod eich rhaca unigol eich hun yn fwy nag yn yr hen ddatrysiad etifeddiaeth, ac ni fydd unrhyw ddamcaniaeth yn dweud wrthych ymlaen llaw pa gribin sy'n aros amdanoch.
Ffynhonnell: hab.com