DBA bot Joe. Anatoli Stansler (Postgres.ai)

Si e kupton një zhvillues backend që një pyetje SQL do të funksionojë mirë në një "prod"? Në kompanitë e mëdha ose me rritje të shpejtë, jo të gjithë kanë akses në "produkt". Dhe me akses, jo të gjitha kërkesat mund të kontrollohen pa dhimbje, dhe krijimi i një kopjeje të bazës së të dhënave shpesh kërkon orë të tëra. Për të zgjidhur këto probleme, ne krijuam një DBA artificiale - Joe. Tashmë është zbatuar me sukses në disa kompani dhe ndihmon më shumë se një duzinë zhvilluesish.

Video:

Pershendetje te gjitheve! Emri im është Anatoli Stansler. Unë punoj për një kompani postgres.ai. Ne jemi të përkushtuar të përshpejtojmë procesin e zhvillimit duke hequr vonesat që lidhen me punën e Postgres nga zhvilluesit, DBA dhe QA.

Kemi klientë të mëdhenj dhe sot një pjesë e raportit do t'i kushtohet rasteve që kemi takuar gjatë punës me ta. Unë do të flas se si i ndihmuam ata të zgjidhnin probleme mjaft serioze.

Kur po zhvillojmë dhe bëjmë migrime komplekse me ngarkesë të lartë, i bëjmë vetes pyetjen: "A do të fillojë ky migrim?". Ne përdorim rishikimin, përdorim njohuritë e kolegëve më me përvojë, ekspertëve të DBA. Dhe ata mund të tregojnë nëse do të fluturojë apo jo.

Por ndoshta do të ishte më mirë nëse do ta testonim vetë në kopje të madhësisë së plotë. Dhe sot do të flasim vetëm se cilat janë qasjet ndaj testimit tani dhe si mund të bëhet më mirë dhe me çfarë mjetesh. Ne gjithashtu do të flasim për të mirat dhe të këqijat e qasjeve të tilla dhe çfarë mund të rregullojmë këtu.

Kush ka bërë ndonjëherë indekse direkt në prod ose ka bërë ndonjë ndryshim? Mjaft pak. Dhe për kë çoi kjo në faktin se të dhënat humbën ose kishte kohë joproduktive? Atëherë ju e dini këtë dhimbje. Falë Zotit ka rezerva.

Qasja e parë është testimi në prod. Ose, kur një zhvillues ulet në një makinë lokale, ai ka të dhëna testimi, ka një lloj përzgjedhjeje të kufizuar. Dhe ne rrokulliset për të nxitur, dhe ne kemi këtë situatë.

Ajo dhemb, është e shtrenjtë. Ndoshta është më mirë të mos.

Dhe cila është mënyra më e mirë për ta bërë atë?

Le të marrim skenën dhe të zgjedhim një pjesë të prodhimit atje. Ose në rastin më të mirë, le të marrim një nxitje të vërtetë, të gjitha të dhënat. Dhe pasi ta kemi zhvilluar atë në nivel lokal, do të kontrollojmë shtesë për skenë.

Kjo do të na lejojë të heqim disa nga gabimet, d.m.th. t'i parandalojmë që të jenë në prod.

Cilat janë problemet?

• Problemi është se ne e ndajmë këtë skenë me kolegët. Dhe shumë shpesh ndodh që ju të bëni një lloj ndryshimi, bam - dhe nuk ka të dhëna, puna është në fund. Inskenimi ishte me shumë terabajt. Dhe ju duhet të prisni një kohë të gjatë që ajo të ngrihet përsëri. Dhe vendosim ta finalizojmë nesër. Kaq, kemi një zhvillim.
• Dhe, sigurisht, ne kemi shumë kolegë që punojnë atje, shumë ekipe. Dhe kjo duhet të bëhet me dorë. Dhe kjo është e papërshtatshme.

Dhe vlen të thuhet se kemi vetëm një përpjekje, një goditje, nëse duam të bëjmë disa ndryshime në bazën e të dhënave, të prekim të dhënat, të ndryshojmë strukturën. Dhe nëse diçka shkoi keq, nëse ka pasur një gabim në migrim, atëherë ne nuk do të kthehemi shpejt.

Kjo është më e mirë se qasja e mëparshme, por ka ende një probabilitet të lartë që një lloj gabimi të shkojë në prodhim.

Çfarë na pengon t'i japim secilit zhvillues një stol testimi, një kopje me madhësi të plotë? Mendoj se është e qartë se çfarë pengon.

Kush ka një bazë të dhënash më të madhe se një terabyte? Më shumë se gjysma e dhomës.

Dhe është e qartë se mbajtja e makinerive për çdo zhvillues, kur ka një prodhim kaq të madh, është shumë e shtrenjtë, dhe përveç kësaj, kërkon shumë kohë.

Kemi klientë që e kanë kuptuar se është shumë e rëndësishme të testohen të gjitha ndryshimet në kopje të madhësisë së plotë, por baza e të dhënave të tyre është më pak se një terabajt dhe nuk ka burime për të mbajtur një bankë testimi për secilin zhvillues. Prandaj, ata duhet të shkarkojnë deponitë në vend në makinën e tyre dhe të testojnë në këtë mënyrë. Duhet shumë kohë.

Edhe nëse e bëni atë brenda infrastrukturës, atëherë shkarkimi i një terabajti të dhënash në orë është tashmë shumë i mirë. Por ata përdorin deponitë logjike, shkarkojnë në nivel lokal nga cloud. Për ta, shpejtësia është rreth 200 gigabajt në orë. Dhe ende duhet kohë për t'u kthyer nga hale logjike, për të mbledhur indekset, etj.

Por ata përdorin këtë qasje sepse u lejon atyre të mbajnë produktin të besueshëm.

Çfarë mund të bëjmë këtu? Le t'i bëjmë stolat e testimit të lirë dhe t'i japim çdo zhvilluesi stolin e tij të provës.

Dhe kjo është e mundur.

Dhe në këtë qasje, kur bëjmë klone të hollë për secilin zhvillues, ne mund ta ndajmë atë në një makinë. Për shembull, nëse keni një bazë të dhënash 10 TB dhe dëshironi t'ua jepni 10 zhvilluesve, nuk keni nevojë të keni baza të dhënash XNUMX x XNUMX TB. Ju duhet vetëm një makinë për të bërë kopje të holla të izoluara për çdo zhvillues duke përdorur një makinë. Unë do t'ju tregoj se si funksionon pak më vonë.

Shembull i vërtetë:

• DB - 4,5 terabajt.

• Ne mund të marrim kopje të pavarura në 30 sekonda.

Ju nuk duhet të prisni për një stendë testimi dhe të vareni se sa i madh është. Mund ta merrni në sekonda. Do të jenë mjedise krejtësisht të izoluara, por që ndajnë të dhëna mes tyre.

Kjo eshte fantastike. Këtu po flasim për magji dhe një univers paralel.

Në rastin tonë, kjo funksionon duke përdorur sistemin OpenZFS.

OpenZFS është një sistem skedari kopjimi në shkrim që mbështet fotografitë dhe klonimet jashtë kutisë. Është i besueshëm dhe i shkallëzueshëm. Ajo është shumë e lehtë për t'u menaxhuar. Ajo fjalë për fjalë mund të vendoset në dy ekipe.

Ka opsione të tjera:

• lvm,

• Magazinimi (për shembull, Ruajtja e pastër).

Laboratori i bazës së të dhënave për të cilin po flas është modular. Mund të zbatohet duke përdorur këto opsione. Por tani për tani, ne jemi fokusuar në OpenZFS, sepse kishte probleme konkretisht me LVM.

Si punon? Në vend që t'i mbishkruajmë të dhënat sa herë që i ndryshojmë, ne i ruajmë ato thjesht duke shënuar se këto të dhëna të reja janë nga një pikë e re në kohë, një pamje e re.

Dhe në të ardhmen, kur duam të rikthehemi ose duam të bëjmë një klon të ri nga ndonjë version më i vjetër, ne thjesht themi: "OK, na jepni këto blloqe të dhënash që janë shënuar kështu."

Dhe ky përdorues do të punojë me një grup të tillë të dhënash. Ai gradualisht do t'i ndryshojë ato, do të bëjë fotografitë e tij.

Dhe ne do të degëzojmë. Secili zhvillues në rastin tonë do të ketë mundësinë të ketë klonin e tij që ai redakton, dhe të dhënat që ndahen do të ndahen midis të gjithëve.

Për të vendosur një sistem të tillë në shtëpi, duhet të zgjidhni dy probleme:

• E para është burimi i të dhënave, nga do t'i merrni ato. Ju mund të konfiguroni përsëritjen me prodhimin. Ju tashmë mund të përdorni kopjet rezervë që keni konfiguruar, shpresoj. WAL-E, WAL-G ose Barman. Dhe edhe nëse jeni duke përdorur një lloj zgjidhjeje Cloud si RDS ose Cloud SQL, atëherë mund të përdorni deponitë logjike. Por ne ende ju këshillojmë të përdorni kopje rezervë, sepse me këtë qasje do të ruani edhe strukturën fizike të skedarëve, gjë që do t'ju lejojë të jeni edhe më afër metrikës që do të shihnit në prodhim për të kapur ato probleme që ekzistojnë.

• E dyta është vendi ku dëshironi të strehoni laboratorin e bazës së të dhënave. Mund të jetë Cloud, mund të jetë On-premise. Është e rëndësishme të thuhet këtu se ZFS mbështet kompresimin e të dhënave. Dhe e bën mjaft mirë.

Imagjinoni që për çdo klon të tillë, në varësi të operacioneve që bëjmë me bazën, do të rritet një lloj dev. Për këtë, dev do t'i duhet gjithashtu hapësirë. Por për shkak të faktit se ne morëm një bazë prej 4,5 terabajtësh, ZFS do ta kompresojë atë në 3,5 terabajt. Kjo mund të ndryshojë në varësi të cilësimeve. Dhe ne kemi ende vend për dev.

Një sistem i tillë mund të përdoret për raste të ndryshme.

• Këta janë zhvillues, DBA për vërtetimin e pyetjeve, për optimizimin.

• Kjo mund të përdoret në testimin e QA për të testuar një migrim të caktuar përpara se ta nxjerrim atë për ta prodhuar. Dhe ne gjithashtu mund të krijojmë mjedise speciale për sigurimin e cilësisë me të dhëna reale, ku ato mund të testojnë funksionalitete të reja. Dhe do të duhen sekonda në vend të orëve të pritjes, dhe ndoshta ditë në disa raste të tjera ku nuk përdoren kopje të holla.

• Dhe një rast tjetër. Nëse kompania nuk ka një sistem analitik të ngritur, atëherë ne mund të izolojmë një klon të hollë të bazës së produktit dhe t'ia japim atë pyetjeve të gjata ose indekseve speciale që mund të përdoren në analitikë.

Me këtë qasje:

1. Probabilitet i ulët i gabimeve në "prod", sepse kemi testuar të gjitha ndryshimet në të dhënat me madhësi të plotë.

2. Ne kemi një kulturë testimi, sepse tani nuk duhet të prisni me orë të tëra për qëndrimin tuaj.

3. Dhe nuk ka asnjë pengesë, nuk ka pritje midis testeve. Në fakt mund të shkoni dhe të kontrolloni. Dhe do të jetë më mirë në këtë mënyrë ndërsa ne përshpejtojmë zhvillimin.

• Do të ketë më pak rifaktorizim. Më pak gabime do të përfundojnë në prod. Ne do t'i rifaktojmë ato më pak më vonë.

• Ne mund të kthejmë ndryshimet e pakthyeshme. Kjo nuk është qasja standarde.

1. Kjo është e dobishme sepse ne ndajmë burimet e bankave të testimit.

Tashmë mirë, por çfarë tjetër mund të përshpejtohet?

Falë një sistemi të tillë, ne mund ta zvogëlojmë shumë pragun për të hyrë në një testim të tillë.

Tani ekziston një rreth vicioz, kur një zhvillues, në mënyrë që të ketë akses në të dhëna reale me madhësi të plotë, duhet të bëhet ekspert. Atij duhet t'i besohet një akses i tillë.

Por si të rritet nëse nuk është aty. Po sikur të keni në dispozicion vetëm një grup shumë të vogël të dhënash testimi? Atëherë nuk do të keni ndonjë përvojë të vërtetë.

Si të dilni nga ky rreth? Si ndërfaqen e parë, të përshtatshme për zhvilluesit e çdo niveli, ne zgjodhëm botin Slack. Por mund të jetë çdo ndërfaqe tjetër.

Çfarë ju lejon të bëni? Ju mund të merrni një pyetje specifike dhe ta dërgoni në një kanal të veçantë për bazën e të dhënave. Ne do të vendosim automatikisht një klon të hollë në sekonda. Le ta zbatojmë këtë kërkesë. Ne mbledhim matje dhe rekomandime. Le të tregojmë një vizualizim. Dhe pastaj ky klon do të mbetet në mënyrë që kjo pyetje të mund të optimizohet disi, të shtojë indekse, etj.

Dhe gjithashtu Slack na jep mundësi për bashkëpunim jashtë kutisë. Meqenëse ky është vetëm një kanal, mund të filloni ta diskutoni këtë kërkesë pikërisht atje në temën për një kërkesë të tillë, duke bërë ping kolegët tuaj, DBA-të që janë brenda kompanisë.

Por sigurisht që ka probleme. Për shkak se kjo është bota reale, dhe ne po përdorim një server që pret shumë klone në të njëjtën kohë, duhet të kompresojmë sasinë e memories dhe fuqisë së CPU-së në dispozicion të kloneve.

Por që këto teste të jenë të besueshme, duhet ta zgjidhni disi këtë problem.

Është e qartë se pika e rëndësishme janë të njëjtat të dhëna. Por ne tashmë e kemi atë. Dhe ne duam të arrijmë të njëjtin konfigurim. Dhe ne mund të japim një konfigurim të tillë pothuajse identik.

Do të ishte mirë të kishim të njëjtin pajisje si në prodhim, por mund të ndryshojë.

Le të kujtojmë se si Postgres punon me kujtesën. Ne kemi dy cache. Një nga sistemi i skedarëve dhe një Postgres vendas, d.m.th. Shared Buffer Cache.

Është e rëndësishme të theksohet se Shared Buffer Cache ndahet kur Postgres fillon, në varësi të madhësisë që specifikoni në konfigurim.

Dhe cache e dytë përdor të gjithë hapësirën e disponueshme.

Dhe kur bëjmë disa klone në një makinë, rezulton se gradualisht mbushim kujtesën. Dhe në një mënyrë të mirë, Shared Buffer Cache është 25% e sasisë totale të memories që disponohet në makinë.

Dhe rezulton se nëse nuk e ndryshojmë këtë parametër, atëherë do të jemi në gjendje të ekzekutojmë vetëm 4 instanca në një makinë, domethënë 4 nga këta klone të hollë në total. Dhe kjo, natyrisht, është e keqe, sepse ne duam të kemi shumë më tepër prej tyre.

Por nga ana tjetër, Buffer Cache përdoret për të ekzekutuar pyetje për indekset, domethënë, plani varet nga sa i madh janë cache-të tona. Dhe nëse thjesht e marrim këtë parametër dhe e zvogëlojmë atë, atëherë planet tona mund të ndryshojnë shumë.

Për shembull, nëse kemi një cache të madhe në prod, atëherë Postgres do të preferojë të përdorë një indeks. Dhe nëse jo, atëherë do të ketë SeqScan. Dhe çfarë do të ishte nëse planet tona nuk do të përputheshin?

Por këtu arrijmë në përfundimin se në fakt plani në Postgres nuk varet nga madhësia specifike e specifikuar në Shared Buffer në plan, varet nga effect_cache_size.

Effective_cache_size është sasia e përllogaritur e cache-it që është në dispozicion për ne, d.m.th. shuma e cache-it të buffer-it dhe cache-it të sistemit të skedarëve. Kjo është vendosur nga konfigurimi. Dhe kjo memorie nuk është e ndarë.

Dhe për shkak të këtij parametri, ne mund ta mashtrojmë Postgresin, duke thënë se ne në fakt kemi shumë të dhëna në dispozicion, edhe nëse nuk i kemi këto të dhëna. Dhe kështu, planet do të përkojnë plotësisht me prodhimin.

Por kjo mund të ndikojë në kohën. Dhe ne optimizojmë pyetjet sipas kohës, por është e rëndësishme që koha të varet nga shumë faktorë:

• Kjo varet nga ngarkesa që është aktualisht në prod.

• Kjo varet nga karakteristikat e vetë makinës.

Dhe ky është një parametër indirekt, por në fakt ne mund të optimizojmë saktësisht me sasinë e të dhënave që do të lexojë ky pyetje për të marrë rezultatin.

Dhe nëse dëshironi që koha të jetë afër asaj që do të shohim në prod, atëherë duhet të marrim harduerin më të ngjashëm dhe, ndoshta, edhe më shumë në mënyrë që të gjithë klonet të përshtaten. Por ky është një kompromis, d.m.th. do të merrni të njëjtat plane, do të shihni se sa të dhëna do të lexojë një pyetje e veçantë dhe do të jeni në gjendje të arrini në përfundimin nëse kjo pyetje është e mirë (ose migrim) apo e keqe, duhet ende të optimizohet .

Le të hedhim një vështrim se si Joe është optimizuar në mënyrë specifike.

Le të marrim një kërkesë nga një sistem real. Në këtë rast, baza e të dhënave është 1 terabajt. Dhe ne duam të numërojmë numrin e postimeve të reja që kanë pasur më shumë se 10 pëlqime.

Ne po i shkruajmë një mesazh kanalit, një klon është vendosur për ne. Dhe ne do të shohim që një kërkesë e tillë do të përfundojë në 2,5 minuta. Kjo është gjëja e parë që vërejmë.

B Joe do t'ju tregojë rekomandime automatike bazuar në planin dhe metrikat.

Do të shohim që pyetja përpunon shumë të dhëna për të marrë një numër relativisht të vogël rreshtash. Dhe nevojitet një lloj indeksi i specializuar, pasi vumë re se ka shumë rreshta të filtruar në pyetje.

Le të hedhim një vështrim më të afërt se çfarë ndodhi. Në të vërtetë, ne shohim se kemi lexuar pothuajse një gigabajt e gjysmë të dhëna nga cache e skedarit apo edhe nga disku. Dhe kjo nuk është mirë, sepse kemi marrë vetëm 142 rreshta.

Dhe, me sa duket, ne kemi një skanim të indeksit këtu dhe duhet të kishim funksionuar shpejt, por meqenëse filtronim shumë rreshta (duheshim t'i numëronim), pyetja funksionoi ngadalë.

Dhe kjo ndodhi në plan për faktin se kushtet në pyetje dhe kushtet në indeks pjesërisht nuk përputhen.

Le të përpiqemi ta bëjmë indeksin më të saktë dhe të shohim se si ndryshon ekzekutimi i pyetjes pas kësaj.

Krijimi i indeksit zgjati mjaft kohë, por tani ne kontrollojmë pyetjen dhe shohim se koha në vend të 2,5 minutave është vetëm 156 milisekonda, që është mjaft e mirë. Dhe ne lexojmë vetëm 6 megabajt të dhëna.

Dhe tani ne përdorim vetëm skanimin e indeksit.

Një histori tjetër e rëndësishme është se ne duam ta paraqesim planin në një mënyrë më të kuptueshme. Ne kemi zbatuar vizualizimin duke përdorur Grafikët e Flakës.

Kjo është një kërkesë ndryshe, më intensive. Dhe ne ndërtojmë Grafikët e Flakës sipas dy parametrave: kjo është sasia e të dhënave që një nyje e veçantë numëroi në plan dhe kohën, d.m.th. koha e ekzekutimit të nyjes.

Këtu mund të krahasojmë nyjet specifike me njëra-tjetrën. Dhe do të jetë e qartë se cila prej tyre kërkon më shumë ose më pak, gjë që zakonisht është e vështirë të bëhet në metodat e tjera të paraqitjes.

Sigurisht, të gjithë e dinë të shpjegojnë.depesz.com. Një tipar i mirë i këtij vizualizimi është se ne ruajmë planin e tekstit dhe gjithashtu vendosim disa parametra bazë në një tabelë në mënyrë që të mund të renditim.

Dhe zhvilluesit që nuk janë thelluar ende në këtë temë përdorin gjithashtu shpjegojnë.depesz.com, sepse është më e lehtë për ta të kuptojnë se cilat metrika janë të rëndësishme dhe cilat jo.

Ekziston një qasje e re për vizualizimin - kjo është shpjegim.dalibo.com. Ata bëjnë një vizualizim të pemës, por është shumë e vështirë të krahasosh nyjet me njëra-tjetrën. Këtu mund ta kuptoni mirë strukturën, megjithatë, nëse ka një kërkesë të madhe, atëherë do t'ju duhet të lëvizni përpara dhe mbrapa, por edhe një opsion.

bashkëpunimi

Dhe, siç thashë, Slack na jep mundësinë për të bashkëpunuar. Për shembull, nëse hasim një pyetje komplekse që nuk është e qartë se si të optimizohet, mund ta sqarojmë këtë çështje me kolegët tanë në një fije në Slack.

Na duket se është e rëndësishme të testojmë në të dhëna me madhësi të plotë. Për ta bërë këtë, ne krijuam mjetin Update Database Lab, i cili është i disponueshëm në burim të hapur. Ju gjithashtu mund të përdorni bot Joe. Mund ta merrni menjëherë dhe ta zbatoni në vendin tuaj. Të gjithë udhëzuesit janë të disponueshëm atje.

Është gjithashtu e rëndësishme të theksohet se zgjidhja në vetvete nuk është revolucionare, sepse ekziston Delphix, por është një zgjidhje ndërmarrje. Eshte plotesisht i mbyllur, kushton shume. Ne jemi të specializuar në mënyrë specifike në Postgres. Këto janë të gjitha produkte me burim të hapur. Bashkohu me ne!

Këtu mbaroj. Faleminderit!

Pyetjet tuaja

Përshëndetje! Faleminderit për raportin! Shumë interesante, veçanërisht për mua, sepse kam zgjidhur të njëjtin problem disa kohë më parë. Dhe kështu kam një sërë pyetjesh. Shpresoj se do të marr të paktën një pjesë të saj.

Pyes veten si e llogaritni vendin për këtë mjedis? Teknologjia do të thotë që në rrethana të caktuara, klonet tuaja mund të rriten në madhësinë maksimale. Përafërsisht, nëse keni një bazë të dhënash dhjetë terabajt dhe 10 klone, atëherë është e lehtë të simuloni një situatë ku çdo klon peshon 10 të dhëna unike. Si e llogaritni këtë vend, pra atë deltën për të cilën folët, në të cilën do të jetojnë këta klone?

Pyetje e mirë. Është e rëndësishme të mbani gjurmët e kloneve specifike këtu. Dhe nëse një klon ka një ndryshim shumë të madh, ai fillon të rritet, atëherë fillimisht mund t'i lëshojmë një paralajmërim përdoruesit në lidhje me të, ose ta ndalojmë menjëherë këtë klon në mënyrë që të mos kemi një situatë dështimi.

Po, kam një pyetje të ndërthurur. Domethënë, si e siguroni ciklin jetësor të këtyre moduleve? Ne e kemi këtë problem dhe një histori krejt të veçantë. Si ndodh kjo?

Ka disa ttl për çdo klon. Në thelb, ne kemi një ttl fikse.

Çfarë, nëse jo një sekret?

1 orë, domethënë boshe - 1 orë. Nëse nuk përdoret, atëherë e përplasim. Por nuk ka asnjë surprizë këtu, pasi ne mund ta ngremë klonin në sekonda. Dhe nëse ju nevojitet përsëri, atëherë ju lutem.

Unë jam gjithashtu i interesuar për zgjedhjen e teknologjive, sepse, për shembull, ne përdorim disa metoda paralelisht për një arsye ose një tjetër. Pse ZFS? Pse nuk keni përdorur LVM? Ju përmendët se kishte probleme me LVM. Cilat ishin problemet? Për mendimin tim, opsioni më optimal është me ruajtjen, për sa i përket performancës.

Cili është problemi kryesor me ZFS? Fakti që duhet të ekzekutoni në të njëjtin host, d.m.th., të gjitha rastet do të jetojnë brenda të njëjtit OS. Dhe në rastin e ruajtjes, mund të lidhni pajisje të ndryshme. Dhe pengesa janë vetëm ato blloqe që janë në sistemin e ruajtjes. Dhe çështja e zgjedhjes së teknologjive është interesante. Pse jo LVM?

Në mënyrë të veçantë, ne mund të diskutojmë LVM në takim. Rreth ruajtjes - është thjesht e shtrenjtë. Ne mund të implementojmë sistemin ZFS kudo. Mund ta vendosni në kompjuterin tuaj. Ju thjesht mund të shkarkoni depon dhe ta vendosni atë. ZFS është instaluar pothuajse kudo nëse po flasim për Linux. Kjo do të thotë, ne marrim një zgjidhje shumë fleksibël. Dhe vetë ZFS jep shumë nga kutia. Mund të ngarkoni sa më shumë të dhëna të doni, të lidhni një numër të madh disqesh, ka fotografi. Dhe, siç thashë, është e lehtë për t'u administruar. Kjo është, duket shumë e këndshme për t'u përdorur. Ai është i testuar, është shumë vjeç. Ai ka një komunitet shumë të madh që po rritet. ZFS është një zgjidhje shumë e besueshme.

Nikolai Samokhvalov: Mund të komentoj më tej? Emri im është Nikolai, ne punojmë së bashku me Anatoli. Jam dakord që ruajtja është e shkëlqyeshme. Dhe disa nga klientët tanë kanë Pure Storage etj.

Anatoli vuri në dukje saktë se ne jemi të përqendruar në modularitet. Dhe në të ardhmen, mund të zbatoni një ndërfaqe - bëni një fotografi, bëni një klon, shkatërroni klonin. Është e gjitha e lehtë. Dhe ruajtja është e lezetshme, nëse është.

Por ZFS është i disponueshëm për të gjithë. DelPhix tashmë është mjaftueshëm, ata kanë 300 klientë. Prej tyre, fortune 100 ka 50 klientë, d.m.th. synojnë NASA-n, etj. Është koha që të gjithë ta marrin këtë teknologji. Dhe kjo është arsyeja pse ne kemi një Core me burim të hapur. Ne kemi një pjesë të ndërfaqes që nuk është me burim të hapur. Kjo është platforma që do të tregojmë. Por ne duam që ajo të jetë e arritshme për të gjithë. Ne duam të bëjmë një revolucion në mënyrë që të gjithë testuesit të ndalojnë të hamendësojnë në laptopë. Duhet të shkruajmë SELECT dhe menjëherë të shohim që është i ngadalshëm. Mos prisni që DBA t'ju tregojë për të. Këtu është qëllimi kryesor. Dhe unë mendoj se ne të gjithë do të arrijmë në këtë. Dhe ne e bëjmë këtë gjë që të gjithë ta kenë. Prandaj ZFS, sepse do të jetë i disponueshëm kudo. Faleminderit komunitetit për zgjidhjen e problemeve dhe për faktin që ekziston një licencë me kod të hapur, etj. *

pershendetje! Faleminderit për raportin! Emri im është Maksim. Ne jemi marrë me të njëjtat çështje. Ata vendosën vetë. Si i ndani burimet midis këtyre kloneve? Çdo klon mund të bëjë gjënë e tij në çdo moment: njëri teston një gjë, tjetri një tjetër, dikush ndërton një indeks, dikush ka një punë të rëndë. Dhe nëse ende mund të ndani me CPU, atëherë me IO, si e ndani? Kjo është pyetja e parë.

Dhe pyetja e dytë ka të bëjë me mosngjashmërinë e tribunave. Le të themi se unë kam ZFS këtu dhe gjithçka është e mirë, por klienti në prod nuk ka ZFS, por ext4, për shembull. Si në këtë rast?

Pyetjet janë shumë të mira. E përmenda pak këtë problem me faktin që ne ndajmë burimet. Dhe zgjidhja është kjo. Imagjinoni që po testoni në skenë. Mund të kesh edhe një situatë të tillë në të njëjtën kohë që dikush të japë një ngarkesë, dikush tjetër. Dhe si rezultat, ju shihni metrika të pakuptueshme. Edhe i njëjti problem mund të jetë me prod. Kur dëshironi të kontrolloni ndonjë kërkesë dhe të shihni se ka ndonjë problem me të - funksionon ngadalë, atëherë në fakt problemi nuk ishte në kërkesë, por në faktin se ka një lloj ngarkese paralele.

Prandaj, këtu është e rëndësishme të fokusohemi se cili do të jetë plani, çfarë hapash do të ndërmarrim në plan dhe sa të dhëna do të mbledhim për këtë. Fakti që disqet tona, për shembull, do të ngarkohen me diçka, do të ndikojë në mënyrë specifike në kohën. Por ne mund të vlerësojmë se sa e ngarkuar është kjo kërkesë nga sasia e të dhënave. Nuk është aq e rëndësishme që në të njëjtën kohë të ketë një lloj ekzekutimi.

Kam dy pyetje. Kjo është diçka shumë e lezetshme. A ka pasur raste kur të dhënat e prodhimit janë kritike, siç janë numrat e kartave të kreditit? A ka diçka gati tashmë apo është një detyrë më vete? Dhe pyetja e dytë - a ka diçka të tillë për MySQL?

Rreth të dhënave. Ne do të bëjmë turbullim derisa ta bëjmë. Por nëse vendosni saktësisht Joe, nëse nuk u jepni akses zhvilluesve, atëherë nuk ka qasje në të dhëna. Pse? Sepse Joe nuk tregon të dhëna. Tregon vetëm metrikë, plane dhe kaq. Kjo është bërë me qëllim, sepse kjo është një nga kërkesat e klientit tonë. Ata donin të ishin në gjendje të optimizonin pa i dhënë akses të gjithëve.

Rreth MySQL. Ky sistem mund të përdoret për çdo gjë që ruan gjendjen në disk. Dhe meqenëse po bëjmë Postgres, tani po bëjmë së pari të gjithë automatizimin për Postgres. Ne duam të automatizojmë marrjen e të dhënave nga një kopje rezervë. Ne po konfigurojmë Postgres saktë. Ne dimë të bëjmë që planet të përputhen, etj.

Por duke qenë se sistemi është i zgjerueshëm, ai mund të përdoret edhe për MySQL. Dhe ka shembuj të tillë. Yandex ka një gjë të ngjashme, por ata nuk e publikojnë askund. Ata e përdorin atë brenda Yandex.Metrica. Dhe ka vetëm një histori për MySQL. Por teknologjitë janë të njëjta, ZFS.

Faleminderit për raportin! Kam edhe nja dy pyetje. Ju përmendët se klonimi mund të përdoret për analitikë, për shembull për të ndërtuar indekse shtesë atje. Mund të tregoni pak më shumë se si funksionon?

Dhe menjëherë do të bëj pyetjen e dytë për ngjashmërinë e tribunave, ngjashmërinë e planeve. Plani varet edhe nga statistikat e mbledhura nga Postgres. Si e zgjidhni këtë problem?

Sipas analitikës, nuk ka raste konkrete, sepse ende nuk e kemi shfrytëzuar, por ka një mundësi të tillë. Nëse po flasim për indekse, atëherë imagjinoni që një pyetje po ndjek një tabelë me qindra miliona regjistrime dhe një kolonë që zakonisht nuk indeksohet në prod. Dhe ne duam të llogarisim disa të dhëna atje. Nëse kjo kërkesë dërgohet në prod, atëherë ekziston mundësia që ajo të jetë e thjeshtë në prod, sepse kërkesa do të procedohet atje për një minutë.

Ok, le të bëjmë një klon të hollë që nuk është e tmerrshme të ndalet për disa minuta. Dhe për ta bërë më të rehatshëm leximin e analitikës, ne do të shtojmë indekse për ato kolona në të cilat ne jemi të interesuar për të dhëna.

Indeksi do të krijohet çdo herë?

Mund ta bëni në mënyrë që ne të prekim të dhënat, të bëjmë fotografi, më pas do të rikuperojmë nga kjo fotografi dhe do të dërgojmë kërkesa të reja. Kjo do të thotë, ju mund ta bëni atë në mënyrë që të mund të ngrini klone të reja me indekse të vendosura tashmë.

Sa i përket pyetjes për statistikat, nëse restaurojmë nga një kopje rezervë, nëse bëjmë përsëritje, atëherë statistikat tona do të jenë saktësisht të njëjta. Sepse ne kemi të gjithë strukturën e të dhënave fizike, domethënë do t'i sjellim të dhënat ashtu siç janë me të gjitha metrikat e statistikave.

Këtu është një problem tjetër. Nëse përdorni një zgjidhje cloud, atëherë vetëm deponitë logjike janë të disponueshme atje, sepse Google, Amazon nuk ju lejojnë të merrni një kopje fizike. Do të ketë një problem.

Faleminderit për raportin. Kishte dy pyetje të mira këtu në lidhje me MySQL dhe ndarjen e burimeve. Por, në fakt, gjithçka vjen në faktin se kjo nuk është një temë e DBMS specifike, por e sistemit të skedarëve në tërësi. Dhe, në përputhje me rrethanat, çështjet e ndarjes së burimeve duhet gjithashtu të zgjidhen nga atje, jo në fund që është Postgres, por në sistemin e skedarëve, në server, për shembull.

Pyetja ime është pak më ndryshe. Është më afër bazës së të dhënave me shumë shtresa, ku ka disa shtresa. Për shembull, ne vendosëm një përditësim imazhi dhjetë terabajt, ne po riprodhojmë. Dhe ne e përdorim në mënyrë specifike këtë zgjidhje për bazat e të dhënave. Replikimi është në progres, të dhënat po përditësohen. Janë 100 punonjës që punojnë paralelisht këtu, të cilët po hedhin vazhdimisht këto xhirime të ndryshme. Çfarë duhet bërë? Si të sigurohemi që të mos ketë asnjë konflikt, që ata të nisën një të tillë, dhe më pas sistemi i skedarëve ndryshoi, dhe këto fotografi shkuan të gjitha?

Ata nuk do të shkojnë sepse kështu funksionon ZFS. Mund të mbajmë veçmas në një thread ndryshimet e sistemit të skedarëve që vijnë për shkak të replikimit. Dhe mbani klonet që përdorin zhvilluesit në versionet më të vjetra të të dhënave. Dhe kjo funksionon për ne, gjithçka është në rregull me këtë.

Rezulton se përditësimi do të bëhet si një shtresë shtesë, dhe të gjitha fotografitë e reja do të shkojnë tashmë, bazuar në këtë shtresë, apo jo?

Nga shtresat e mëparshme që ishin nga përsëritjet e mëparshme.

Shtresat e mëparshme do të bien, por ato do t'i referohen shtresës së vjetër dhe a do të marrin imazhe të reja nga shtresa e fundit që është marrë në përditësim?

Në përgjithësi, po.

Më pas si pasojë do të kemi deri në një fik me shtresa. Dhe me kalimin e kohës ata do të duhet të kompresohen?

Po gjithçka është e saktë. Ka një dritare. Ne mbajmë fotografi javore. Varet nga burimi që keni. Nëse keni aftësinë për të ruajtur shumë të dhëna, mund të ruani fotografi për një kohë të gjatë. Ata nuk do të largohen vetë. Nuk do të ketë korrupsion të të dhënave. Nëse fotografitë janë të vjetruara, siç na duket, d.m.th. varet nga politika në kompani, atëherë thjesht mund t'i fshijmë dhe të lirojmë hapësirë.

Përshëndetje, faleminderit për raportin! Pyetje për Joe. Ju thatë që klienti nuk donte t'u jepte të gjithëve akses në të dhënat. Në mënyrë të rreptë, nëse një person ka rezultatin e Shpjegoni Analizën, atëherë ai mund të shikojë të dhënat.

Është kështu. Për shembull, mund të shkruajmë: "SELECT FROM WHERE email = në atë". Kjo do të thotë, ne nuk do t'i shohim vetë të dhënat, por mund të shohim disa shenja indirekte. Kjo duhet kuptuar. Por nga ana tjetër, gjithçka është atje. Ne kemi një auditim të regjistrave, kemi kontrollin e kolegëve të tjerë të cilët gjithashtu shohin se çfarë po bëjnë zhvilluesit. Dhe nëse dikush përpiqet ta bëjë këtë, atëherë shërbimi i sigurisë do të vijë tek ata dhe do të punojë për këtë çështje.

Mirembrema Faleminderit për raportin! Unë kam një pyetje të shkurtër. Nëse kompania nuk përdor Slack, a ka ndonjë detyrim për të tani, apo a është e mundur që zhvilluesit të vendosin shembuj për të lidhur një aplikacion testimi me bazat e të dhënave?

Tani ka një lidhje me Slack, d.m.th. nuk ka asnjë mesazher tjetër, por me të vërtetë dua të bëj mbështetje edhe për mesazherët e tjerë. Cfare mund te besh? Ju mund të vendosni DB Lab pa Joe, të shkoni me ndihmën e REST API ose me ndihmën e platformës sonë dhe të krijoni klone dhe të lidheni me PSQL. Por kjo mund të bëhet nëse jeni gati t'u jepni zhvilluesve qasje në të dhëna, sepse nuk do të ketë më asnjë ekran.

Unë nuk kam nevojë për këtë shtresë, por kam nevojë për një mundësi të tillë.

Atëherë po, mund të bëhet.

Burimi: www.habr.com