Tan yn ddiweddar yn Odnoklassniki, roedd tua 50 TB o ddata a broseswyd mewn amser real yn cael ei storio yn SQL Server. Ar gyfer cyfaint o'r fath, mae bron yn amhosibl darparu mynediad cyflym a dibynadwy, a hyd yn oed i oddef bai, i ganolfan ddata gan ddefnyddio SQL DBMS. Fel arfer mewn achosion o'r fath defnyddir un o'r siopau NoSQL, ond ni ellir trosglwyddo popeth i NoSQL: mae angen gwarantau trafodion ACID ar rai endidau.
Arweiniodd hyn ni at ddefnyddio storfa NewSQL, hynny yw, DBMS sy'n darparu goddefgarwch bai, scalability a pherfformiad systemau NoSQL, ond ar yr un pryd yn cadw'r gwarantau ACID sy'n gyfarwydd i systemau clasurol. Nid oes llawer o systemau diwydiannol gweithredol o'r dosbarth newydd hwn, felly gwnaethom weithredu system o'r fath ein hunain a'i rhoi ar waith yn fasnachol.
Sut mae'n gweithio a beth ddigwyddodd - darllenwch o dan y toriad.
Heddiw, mae cynulleidfa fisol Odnoklassniki yn fwy na 70 miliwn o ymwelwyr unigryw. Rydym ni rhwydweithiau cymdeithasol mwyaf yn y byd, ac yn yr ugain safle gorau y mae defnyddwyr yn treulio'r amser mwyaf arnynt. Mae'r seilwaith "Iawn" yn delio â llwythi uchel iawn: dros filiwn o geisiadau HTTP/eiliad fesul blaen. Mae rhannau o'r parc gweinyddwr yn y swm o fwy na 8000 o ddarnau wedi'u lleoli'n agos at ei gilydd - mewn pedair canolfan ddata Moscow, sy'n ei gwneud hi'n bosibl darparu oedi rhwydwaith o lai nag 1 ms rhyngddynt.
Rydym wedi bod yn defnyddio Cassandra ers 2010, gan ddechrau gyda fersiwn 0.6. Heddiw, mae sawl dwsin o glystyrau ar waith. Mae'r clwstwr cyflymaf yn prosesu dros 4 miliwn o lawdriniaethau yr eiliad, tra bod yr un mwyaf yn storio 260 TB.
Fodd bynnag, mae'r rhain i gyd yn glystyrau NoSQL cyffredin a ddefnyddir i storio data. Roeddem am ddisodli'r prif storfa gyson, Microsoft SQL Server, a ddefnyddiwyd ers sefydlu Odnoklassniki. Roedd y storfa yn cynnwys mwy na 300 o beiriannau SQL Server Standard Edition, a oedd yn cynnwys 50 TB o ddata - endidau busnes. Mae'r data hwn yn cael ei addasu fel rhan o drafodion ACID ac mae angen .
I ddosbarthu data ar draws nodau SQL Server, fe wnaethom ddefnyddio fertigol a llorweddol (rhannu). Yn hanesyddol, fe wnaethom ddefnyddio cynllun rhannu data syml: roedd pob endid yn gysylltiedig â thocyn - un o swyddogaethau'r ID endid. Rhoddwyd endidau gyda'r un tocyn ar yr un gweinydd SQL. Gweithredwyd y berthynas meistr-manylion yn y fath fodd fel bod tocynnau'r cofnodion meistr a phlentyn bob amser yn cyd-fynd ac wedi'u lleoli ar yr un gweinydd. Mewn rhwydwaith cymdeithasol, mae bron pob cofnod yn cael ei gynhyrchu ar ran y defnyddiwr, sy'n golygu bod yr holl ddata defnyddiwr o fewn un is-system swyddogaethol yn cael ei storio ar un gweinydd. Hynny yw, roedd tablau un gweinydd SQL bron bob amser yn cymryd rhan mewn trafodiad busnes, a oedd yn ei gwneud hi'n bosibl sicrhau cysondeb data gan ddefnyddio trafodion ACID lleol, heb yr angen i ddefnyddio trafodion ACID wedi'u dosbarthu.
Diolch i rannu ac i gyflymu SQL:
- Nid ydym yn defnyddio cyfyngiadau allwedd Tramor, oherwydd wrth rannu, gellir lleoli'r ID endid ar weinydd arall.
- Nid ydym yn defnyddio gweithdrefnau a sbardunau sydd wedi'u storio oherwydd y llwyth ychwanegol ar y CPU DBMS.
- Nid ydym yn defnyddio JOINs oherwydd yr uchod i gyd a llawer o ddarlleniadau ar hap o ddisg.
- Y tu allan i drafodiad, rydym yn defnyddio lefel ynysu Read Uncommitted i leihau terfynau amser.
- Dim ond trafodion byr yr ydym yn eu cyflawni (llai na 100ms ar gyfartaledd).
- Nid ydym yn defnyddio aml-rhes DIWEDDARAF a DELETE oherwydd nifer fawr o ddatgloi - dim ond un cofnod ar y tro rydym yn ei ddiweddaru.
- Mae ymholiadau bob amser yn cael eu gweithredu trwy fynegeion yn unig - mae ymholiad gyda chynllun sgan tabl llawn yn golygu i ni orlwytho'r gronfa ddata a'i methiant.
Roedd y camau hyn yn ein galluogi i wasgu bron y perfformiad mwyaf allan o weinyddion SQL. Fodd bynnag, daeth y problemau yn fwyfwy. Gadewch i ni edrych arnynt.
Problemau gyda SQL
- Ers i ni ddefnyddio darnio hunan-ysgrifenedig, gweinyddwyr oedd yn ychwanegu darnau newydd â llaw. Trwy'r amser hwn, nid yw atgynyrchiadau data graddadwy wedi cyflwyno ceisiadau.
- Wrth i nifer y cofnodion yn y tabl dyfu, mae cyflymder mewnosod ac addasu yn lleihau, wrth ychwanegu mynegeion i dabl presennol, mae'r cyflymder yn gostwng gan luosrif, mae creu ac ail-greu mynegeion yn cymryd amser segur.
- Mae cael ychydig bach o Windows ar gyfer SQL Server wrth gynhyrchu yn gwneud rheoli seilwaith yn anodd
Ond y brif broblem yw
goddefgarwch fai
Mae gan Classic SQL Server oddefgarwch namau gwael. Gadewch i ni ddweud mai dim ond un gweinydd cronfa ddata sydd gennych ac mae'n methu bob tair blynedd. Ar hyn o bryd, mae'r safle i lawr am 20 munud, mae hyn yn dderbyniol. Os oes gennych 64 o weinyddion, yna mae'r wefan i lawr unwaith bob tair wythnos. Ac os oes gennych 200 o weinyddion, yna nid yw'r wefan yn gweithio bob wythnos. Mae hyn yn broblem.
Beth ellir ei wneud i wella goddefgarwch nam ar y gweinydd SQL? Mae Wikipedia yn ein gwahodd i adeiladu : lle mae copi wrth gefn rhag ofn y bydd unrhyw un o'r cydrannau'n methu.
Mae hyn yn gofyn am fflyd o offer drud: dyblygu niferus, opteg ffibr, storio a rennir, ac nid yw cynnwys y gronfa wrth gefn yn gweithio'n ddibynadwy: mae tua 10% o'r cynhwysiant yn dod i ben gyda methiant y nod wrth gefn gyda thrên y tu ôl i'r prif nod.
Ond prif anfantais clwstwr sydd ar gael mor fawr yw dim argaeledd rhag ofn y bydd y ganolfan ddata y mae wedi'i lleoli ynddi yn methu. Mae gan Odnoklassniki bedair canolfan ddata, ac mae angen inni sicrhau gwaith yn un ohonynt rhag ofn y bydd methiant llwyr.
Ar gyfer hyn gallai un wneud cais atgynhyrchu wedi'i ymgorffori yn SQL Server. Mae'r ateb hwn yn llawer drutach oherwydd cost meddalwedd ac mae'n dioddef o broblemau ail-greu adnabyddus - oedi trafodion anrhagweladwy gyda dyblygu cydamserol ac oedi wrth gymhwyso dyblygu (ac, o ganlyniad, addasiadau coll) ag asyncronig. ymhlyg yn gwneud yr opsiwn hwn yn gwbl amherthnasol i ni.
Roedd angen ateb cardinal ar yr holl broblemau hyn ac aethom ymlaen at eu dadansoddiad manwl. Yma mae angen i ni ddod yn gyfarwydd â'r hyn y mae SQL Server yn ei wneud yn y bôn - trafodion.
Trafodiad syml
Ystyriwch y trafodiad symlaf o safbwynt rhaglennydd SQL cymhwysol: ychwanegu llun at albwm. Mae albymau a lluniau yn cael eu storio mewn gwahanol blatiau. Mae gan yr albwm gownter lluniau cyhoeddus. Yna mae trafodiad o'r fath yn cael ei rannu i'r camau canlynol:
- Rydyn ni'n blocio'r albwm trwy allwedd.
- Creu cofnod yn y tabl lluniau.
- Os oes gan y llun statws cyhoeddus, yna rydyn ni'n dirwyn y cownter o luniau cyhoeddus yn yr albwm i ben, yn diweddaru'r cofnod ac yn ymrwymo'r trafodiad.
Neu mewn ffuggod:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();Gwelwn mai'r senario mwyaf cyffredin ar gyfer trafodiad busnes yw darllen data o'r gronfa ddata i gof gweinydd y cais, newid rhywbeth ac arbed y gwerthoedd newydd yn ôl i'r gronfa ddata. Fel arfer mewn trafodiad o'r fath rydym yn diweddaru sawl endid, sawl tabl.
Pan fydd trafodiad yn cael ei gyflawni, efallai y bydd addasiad cydamserol o'r un data o system arall yn digwydd. Er enghraifft, efallai y bydd Antispam yn penderfynu bod y defnyddiwr rywsut yn amheus ac felly ni ddylai pob llun o'r defnyddiwr fod yn gyhoeddus mwyach, mae angen eu hanfon i'w cymedroli, sy'n golygu newid photo.status i ryw werth arall a diffodd y cownteri cyfatebol. Yn amlwg, os bydd y llawdriniaeth hon yn digwydd heb warantau o atomigedd cymhwysiad ac ynysu addasiadau cystadleuol, fel yn , yna ni fydd y canlyniad yr hyn sydd ei angen arnoch - naill ai bydd y cownter lluniau yn dangos y gwerth anghywir, neu ni fydd pob llun yn cael ei anfon i'w gymedroli.
Mae llawer o god o'r fath sy'n trin amrywiol endidau busnes o fewn un trafodiad wedi'i ysgrifennu trwy gydol bodolaeth Odnoklassniki. Yn ôl profiad mudo i NoSQL gyda gwyddom mai'r her fwyaf (ac sy'n cymryd llawer o amser) yw'r angen i ddatblygu cod i gynnal cysondeb data. Felly, roeddem o'r farn mai'r prif ofyniad ar gyfer y storfa newydd oedd y ddarpariaeth ar gyfer rhesymeg cymhwyso trafodion ACID go iawn.
Gofynion eraill yr un mor bwysig oedd:
- Os bydd canolfan ddata yn methu, rhaid bod darllen ac ysgrifennu ar gael i'r storfa newydd.
- Cynnal cyflymder datblygu presennol. Hynny yw, wrth weithio gyda storfa newydd, dylai maint y cod fod tua'r un peth, ni ddylai fod angen ychwanegu rhywbeth at y storfa, datblygu algorithmau ar gyfer datrys gwrthdaro, cynnal mynegeion eilaidd, ac ati.
- Dylai cyflymder y storfa newydd fod yn ddigon cyflym, wrth ddarllen data ac wrth brosesu trafodion, a oedd i bob pwrpas yn golygu bod atebion academaidd trwyadl, pwrpas cyffredinol, ond araf, megis .
- Graddio awtomatig ar y hedfan.
- Gan ddefnyddio gweinyddwyr rhad cyffredin, heb yr angen i brynu darnau egsotig o haearn.
- Posibilrwydd o ddatblygiad storio gan ddatblygwyr y cwmni. Mewn geiriau eraill, rhoddwyd blaenoriaeth i atebion perchnogol neu ffynhonnell agored, yn ddelfrydol yn Java.
Penderfyniadau, penderfyniadau
Wrth ddadansoddi atebion posibl, fe wnaethom feddwl am ddau ddewis pensaernïaeth posibl:
Y cyntaf yw cymryd unrhyw weinydd SQL a gweithredu'r goddefgarwch bai gofynnol, mecanwaith graddio, clystyru methiant, datrys gwrthdaro, a thrafodion ACID gwasgaredig, dibynadwy a chyflym. Fe wnaethom asesu'r opsiwn hwn fel un nad yw'n ddibwys ac yn cymryd llawer o amser.
Yr ail opsiwn yw cymryd storfa NoSQL parod gyda graddio wedi'i weithredu, clystyru methiant, datrys gwrthdaro a gweithredu trafodion a SQL eich hun. Ar yr olwg gyntaf, mae hyd yn oed y dasg o weithredu SQL, heb sôn am drafodion ACID, yn edrych fel tasg ers blynyddoedd. Ond yna sylweddolom fod y set o nodweddion SQL a ddefnyddiwn yn ymarferol mor bell o ANSI SQL ag ymhell o ANSI SQL. Wrth edrych yn agosach ar CQL, sylweddolom ei fod yn ddigon agos at yr hyn sydd ei angen arnom.
Cassandra a CQL
Felly, beth sy'n ddiddorol am Cassandra, pa nodweddion sydd ganddo?
Yn gyntaf, yma gallwch greu tablau gyda chefnogaeth ar gyfer gwahanol fathau o ddata, gallwch wneud SELECT neu DIWEDDARIAD yn ôl allwedd gynradd.
CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;Er mwyn sicrhau cysondeb data replica, mae Cassandra yn defnyddio . Yn yr achos symlaf, mae hyn yn golygu, wrth osod tri atgynhyrchiad o’r un rhes ar wahanol nodau’r clwstwr, yr ystyrir bod yr ysgrifennu yn llwyddiannus os yw’r rhan fwyaf o’r nodau (h.y. dau o bob tri) yn cadarnhau llwyddiant y weithred ysgrifennu hon. Ystyrir bod data cyfres yn gyson os, wrth ddarllen, y cafodd y rhan fwyaf o'r nodau eu holi a'u cadarnhau. Felly, os oes tri atgynhyrchiad, gwarantir cysondeb data llawn ac ar unwaith os bydd un nod yn methu. Roedd y dull hwn yn ein galluogi i weithredu cynllun hyd yn oed yn fwy dibynadwy: anfon ceisiadau at bob un o'r tri atgynhyrchiad bob amser, gan aros am ymateb gan y ddau gyflymaf. Yna caiff ymateb hwyr y trydydd replica ei daflu. Ar yr un pryd, gall nod sy'n hwyr gydag ymateb gael problemau difrifol - breciau, casglu sbwriel yn y JVM, adennill cof uniongyrchol yn y cnewyllyn linux, methiant caledwedd, datgysylltu o'r rhwydwaith. Fodd bynnag, nid yw gweithrediadau a data cleientiaid yn cael eu heffeithio mewn unrhyw ffordd.
Gelwir y dull gweithredu pan fyddwn yn cyrchu tri nod ac yn derbyn ymateb gan ddau : anfonir cais am atgynyrchiadau ychwanegol cyn iddo "syrthio".
Mantais arall Cassandra yw Batchlog, mecanwaith sy'n sicrhau bod newidiadau a wnewch naill ai'n cael eu cymhwyso'n llawn neu heb eu cymhwyso'n llwyr i'r pecyn. Mae hyn yn ein galluogi i ddatrys A mewn ASID - atomigedd allan o'r bocs.
Y peth agosaf at drafodion yn Cassandra yw'r hyn a elwir yn "" . Ond maent ymhell o fod yn drafodion ASID “go iawn”: mewn gwirionedd, mae hwn yn gyfle i wneud ar ddata un cofnod yn unig, gan ddefnyddio consensws protocol pwysau trwm Paxos. Felly, mae cyflymder trafodion o'r fath yn isel.
Beth wnaethon ni ei golli yn Cassandra
Felly, bu'n rhaid i ni weithredu trafodion ACID go iawn yn Cassandra. Gyda chymorth y gallem weithredu dwy nodwedd gyfleus arall o'r DBMS clasurol yn hawdd: mynegeion cyflym cyson, a fyddai'n caniatáu inni ddewis data nid yn unig yn ôl y cywair cynradd, a'r generadur arferol o IDau auto-cynnydd undonog.
C* Un
Felly ganwyd y DBMS newydd C* Un, sy'n cynnwys tri math o nodau gweinydd:
- Mae storfeydd (bron) yn weinyddion Cassandra safonol sy'n gyfrifol am storio data ar yriannau lleol. Wrth i lwyth a chyfaint y data gynyddu, gellir cynyddu eu nifer yn hawdd i ddegau a channoedd.
- Cydlynwyr trafodion - sicrhau bod trafodion yn cael eu cyflawni.
- Mae cleientiaid yn weinyddion cymwysiadau sy'n gweithredu gweithrediadau busnes ac yn cychwyn trafodion. Efallai y bydd miloedd o gleientiaid o'r fath.
Mae gweinyddwyr o bob math mewn clwstwr cyffredin, yn defnyddio protocol negeseuon mewnol Cassandra i gyfathrebu â'i gilydd a ar gyfer cyfnewid gwybodaeth clwstwr. Gyda chymorth Heartbeat, mae gweinyddwyr yn dysgu am fethiannau cilyddol, yn cynnal cynllun data sengl - tablau, eu strwythur a'u dyblygu; cynllun rhaniadu, topoleg clwstwr, ac ati.
Cwsmeriaid
Yn lle gyrwyr safonol, defnyddir modd Cleient Braster. Nid yw nod o'r fath yn storio data, ond gall weithredu fel cydlynydd gweithredu ceisiadau, hynny yw, mae'r Cleient ei hun yn gweithredu fel cydlynydd ei geisiadau: mae'n pleidleisio replicas storio ac yn datrys gwrthdaro. Mae hyn nid yn unig yn fwy dibynadwy ac yn gyflymach na'r gyrrwr safonol, sy'n gofyn am gyfathrebu â chydlynydd anghysbell, ond hefyd yn caniatáu ichi reoli trosglwyddo ceisiadau. Y tu allan i drafodiad sy'n agored i'r cleient, anfonir ceisiadau i storfeydd. Os agorodd y cleient drafodiad, yna anfonir pob cais o fewn y trafodiad at y cydlynydd trafodion.
C*Un Cydlynydd Trafodion
Y cydlynydd yw'r hyn a weithredwyd gennym ar gyfer C*O o'r dechrau. Mae'n gyfrifol am reoli trafodion, cloeon, a'r drefn y caiff trafodion eu cymhwyso.
Ar gyfer pob trafodiad â gwasanaeth, mae'r cydlynydd yn cynhyrchu stamp amser: mae pob un dilynol yn fwy na'r trafodiad blaenorol. Gan fod y system datrys gwrthdaro yn Cassandra yn seiliedig ar stampiau amser (o ddau gofnod anghyson, ystyrir bod y stamp amser diweddaraf yn berthnasol), bydd y gwrthdaro bob amser yn cael ei ddatrys o blaid y trafodiad dilynol. Felly rydym wedi gweithredu yn ffordd rad o ddatrys gwrthdaro mewn system ddosbarthedig.
Cloeon
Er mwyn sicrhau unigedd, fe benderfynon ni ddefnyddio'r ffordd hawsaf - cloeon pesimistaidd ar allwedd sylfaenol y cofnod. Mewn geiriau eraill, mewn trafodiad, rhaid cloi cofnod yn gyntaf, dim ond wedyn ei ddarllen, ei addasu a'i gadw. Dim ond ar ôl ymrwymiad llwyddiannus y gellir datgloi cofnod fel y gall trafodion cystadleuol ei ddefnyddio.
Mae gweithredu clo o'r fath yn syml mewn amgylchedd nad yw'n cael ei ddosbarthu. Mewn system ddosbarthedig, mae dwy brif ffordd: naill ai gweithredu cloi gwasgaredig ar glwstwr, neu ddosbarthu trafodion fel bod trafodion sy'n cynnwys yr un cofnod bob amser yn cael eu gwasanaethu gan yr un cydlynydd.
Gan fod y data yn ein hachos ni eisoes wedi'i ddosbarthu ymhlith grwpiau o drafodion lleol yn SQL, penderfynwyd neilltuo grwpiau o drafodion lleol i'r cydlynwyr: mae un cydlynydd yn cyflawni'r holl drafodion gyda thocyn o 0 i 9, yr ail - gyda thocyn o 10 i 19, ac yn y blaen. O ganlyniad, mae pob un o achosion y cydlynydd yn dod yn feistr ar y grŵp trafodion.
Yna gellir gweithredu cloeon fel HashMap banal er cof am y cydlynydd.
Cydlynwyr yn gwrthod
Gan fod un cydlynydd yn gwasanaethu grŵp o drafodion yn unig, mae'n bwysig iawn pennu ffaith ei fethiant yn gyflym fel bod yr ymgais dro ar ôl tro i gyflawni'r trafodiad o fewn y terfyn amser. I wneud hyn yn gyflym ac yn ddibynadwy, fe wnaethom ddefnyddio protocol curiad clyw cworwm llawn rhwyllog:
Mae gan bob canolfan ddata o leiaf ddau nod cydlynydd. O bryd i'w gilydd, mae pob cydlynydd yn anfon neges curiad calon at y cydlynwyr eraill ac yn eu hysbysu am ei weithrediad, yn ogystal ag am y tro diwethaf iddo dderbyn negeseuon curiad calon gan ba gydlynwyr yn y clwstwr.
Gan dderbyn gwybodaeth debyg gan y gweddill fel rhan o'u negeseuon curiad calon, mae pob cydlynydd yn penderfynu drosto'i hun pa nodau o'r clwstwr sy'n gweithredu a pha rai nad ydynt, wedi'u harwain gan egwyddor y cworwm: pe bai nod X yn derbyn gwybodaeth gan y mwyafrif o nodau yn y clwstwr am derbyniad arferol negeseuon o nod Y, yna , mae Y yn gweithio. I'r gwrthwyneb, cyn gynted ag y bydd y mwyafrif yn adrodd am negeseuon coll o nod Y, yna mae Y wedi methu. Yn rhyfedd iawn, os yw’r cworwm yn dweud wrth nod X nad yw’n derbyn rhagor o negeseuon ganddo, yna bydd nod X ei hun yn ystyried ei fod wedi methu.
Anfonir negeseuon curiad calon ar amledd uchel, tua 20 gwaith yr eiliad, gyda chyfnod o 50 ms. Yn Java, mae'n anodd gwarantu ymateb cais o fewn 50ms oherwydd amseroedd saib tebyg a achosir gan y casglwr sbwriel. Roeddem yn gallu cyflawni'r amser ymateb hwn gan ddefnyddio casglwr sbwriel G1, sy'n eich galluogi i bennu targed ar gyfer hyd seibiannau GC. Fodd bynnag, weithiau, yn anaml iawn, mae seibiau'r casglwr yn mynd y tu hwnt i 50 ms, a all arwain at ganfod methiant ffug. Er mwyn osgoi hyn, nid yw'r cydlynydd yn adrodd am fethiant y nod o bell pan fydd y neges curiad calon gyntaf ohono yn cael ei golli, dim ond os yw sawl un yn olynol ar goll.Felly llwyddwyd i ganfod methiant y nod cydlynydd yn 200 ms.
Ond nid yw'n ddigon deall yn gyflym pa nod sydd wedi peidio â gweithredu. Mae angen gwneud rhywbeth yn ei gylch.
Archebu
Mae'r cynllun clasurol yn cymryd yn ganiataol, os bydd y meistr yn methu â lansio etholiad un newydd gan ddefnyddio un o'r algorithmau. Fodd bynnag, mae gan algorithmau o'r fath broblemau adnabyddus o ran cydgyfeirio mewn amser a hyd y broses etholiadol ei hun. Llwyddom i osgoi oedi ychwanegol o’r fath drwy ddefnyddio’r cynllun disodli cydlynydd mewn rhwydwaith cwbl gysylltiedig:
Gadewch i ni ddweud ein bod am gyflawni trafodiad yng ngrŵp 50. Gadewch i ni ddiffinio cynllun newydd ymlaen llaw, hynny yw, pa nodau fydd yn gweithredu trafodion grŵp 50 rhag ofn y bydd y prif gydlynydd yn methu. Ein nod yw cadw'r system ar waith os bydd canolfan ddata yn methu. Gadewch i ni ddiffinio y bydd y gronfa wrth gefn gyntaf yn nod o ganolfan ddata arall, a bydd yr ail gronfa wrth gefn yn nod o'r drydedd. Dewisir y cynllun hwn unwaith ac nid yw'n newid nes bod topoleg y clwstwr yn newid, hynny yw, nes bod nodau newydd yn dod i mewn iddo (sy'n digwydd yn anaml iawn). Bydd y drefn o ddewis meistr gweithredol newydd rhag ofn y bydd yr hen un yn methu bob amser fel a ganlyn: bydd y gronfa wrth gefn gyntaf yn dod yn feistr gweithredol, ac os yw wedi peidio â gweithredu, daw'r ail gronfa wrth gefn.
Mae cynllun o'r fath yn fwy dibynadwy nag algorithm cyffredinol, oherwydd i actifadu meistr newydd, mae'n ddigon i bennu ffaith methiant yr hen un.
Ond sut bydd cwsmeriaid yn deall pa un o'r meistri sy'n gweithio ar hyn o bryd? Mae'n amhosibl anfon gwybodaeth at filoedd o gleientiaid mewn 50 ms. Mae'n bosibl bod cleient yn anfon cais i agor trafodiad, heb wybod eto nad yw'r meistr hwn yn gweithredu mwyach, a bydd y cais yn dibynnu ar derfyn amser. Er mwyn atal hyn rhag digwydd, mae cleientiaid yn hapfasnachol yn anfon cais i agor trafodiad i feistr y grŵp a'i ddwy gronfa wrth gefn ar unwaith, ond dim ond yr un sy'n feistr gweithredol ar hyn o bryd fydd yn ymateb i'r cais hwn. Bydd yr holl gyfathrebu dilynol o fewn y trafodiad yn cael ei berfformio gan y cleient yn unig gyda'r meistr gweithredol.
Mae'r meistri wrth gefn yn gosod y ceisiadau a dderbyniwyd am drafodion nad ydynt yn rhai eu hunain yn y ciw o drafodion heb eu geni, lle cânt eu storio am beth amser. Os bydd y meistr gweithredol yn marw, mae'r meistr newydd yn prosesu ceisiadau i agor trafodion o'i giw ac yn ymateb i'r cleient. Os yw'r cleient eisoes wedi llwyddo i agor trafodiad gyda'r hen feistr, yna anwybyddir yr ail ymateb (ac, yn amlwg, ni fydd trafodiad o'r fath yn gyflawn a bydd yn cael ei ailadrodd gan y cleient).
Sut mae trafodiad yn gweithio
Tybiwch fod y cleient wedi anfon cais at y cydlynydd i agor trafodiad ar gyfer endid o'r fath ac endid o'r fath gydag allwedd sylfaenol o'r fath. Mae'r cydlynydd yn cloi'r endid hwn ac yn ei roi yn y bwrdd clo er cof. Os oes angen, mae'r cydlynydd yn darllen yr endid hwn o'r storfa ac yn cadw'r data a dderbyniwyd i gyflwr trafodaethol yng nghof y cydlynydd.
Pan fydd cleient eisiau newid y data mewn trafodiad, mae'n anfon cais at y cydlynydd i addasu'r endid, ac mae'r cydlynydd yn gosod y data newydd yn y tabl cyflwr trafodiad er cof. Mae hyn yn cwblhau'r recordiad - nid ysgrifennir at y storfa.
Pan fydd cleient yn gofyn am ei ddata wedi'i addasu ei hun fel rhan o drafodiad gweithredol, mae'r cydlynydd yn gweithredu fel a ganlyn:
- os yw'r ID eisoes yn y trafodiad, yna cymerir y data o'r cof;
- os nad oes ID yn y cof, yna darllenir y data coll o'r nodau storio, ynghyd â'r rhai sydd eisoes yn y cof, a dychwelir y canlyniad i'r cleient.
Felly, gall y cleient ddarllen ei newidiadau ei hun, ac nid yw cleientiaid eraill yn gweld y newidiadau hyn, oherwydd eu bod yn cael eu storio er cof am y cydlynydd yn unig, nid ydynt eto yn nodau Cassandra.
Pan fydd y cleient yn anfon ymrwymiad, mae cyflwr y gwasanaeth er cof yn cael ei storio gan y cydlynydd mewn swp wedi'i logio, a'i anfon i siopau Cassandra fel swp wedi'i logio. Mae'r ystorfeydd yn gwneud popeth sy'n angenrheidiol i'r pecyn hwn gael ei gymhwyso'n atomig (yn llawn), ac yn dychwelyd ymateb i'r cydlynydd, sy'n rhyddhau'r cloeon ac yn cadarnhau llwyddiant y trafodiad i'r cleient.
Ac ar gyfer dychwelyd, dim ond y cof a feddiannir gan gyflwr y trafodiad sydd ei angen ar y cydlynydd.
O ganlyniad i’r gwelliannau a ddisgrifir uchod, rydym wedi rhoi egwyddorion ACID ar waith:
- Atomity. Mae hyn yn warant na fydd unrhyw drafodiad yn cael ei osod yn rhannol yn y system, naill ai y bydd ei holl is-weithrediadau yn cael eu cyflawni, neu na fydd yr un ohonynt yn cael ei gyflawni. Yn ein hachos ni, mae'r egwyddor hon yn cael ei dilyn oherwydd y swp sydd wedi'i logio yn Cassandra.
- Cysondeb. Mae pob trafodiad llwyddiannus, yn ôl diffiniad, yn ymrwymo canlyniadau dilys yn unig. Os, ar ôl agor trafodiad a pherfformio rhai o'r gweithrediadau, y canfyddir bod y canlyniad yn annilys, bydd dychweliad yn cael ei berfformio.
- ynysu. Pan fydd trafodiad yn cael ei gyflawni, ni ddylai trafodion cyfochrog effeithio ar ei ganlyniad. Mae trafodion cydamserol yn cael eu hynysu gyda chloeon pesimistaidd ar y cydlynydd. Ar gyfer darlleniadau y tu allan i drafodiad, perchir yr egwyddor o ynysu ar y lefel Read Committed.
- Cynaliadwyedd. Waeth beth fo'r problemau ar y lefelau is - blacowt yn y system, methiant caledwedd - dylai'r newidiadau a wneir gan drafodiad a gwblhawyd yn llwyddiannus barhau i gael eu harbed ar ôl ailddechrau gweithredu.
Darllen yn ôl mynegeion
Gadewch i ni gymryd tabl syml:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)Mae ganddo ID (allwedd sylfaenol), perchennog, a dyddiad addasu. Mae angen i chi wneud cais syml iawn - dewiswch ddata ar y perchennog gyda'r dyddiad newid "am y diwrnod olaf".
SELECT *
WHERE owner=?
AND modified>?Er mwyn prosesu ymholiad o'r fath yn gyflym, mewn SQL DBMS clasurol, mae angen i chi adeiladu mynegai ar y colofnau (perchennog, wedi'i addasu). Gallwn wneud hyn yn eithaf syml, gan fod gennym bellach warantau ACID!
Mynegeion yn C*Un
Mae tabl cychwynnol gyda lluniau lle mae ID cofnod yn brif allwedd.
Ar gyfer mynegai, mae C* One yn creu tabl newydd sy'n gopi o'r tabl gwreiddiol. Mae'r allwedd yr un peth â'r mynegiad mynegai, ond mae hefyd yn cynnwys prif allwedd y cofnod o'r tabl ffynhonnell:
Nawr gellir ailysgrifennu'r ymholiad am "perchennog yn y XNUMX awr ddiwethaf" fel detholiad o dabl arall:
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Mae cysondeb data rhwng y lluniau tabl ffynhonnell a mynegai i1 yn cael ei gynnal yn awtomatig gan y cydlynydd. Yn seiliedig ar y sgema data yn unig, pan dderbynnir newid, mae'r cydlynydd yn cynhyrchu ac yn cofio'r newid nid yn unig yn y prif dabl, ond hefyd newidiadau'r copïau. Ni chyflawnir unrhyw gamau ychwanegol gyda'r tabl mynegai, ni ddarllenir logiau, ni ddefnyddir cloeon. Hynny yw, nid yw ychwanegu mynegeion bron yn defnyddio adnoddau ac yn ymarferol nid yw'n effeithio ar gyflymder cymhwyso addasiadau.
Gyda chymorth ACID, rydym yn llwyddo i weithredu mynegeion "fel yn SQL". Maent yn gyson, yn raddadwy, yn gyflym, yn gyfansawdd, ac wedi'u hadeiladu i mewn i iaith ymholiad CQL. Nid oes angen unrhyw newidiadau i god y cais ar gyfer cymorth mynegai. Mae popeth yn syml, fel yn SQL. Ac yn bwysicaf oll, nid yw mynegeion yn effeithio ar gyflymder gweithredu addasiadau i'r tabl trafodion gwreiddiol.
Beth ddigwyddodd
Fe wnaethom ddatblygu C * Un dair blynedd yn ôl a'i roi ar waith yn fasnachol.
Beth wnaethom ni yn y diwedd? Gadewch i ni werthuso hyn ar yr enghraifft o is-system ar gyfer prosesu a storio lluniau, un o'r mathau pwysicaf o ddata mewn rhwydwaith cymdeithasol. Nid yw hyn yn ymwneud â chyrff y ffotograffau eu hunain, ond am bob math o feta-wybodaeth. Nawr yn Odnoklassniki mae tua 20 biliwn o gofnodion o'r fath, mae'r system yn prosesu 80 mil o geisiadau darllen yr eiliad, hyd at 8 mil o drafodion ACID yr eiliad yn ymwneud ag addasu data.
Pan wnaethom ddefnyddio SQL gyda ffactor atgynhyrchu = 1 (ond yn RAID 10), roedd y meta-wybodaeth llun yn cael ei storio ar glwstwr o 32 o beiriannau Microsoft SQL Server oedd ar gael yn fawr (ynghyd ag 11 sbâr). Hefyd, dyrannwyd 10 gweinydd ar gyfer storio copïau wrth gefn. Cyfanswm o 50 o geir drud. Ar yr un pryd, roedd y system yn gweithio ar lwyth graddedig, heb ymyl.
Ar ôl mudo i system newydd, cawsom ffactor atgynhyrchu = 3 - copi ym mhob canolfan ddata. Mae'r system yn cynnwys 63 o nodau storio Cassandra a 6 pheiriant cydgysylltu, ar gyfer cyfanswm o 69 o weinyddion. Ond mae'r peiriannau hyn yn llawer rhatach, gan wneud cyfanswm o tua 30% o gost system SQL. Yn yr achos hwn, cedwir y llwyth ar y lefel o 30%.
Gyda chyflwyniad C*One, gostyngodd hwyrni hefyd: yn SQL, cymerodd gweithrediad ysgrifennu tua 4,5 ms. Yn C* Un — tua 1,6 ms. Mae hyd trafodiad ar gyfartaledd yn llai na 40 ms, mae'r ymrwymiad wedi'i gwblhau mewn 2 ms, hyd y darllen ac ysgrifennu yw 2 ms ar gyfartaledd. Dim ond 99-3 ms yw'r 3,1fed canradd, mae nifer y goramser wedi gostwng 100 gwaith - i gyd oherwydd y defnydd eang o ddyfalu.
Hyd yn hyn, mae'r rhan fwyaf o nodau Gweinydd SQL wedi'u dadgomisiynu, dim ond C * Un sy'n datblygu cynhyrchion newydd. Fe wnaethom addasu C*One i weithio yn ein cwmwl , a oedd yn ei gwneud hi'n bosibl cyflymu'r defnydd o glystyrau newydd, symleiddio cyfluniad ac awtomeiddio gweithrediad. Heb y cod ffynhonnell, byddai hyn yn llawer anoddach ac yn hacni.
Nawr rydyn ni'n gweithio ar drosglwyddo ein storfeydd eraill i'r cwmwl - ond mae honno'n stori hollol wahanol.
Ffynhonnell: hab.com