DBA bot Joe. Anatoly Stansler (Postgres.ai)

Sut mae datblygwr backend yn deall y bydd ymholiad SQL yn gweithio'n dda ar “prod”? Mewn cwmnïau mawr neu gwmnïau sy'n tyfu'n gyflym, nid oes gan bawb fynediad at y "cynnyrch". A chyda mynediad, ni ellir gwirio pob cais yn ddi-boen, ac mae creu copi o'r gronfa ddata yn aml yn cymryd oriau. I ddatrys y problemau hyn, rydym yn creu DBA artiffisial - Joe. Mae eisoes wedi'i weithredu'n llwyddiannus mewn sawl cwmni ac mae'n helpu mwy na dwsin o ddatblygwyr.

Fideo:

Helo pawb! Fy enw i yw Anatoly Stansler. Rwy'n gweithio i gwmni postgres.ai. Rydym wedi ymrwymo i gyflymu'r broses ddatblygu drwy gael gwared ar yr oedi sy'n gysylltiedig â gwaith Postgres gan ddatblygwyr, DBAs a SA.

Mae gennym gleientiaid gwych a heddiw bydd rhan o'r adroddiad yn cael ei neilltuo i achosion y gwnaethom gyfarfod â nhw wrth weithio gyda nhw. Byddaf yn siarad am sut y gwnaethom eu helpu i ddatrys problemau eithaf difrifol.

Pan fyddwn yn datblygu ac yn gwneud ymfudiadau llwyth uchel cymhleth, rydym yn gofyn y cwestiwn i'n hunain: “A fydd y mudo hwn yn dod i ben?”. Rydym yn defnyddio adolygu, rydym yn defnyddio gwybodaeth cydweithwyr mwy profiadol, arbenigwyr DBA. A gallant ddweud a fydd yn hedfan ai peidio.

Ond efallai y byddai'n well pe gallem ei brofi ein hunain ar gopïau maint llawn. A heddiw byddwn ni'n siarad am beth yw dulliau profi nawr a sut y gellir ei wneud yn well a chyda pha offer. Byddwn hefyd yn siarad am fanteision ac anfanteision dulliau o'r fath, a'r hyn y gallwn ei ddatrys yma.

Pwy sydd erioed wedi gwneud mynegeion yn uniongyrchol ar gynnyrch neu wedi gwneud unrhyw newidiadau? Cryn dipyn o. Ac i bwy yr arweiniodd hyn at y ffaith bod data wedi'i golli neu fod amser segur? Yna rydych chi'n gwybod y boen hon. Diolch i Dduw mae copïau wrth gefn.

Y dull cyntaf yw profi mewn prod. Neu, pan fydd datblygwr yn eistedd ar beiriant lleol, mae ganddo ddata prawf, mae yna ryw fath o ddetholiad cyfyngedig. Ac rydym yn cyflwyno i prod, ac rydym yn cael y sefyllfa hon.

Mae'n brifo, mae'n ddrud. Mae'n debyg ei bod yn well peidio.

A beth yw'r ffordd orau i'w wneud?

Gadewch i ni gymryd llwyfannu a dewis rhyw ran o'r prod yno. Neu ar y gorau, gadewch i ni gymryd prod go iawn, yr holl ddata. Ac ar ôl i ni ei ddatblygu'n lleol, byddwn hefyd yn gwirio ar gyfer llwyfannu.

Bydd hyn yn ein galluogi i gael gwared ar rai o’r gwallau, h.y. eu hatal rhag bod yn barod.

Beth yw'r problemau?

• Y broblem yw ein bod yn rhannu’r llwyfan hwn gyda chydweithwyr. Ac yn aml iawn mae'n digwydd eich bod chi'n gwneud rhyw fath o newid, bam - ac nid oes data, mae'r gwaith i lawr y draen. Roedd y llwyfannu yn aml-terabyte. Ac mae'n rhaid i chi aros am amser hir iddo godi eto. Ac rydym yn penderfynu ei gwblhau yfory. Dyna ni, mae gennym ni ddatblygiad.
• Ac, wrth gwrs, mae gennym ni lawer o gydweithwyr yn gweithio yno, llawer o dimau. Ac mae'n rhaid ei wneud â llaw. Ac mae hyn yn anghyfleus.

Ac mae'n werth dweud mai dim ond un ymgais sydd gennym, un ergyd, os ydym am wneud rhai newidiadau i'r gronfa ddata, cyffwrdd â'r data, newid y strwythur. Ac os aeth rhywbeth o'i le, os bu gwall yn y mudo, yna ni fyddwn yn treiglo'n ôl yn gyflym.

Mae hyn yn well na'r dull blaenorol, ond mae tebygolrwydd uchel o hyd y bydd rhyw fath o gamgymeriad yn mynd i gynhyrchu.

Beth sy'n ein hatal rhag rhoi mainc brawf, copi maint llawn i bob datblygwr? Rwy'n meddwl ei bod yn amlwg beth sy'n rhwystro.

Pwy sydd â chronfa ddata fwy na terabyte? Mwy na hanner yr ystafell.

Ac mae'n amlwg bod cadw peiriannau ar gyfer pob datblygwr, pan fo cynhyrchiad mor fawr, yn ddrud iawn, ac ar wahân, mae'n cymryd amser hir.

Mae gennym gleientiaid sydd wedi sylweddoli ei bod yn bwysig iawn profi pob newid ar gopïau maint llawn, ond mae eu cronfa ddata yn llai na terabyte, ac nid oes adnoddau i gadw mainc brawf ar gyfer pob datblygwr. Felly, mae'n rhaid iddynt lawrlwytho'r tomenni yn lleol i'w peiriant a'u profi yn y modd hwn. Mae'n cymryd llawer o amser.

Hyd yn oed os gwnewch hynny y tu mewn i'r seilwaith, yna mae lawrlwytho un terabyte o ddata yr awr eisoes yn dda iawn. Ond maen nhw'n defnyddio tomenni rhesymegol, maen nhw'n lawrlwytho'n lleol o'r cwmwl. Ar eu cyfer, mae'r cyflymder tua 200 gigabeit yr awr. Ac mae'n dal i gymryd amser i droi o gwmpas y dymp rhesymegol, rholio i fyny'r mynegeion, ac ati.

Ond maen nhw'n defnyddio'r dull hwn oherwydd ei fod yn caniatáu iddynt gadw'r cynnyrch yn ddibynadwy.

Beth allwn ni ei wneud yma? Gadewch i ni wneud meinciau prawf yn rhad a rhoi eu mainc brawf eu hunain i bob datblygwr.

Ac mae hyn yn bosibl.

Ac yn y dull hwn, pan fyddwn yn gwneud clonau tenau ar gyfer pob datblygwr, gallwn ei rannu ar un peiriant. Er enghraifft, os oes gennych gronfa ddata 10TB ac eisiau ei roi i 10 datblygwr, nid oes angen i chi gael cronfeydd data XNUMX x XNUMXTB. Dim ond un peiriant sydd ei angen arnoch i wneud copïau ynysig tenau ar gyfer pob datblygwr gan ddefnyddio un peiriant. Byddaf yn dweud wrthych sut mae'n gweithio ychydig yn ddiweddarach.

Enghraifft go iawn:

• DB - 4,5 terabytes.

• Gallwn gael copïau annibynnol mewn 30 eiliad.

Nid oes rhaid i chi aros am stondin prawf a dibynnu ar ba mor fawr ydyw. Gallwch ei gael mewn eiliadau. Bydd yn amgylcheddau cwbl ynysig, ond sy'n rhannu data ymhlith ei gilydd.

Mae hyn yn wych. Yma rydym yn sôn am hud a bydysawd cyfochrog.

Yn ein hachos ni, mae hyn yn gweithio gan ddefnyddio system OpenZFS.

System ffeiliau copi-ar-ysgrifennu yw OpenZFS sy'n cefnogi cipluniau a chlonau allan o'r blwch. Mae'n ddibynadwy ac yn raddadwy. Mae hi'n hawdd iawn i'w rheoli. Yn llythrennol, gellir ei ddefnyddio mewn dau dîm.

Mae opsiynau eraill:

• lvm,

• Storio (er enghraifft, Storio Pur).

Mae'r Labordy Cronfa Ddata rwy'n sôn amdano yn fodiwlaidd. Gellir ei weithredu gan ddefnyddio'r opsiynau hyn. Ond am y tro, rydym wedi canolbwyntio ar OpenZFS, oherwydd roedd problemau gyda LVM yn benodol.

Sut mae'n gweithio? Yn lle trosysgrifo'r data bob tro y byddwn yn ei newid, rydym yn ei arbed trwy nodi'n syml bod y data newydd hwn o bwynt newydd mewn amser, yn giplun newydd.

Ac yn y dyfodol, pan fyddwn ni eisiau dychwelyd neu os ydym am wneud clôn newydd o fersiwn hŷn, rydyn ni'n dweud: "Iawn, rhowch y blociau data hyn i ni sydd wedi'u marcio fel hyn."

A bydd y defnyddiwr hwn yn gweithio gyda set ddata o'r fath. Bydd yn eu newid yn raddol, yn gwneud ei gipluniau ei hun.

A byddwn yn cangen. Bydd pob datblygwr yn ein hachos ni yn cael y cyfle i gael ei glôn ei hun y mae'n ei olygu, a bydd y data a rennir yn cael ei rannu rhwng pawb.

I ddefnyddio system o'r fath gartref, mae angen i chi ddatrys dwy broblem:

• Y cyntaf yw ffynhonnell y data, o ble y byddwch chi'n ei gymryd. Gallwch chi osod atgynhyrchu gyda chynhyrchiad. Gallwch chi eisoes ddefnyddio'r copïau wrth gefn rydych chi wedi'u ffurfweddu, gobeithio. WAL-E, WAL-G neu Barman. A hyd yn oed os ydych chi'n defnyddio rhyw fath o ddatrysiad Cloud fel RDS neu Cloud SQL, yna gallwch chi ddefnyddio tomenni rhesymegol. Ond rydym yn dal i'ch cynghori i ddefnyddio copïau wrth gefn, oherwydd gyda'r dull hwn byddwch hefyd yn cadw strwythur ffisegol y ffeiliau, a fydd yn caniatáu ichi fod hyd yn oed yn agosach at y metrigau y byddech chi'n eu gweld wrth gynhyrchu er mwyn dal y problemau hynny sy'n bodoli.

• Yr ail yw lle rydych chi am gynnal y Labordy Cronfa Ddata. Gallai fod yn Cloud, gallai fod yn On-premise. Mae'n bwysig dweud yma bod ZFS yn cefnogi cywasgu data. Ac mae'n ei wneud yn eithaf da.

Dychmygwch, ar gyfer pob clôn o'r fath, yn dibynnu ar y gweithrediadau a wnawn gyda'r sylfaen, bydd rhyw fath o ddatblygiad yn tyfu. Ar gyfer hyn, bydd angen lle ar dev hefyd. Ond oherwydd y ffaith inni gymryd sylfaen o 4,5 terabytes, bydd ZFS yn ei gywasgu i 3,5 terabytes. Gall hyn amrywio yn dibynnu ar y gosodiadau. Ac mae gennym le i ddatblygu o hyd.

Gellir defnyddio system o'r fath ar gyfer gwahanol achosion.

• Mae'r rhain yn ddatblygwyr, DBAs ar gyfer dilysu ymholiad, ar gyfer optimeiddio.

• Gellir defnyddio hwn mewn profion SA i brofi mudo penodol cyn i ni ei gyflwyno i gynhyrchu. A gallwn hefyd godi amgylcheddau arbennig ar gyfer QA gyda data go iawn, lle gallant brofi ymarferoldeb newydd. A bydd yn cymryd eiliadau yn lle oriau aros, ac efallai dyddiau mewn rhai achosion eraill lle na ddefnyddir copïau tenau.

• Ac achos arall. Os nad oes gan y cwmni system ddadansoddeg wedi'i sefydlu, yna gallwn ynysu clôn tenau o sylfaen y cynnyrch a'i roi i ymholiadau hir neu fynegeion arbennig y gellir eu defnyddio mewn dadansoddeg.

Gyda'r dull hwn:

1. Tebygolrwydd isel o wallau ar y "prod", oherwydd i ni brofi'r holl newidiadau ar ddata maint llawn.

2. Mae gennym ddiwylliant o brofi, oherwydd nawr nid oes yn rhaid i chi aros am oriau ar gyfer eich stondin eich hun.

3. Ac nid oes rhwystr, dim aros rhwng profion. Gallwch chi fynd i wirio mewn gwirionedd. A bydd yn well fel hyn wrth i ni gyflymu'r datblygiad.

• Bydd llai o ailffactorio. Bydd llai o fygiau yn y pen draw yn prod. Byddwn yn eu hailystyried yn llai yn ddiweddarach.

• Gallwn wrthdroi newidiadau na ellir eu gwrthdroi. Nid dyma'r dull safonol.

1. Mae hyn yn fuddiol oherwydd ein bod yn rhannu adnoddau'r meinciau prawf.

Eisoes yn dda, ond beth arall y gellid ei gyflymu?

Diolch i system o'r fath, gallwn leihau'r trothwy ar gyfer mynd i mewn i brofion o'r fath yn fawr.

Nawr mae yna gylch dieflig, pan fydd yn rhaid i ddatblygwr, er mwyn cael mynediad at ddata maint llawn go iawn, ddod yn arbenigwr. Rhaid ymddiried ynddo gyda mynediad o'r fath.

Ond sut i dyfu os nad yw yno. Ond beth os mai dim ond set fach iawn o ddata prawf sydd ar gael i chi? Yna ni fyddwch yn cael unrhyw brofiad go iawn.

Sut i fynd allan o'r cylch hwn? Fel y rhyngwyneb cyntaf, sy'n gyfleus i ddatblygwyr o unrhyw lefel, fe wnaethon ni ddewis y Slack bot. Ond gall fod yn unrhyw ryngwyneb arall.

Beth mae'n caniatáu ichi ei wneud? Gallwch gymryd ymholiad penodol a'i anfon i sianel arbennig ar gyfer y gronfa ddata. Byddwn yn defnyddio clôn tenau yn awtomatig mewn eiliadau. Gadewch i ni redeg y cais hwn. Rydym yn casglu metrigau ac argymhellion. Gadewch i ni ddangos delweddu. Ac yna bydd y clôn hwn yn aros fel y gellir optimeiddio'r ymholiad hwn rywsut, ychwanegu mynegeion, ac ati.

A hefyd mae Slack yn rhoi cyfleoedd i ni gydweithio allan o'r bocs. Gan mai sianel yn unig yw hon, gallwch chi ddechrau trafod y cais hwn yno yn yr edefyn ar gyfer cais o'r fath, ping eich cydweithwyr, DBAs sydd y tu mewn i'r cwmni.

Ond mae yna broblemau, wrth gwrs. Gan mai dyma'r byd go iawn, ac rydym yn defnyddio gweinydd sy'n cynnal llawer o glonau ar unwaith, mae'n rhaid i ni gywasgu faint o bŵer cof a CPU sydd ar gael i'r clonau.

Ond er mwyn i'r profion hyn fod yn gredadwy, mae angen ichi ddatrys y broblem hon rywsut.

Mae'n amlwg mai'r un data yw'r pwynt pwysig. Ond mae gennym ni eisoes. Ac rydym am gyflawni'r un ffurfweddiad. A gallwn roi cyfluniad o'r fath bron yn union yr un fath.

Byddai'n cŵl cael yr un caledwedd ag wrth gynhyrchu, ond gall fod yn wahanol.

Gadewch i ni gofio sut mae Postgres yn gweithio gyda'r cof. Mae gennym ddau caches. Un o'r system ffeiliau ac un Postgres brodorol, h.y. Shared Buffer Cache.

Mae'n bwysig nodi bod y Cache Clustogi a Rennir yn cael ei ddyrannu pan fydd Postgres yn dechrau, yn dibynnu ar ba faint rydych chi'n ei nodi yn y ffurfweddiad.

Ac mae'r ail storfa yn defnyddio'r holl le sydd ar gael.

A phan fyddwn yn gwneud sawl clon ar un peiriant, mae'n troi allan ein bod yn llenwi'r cof yn raddol. Ac mewn ffordd dda, mae Shared Buffer Cache yn 25% o gyfanswm y cof sydd ar gael ar y peiriant.

Ac mae'n ymddangos, os na fyddwn yn newid y paramedr hwn, yna dim ond 4 achos y byddwn yn gallu rhedeg ar un peiriant, hy 4 o'r holl glonau tenau o'r fath. Ac mae hyn, wrth gwrs, yn ddrwg, oherwydd rydym ni eisiau cael llawer mwy ohonyn nhw.

Ond ar y llaw arall, defnyddir Buffer Cache i weithredu ymholiadau am fynegeion, hynny yw, mae'r cynllun yn dibynnu ar ba mor fawr yw ein caches. Ac os cymerwn y paramedr hwn a'i leihau, yna gall ein cynlluniau newid llawer.

Er enghraifft, os oes gennym storfa fawr ar y prod, yna bydd yn well gan Postgres ddefnyddio mynegai. Ac os na, yna bydd SeqScan. A beth fyddai'r pwynt pe na bai ein cynlluniau'n cyd-daro?

Ond yma rydym yn dod i'r casgliad nad yw'r cynllun yn Postgres mewn gwirionedd yn dibynnu ar y maint penodol a nodir yn y Clustogfa a Rennir yn y cynllun, mae'n dibynnu ar y effective_cache_size.

Effeithiol_cache_size yw’r swm amcangyfrifedig o storfa sydd ar gael i ni, h.y. swm y Cache Clustogi a storfa system ffeiliau. Mae hyn yn cael ei osod gan y config. Ac nid yw'r cof hwn yn cael ei ddyrannu.

Ac oherwydd y paramedr hwn, gallwn ni dwyllo Postgres, gan ddweud bod gennym ni lawer o ddata ar gael mewn gwirionedd, hyd yn oed os nad oes gennym ni'r data hwn. Ac felly, bydd y cynlluniau yn cyd-fynd yn llwyr â chynhyrchu.

Ond gall hyn effeithio ar yr amseriad. Ac rydym yn gwneud y gorau o ymholiadau yn ôl amseriad, ond mae'n bwysig bod amseriad yn dibynnu ar lawer o ffactorau:

• Mae'n dibynnu ar y llwyth sydd ar prod ar hyn o bryd.

• Mae'n dibynnu ar nodweddion y peiriant ei hun.

Ac mae hwn yn baramedr anuniongyrchol, ond mewn gwirionedd gallwn wneud y gorau yn union gan faint o ddata y bydd yr ymholiad hwn yn ei ddarllen er mwyn cael y canlyniad.

Ac os ydych chi am i'r amseriad fod yn agos at yr hyn a welwn yn prod, yna mae angen i ni gymryd y caledwedd mwyaf tebyg ac, o bosibl, hyd yn oed yn fwy fel bod yr holl glonau'n ffitio. Ond cyfaddawd yw hwn, h.y. byddwch yn cael yr un cynlluniau, fe welwch faint o ddata y bydd ymholiad penodol yn ei ddarllen a byddwch yn gallu dod i'r casgliad a yw'r ymholiad hwn yn dda (neu'n mudo) neu'n ddrwg, mae angen ei optimeiddio o hyd .

Gadewch i ni edrych ar sut mae Joe wedi'i optimeiddio'n benodol.

Gadewch i ni gymryd cais gan system go iawn. Yn yr achos hwn, mae'r gronfa ddata yn 1 terabyte. Ac rydyn ni eisiau cyfrif nifer y postiadau ffres a gafodd fwy na 10 o hoffterau.

Rydym yn ysgrifennu neges i'r sianel, mae clôn wedi'i ddefnyddio ar ein cyfer. A byddwn yn gweld y bydd cais o'r fath yn cael ei gwblhau mewn 2,5 munud. Dyma'r peth cyntaf rydyn ni'n sylwi arno.

Bydd B Joe yn dangos argymhellion awtomatig i chi yn seiliedig ar y cynllun a'r metrigau.

Byddwn yn gweld bod yr ymholiad yn prosesu gormod o ddata i gael nifer gymharol fach o resi. Ac mae angen rhyw fath o fynegai arbenigol, oherwydd i ni sylwi bod gormod o resi wedi'u hidlo yn yr ymholiad.

Gadewch i ni edrych yn agosach ar yr hyn a ddigwyddodd. Yn wir, gwelwn ein bod wedi darllen bron i un a hanner gigabeit o ddata o'r storfa ffeiliau neu hyd yn oed o ddisg. Ac nid yw hyn yn dda, oherwydd ni chawsom ond 142 o linellau.

Ac, mae'n ymddangos, mae gennym ni sgan mynegai yma a dylai fod wedi gweithio allan yn gyflym, ond ers i ni hidlo gormod o linellau (roedd yn rhaid i ni eu cyfrif), fe weithiodd y cais yn araf.

A digwyddodd hyn yn y cynllun oherwydd y ffaith nad yw'r amodau yn yr ymholiad a'r amodau yn y mynegai yn cyfateb yn rhannol.

Gadewch i ni geisio gwneud y mynegai yn fwy manwl gywir a gweld sut mae gweithrediad yr ymholiad yn newid ar ôl hynny.

Cymerodd amser eithaf hir i greu'r mynegai, ond nawr rydym yn gwirio'r ymholiad a gweld mai dim ond 2,5 milieiliad yw'r amser yn lle 156 munud, sy'n ddigon da. Ac rydym yn darllen dim ond 6 megabeit o ddata.

Ac yn awr rydym yn defnyddio sgan mynegai yn unig.

Stori bwysig arall yw ein bod am gyflwyno’r cynllun mewn ffordd fwy dealladwy. Rydym wedi gweithredu delweddu gan ddefnyddio Graffiau Fflam.

Mae hwn yn gais gwahanol, yn fwy dwys. Ac rydym yn adeiladu Graffiau Fflam yn ôl dau baramedr: dyma faint o ddata a gyfrifwyd gan nod penodol yn y cynllun a'r amseriad, h.y. amser gweithredu'r nod.

Yma gallwn gymharu nodau penodol â'i gilydd. A bydd yn amlwg pa un ohonynt sy'n cymryd mwy neu lai, sydd fel arfer yn anodd ei wneud mewn dulliau rendro eraill.

Wrth gwrs, mae pawb yn gwybod explain.depesz.com. Nodwedd dda o'r delweddu hwn yw ein bod yn arbed y cynllun testun a hefyd yn rhoi rhai paramedrau sylfaenol mewn tabl fel y gallwn ddidoli.

Ac mae datblygwyr nad ydynt eto wedi ymchwilio i'r pwnc hwn hefyd yn defnyddio explain.depesz.com, oherwydd mae'n haws iddynt ddarganfod pa fetrigau sy'n bwysig a pha rai nad ydynt.

Mae yna ddull newydd o ddelweddu - esbonio.dalibo.com yw hyn. Maent yn delweddu coeden, ond mae'n anodd iawn cymharu nodau â'i gilydd. Yma gallwch chi ddeall y strwythur yn dda, fodd bynnag, os oes cais mawr, yna bydd angen i chi sgrolio yn ôl ac ymlaen, ond hefyd opsiwn.

cydweithio

Ac, fel y dywedais, mae Slack yn rhoi cyfle inni gydweithio. Er enghraifft, os down ar draws ymholiad cymhleth nad yw'n glir sut i wneud y gorau ohono, gallwn egluro'r mater hwn gyda'n cydweithwyr mewn edefyn yn Slack.

Mae'n ymddangos i ni ei bod yn bwysig profi ar ddata maint llawn. I wneud hyn, gwnaethom yr offeryn Diweddaru Cronfa Ddata Lab, sydd ar gael mewn ffynhonnell agored. Gallwch chi ddefnyddio'r Joe bot hefyd. Gallwch ei gymryd ar hyn o bryd a'i roi ar waith yn eich lle. Mae'r holl ganllawiau ar gael yno.

Mae hefyd yn bwysig nodi nad yw'r ateb ei hun yn chwyldroadol, oherwydd mae Delphix, ond mae'n ateb menter. Mae wedi'i gau'n llwyr, mae'n ddrud iawn. Rydym yn arbenigo yn benodol mewn Postgres. Mae'r rhain i gyd yn gynhyrchion ffynhonnell agored. Ymunwch â ni!

Dyma lle dwi'n gorffen. Diolch!

cwestiynau

Helo! Diolch am yr adroddiad! Diddorol iawn, yn enwedig i mi, oherwydd fe wnes i ddatrys am yr un broblem beth amser yn ôl. Ac felly mae gen i nifer o gwestiynau. Gobeithio y caf o leiaf ran ohono.

Tybed sut rydych chi'n cyfrifo'r lle ar gyfer yr amgylchedd hwn? Mae'r dechnoleg yn golygu, o dan rai amgylchiadau, y gall eich clonau dyfu i'r maint mwyaf. Yn fras, os oes gennych chi gronfa ddata deg terabyte a 10 clon, yna mae'n hawdd efelychu sefyllfa lle mae pob clôn yn pwyso 10 data unigryw. Sut ydych chi'n cyfrifo'r lle hwn, hynny yw, y delta y siaradoch chi amdano, y bydd y clonau hyn yn byw ynddo?

Cwestiwn da. Mae'n bwysig cadw golwg ar glonau penodol yma. Ac os oes gan glôn newid rhy fawr, mae'n dechrau tyfu, yna gallwn yn gyntaf roi rhybudd i'r defnyddiwr am hyn, neu atal y clôn hwn ar unwaith fel nad oes gennym sefyllfa fethiant.

Oes, mae gen i gwestiwn nythu. Hynny yw, sut ydych chi'n sicrhau cylch bywyd y modiwlau hyn? Mae gennym y broblem hon a stori gyfan gwbl ar wahân. Sut mae hyn yn digwydd?

Mae rhywfaint o ttl ar gyfer pob clôn. Yn y bôn, mae gennym ttl sefydlog.

Beth, os nad yn gyfrinach?

1 awr, h.y. segur - 1 awr. Os na chaiff ei ddefnyddio, yna rydym yn ei guro. Ond nid oes unrhyw syndod yma, gan y gallwn godi'r clôn mewn eiliadau. Ac os oes ei angen arnoch eto, yna os gwelwch yn dda.

Mae gennyf ddiddordeb hefyd yn y dewis o dechnolegau, oherwydd, er enghraifft, rydym yn defnyddio sawl dull ochr yn ochr am ryw reswm neu'i gilydd. Pam ZFS? Pam na wnaethoch chi ddefnyddio LVM? Soniasoch fod problemau gyda LVM. Beth oedd y problemau? Yn fy marn i, yr opsiwn mwyaf optimaidd yw storio, o ran perfformiad.

Beth yw'r brif broblem gyda ZFS? Y ffaith bod yn rhaid i chi redeg ar yr un gwesteiwr, h.y. bydd pob achos yn byw o fewn yr un OS. Ac yn achos storio, gallwch gysylltu gwahanol offer. A dim ond y blociau hynny sydd ar y system storio yw'r dagfa. Ac mae'r cwestiwn o ddewis technolegau yn ddiddorol. Beth am LVM?

Yn benodol, gallwn drafod LVM yn y cyfarfod. Ynglŷn â storio - mae'n ddrud. Gallwn weithredu'r system ZFS yn unrhyw le. Gallwch ei ddefnyddio ar eich peiriant. Yn syml, gallwch chi lawrlwytho'r ystorfa a'i defnyddio. Mae ZFS wedi'i osod bron ym mhobman os ydym yn sôn am Linux. Hynny yw, rydym yn cael ateb hyblyg iawn. Ac mae ZFS ei hun yn rhoi llawer allan o'r bocs. Gallwch uwchlwytho cymaint o ddata ag y dymunwch, cysylltu nifer fawr o ddisgiau, mae yna gipluniau. Ac, fel y dywedais, mae'n hawdd ei weinyddu. Hynny yw, mae'n ymddangos yn ddymunol iawn i'w ddefnyddio. Profir ef, y mae yn flynyddau lawer. Mae ganddo gymuned fawr iawn sy'n tyfu. Mae ZFS yn ateb dibynadwy iawn.

Nikolai Samokhvalov: A gaf wneud sylwadau pellach? Fy enw i yw Nikolay, rydym yn gweithio gyda Anatoly. Rwy'n cytuno bod storio yn wych. Ac mae gan rai o'n cwsmeriaid Storfa Bur ac ati.

Nododd Anatoly yn gywir ein bod yn canolbwyntio ar fodiwlaidd. Ac yn y dyfodol, gallwch chi weithredu un rhyngwyneb - cymryd cipolwg, gwneud clôn, dinistrio'r clôn. Mae'r cyfan yn hawdd. Ac mae storio yn oer, os ydyw.

Ond mae ZFS ar gael i bawb. Mae DelPhix eisoes yn ddigon, mae ganddyn nhw 300 o gleientiaid. O'r rhain, mae gan ffortiwn 100 50 o gleientiaid, h.y. maent wedi'u hanelu at NASA, ac ati. Mae'n bryd i bawb gael y dechnoleg hon. A dyna pam mae gennym Craidd ffynhonnell agored. Mae gennym ran rhyngwyneb nad yw'n ffynhonnell agored. Dyma'r platfform y byddwn yn ei ddangos. Ond rydym am iddo fod yn hygyrch i bawb. Rydyn ni eisiau gwneud chwyldro fel bod pob profwr yn rhoi'r gorau i ddyfalu ar liniaduron. Mae'n rhaid i ni ysgrifennu SELECT a gweld ar unwaith ei fod yn araf. Stopiwch aros i'r DBA ddweud wrthych amdano. Dyma'r prif nod. Ac rwy’n meddwl y byddwn ni i gyd yn dod at hyn. Ac rydyn ni'n gwneud y peth hwn i bawb ei gael. Felly ZFS, oherwydd bydd ar gael ym mhobman. Diolch i'r gymuned am ddatrys problemau ac am gael trwydded ffynhonnell agored, ac ati.*

Cyfarchion! Diolch am yr adroddiad! Fy enw i yw Maxim. Yr ydym wedi ymdrin â’r un materion. Penderfynasant ar eu pen eu hunain. Sut ydych chi'n rhannu adnoddau rhwng y clonau hyn? Gall pob clôn wneud ei beth ei hun ar unrhyw adeg benodol: mae un yn profi un peth, un arall yn un arall, mae rhywun yn adeiladu mynegai, mae gan rywun waith trwm. Ac os gallwch chi rannu â CPU o hyd, yna trwy IO, sut ydych chi'n rhannu? Dyma'r cwestiwn cyntaf.

Ac mae'r ail gwestiwn yn ymwneud ag annhebygrwydd y standiau. Dywedwch fod gen i ZFS yma ac mae popeth yn cŵl, ond nid oes gan y cleient ar y prod ZFS, ond ext4, er enghraifft. Sut yn yr achos hwn?

Mae'r cwestiynau'n dda iawn. Soniais ychydig am y broblem hon gyda’r ffaith ein bod yn rhannu adnoddau. A dyma'r ateb. Dychmygwch eich bod yn profi ar lwyfannu. Gallwch hefyd gael sefyllfa o'r fath ar yr un pryd bod rhywun yn rhoi un llwyth, rhywun arall. Ac o ganlyniad, rydych chi'n gweld metrigau annealladwy. Gall hyd yn oed yr un broblem fod gyda phrod. Pan fyddwch chi eisiau gwirio rhywfaint o gais a gweld bod rhywfaint o broblem ag ef - mae'n gweithio'n araf, yna mewn gwirionedd nid oedd y broblem yn y cais, ond yn y ffaith bod rhyw fath o lwyth cyfochrog.

Ac felly, mae’n bwysig yma ganolbwyntio ar beth fydd y cynllun, pa gamau y byddwn yn eu cymryd yn y cynllun a faint o ddata y byddwn yn ei godi ar gyfer hyn. Mae'r ffaith y bydd ein disgiau, er enghraifft, yn cael eu llwytho â rhywbeth, bydd yn effeithio'n benodol ar yr amseriad. Ond gallwn amcangyfrif faint o ddata sydd ar y cais hwn. Nid yw mor bwysig ar yr un pryd y bydd rhyw fath o ddienyddiad.

Mae gennyf ddau gwestiwn. Mae hwn yn stwff cŵl iawn. A fu achosion lle mae data cynhyrchu yn hollbwysig, megis rhifau cardiau credyd? A oes rhywbeth yn barod yn barod neu a yw'n dasg ar wahân? A'r ail gwestiwn - a oes rhywbeth fel hyn ar gyfer MySQL?

Am y data. Gwnawn obfuscation hyd nes y gwnawn. Ond os ydych chi'n defnyddio Joe yn union, os na fyddwch chi'n rhoi mynediad i ddatblygwyr, yna nid oes mynediad i'r data. Pam? Oherwydd nid yw Joe yn dangos data. Dim ond metrigau, cynlluniau y mae'n eu dangos a dyna ni. Gwnaed hyn yn bwrpasol, oherwydd dyma un o ofynion ein cleient. Roeddent eisiau gallu optimeiddio heb roi mynediad i bawb.

Ynglŷn â MySQL. Gellir defnyddio'r system hon ar gyfer unrhyw beth sy'n storio cyflwr ar ddisg. A chan ein bod ni'n gwneud Postgres, rydyn ni nawr yn gwneud yr holl awtomeiddio ar gyfer Postgres yn gyntaf. Rydym am awtomeiddio cael data o gopi wrth gefn. Rydym yn ffurfweddu Postgres yn gywir. Rydyn ni'n gwybod sut i wneud i gynlluniau gyfateb, ac ati.

Ond gan fod y system yn estynadwy, gellir ei defnyddio hefyd ar gyfer MySQL. Ac mae enghreifftiau o'r fath. Mae gan Yandex beth tebyg, ond nid ydynt yn ei gyhoeddi yn unman. Maent yn ei ddefnyddio y tu mewn i Yandex.Metrica. A dim ond stori sydd am MySQL. Ond mae'r technolegau yr un peth, ZFS.

Diolch am yr adroddiad! Mae gen i gwpl o gwestiynau hefyd. Soniasoch y gellir defnyddio clonio ar gyfer dadansoddeg, er enghraifft i adeiladu mynegeion ychwanegol yno. A allwch chi ddweud ychydig mwy am sut mae'n gweithio?

A byddaf yn gofyn yr ail gwestiwn ar unwaith am debygrwydd y stondinau, tebygrwydd y cynlluniau. Mae'r cynllun hefyd yn dibynnu ar yr ystadegau a gasglwyd gan Postgres. Sut ydych chi'n datrys y broblem hon?

Yn ôl y dadansoddeg, nid oes unrhyw achosion penodol, oherwydd nid ydym wedi ei ddefnyddio eto, ond mae cyfle o'r fath. Os ydym yn sôn am fynegeion, yna dychmygwch fod ymholiad yn mynd ar drywydd tabl gyda channoedd o filiynau o gofnodion a cholofn nad yw fel arfer wedi'i mynegeio mewn prod. Ac rydym am gyfrifo rhywfaint o ddata yno. Os anfonir y cais hwn i'r prod, yna mae'n bosibl y bydd yn syml ar prod, oherwydd bydd y cais yn cael ei brosesu yno am funud.

Iawn, gadewch i ni wneud clôn tenau nad yw'n ofnadwy i stopio am ychydig funudau. Ac er mwyn ei gwneud yn fwy cyfforddus i ddarllen y dadansoddeg, byddwn yn ychwanegu mynegeion ar gyfer y colofnau hynny y mae gennym ddiddordeb mewn data ynddynt.

Bydd y mynegai yn cael ei greu bob tro?

Gallwch ei wneud fel ein bod yn cyffwrdd â'r data, yn gwneud cipluniau, yna byddwn yn adfer o'r ciplun hwn ac yn gyrru ceisiadau newydd. Hynny yw, gallwch chi ei wneud fel y gallwch chi godi clonau newydd gyda mynegeion sydd eisoes wedi'u gosod.

O ran y cwestiwn am ystadegau, os byddwn yn adfer o gopi wrth gefn, os byddwn yn dyblygu, yna bydd ein hystadegau yn union yr un fath. Oherwydd bod gennym y strwythur data ffisegol cyfan, hynny yw, byddwn yn dod â'r data fel y mae gyda'r holl fetrigau ystadegau hefyd.

Dyma broblem arall. Os ydych chi'n defnyddio datrysiad cwmwl, yna dim ond tomenni rhesymegol sydd ar gael yno, oherwydd nid yw Google, Amazon yn caniatáu ichi gymryd copi corfforol. Bydd problem.

Diolch am yr adroddiad. Roedd dau gwestiwn da yma am MySQL a rhannu adnoddau. Ond, mewn gwirionedd, mae'r cyfan yn dibynnu ar y ffaith nad yw hwn yn bwnc o DBMS penodol, ond o'r system ffeiliau yn ei chyfanrwydd. Ac, yn unol â hynny, dylid datrys materion rhannu adnoddau oddi yno hefyd, nid o'r diwedd mai Postgres ydyw, ond yn y system ffeiliau, yn y gweinydd, er enghraifft.

Mae fy nghwestiwn ychydig yn wahanol. Mae'n agosach at y gronfa ddata aml-haenog, lle mae sawl haen. Er enghraifft, rydym yn sefydlu diweddariad delwedd deg-terabyte, rydym yn ailadrodd. Ac rydym yn defnyddio'r ateb hwn yn benodol ar gyfer cronfeydd data. Mae atgynhyrchu ar y gweill, mae data'n cael ei ddiweddaru. Mae 100 o weithwyr yn gweithio ochr yn ochr, sy'n lansio'r gwahanol luniau hyn yn gyson. Beth i'w wneud? Sut i wneud yn siŵr nad oes gwrthdaro, eu bod wedi lansio un, ac yna newidiodd y system ffeiliau, ac aeth y lluniau hyn i gyd?

Ni fyddant yn mynd oherwydd dyna sut mae ZFS yn gweithio. Gallwn gadw ar wahân mewn un edefyn y newidiadau system ffeiliau a ddaw oherwydd atgynhyrchu. A chadwch y clonau y mae datblygwyr yn eu defnyddio ar fersiynau hŷn o'r data. Ac mae'n gweithio i ni, mae popeth mewn trefn gyda hyn.

Mae'n troi allan y bydd y diweddariad yn digwydd fel haen ychwanegol, a bydd yr holl luniau newydd yn mynd yn barod, yn seiliedig ar yr haen hon, iawn?

O haenau blaenorol a oedd o atgynyrchiadau blaenorol.

Bydd yr haenau blaenorol yn disgyn i ffwrdd, ond byddant yn cyfeirio at yr hen haen, ac a fyddant yn cymryd delweddau newydd o'r haen olaf a dderbyniwyd yn y diweddariad?

Yn gyffredinol, ie.

Yna o ganlyniad bydd gennym hyd at ffigys o haenau. A thros amser bydd angen eu cywasgu?

Ydy mae popeth yn gywir. Mae rhywfaint o ffenestr. Rydym yn cadw cipluniau wythnosol. Mae'n dibynnu ar ba adnodd sydd gennych chi. Os oes gennych y gallu i storio llawer o ddata, gallwch storio cipluniau am amser hir. Ni fyddant yn mynd i ffwrdd ar eu pen eu hunain. Ni fydd unrhyw lygredd data. Os yw'r cipluniau'n hen ffasiwn, fel y mae'n ymddangos i ni, h.y. mae'n dibynnu ar y polisi yn y cwmni, yna gallwn eu dileu a rhyddhau lle.

Helo, diolch am yr adroddiad! Cwestiwn am Joe. Dywedasoch nad oedd y cwsmer am roi mynediad i bawb at y data. A siarad yn fanwl gywir, os oes gan berson ganlyniad Egluro Dadansoddi, yna gall edrych ar y data.

Dyna fel yna. Er enghraifft, gallwn ysgrifennu: "SELECT O BLE email = i hynny". Hynny yw, ni fyddwn yn gweld y data ei hun, ond gallwn weld rhai arwyddion anuniongyrchol. Rhaid deall hyn. Ond ar y llaw arall, mae'r cyfan yno. Mae gennym archwiliad log, mae gennym reolaeth ar gydweithwyr eraill sydd hefyd yn gweld beth mae'r datblygwyr yn ei wneud. Ac os bydd rhywun yn ceisio gwneud hyn, yna bydd y gwasanaeth diogelwch yn dod atynt ac yn gweithio ar y mater hwn.

Prynhawn Da Diolch am yr adroddiad! Mae gennyf gwestiwn byr. Os nad yw'r cwmni'n defnyddio Slack, a oes unrhyw rwymiad iddo nawr, neu a yw'n bosibl i ddatblygwyr ddefnyddio achosion er mwyn cysylltu cais prawf â'r cronfeydd data?

Nawr mae dolen i Slack, h.y. nid oes negesydd arall, ond rydw i wir eisiau cefnogi negeswyr eraill hefyd. Beth wyt ti'n gallu gwneud? Gallwch chi ddefnyddio DB Lab heb Joe, mynd gyda chymorth yr API REST neu gyda chymorth ein platfform a chreu clonau a chysylltu â PSQL. Ond gellir gwneud hyn os ydych chi'n barod i roi mynediad i'r data i'ch datblygwyr, oherwydd ni fydd unrhyw sgrin mwyach.

Nid oes angen yr haen hon arnaf, ond mae angen cyfle o'r fath arnaf.

Yna ie, gellir ei wneud.

Ffynhonnell: hab.com