Si një zhvillues backend, si e kupton se një SQL kërkesë do të funksionojë mirë në «prod»? Në kompanitë e mëdha ose ato që rriten shpejt, aksesin në «prod» të gjithë nuk e kanë. Po ashtu, me aksesin nuk është e lehtë të verifikosh të gjitha kërkesat pa probleme, dhe krijimi i një kopjeje të bazës së të dhënave shpesh merr orë. Për të zgjidhur këto probleme, krijuam një DBA të artificshëm – Joe. Ai tashmë është implementuar me sukses në disa kompani dhe ndihmon shumë zhvillues.
Video:
Përshëndetje të gjithëve! Quhem Anatolij Stansler. Punoj në kompaninë . Ne merremi me përshpejtimin e procesit të zhvillimit, duke hequr vonesat e lidhura me funksionimin e Postgres për zhvilluesit, DBA dhe QA.
Kemi klientë të shkëlqyer dhe sot një pjesë e prezantimit do t'i kushtohet rasteve që kemi hasur gjatë punës me ta. Do të flas për mënyrën se si i ndihmuam ata të zgjidhnin probleme mjaft serioze.
Kur jemi në procesin e zhvillimit dhe bëjmë migrime të komplikuara të ngarkesave, e kemi pyetjen: "A do të përflaket kjo migrim?" Ne përdorim review, e themi me njohuritë e kolegëve më të përvojshëm dhe ekspertëve DBA. Dhe ata mund të thonë – do të përflaket apo jo.
Porë, ndoshta do të ishte më mirë nëse do të mundnim ta testonim këtë vetë në kopjet e plota. Dhe sot pikërisht do të flasim për qasjet aktuale ndaj testimit dhe si mund ta bëjmë më mirë dhe me cilat mjete. Gjithashtu do të diskutojmë për avantazhet dhe disavantazhet e këtyre qasjeve, si dhe se çfarë mund të korrigjojmë këtu.
Kush ndonjëherë ka krijuar indekse ose ka bërë disa ndryshime direkt në prodhim? Ka pasur mjaft. Dhe sa prej jush ka përjetuar humbje të të dhënave ose ndërprerje? Atëherë ju e njihni këtë dhimbje. Faleminderit Zotit, kemi kopje rezervë.
Qasja e parë është testimi në prodhim. Ose, kur zhvilluesi është me një makinë lokale, ka të dhëna testuese, një mostër të kufizuar. Dhe ne e hedhim në prodhim dhe marrim këtë situatë.
Kjo është e dhimbshme, është e shtrenjtë. Ndoshta, nuk është më mirë të bëhet kështu.
Si duhet bërë më mirë?
Le të marrim staging dhe të ndalim një pjesë të prodhimit. Ose, në rastin më të mirë, të marrim të gjithë të dhënat reale nga prodhimi. Dhe pasi të kemi zhvilluar lokal, do të kontrollojmë gjithashtu në staging.
Kjo do të na lejojë të eliminojmë disa gabime, dmth. të mos i lejojmë në prodhim.
Cilat janë problemet?
- Problemi është se këtë staging e ndajem me kolegët. Dhe shumë shpesh ndodh që ti bën një ndryshim, bam – dhe nuk ka asnjë të dhënë, puna shkon dëm. Staging ishte shumë-terabajt. Dhe duhet shumë kohë derisa të ngrihet sërish. Dhe ne vendosim ta përfundojmë këtë nesër. Çdo gjë, zhvillimi ynë është ndalur.
- Dhe, sigurisht, atje punojnë shumë kolegë, shumë ekipe. Dhe është e nevojshme të koordinohen manualisht. Kjo është e papërshtatshme.
Dhe duhet thënë se kemi vetëm një përpjekje, një goditje, nëse duam të japim disa ndryshime në bazën e të dhënave, të prekëm të dhënat, të ndryshojmë strukturën. Dhe nëse diçka shkon keq, nëse kishte një gabim në migrim, përfundimisht nuk do të mund të rikthehemi shpejt.
Kjo është më mirë se qasja e mëparshme, por prapë ka një probabilitet të madh që ndonjë gabim të kalojë në prodhim.
Çfarë na pengon të gjithëve zhvilluesve t'u japim një ambjent testimi, një kopje përmasash të plota? Mendoj se është e qartë çfarë na pengon.
Kush ka një bazë të dhënash më të madhe se një terabajt? Më shumë se gjysma e sallës.
Dhe është e qartë se të mbash makina për çdo zhvillues, kur ka një prodhim kaq të madh, është shumë e shtrenjtë, dhe gjithashtu merr shumë kohë.
Kemi klientë që e kuptojnë rëndësinë e testimit të të gjitha ndryshimeve në kopje të plota, por ata kanë më pak se një terabajt bazë dhe nuk kanë burime për të mbajtur një qëndër testimi për çdo zhvillues. Prandaj, ata duhet të shkarkojnë dump-et lokal në kompjuterin e tyre dhe të testojnë në këtë mënyrë. Kjo merr shumë kohë.
Edhe nëse e bëni këtë brenda infrastrukturës, shkarkimi i një terabajti të dhënash për një orë – është vërtet shumë e mirë. Por ata përdorin dump-e logjike dhe i shkarkojnë lokal nga cloud. Për ta, shpejtësia është rreth 200 gigabajt për orë. Dhe gjithashtu duhet kohë për të rikuperuar nga dump-i logjik, për të aplikuar indeksët, etj.
Por ata e përdorin këtë qasje sepse lejon që prodhimi të qëndrojë i besueshëm.
Çfarë mund të bëjmë këtu? Le të bëjmë që qendrat testuese të jenë të lira dhe t'i japim çdo zhvilluesi të vetin qendër testuese.
Dhe kjo është e mundur.
Dhe me këtë qasje, kur krijojmë klone të hollë për çdo zhvillues, mund ta ndajmë këtë në një makinë. Për shembull, nëse keni një bazë prej katër terabajtësh dhe dëshironi t'i jepni atë 10 zhvilluesve, nuk keni nevojë për 10 herë katër terabajtë baza. Ju mjafton një makinë për të krijuar kopje të izoluara të holla për secilin zhvillues, duke përdorur një makinë. Si funksionon do ta tregoj pak më vonë.
Një shembull real:
BD – 4.5 terabajt.
Mund të marrim kopje të pavarura për 30 sekonda.
Nuk keni nevojë të prisni për një testim të qëndrueshëm dhe të vareni nga madhësia e tij. Mund ta merrni atë brenda sekondash. Këto do të jenë mjete të plota izoluese, por që ndajnë të dhënat mes vetes.
Kjo është e shkëlqyer. Këtu po flasim për magjinë dhe universin paralel.
Në rastin tonë, kjo funksionon me sistemin OpenZFS.
OpenZFS është një sistem skedari copy-on-write, i cili përfshin natyrshëm mbështetje për snapshote dhe klone. Ai është i besueshëm dhe i shkallëzueshëm. E menaxhohet shumë lehtë. Mund të vendoset me vetëm dy komanda.
Ka mundësi të tjera:
LVM,
Sistemet e ruajtjes (p.sh., Pure Storage).
Laboratori i bazave, për të cilin po flas, është modular. Mund të realizohet duke përdorur këto mundësi. Por për momentin jemi fokusuar te OpenZFS, sepse konkretisht pati probleme me LVM.
Si funksionon? Në vend që të shkruajmë të dhënat çdo herë kur i ndryshojmë, ne i ruajmë ato, thjesht duke i etiketuar se këto të dhëna të reja i përkasin një momenti të ri në kohë, një snapshot të ri.
Dhe më tej, kur duam të kthehemi prapa ose duam të bëjmë një klon të ri nga ndonjë version më të vjetër, thjesht i themi: "Ok, na jepni këto blloqe të dhënash, të cilat janë etiketuar në këtë mënyrë."
Dhe ky përdorues do të punojë me këtë grup të dhënash. Ai do t'i modifikojë gradualisht, duke bërë snapshotet e tij.
Dhe do të kemi degëzim. Çdo zhvillues në rastin tonë do të ketë mundësinë të ketë klonin e tij, të cilin e redakton, ndërsa të dhënat që janë të përbashkët do të ndahen mes të gjithëve.
Për të implementuar një sistem të tillë, duhet të zgjidhni dy probleme:
E para, ky është burimi i të dhënave, nga i cili do t'i merrni ato. Mund të konfigurohet replikimi me production. Mund të përdorni backup-et që keni të vendosur, shpresoj. WAL-E, WAL-G ose Barman. Dhe madje, nëse po përdorni një zgjidhje Cloud, si RDS ose Cloud SQL, mund të përdorni dumpe logjike. Megjithatë, ne ju rekomandojmë të përdorni backup-et, sepse me këtë qasje do të ruani gjithashtu strukturën fizike të skedave, gjë që do të lejojë të jeni më afër metrikave që do të shihnit në production, për të kapur problemet që ekzistojnë.
E dyta – është vendi ku dëshironi të hostoni Database Lab. Kjo mund të jetë Cloud, mund të jetë On-premise. Këtu është e rëndësishme të thuhet se ZFS mbështet kompresimin e të dhënave. Dhe e bën këtë mjaft mirë.
Imagjinoni që çdo klon i tillë, në varësi të operacioneve që bëjmë me bazën, do të ketë një dev që do të rritet. Për këtë dev gjithashtu do të nevojitet hapësirë. Por për shkak se morëm një bazë prej 4.5 terabajtësh, ZFS do ta comprimojë atë në 3.5 terabajtë. Në varësi të konfigurimeve, kjo mund të ndryshohet. Dhe do të mbetet hapësirë për dev-in.
Një sistem i tillë mund të përdoret për raste të ndryshme.
Këta janë zhvilluesit, DBA për të verifikuar kërkesat, për optimizimin.
Kjo mund të përdoret në testimin QA për të verifikuar migrimin specifik para se të nxjerrim këtë në prodhim. Gjithashtu, mund të ngrisim ambjente speciale për QA me të dhëna reale, ku ata mund të testojnë funksionalitetin e ri. Dhe kjo do të marrë sekonda në vend që të presim orë, ndoshta edhe ditë në disa raste të tjera ku nuk përdoren kopje të hollë.
Dhe një rast tjetër të veçantë. Nëse në kompani nuk është vendosur një sistem analitik, mund të nxjerrim një klon të hollë të bazës produktive dhe ta japim për kërkesa të gjata ose për indekse speciale që mund të përdoren në analitikë.
Me këtë qasje:
Probabilitet i ulët për gabime në "prod", sepse të gjitha ndryshimet janë testuar në të dhëna të plota.
Ne krijojmë një kulturë testimi, pasi tani nuk është e nevojshme të presim orë për një platformë të vetme.
Dhe nuk ka pengesa, nuk ka pritje mes testimeve. Në të vërtetë mund të shkosh dhe ta verifikosh. Dhe kështu do të jetë më mirë, pasi do të përshpejtojmë zhvillimin.
Do të ketë më pak refaktorizim. Do të ketë më pak bug-e që do të kalojnë në prodhim. Ne do t'i refaktorizojmë më pak më vonë.
Ne mund të bëjmë ndryshime irrëversibile. Kjo nuk ekziston në qasjet standarde.
- Kjo është e dobishme, sepse ne ndajmë burimet e mjediseve teste.
Tani është mirë, por çfarë tjetër mund të shpejtohet?
Falë kësaj sistemi, ne mund të ulim ndjeshëm pragun e hyrjes në këtë testim.
Aktualisht kemi një cikël të mbyllur, ku zhvilluesi, për të marrë akses tek të dhënat reale në përmasë të plotë, duhet të bëhet ekspert. Ai duhet të besohët me këtë akses.
Por si të rritesh, nëse nuk e ke. Çfarë ndodh nëse keni vetëm një grup shumë të vogël të dhënash për testa? Atëherë nuk mund të marrësh përvojë reale.
Si të dalim nga ky cikël? Si interfejsin e parë, të përshtatshëm për zhvilluesit e çdo niveli, ne zgjodhëm një bot Slack. Por kjo mund të jetë çdo interfejs tjetër.
Çfarë lejon të bëjë? Mund të marrësh një kërkesë specifike dhe ta dërgosh në një kanal të veçantë për bazën e të dhënave. Ne automatikisht do të krijojmë një klon të hollë brenda sekondash. Do ta ekzekutojmë këtë kërkesë. Do të grumbullojmë metrika dhe rekomandime. Do të shfaqim vizualizimin. Më pas, ky klon do të mbetet në dispozicion për të optimizuar këtë kërkesë, për të shtuar indekse etj.
Dhe gjithashtu, Slack na ofron mundësi për bashkëpunim nga fillimi. Duke qenë se është thjesht një kanal, mund të fillosh diskutimin për këtë kërkesë direkt në thread, duke përmendur kolegët e tu, DBA-të që janë brenda kompanisë.
Por, sigurisht, ka dhe probleme. Duke qenë se është një botë reale, dhe ne përdorim një server ku hostojmë shumë klonë, na duhet të pakësojmë sasinë e memories dhe fuqisë procesorike që klonët kanë në dispozicion.
Por për të pasur testet që janë të besueshme, është e nevojshme të zgjidhet ndonjëherë ky problem.
E qartë është se një moment i rëndësishëm janë të dhënat e njëjta. Por ne tashmë i kemi këto. Dhe dëshirojmë të arrijmë një konfigurim të njëjtë. Dhe ne mund t'i ofrojmë një konfigurim praktikisht të njëjtë.
Do t'kishte një të tillë harduer si në production, por ai mund të ndryshojë.
Le të kujtojmë se si Postgres punon me memorien. Ne kemi dy cache. Një nga sistemi i skedarëve dhe një tjetër nga Postgres vetë, dmth. Shared Buffer Cache.
Është e rëndësishme të theksohet se Shared Buffer Cache alokohet kur Postgres fillon në varësi të madhësisë që do të përcaktoni në konfigurim.
Dhe cache i dytë përdor të gjithë hapësirën e disponueshme.
Dhe kur krijojmë disa klone në një makinë, rezulton se ne gradualisht po e mbushim memorien. Dhe në mënyrë të përshtatshme, Shared Buffer Cache është 25% e gjithë kapacitetit të memories që është e disponueshme në makinë.
Dhe kështu, nëse ne nuk e ndryshojmë këtë parametër, do të mund të fillojmë vetëm 4 instance në një makinë, dmth. vetëm 4 të tilla klone të holla. Kjo natyrisht është e keqe, sepse duam të kemi shumë më tepër.
Por nga ana tjetër, Buffer Cache përdoret për ekzekutimin e pyetjeve, për indeksat, dmth. plani varet nga madhësia e cache-eve tona. Dhe nëse e marrim këtë parametër dhe e zvogëlojmë, planet tona mund të ndryshojnë ndjeshëm.
Për shembull, nëse kemi një cache të madhe në prodhimin tonë, Postgres do të preferonte të përdorte indeksin. Por nëse jo, atëherë do të ketë SeqScan. Çfarë kuptimi ka nëse planet tona nuk do të përputheshin?
Por këtu arrijmë në një zgjidhje që në të vërtetë plani në Postgres nuk varet nga madhësia e caktuar në Shared Buffer, por varet nga effective_cache_size.
Effective_cache_size është vëllimi i supozuar i cache-it që na është i aksesueshëm, pra në përmbledhje Buffer Cache dhe cache e sistemit të skedarëve. Kjo përcaktohet nga konfigurimi. Dhe kjo memorie nuk alokohen.
Dhe përmes këtij parametri mund të mashtrojmë në njëfarë forme Postgres, duke thënë se në të vërtetë na janë të accesueshme shumë të dhëna, edhe nëse nuk i kemi ato të dhëna. Dhe kështu, planet do të përputhen plotësisht me prodhimin.
Por kjo mund të ndiejë mbi kohën e ekzekutimit. Ne optimizojmë kërkesat sipas kohës, por e rëndësishme është se koha varet nga shumë faktorë:
Varet nga ngarkesa që aktualisht ka në prodhim.
Varet nga karakteristikat e vetë makinës.
Dhe ky është një parameter indirekt, por në të vërtetë mund të optimizojmë sipas sasisë së të dhënave që ky kërkesë do të lexojë për të marrë rezultatin.
Dhe nëse dëshirojmë që koha të jetë sa më e afërt me atë që do të shohim në prodhim, atëherë na nevojitet të marrim harduer sa më të ngjashëm, dhe ndoshta edhe më shumë, në mënyrë që të gjithë klonët të kenë vend. Por kjo është një kompromis, pra do të merrni plane të ngjashme, do të shihni se sa të dhëna lexon një kërkesë e caktuar dhe do të jeni në gjendje të përfundoni – a është kjo kërkesë e mirë (ose migrim) apo e keqe, duhet ende të optimizohet.
Le t'i hedhim një vështrim se si kalon optimizimi me Joe.
Të marrim një kërkesë nga një sistem real. Në këtë rast, baza e të dhënave është 1 terabyte. Dhe ne duam të numurojmë sa janë postimet e reja, të cilat kanë më shumë se 10 pëlqime.
Ne shkruajmë një mesazh në kanal, u zhvillua për ne një klon. Dhe ne do të shohim se një kërkesë e tillë do të përfundojë brenda 2.5 minutash. Kjo është e para që do të vëmë re.
B Joe do të tregojë rekomandime automatike, të bazuara në planin dhe metrikat.
Ne do të shohim se kërkesa po përpunon shumë të dhëna, për të marrë një numër relativisht të vogël rreshtash. Dhe na nevojitet një indeks i specializuar, pasi vërejtëm se në kërkesë ka shumë rreshta të filtruar.
Le të shohim më në detaje se çfarë ndodhi. Në të vërtetë, shohim se kemi lexuar gati një e gjysmë gigabajt të dhënash nga cache-i i skedarëve ose madje nga disku. Dhe kjo nuk është e mirë, pasi kemi marrë vetëm 142 rreshta.
Dhe, siç duket, kemi këtu një skanim indeksi dhe duhej të kishte funksionuar shpejt, por, pasi kemi filtruar shumë rreshta (na u desh t'i numëronim), kërkesa punoi ngadalë.
Dhe kjo ndodhi në plan për shkak se kushtet në kërkesë dhe kushtet në indeks nuk përputhen plotësisht.
Le të provojmë të bëjmë indeksin më të saktë dhe të shohim si do të ndryshojë ekzekutimi i kërkesës pas kësaj.
Krijimi i indeksit mori mjaft kohë, por tani po kontrollojmë kërkesën dhe shohim se koha nga 2,5 minuta ra në vetëm 156 milisekonda, që është mjaft mirë. Dhe po lexojmë vetëm 6 megabajt të dhënash.
Dhe tani po përdorim skanimin vetëm të indeksit.
Një histori tjetër e rëndësishme është se dëshirojmë ta prezantojmë planin në një mënyrë më të kuptueshme. Ne kemi implementuar vizualizimin përmes Flame Graphs.
Ky është një kërkesë tjetër, më e pasur. Ne krijojmë Flame Graphs bazuar në dy parametra: sasia e të dhënave që një nod konkret ka lexuar dhe kohën, dmth, kohën e ekzekutimit të nodit.
Këtu mund të krahasojmë konkretisht nodet midis tyre. Dhe do të jetë e qartë se cila prej tyre merr më shumë ose më pak, e cila zakonisht është e vështirë të bëhet në metoda të tjera vizualizimi.
Sigurisht, të gjithë e dinë explain.depesz.com. Një karakteristikë e shkëlqyer e kësaj vizualizimi është se ne ruajmë planin tekstual dhe gjithashtu nxjerrim disa parametra kryesorë në një tabelë, për të mundësuar renditjen.
Dhe zhvilluesit që ende nuk janë thelluar në këtë temë, gjithashtu përdorin explain.depesz.com, sepse është më e lehtë për ta të kuptojnë cilat metrika janë të rëndësishme dhe cilat jo.
Ka një qasje të re për vizualizimin – kjo është explain.dalibo.com. Ata bëjnë një vizualizim në formë peme, por këtu është shumë e vështirë të krahasosh nodet midis tyre. Këtu është e lehtë të kuptohet struktura, megjithatë, nëse do të ketë një kërkesë të madhe, do të duhet të skrollosh këtu e atje, por është gjithashtu një mundësi.
Kolaborimi
Dhe, siç e thashë më parë, Slack na ofron mundësinë për bashkëpunim. Për shembull, nëse hasim një kërkesë të ngatërruar që nuk dihet si ta optimizojmë, mund ta sqarojmë këtë çështje me kolegët tanë në thread në Slack.
Na duket se është e rëndësishme të testojmë me të dhëna në shkallë të plotë. Për këtë, kemi krijuar mjetin Update Database Lab, i cili është në open source. Ju gjithashtu mund të përdorni botin Joe. Mund ta merrni atë tani dhe ta përdorni te ju. Të gjitha udhëzimet janë aty.
Është gjithashtu e rëndësishme të theksohet se zgjidhja vetë nuk është ndonjë gjë revolucionare, sepse ekziston Delphix, por kjo është një zgjidhje enterprise. Ajo është plotësisht e mbyllur dhe kushton shumë. Ne specializohemi pikërisht në Postgres. Të gjitha këto produkte janë open source. Bashkohuni me ne!
Me këtë përfundoj. Faleminderit!
Pyetje
Përshëndetje! Faleminderit për prezantimin! Jashtëzakonisht interesant, sidomos për mua, sepse kam trajtuar një detyrë të ngjashme pak kohë më parë. Prandaj kam një sërë pyetjesh. Shpresoj se do të arrij të bëj të paktën disa prej tyre.
Interessant, sih do llogaritni hapësirën për këtë mjedis? Technologjia nënkupton se në kushte të caktuara, klonët tuaj mund të rriten deri në madhësinë maksimale. Në terma të thjeshtë, nëse keni një bazë dhjetë terabajt dhe 10 klonë, lehtësisht mund të modeloni një situatë ku çdo klon peshoj me 10 të dhëna unike. Si e llogaritni atë hapësirë, pra atë diferencë, për të cilën flisnit, ku do të jetojnë këta klonë?
Pyetje e mirë. Këtu është e rëndësishme të kuptoni klonët specifikë. Nëse ndodh një ndryshim shumë i madh te ndonjë klon dhe ai fillon të rritet, mund të lëshojmë fillimisht një paralajmërim për këtë përdoruesin, ose ta ndalojmë menjëherë atë klon, për të parandaluar një situatë dështimi.
Po, kam një pyetje të brendshme. Domethënë, si e siguroni ciklin e jetës së këtyre moduleve? Ne e kemi këtë si një problem dhe një histori të veçantë. Si ndodh kjo?
Ka një ttl për çdo klon. Në parim, ne kemi një ttl të fiksuar.
Cili është, nëse nuk keni ndonjë sekret?
1 orë, pra idle – 1 orë. Nëse nuk përdoret, atëherë ne e shuajmë. Por këtu nuk ka asnjë surprizë, pasi mund të ngremë një klon për sekonda. Dhe nëse përsëri nevojitet, atëherë – s'ka problem.
Më intereson gjithashtu zgjedhja e teknologjive, sepse ne, për shembull, përdorim disa metoda paralelisht për arsye të ndryshme. Pse pikërisht ZFS? Pse nuk keni përdorur LVM? Ju e përmendët se keni pasur probleme me LVM. Cilat ishin këto probleme? Sipas mendimit tim, opsioni më optimal është ai me SCSI, sa i përket performancës.
Cila është problemi kryesor me ZFS? Ai është se duhet të funksionojë në një host, pra të gjithë instancat do të jetojnë brenda një operacioni. Ndërsa në rastin me SCSI, mund të lidhni pajisje të ndryshme. Dhe pika e ngushtë janë vetëm ato blloqe, të cilat janë në SCSI. Dhe pyetje interesante është për zgjedhjen e teknologjive. Pse jo LVM?
Mund të flasim për LVM në meetup. Rreth storjeve të dhënash – është thjesht e kushtueshme. Ne mund ta implementojmë sistemin ZFS kudo. Mund ta vendosni në makinat tuaja. Thjesht mund të shkarkoni depozitat dhe ta vendosni. ZFS instalohet pothuajse kudo, nëse flasim për Linux. Pra, kemi një zgjidhje shumë fleksibile. Vetë ZFS ofron shumë nga paketa. Mund të ngarkoni sasi të pakufizuara të të dhënave, lidhni shumë disqe, janë të disponueshme snapshot-et. Dhe, siç e thashë, është shumë e lehtë për ta administruar. Pra, duket shumë e këndshme për t'u përdorur. Ka shumë vite që ekziston dhe është testuar. Ka një komunitet shumë të madh, që vazhdon të rritet. ZFS është një zgjidhje shumë e besueshme.
Nikola Samohvalov: A mund të komentoj edhe unë? Më quajnë Nikola, punoj me Anatonin. Jam dakord që storjet e dhënash janë të shkëlqyera. Disa klientë tanë kanë Pure Storage dhe të tjera.
Anatoli e theksoi saktësisht se ne jemi të fokusuar në modularitet. Në të ardhmen, mund të implementojmë një ndërfaqe – krijo snapshot, krijo klon, shkatërro klonin. E gjitha është e lehtë. Dhe storjet e dhënash janë të shkëlqyera, nëse ekzistojnë.
Por ZFS është i accessible për të gjithë. Mjaft me DelPhix, ata kanë 300 klientë. Prej tyre në fortune 100 — 50 klientë, domethënë atallë ndihmojnë NASA-n e kështu me radhë. Është koha për të bërë këtë teknologji të disponueshme për të gjithë. Prandaj kemi Core-në open source. Ne kemi një pjesë të ndërfaqes që nuk është open source. Kjo është platforma që do të tregojmë. Por ne duam që kjo të jetë e aksesueshme për çdo njeri. Ne duam të bëjmë një revolucion, që të gjithë testuesit të ndalen së parashikuari në laptopë. Duhet të shkruajmë SELECT dhe të shohim menjëherë nëse është i ngadaltë. Mjaft më me pritjen për t'u treguar nga DBA. Kjo është synimi kryesor. Dhe mendoj se do ta arrijmë këtë të gjithë ne. Dhe këtë gjë e bëjmë që të jetë e gjithësecilit. Prandaj ZFS, sepse do të jetë i gjithëpërhapur. Faleminderit komunitetit për zgjidhjen e problemeve dhe për licencën open source etj.*
Përshëndetje! Faleminderit për prezantimin! Më quajnë Maksim. Ne kemi përballuar probleme të ngjashme. I kemi zgjidhur atje. Si ndani burimet midis këtyre klonëve? Çdo klon në çdo moment mund të merret me gjënë e vet: një teston diçka, tjetri diçka tjetër, një ndërtim indeksi, ndonjë tjetër ka një punë të rëndë. Nëse për CPU ka mundësi të ndajmë, si e ndan për IO? Ky është pyetja e parë.
Dhe pyetje e dytë ka të bëjë me mospërputhjen e standeve. Supozoni, kam këtu ZFS dhe gjithçka është në rregull, ndërsa klienti në prodhimin e tij ka ext4, për shembull. Si e zgjidhim këtë rast?
Pyetjet janë shumë të mira. Pak e përmenda këtë problem lidhur me ndarjen e burimeve. Zgjidhja është si më poshtë. Mendoni se keni një testim në staging. Edhe aty mund të ndodhi që dikush të japë një ngarkesë, ndonjë tjetër një tjetër. Në fund, shihni metrika të paqarta. Edhe një problem i tillë mund të ndodhë në prodhim. Kur dëshironi të kontrolloni një kërkesë dhe shihni se ka ndonjë problem – ajo po përfundon ngadalë, në të vërtetë problemi nuk ka qenë në kërkesë, por në ngarkesën paralele.
Pra, këtu është e rëndësishme të përqendrohemi në atë se çfarë plani do të kemi, cilat hapa do të ndjekim dhe sa të dhëna do të ngremë për këtë. Ajo që ka të bëjë me diskun, për shembull, që do të ngarkohet me diçka, do të ndikojë konkretisht në kohën e përgjigjes. Por mund të vlerësojmë sasinë e të dhënave për të parë se sa e ngarkuar është kjo kërkesë. Nuk ka shumë rëndësi nëse ka një ekzekutim tjetër në të njëjtën kohë.
Kam dy pyetje. Kjo është diçka shumë e bukur. A ka pasur raste kur të dhënat në production janë tepër të rëndësishme, siç janë numrat e kartave të kreditit? A është ndonjë gjë e gatshme tashmë apo është një detyrë e veçantë? Pyetja e dytë – a ka diçka të tillë për MySQL?
Për sa i përket të dhënave. Ne do të bëjmë obfuscim, derisa ta bëjmë këtë. Por nëse ju implementoni pikërisht Joe, nëse nuk i jepni qasje zhvilluesve, atëherë nuk ka qasje në të dhëna. Pse? Sepse Joe nuk tregon të dhënat. Ai tregon vetëm metrikat, planet dhe gjithçka tjetër. Kjo është bërë qëllimisht, sepse është një nga kërkesat e klientit tonë. Ata dëshironin të kishin mundësinë të optimizojnë, por pa i dhënë qasje të gjithëve.
Për sa i përket MySQL. Ky sistem mund të përdoret për çdo gjë që ruan gjendjen në disk. Dhe pasi ne merremi me Postgres, aktualisht po bëjmë automatin e plotë për Postgres. Ne duam të automatizojmë marrjen e të dhënave nga backup. Ne e konfigurojmë Postgres siç duhet. Ne e dimë se si mund të bëjmë që planet të përputhen, etj.
Por shkak se sistemi është i zgjerueshëm, ai gjithashtu mund të përdoret për MySQL. Ka disa shembuj të tillë. Një skemë e ngjashme ka Yandex, por ata nuk e publikojnë asnjëherë. Ata e përdorin brenda Yandex.Metrica. Dhe aty saktësisht ka histori për MySQL. Por teknologjitë janë të njëjta, ZFS.
Faleminderit për prezantimin! Kam edhe disa 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ë na tregoni pak më shumë se si funksionon kjo?
Dhe menjëherë po bëj pyetjen e dytë në lidhje me uniformitetin e standeve, uniformitetin e planeve. Plani varet, përfshirë statistikën e mbledhur nga Postgres. Si e zgjidhni këtë problem?
Për analitikën nuk kemi raste të veçanta, sepse nuk e kemi përdorur kështu deri tani, por ka një mundësi të tillë. Nëse flasim për indekset, imagjinoni që një kërkesë ekzekutohet në një tabelë me qindra milionë të dhëna dhe në një kolonë që zakonisht nuk është indeksuar në prodhim. Dhe ne duam të llogarisim disa të dhëna aty. Nëse e ekzekutojmë këtë kërkesë në prodhim, ka mundësi që prodhimi të ndalet, sepse kërkesa do të zgjat për një minutë.
Ok, le të bëjmë një klon të hollë, i cili nuk është problem të ndalet për disa minuta. Dhe për ta bërë më të lehtë llogaritjen e statistikave, do të shtojmë indekse për ato kolona që na interesojnë.
Indeksi do të krijohet çdo herë?
Mund të bëjmë që të prekim të dhënat, të krijojmë snapshot-e, pastaj nga ky snapshot do të rikthehemi dhe të ekzekutojmë kërkesa të reja. Domethënë, mund të bëjmë që të mund të ndajmë klonë të rinj me indekse të vendosura tashmë.
Sa i përket pyetjes në lidhje me statistikat, nëse ne rikthehemi nga një backup, nëse ne bëjmë replikim, atëherë statistikat tona do të jenë saktësisht të njëjta. Sepse struktura fizike e të dhënave do të jetë plotësisht identike, dmth. të dhënat siç janë me të gjitha metrikat e statistikës do t'i sjellim gjithashtu.
Këtu ka një problem tjetër. Nëse përdoret një zgjidhje cloud, atëherë aty janë të disponueshme vetëm dump-et logjike, sepse Google, Amazon nuk japin kopje fizike. Do të ketë një problem të tillë.
Faleminderit për raportin. Këtu u shfaqën dy pyetje të mira për MySQL dhe për ndarjen e burimeve. Megjithatë, thelbësisht, gjithçka reduktohet në faktin se kjo është një temë jo specifike për SGBD-të, por për sistemin e skedarëve në përgjithësi. Prandaj, pyetjet për ndarjen e burimeve gjithashtu duhet të zgjidhen nga aty, dhe jo në fund, duke thënë se është Postgres, por në sistemin e skedarëve, në serveri, në instance.
Pyetja ime është pak më ndryshe. Ajo është më afër shumë-shtresimit të bazës së të dhënave, ku ka disa shtresa. Për shembull, ne kemi konfigurur azhurnimin e një imazhi dhjetë terabajtësh, kemi replikimin në zhvillim. Dhe ne konkretisht përdorim këtë zgjidhje për bazat e të dhënave. Po zhvillohet replikimi, ndodhin azhurnime të të dhënave. Në këtë rast, punojnë paralelisht 100 punonjës, të cilët vazhdimisht fillojnë këto imazhe të ndryshme. Çfarë duhet të bëjmë? Si mund të bëjmë që të mos ketë konflikte, që ata të fillojnë një të tillë, pastaj sistemi i skedarëve të ndryshojë, dhe këto imazhe të shkelen?
Ato nuk do të çojnë, sepse kështu funksionon ZFS. Mund të mbajmë ndarë në një rrjedhë ndryshimet e sistemit të skedarëve, të cilat vijnë përmes replikimit. Dhe të mbajmë klonët në versionet e vjetra të të dhënave, të cilat zhvilluesit i përdorin. Dhe kjo na funksionon, me këtë gjithçka është në rregull.
Kështu që përditësimi do të ndodhë si një shtresë shtesë, dhe të gjitha imazhet e reja do të shkojnë duke u bazuar në këtë shtresë, apo jo?
Nga shtresat e mëparshme, që kanë qenë nga replikimet e mëparshme.
Shtresat e mëparshme do të largohen, por ato do të referohen në shtresën e vjetër, dhe imazhet e reja do t'i marrin nga shtresa e fundit që është marrë në përditësim?
Në përgjithësi, po.
Atëherë si pasojë do të kemi shumë shtresa. Dhe me kalimin e kohës do të duhet t'i kompresojmë?
Po, saktësisht. Ka një dritare. Ruajmë snapshot-e javore. Kjo varet nga sa burime keni. Nëse keni mundësinë të ruani shumë të dhëna, mund të mbani snapshot-e për një periudhë të gjatë. Ato nuk do të fshihen vetë. Nuk do të ketë ndonjë korruptim të të dhënave. Nëse snapshot-et janë të vjetra, siç na duket, dmth kjo varet nga politika në kompani, atëherë mund t’i fshijmë ato dhe të çlirojmë hapësirë.
Përshëndetje, faleminderit për prezentimin! Në lidhje me pyetjen e Joe. Ju thatë se klienti nuk dëshironte t’i jepte qasje askujt për të dhënat. Rreptësisht, nëse një person ka rezultatet e Explain Analyze, ai mund t'i shikojë të dhënat.
E gjitha është e vërtetë. Për shembull, ne mund të shkruajmë: «SELECT FROM WHERE email = dikush». Kështu, ne nuk do të shohim të dhënat vetë, por mund të shikojmë disa tregues indirekt. Kjo është diçka që duhet ta kuptojmë. Megjithatë, nga ana tjetër, kjo është gjithashtu evidente. Ne kemi logët e auditurit, kemi kontrollin e kolegëve të tjerë që gjithashtu shohin se me çfarë po merren zhvilluesit. Dhe nëse dikush përpiqet të bëjë kështu, shërbimi i sigurisë do të shkojë tek ata dhe do të punojë mbi këtë çështje.
Përshëndetje! Faleminderit për prezantimin! Kam një pyetje të shkurtër. Nëse Slack nuk përdoret në kompani, a ka ndonjë lidhje me të tani ose a mund të krijojmë instanca për zhvilluesit, për të lidhur aplikacionin testues me bazat?
Aktualisht ka një lidhje me Slack, domethënë nuk ka ndonjë mesazh tjetër, por është shumë e dëshirueshme të bëjmë mbështetje për mesazhe të tjera gjithashtu. Çfarë mund të bëni? Mund të vendosni DB Lab pa Joe, të përdorni REST API ose platformën tonë për të krijuar klonë dhe për t'u lidhur me PSQL. Por kjo mund të bëhet nëse jeni të gatshëm të jepni zhvilluesve tuaj qasje në të dhëna, sepse këtu nuk do të ketë asnjë ekran.
Mua më nevojitet kjo ndërfaqe, por më nevojitet një mundësi e tillë.
Atëherë – po, kjo mund të bëhet.
Burimi: habr.com
