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
