Ang kontribusyon ng Yandex sa mga sumusunod na database ay susuriin.
- clickhouse
- Odisea
- Pagbawi sa isang punto sa oras (WAL-G)
- PostgreSQL (kabilang ang mga logerror, Amcheck, heapcheck)
- Greenplum
Video:
Hello mundo! Ang pangalan ko ay Andrey Borodin. At ang ginagawa ko sa Yandex.Cloud ay bumuo ng mga bukas na relational database sa interes ng mga kliyente ng Yandex.Cloud at Yandex.Cloud.
Sa pag-uusap na ito, pag-uusapan natin ang mga hamon na kinakaharap ng mga bukas na database sa sukat. Bakit ito mahalaga? Dahil maliit, maliliit na problema na, tulad ng mga lamok, pagkatapos ay nagiging mga elepante. Lumalaki sila kapag marami kang kumpol.
Ngunit hindi iyon ang pangunahing bagay. Hindi kapani-paniwalang mga bagay ang nangyayari. Mga bagay na nangyayari sa isa sa isang milyong kaso. At sa isang cloud environment, kailangan mong maging handa para doon, dahil ang mga hindi kapani-paniwalang bagay ay nagiging mataas ang posibilidad kapag mayroong isang bagay sa sukat.
Ngunit! Ano ang bentahe ng bukas na mga database? Ang katotohanan ay mayroon kang teoretikal na pagkakataon upang harapin ang anumang problema. Mayroon kang source code, mayroon kang kaalaman sa programming. Pinagsasama namin ito at ito ay gumagana.
Anong mga diskarte ang mayroon sa pagtatrabaho sa open source software?
- Ang pinakasimpleng diskarte ay ang paggamit ng software. Kung gumagamit ka ng mga protocol, kung gumagamit ka ng mga pamantayan, kung gumagamit ka ng mga format, kung nagsusulat ka ng mga query sa open source software, pagkatapos ay sinusuportahan mo na ito.
- Pinapalaki mo ang ecosystem nito. Ginagawa mong mas malaki ang posibilidad ng maagang pagtuklas ng isang bug. Pinapataas mo ang pagiging maaasahan ng sistemang ito. Pinapataas mo ang pagkakaroon ng mga developer sa merkado. Pagbutihin mo ang software na ito. Isa ka nang kontribyutor kung gumawa ka lang ng istilo at nag-iisip ng isang bagay doon.
- Ang isa pang naiintindihan na diskarte ay ang pag-sponsor ng open source software. Halimbawa, ang kilalang Google Summer of Code program, kapag binayaran ng Google ang isang malaking bilang ng mga mag-aaral mula sa buong mundo, maliwanag na pera upang bumuo sila ng mga bukas na proyekto ng software na nakakatugon sa ilang partikular na kinakailangan sa paglilisensya.
- Ito ay isang napaka-kagiliw-giliw na diskarte dahil pinapayagan nito ang software na mag-evolve nang hindi inililipat ang focus mula sa komunidad. Ang Google, bilang isang higanteng teknolohiya, ay hindi nagsasabi na gusto namin ang tampok na ito, gusto naming ayusin ang bug na ito at dito kailangan naming maghukay. Sabi ng Google: βGawin mo ang ginagawa mo. Ipagpatuloy mo lang ang trabaho sa paraang ginawa mo at magiging maayos ang lahat."
- Ang susunod na diskarte sa paglahok sa open source ay pakikilahok. Kapag mayroon kang problema sa open source software at may mga developer, magsisimulang lutasin ng iyong mga developer ang mga problema. Sinimulan nilang gawing mas mahusay ang iyong imprastraktura, mas mabilis at mas maaasahan ang iyong mga programa.
Ang isa sa mga pinakatanyag na proyekto ng Yandex sa larangan ng open source software ay ang ClickHouse. Ito ay isang database na isinilang bilang tugon sa mga hamon na kinakaharap ng Yandex.Metrica.
At bilang isang database, ginawa ito sa open source upang lumikha ng isang ecosystem at bumuo nito kasama ng iba pang mga developer (hindi lamang sa loob ng Yandex). At ngayon ito ay isang malaking proyekto kung saan maraming iba't ibang mga kumpanya ang kasangkot.
Sa Yandex.Cloud, gumawa kami ng ClickHouse sa ibabaw ng Yandex Object Storage, ibig sabihin, sa ibabaw ng cloud storage.
Bakit ito mahalaga sa ulap? Dahil gumagana ang anumang database sa tatsulok na ito, sa pyramid na ito, sa hierarchy na ito ng mga uri ng memorya. Mayroon kang mabilis ngunit maliliit na rehistro at murang malaki ngunit mabagal na SSD, hard drive at ilang iba pang mga block device. At kung ikaw ay mahusay sa tuktok ng pyramid, pagkatapos ay mayroon kang isang mabilis na database. kung ikaw ay mahusay sa ilalim ng pyramid na ito, kung gayon mayroon kang isang naka-scale na database. At sa bagay na ito, ang pagdaragdag ng isa pang layer mula sa ibaba ay isang lohikal na diskarte sa pagtaas ng scalability ng database.
Paano ito magagawa? Ito ay isang mahalagang punto sa ulat na ito.
- Maaari naming ipatupad ang ClickHouse sa MDS. Ang MDS ay isang panloob na interface ng imbakan ng ulap ng Yandex. Ito ay mas kumplikado kaysa sa karaniwang S3 protocol, ngunit ito ay mas angkop para sa isang block device. Ito ay mas mahusay para sa pagtatala ng data. Nangangailangan ito ng higit pang programming. Magpo-program ang mga programmer, maganda pa nga, kawili-wili.
- Ang S3 ay isang mas karaniwang diskarte na ginagawang mas simple ang interface sa halaga ng mas kaunting pagbagay sa ilang uri ng mga workload.
Natural, sa kagustuhang magbigay ng functionality sa buong ClickHouse ecosystem at gawin ang gawain na kailangan sa loob ng Yandex.Cloud, nagpasya kaming tiyaking makikinabang dito ang buong komunidad ng ClickHouse. Ipinatupad namin ang ClickHouse sa S3, hindi ClickHouse sa MDS. At ito ay maraming trabaho.
Link:
"Filesystem abstraction layer"
"Pagsasama ng AWS SDK S3"
"Base na pagpapatupad ng IDisk interafce para sa S3"
"Pagsasama ng mga log storage engine na may interface ng IDisk"
"Suporta sa log engine para sa S3 at SeekableReadBuffer"
"Suporta sa Storage Stripe Log S3"
"Paunang suporta ng Storage MergeTree para sa S3"
"Buong suporta ng MergeTree para sa S3"
"Suportahan ang ReplicatedMergeTree sa S3"
"Magdagdag ng mga default na kredensyal at custom na header para sa s3 storage"
"S3 na may dynamic na proxy configuration"
"S3 na may proxy resolver"
Isa itong listahan ng pull request para sa pagpapatupad ng virtual file system sa ClickHouse. Ito ay isang malaking bilang ng mga pull request.
Link:
"Ang pinakamainam na pagpapatupad ng mga hardlink ng DiskS3"
βS3 HTTP client β Iwasan ang pagkopya ng response stream sa memoryaβ
βIwasang kopyahin ang buong stream ng tugon sa memorya sa S3 HTTP
kliyente"
"Kakayahang mag-cache ng marka at mag-index ng mga file para sa S3 disk"
"Ilipat ang mga bahagi mula sa DiskLocal patungo sa DiskS3 nang magkatulad"
Ngunit ang gawain ay hindi natapos doon. Pagkatapos gawin ang feature, kailangan pa ng ilang trabaho para ma-optimize ang functionality na ito.
Link:
"Magdagdag ng SelectedRows at SelectedBytes na mga kaganapan"
"Magdagdag ng mga kaganapan sa pag-profile mula sa kahilingan ng S3 sa system.events"
"Magdagdag ng QueryTimeMicroseconds, SelectQueryTimeMicroseconds at InsertQueryTimeMicroseconds"
At pagkatapos ay kinakailangan na gawin itong masuri, i-set up ang pagsubaybay at gawin itong mapapamahalaan.
At lahat ng ito ay ginawa upang ang buong komunidad, ang buong ClickHouse ecosystem, ay nakatanggap ng resulta ng gawaing ito.
Lumipat tayo sa mga database ng transaksyon, sa mga database ng OLTP, na mas malapit sa akin nang personal.
Ito ang open source DBMS development division. Gumagawa ang mga taong ito ng magic sa kalye para mapabuti ang mga transactional open database.
Ang isa sa mga proyekto, gamit ang isang halimbawa kung saan maaari nating pag-usapan kung paano at kung ano ang ginagawa natin, ay ang Connection Pooler sa Postgres.
Ang mga postgres ay isang database ng proseso. Nangangahulugan ito na ang database ay dapat magkaroon ng kaunting mga koneksyon sa network hangga't maaari na humahawak ng mga transaksyon.
Sa kabilang banda, sa isang cloud environment, ang isang tipikal na sitwasyon ay kapag ang isang libong koneksyon ay dumating sa isang cluster nang sabay-sabay. At ang gawain ng connection pooler ay mag-pack ng isang libong koneksyon sa isang maliit na bilang ng mga koneksyon sa server.
Masasabi natin na ang connection pooler ay ang operator ng telepono na muling nag-aayos ng mga byte upang mahusay nilang maabot ang database.
Sa kasamaang palad, walang magandang salitang Ruso para sa pooler ng koneksyon. Minsan tinatawag itong multiplexer connections. Kung alam mo kung ano ang tawag sa pooler ng koneksyon, siguraduhing sabihin sa akin, ikalulugod kong magsalita ng tamang teknikal na wikang Ruso.
Inimbestigahan namin ang mga pooler ng koneksyon na angkop para sa isang pinamamahalaang postgres cluster. At ang PgBouncer ang pinakamagandang pagpipilian para sa amin. Ngunit nakatagpo kami ng ilang problema sa PgBouncer. Maraming taon na ang nakalilipas, nagbigay si Volodya Borodin ng mga ulat na ginagamit namin ang PgBouncer, gusto namin ang lahat, ngunit may mga nuances, mayroong isang bagay na dapat gawin.
At nagtrabaho kami. Inayos namin ang mga problemang naranasan namin, nag-patch kami ng Bouncer, at sinubukang i-push ang mga pull request upstream. Ngunit ang pangunahing single-threading ay mahirap gamitin.
Kinailangan naming mangolekta ng mga cascades mula sa mga patched Bouncers. Kapag marami kaming single-threaded na Bouncer, ang mga koneksyon sa itaas na layer ay ililipat sa inner layer ng Bouncers. Ito ay isang sistemang hindi maayos na pinamamahalaan na mahirap buuin at sukatin pabalik-balik.
Nakarating kami sa konklusyon na lumikha kami ng aming sariling pooler ng koneksyon, na tinatawag na Odyssey. Sinulat namin ito mula sa simula.
Noong 2019, sa kumperensya ng PgCon, ipinakita ko ang pooler na ito sa komunidad ng developer. Ngayon ay mayroon na kaming mas mababa sa 2 bituin sa GitHub, ibig sabihin, buhay ang proyekto, sikat ang proyekto.
At kung gagawa ka ng isang Postgres cluster sa Yandex.Cloud, ito ay magiging isang cluster na may built-in na Odyssey, na muling na-configure kapag sinusuri ang cluster pabalik o pabalik.
Ano ang natutunan natin sa proyektong ito? Ang paglulunsad ng isang nakikipagkumpitensyang proyekto ay palaging isang agresibong hakbang, ito ay isang matinding panukala kapag sinabi natin na may mga problemang hindi nareresolba nang mabilis, hindi nareresolba sa mga agwat ng oras na angkop sa atin. Ngunit ito ay isang epektibong panukala.
Ang PgBouncer ay nagsimulang umunlad nang mas mabilis.
At ngayon lumitaw ang iba pang mga proyekto. Halimbawa, ang pgagroal, na binuo ng mga developer ng Red Hat. Hinahabol nila ang mga katulad na layunin at nagpapatupad ng mga katulad na ideya, ngunit, siyempre, sa kanilang sariling mga detalye, na mas malapit sa mga developer ng pgagroal.
Ang isa pang kaso ng pakikipagtulungan sa komunidad ng postgres ay pagpapanumbalik sa isang punto sa oras. Ito ay pagbawi pagkatapos ng isang pagkabigo, ito ay pagbawi mula sa isang backup.
Mayroong maraming mga backup at lahat sila ay naiiba. Halos bawat Postgres vendor ay may sariling backup na solusyon.
Kung kukunin mo ang lahat ng mga backup system, lumikha ng isang tampok na matrix at pabirong kalkulahin ang determinant sa matrix na ito, ito ay magiging zero. Ano ang ibig sabihin nito? Paano kung kumuha ka ng isang tiyak na backup na file, kung gayon hindi ito maaaring tipunin mula sa mga piraso ng lahat ng iba pa. Ito ay natatangi sa pagpapatupad nito, natatangi sa layunin nito, natatangi sa mga ideyang nakapaloob dito. At lahat sila ay tiyak.
Habang ginagawa namin ang isyung ito, inilunsad ng CitusData ang proyektong WAL-G. Ito ay isang backup system na ginawa gamit ang isang mata sa cloud environment. Ngayon ang CitusData ay bahagi na ng Microsoft. At sa sandaling iyon, talagang nagustuhan namin ang mga ideyang inilatag sa mga unang paglabas ng WAL-G. At nagsimula kaming mag-ambag sa proyektong ito.
Ngayon ay mayroong maraming dose-dosenang mga developer sa proyektong ito, ngunit ang nangungunang 10 na nag-ambag sa WAL-G ay may kasamang 6 na Yandexoids. Dinala namin ang marami sa aming mga ideya doon. At, siyempre, ipinatupad namin ang mga ito sa aming sarili, sinubukan ang mga ito sa aming sarili, inilunsad ang mga ito sa produksyon, kami mismo ang gumagamit ng mga ito, kami mismo ang nag-iisip kung saan susunod na lilipat, habang nakikipag-ugnayan sa malaking komunidad ng WAL-G.
At mula sa aming pananaw, ngayon ang backup system na ito, kabilang ang pagsasaalang-alang sa aming mga pagsisikap, ay naging pinakamainam para sa isang cloud environment. Ito ang pinakamagandang gastos sa pag-back up ng mga Postgres sa cloud.
Ano ang ibig sabihin nito? Nagsusulong kami ng isang medyo malaking ideya: ang backup ay dapat na ligtas, murang patakbuhin at sa pinakamabilis na paraan upang maibalik.
Bakit dapat mura ang pagpapatakbo? Kapag walang sira, hindi mo dapat alam na mayroon kang mga backup. Gumagana nang maayos ang lahat, nag-aaksaya ka ng kaunting CPU hangga't maaari, gumagamit ka ng kaunting mga mapagkukunan ng iyong disk hangga't maaari, at nagpapadala ka ng kaunting byte sa network hangga't maaari upang hindi makagambala sa payload ng iyong mahahalagang serbisyo.
At kapag nasira ang lahat, halimbawa, ang admin ay nag-drop ng data, may nangyaring mali, at kailangan mong mapilit na bumalik sa nakaraan, bumawi ka sa lahat ng pera, dahil gusto mong mabilis at buo ang iyong data.
At isinulong namin ang simpleng ideyang ito. At, tila sa amin, nagawa naming ipatupad ito.
Ngunit hindi lang iyon. Gusto namin ng isa pang maliit na bagay. Gusto namin ng maraming iba't ibang database. Hindi lahat ng aming mga kliyente ay gumagamit ng Postgres. Ang ilang mga tao ay gumagamit ng MySQL, MongoDB. Sa komunidad, sinusuportahan ng ibang mga developer ang FoundationDB. At ang listahang ito ay patuloy na lumalawak.
Gusto ng komunidad ang ideya ng database na pinapatakbo sa isang pinamamahalaang kapaligiran sa cloud. At pinapanatili ng mga developer ang kanilang mga database, na maaaring i-back up nang pantay-pantay kasama ng mga Postgres sa aming backup system.
Ano ang natutunan natin sa kwentong ito? Ang aming produkto, bilang isang development division, ay hindi mga linya ng code, hindi ito mga pahayag, hindi ito mga file. Ang aming produkto ay hindi pull request. Ito ang mga ideyang ipinahahatid namin sa komunidad. Ito ay teknolohikal na kadalubhasaan at ang paggalaw ng teknolohiya patungo sa isang cloud environment.
Mayroong isang database tulad ng Postgres. Pinaka gusto ko ang Postgres core. Gumugugol ako ng maraming oras sa pagbuo ng Postgres core sa komunidad.
Ngunit dito dapat sabihin na ang Yandex.Cloud ay may panloob na pag-install ng mga pinamamahalaang database. At matagal na itong nagsimula sa Yandex.Mail. Ang kadalubhasaan na ngayon ay humantong sa pinamamahalaang mga Postgres ay naipon noong gusto ng mail na lumipat sa Postgres.
Ang mail ay may halos kaparehong mga kinakailangan sa cloud. Kailangan mong ma-scale sa hindi inaasahang exponential growth sa anumang punto sa iyong data. At ang mail ay mayroon nang load na may ilang daang milyong mailbox ng malaking bilang ng mga user na patuloy na gumagawa ng maraming kahilingan.
At ito ay isang seryosong hamon para sa pangkat na bumubuo ng Postgres. Noon, ang anumang problemang naranasan namin ay iniulat sa komunidad. At ang mga problemang ito ay naitama, at naitama ng komunidad sa ilang mga lugar kahit na sa antas ng bayad na suporta para sa ilang iba pang mga database at mas mabuti pa. Iyon ay, maaari kang magpadala ng sulat sa PgSQL hacker at makatanggap ng tugon sa loob ng 40 minuto. Ang bayad na suporta sa ilang mga database ay maaaring isipin na mayroong higit na priyoridad na mga bagay kaysa sa iyong bug.
Ngayon ang panloob na pag-install ng Postgres ay ilang petabytes ng data. Ito ay ilang milyon-milyong mga kahilingan sa bawat segundo. Ito ay libu-libong kumpol. Ito ay napakalaking sukat.
Ngunit mayroong isang nuance. Hindi ito nabubuhay sa magarbong mga drive ng network, ngunit sa medyo simpleng hardware. At mayroong isang pagsubok na kapaligiran partikular para sa mga kawili-wiling bagong bagay.
At sa isang tiyak na sandali sa kapaligiran ng pagsubok nakatanggap kami ng isang mensahe na nagpapahiwatig na ang mga panloob na invariant ng mga index ng database ay nilabag.
Ang isang invariant ay isang uri ng relasyon na inaasahan nating laging hawak.
Isang napaka-kritikal na sitwasyon para sa amin. Ito ay nagpapahiwatig na ang ilang data ay maaaring nawala. At ang pagkawala ng data ay isang bagay na talagang sakuna.
Ang pangkalahatang ideya na sinusunod namin sa mga pinamamahalaang database ay na kahit na may pagsisikap, magiging mahirap na mawalan ng data. Kahit na sinadya mong alisin ang mga ito, kakailanganin mo pa ring balewalain ang kanilang pagkawala sa loob ng mahabang panahon. Ang seguridad ng data ay isang relihiyon na masigasig naming sinusunod.
At dito lumitaw ang isang sitwasyon na nagmumungkahi na maaaring may isang sitwasyon na maaaring hindi tayo handa. At nagsimula kaming maghanda para sa sitwasyong ito.
Ang unang bagay na ginawa namin ay ilibing ang mga troso mula sa libu-libong kumpol na ito. Natagpuan namin kung alin sa mga cluster ang matatagpuan sa mga disk na may problemang firmware na nawawalan ng mga update sa page ng data. Minarkahan ang lahat ng Postgres data code. At minarkahan namin ang mga mensaheng iyon na nagsasaad ng mga paglabag sa mga panloob na invariant gamit ang code na idinisenyo upang makita ang katiwalian ng data.
Ang patch na ito ay halos tinanggap ng komunidad nang walang gaanong talakayan, dahil sa bawat partikular na kaso ay halata na may nangyaring masama at kailangang iulat sa log.
Pagkatapos nito, dumating kami sa punto na mayroon kaming monitoring na nag-scan ng mga log. At sakaling may mga kahina-hinalang mensahe, ginigising niya ang duty officer, at inaayos ito ng duty officer.
Ngunit! Ang pag-scan ng mga log ay isang murang operasyon sa isang kumpol at napakamahal para sa isang libong kumpol.
Sumulat kami ng extension na tinatawag . Lumilikha ito ng view ng database kung saan maaari mong mura at mabilis na pumili ng mga istatistika sa mga nakaraang error. At kung kailangan nating gisingin ang opisyal ng tungkulin, malalaman natin ang tungkol dito nang hindi nag-scan ng mga gigabyte na file, ngunit sa pamamagitan ng pagkuha ng ilang byte mula sa hash table.
Ang extension na ito ay pinagtibay, halimbawa, sa repositoryo para sa . Kung nais mong gamitin ito, maaari mong i-install ito sa iyong sarili. Syempre open source ito.
Ngunit hindi lang iyon. Sinimulan naming gamitin ang Amcheck, isang extension na binuo ng komunidad, upang maghanap ng mga invariant na paglabag sa mga index.
At nalaman namin na kung paandarin mo ito nang malaki, may mga bug. Sinimulan naming ayusin ang mga ito. Ang aming mga pagwawasto ay tinanggap.
Natuklasan namin na hindi masusuri ng extension na ito ang mga index ng GiST at GIT. Ginawa namin silang suporta. Ngunit ang suportang ito ay tinatalakay pa rin ng komunidad, dahil ito ay isang medyo bagong pag-andar at mayroong maraming mga detalye doon.
At natuklasan din namin na kapag sinusuri ang mga index para sa mga paglabag sa pinuno ng pagtitiklop, sa master, lahat ay gumagana nang maayos, ngunit sa mga replika, sa tagasunod, ang paghahanap para sa katiwalian ay hindi gaanong epektibo. Hindi lahat ng invariant ay sinusuri. At isang invariant ang labis na nag-abala sa amin. At gumugol kami ng isang taon at kalahating pakikipag-ugnayan sa komunidad upang mapagana ang pagsusuring ito sa mga replika.
Sumulat kami ng code na dapat sumunod sa lahat ng maaaring... protocol. Tinalakay namin ang patch na ito sa loob ng mahabang panahon kasama si Peter Gaghan mula sa Crunchy Data. Kinailangan niyang bahagyang baguhin ang umiiral na B-tree sa Postgres upang tanggapin ang patch na ito. Tinanggap siya. At ngayon, ang pagsuri sa mga index sa mga replika ay naging sapat na rin upang matukoy ang mga paglabag na aming naranasan. Iyon ay, ito ang mga paglabag na maaaring sanhi ng mga error sa firmware ng disk, mga bug sa Postgres, mga bug sa kernel ng Linux, at mga problema sa hardware. Isang malawak na listahan ng mga pinagmumulan ng mga problema kung saan kami ay naghahanda.
Ngunit bukod sa mga index, mayroong isang bahagi bilang heap, i.e. ang lugar kung saan naka-imbak ang data. At walang maraming invariant na maaaring suriin.
Mayroon kaming extension na tinatawag na Heapcheck. Sinimulan namin itong i-develop. At kahanay, kasama namin, ang kumpanya ng EnterpriseDB ay nagsimula ring magsulat ng isang module, na tinawag nilang Heapcheck sa parehong paraan. Tinawag lang namin itong PgHeapcheck, at tinawag lang nila itong Heapcheck. Mayroon silang katulad na mga pag-andar, isang bahagyang naiibang lagda, ngunit may parehong mga ideya. Ipinatupad nila ang mga ito nang medyo mas mahusay sa ilang mga lugar. At nai-post nila ito sa open source dati.
And now we are develop their expansion, kasi hindi na yung expansion nila, kundi yung expansion ng community. At sa hinaharap, ito ay bahagi ng kernel na ibibigay sa lahat upang malaman nila nang maaga ang tungkol sa mga problema sa hinaharap.
Sa ilang lugar, dumating pa nga kami sa punto na mayroon kaming mga maling positibo sa aming mga sistema ng pagsubaybay. Halimbawa, ang 1C system. Kapag gumagamit ng database, minsan nagsusulat ang Postgres ng data dito na mababasa nito, ngunit hindi mabasa ng pg_dump.
Ang sitwasyong ito ay mukhang katiwalian sa aming sistema ng pagtuklas ng problema. Nagising ang duty officer. Tiningnan ng duty officer ang nangyayari. Pagkaraan ng ilang oras, dumating ang isang kliyente at sinabing may problema ako. Ipinaliwanag ng attendant kung ano ang problema. Ngunit ang problema ay nasa core ng Postgres.
Nakakita ako ng talakayan tungkol sa feature na ito. At isinulat niya na nakatagpo namin ang tampok na ito at ito ay hindi kanais-nais, ang isang tao ay nagising sa gabi upang malaman kung ano ito.
Tumugon ang komunidad, "Naku, kailangan talaga nating ayusin ito."
Mayroon akong isang simpleng pagkakatulad. Kung naglalakad ka sa isang sapatos na may butil ng buhangin sa loob nito, kung gayon, sa prinsipyo, maaari kang magpatuloy - walang problema. Kung nagbebenta ka ng mga bota sa libu-libong tao, gawin natin ang mga bota na walang buhangin. At kung ang isa sa mga gumagamit ng iyong sapatos ay tatakbo sa isang marathon, gusto mong gumawa ng napakagandang sapatos, at pagkatapos ay i-scale ang mga ito sa lahat ng iyong mga user. At ang mga hindi inaasahang user ay palaging nasa cloud environment. Palaging may mga user na nagsasamantala sa cluster sa ilang orihinal na paraan. Kailangan mong laging maghanda para dito.
Ano ang natutunan natin dito? Natutunan namin ang isang simpleng bagay: ang pinakamahalaga ay ipaliwanag sa komunidad na may problema. Kung nakilala ng komunidad ang problema, natural na kumpetisyon ang lumitaw upang malutas ang problema. Dahil ang lahat ay gustong malutas ang isang mahalagang problema. Ang lahat ng mga vendor, lahat ng mga hacker ay nauunawaan na sila mismo ay maaaring makatapak sa rake na ito, kaya gusto nilang alisin ang mga ito.
Kung ikaw ay gumagawa ng isang problema, ngunit ito ay walang sinumang nakakaabala maliban sa iyo, ngunit ikaw ay nagtatrabaho sa sistematikong paraan at ito sa huli ay itinuturing na isang problema, kung gayon ang iyong kahilingan sa paghila ay tiyak na tatanggapin. Ang iyong patch ay tatanggapin, ang iyong mga pagpapabuti o kahit na mga kahilingan para sa mga pagpapabuti ay susuriin ng komunidad. Sa pagtatapos ng araw, ginagawa naming mas mahusay ang database para sa isa't isa.
Ang isang kawili-wiling database ay Greenplum. Ito ay isang mataas na parallel na database batay sa Postgres codebase, na pamilyar sa akin.
At ang Greenplum ay may kawili-wiling pag-andar - idagdag ang mga naka-optimize na talahanayan. Ito ang mga talahanayan na mabilis mong maidaragdag. Maaari silang maging columnar o row.
Ngunit walang clustering, ibig sabihin, walang pag-andar kung saan maaari mong ayusin ang data na matatagpuan sa talahanayan alinsunod sa pagkakasunud-sunod na nasa isa sa mga index.
Lumapit sa akin ang mga lalaki mula sa taxi at sinabing: βAndrey, kilala mo si Postgres. At dito ito ay halos pareho. Lumipat sa 20 minuto. Kunin mo at gawin mo." Naisip ko na oo, alam ko ang mga Postgres, lumilipat sa loob ng 20 minuto - kailangan kong gawin ito.
Ngunit hindi, hindi ito 20 minuto, isinulat ko ito sa loob ng maraming buwan. Sa kumperensya ng PgConf.Russia, nilapitan ko si Heikki Linakangas mula sa Pivotal at nagtanong: βMay problema ba dito? Bakit walang append optimized table clustering?" Sabi niya: "Kunin mo ang data. Umayos ka, ayusin mo. Trabaho lang yan." Ako: "Oh, oo, kailangan mo lang kunin at gawin ito." Sinabi niya: "Oo, kailangan namin ng libreng mga kamay upang gawin ito." Naisip ko na talagang kailangan kong gawin ito.
At pagkalipas ng ilang buwan nagsumite ako ng pull request na nagpatupad ng functionality na ito. Ang kahilingan sa paghila na ito ay sinuri ng Pivotal kasama ng komunidad. Siyempre, may mga bug.
Ngunit ang pinaka-kagiliw-giliw na bagay ay na kapag ang pull request na ito ay pinagsama, ang mga bug ay natagpuan sa Greenplum mismo. Nalaman namin na ang mga heap table kung minsan ay sumisira sa transactionality kapag naka-cluster. At ito ay isang bagay na kailangang ayusin. At siya ay nasa lugar na ngayon ko lang nahawakan. At ang natural kong reaksyon ay β okay, hayaan mo rin akong gawin ito.
Inayos ko ang bug na ito. Nagpadala ng pull request sa mga fixer. Pinatay siya.
Pagkatapos nito, lumabas na ang pagpapaandar na ito ay kailangang makuha sa bersyon ng Greenplum para sa PostgreSQL 12. Ibig sabihin, ang 20 minutong pakikipagsapalaran ay nagpapatuloy sa mga bagong kawili-wiling pakikipagsapalaran. Ito ay kagiliw-giliw na hawakan ang kasalukuyang pag-unlad, kung saan ang komunidad ay pinuputol ang mga bago at pinakamahalagang tampok. Ito ay nagyelo.
Ngunit hindi doon nagtapos. Pagkatapos ng lahat, lumabas na kailangan naming magsulat ng dokumentasyon para sa lahat ng ito.
Nagsimula akong magsulat ng dokumentasyon. Sa kabutihang palad, dumating ang mga dokumentaryo mula sa Pivotal. English ang kanilang katutubong wika. Tinulungan nila ako sa dokumentasyon. Sa katunayan, sila mismo ang sumulat ng aking iminungkahi sa totoong Ingles.
At dito, tila, natapos ang pakikipagsapalaran. At alam mo ba kung ano ang nangyari noon? Lumapit sa akin ang mga lalaki mula sa taxi at nagsabi: "Mayroon pa ring dalawang pakikipagsapalaran, bawat isa sa loob ng 10 minuto." At ano ang dapat kong sabihin sa kanila? Sinabi ko na ngayon ay magbibigay ako ng isang ulat sa sukat, pagkatapos ay makikita natin ang iyong mga pakikipagsapalaran, dahil ito ay isang kawili-wiling trabaho.
Ano ang natutunan natin sa kasong ito? Dahil ang pagtatrabaho sa open source ay palaging nagtatrabaho sa isang partikular na tao, palagi itong nagtatrabaho sa komunidad. Dahil sa bawat yugto ay nagtrabaho ako sa ilang developer, ilang tester, ilang hacker, ilang dokumentaryo, ilang arkitekto. Hindi ako nagtrabaho sa Greenplum, nagtrabaho ako sa mga tao sa paligid ng Greenplum.
Ngunit! May isa pang mahalagang punto - ito ay trabaho lamang. Ibig sabihin, pumunta ka, uminom ng kape, sumulat ng code. Gumagana ang lahat ng uri ng simpleng invariant. Gawin ito nang normal - magiging maayos ito! At ito ay medyo isang kawili-wiling trabaho. Mayroong kahilingan para sa gawaing ito mula sa mga kliyente ng Yandex.Cloud, mga gumagamit ng aming mga cluster sa loob at labas ng Yandex. At sa tingin ko, tataas ang bilang ng mga proyektong ating sasalihan at tataas din ang lalim ng ating pakikisangkot.
Iyon lang. Lumipat tayo sa mga tanong.
Sesyon ng mga tanong
Kamusta! May question and answer session pa tayo. At sa studio Andrei Borodin. Ito ang taong nagsabi sa iyo tungkol sa kontribusyon ng Yandex.Cloud at Yandex sa open source. Ang aming ulat ngayon ay hindi ganap na tungkol sa Cloud, ngunit sa parehong oras kami ay batay sa mga naturang teknolohiya. Kung wala ang ginawa mo sa loob ng Yandex, walang serbisyo sa Yandex.Cloud, kaya salamat sa iyo mula sa akin nang personal. At ang unang tanong mula sa broadcast: "Ano ang nakasulat sa bawat proyekto na iyong binanggit?"
Ang backup system sa WAL-G ay nakasulat sa Go. Ito ay isa sa mga mas bagong proyekto na aming ginawa. Siya ay literal na 3 taong gulang lamang. At ang isang database ay kadalasang tungkol sa pagiging maaasahan. At nangangahulugan ito na medyo luma na ang mga database at kadalasang nakasulat ang mga ito sa C. Nagsimula ang proyekto ng Postgres mga 30 taon na ang nakakaraan. Pagkatapos ay ang C89 ang tamang pagpipilian. At ang mga Postgres ay nakasulat dito. Ang mas modernong mga database tulad ng ClickHouse ay karaniwang nakasulat sa C++. Ang lahat ng pagbuo ng system ay nakabatay sa paligid ng C at C++.
Isang tanong mula sa aming financial manager, na responsable para sa mga gastusin sa Cloud: "Bakit gumagastos ang Cloud ng pera sa pagsuporta sa open source?"
Mayroong isang simpleng sagot para sa tagapamahala ng pananalapi dito. Ginagawa namin ito upang gawing mas mahusay ang aming mga serbisyo. Sa anong mga paraan tayo makakagawa ng mas mahusay? Magagawa natin ang mga bagay nang mas mahusay, mas mabilis, at gawing mas nasusukat ang mga bagay. Ngunit para sa amin, ang kuwentong ito ay pangunahing tungkol sa pagiging maaasahan. Halimbawa, sa isang backup system, sinusuri namin ang 100% ng mga patch na nalalapat dito. Alam namin kung ano ang code. At mas komportable kaming maglunsad ng mga bagong bersyon sa produksyon. Iyon ay, una sa lahat, ito ay tungkol sa kumpiyansa, tungkol sa kahandaan para sa pag-unlad at tungkol sa pagiging maaasahan
Isa pang tanong: "Ang mga kinakailangan ba ng mga external na user na nakatira sa Yandex.Cloud ay iba sa mga internal na user na nakatira sa internal na Cloud?"
Ang load profile, siyempre, iba. Ngunit mula sa punto ng view ng aking departamento, ang lahat ng mga espesyal at kawili-wiling mga kaso ay nilikha sa isang hindi karaniwang pagkarga. Ang mga developer na may imahinasyon, mga developer na gumagawa ng hindi inaasahan, ay malamang na matagpuan sa loob at labas. Sa bagay na ito, lahat tayo ay halos pareho. At, marahil, ang tanging mahalagang tampok sa loob ng pagpapatakbo ng Yandex ng mga database ay na sa loob ng Yandex mayroon kaming pagtuturo. Sa ilang mga punto, ang ilang availability zone ay ganap na napupunta sa anino, at lahat ng mga serbisyo ng Yandex ay dapat na kahit papaano ay patuloy na gumana sa kabila nito. Ito ay isang maliit na pagkakaiba. Ngunit lumilikha ito ng maraming pag-unlad ng pananaliksik sa interface ng database at network stack. Kung hindi, ang mga panlabas at panloob na pag-install ay bumubuo ng parehong mga kahilingan para sa mga tampok at katulad na mga kahilingan para sa pagpapabuti ng pagiging maaasahan at pagganap.
Susunod na tanong: "Ano ang personal mong pakiramdam tungkol sa katotohanan na karamihan sa iyong ginagawa ay ginagamit ng iba pang Ulap?" Hindi namin pangalanan ang mga partikular, ngunit maraming proyekto na ginawa sa Yandex.Cloud ang ginagamit sa mga ulap ng ibang tao.
Ito ay astig. Una, ito ay senyales na may nagawa tayong tama. At kinakalmot nito ang ego. At mas tiwala kami na tama ang naging desisyon namin. Sa kabilang banda, ito ang pag-asa na sa hinaharap ay magdadala ito sa amin ng mga bagong ideya, mga bagong kahilingan mula sa mga user ng third-party. Karamihan sa mga isyu sa GitHub ay nilikha ng mga indibidwal na tagapangasiwa ng system, mga indibidwal na DBA, mga indibidwal na arkitekto, mga indibidwal na inhinyero, ngunit kung minsan ang mga taong may sistematikong karanasan ay dumarating at nagsasabi na sa 30% ng ilang mga kaso mayroon tayong problemang ito at pag-isipan natin kung paano ito lutasin. Ito ang pinakahihintay namin. Inaasahan namin ang pagbabahagi ng mga karanasan sa iba pang mga cloud platform.
Marami kang napag-usapan tungkol sa marathon. Alam ko na nagpatakbo ka ng isang marathon sa Moscow. Ang resulta? Na-overtake ang mga lalaki mula sa PostgreSQL?
Hindi, tumakbo nang napakabilis si Oleg Bartunov. Nauna siyang natapos ng isang oras sa akin. Sa pangkalahatan, masaya ako sa kung gaano kalayo ang narating ko. Para sa akin, ang pagtatapos lamang ay isang tagumpay. Sa pangkalahatan, nakakagulat na napakaraming runner sa postgres community. Tila sa akin ay may ilang uri ng ugnayan sa pagitan ng aerobic sports at ang pagnanais para sa mga system programming.
Sinasabi mo bang walang runner sa ClickHouse?
Alam kong nandoon sila. Ang ClickHouse ay isa ring database. Siya nga pala, sumusulat na sa akin si Oleg: "Tatakbo ba tayo pagkatapos ng ulat?" Ito ay isang magandang ideya.
Ang isa pang tanong mula sa broadcast mula kay Nikita: "Bakit ikaw mismo ang nag-ayos ng bug sa Greenplum at hindi mo ito ibinigay sa mga juniors?" Totoo, hindi masyadong malinaw kung ano ang bug at kung saang serbisyo, ngunit malamang na ang ibig sabihin nito ay ang iyong pinag-usapan.
Oo, sa prinsipyo, ito ay maaaring ibinigay sa isang tao. Iyon lang ang code na binago ko lang. At natural na ipagpatuloy ang paggawa nito kaagad. Sa prinsipyo, ang ideya ng pagbabahagi ng kadalubhasaan sa koponan ay isang magandang ideya. Talagang ibabahagi namin ang mga gawain sa Greenplum sa lahat ng miyembro ng aming dibisyon.
Dahil juniors ang pinag-uusapan, eto ang tanong. Nagpasya ang tao na gumawa ng unang commit sa Postgres. Ano ang kailangan niyang gawin para magawa ang unang commit?
Ito ay isang kawili-wiling tanong: "Saan magsisimula?" Karaniwang mahirap magsimula sa isang bagay sa kernel. Sa Postgres, halimbawa, mayroong listahan ng dapat gawin. Ngunit sa katunayan, ito ay isang sheet ng kung ano ang sinubukan nilang gawin, ngunit hindi nagtagumpay. Ito ay mga kumplikadong bagay. At kadalasan ay makakahanap ka ng ilang utility sa ecosystem, ilang extension na maaaring pahusayin, na hindi gaanong nakakaakit ng atensyon mula sa mga developer ng kernel. At, nang naaayon, mayroong higit pang mga punto para sa paglago doon. Sa Google Summer of code program, bawat taon ang postgres community ay naglalagay ng maraming iba't ibang paksa na maaaring matugunan. Sa taong ito, sa tingin ko, mayroon kaming tatlong estudyante. Nagsulat pa nga ang isa sa WAL-G sa mga paksang mahalaga para sa Yandex. Sa Greenplum, mas simple ang lahat kaysa sa komunidad ng Postgres, dahil napakahusay na tinatrato ng mga hacker ng Greenplum ang mga kahilingan sa pag-pull at nagsimulang mag-review kaagad. Ang pagpapadala ng patch sa Postgres ay ilang buwan lang, ngunit darating ang Greenplum sa isang araw at makikita kung ano ang nagawa mo. Ang isa pang bagay ay kailangan ng Greenplum na lutasin ang mga kasalukuyang problema. Ang Greenplum ay hindi malawakang ginagamit, kaya ang paghahanap ng iyong problema ay medyo mahirap. At una sa lahat, kailangan nating lutasin ang mga problema, siyempre.
Pinagmulan: www.habr.com