Hoe begrypt in backend-ûntwikkelder dat in SQL-query goed sil wurkje op in "prod"? Yn grutte of rap groeiende bedriuwen hat net elkenien tagong ta it "produkt". En mei tagong kinne net alle oanfragen sûnder pine wurde kontrolearre, en it meitsjen fan in kopy fan 'e databank duorret faak oeren. Om dizze problemen op te lossen, hawwe wy in keunstmjittige DBA makke - Joe. It is al mei súkses ymplementearre yn ferskate bedriuwen en helpt mear as in tsiental ûntwikkelders.
Video:
Hoi allegearre! Myn namme is Anatoly Stansler. Ik wurkje foar in bedriuw . Wy sette ús yn foar it rapperjen fan it ûntwikkelingsproses troch de fertragingen te ferwiderjen dy't ferbûn binne mei it wurk fan Postgres fan ûntwikkelders, DBA's en QAs.
Wy hawwe geweldige kliïnten en hjoed sil in diel fan it rapport wijd wurde oan gefallen dy't wy moete hawwe by it wurkjen mei har. Ik sil prate oer hoe't wy har holpen hawwe om frij serieuze problemen op te lossen.
As wy komplekse migraasjes mei hege lading ûntwikkelje en dogge, stelle wy ússels de fraach: "Sil dizze migraasje fuortgean?". Wy brûke resinsje, wy brûke de kennis fan mear betûfte kollega, DBA saakkundigen. En se kinne sizze oft it sil fleane of net.
Mar miskien soe it better wêze as wy it sels op folsleine grutte kopyen kinne testen. En hjoed sille wy gewoan prate oer hokker oanpak foar testen no binne en hoe't it better kin wurde dien en mei hokker ark. Wy sille ek prate oer de foar- en neidielen fan sokke oanpak, en wat wy hjir kinne reparearje.
Wa hat oait yndeksen direkt op prod makke of wizigingen makke? Hiel wat. En foar wa hat dit laat ta it feit dat gegevens ferlern gienen of der wiene downtime? Dan kenne jo dizze pine. Tankewol dat d'r backups binne.
De earste oanpak is testen yn prod. Of, as in ûntwikkelder op in lokale masine sit, hat hy testgegevens, d'r is in soarte fan beheinde seleksje. En wy rôlje út nei prod, en wy krije dizze situaasje.
It docht sear, it is djoer. It is wierskynlik it bêste net te dwaan.
En wat is de bêste manier om it te dwaan?
Litte wy staging nimme en dêr wat diel fan prod selektearje. Of yn it bêste gefal, litte wy in echte prod nimme, alle gegevens. En nei't wy it lokaal ûntwikkele hawwe, sille wy ek kontrolearje op staging.
Dit sil tastean ús te ferwiderjen guon fan 'e flaters, d.w.s. foarkomme dat se op prod.
Wat binne de problemen?
- It probleem is dat wy dizze staging diele mei kollega's. En hiel faak bart it dat jo in soarte fan feroaring meitsje, bam - en d'r binne gjin gegevens, it wurk is yn 'e drain. Staging wie multi-terabyte. En jo moatte lang wachtsje oant it wer omheech komt. En wy beslute om it moarn te finalisearjen. Dat is it, wy hawwe in ûntwikkeling.
- En fansels hawwe wy in protte kollega's dy't dêr wurkje, in protte teams. En it moat mei de hân dien wurde. En dit is ûngemaklik.
En it is it wurdich te sizzen dat wy mar ien besykjen hawwe, ien skot, as wy wat wizigingen yn 'e databank wolle meitsje, de gegevens oanreitsje, de struktuer feroarje. En as der wat mis gie, as der in flater wie yn 'e migraasje, dan sille wy net gau weromdraaie.
Dit is better as de foarige oanpak, mar der is noch in hege kâns dat in soarte fan flater sil gean nei produksje.
Wat foarkomt ús om elke ûntwikkelder in testbank te jaan, in kopy op folsleine grutte? Ik tink dat it dúdlik is wat der yn 'e wei stiet.
Wa hat in databank grutter dan in terabyte? Mear as de helte fan 'e keamer.
En it is dúdlik dat it hâlden fan masines foar elke ûntwikkelder, as d'r sa'n grutte produksje is, heul djoer is, en boppedat duorret it lang.
We hawwe kliïnten dy't hawwe realisearre dat it is hiel wichtich om te testen alle feroarings op folsleine grutte kopyen, mar harren databank is minder as in terabyte, en der binne gjin middels foar in hâlden in test bankje foar eltse ûntwikkelder. Dêrom moatte se de dumps lokaal downloade nei har masine en op dizze manier testen. It duorret in protte tiid.
Sels as jo it binnen de ynfrastruktuer dogge, dan is it downloaden fan ien terabyte oan gegevens per oere al heul goed. Mar se brûke logyske dumps, se downloade lokaal út 'e wolk. Foar harren is de snelheid sa'n 200 gigabyte per oere. En it duorret noch tiid om fan 'e logyske dump ôf te draaien, de yndeksen op te rôljen, ensfh.
Mar se brûke dizze oanpak om't it har mooglik makket om de prod betrouber te hâlden.
Wat kinne wy hjir dwaan? Litte wy testbanken goedkeap meitsje en elke ûntwikkelder har eigen testbank jaan.
En dit is mooglik.
En yn dizze oanpak, as wy tinne klonen meitsje foar elke ûntwikkelder, kinne wy it diele op ien masine. As jo bygelyks in 10TB-database hawwe en dy wolle jaan oan 10 ûntwikkelders, hoege jo gjin XNUMX x XNUMXTB-databases te hawwen. Jo hawwe mar ien masine nedich om tinne isolearre kopyen te meitsjen foar elke ûntwikkelder mei ien masine. Hoe't it wurket sil ik efkes letter fertelle.
Echt foarbyld:
-
DB - 4,5 terabytes.
-
Wy kinne ûnôfhinklike kopyen krije yn 30 sekonden.
Jo hoege net te wachtsjen op in test stand en hinget ôf fan hoe grut it is. Jo kinne it yn sekonden krije. It sil folslein isolearre omjouwings wêze, mar dy't gegevens ûnderinoar diele.
Dit is geweldich. Hjir hawwe wy it oer magy en in parallel universum.
Yn ús gefal wurket dit mei it OpenZFS-systeem.
OpenZFS is in kopy-op-skriuwe-bestânsysteem dat snapshots en klonen út it fak stipet. It is betrouber en skalberber. Se is heul maklik te behearjen. It kin letterlik yn twa teams ynset wurde.
D'r binne oare opsjes:
-
lvm,
-
Opslach (bygelyks Pure Storage).
It Database Lab dêr't ik it oer ha is modulêr. Kin wurde útfierd mei help fan dizze opsjes. Mar foar no hawwe wy rjochte op OpenZFS, om't d'r spesifyk problemen wiene mei LVM.
Hoe't it wurket? Ynstee fan it oerskriuwen fan de gegevens elke kear as wy it feroarje, bewarje wy it troch gewoan te markearjen dat dizze nije gegevens fan in nij punt yn 'e tiid binne, in nije momintopname.
En yn 'e takomst, as wy werom wolle of wy wolle in nije kloon meitsje fan wat âldere ferzje, sizze wy gewoan: "OK, jou ús dizze blokken fan gegevens dy't sa markearre binne."
En dizze brûker sil wurkje mei sa'n dataset. Hy sil se stadichoan feroarje, syn eigen snapshots meitsje.
En wy sille branch. Elke ûntwikkelder yn ús gefal sil de kâns hawwe om syn eigen kloon te hawwen dy't hy bewurket, en de gegevens dy't dield wurde wurde dield tusken elkenien.
Om sa'n systeem thús yn te setten, moatte jo twa problemen oplosse:
-
De earste is de boarne fan 'e gegevens, wêr't jo it sille nimme. Jo kinne replikaasje ynstelle mei produksje. Jo kinne de backups al brûke dy't jo hawwe ynsteld, hoopje ik. WAL-E, WAL-G of Barman. En sels as jo in soarte fan Cloud-oplossing brûke lykas RDS of Cloud SQL, dan kinne jo logyske dumps brûke. Mar wy riede jo noch oan om backups te brûken, om't jo mei dizze oanpak ek de fysike struktuer fan 'e bestannen behâlde, wêrtroch jo noch tichter by de metriken kinne wêze dy't jo yn' e produksje soene sjen om dy problemen te fangen dy't besteane.
-
De twadde is wêr't jo it Database Lab wolle hostje. It kin Wolk wêze, it kin On-premise wêze. It is wichtich om hjir te sizzen dat ZFS datakompresje stipet. En it docht it hiel goed.
Stel jo foar dat foar elke sa'n kloon, ôfhinklik fan 'e operaasjes dy't wy dogge mei de basis, in soarte fan dev sil groeie. Dêrfoar sil dev ek romte nedich hawwe. Mar troch it feit dat wy in basis fan 4,5 terabytes namen, sil ZFS it komprimearje nei 3,5 terabytes. Dit kin ferskille ôfhinklik fan de ynstellings. En wy hawwe noch romte foar dev.
Sa'n systeem kin brûkt wurde foar ferskate gefallen.
-
Dit binne ûntwikkelders, DBA's foar query-validaasje, foar optimalisaasje.
-
Dit kin brûkt wurde yn QA-testen om in bepaalde migraasje te testen foardat wy it útrolje nei prod. En wy kinne ek spesjale omjouwings foar QA ferheegje mei echte gegevens, wêr't se nije funksjonaliteit kinne testen. En it sil nimme sekonden ynstee fan wachtsjen oeren, en miskien dagen yn guon oare gefallen dêr't tinne kopyen wurde net brûkt.
-
En in oare saak. As it bedriuw gjin analytysk systeem hat ynsteld, dan kinne wy in tinne kloon fan 'e produktbasis isolearje en it jaan oan lange fragen as spesjale yndeksen dy't kinne wurde brûkt yn analytyk.
Mei dizze oanpak:
-
Lege kâns op flaters op 'e "prod", om't wy alle wizigingen testen op folsleine gegevens.
-
Wy hawwe in kultuer fan testen, want no hoege jo net oeren te wachtsjen op jo eigen stand.
-
En d'r is gjin barriêre, gjin wachtsjen tusken testen. Jo kinne eins gean en kontrolearje. En it sil op dizze manier better wêze as wy de ûntwikkeling fersnelle.
-
Der sil minder refactoring wêze. Minder bugs sille einigje yn prod. Wy sille se letter minder refaktorearje.
-
Wy kinne ûnomkearbere feroarings omkeare. Dit is net de standert oanpak.
- Dit is foardielich om't wy de boarnen fan 'e testbanken diele.
Al goed, mar wat koe noch fersneld wurde?
Mei tank oan sa'n systeem kinne wy de drompel foar it ynfieren fan sokke testen gâns ferminderje.
No is d'r in vicieuze sirkel wêr't in ûntwikkelder in ekspert moat wurde om tagong te krijen ta echte gegevens op folsleine grutte. Hy moat fertroud wurde mei sa'n tagong.
Mar hoe groeie as it der net is. Mar wat as jo mar in heul lytse set testgegevens foar jo beskikber hawwe? Dan krije jo gjin echte ûnderfining.
Hoe te krijen út dizze sirkel? As de earste ynterface, handich foar ûntwikkelders fan elk nivo, hawwe wy de Slack-bot keazen. Mar it kin elke oare ynterface wêze.
Wat lit it jo dwaan? Jo kinne in spesifike fraach nimme en it stjoere nei in spesjaal kanaal foar de databank. Wy sille automatysk in tinne kloon yn sekonden ynsette. Litte wy dit fersyk útfiere. Wy sammelje metriken en oanbefellings. Litte wy in fisualisaasje sjen litte. En dan sil dizze kloon bliuwe sadat dizze query op ien of oare manier optimisearre wurde kin, yndeksen tafoegje, ensfh.
En ek Slack jout ús kânsen foar gearwurking bûten it fak. Sûnt dit is gewoan in kanaal, kinne jo begjinne te besprekken dit fersyk rjochts dêr yn 'e tried foar sa'n fersyk, ping jo kollega's, DBA's dy't binnen it bedriuw.
Mar d'r binne fansels problemen. Om't dit de echte wrâld is, en wy brûke in tsjinner dy't in protte klonen tagelyk host, moatte wy de hoemannichte ûnthâld en CPU-krêft dy't beskikber binne foar de klonen komprimearje.
Mar om dizze tests oannimlik te wêzen, moatte jo dit probleem op ien of oare manier oplosse.
It is dúdlik dat it wichtige punt deselde gegevens is. Mar wy hawwe it al. En wy wolle deselde konfiguraasje berikke. En wy kinne sa'n hast identike konfiguraasje jaan.
It soe cool wêze om deselde hardware te hawwen as yn produksje, mar it kin ferskille.
Lit ús ûnthâlde hoe't Postgres wurket mei ûnthâld. Wy hawwe twa caches. Ien fan it bestânsysteem en ien native Postgres, dus Shared Buffer Cache.
It is wichtich om te notearjen dat de Shared Buffer Cache wurdt tawiisd as Postgres begjint, ôfhinklik fan hokker grutte jo oantsjutte yn 'e konfiguraasje.
En de twadde cache brûkt alle beskikbere romte.
En as wy meitsje ferskate klonen op ien masine, docht bliken dat wy stadichoan folje it ûnthâld. En op in goede manier is Shared Buffer Cache 25% fan it totale bedrach fan ûnthâld dat is beskikber op 'e masine.
En it docht bliken dat as wy dizze parameter net feroarje, dan kinne wy mar 4 eksimplaren op ien masine útfiere, dus 4 fan al sokke tinne klonen. En dit is fansels min, want dêr wolle wy folle mear fan ha.
Mar oan 'e oare kant wurdt Buffer Cache brûkt om queries foar yndeksen út te fieren, dat is, it plan hinget ôf fan hoe grut ús caches binne. En as wy dizze parameter gewoan nimme en it ferminderje, dan kinne ús plannen in protte feroarje.
As wy bygelyks in grutte cache hawwe op prod, dan sil Postgres leaver in yndeks brûke. En sa net, dan sil d'r SeqScan wêze. En wat soe it punt wêze as ús plannen net oerienkomme?
Mar hjir komme wy ta de konklúzje dat yn feite it plan yn Postgres net ôfhinklik is fan 'e spesifike grutte oantsjutte yn' e Shared Buffer yn it plan, it hinget ôf fan 'e effective_cache_size.
Effective_cache_size is it rûsde bedrach fan cache dat foar ús beskikber is, dus de som fan Buffer Cache en triemsysteemcache. Dit wurdt ynsteld troch de konfiguraasje. En dit ûnthâld wurdt net tawiisd.
En troch dizze parameter, kinne wy in soarte fan trick Postgres, sizzende dat wy eins hawwe in soad gegevens beskikber, sels as wy hawwe net dizze gegevens. En dêrmei sille de plannen folslein gearfalle mei de produksje.
Mar dit kin ynfloed op de timing. En wy optimalisearje fragen troch timing, mar it is wichtich dat timing hinget fan in protte faktoaren:
-
It hinget ôf fan 'e lading dy't op it stuit op prod is.
-
It hinget ôf fan 'e skaaimerken fan' e masine sels.
En dit is in yndirekte parameter, mar feitlik kinne wy krekt optimalisearje troch de hoemannichte gegevens dy't dizze query sil lêze om it resultaat te krijen.
En as jo wolle dat de timing tichtby is wat wy sille sjen yn prod, dan moatte wy de meast ferlykbere hardware nimme en, mooglik noch mear, sadat alle klonen passe. Mar dit is in kompromis, d.w.s. jo sille deselde plannen krije, jo sille sjen hoefolle gegevens in bepaalde query sil lêze en jo kinne konkludearje oft dizze query goed (of migraasje) of min is, it moat noch optimisearre wurde .
Litte wy ris sjen hoe't Joe spesifyk is optimalisearre.
Litte wy in fersyk nimme fan in echt systeem. Yn dit gefal is de databank 1 terabyte. En wy wolle it oantal nije berjochten telle dat mear as 10 likes hie.
Wy skriuwe in berjocht nei it kanaal, in kloon is foar ús ynset. En wy sille sjen dat sa'n fersyk yn 2,5 minuten sil foltôgje. Dit is it earste wat wy opmerke.
B Joe sil jo automatyske oanbefellings sjen litte basearre op it plan en metriken.
Wy sille sjen dat de query tefolle gegevens ferwurket om in relatyf lyts oantal rigen te krijen. En in soarte fan spesjalisearre yndeks is nedich, om't wy opfallen dat d'r tefolle filtere rigen binne yn 'e query.
Litte wy in tichterby sjen wat der bard is. Yndie, wy sjogge dat wy hawwe lêzen hast ien en in heale gigabyte oan gegevens út de triem cache of sels fan skiif. En dit is net goed, want wy krigen mar 142 rigels.
En, it liket derop, wy hawwe hjir in yndeksscan en hiene gau útwurke moatten, mar om't wy tefolle rigels filtere (wy moasten se telle), wurke de fraach stadichoan út.
En dit barde yn it plan fanwege it feit dat de betingsten yn 'e query en de betingsten yn' e yndeks foar in part net oerienkomme.
Litte wy besykje de yndeks krekter te meitsjen en te sjen hoe't de query-útfiering dêrnei feroaret.
De oprjochting fan 'e yndeks hat nochal lang duorre, mar no kontrolearje wy de query en sjogge dat de tiid ynstee fan 2,5 minuten mar 156 millisekonden is, wat goed genôch is. En wy lêze mar 6 megabytes oan gegevens.
En no brûke wy allinich yndeksscan.
In oar wichtich ferhaal is dat wy it plan op wat mear begryplike wize presintearje wolle. Wy hawwe fisualisaasje ymplementearre mei Flame Graphs.
Dit is in oar fersyk, yntinsiver. En wy bouwe Flame Grafiken neffens twa parameters: dit is de hoemannichte gegevens dat in bepaald knooppunt teld yn it plan en timing, dus de útfiering tiid fan de knooppunt.
Hjir kinne wy spesifike knopen mei elkoar fergelykje. En it sil wêze dúdlik hokker fan harren nimt mear of minder, dat is meastal dreech te dwaan yn oare rendering metoaden.
Fansels wit elkenien explain.depesz.com. In goede eigenskip fan dizze fisualisaasje is dat wy it tekstplan bewarje en ek guon basisparameters yn in tabel sette, sadat wy sortearje kinne.
En ûntwikkelders dy't noch net yn dit ûnderwerp ferdjippe hawwe, brûke ek explain.depesz.com, om't it makliker is foar har om út te finen hokker metriken wichtich binne en hokker net.
D'r is in nije oanpak foar fisualisaasje - dit is explain.dalibo.com. Se dogge in beamfisualisaasje, mar it is heul lestich om knopen mei elkoar te fergelykjen. Hjir kinne jo de struktuer goed begripe, lykwols, as der in grut fersyk is, dan moatte jo hinne en wer rôlje, mar ek in opsje.
kollaboraasje
En, lykas ik sei, Slack jout ús de kâns om gear te wurkjen. Bygelyks, as wy in komplekse query tsjinkomme dy't net dúdlik is hoe te optimalisearjen, kinne wy dit probleem ferdúdlikje mei ús kollega's yn in thread yn Slack.
It liket ús dat it wichtich is om te testen op gegevens op folsleine grutte. Om dit te dwaan, hawwe wy it Update Database Lab-ark makke, dat beskikber is yn iepen boarne. Jo kinne ek de Joe bot brûke. Jo kinne it no direkt nimme en it op jo plak implementearje. Alle gidsen binne beskikber dêr.
It is ek wichtich om te notearjen dat de oplossing sels net revolúsjonêr is, om't d'r Delphix is, mar it is in bedriuwsoplossing. It is hielendal sluten, it is hiel djoer. Wy spesjalisearje spesifyk yn Postgres. Dit binne allegear iepen boarne produkten. Kom by ûs!
Dit is wêr't ik einigje. Dankewol!
Jo fragen
Hallo! Tank foar it ferslach! Hiel nijsgjirrich, foaral foar my, om't ik in skoft lyn itselde probleem oplost. En dus haw ik in oantal fragen. Hooplik krij ik der op syn minst in part fan.
Ik freegje my ôf hoe't jo it plak foar dizze omjouwing berekkenje? De technology betsjut dat jo klonen ûnder bepaalde omstannichheden kinne groeie nei de maksimale grutte. Rûchwei sprutsen, as jo in database fan tsien terabyte en 10 klonen hawwe, dan is it maklik om in situaasje te simulearjen wêr't elke kloon 10 unike gegevens weaget. Hoe berekkenje jo dit plak, dat is de delta dêr't jo oer sprieken, wêryn dizze klonen libje sille?
Goeie fraach. It is wichtich om hjir spesifike klonen by te hâlden. En as in kloon wat te grutte feroaringen hat, begjint it te groeien, dan kinne wy earst in warskôging oan de brûker hjiroer jaan, of dizze kloon daliks stopje, sadat wy gjin mislearre situaasje hawwe.
Ja, ik haw in nêst fraach. Dat is, hoe garandearje jo de libbenssyklus fan dizze modules? Wy hawwe dit probleem en in hiel apart ferhaal. Hoe komt dit?
D'r is wat ttl foar elke kloon. Yn prinsipe hawwe wy in fêste ttl.
Wat, as net in geheim?
1 oere, dus idle - 1 oere. As it net brûkt wurdt, dan slaan wy it. Mar d'r is hjir gjin ferrassing, om't wy de kloon yn sekonden kinne ferheegje. En as jo it nochris nedich hawwe, dan asjebleaft.
Ik bin ek ynteressearre yn 'e kar fan technologyen, om't wy bygelyks ferskate metoaden parallel brûke om ien of oare reden. Wêrom ZFS? Wêrom hawwe jo LVM net brûkt? Jo hawwe neamd dat der wiene problemen mei LVM. Wat wiene de problemen? Yn myn miening is de meast optimale opsje mei opslach, yn termen fan prestaasjes.
Wat is it wichtichste probleem mei ZFS? It feit dat jo op deselde host moatte rinne, d.w.s. alle eksimplaren sille binnen itselde OS libje. En yn it gefal fan opslach kinne jo ferskate apparatuer ferbine. En de knelpunt is allinich dy blokken dy't op it opslachsysteem binne. En de fraach fan 'e kar fan technologyen is ynteressant. Wêrom net LVM?
Spesifyk kinne wy LVM besprekke by meetup. Oer opslach - it is gewoan djoer. Wy kinne it ZFS-systeem oeral ymplementearje. Jo kinne it ynsette op jo masine. Jo kinne it repository gewoan downloade en it ynsette. ZFS is hast oeral ynstalleare as wy it oer Linux prate. Dat is, wy krije in tige fleksibele oplossing. En ZFS sels jout in protte út 'e doaze. Jo kinne safolle gegevens uploade as jo wolle, in grut oantal skiven ferbine, d'r binne snapshots. En, lykas ik sei, it is maklik te administrearjen. Dat is, it liket hiel noflik om te brûken. Hy wurdt hifke, hy is in protte jierren âld. Hy hat in heul grutte mienskip dy't groeit. ZFS is in heul betroubere oplossing.
Nikolai Samokhvalov: Mei ik fierder kommentaar? Myn namme is Nikolay, wy wurkje gear mei Anatoly. Ik iens dat opslach is great. En guon fan ús klanten hawwe Pure Storage ensfh.
Anatoly konstatearre korrekt dat wy rjochte binne op modulariteit. En yn 'e takomst kinne jo ien ynterface ymplementearje - in momintopname nimme, in kloon meitsje, de kloon ferneatigje. It is allegear maklik. En opslach is cool, as it is.
Mar ZFS is beskikber foar elkenien. DelPhix is al genôch, se hawwe 300 kliïnten. Fan dizze hat fortune 100 50 kliïnten, d.w.s. se binne rjochte op NASA, ensfh. It is tiid foar elkenien om dizze technology te krijen. En dêrom hawwe wy in iepen boarne Core. Wy hawwe in ynterface-diel dat net iepen boarne is. Dit is it platfoarm dat wy sille sjen litte. Mar wy wolle dat it foar elkenien tagonklik is. Wy wolle in revolúsje meitsje sadat alle testers ophâlde mei rieden op laptops. Wy moatte SELECT skriuwe en fuortendaliks sjogge dat it stadich is. Stopje mei wachtsjen op 'e DBA om jo deroer te fertellen. Hjir is it haaddoel. En ik tink dat wy hjir allegear komme sille. En wy meitsje dit ding foar elkenien om te hawwen. Dêrom ZFS, omdat it sil wêze beskikber oeral. Mei tank oan de mienskip foar it oplossen fan problemen en foar it hawwen fan in iepen boarne lisinsje, ensfh.*
Groetnis! Tank foar it ferslach! Myn namme is Maxim. Wy hawwe mei deselde problemen behannele. Se besletten op har eigen. Hoe diele jo boarnen tusken dizze klonen? Elke kloon kin op elts momint syn eigen ding dwaan: ien test it iene, in oar in oar, ien bout in yndeks, ien hat in swiere baan. En as jo noch kinne dielen troch CPU, dan troch IO, hoe ferdiele jo? Dit is de earste fraach.
En de twadde fraach giet oer de ûngelikens fan de tribunes. Litte wy sizze dat ik hjir ZFS haw en alles is cool, mar de kliïnt op prod hat gjin ZFS, mar ext4, bygelyks. Hoe yn dit gefal?
De fragen binne tige goed. Ik neamde dit probleem in bytsje mei it feit dat wy diele middels. En de oplossing is dit. Stel jo foar dat jo testen op staging. Jo kinne ek sa'n situaasje tagelyk hawwe dat ien ien lêst jout, in oar. En as gefolch sjogge jo ûnbegryplike metriken. Sels itselde probleem kin wêze mei prod. As jo wat fersyk kontrolearje wolle en sjen dat d'r wat probleem mei is - it wurket stadich, dan wie it probleem yn feite net yn it fersyk, mar yn it feit dat d'r in soarte fan parallelle lading is.
En dêrom is it hjir wichtich om te rjochtsjen op wat it plan sil wêze, hokker stappen wy sille nimme yn it plan en hoefolle gegevens wy sille sammelje foar dit. It feit dat ús skiven, bygelyks, sille wurde laden mei wat, it sil spesifyk beynfloedzje de timing. Mar wy kinne skatte hoe laden dit fersyk is troch de hoemannichte gegevens. It is net sa wichtich dat der tagelyk in soarte fan eksekúsje komt.
Ik haw twa fragen. Dit is heul cool spul. Hawwe d'r gefallen west wêr't produksjegegevens kritysk binne, lykas kredytkaartnûmers? Is der al wat klear of is it in aparte taak? En de twadde fraach - is d'r sokssawat foar MySQL?
Oer de gegevens. Wy sille dwaan obfuscation oant wy dogge. Mar as jo Joe krekt ynsette, as jo gjin tagong jouwe oan ûntwikkelders, dan is d'r gjin tagong ta de gegevens. Wêrom? Om't Joe gjin gegevens toant. It toant allinich metriken, plannen en dat is it. Dit is mei opsetsin dien, want dit is ien fan de easken fan ús klant. Se woene optimisearje kinne sûnder elkenien tagong te jaan.
Oer MySQL. Dit systeem kin brûkt wurde foar alles dat steat opslaat op skiif. En om't wy Postgres dogge, dogge wy no earst alle automatisearring foar Postgres. Wy wolle automatisearje it krijen fan gegevens fan in reservekopy. Wy konfigurearje Postgres korrekt. Wy witte hoe't jo plannen oerienkomme, ensfh.
Mar om't it systeem útbreidber is, kin it ek brûkt wurde foar MySQL. En der binne sokke foarbylden. Yandex hat in ferlykber ding, mar se publisearje it net oeral. Se brûke it binnen Yandex.Metrica. En d'r is gewoan in ferhaal oer MySQL. Mar de technologyen binne itselde, ZFS.
Tank foar it ferslach! Ik haw ek in pear fragen. Jo hawwe neamd dat klonen brûkt wurde kin foar analytyk, bygelyks om dêr ekstra yndeksen te bouwen. Kinne jo wat mear fertelle oer hoe't it wurket?
En ik sil daliks de twadde fraach stelle oer de oerienkomst fan de tribunes, de oerienkomst fan de plannen. It plan hinget ek ôf fan 'e statistiken sammele troch Postgres. Hoe kinne jo dit probleem oplosse?
Neffens de analytics binne d'r gjin spesifike gefallen, om't wy it noch net brûkt hawwe, mar d'r is sa'n kâns. As wy it hawwe oer yndeksen, stel jo dan foar dat in query in tabel jaget mei hûnderten miljoenen records en in kolom dy't normaal net yn prod is yndeksearre. En wy wolle dêr wat gegevens berekkenje. As dit fersyk nei prod stjoerd wurdt, dan is der in mooglikheid dat it ienfâldich is op prod, om't it fersyk dêr in minút ferwurke wurdt.
Ok, litte wy in tinne kloon meitsje dy't net ferskriklik is om in pear minuten te stopjen. En om it nofliker te meitsjen om de analytiken te lêzen, sille wy yndeksen tafoegje foar dy kolommen wêryn wy ynteressearre binne yn gegevens.
De yndeks wurdt makke eltse kear?
Jo kinne it sa meitsje dat wy de gegevens oanreitsje, snapshots meitsje, dan sille wy weromhelje fan dizze snapshot en nije oanfragen stjoere. Dat is, jo kinne it sa meitsje dat jo nije klonen kinne ferheegje mei al oanbrochte yndeksen.
Wat de fraach oer statistiken oanbelanget, as wy weromsette fan in reservekopy, as wy replikaasje dogge, dan sille ús statistiken krekt itselde wêze. Om't wy de folsleine fysike gegevensstruktuer hawwe, dat is, wy sille de gegevens ek bringe sa't it is mei alle statistyske metriken.
Hjir is in oar probleem. As jo in wolkoplossing brûke, dan binne der allinich logyske dumps beskikber, om't Google, Amazon jo net tastean om in fysike kopy te nimmen. Der sil sa'n probleem wêze.
Tank foar it ferslach. D'r wiene hjir twa goede fragen oer MySQL en dielen fan boarnen. Mar yn feite komt it allegear del op it feit dat dit gjin ûnderwerp is fan spesifike DBMS, mar fan it bestânsysteem as gehiel. En dêrtroch moatte de problemen fan dielen fan boarnen ek fan dêrút oplost wurde, net oan it ein dat it Postgres is, mar yn it bestânsysteem, yn 'e server, bygelyks.
Myn fraach is in bytsje oars. It is tichter by de multi-layered databank, dêr't der binne ferskate lagen. Wy sette bygelyks in ôfbyldingsfernijing fan tsien terabyte yn, wy replikearje. En wy brûke dizze oplossing spesifyk foar databases. Replikaasje is oan 'e gong, gegevens wurde bywurke. D'r wurkje hjir parallel 100 meiwurkers, dy't konstant dizze ferskate shots lansearje. Wat te dwaan? Hoe kinne jo derfoar soargje dat d'r gjin konflikt is, dat se ien lansearre hawwe, en dan feroare it bestânsysteem, en dizze foto's gongen allegear?
Se sille net gean, want dat is hoe ZFS wurket. Wy kinne apart yn ien thread de wizigingen fan bestânsysteem hâlde dy't komme troch replikaasje. En hâld de klonen dy't ûntwikkelders brûke op âldere ferzjes fan 'e gegevens. En it wurket foar ús, hjir is alles yn oarder.
It docht bliken dat de fernijing sil plakfine as in ekstra laach, en alle nije foto sil gean al, basearre op dizze laach, rjochts?
Fan eardere lagen dy't fan eardere replikaasjes wiene.
De foarige lagen sille falle ôf, mar se sille ferwize nei de âlde laach, en sille se nimme nije bylden út de lêste laach dat waard ûntfongen yn de fernijing?
Yn it algemien, ja.
Dan as gefolch hawwe wy oant in fig fan lagen. En oer de tiid sille se moatte wurde komprimearre?
Ja alles is korrekt. Der is wat finster. Wy hâlde wyklikse snapshots. It hinget ôf fan hokker boarne jo hawwe. As jo de mooglikheid hawwe om in protte gegevens op te slaan, kinne jo snapshots foar in lange tiid bewarje. Se sille net fuort op harsels. D'r sil gjin gegevenskorrupsje wêze. As de snapshots ferâldere binne, sa't it ús liket, dus it hinget ôf fan it belied yn it bedriuw, dan kinne wy se gewoan wiskje en romte frijmeitsje.
Hallo, tank foar it rapport! Fraach oer Joe. Jo seine dat de klant net elkenien tagong ta de gegevens jaan woe. Strictly speaking, as in persoan hat it resultaat fan Explain Analyze, dan kin er peep de gegevens.
It is sa. Wy kinne bygelyks skriuwe: "SELECT FROM WHERE email = to that". Dat is, wy sille de gegevens sels net sjen, mar wy kinne wat yndirekte tekens sjen. Dit moat begrepen wurde. Mar oan de oare kant is it der allegear. Wy hawwe in log audit, wy hawwe kontrôle fan oare kollega's dy't ek sjogge wat de ûntwikkelders dogge. En as immen besiket dit te dwaan, dan sil de befeiligingstsjinst nei har komme en wurkje oan dit probleem.
Goeiemiddei Tank foar it ferslach! Ik haw in koarte fraach. As it bedriuw Slack net brûkt, is d'r dan no bining oan it, of is it mooglik foar ûntwikkelders om eksimplaren yn te setten om in testapplikaasje te ferbinen mei de databases?
No is d'r in keppeling nei Slack, d.w.s. d'r is gjin oare boadskipper, mar ik wol wirklik ek stipe meitsje foar oare boaden. Wat kinst dwaan? Jo kinne DB Lab ynsette sûnder Joe, gean mei help fan de REST API of mei help fan ús platfoarm en meitsje klonen en ferbine mei PSQL. Mar dit kin dien wurde as jo ree binne om jo ûntwikkelders tagong te jaan ta de gegevens, om't d'r gjin skerm mear sil wêze.
Ik haw dizze laach net nedich, mar ik haw sa'n kâns nedich.
Dan ja, it kin dien wurde.
Boarne: www.habr.com