Tiks pārskatīts Yandex ieguldījums tālāk norādītajās datubāzēs.
- Noklikšķiniet uz Māja
- Odyssey
- Atgūšana līdz noteiktam brīdim (WAL-G)
- PostgreSQL (tostarp logerrors, Amcheck, heapcheck)
- Greenplum
Video:
Sveika pasaule! Mani sauc Andrejs Borodins. Un tas, ko es daru Yandex.Cloud, ir atvērtu relāciju datubāzu izstrāde Yandex.Cloud un Yandex.Cloud klientu interesēs.
Šajā runā mēs runāsim par problēmām, ar kurām saskaras atvērtās datu bāzes. Kāpēc tas ir svarīgi? Jo mazas, mazas problēmas, kas kā odi pēc tam kļūst par ziloņiem. Tie kļūst lieli, ja jums ir daudz kopu.
Bet tas nav galvenais. Notiek neticamas lietas. Lietas, kas notiek vienā no miljona gadījumu. Un mākoņa vidē jums ir jābūt gatavam tam, jo neticamas lietas kļūst ļoti iespējamas, ja kaut kas pastāv lielā mērogā.
Bet! Kādas ir atvērto datu bāzu priekšrocības? Fakts ir tāds, ka jums ir teorētiska iespēja tikt galā ar jebkuru problēmu. Jums ir pirmkods, jums ir programmēšanas zināšanas. Mēs to apvienojam, un tas darbojas.
Kādas pieejas pastāv, strādājot pie atvērtā pirmkoda programmatūras?
- Vienkāršākā pieeja ir programmatūras izmantošana. Ja izmantojat protokolus, ja izmantojat standartus, ja izmantojat formātus, ja rakstāt vaicājumus atvērtā pirmkoda programmatūrā, tad jūs to jau atbalstāt.
- Jūs padarāt tās ekosistēmu lielāku. Jūs palielināsiet kļūdas agrīnas atklāšanas iespējamību. Jūs palielināsiet šīs sistēmas uzticamību. Jūs palielināt izstrādātāju pieejamību tirgū. Jūs uzlabojat šo programmatūru. Jūs jau esat līdzstrādnieks, ja tikko esat paguvis iegūt stilu un kaut ko izdomāt.
- Vēl viena saprotama pieeja ir atvērtā pirmkoda programmatūras sponsorēšana. Piemēram, labi zināmā Google Summer of Code programma, kad Google lielam skaitam studentu no visas pasaules maksā saprotamu naudu, lai viņi izstrādātu atklātas programmatūras projektus, kas atbilst noteiktām licencēšanas prasībām.
- Šī ir ļoti interesanta pieeja, jo tā ļauj programmatūrai attīstīties, nenovēršot uzmanību no kopienas. Google kā tehnoloģiju gigants nesaka, ka mēs vēlamies šo funkciju, mēs vēlamies izlabot šo kļūdu, un šeit mums ir jārok. Google saka: “Dari to, ko dari. Vienkārši turpiniet strādāt, kā strādājāt, un viss būs kārtībā.
- Nākamā pieeja dalībai atvērtā pirmkoda programmā ir līdzdalība. Ja jums ir problēmas ar atvērtā pirmkoda programmatūru un ir izstrādātāji, jūsu izstrādātāji sāk problēmas risināt. Tie sāk padarīt jūsu infrastruktūru efektīvāku, jūsu programmas ātrākas un uzticamākas.
Viens no slavenākajiem Yandex projektiem atvērtā pirmkoda programmatūras jomā ir ClickHouse. Šī ir datu bāze, kas tika izveidota kā atbilde uz problēmām, ar kurām saskaras Yandex.Metrica.
Un kā datu bāze tā tika izveidota atvērtā pirmkoda veidā, lai izveidotu ekosistēmu un attīstītu to kopā ar citiem izstrādātājiem (ne tikai Yandex). Un tagad šis ir liels projekts, kurā ir iesaistīti daudzi dažādi uzņēmumi.
Vietnē Yandex.Cloud mēs izveidojām ClickHouse virs Yandex Object Storage, t.i., virs mākoņa krātuves.
Kāpēc tas ir svarīgi mākonī? Jo jebkura datu bāze darbojas šajā trīsstūrī, šajā piramīdā, šajā atmiņas tipu hierarhijā. Jums ir ātri, bet mazi reģistri un lēti lieli, bet lēni SSD, cietie diski un dažas citas blokierīces. Un, ja jūs esat efektīvs piramīdas augšpusē, tad jums ir ātra datu bāze. ja esat efektīvs šīs piramīdas apakšā, tad jums ir mērogota datu bāze. Un šajā sakarā cita slāņa pievienošana no apakšas ir loģiska pieeja datu bāzes mērogojamības palielināšanai.
Kā to varēja izdarīt? Tas ir svarīgs punkts šajā ziņojumā.
- Mēs varētu ieviest ClickHouse, izmantojot MDS. MDS ir iekšēja Yandex mākoņa krātuves saskarne. Tas ir sarežģītāks nekā parastais S3 protokols, taču tas ir vairāk piemērots blokierīcei. Tas ir labāks datu ierakstīšanai. Tas prasa vairāk programmēšanas. Programmētāji programmēs, tas ir pat labi, interesanti.
- S3 ir izplatītāka pieeja, kas padara saskarni vienkāršāku, samazinot pielāgošanos noteikta veida darba slodzēm.
Protams, vēloties nodrošināt funkcionalitāti visai ClickHouse ekosistēmai un veikt nepieciešamos uzdevumus Yandex.Cloud iekšienē, mēs nolēmām pārliecināties, ka visa ClickHouse kopiena gūs labumu no tā. Mēs ieviesām ClickHouse, izmantojot S3, nevis ClickHouse, izmantojot MDS. Un tas ir daudz darba.
Saites:
"Failu sistēmas abstrakcijas slānis"
"AWS SDK S3 integrācija"
“IDisk interfeisa bāzes ieviešana S3”
"Žurnālu uzglabāšanas dzinēju integrācija ar IDisk interfeisu"
"Žurnāla dzinēja atbalsts S3 un SeekableReadBuffer"
"Storage Stripe Log S3 atbalsts"
"Storage MergeTree sākotnējais atbalsts S3"
"MergeTree pilnīgs S3 atbalsts"
"Atbalstiet ReplicatedMergeTree, izmantojot S3"
“Pievienot noklusējuma akreditācijas datus un pielāgotas galvenes s3 krātuvei”
"S3 ar dinamisku starpniekservera konfigurāciju"
"S3 ar starpniekservera atrisinātāju"
Šis ir ievilkšanas pieprasījumu saraksts virtuālās failu sistēmas ieviešanai ClickHouse. Tas ir liels skaits izvilkšanas pieprasījumu.
Saites:
"DiskS3 cieto saišu optimāla ieviešana"
"S3 HTTP klients — izvairieties no atbildes straumes kopēšanas atmiņā"
“Izvairieties no visas atbildes straumes kopēšanas S3 HTTP atmiņā
klients"
“Spēja saglabāt kešatmiņu un indeksēt failus S3 diskā”
"Paralēli pārvietot daļas no DiskLocal uz DiskS3"
Bet ar to darbs nebeidzās. Pēc funkcijas izveides bija nepieciešams vēl nedaudz strādāt, lai optimizētu šo funkcionalitāti.
Saites:
"Pievienot SelectedRows un SelectedBytes notikumus"
"Pievienot profilēšanas notikumus no S3 pieprasījuma uz system.events"
"Pievienot QueryTimeMicroseconds, SelectQueryTimeMicroseconds un InsertQueryTimeMicroseconds"
Un tad bija nepieciešams to padarīt diagnosticējamu, izveidot uzraudzību un padarīt to pārvaldāmu.
Un tas viss tika darīts, lai visa kopiena, visa ClickHouse ekosistēma saņemtu šī darba rezultātu.
Pāriesim pie darījumu datu bāzēm, pie OLTP datu bāzēm, kas man personīgi ir tuvākas.
Šī ir atvērtā koda DBVS izstrādes nodaļa. Šie puiši veic ielu maģiju, lai uzlabotu darījumu atvērtās datu bāzes.
Viens no projektiem, izmantojot piemēru, kurā mēs varam runāt par to, kā un ko mēs darām, ir Connection Pooler Postgres.
Postgres ir procesu datu bāze. Tas nozīmē, ka datu bāzei jābūt pēc iespējas mazākam tīkla pieslēgumam, kas apstrādā darījumus.
Savukārt mākoņa vidē tipiska situācija ir, kad vienā klasterī uzreiz nonāk tūkstotis savienojumu. Un savienojumu apkopotāja uzdevums ir iesaiņot tūkstoš savienojumu nelielā skaitā servera savienojumu.
Var teikt, ka savienojumu pūlētājs ir telefona operators, kurš pārkārto baitus tā, lai tie efektīvi nonāktu datu bāzē.
Diemžēl nav neviena laba krievu vārda, kas apzīmētu savienojumu baseinu. Dažreiz to sauc par multiplekseru savienojumiem. Ja zini kā saukt pieslēguma pūlinieku, tad noteikti pasaki, ar lielu prieku runāšu pareizā krievu tehniskajā valodā.
Mēs izpētījām savienojumu apvienotājus, kas bija piemēroti pārvaldītam postgres klasterim. Un PgBouncer mums bija labākā izvēle. Taču mēs saskārāmies ar vairākām problēmām ar PgBouncer. Pirms daudziem gadiem Volodja Borodins sniedza ziņojumus, ka lietojam PgBouncer, mums viss patīk, bet ir nianses, ir pie kā strādāt.
Un mēs strādājām. Mēs novērsām radušās problēmas, izlabojām Bouncer un mēģinājām virzīt izvilkšanas pieprasījumus augšup. Bet ar fundamentālu viena vītne bija grūti strādāt.
Mums bija jāsavāc kaskādes no lāpītajiem Bouncers. Ja mums ir daudz viena vītnes izlēcēju, augšējā slāņa savienojumi tiek pārnesti uz atlēcēju iekšējo slāni. Šī ir slikti pārvaldīta sistēma, kuru ir grūti izveidot un mērogot uz priekšu un atpakaļ.
Mēs nonācām pie secinājuma, ka esam izveidojuši paši savu savienojumu baseinu, ko sauc par Odiseju. Mēs to rakstījām no nulles.
2019. gadā PgCon konferencē es prezentēju šo pūlinītāju izstrādātāju kopienai. Tagad mums ir nedaudz mazāk par 2 zvaigznēm vietnē GitHub, t.i., projekts ir dzīvs, projekts ir populārs.
Un, ja vietnē Yandex.Cloud izveidojat Postgres kopu, tas būs klasteris ar iebūvētu Odyssey, kas tiek pārkonfigurēts, mērogojot kopu uz priekšu vai atpakaļ.
Ko mēs mācījāmies no šī projekta? Konkurējoša projekta uzsākšana vienmēr ir agresīvs solis, tas ir ārkārtējs pasākums, kad sakām, ka ir problēmas, kuras netiek risinātas pietiekami ātri, netiek atrisinātas tādos laika intervālos, kādi mums būtu piemēroti. Bet tas ir efektīvs pasākums.
PgBouncer sāka attīstīties ātrāk.
Un tagad ir parādījušies citi projekti. Piemēram, pgagroal, ko izstrādā Red Hat izstrādātāji. Viņi tiecas pēc līdzīgiem mērķiem un īsteno līdzīgas idejas, bet, protams, ar savu specifiku, kas ir tuvāka pgagroal izstrādātājiem.
Vēl viens darba ar postgres kopienu gadījums ir atjaunošana uz noteiktu laiku. Šī ir atkopšana pēc neveiksmes, šī ir atkopšana no dublējuma.
Ir daudz dublējumu, un tie visi ir atšķirīgi. Gandrīz katram Postgres pārdevējam ir savs rezerves risinājums.
Ja ņemat visas rezerves sistēmas, izveidojat pazīmju matricu un pa jokam parēķināsit determinantu šajā matricā, tā būs nulle. Ko tas nozīmē? Ko darīt, ja paņemat konkrētu dublējuma failu, tad to nevar salikt no visu pārējo daļām. Tas ir unikāls savā īstenošanā, tas ir unikāls ar mērķi, tas ir unikāls idejās, kas tajā ir iestrādātas. Un tie visi ir specifiski.
Kamēr mēs strādājām pie šī jautājuma, CitusData uzsāka WAL-G projektu. Šī ir rezerves sistēma, kas tika izveidota, ņemot vērā mākoņa vidi. Tagad CitusData jau ir daļa no Microsoft. Un tajā brīdī mums ļoti patika idejas, kas tika izklāstītas WAL-G sākotnējos laidienos. Un mēs sākām dot savu ieguldījumu šajā projektā.
Tagad šajā projektā ir vairāki desmiti izstrādātāju, bet starp 10 labākajiem WAL-G atbalstītājiem ir 6 Yandexoids. Mēs tur ienesām daudzas savas idejas. Un, protams, mēs paši tos ieviesām, paši pārbaudījām, paši izrullējām ražošanā, paši lietojam, paši izdomājam, kur tālāk virzīties, vienlaikus mijiedarbojoties ar lielo WAL-G kopienu.
Un no mūsu viedokļa tagad šī rezerves sistēma, tostarp ņemot vērā mūsu centienus, ir kļuvusi optimāla mākoņa videi. Šīs ir labākās Postgres dublēšanas izmaksas mākonī.
Ko tas nozīmē? Mēs veicinājām diezgan lielu ideju: dublējumam jābūt drošam, lētam darbam un pēc iespējas ātrākai atjaunošanai.
Kāpēc lai ekspluatācija būtu lēta? Ja nekas nav bojāts, jums nevajadzētu zināt, ka jums ir rezerves kopijas. Viss darbojas labi, jūs iztērējat pēc iespējas mazāk CPU, izmantojat pēc iespējas mazāk diska resursu un sūtāt tīklā pēc iespējas mazāk baitu, lai netraucētu jūsu vērtīgo pakalpojumu slodzei.
Un, kad viss sabojājas, piemēram, administrators nometa datus, kaut kas nogāja greizi, un jums steidzami jāatgriežas pagātnē, jūs atgūstaties ar visu naudu, jo vēlaties ātri un neskartus datus atgūt.
Un mēs veicinājām šo vienkāršo ideju. Un, kā mums šķiet, mums tas izdevās.
Bet tas vēl nav viss. Mēs gribējām vēl vienu mazu lietu. Mēs gribējām daudz dažādu datu bāzu. Ne visi mūsu klienti izmanto Postgres. Daži cilvēki izmanto MySQL, MongoDB. Kopienā citi izstrādātāji ir atbalstījuši FoundationDB. Un šis saraksts nepārtraukti paplašinās.
Kopienai patīk ideja, ka datubāze tiek darbināta pārvaldītā vidē mākonī. Un izstrādātāji uztur savas datu bāzes, kuras var dublēt vienādi kopā ar Postgres, izmantojot mūsu rezerves sistēmu.
Ko mēs esam iemācījušies no šī stāsta? Mūsu produkts kā izstrādes nodaļa nav koda rindas, tie nav paziņojumi, tie nav faili. Mūsu produkts nav pull pieprasījumus. Šīs ir idejas, ko mēs nododam sabiedrībai. Tā ir tehnoloģiskā pieredze un tehnoloģiju virzība uz mākoņa vidi.
Ir tāda datu bāze kā Postgres. Man visvairāk patīk Postgres kodols. Es pavadu daudz laika, attīstot Postgres kodolu kopā ar sabiedrību.
Bet šeit jāsaka, ka Yandex.Cloud ir iekšēja pārvaldīto datu bāzu instalācija. Un tas sākās jau sen pakalpojumā Yandex.Mail. Zināšanas, kas tagad ir novedušas pie pārvaldītās Postgres, tika uzkrātas, kad pasts vēlējās pārvietoties uz Postgres.
Pastam ir ļoti līdzīgas prasības kā mākonim. Tam ir nepieciešams, lai jūs varētu mērogot līdz negaidītam eksponenciālam pieaugumam jebkurā datu punktā. Un pasts jau bija noslogots ar dažiem simtiem miljonu pastkastīšu ar milzīgu skaitu lietotāju, kuri pastāvīgi veic daudzus pieprasījumus.
Un tas bija diezgan nopietns izaicinājums komandai, kas izstrādāja Postgres. Toreiz par visām problēmām, ar kurām saskārāmies, tika ziņots kopienai. Un šīs problēmas tika izlabotas un izlabotas dažās vietās pat dažu citu datu bāzu maksas atbalsta līmenī un pat labāk. Tas ir, jūs varat nosūtīt vēstuli PgSQL hakeram un saņemt atbildi 40 minūšu laikā. Maksas atbalsts dažās datubāzēs var domāt, ka ir svarīgākas lietas nekā jūsu kļūda.
Tagad Postgres iekšējā instalācija ir daži petabaiti datu. Tie ir daži miljoni pieprasījumu sekundē. Tie ir tūkstošiem kopu. Tas ir ļoti liela mēroga.
Bet ir kāda nianse. Tas darbojas nevis uz izdomātiem tīkla diskdziņiem, bet gan uz diezgan vienkāršu aparatūru. Un ir testa vide, kas ir īpaši paredzēta interesantām jaunām lietām.
Un noteiktā brīdī testa vidē mēs saņēmām ziņojumu, kas norādīja, ka ir pārkāpti datu bāzes indeksu iekšējie invarianti.
Invariants ir sava veida attiecības, kuras mēs sagaidām vienmēr.
Mums ļoti kritiska situācija. Tas norāda, ka daži dati, iespējams, ir pazaudēti. Un datu zudums ir kaut kas pilnīgi katastrofāls.
Vispārējā ideja, ko mēs ievērojam pārvaldītajās datubāzēs, ir tāda, ka pat ar piepūli būs grūti zaudēt datus. Pat ja jūs tos apzināti noņemat, jums joprojām būs jāignorē to prombūtne ilgu laiku. Datu drošība ir reliģija, kurai mēs diezgan rūpīgi sekojam.
Un šeit rodas situācija, kas liek domāt, ka var būt situācija, kurai mēs varam nebūt gatavi. Un mēs sākām gatavoties šai situācijai.
Pirmā lieta, ko mēs izdarījām, bija apglabāt baļķus no šiem tūkstošiem kopu. Mēs noskaidrojām, kuras no kopām atradās diskos ar problemātisku programmaparatūru, kurā tika zaudēti datu lapu atjauninājumi. Atzīmēts viss Postgres datu kods. Un tos ziņojumus, kas norāda uz iekšējo invariantu pārkāpumiem, mēs atzīmējām ar kodu, kas paredzēts datu bojājumu noteikšanai.
Šo ielāpu sabiedrība praktiski pieņēma bez lielām diskusijām, jo katrā konkrētajā gadījumā bija redzams, ka ir noticis kaut kas slikts un par to jāziņo žurnālam.
Pēc tam mēs nonācām pie tā, ka mums ir uzraudzība, kas skenē žurnālus. Un aizdomīgu ziņojumu gadījumā viņš pamodina dežurantu, un dežurants to salabo.
Bet! Žurnālu skenēšana ir lēta darbība vienā klasterī un katastrofāli dārga tūkstoš kopu.
Mēs uzrakstījām paplašinājumu ar nosaukumu . Tas rada datu bāzes skatu, kurā varat lēti un ātri atlasīt statistiku par pagātnes kļūdām. Un, ja mums vajadzēs pamodināt dežurantu, tad mēs to uzzināsim, neskenējot gigabaitu failus, bet gan izvelkot dažus baitus no hash tabulas.
Šis paplašinājums ir pieņemts, piemēram, repozitorijā for . Ja vēlaties to izmantot, varat to instalēt pats. Protams, tas ir atvērtā koda avots.
Bet tas vēl nav viss. Mēs sākām izmantot Amcheck — kopienas izveidotu paplašinājumu, lai indeksos atrastu nemainīgus pārkāpumus.
Un mēs noskaidrojām, ka, ja to izmantojat lielā mērogā, ir kļūdas. Mēs sākām tos labot. Mūsu labojumi ir pieņemti.
Mēs atklājām, ka šis paplašinājums nevar analizēt GiST un GIT indeksus. Mēs likām viņiem atbalstīt. Taču šis atbalsts joprojām tiek apspriests sabiedrībā, jo šī ir salīdzinoši jauna funkcionalitāte un tajā ir daudz detaļu.
Un mēs arī atklājām, ka, pārbaudot indeksus par pārkāpumiem uz replikācijas vadītāja, uz galvenā, viss darbojas labi, bet uz replikām, uz sekotāju, korupcijas meklēšana nav tik efektīva. Ne visi invarianti tiek pārbaudīti. Un viens invariants mūs ļoti traucēja. Un mēs pavadījām pusotru gadu, sazinoties ar kopienu, lai iespējotu šo kopiju pārbaudi.
Mēs rakstījām kodu, kam bija jāievēro visi can… protokoli. Mēs ilgi apspriedām šo ielāpu ar Pīteru Geogheganu no Crunchy Data. Viņam bija nedaudz jāpārveido esošais B-koks Postgres, lai ielāps tiktu pieņemts. Tas tika pieņemts. Un tagad arī repliku indeksu pārbaude ir kļuvusi pietiekami efektīva, lai atklātu pārkāpumus, ar kuriem mēs saskārāmies. Tas ir, šie ir pārkāpumi, ko var izraisīt diska programmaparatūras kļūdas, Postgres kļūdas un kodola kļūdas. Linux, nelokāmas problēmas. Diezgan plašs problēmu avotu saraksts, kuriem mēs gatavojāmies.
Bet bez indeksiem ir tāda daļa kā kaudze, t.i., vieta, kur dati tiek glabāti. Un nav daudz invariantu, ko varētu pārbaudīt.
Mums ir paplašinājums Heapcheck. Mēs sākām to izstrādāt. Un paralēli kopā ar mums uzņēmums EnterpriseDB arī sāka rakstīt moduli, kuru viņi tāpat sauca par Heapcheck. Tikai mēs to saucām par PgHeapcheck, un viņi to vienkārši sauca par Heapcheck. Viņiem tas ir ar līdzīgām funkcijām, nedaudz atšķirīgs paraksts, bet ar vienādām idejām. Dažās vietās viņi tos ieviesa nedaudz labāk. Un viņi to iepriekš ievietoja atvērtā avotā.
Un tagad mēs attīstām viņu paplašināšanos, jo tā vairs nav viņu paplašināšanās, bet gan kopienas paplašināšanās. Un nākotnē šī ir daļa no kodola, kas tiks piegādāta ikvienam, lai viņi jau iepriekš zinātu par nākotnes problēmām.
Dažās vietās mēs pat nonācām pie secinājuma, ka mūsu uzraudzības sistēmās ir kļūdaini pozitīvi rezultāti. Piemēram, 1C sistēma. Lietojot datu bāzi, Postgres dažkārt tajā ieraksta datus, ko var nolasīt, bet pg_dump nevar nolasīt.
Mūsu problēmu noteikšanas sistēmai šī situācija izskatījās kā korupcija. Dežurants tika pamodināts. Dežurants paskatījās, kas notiek. Pēc kāda laika atnāca kliente un teica, ka man ir problēmas. Dežurants paskaidroja, kas par problēmu. Bet problēma ir Postgres kodolā.
Atradu diskusiju par šo funkciju. Un viņš rakstīja, ka mēs saskārāmies ar šo funkciju un tas bija nepatīkami, cilvēks naktī pamodās, lai saprastu, kas tas ir.
Sabiedrība atbildēja: "Ak, mums tas tiešām ir jālabo."
Man ir vienkārša līdzība. Ja staigā apavos, kurā ir smilšu graudiņš, tad principā var doties tālāk – nekādu problēmu. Ja pārdod zābakus tūkstošiem cilvēku, tad taisīsim zābakus vispār bez smiltīm. Un, ja kāds no jūsu apavu lietotājiem gatavojas skriet maratonu, jūs vēlaties izgatavot ļoti labus apavus un pēc tam pielāgot tos visiem lietotājiem. Un šādi negaidīti lietotāji vienmēr atrodas mākoņa vidē. Vienmēr ir lietotāji, kuri izmanto kopu kaut kādā oriģinālā veidā. Jums vienmēr tam ir jāsagatavojas.
Ko mēs šeit esam iemācījušies? Mēs uzzinājām vienkāršu lietu: vissvarīgākais ir izskaidrot sabiedrībai, ka pastāv problēma. Ja sabiedrība ir atzinusi problēmu, tad rodas dabiska konkurence, lai atrisinātu problēmu. Jo katrs vēlas atrisināt kādu svarīgu problēmu. Visi pārdevēji, visi hakeri saprot, ka viņi paši var uzkāpt uz šī grābekļa, tāpēc vēlas tos likvidēt.
Ja strādājat pie kādas problēmas, bet tā netraucē nevienu, izņemot jūs, bet jūs strādājat pie tās sistemātiski un galu galā tā tiek uzskatīta par problēmu, tad jūsu izvilkšanas pieprasījums noteikti tiks pieņemts. Jūsu ielāps tiks pieņemts, kopiena pārskatīs jūsu uzlabojumus vai pat uzlabojumu pieprasījumus. Galu galā mēs uzlabojam datubāzi viens otram.
Interesanta datu bāze ir Greenplum. Tā ir ļoti paralēla datu bāze, kuras pamatā ir Postgres kodu bāze, kas man ir ļoti pazīstama.
Un Greenplum ir interesanta funkcionalitāte - pievienojiet optimizētas tabulas. Šīs ir tabulas, kuras varat ātri pievienot. Tās var būt kolonnas vai rindas.
Bet nebija klasterizācijas, t.i., nebija funkcionalitātes, kur varētu sakārtot tabulā esošos datus tādā secībā, kāda ir kādā no indeksiem.
Puiši no taksometra pienāca pie manis un teica: “Andrej, tu pazīsti Postgresu. Un šeit tas ir gandrīz tas pats. Pārslēdzieties uz 20 minūtēm. Tu ņem un dari." Es domāju, ka jā, es pazīstu Postgres, pārslēdzoties uz 20 minūtēm – man tas jādara.
Bet nē, tās nebija 20 minūtes, es to rakstīju vairāku mēnešu garumā. PgConf.Russia konferencē es uzrunāju Heiki Linakangas no Pivotal un jautāju: “Vai ar to ir kādas problēmas? Kāpēc nav pievienota optimizēta tabulu klasterizācijas? Viņš saka: “Jūs ņemat datus. Jūs šķirojat, pārkārtojat. Tas ir tikai darbs." Es: "Ak, jā, jums vienkārši vajag to ņemt un darīt." Viņš saka: "Jā, mums ir vajadzīgas brīvas rokas, lai to izdarītu." Es domāju, ka man tas noteikti ir jādara.
Un dažus mēnešus vēlāk es iesniedzu izvilkšanas pieprasījumu, kas ieviesa šo funkcionalitāti. Pivotal kopā ar kopienu pārskatīja šo piesaistes pieprasījumu. Protams, bija arī kļūdas.
Bet pats interesantākais ir tas, ka tad, kad šis pull pieprasījums tika apvienots, bugs tika atrasts pašā Greenplum. Mēs esam noskaidrojuši, ka kaudzes tabulas dažkārt izjauc transakciju darbību, ja tās tiek grupētas. Un šī ir lieta, kas ir jālabo. Un viņa atrodas vietā, kurai es tikko pieskāros. Un mana dabiskā reakcija bija – labi, ļaujiet man arī to izdarīt.
Es izlaboju šo kļūdu. Nosūtīja izvilkšanas pieprasījumu fiksētājiem. Viņu nogalināja.
Pēc kā izrādījās, ka šī funkcionalitāte ir jāiegūst Greenplum versijā PostgreSQL 12. Tas ir, 20 minūšu piedzīvojums turpinās ar jauniem interesantiem piedzīvojumiem. Bija interesanti pieskarties pašreizējai attīstībai, kurā kopiena izgriež jaunas un vissvarīgākās iezīmes. Tas ir sasalis.
Bet ar to viss nebeidzās. Pēc visa tā izrādījās, ka par to visu vajag uzrakstīt dokumentāciju.
Sāku rakstīt dokumentāciju. Par laimi, pienāca Pivotal dokumentālisti. Angļu valoda ir viņu dzimtā valoda. Viņi man palīdzēja ar dokumentāciju. Patiesībā viņi paši manis piedāvāto pārrakstīja īstā angļu valodā.
Un šeit, šķiet, piedzīvojums beidzās. Un vai jūs zināt, kas tad notika? Puiši no taksometra pienāca pie manis un teica: "Vēl ir divi piedzīvojumi, katrs pa 10 minūtēm." Un kas man viņiem jāsaka? Teicu, ka tagad sniegšu atskaiti par mērogu, tad redzēsim jūsu piedzīvojumus, jo šis ir interesants darbs.
Ko mēs mācījāmies no šī gadījuma? Tā kā darbs ar atvērto avotu vienmēr ir darbs ar konkrētu personu, tas vienmēr ir darbs ar kopienu. Jo katrā posmā es strādāju ar kādu izstrādātāju, kādu testētāju, kādu hakeri, kādu dokumentālistu, kādu arhitektu. Es nestrādāju ar Greenplum, es strādāju ar cilvēkiem ap Greenplum.
Bet! Ir vēl viens svarīgs punkts - tas ir tikai darbs. Tas ir, tu atnāc, iedzer kafiju, uzraksti kodu. Darbojas visādi vienkārši invarianti. Dariet to normāli - būs labi! Un tas ir diezgan interesants darbs. Šim darbam ir pieprasījums no Yandex.Cloud klientiem, mūsu klasteru lietotājiem gan Yandex, gan ārpus tās. Un es domāju, ka pieaugs projektu skaits, kuros mēs piedalāmies, un palielināsies arī mūsu iesaistes dziļums.
Tas ir viss. Pāriesim pie jautājumiem.
Jautājumu sesija
Sveiki! Mums ir vēl viena jautājumu un atbilžu sesija. Un studijā Andrejs Borodins. Šī ir persona, kas tikko pastāstīja par Yandex.Cloud un Yandex ieguldījumu atvērtā koda attīstībā. Mūsu ziņojums tagad nav tikai par mākoni, taču tajā pašā laikā mēs esam balstīti uz šādām tehnoloģijām. Bez tā, ko jūs darījāt Yandex, Yandex.Cloud nebūtu pakalpojumu, tāpēc paldies no manis personīgi. Un pirmais jautājums no raidījuma: "Par ko ir rakstīts katrs no jūsu pieminētajiem projektiem?"
Rezerves sistēma WAL-G ir rakstīta Go. Šis ir viens no jaunākajiem projektiem, pie kura esam strādājuši. Viņam burtiski ir tikai 3 gadi. Un datubāze bieži ir saistīta ar uzticamību. Un tas nozīmē, ka datu bāzes ir diezgan vecas, un tās parasti ir rakstītas C. Postgres projekts sākās apmēram pirms 30 gadiem. Tad C89 bija pareizā izvēle. Un uz tā ir rakstīts Postgres. Mūsdienīgākas datu bāzes, piemēram, ClickHouse, parasti tiek rakstītas C++ valodā. Visas sistēmas izstrādes pamatā ir C un C++.
Jautājums no mūsu finanšu menedžera, kurš ir atbildīgs par Cloud izdevumiem: "Kāpēc Cloud tērē naudu atvērtā koda atbalstam?"
Šeit finanšu vadītājam ir vienkārša atbilde. Mēs to darām, lai uzlabotu savus pakalpojumus. Kādos veidos mēs varam darīt labāk? Mēs varam darīt lietas efektīvāk, ātrāk un padarīt lietas mērogojamākas. Bet mums šis stāsts galvenokārt ir par uzticamību. Piemēram, rezerves sistēmā mēs pārskatām 100% no ielāpu, kas uz to attiecas. Mēs zinām, kas ir kods. Un mums ir ērtāk ieviest jaunas versijas ražošanā. Tas ir, pirmkārt, par pārliecību, par gatavību attīstībai un par uzticamību
Vēl viens jautājums: "Vai ārējo lietotāju prasības, kas dzīvo Yandex.Cloud, atšķiras no iekšējiem lietotājiem, kuri dzīvo iekšējā mākonī?"
Slodzes profils, protams, ir atšķirīgs. Bet no manas nodaļas viedokļa visi īpašie un interesantie gadījumi tiek veidoti uz nestandarta slodzes. Izstrādātājus ar iztēli, izstrādātājus, kuri paveic neparedzētos, visticamāk, atradīs gan iekšēji, gan ārēji. Šajā ziņā mēs visi esam aptuveni vienādi. Un, iespējams, vienīgā svarīgā iezīme Yandex datu bāzu darbībā būs tā, ka Yandex mums ir mācība. Kādā brīdī kāda pieejamības zona pilnībā nonāk ēnā, un visiem Yandex pakalpojumiem ir jāturpina darboties, neskatoties uz to. Tā ir neliela atšķirība. Bet tas rada daudz pētījumu izstrādes datu bāzes un tīkla steka saskarnē. Pretējā gadījumā ārējās un iekšējās instalācijas rada vienādus pieprasījumus pēc funkcijām un līdzīgus pieprasījumus uzticamības un veiktspējas uzlabošanai.
Nākamais jautājums: “Kā jūs personīgi jūtaties par to, ka lielu daļu no tā, ko darāt, izmanto citi mākoņi?” Mēs nenosauksim konkrētus, taču daudzi projekti, kas tika veikti pakalpojumā Yandex.Cloud, tiek izmantoti citu cilvēku mākoņos.
Tas ir forši. Pirmkārt, tā ir zīme, ka esam kaut ko izdarījuši pareizi. Un tas skrāpē ego. Un mēs esam pārliecinātāki, ka pieņēmām pareizo lēmumu. No otras puses, tā ir cerība, ka nākotnē tas mums nesīs jaunas idejas, jaunus trešo pušu lietotāju pieprasījumus. Lielāko daļu GitHub problēmu rada individuāli sistēmu administratori, individuālie DBA, individuāli arhitekti, individuāli inženieri, taču dažkārt nāk cilvēki ar sistemātisku pieredzi un saka, ka 30% gadījumu mums ir šī problēma, un domāsim, kā to atrisināt. Tas ir tas, ko mēs gaidām visvairāk. Mēs ceram dalīties pieredzē ar citām mākoņu platformām.
Jūs daudz runājāt par maratonu. Es zinu, ka jūs skrējāt maratonu Maskavā. Rezultātā? Apsteidza puišus no PostgreSQL?
Nē, Oļegs Bartunovs skrien ļoti ātri. Viņš pabeidza stundu pirms manis. Kopumā esmu apmierināts ar to, cik tālu esmu nonācis. Man tikai finišēšana bija sasniegums. Kopumā ir pārsteidzoši, ka postgres kopienā ir tik daudz skrējēju. Man šķiet, ka pastāv kaut kāda saistība starp aerobikas sportu un vēlmi pēc sistēmu programmēšanas.
Vai jūs sakāt, ka ClickHouse nav skrējēju?
Es noteikti zinu, ka viņi tur ir. ClickHouse ir arī datu bāze. Starp citu, Oļegs man tagad raksta: "Vai ejam paskriet pēc ziņojuma?" Šī ir lieliska ideja.
Vēl viens jautājums no Ņikitas raidījuma: "Kāpēc jūs pats izlabojāt Greenplum kļūdu un neiedevāt to junioriem?" Tiesa, nav īsti skaidrs, kas ir kļūda un kurā pakalpojumā, bet tas, iespējams, nozīmē to, par kuru runājāt.
Jā, principā varēja kādam iedot. Tas bija tikai kods, kuru es tikko nomainīju. Un tas bija dabiski turpināt to darīt uzreiz. Principā ideja dalīties pieredzē ar komandu ir laba ideja. Mēs noteikti sadalīsim Greenplum uzdevumus starp visiem mūsu nodaļas dalībniekiem.
Tā kā mēs runājam par junioriem, tad šeit ir jautājums. Persona nolēma izveidot pirmo apņemšanos Postgresā. Kas viņam jādara, lai izdarītu pirmo apņemšanos?
Šis ir interesants jautājums: "Kur sākt?" Parasti ir diezgan grūti sākt ar kaut ko kodolā. Piemēram, Postgres ir veicamo darbu saraksts. Bet patiesībā šī ir lapa par to, ko viņi mēģināja izdarīt, bet neizdevās. Tās ir sarežģītas lietas. Un parasti ekosistēmā var atrast dažas utilītas, dažus paplašinājumus, kurus var uzlabot, kas piesaista mazāku kodola izstrādātāju uzmanību. Un attiecīgi tur ir vairāk punktu izaugsmei. Programmā Google Summer of Code katru gadu postgres kopiena izvirza daudzas dažādas tēmas, kuras varētu risināt. Šogad mums bija, manuprāt, trīs skolēni. Viens pat rakstīja WAL-G par tēmām, kas ir svarīgas Yandex. Greenplum viss ir vienkāršāk nekā Postgres kopienā, jo Greenplum hakeri ļoti labi izturas pret pull pieprasījumiem un nekavējoties sāk pārskatīšanu. Plākstera nosūtīšana Postgres ir dažu mēnešu jautājums, taču Greenplum ieradīsies pēc dienas un redzēs, ko esat paveicis. Cita lieta, ka Greenplum ir jāatrisina aktuālās problēmas. Greenplum netiek plaši izmantots, tāpēc atrast savu problēmu ir diezgan grūti. Un, pirmkārt, mums, protams, ir jāatrisina problēmas.
Avots: www.habr.com
