DBA láni Joe. Anatoly Stansler (Postgres.ai)

Hvernig skilur bakendi verktaki að SQL fyrirspurn muni virka vel á „prod“? Í stórum eða ört vaxandi fyrirtækjum hafa ekki allir aðgang að „vörunni“. Og með aðgangi er ekki hægt að athuga allar beiðnir sársaukalaust og það tekur oft nokkrar klukkustundir að búa til afrit af gagnagrunninum. Til að leysa þessi vandamál bjuggum við til gervi DBA - Joe. Það hefur þegar verið innleitt með góðum árangri í nokkrum fyrirtækjum og hjálpar meira en tugi þróunaraðila.

Video:

Hæ allir! Ég heiti Anatoly Stansler. Ég vinn hjá fyrirtæki postgres.ai. Við erum staðráðin í að hraða þróunarferlinu með því að fjarlægja tafir sem tengjast starfi Postgres frá hönnuðum, DBA og QAs.

Við eigum frábæra viðskiptavini og í dag verður hluti skýrslunnar helgaður málum sem við hittum þegar við unnum með þá. Ég mun tala um hvernig við hjálpuðum þeim að leysa alvarleg vandamál.

Þegar við erum að þróa og gera flóknar flutninga á háu álagi spyrjum við okkur spurningarinnar: „Mun þessi flutningur taka við?“. Við notum endurskoðun, við notum þekkingu reyndari samstarfsmanna, DBA sérfræðinga. Og þeir geta sagt hvort það mun fljúga eða ekki.

En kannski væri betra ef við gætum prófað það sjálf á eintökum í fullri stærð. Og í dag munum við bara tala um hvaða aðferðir við prófanir eru núna og hvernig hægt er að gera það betur og með hvaða verkfærum. Við munum einnig tala um kosti og galla slíkra aðferða og hvað við getum lagað hér.

Hver hefur einhvern tíma gert vísitölur beint á vöru eða gert einhverjar breytingar? Nokkuð af. Og fyrir hvern leiddi þetta til þess að gögn týndust eða niður í miðbæ? Þá þekkirðu þennan sársauka. Guði sé lof að það eru öryggisafrit.

Fyrsta aðferðin er prófun í framleiðslu. Eða, þegar verktaki situr á staðbundinni vél, hefur hann prófunargögn, það er einhvers konar takmarkað úrval. Og við rúllum út til að stinga, og við fáum þetta ástand.

Það er sárt, það er dýrt. Það er líklega best að gera það ekki.

Og hvernig er best að gera það?

Tökum sviðsetningu og veljum einhvern hluta af pród þar. Eða í besta falli, við skulum taka alvöru prod, öll gögnin. Og eftir að við höfum þróað það á staðnum munum við að auki athuga hvort sviðsetning sé.

Þetta gerir okkur kleift að fjarlægja sumar villurnar, þ.e.a.s. koma í veg fyrir að þær séu á framleiðslu.

Hver eru vandamálin?

• Vandamálið er að við deilum þessari sviðsetningu með samstarfsfólki. Og mjög oft gerist það að þú gerir einhvers konar breytingu, bam - og það eru engin gögn, vinnan er í holræsi. Sviðsetning var margra terabæta. Og þú þarft að bíða lengi eftir að hann rísi aftur. Og við ákveðum að klára það á morgun. Það er það, við höfum þróun.
• Og auðvitað erum við með marga samstarfsmenn sem vinna þarna, mörg teymi. Og það þarf að gera það handvirkt. Og þetta er óþægilegt.

Og það er þess virði að segja að við höfum aðeins eina tilraun, eitt skot, ef við viljum gera nokkrar breytingar á gagnagrunninum, snerta gögnin, breyta uppbyggingunni. Og ef eitthvað fór úrskeiðis, ef villa var í flutningnum, þá munum við ekki snúa aftur til baka.

Þetta er betra en fyrri nálgun, en samt eru miklar líkur á að einhvers konar villa fari í framleiðslu.

Hvað kemur í veg fyrir að við gefum hverjum forritara prófunarbekk, eintak í fullri stærð? Ég held að það sé ljóst hvað kemur í veg fyrir.

Hver er með gagnagrunn sem er stærri en terabæt? Meira en hálft herbergið.

Og það er ljóst að það er mjög dýrt að halda vélum fyrir hvern framkvæmdaraðila, þegar það er svo mikil framleiðsla, og þar að auki tekur það langan tíma.

Við höfum viðskiptavini sem hafa áttað sig á því að það er mjög mikilvægt að prófa allar breytingar á eintökum í fullri stærð, en gagnagrunnur þeirra er minna en terabæt og það eru engin úrræði til að halda prófunarbekk fyrir hvern forritara. Þess vegna verða þeir að hlaða niður sorpunum á staðnum á vélina sína og prófa á þennan hátt. Það tekur mikinn tíma.

Jafnvel ef þú gerir það inni í innviðum, þá er nú þegar mjög gott að hala niður einu terabæti af gögnum á klukkustund. En þeir nota rökrétt sorp, þeir hlaða niður á staðnum úr skýinu. Hjá þeim er hraðinn um 200 gígabæt á klukkustund. Og það tekur enn tíma að snúa við frá rökrænu sorpinu, rúlla upp vísitölum o.s.frv.

En þeir nota þessa nálgun vegna þess að það gerir þeim kleift að halda framleiðslunni áreiðanlega.

Hvað getum við gert hér? Gerum prófunarbekki ódýra og gefum hverjum forritara sinn prófbekk.

Og þetta er hægt.

Og í þessari nálgun, þegar við búum til þunn klón fyrir hvern forritara, getum við deilt því á einni vél. Til dæmis, ef þú ert með 10TB gagnagrunn og vilt gefa hann til 10 forritara, þarftu ekki að hafa XNUMX x XNUMXTB gagnagrunna. Þú þarft aðeins eina vél til að búa til þunn einangruð afrit fyrir hvern forritara sem notar eina vél. Ég skal segja þér hvernig það virkar aðeins síðar.

Raunverulegt dæmi:

• DB - 4,5 terabæta.

• Við getum fengið sjálfstæð eintök á 30 sekúndum.

Þú þarft ekki að bíða eftir prófunarstandi og fer eftir því hversu stór hann er. Þú getur fengið það á nokkrum sekúndum. Það verður algjörlega einangrað umhverfi, en sem deilir gögnum sín á milli.

Þetta er frábært. Hér erum við að tala um galdra og samhliða alheim.

Í okkar tilviki virkar þetta með OpenZFS kerfinu.

OpenZFS er afrita-í-skrifa skráarkerfi sem styður skyndimyndir og klón úr kassanum. Það er áreiðanlegt og skalanlegt. Það er mjög auðvelt að stjórna henni. Það getur bókstaflega verið dreift í tveimur liðum.

Það eru aðrir valkostir:

• lvm,

• Geymsla (til dæmis Pure Storage).

Database Lab sem ég er að tala um er mát. Hægt að útfæra með þessum valkostum. En í bili höfum við einbeitt okkur að OpenZFS, vegna þess að það voru vandamál með LVM sérstaklega.

Hvernig það virkar? Í stað þess að endurskrifa gögnin í hvert skipti sem við breytum þeim vistum við þau með því einfaldlega að merkja að þessi nýju gögn séu frá nýjum tímapunkti, nýrri skyndimynd.

Og í framtíðinni, þegar við viljum afturkalla eða við viljum búa til nýjan klón úr einhverri eldri útgáfu, segjum við bara: "Allt í lagi, gefðu okkur þessar gagnablokkir sem eru merktar svona."

Og þessi notandi mun vinna með slíkt gagnasett. Hann mun smám saman breyta þeim, gera sínar eigin skyndimyndir.

Og við munum útibú. Hver þróunaraðili í okkar tilfelli mun hafa tækifæri til að hafa sinn eigin klón sem hann breytir og gögnunum sem er deilt verður deilt á milli allra.

Til að setja upp slíkt kerfi heima þarftu að leysa tvö vandamál:

• Hið fyrsta er uppspretta gagna, þaðan sem þú munt taka þau. Þú getur sett upp afritun með framleiðslu. Þú getur nú þegar notað öryggisafritin sem þú hefur stillt, vona ég. WAL-E, WAL-G eða Barman. Og jafnvel ef þú ert að nota einhvers konar skýjalausn eins og RDS eða Cloud SQL, þá geturðu notað rökrétt sorp. En við ráðleggjum þér samt að nota öryggisafrit, því með þessari nálgun muntu einnig halda líkamlegri uppbyggingu skráanna, sem gerir þér kleift að vera enn nær þeim mæligildum sem þú myndir sjá í framleiðslu til að ná þeim vandamálum sem eru til staðar.

• Annað er þar sem þú vilt hýsa gagnagrunnsstofuna. Það gæti verið Cloud, það gæti verið á staðnum. Það er mikilvægt að segja hér að ZFS styður gagnaþjöppun. Og það gerir það nokkuð vel.

Ímyndaðu þér að fyrir hvern slíkan klón, eftir aðgerðunum sem við gerum með grunninn, muni einhvers konar dev vaxa. Fyrir þetta mun dev einnig þurfa pláss. En vegna þess að við tókum grunn af 4,5 terabætum, mun ZFS þjappa því niður í 3,5 terabæta. Þetta getur verið mismunandi eftir stillingum. Og við höfum enn pláss fyrir dev.

Slíkt kerfi er hægt að nota fyrir mismunandi tilvik.

• Þetta eru forritarar, DBA fyrir sannprófun fyrirspurna, til hagræðingar.

• Þetta er hægt að nota í QA prófun til að prófa tiltekna flutning áður en við setjum hana út í framleiðslu. Og við getum líka hækkað sérstakt umhverfi fyrir QA með raunverulegum gögnum, þar sem þeir geta prófað nýja virkni. Og það mun taka sekúndur í stað þess að bíða klukkustundir, og kannski daga í sumum öðrum tilvikum þar sem þunn eintök eru ekki notuð.

• Og annað mál. Ef fyrirtækið er ekki með greiningarkerfi sett upp þá getum við einangrað þunnan klón af vörugrunninum og gefið það í langar fyrirspurnir eða sérstakar vísitölur sem hægt er að nota í greiningu.

Með þessari nálgun:

1. Lítil líkur á villum á „prod“ því við prófuðum allar breytingar á gögnum í fullri stærð.

2. Við höfum menningu að prófa, því nú þarftu ekki að bíða tímunum saman eftir þínum eigin bás.

3. Og það er engin hindrun, engin bið á milli prófa. Þú getur í raun farið og athugað. Og það verður betra með þessum hætti þegar við flýtum þróuninni.

• Það verður minni endurnýjun. Færri villur munu enda í framleiðslu. Við munum endurskoða þá minna síðar.

• Við getum snúið við óafturkræfum breytingum. Þetta er ekki staðlað nálgun.

1. Þetta er gagnlegt vegna þess að við deilum auðlindum prófunarbekkanna.

Nú þegar gott, en hvað annað væri hægt að flýta fyrir?

Þökk sé slíku kerfi getum við dregið verulega úr þröskuldinum til að fara í slík próf.

Nú er kominn vítahringur þar sem verktaki verður að verða sérfræðingur til að fá aðgang að raunverulegum gögnum í fullri stærð. Honum verður að treysta fyrir slíkum aðgangi.

En hvernig á að vaxa ef það er ekki til staðar. En hvað ef þú hefur aðeins mjög lítið sett af prófunargögnum tiltækt fyrir þig? Þá færðu enga raunverulega reynslu.

Hvernig á að komast út úr þessum hring? Sem fyrsta viðmótið, þægilegt fyrir forritara á hvaða stigi sem er, völdum við Slack bot. En það getur verið hvaða viðmót sem er.

Hvað leyfir það þér að gera? Þú getur tekið ákveðna fyrirspurn og sent hana á sérstaka rás fyrir gagnagrunninn. Við munum sjálfkrafa setja upp þunnan klón á nokkrum sekúndum. Við skulum keyra þessa beiðni. Við söfnum mælingum og ráðleggingum. Sýnum sjónræna mynd. Og þá verður þessi klón áfram þannig að hægt sé að fínstilla þessa fyrirspurn á einhvern hátt, bæta við vísitölum osfrv.

Og einnig gefur Slack okkur tækifæri til samstarfs út úr kassanum. Þar sem þetta er bara rás geturðu byrjað að ræða þessa beiðni þarna á þræðinum fyrir slíka beiðni, pingaðu samstarfsfólki þínu, DBA sem eru inni í fyrirtækinu.

En það eru auðvitað vandamál. Vegna þess að þetta er hinn raunverulegi heimur og við erum að nota netþjón sem hýsir marga klóna í einu, verðum við að þjappa saman minni og örgjörvaafli sem er tiltækt fyrir klónana.

En til að þessar prófanir séu trúverðugar þarftu einhvern veginn að leysa þetta vandamál.

Það er ljóst að mikilvægi punkturinn eru sömu gögnin. En við höfum það nú þegar. Og við viljum ná sömu uppsetningu. Og við getum gefið svona næstum eins uppsetningu.

Það væri flott að hafa sama vélbúnað og í framleiðslu, en það getur verið mismunandi.

Við skulum muna hvernig Postgres vinnur með minni. Við erum með tvö skyndiminni. Einn úr skráarkerfinu og einn innfæddur Postgres, þ.e. Shared Buffer Cache.

Það er mikilvægt að hafa í huga að Shared Buffer Cache er úthlutað þegar Postgres byrjar, eftir því hvaða stærð þú tilgreinir í stillingunum.

Og annað skyndiminni notar allt tiltækt pláss.

Og þegar við búum til nokkur klón á einni vél kemur í ljós að við fyllum smám saman í minnið. Og á góðan hátt er Shared Buffer Cache 25% af heildarmagni minni sem er tiltækt á vélinni.

Og það kemur í ljós að ef við breytum ekki þessari færibreytu, þá munum við geta keyrt aðeins 4 tilvik á einni vél, þ.e.a.s. 4 af öllum svona þunnum klónum. Og þetta er auðvitað slæmt, því við viljum hafa miklu meira af þeim.

En aftur á móti er Buffer Cache notað til að framkvæma fyrirspurnir fyrir vísitölur, það er að segja að áætlunin fer eftir því hversu stór skyndiminni okkar eru. Og ef við tökum bara þessa breytu og minnkum hana, þá geta áætlanir okkar breyst mikið.

Til dæmis, ef við erum með stórt skyndiminni á prod, þá mun Postgres frekar nota vísitölu. Og ef ekki, þá verður SeqScan. Og hvað væri tilgangurinn ef áætlanir okkar færu ekki saman?

En hér komumst við að þeirri niðurstöðu að í raun er áætlunin í Postgres ekki háð tiltekinni stærð sem tilgreind er í Shared Buffer í áætluninni, það fer eftir effect_cache_size.

Effective_cache_size er áætlað magn skyndiminni sem er í boði fyrir okkur, þ.e. summan af Buffer Cache og skyndiminni skráarkerfisins. Þetta er stillt af config. Og þessu minni er ekki úthlutað.

Og vegna þessarar breytu getum við platað Postgres og sagt að við höfum í raun mikið af gögnum tiltæk, jafnvel þótt við höfum ekki þessi gögn. Og þannig munu áætlanirnar falla algjörlega saman við framleiðslu.

En þetta getur haft áhrif á tímasetninguna. Og við fínstillum fyrirspurnir með tímasetningu, en það er mikilvægt að tímasetning fari eftir mörgum þáttum:

• Það fer eftir því álagi sem nú er á framleiðslu.

• Það fer eftir eiginleikum vélarinnar sjálfrar.

Og þetta er óbein færibreyta, en í raun getum við fínstillt nákvæmlega eftir því magni gagna sem þessi fyrirspurn mun lesa til að fá niðurstöðuna.

Og ef þú vilt að tímasetningin sé nálægt því sem við munum sjá í framleiðslu, þá þurfum við að taka svipaðan vélbúnað og, hugsanlega, jafnvel meira svo að öll klónin passi. En þetta er málamiðlun, þ.e. þú munt fá sömu áætlanir, þú munt sjá hversu mikið af gögnum tiltekin fyrirspurn mun lesa og þú munt geta ályktað hvort þessi fyrirspurn sé góð (eða flutningur) eða slæm, það þarf samt að fínstilla hana .

Við skulum skoða hvernig Joe er sérstaklega fínstillt.

Við skulum taka beiðni frá alvöru kerfi. Í þessu tilviki er gagnagrunnurinn 1 terabæt. Og við viljum telja fjölda ferskra pósta sem höfðu meira en 10 líkar.

Við erum að skrifa skilaboð til rásarinnar, klóni hefur verið dreift fyrir okkur. Og við munum sjá að slík beiðni mun klárast á 2,5 mínútum. Þetta er það fyrsta sem við tökum eftir.

B Joe mun sýna þér sjálfvirkar ráðleggingar byggðar á áætluninni og mælingum.

Við munum sjá að fyrirspurnin vinnur of mikið af gögnum til að fá tiltölulega fáan fjölda raða. Og einhvers konar sérhæfða vísitölu er þörf, þar sem við tókum eftir því að það eru of margar síaðar línur í fyrirspurninni.

Við skulum skoða nánar hvað gerðist. Reyndar sjáum við að við höfum lesið næstum eitt og hálft gígabæta af gögnum úr skyndiminni skráarinnar eða jafnvel af disknum. Og þetta er ekki gott, því við fengum aðeins 142 línur.

Og, það virðist, við erum með vísitöluskönnun hér og hefðum átt að ganga fljótt, en þar sem við síuðum út of margar línur (við þurftum að telja þær), tókst beiðnin hægt og rólega.

Og þetta gerðist í áætluninni vegna þess að skilyrðin í fyrirspurninni og skilyrðin í vísitölunni passa að hluta ekki saman.

Við skulum reyna að gera vísitöluna nákvæmari og sjá hvernig framkvæmd fyrirspurnarinnar breytist eftir það.

Stofnun vísitölunnar tók nokkuð langan tíma, en nú skoðum við fyrirspurnina og sjáum að tíminn í stað 2,5 mínútna er aðeins 156 millisekúndur, sem er nógu gott. Og við lesum aðeins 6 megabæti af gögnum.

Og nú notum við aðeins vísitöluskönnun.

Önnur mikilvæg saga er sú að við viljum kynna áætlunina á einhvern skiljanlegri hátt. Við höfum innleitt sjónmynd með því að nota logagrafík.

Þetta er önnur beiðni, ákafari. Og við smíðum logagraff samkvæmt tveimur breytum: þetta er magn gagna sem tiltekinn hnút taldi í áætluninni og tímasetningunni, þ.e. framkvæmdartíma hnútsins.

Hér getum við borið saman tiltekna hnúta sín á milli. Og það verður ljóst hver þeirra tekur meira eða minna, sem er venjulega erfitt að gera í öðrum flutningsaðferðum.

Auðvitað vita allir explain.depesz.com. Góður eiginleiki við þessa sjónmynd er að við vistum textaáætlunina og setjum líka nokkrar grunnbreytur í töflu svo við getum flokkað.

Og forritarar sem hafa ekki enn kafað ofan í þetta efni nota líka explain.depesz.com, því það er auðveldara fyrir þá að finna út hvaða mælikvarðar eru mikilvægir og hverjir ekki.

Það er ný nálgun í sjónrænum aðferðum - þetta er explain.dalibo.com. Þeir gera trésjónmynd, en það er mjög erfitt að bera hnúta saman. Hér getur þú skilið uppbygginguna vel, en ef það er stór beiðni, þá þarftu að fletta fram og til baka, en einnig valmöguleika.

samvinnu

Og eins og ég sagði, Slack gefur okkur tækifæri til samstarfs. Til dæmis, ef við rekumst á flókna fyrirspurn sem ekki er ljóst hvernig á að hagræða, getum við skýrt þetta mál með samstarfsfólki okkar í þræði í Slack.

Okkur sýnist að það sé mikilvægt að prófa á gögnum í fullri stærð. Til að gera þetta gerðum við Update Database Lab tólið, sem er fáanlegt í opnum hugbúnaði. Þú getur líka notað Joe bot. Þú getur tekið það strax og útfært það á þínum stað. Þar fást allir leiðsögumenn.

Það er líka mikilvægt að hafa í huga að lausnin sjálf er ekki byltingarkennd, því það er Delphix, heldur er hún fyrirtækjalausn. Það er alveg lokað, það er mjög dýrt. Við sérhæfum okkur sérstaklega í Postgres. Þetta eru allt opinn uppspretta vörur. Gakktu til liðs við okkur!

Þetta er þar sem ég enda. Þakka þér fyrir!

spurningar

Halló! Takk fyrir skýrsluna! Mjög áhugavert, sérstaklega fyrir mig, vegna þess að ég leysti svipað vandamál fyrir nokkru síðan. Og svo hef ég ýmsar spurningar. Vonandi næ ég að minnsta kosti hluta af því.

Ég velti því fyrir mér hvernig þú reiknar út staðinn fyrir þetta umhverfi? Tæknin þýðir að undir vissum kringumstæðum geta klónarnir þínir vaxið upp í hámarksstærð. Í grófum dráttum, ef þú ert með tíu terabæta gagnagrunn og 10 klóna, þá er auðvelt að líkja eftir aðstæðum þar sem hver klón vegur 10 einstök gögn. Hvernig reiknarðu út þennan stað, það er, þessi delta sem þú talaðir um, þar sem þessi klón munu lifa?

Góð spurning. Það er mikilvægt að fylgjast með tilteknum klónum hér. Og ef klón hefur einhverja of stóra breytingu, þá byrjar hann að stækka, þá getum við fyrst gefið notandanum viðvörun um þetta, eða strax stöðvað þennan klón svo að við lendum ekki í bilunarástandi.

Já, ég er með hreiðraða spurningu. Það er, hvernig tryggir þú líftíma þessara eininga? Við höfum þetta vandamál og alveg sérstaka sögu. Hvernig gerist þetta?

Það er einhver ttl fyrir hvern klón. Í grundvallaratriðum höfum við fastan ttl.

Hvað, ef ekki leyndarmál?

1 klukkustund, þ.e. aðgerðalaus - 1 klukkustund. Ef það er ekki notað, þá skellum við það. En það kemur ekkert á óvart hér, þar sem við getum hækkað klónið á nokkrum sekúndum. Og ef þú þarft það aftur, vinsamlegast.

Ég hef líka áhuga á vali á tækni, vegna þess að við notum til dæmis nokkrar aðferðir samhliða af einni eða annarri ástæðu. Af hverju ZFS? Af hverju notaðirðu ekki LVM? Þú nefndir að það væru vandamál með LVM. Hver voru vandamálin? Að mínu mati er besti kosturinn með geymslu, hvað varðar frammistöðu.

Hvert er helsta vandamálið með ZFS? Sú staðreynd að þú verður að keyra á sama vélinni, þ.e.a.s. öll tilvik munu búa innan sama stýrikerfisins. Og ef um geymslu er að ræða geturðu tengt mismunandi búnað. Og flöskuhálsinn er aðeins þær blokkir sem eru á geymslukerfinu. Og spurningin um val á tækni er áhugaverð. Af hverju ekki LVM?

Nánar tiltekið getum við rætt LVM á fundinum. Um geymslu - það er bara dýrt. Við getum innleitt ZFS kerfið hvar sem er. Þú getur sett það á vélina þína. Þú getur einfaldlega halað niður geymslunni og dreift henni. ZFS er uppsett nánast alls staðar ef við erum að tala um Linux. Það er, við fáum mjög sveigjanlega lausn. Og ZFS sjálft gefur mikið út úr kassanum. Þú getur hlaðið upp eins miklum gögnum og þú vilt, tengt fjölda diska, það eru skyndimyndir. Og eins og ég sagði, það er auðvelt að stjórna því. Það er, það virðist mjög notalegt í notkun. Hann er prófaður, hann er margra ára. Hann á mjög stórt samfélag sem er að stækka. ZFS er mjög áreiðanleg lausn.

Nikolai Samokhvalov: Má ég tjá mig frekar? Ég heiti Nikolay, við vinnum saman með Anatoly. Ég er sammála því að geymsla er frábær. Og sumir viðskiptavina okkar eru með Pure Storage o.fl.

Anatoly tók réttilega fram að við einbeitum okkur að mát. Og í framtíðinni geturðu útfært eitt viðmót - tekið skyndimynd, búið til klón, eyðilagt klóninn. Þetta er allt auðvelt. Og geymsla er flott, ef svo er.

En ZFS er í boði fyrir alla. DelPhix er nú þegar nóg, þeir eru með 300 viðskiptavini. Þar af er Fortune 100 með 50 viðskiptavini, þ.e.a.s. þeir eru ætlaðir NASA o.s.frv. Það er kominn tími til að allir fái þessa tækni. Og þess vegna erum við með opinn uppspretta kjarna. Við erum með tengihluta sem er ekki opinn uppspretta. Þetta er vettvangurinn sem við munum sýna. En við viljum að það sé aðgengilegt öllum. Við viljum gera byltingu þannig að allir prófunaraðilar hætti að giska á fartölvur. Við verðum að skrifa SELECT og sjáum strax að það er hægt. Hættu að bíða eftir að DBA segi þér frá því. Hér er aðalmarkmiðið. Og ég held að við munum öll koma að þessu. Og við gerum þetta fyrir alla að eiga. Þess vegna ZFS, vegna þess að það verður fáanlegt alls staðar. Þökk sé samfélaginu fyrir að leysa vandamál og fyrir að hafa opið leyfi o.s.frv.*

Kveðja! Takk fyrir skýrsluna! Ég heiti Maxim. Við höfum tekist á við sömu mál. Þeir ákváðu sjálfir. Hvernig deilir þú auðlindum á milli þessara klóna? Hver klón getur gert sitt á hverjum tíma: einn prófar eitt, annað annað, einhver býr til vísitölu, einhver er í þungu starfi. Og ef þú getur samt deilt með CPU, þá með IO, hvernig deilirðu? Þetta er fyrsta spurningin.

Og önnur spurningin snýst um mismun á áhorfendum. Segjum að ég sé með ZFS hérna og allt sé flott, en clientinn á prod er ekki með ZFS heldur ext4 til dæmis. Hvernig í þessu tilfelli?

Spurningarnar eru mjög góðar. Ég minntist aðeins á þetta vandamál með það að við deilum auðlindum. Og lausnin er þessi. Ímyndaðu þér að þú sért að prófa á sviðsetningu. Þú getur líka lent í slíkum aðstæðum á sama tíma að einhver gefur einn farm, einhver annar. Og fyrir vikið sérðu óskiljanlega mælikvarða. Jafnvel sama vandamál getur verið með framleiðslu. Þegar þú vilt athuga einhverja beiðni og sjá að það er einhver vandamál með það - það virkar hægt, þá var vandamálið í raun ekki í beiðninni, heldur í því að það er einhvers konar samhliða álag.

Og því er mikilvægt hér að einblína á hver áætlunin verður, hvaða skref við munum taka í áætluninni og hversu mikið af gögnum við munum safna fyrir þetta. Sú staðreynd að diskarnir okkar, til dæmis, verða hlaðnir með einhverju, það mun sérstaklega hafa áhrif á tímasetninguna. En við getum metið hversu hlaðin þessi beiðni er miðað við magn gagna. Það er ekki svo mikilvægt að á sama tíma verði einhvers konar aðför.

Ég er með tvær spurningar. Þetta er mjög flott stuff. Hafa komið upp tilvik þar sem framleiðslugögn eru mikilvæg, svo sem kreditkortanúmer? Er eitthvað tilbúið nú þegar eða er það sérstakt verkefni? Og önnur spurningin - er eitthvað svona fyrir MySQL?

Um gögnin. Við munum gera þoku þar til við gerum það. En ef þú sendir inn nákvæmlega Joe, ef þú veitir ekki hönnuðum aðgang, þá er enginn aðgangur að gögnunum. Hvers vegna? Vegna þess að Joe sýnir ekki gögn. Það sýnir aðeins mælikvarða, áætlanir og það er það. Þetta var viljandi gert, því þetta er ein af kröfum viðskiptavina okkar. Þeir vildu geta hagrætt án þess að veita öllum aðgang.

Um MySQL. Þetta kerfi er hægt að nota fyrir allt sem geymir ástand á disknum. Og þar sem við erum að gera Postgres, erum við nú að gera alla sjálfvirkni fyrir Postgres fyrst. Við viljum gera sjálfvirkan aðgang að gögnum úr öryggisafriti. Við erum að stilla Postgres rétt. Við vitum hvernig á að láta áætlanir passa osfrv.

En þar sem kerfið er stækkanlegt er einnig hægt að nota það fyrir MySQL. Og slík dæmi eru til. Yandex hefur svipaðan hlut, en þeir birta það hvergi. Þeir nota það inni í Yandex.Metrica. Og það er bara saga um MySQL. En tæknin er sú sama, ZFS.

Takk fyrir skýrsluna! Ég hef líka nokkrar spurningar. Þú nefndir að hægt sé að nota klónun til greiningar, til dæmis til að byggja upp viðbótarvísitölur þar. Geturðu sagt aðeins meira um hvernig það virkar?

Og ég mun strax spyrja seinni spurningarinnar um líkindi áhorfenda, líkt áformum. Áætlunin veltur einnig á tölfræðinni sem Postgres safnar. Hvernig leysir þú þetta vandamál?

Samkvæmt greiningunum eru engin sérstök tilvik, vegna þess að við höfum ekki notað það ennþá, en það er slíkt tækifæri. Ef við erum að tala um vísitölur, ímyndaðu þér þá að fyrirspurn sé að elta töflu með hundruð milljóna skráa og dálk sem er venjulega ekki verðtryggður í framleiðslu. Og við viljum reikna nokkur gögn þar. Ef þessi beiðni er send á prod, þá er möguleiki á að það verði einfalt á prod, því beiðnin verður afgreidd þar í eina mínútu.

Ok, búum til þunnan klón sem er ekki hræðilegt að stoppa í nokkrar mínútur. Og til að gera það þægilegra að lesa greiningar, munum við bæta við vísitölum fyrir þá dálka sem við höfum áhuga á gögnum í.

Vísitalan verður til í hvert sinn?

Þú getur gert það þannig að við snertum gögnin, gerum skyndimyndir, svo munum við endurheimta þessa skyndimynd og keyra nýjar beiðnir. Það er, þú getur gert það þannig að þú getur alið upp ný klón með vísitölum sem þegar hafa verið festar á.

Hvað varðar spurninguna um tölfræði, ef við endurheimtum úr öryggisafriti, ef við gerum afritun, þá verður tölfræði okkar nákvæmlega sú sama. Vegna þess að við höfum alla líkamlegu gagnaskipulagið, það er að segja, við munum koma með gögnin eins og þau eru með öllum tölfræðimælingum líka.

Hér er annað vandamál. Ef þú notar skýjalausn, þá eru aðeins rökrétt sorphaugar fáanlegir þar, vegna þess að Google, Amazon leyfa þér ekki að taka líkamlegt afrit. Það verður vandamál.

Takk fyrir skýrsluna. Það voru tvær góðar spurningar hér um MySQL og deilingu auðlinda. En í raun snýst þetta allt um þá staðreynd að þetta er ekki efni tiltekinna DBMS, heldur skráarkerfisins í heild. Og í samræmi við það ætti einnig að leysa vandamálin um deilingu auðlinda þaðan, ekki í lok þess að það sé Postgres, heldur í skráarkerfinu, á þjóninum, til dæmis.

Spurningin mín er aðeins öðruvísi. Það er nær marglaga gagnagrunninum, þar sem það eru nokkur lög. Til dæmis setjum við upp tíu terabæta mynduppfærslu, við erum að endurtaka. Og við notum þessa lausn sérstaklega fyrir gagnagrunna. Afritun er í gangi, gögn eru uppfærð. Hér starfa 100 starfsmenn samhliða, sem eru stöðugt að koma þessum mismunandi skotum af stað. Hvað skal gera? Hvernig á að ganga úr skugga um að það sé engin ágreiningur, að þeir hafi ræst einn og síðan breyttist skráarkerfið og þessar myndir fóru allar?

Þeir fara ekki vegna þess að þannig virkar ZFS. Við getum haldið sérstaklega í einum þræði skráarkerfisbreytingunum sem koma vegna afritunar. Og haltu klónunum sem forritarar nota á eldri útgáfum af gögnunum. Og það virkar hjá okkur, allt er í lagi með þetta.

Það kemur í ljós að uppfærslan mun eiga sér stað sem viðbótarlag og allar nýjar myndir fara nú þegar, byggt á þessu lagi, ekki satt?

Frá fyrri lögum sem voru frá fyrri afritunum.

Fyrri lögin munu detta af, en þau munu vísa til gamla lagsins, og munu þeir taka nýjar myndir úr síðasta lagi sem barst í uppfærslunni?

Almennt séð já.

Þar af leiðandi munum við hafa allt að fíkju af lögum. Og með tímanum þarf að þjappa þeim saman?

Já allt er rétt. Það er einhver gluggi. Við geymum vikulegar skyndimyndir. Það fer eftir því hvaða úrræði þú hefur. Ef þú hefur getu til að geyma mikið af gögnum geturðu geymt skyndimyndir í langan tíma. Þeir munu ekki hverfa af sjálfu sér. Það verður engin gagnaspilling. Ef skyndimyndirnar eru úreltar, eins og okkur sýnist, þ.e.a.s. það fer eftir stefnu í fyrirtækinu, þá getum við einfaldlega eytt þeim og losað um pláss.

Halló, takk fyrir skýrsluna! Spurning um Jóa. Þú sagðir að viðskiptavinurinn vildi ekki veita öllum aðgang að gögnunum. Strangt til tekið, ef einstaklingur er með niðurstöðu Explain Analyze, þá getur hann kíkt á gögnin.

Það er svona. Til dæmis getum við skrifað: "SELECT FROM WHERE email = to that". Það er, við munum ekki sjá gögnin sjálf, en við getum séð nokkur óbein merki. Þetta verður að skilja. En á hinn bóginn er þetta allt til staðar. Við erum með log endurskoðun, við höfum stjórn á öðrum samstarfsmönnum sem sjá líka hvað þróunaraðilar eru að gera. Og ef einhver reynir að gera þetta, þá mun öryggisþjónustan koma til hans og vinna að þessu máli.

Góðan daginn Takk fyrir skýrsluna! Ég er með stutta spurningu. Ef fyrirtækið notar ekki Slack, er þá einhver binding við það núna, eða er mögulegt fyrir forritara að dreifa tilvikum til að tengja prófunarforrit við gagnagrunnana?

Núna er hlekkur á Slack, þ.e.a.s. það er enginn annar boðberi, en ég vil endilega gera stuðning fyrir aðra boðbera líka. Hvað er hægt að gera? Þú getur sett inn DB Lab án Joe, farið með hjálp REST API eða með hjálp vettvangsins okkar og búið til klón og tengst PSQL. En þetta er hægt að gera ef þú ert tilbúinn að veita forriturum þínum aðgang að gögnunum, því það verður ekki lengur neinn skjár.

Ég þarf ekki þetta lag, en ég þarf svona tækifæri.

Þá já, það er hægt.

Heimild: www.habr.com