Kontributi i Yandex në bazat e të dhënave të mëposhtme do të rishikohet.
- Shtëpi Kliko
- Odisea
- Rimëkëmbja deri në një pikë në kohë (WAL-G)
- PostgreSQL (përfshirë logerrors, Amcheck, heapcheck)
- Kumbulla jeshile
Video:
Përshendetje Botë! Emri im është Andrey Borodin. Dhe ajo që bëj në Yandex.Cloud është të zhvilloj baza të dhënash të hapura relacionale në interes të klientëve Yandex.Cloud dhe Yandex.Cloud.
Në këtë bisedë, ne do të flasim për sfidat me të cilat përballen bazat e të dhënave të hapura në shkallë. Pse është e rëndësishme? Sepse pak e pak probleme që, si mushkonjat, më pas bëhen elefantë. Ato bëhen të mëdha kur keni shumë grupime.
Por kjo nuk është gjëja kryesore. Gjëra të pabesueshme ndodhin. Gjërat që ndodhin në një në një milion raste. Dhe në një mjedis cloud, ju duhet të jeni të përgatitur për këtë, sepse gjërat e pabesueshme bëhen shumë të mundshme kur diçka ekziston në shkallë.
Por! Cili është avantazhi i bazave të të dhënave të hapura? Fakti është se ju keni një mundësi teorike për t'u marrë me çdo problem. Ju keni kodin burimor, keni njohuri programimi. E kombinojmë dhe funksionon.
Çfarë qasjesh ekzistojnë për të punuar në softuer me burim të hapur?
- Qasja më e drejtpërdrejtë është përdorimi i softuerit. Nëse përdorni protokolle, nëse përdorni standarde, nëse përdorni formate, nëse shkruani pyetje në softuer me burim të hapur, atëherë ju tashmë e mbështesni atë.
- Ju po e bëni ekosistemin e tij më të madh. Ju rritni mundësinë e zbulimit të hershëm të një defekti. Ju rrisni besueshmërinë e këtij sistemi. Ju rrisni disponueshmërinë e zhvilluesve në treg. Ju e përmirësoni këtë softuer. Ju jeni tashmë një kontribues nëse sapo keni marrë stilin dhe keni ndërruar diçka atje.
- Një tjetër qasje e kuptueshme është sponsorizimi i softuerit me burim të hapur. Për shembull, programi i mirënjohur Google Summer of Code, kur Google paguan një numër të madh studentësh nga e gjithë bota para të kuptueshme në mënyrë që ata të zhvillojnë projekte të hapura softuerike që plotësojnë disa kërkesa licencimi.
- Kjo është një qasje shumë interesante sepse lejon që softueri të evoluojë pa e zhvendosur fokusin larg komunitetit. Google, si një gjigant i teknologjisë, nuk thotë se ne duam këtë veçori, ne duam ta rregullojmë këtë gabim dhe këtu duhet të gërmojmë. Google thotë: “Bëni atë që bëni. Thjesht vazhdoni të punoni ashtu siç keni punuar dhe gjithçka do të jetë mirë.”
- Qasja tjetër për të marrë pjesë në burim të hapur është pjesëmarrja. Kur keni një problem në softuerin me burim të hapur dhe ka zhvillues, zhvilluesit tuaj fillojnë t'i zgjidhin problemet. Ata fillojnë ta bëjnë infrastrukturën tuaj më efikase, programet tuaja më të shpejta dhe më të besueshme.
Një nga projektet më të famshme Yandex në fushën e softuerit me burim të hapur është ClickHouse. Kjo është një bazë të dhënash që lindi si përgjigje ndaj sfidave me të cilat përballet Yandex.Metrica.
Dhe si një bazë të dhënash, ajo u krijua në burim të hapur për të krijuar një ekosistem dhe për ta zhvilluar atë së bashku me zhvilluesit e tjerë (jo vetëm brenda Yandex). Dhe tani ky është një projekt i madh në të cilin janë përfshirë shumë kompani të ndryshme.
Në Yandex.Cloud, ne krijuam ClickHouse në krye të ruajtjes së objekteve Yandex, d.m.th. në krye të ruajtjes së cloud.
Pse është e rëndësishme kjo në re? Sepse çdo bazë të dhënash funksionon në këtë trekëndësh, në këtë piramidë, në këtë hierarki të llojeve të memories. Ju keni regjistra të shpejtë, por të vegjël dhe SSD të lira, të mëdha, por të ngadalta, disqe të ngurtë dhe disa pajisje të tjera bllokuese. Dhe nëse jeni efikas në krye të piramidës, atëherë keni një bazë të dhënash të shpejtë. nëse jeni efikas në fund të kësaj piramide, atëherë keni një bazë të dhënash të shkallëzuar. Dhe në këtë drejtim, shtimi i një shtrese tjetër nga poshtë është një qasje logjike për rritjen e shkallëzueshmërisë së bazës së të dhënave.
Si mund të bëhej? Kjo është një pikë e rëndësishme në këtë raport.
- Ne mund të implementojmë ClickHouse mbi MDS. MDS është një ndërfaqe e brendshme e ruajtjes së reve Yandex. Është më kompleks se protokolli i zakonshëm S3, por është më i përshtatshëm për një pajisje bllok. Është më mirë për regjistrimin e të dhënave. Kërkon më shumë programim. Programuesit do të programojnë, madje është mirë, është interesante.
- S3 është një qasje më e zakonshme që e bën ndërfaqen më të thjeshtë me koston e më pak përshtatjes ndaj llojeve të caktuara të ngarkesave të punës.
Natyrisht, duke dashur t'i ofrojmë funksionalitet të gjithë ekosistemit ClickHouse dhe të bëjmë detyrën që nevojitet brenda Yandex.Cloud, vendosëm të sigurohemi që i gjithë komuniteti ClickHouse të përfitojë prej tij. Ne kemi implementuar ClickHouse mbi S3, jo ClickHouse mbi MDS. Dhe kjo është shumë punë.
referencat:
"Shtesa e abstraksionit të sistemit të skedarëve"
"Integrimi AWS SDK S3"
"Zbatimi bazë i ndërfaqes IDisk për S3"
"Integrimi i motorëve të ruajtjes së regjistrave me ndërfaqen IDisk"
"Mbështetje e motorit të regjistrit për S3 dhe SeekableReadBuffer"
"Mbështetje Storage Stripe Log S3"
"Storage MergeTree mbështetje fillestare për S3"
"MergeTree mbështetje e plotë për S3"
"Support ReplicatedMergeTree mbi S3"
"Shto kredencialet e paracaktuara dhe titujt e personalizuar për ruajtjen e s3"
"S3 me konfigurim dinamik të përfaqësuesit"
"S3 me zgjidhës proxy"
Kjo është një listë e kërkesave tërheqëse për zbatimin e një sistemi skedarësh virtual në ClickHouse. Ky është një numër i madh i kërkesave për tërheqje.
referencat:
"Zbatimi optimal i lidhjeve të forta DiskS3"
"Klienti S3 HTTP - Shmangni kopjimin e rrjedhës së përgjigjeve në memorie"
“Shmangni kopjimin e të gjithë rrjedhës së përgjigjeve në memorie në S3 HTTP
klient"
"Aftësia për të cache shenjën dhe indeksimin e skedarëve për diskun S3"
"Lëvizni pjesë nga DiskLocal në DiskS3 paralelisht"
Por puna nuk mbaroi me kaq. Pas krijimit të veçorisë, kërkohej më shumë punë për të optimizuar këtë funksionalitet.
referencat:
"Shto ngjarje të SelectedRows dhe SelectedBytes"
"Shto ngjarje të profilizimit nga kërkesa S3 në system.events"
"Shto QueryTimeMicroseconds, SelectQueryTimeMicroseconds dhe InsertQueryTimeMicroseconds"
Dhe atëherë ishte e nevojshme që të bëhej i diagnostikueshëm, të vendosej monitorimi dhe të bëhej i menaxhueshëm.
Dhe e gjithë kjo u bë në mënyrë që i gjithë komuniteti, i gjithë ekosistemi ClickHouse, të merrte rezultatin e kësaj pune.
Le të kalojmë te bazat e të dhënave transaksionale, te bazat e të dhënave OLTP, të cilat janë më afër meje personalisht.
Ky është divizioni i zhvillimit të DBMS me burim të hapur. Këta djem po bëjnë magji në rrugë për të përmirësuar bazat e të dhënave të hapura transaksionale.
Një nga projektet, duke përdorur një shembull të të cilit mund të flasim se si dhe çfarë bëjmë, është Connection Pooler në Postgres.
Postgres është një bazë të dhënash procesesh. Kjo do të thotë që baza e të dhënave duhet të ketë sa më pak lidhje rrjeti që të jetë e mundur që të trajtojnë transaksionet.
Nga ana tjetër, në një mjedis cloud, një situatë tipike është kur një mijë lidhje vijnë në një grup menjëherë. Dhe detyra e grupit të lidhjeve është të paketojë një mijë lidhje në një numër të vogël lidhjesh të serverit.
Mund të themi se bashkuesi i lidhjes është operatori telefonik i cili i riorganizon bajtet në mënyrë që ato të arrijnë në mënyrë efikase në bazën e të dhënave.
Fatkeqësisht, nuk ka asnjë fjalë të mirë ruse për bashkimin e lidhjeve. Ndonjëherë quhet lidhje multiplekser. Nëse e dini se si ta quani bashkuesin e lidhjes, atëherë sigurohuni që të më tregoni, do të jem shumë i lumtur të flas gjuhën e saktë teknike ruse.
Ne hetuam bashkuesit e lidhjeve që ishin të përshtatshme për një grup postgres të menaxhuar. Dhe PgBouncer ishte zgjidhja më e mirë për ne. Por ne hasëm një sërë problemesh me PgBouncer. Shumë vite më parë, Volodya Borodin dha raporte se ne përdorim PgBouncer, na pëlqen gjithçka, por ka nuanca, ka diçka për të punuar.
Dhe ne punuam. Ne rregulluam problemet që hasëm, rregulluam Bouncer dhe u përpoqëm të shtynim kërkesat për tërheqje në rrjedhën e sipërme. Por me një fillesë themelore ishte e vështirë të punohej.
Na u desh të mblidhnim kaskada nga Bouncers të arnuara. Kur kemi shumë Bouncer me një fije, lidhjet në shtresën e sipërme transferohen në shtresën e brendshme të Bouncers. Ky është një sistem i menaxhuar keq që është i vështirë për t'u ndërtuar dhe për t'u shkallëzuar përpara dhe mbrapa.
Ne arritëm në përfundimin se krijuam grupin tonë të lidhjeve, i cili quhet Odisea. E kemi shkruar nga e para.
Në vitin 2019, në konferencën PgCon, unë e prezantova këtë grup para komunitetit të zhvilluesve. Tani kemi pak më pak se 2 yje në GitHub, domethënë projekti është i gjallë, projekti është i popullarizuar.
Dhe nëse krijoni një grup Postgres në Yandex.Cloud, atëherë do të jetë një grup me Odyssey të integruar, i cili rikonfigurohet kur shkallëzoni grupin përpara ose me radhë.
Çfarë mësuam nga ky projekt? Nisja e një projekti konkurrues është gjithmonë një hap agresiv, është një masë ekstreme kur themi se ka probleme që nuk zgjidhen sa duhet, nuk zgjidhen në intervalet kohore që do të na përshtateshin. Por kjo është një masë efektive.
PgBouncer filloi të zhvillohej më shpejt.
Dhe tani janë shfaqur projekte të tjera. Për shembull, pgagroal, i cili është zhvilluar nga zhvilluesit e Red Hat. Ata ndjekin qëllime të ngjashme dhe zbatojnë ide të ngjashme, por, natyrisht, me specifikat e tyre, të cilat janë më afër zhvilluesve të pgagroal.
Një rast tjetër i punës me komunitetin postgres po rikthehet në një moment në kohë. Ky është rikuperimi pas një dështimi, ky është rikuperimi nga një kopje rezervë.
Ka shumë kopje rezervë dhe të gjithë janë të ndryshëm. Pothuajse çdo shitës Postgres ka zgjidhjen e vet rezervë.
Nëse merrni të gjitha sistemet rezervë, krijoni një matricë të veçorive dhe llogaritni me shaka përcaktuesin në këtë matricë, ai do të jetë zero. Çfarë do të thotë kjo? Po sikur të merrni një skedar rezervë specifik, atëherë ai nuk mund të mblidhet nga pjesët e të gjithë të tjerëve. Është unik në zbatimin e tij, është unik në qëllimin e tij, është unik në idetë që janë të ngulitura në të. Dhe të gjitha janë specifike.
Ndërsa po punonim për këtë çështje, CitusData lançoi projektin WAL-G. Ky është një sistem rezervë që është krijuar me një sy në mjedisin cloud. Tani CitusData është tashmë pjesë e Microsoft. Dhe në atë moment, ne na pëlqyen shumë idetë që u hodhën në publikimet fillestare të WAL-G. Dhe ne filluam të kontribuojmë në këtë projekt.
Tani ka shumë dhjetëra zhvillues në këtë projekt, por 10 kontribuesit kryesorë të WAL-G përfshijnë 6 Yandexoids. Ne sollëm shumë nga idetë tona atje. Dhe, sigurisht, ne i zbatuam ato vetë, i testuam vetë, i hodhëm në prodhim vetë, i përdorim vetë, ne vetë kuptojmë se ku të lëvizim më pas, ndërsa ndërveprojmë me komunitetin e madh WAL-G.
Dhe nga këndvështrimi ynë, tani ky sistem rezervë, përfshirë marrjen parasysh të përpjekjeve tona, është bërë optimale për një mjedis cloud. Kjo është kostoja më e mirë e rezervimit të Postgres në re.
Çfarë do të thotë? Ne po promovonim një ide mjaft të madhe: rezervimi duhet të jetë i sigurt, i lirë për t'u përdorur dhe sa më shpejt që të jetë e mundur për t'u restauruar.
Pse duhet të jetë i lirë për të vepruar? Kur asgjë nuk është e prishur, nuk duhet të dini se keni kopje rezervë. Gjithçka funksionon mirë, ju shpenzoni sa më pak CPU, përdorni sa më pak burime të diskut dhe dërgoni sa më pak bajt në rrjet që të mos ndërhyni në ngarkesën e shërbimeve tuaja të vlefshme.
Dhe kur gjithçka prishet, për shembull, administratori i hodhi të dhënat, diçka shkoi keq dhe ju duhet urgjentisht të ktheheni në të kaluarën, rikuperoni me të gjitha paratë, sepse dëshironi që të dhënat tuaja të kthehen shpejt dhe të paprekura.
Dhe ne promovuam këtë ide të thjeshtë. Dhe, na duket, kemi arritur ta zbatojmë atë.
Por kjo nuk është e gjitha. Ne donim edhe një gjë të vogël. Ne donim shumë baza të dhënash të ndryshme. Jo të gjithë klientët tanë përdorin Postgres. Disa njerëz përdorin MySQL, MongoDB. Në komunitet, zhvillues të tjerë kanë mbështetur FoundationDB. Dhe kjo listë po zgjerohet vazhdimisht.
Komunitetit i pëlqen ideja që baza e të dhënave të ekzekutohet në një mjedis të menaxhuar në re. Dhe zhvilluesit ruajnë bazat e tyre të të dhënave, të cilat mund të rezervohen në mënyrë uniforme së bashku me Postgres me sistemin tonë rezervë.
Çfarë kemi mësuar nga kjo histori? Produkti ynë, si divizion zhvillimi, nuk është linja kodi, nuk është deklarata, nuk është skedarë. Produkti ynë nuk është kërkesa tërheqëse. Këto janë idetë që ne i përcjellim komunitetit. Kjo është ekspertizë teknologjike dhe lëvizja e teknologjisë drejt një mjedisi cloud.
Ekziston një bazë e të dhënave si Postgres. Më pëlqen më shumë thelbi i Postgres. Kaloj shumë kohë duke zhvilluar thelbin e Postgres me komunitetin.
Por këtu duhet thënë se Yandex.Cloud ka një instalim të brendshëm të bazave të të dhënave të menaxhuara. Dhe filloi shumë kohë më parë në Yandex.Mail. Ekspertiza që ka çuar tani në Postgres të menaxhuar u grumbullua kur posta donte të kalonte në Postgres.
Mail ka kërkesa shumë të ngjashme me cloud. Ajo ka nevojë që ju të jeni në gjendje të shkallëzoheni në një rritje eksponenciale të papritur në çdo pikë të të dhënave tuaja. Dhe posta tashmë kishte një ngarkesë me disa qindra miliona kuti postare të një numri të madh përdoruesish që vazhdimisht bëjnë shumë kërkesa.
Dhe kjo ishte një sfidë mjaft serioze për ekipin që po zhvillonte Postgres. Në atë kohë, çdo problem që hasëm i raportohej komunitetit. Dhe këto probleme u korrigjuan, dhe u korrigjuan nga komuniteti në disa vende edhe në nivelin e mbështetjes me pagesë për disa baza të tjera të dhënash dhe akoma më mirë. Kjo do të thotë, ju mund t'i dërgoni një letër hakerit PgSQL dhe të merrni një përgjigje brenda 40 minutave. Mbështetja me pagesë në disa baza të dhënash mund të mendojë se ka gjëra më prioritare sesa gabimet tuaja.
Tani instalimi i brendshëm i Postgres është disa petabajt të dhëna. Këto janë disa miliona kërkesa në sekondë. Këto janë mijëra grupime. Është në shkallë shumë të madhe.
Por ka një nuancë. Ai nuk jeton në disqet e rrjetit të zbukuruar, por në pajisje mjaft të thjeshta. Dhe ekziston një mjedis testimi posaçërisht për gjëra të reja interesante.
Dhe në një moment të caktuar në mjedisin e testimit morëm një mesazh që tregonte se invariantet e brendshme të indekseve të bazës së të dhënave ishin shkelur.
Një invariant është një lloj marrëdhënieje që ne presim ta mbajmë gjithmonë.
Një situatë shumë kritike për ne. Kjo tregon se disa të dhëna mund të kenë humbur. Dhe humbja e të dhënave është diçka krejtësisht katastrofike.
Ideja e përgjithshme që ndjekim në bazat e të dhënave të menaxhuara është se edhe me përpjekje, do të jetë e vështirë të humbasësh të dhënat. Edhe nëse i hiqni qëllimisht, do t'ju duhet të injoroni mungesën e tyre për një periudhë të gjatë kohore. Siguria e të dhënave është një fe që ne e ndjekim me mjaft zell.
Dhe këtu lind një situatë që sugjeron se mund të ketë një situatë për të cilën mund të mos jemi të përgatitur. Dhe ne filluam të përgatitemi për këtë situatë.
Gjëja e parë që bëmë ishte varrosja e trungjeve nga këto mijëra grupime. Ne zbuluam se cilat nga grupet ndodheshin në disqe me firmware problematik që po humbnin përditësimet e faqeve të të dhënave. Shënuar të gjithë kodin e të dhënave Postgres. Dhe ne i shënuam ato mesazhe që tregojnë shkelje të invarianteve të brendshme me kod që është krijuar për të zbuluar korrupsionin e të dhënave.
Ky patch praktikisht u pranua nga komuniteti pa shumë diskutime, sepse në çdo rast specifik ishte e qartë se diçka e keqe kishte ndodhur dhe duhej të raportohej në regjistër.
Pas kësaj, arritëm në pikën që kemi monitorim që skanon regjistrat. Dhe në rast mesazhesh të dyshimta, ai e zgjon detyrën, dhe kujdestari e riparon atë.
Por! Skanimi i regjistrave është një operacion i lirë në një grup dhe katastrofikisht i shtrenjtë për një mijë grupime.
Ne shkruam një shtesë të quajtur . Krijon një pamje të bazës së të dhënave në të cilën mund të zgjidhni me çmim të ulët dhe shpejt statistikat për gabimet e kaluara. Dhe nëse duhet të zgjojmë oficerin e shërbimit, atëherë do ta zbulojmë këtë pa skanuar skedarë gigabajt, por duke nxjerrë disa bajt nga tabela e hash-it.
Kjo shtesë është miratuar, për shembull, në depo për . Nëse dëshironi ta përdorni, mund ta instaloni vetë. Sigurisht që është me kod të hapur.
Por kjo nuk është e gjitha. Ne filluam të përdorim Amcheck, një shtesë e krijuar nga komuniteti, për të gjetur shkelje të pandryshueshme në indekse.
Dhe ne zbuluam se nëse e përdorni atë në shkallë, ka defekte. Ne filluam t'i rregullojmë ato. Korrigjimet tona janë pranuar.
Zbuluam se kjo shtesë nuk mund të analizojë indekset GiST & GIT. Ne i bëmë ata të mbështesin. Por kjo mbështetje është ende duke u diskutuar nga komuniteti, sepse ky është një funksionalitet relativisht i ri dhe aty ka shumë detaje.
Dhe zbuluam gjithashtu se kur kontrollojmë indekset për shkelje në drejtuesin e replikimit, në master, gjithçka funksionon mirë, por në kopjet, tek ndjekësi, kërkimi për korrupsion nuk është aq efektiv. Jo të gjitha invariantet janë kontrolluar. Dhe një invariant na shqetësoi shumë. Dhe kaluam një vit e gjysmë duke komunikuar me komunitetin për të mundësuar këtë kontroll mbi kopjet.
Ne kemi shkruar kodin që duhet të ndjekë të gjitha protokollet... Ne e diskutuam këtë patch për mjaft kohë me Peter Gaghan nga Crunchy Data. Ai duhej të modifikonte pak pemën B ekzistuese në Postgres në mënyrë që të pranonte këtë copëz. Ai u pranua. Dhe tani kontrollimi i indekseve në kopje është bërë gjithashtu mjaft efektiv për të zbuluar shkeljet që kemi hasur. Kjo do të thotë, këto janë shkeljet që mund të shkaktohen nga gabimet në firmuerin e diskut, gabimet në Postgres, gabimet në kernelin Linux dhe problemet e harduerit. Një listë mjaft e gjerë e burimeve të problemeve për të cilat po përgatiteshim.
Por përveç indekseve, ekziston një pjesë e tillë si grumbulli, d.m.th. vendi ku ruhen të dhënat. Dhe nuk ka shumë të pandryshueshme që mund të kontrollohen.
Ne kemi një shtesë të quajtur Heapcheck. Ne filluam ta zhvillojmë atë. Dhe paralelisht, së bashku me ne, kompania EnterpriseDB gjithashtu filloi të shkruante një modul, të cilin e quajtën Heapcheck në të njëjtën mënyrë. Vetëm ne e quajtëm PgHeapcheck, dhe ata thjesht e quajtën Heapcheck. E kanë me funksione të ngjashme, një firmë paksa të ndryshme, por me të njëjtat ide. Ata i zbatuan pak më mirë në disa vende. Dhe ata e postuan atë në burim të hapur më parë.
Dhe tani po zhvillojmë zgjerimin e tyre, sepse nuk është më zgjerimi i tyre, por zgjerimi i komunitetit. Dhe në të ardhmen, kjo është pjesë e kernelit që do t'u ofrohet të gjithëve në mënyrë që ata të mund të dinë paraprakisht për problemet e ardhshme.
Madje, në disa vende kemi arritur në përfundimin se kemi false pozitive në sistemet tona të monitorimit. Për shembull, sistemi 1C. Kur përdor një bazë të dhënash, Postgres ndonjëherë shkruan në të të dhëna që mund t'i lexojë, por pg_dump nuk mund t'i lexojë.
Kjo situatë dukej si korrupsion për sistemin tonë të zbulimit të problemeve. Oficeri i shërbimit u zgjua. Oficeri i detyrës shikoi se çfarë po ndodhte. Pas ca kohësh erdhi një klient dhe më tha se kisha probleme. Punonjësi shpjegoi se cili ishte problemi. Por problemi është në thelbin e Postgres.
Gjeta një diskutim për këtë veçori. Dhe ai shkroi se ne hasëm këtë veçori dhe ishte e pakëndshme, një person u zgjua natën për të kuptuar se çfarë ishte.
Komuniteti u përgjigj: "Oh, ne me të vërtetë duhet ta rregullojmë atë."
Unë kam një analogji të thjeshtë. Nëse po ecni në një këpucë që ka një kokërr rërë në të, atëherë, në parim, mund të vazhdoni - nuk ka problem. Nëse u shet çizme mijëra njerëzve, atëherë le të bëjmë çizme pa rërë fare. Dhe nëse një nga përdoruesit e këpucëve tuaja do të vrapojë një maratonë, atëherë ju dëshironi të bëni këpucë shumë të mira dhe më pas t'i shkallëzoni ato për të gjithë përdoruesit tuaj. Dhe përdorues të tillë të papritur janë gjithmonë në mjedisin cloud. Gjithmonë ka përdorues që shfrytëzojnë grupin në një mënyrë origjinale. Ju gjithmonë duhet të përgatiteni për këtë.
Çfarë kemi mësuar këtu? Mësuam një gjë të thjeshtë: gjëja më e rëndësishme është t'i shpjegojmë komunitetit se ka një problem. Nëse komuniteti e ka njohur problemin, atëherë lind konkurrenca natyrore për zgjidhjen e problemit. Sepse të gjithë duan të zgjidhin një problem të rëndësishëm. Të gjithë shitësit, të gjithë hakerët e kuptojnë se ata vetë mund të shkelin këtë grabujë, ndaj duan t'i eliminojnë.
Nëse jeni duke punuar për një problem, por ai nuk shqetëson askënd përveç jush, por e punoni në mënyrë sistematike dhe në fund të fundit konsiderohet si problem, atëherë kërkesa juaj për tërheqje do të pranohet patjetër. Patch-i juaj do të pranohet, përmirësimet tuaja apo edhe kërkesat për përmirësime do të shqyrtohen nga komuniteti. Në fund të fundit, ne e bëjmë bazën e të dhënave më të mirë për njëri-tjetrin.
Një bazë të dhënash interesante është Greenplum. Është një bazë të dhënash shumë paralele e bazuar në bazën e kodeve Postgres, me të cilën jam shumë i njohur.
Dhe Greenplum ka funksionalitet interesant - shtoni tabela të optimizuara. Këto janë tabela që mund t'i shtoni shpejt. Ato mund të jenë ose kolone ose rreshtore.
Por nuk kishte asnjë grupim, d.m.th. nuk kishte funksionalitet ku mund të rregulloni të dhënat e vendosura në tabelë në përputhje me rendin që është në një nga indekset.
Djemtë nga taksia erdhën tek unë dhe më thanë: “Andrey, ti e njeh Postgresin. Dhe këtu është pothuajse e njëjta gjë. Kaloni në 20 minuta. Merre dhe bëje”. Mendova se po, e njoh Postgres, duke kaluar për 20 minuta - duhet ta bëj këtë.
Por jo, nuk ishin 20 minuta, e shkrova me muaj. Në konferencën PgConf.Russia, iu afrova Heikki Linakangas nga Pivotal dhe pyeta: “A ka ndonjë problem me këtë? Pse nuk ka një grupim të optimizuar të tabelave shtesë?” Ai thotë: “Ti merr të dhënat. Ju renditni, ju riorganizoni. Është thjesht një punë”. Unë: "Oh, po, thjesht duhet ta marrësh dhe ta bësh." Ai thotë: "Po, ne kemi nevojë për duar të lira për ta bërë këtë." Mendova se duhet ta bëj këtë patjetër.
Dhe disa muaj më vonë unë paraqita një kërkesë tërheqëse që zbatonte këtë funksionalitet. Kjo kërkesë për tërheqje u shqyrtua nga Pivotal së bashku me komunitetin. Sigurisht, kishte defekte.
Por gjëja më interesante është se kur kjo kërkesë tërheqëse u shkri, u gjetën gabime në vetë Greenplum. Kemi zbuluar se tabelat e grumbullit ndonjëherë prishin transaksionalitetin kur grupohen. Dhe kjo është një gjë që duhet rregulluar. Dhe ajo është në vendin që sapo e preka. Dhe reagimi im i natyrshëm ishte - në rregull, më lejoni ta bëj edhe këtë.
E rregullova këtë gabim. Dërgoi një kërkesë tërheqjeje te fiksuesit. Ai u vra.
Pas së cilës rezultoi se ky funksionalitet duhet të merret në versionin Greenplum për PostgreSQL 12. Domethënë, aventura 20-minutëshe vazhdon me aventura të reja interesante. Ishte interesante të prekja zhvillimin aktual, ku komuniteti po pret veçori të reja dhe më të rëndësishme. Është ngrirë.
Por nuk mbaroi me kaq. Në fund të fundit, doli që na duhej të shkruanim dokumentacion për të gjithë këtë.
Fillova të shkruaj dokumente. Për fat, dokumentarët nga Pivotal erdhën. Anglishtja është gjuha e tyre amtare. Më ndihmuan me dokumentacionin. Në fakt, ata vetë e rishkruan atë që propozova në anglisht të vërtetë.
Dhe këtu, me sa duket, aventura mbaroi. Dhe a e dini se çfarë ndodhi atëherë? Djemtë nga taksia erdhën tek unë dhe më thanë: "Ka ende dy aventura, secila për 10 minuta." Dhe çfarë duhet t'u them atyre? Unë thashë që tani do të jap një raport në shkallë, pastaj do të shohim aventurat tuaja, sepse kjo është një punë interesante.
Çfarë mësuam nga ky rast? Për shkak se të punosh me burim të hapur është gjithmonë të punosh me një person specifik, është gjithmonë të punosh me komunitetin. Sepse në çdo fazë kam punuar me disa zhvillues, disa testues, disa haker, disa dokumentarë, disa arkitektë. Unë nuk kam punuar me Greenplum, kam punuar me njerëz rreth Greenplum.
Por! Ekziston një pikë tjetër e rëndësishme - është vetëm punë. Dmth vini, pini kafe, shkruani kod. Të gjitha llojet e invarianteve të thjeshta funksionojnë. Bëni atë normalisht - do të jetë mirë! Dhe është një punë mjaft interesante. Ka një kërkesë për këtë punë nga klientët Yandex.Cloud, përdorues të grupimeve tona brenda dhe jashtë Yandex. Dhe mendoj se do të rritet numri i projekteve në të cilat ne marrim pjesë dhe do të rritet edhe thellësia e përfshirjes sonë.
Kjo eshte e gjitha. Le të kalojmë te pyetjet.
Sesioni i pyetjeve
Përshëndetje! Kemi një seancë tjetër pyetje-përgjigje. Dhe në studio Andrei Borodin. Ky është personi që sapo ju tregoi për kontributin e Yandex.Cloud dhe Yandex në burim të hapur. Raporti ynë tani nuk ka të bëjë tërësisht me Cloud-in, por në të njëjtën kohë ne jemi të bazuar në teknologji të tilla. Pa atë që bëtë brenda Yandex, nuk do të kishte asnjë shërbim në Yandex.Cloud, kështu që ju falënderoj nga unë personalisht. Dhe pyetja e parë nga transmetimi: “Për çfarë është shkruar secili nga projektet që përmendët?”
Sistemi rezervë në WAL-G është shkruar në Go. Ky është një nga projektet më të reja që kemi punuar. Ai është fjalë për fjalë vetëm 3 vjeç. Dhe një bazë të dhënash shpesh ka të bëjë me besueshmërinë. Dhe kjo do të thotë se bazat e të dhënave janë mjaft të vjetra dhe zakonisht shkruhen në C. Projekti Postgres filloi rreth 30 vjet më parë. Atëherë C89 ishte zgjedhja e duhur. Dhe Postgres është shkruar në të. Bazat e të dhënave më moderne si ClickHouse zakonisht shkruhen në C++. I gjithë zhvillimi i sistemit bazohet rreth C dhe C++.
Një pyetje nga menaxheri ynë financiar, i cili është përgjegjës për shpenzimet në Cloud: "Pse Cloud shpenzon para për mbështetjen e burimit të hapur?"
Këtu ka një përgjigje të thjeshtë për menaxherin financiar. Ne e bëjmë këtë për t'i përmirësuar shërbimet tona. Në çfarë mënyrash mund të bëjmë më mirë? Ne mund t'i bëjmë gjërat në mënyrë më efikase, më të shpejtë dhe t'i bëjmë gjërat më të shkallëzueshme. Por për ne, kjo histori ka të bëjë kryesisht me besueshmërinë. Për shembull, në një sistem rezervë ne shqyrtojmë 100% të arnimeve që zbatohen për të. Ne e dimë se cili është kodi. Dhe ne jemi më të kënaqur të nxjerrim versione të reja në prodhim. Kjo do të thotë, para së gjithash, bëhet fjalë për besimin, për gatishmërinë për zhvillim dhe për besueshmërinë
Një pyetje tjetër: "A janë kërkesat e përdoruesve të jashtëm që jetojnë në Yandex.Cloud të ndryshme nga përdoruesit e brendshëm që jetojnë në renë e brendshme?"
Profili i ngarkesës është, natyrisht, i ndryshëm. Por nga këndvështrimi i departamentit tim, të gjitha rastet e veçanta dhe interesante krijohen me një ngarkesë jo standarde. Zhvilluesit me imagjinatë, zhvilluesit që bëjnë të papriturën, ka të ngjarë të gjenden brenda dhe jashtë. Në këtë drejtim, të gjithë jemi afërsisht të njëjtë. Dhe, ndoshta, e vetmja veçori e rëndësishme brenda funksionimit Yandex të bazave të të dhënave do të jetë që brenda Yandex të kemi një mësim. Në një moment, një zonë e disponueshmërisë shkon plotësisht në hije, dhe të gjitha shërbimet Yandex duhet disi të vazhdojnë të funksionojnë pavarësisht kësaj. Ky është një ndryshim i vogël. Por krijon shumë zhvillime kërkimore në ndërfaqen e bazës së të dhënave dhe grumbullit të rrjetit. Përndryshe, instalimet e jashtme dhe të brendshme gjenerojnë të njëjtat kërkesa për veçori dhe kërkesa të ngjashme për të përmirësuar besueshmërinë dhe performancën.
Pyetja tjetër: "Si ndiheni ju personalisht për faktin se shumica e asaj që bëni përdoret nga Retë e tjera?" Ne nuk do të përmendim ato specifike, por shumë projekte që janë bërë në Yandex.Cloud përdoren në retë e njerëzve të tjerë.
Kjo është e lezetshme. Së pari, është një shenjë se ne kemi bërë diçka të drejtë. Dhe gërvisht egon. Dhe ne jemi më të sigurt se kemi marrë vendimin e duhur. Nga ana tjetër, kjo është shpresa që në të ardhmen kjo të na sjellë ide të reja, kërkesa të reja nga përdoruesit e palëve të treta. Shumica e çështjeve në GitHub krijohen nga administratorë individualë të sistemit, DBA individuale, arkitektë individualë, inxhinierë individualë, por ndonjëherë vijnë njerëz me përvojë sistematike dhe thonë se në 30% të rasteve të caktuara e kemi këtë problem dhe le të mendojmë se si ta zgjidhim atë. Kjo është ajo që ne po presim më shumë. Mezi presim të ndajmë përvojat me platformat e tjera cloud.
Ju folët shumë për maratonën. E di që keni vrapuar në një maratonë në Moskë. Si rezultat? I kapërceu djemtë nga PostgreSQL?
Jo, Oleg Bartunov vrapon shumë shpejt. Ai përfundoi një orë përpara meje. Në përgjithësi, jam i kënaqur me atë se sa larg kam arritur. Për mua, vetëm përfundimi ishte një arritje. Në përgjithësi, është e habitshme që ka kaq shumë vrapues në komunitetin postgres. Më duket se ekziston një lloj marrëdhënieje midis sporteve aerobike dhe dëshirës për programimin e sistemeve.
A po thoni se nuk ka vrapues në ClickHouse?
Unë e di me siguri se ata janë atje. ClickHouse është gjithashtu një bazë të dhënash. Nga rruga, Oleg tani po më shkruan: "A duhet të shkojmë për një vrap pas raportit?" Kjo është një ide e madhe.
Një pyetje tjetër nga transmetimi nga Nikita: "Pse e rregulluat vetë defektin në Greenplum dhe nuk ua jepni juniorëve?" Vërtetë, nuk është shumë e qartë se çfarë është gabimi dhe në cilin shërbim, por me siguri do të thotë atë për të cilin folët.
Po, në parim, mund t'i ishte dhënë dikujt. Ishte vetëm kodi që sapo ndryshova. Dhe ishte e natyrshme të vazhdoja ta bëja menjëherë. Në parim, ideja e ndarjes së ekspertizës me ekipin është një ide e mirë. Ne patjetër do të ndajmë detyrat e Greenplum me të gjithë anëtarët e divizionit tonë.
Meqenëse po flasim për juniorët, ja një pyetje. Personi vendosi të krijojë komitetin e parë në Postgres. Çfarë duhet të bëjë ai për të bërë angazhimin e parë?
Kjo është një pyetje interesante: "Ku të fillojë?" Zakonisht është mjaft e vështirë të fillosh me diçka në kernel. Në Postgres, për shembull, ekziston një listë për të bërë. Por në fakt, kjo është një fletë e asaj që ata u përpoqën të bënin, por nuk ia dolën. Këto janë gjëra të komplikuara. Dhe zakonisht mund të gjeni disa shërbime në ekosistem, disa zgjerime që mund të përmirësohen, që tërheqin më pak vëmendje nga zhvilluesit e kernelit. Dhe, në përputhje me rrethanat, ka më shumë pikë për rritje atje. Në programin Google Summer of code, çdo vit komuniteti postgres parashtron shumë tema të ndryshme që mund të trajtohen. Këtë vit kemi pasur, mendoj, tre studentë. Njëri madje shkroi në WAL-G për tema që janë të rëndësishme për Yandex. Në Greenplum, gjithçka është më e thjeshtë se në komunitetin Postgres, sepse hakerët e Greenplum i trajtojnë shumë mirë kërkesat për tërheqje dhe fillojnë t'i shqyrtojnë menjëherë. Dërgimi i një patch në Postgres është çështje muajsh, por Greenplum do të vijë brenda një dite dhe do të shohë se çfarë keni bërë. Një tjetër gjë është se Greenplum duhet të zgjidhë problemet aktuale. Greenplum nuk përdoret gjerësisht, kështu që gjetja e problemit tuaj është mjaft e vështirë. Dhe para së gjithash, ne duhet të zgjidhim problemet, natyrisht.
Burimi: www.habr.com