La kontribuo de Yandex al la sekvaj datumbazoj estos reviziita.
- KlakuDomo
- Odiseado
- Reakiro al tempopunkto (WAL-G)
- PostgreSQL (inkluzive de logeraroj, Amcheck, heapcheck)
- Verda pruno
Video:
Saluton mondo! Mia nomo estas Andrej Borodin. Kaj kion mi faras ĉe Yandex.Cloud estas disvolvi malfermajn interrilatajn datumbazojn en la interesoj de klientoj de Yandex.Cloud kaj Yandex.Cloud.
En ĉi tiu parolado, ni parolos pri la defioj alfrontantaj malfermajn datumbazojn je skalo. Kial ĝi estas grava? Ĉar etaj, malgrandaj problemoj kiuj, kiel moskitoj, poste fariĝas elefantoj. Ili fariĝas grandaj kiam vi havas multajn aretojn.
Sed tio ne estas la ĉefa afero. Nekredeblaj aferoj okazas. Aferoj kiuj okazas en unu el miliono da kazoj. Kaj en nuba medio, vi devas esti preta por tio, ĉar nekredeblaj aferoj fariĝas tre verŝajnaj kiam io ekzistas skale.
Sed! Kio estas la avantaĝo de malfermaj datumbazoj? La fakto estas, ke vi havas teorian ŝancon trakti ajnan problemon. Vi havas la fontkodon, vi havas programadon. Ni kombinas ĝin kaj ĝi funkcias.
Kiuj aliroj ekzistas por labori pri malfermkoda programaro?
- La plej simpla aliro estas uzi programaron. Se vi uzas protokolojn, se vi uzas normojn, se vi uzas formatojn, se vi skribas demandojn en malfermkoda programaro, tiam vi jam subtenas ĝin.
- Vi pligrandigas ĝian ekosistemon. Vi pligrandigas la probablecon de frua detekto de cimo. Vi pliigas la fidindecon de ĉi tiu sistemo. Vi pliigas la haveblecon de programistoj en la merkato. Vi plibonigas ĉi tiun programaron. Vi jam estas kunlaboranto, se vi ĵus faris stilon kaj tuŝis ion tie.
- Alia komprenebla aliro estas sponsorado de malfermkoda programaro. Ekzemple, la konata programo Google Summer of Code, kiam Guglo pagas grandan nombron da studentoj el la tuta mondo kompreneblan monon, por ke ili disvolvu malfermajn programajn projektojn, kiuj plenumas iujn licencajn postulojn.
- Ĉi tio estas tre interesa aliro ĉar ĝi permesas al la programaro evolui sen deturni la fokuson de la komunumo. Guglo, kiel teknologia giganto, ne diras, ke ni volas ĉi tiun funkcion, ni volas ripari ĉi tiun cimon kaj ni devas fosi tie. Google diras: "Faru tion, kion vi faras. Nur daŭre laboru kiel vi laboris kaj ĉio estos en ordo."
- La sekva aliro al partopreno en malferma fonto estas partopreno. Kiam vi havas problemon en malfermkoda programaro kaj estas programistoj, viaj programistoj komencas solvi la problemojn. Ili komencas fari vian infrastrukturon pli efika, viajn programojn pli rapidaj kaj pli fidindaj.
Unu el la plej famaj Yandex-projektoj en la kampo de malfermkoda programaro estas ClickHouse. Ĉi tio estas datumbazo, kiu naskiĝis kiel respondo al la defioj alfrontantaj Yandex.Metrica.
Kaj kiel datumbazo, ĝi estis farita en malferma fonto por krei ekosistemon kaj disvolvi ĝin kune kun aliaj programistoj (ne nur en Yandex). Kaj nun ĉi tio estas granda projekto en kiu multaj malsamaj kompanioj estas implikitaj.
En Yandex.Cloud, ni kreis ClickHouse aldone al Yandex Object Storage, t.e. al nuba stokado.
Kial ĉi tio estas grava en la nubo? Ĉar ajna datumbazo funkcias en ĉi tiu triangulo, en ĉi tiu piramido, en ĉi tiu hierarkio de memortipoj. Vi havas rapidajn sed malgrandajn registrojn kaj malmultekostajn grandajn sed malrapidajn SSDojn, malmolajn diskojn kaj iujn aliajn blokajn aparatojn. Kaj se vi estas efika ĉe la supro de la piramido, tiam vi havas rapidan datumbazon. se vi estas efika ĉe la fundo de ĉi tiu piramido, tiam vi havas skalitan datumbazon. Kaj ĉi-rilate, aldoni alian tavolon de malsupre estas logika aliro por pliigi la skaleblon de la datumbazo.
Kiel ĝi povus esti farita? Ĉi tio estas grava punkto en ĉi tiu raporto.
- Ni povus efektivigi ClickHouse super MDS. MDS estas interna Yandex-nuba stokado-interfaco. Ĝi estas pli kompleksa ol la komuna S3-protokolo, sed ĝi estas pli taŭga por bloka aparato. Estas pli bone por registri datumojn. Ĝi postulas pli da programado. Programistoj programos, ĝi estas eĉ bona, ĝi estas interesa.
- S3 estas pli ofta aliro, kiu igas la interfacon pli simpla koste de malpli adaptiĝo al certaj specoj de laborŝarĝoj.
Kompreneble, volante provizi funkciecon al la tuta ClickHouse-ekosistemo kaj fari la taskon necesan en Yandex.Cloud, ni decidis certigi, ke la tuta ClickHouse-komunumo profitos de ĝi. Ni efektivigis ClickHouse super S3, ne ClickHouse super MDS. Kaj ĉi tio estas multe da laboro.
Referencoj
"Dosiersistema abstrakta tavolo"
"AWS SDK S3-integriĝo"
"Baza efektivigo de IDisk-interfaco por S3"
"Integriĝo de protokolaj motoroj kun IDisk-interfaco"
"Protokolo-motorsubteno por S3 kaj SeekableReadBuffer"
"Stokado Stripe Log S3-subteno"
"Stokado MergeTree komenca subteno por S3"
"MergeTree plena subteno por S3"
"Subtenu ReplicatedMergeTree super S3"
"Aldonu defaŭltajn akreditaĵojn kaj kutimajn titolojn por s3-stokado"
"S3 kun dinamika prokura agordo"
"S3 kun prokura solvilo"
Ĉi tio estas tira petolisto por efektivigi virtualan dosiersistemon en ClickHouse. Ĉi tio estas granda nombro da tirpetoj.
Referencoj
"DiskS3 malmolaj ligiloj optimuma efektivigo"
"S3 HTTP-kliento - Evitu kopii respondfluon en memoron"
"Evitu kopii tutan respondfluon en memoron en S3 HTTP
kliento"
"Kapablo konservi markon kaj indeksajn dosierojn por S3-disko"
"Movu partojn de DiskLocal al DiskS3 paralele"
Sed la laboro ne finiĝis tie. Post kiam la funkcio estis farita, iom pli da laboro estis postulata por optimumigi ĉi tiun funkcion.
Referencoj
"Aldonu SelectedRows kaj SelectedBytes-okazaĵojn"
"Aldonu profilajn eventojn de S3-peto al system.events"
"Aldonu QueryTimeMicrosekundojn, ElektuQueryTimeMicrosekundojn kaj InsertQueryTimeMicrosekundojn"
Kaj tiam necesis igi ĝin diagnozebla, agordi monitoradon kaj igi ĝin regebla.
Kaj ĉio ĉi estis farita por ke la tuta komunumo, la tuta ekosistemo de ClickHouse, ricevis la rezulton de ĉi tiu laboro.
Ni transiru al transakciaj datumbazoj, al OLTP-datumbazoj, kiuj persone estas pli proksimaj al mi.
Ĉi tiu estas la malfermfonta DBMS-disvolva divido. Ĉi tiuj uloj faras stratmagion por plibonigi transakciajn malfermajn datumbazojn.
Unu el la projektoj, uzante ekzemplon pri kiu ni povas paroli pri kiel kaj kion ni faras, estas Connection Pooler en Postgres.
Postgres estas proceza datumbazo. Ĉi tio signifas, ke la datumbazo devus havi kiel eble plej malmultajn retajn konektojn, kiuj pritraktas transakciojn.
Aliflanke, en nuba medio, tipa situacio estas kiam mil konektoj venas al unu areto samtempe. Kaj la tasko de la konekto-pooler estas paki mil konektojn en malgrandan nombron da servilaj konektoj.
Ni povas diri, ke la konektopooler estas la telefonisto, kiu rearanĝas la bajtojn por ke ili efike atingu la datumbazon.
Bedaŭrinde, ne ekzistas bona rusa vorto por konekto-pooler. Foje ĝi estas nomita multipleksilaj konektoj. Se vi scias kiel nomi la konekto-pooler, tiam nepre diru al mi, mi tre volonte parolos la ĝustan rusan teknikan lingvon.
Ni esploris konekto-komunilojn, kiuj taŭgis por administrita postgres-grupo. Kaj PgBouncer estis la plej bona elekto por ni. Sed ni renkontis kelkajn problemojn kun PgBouncer. Antaŭ multaj jaroj, Volodya Borodin raportis, ke ni uzas PgBouncer, ni ŝatas ĉion, sed estas nuancoj, estas io por labori.
Kaj ni laboris. Ni riparis la problemojn, kiujn ni renkontis, ni flikis Bouncer kaj provis puŝi tirpetojn kontraŭflue. Sed fundamenta unu-fadenado estis malfacile labori kun.
Ni devis kolekti kaskadojn de flikitaj Bouncers. Kiam ni havas multajn unu-fadenajn Bouncers, la ligoj sur la supra tavolo estas translokigitaj al la interna tavolo de Bouncers. Ĉi tio estas malbone administrita sistemo, kiu malfacilas konstrui kaj grimpi tien kaj reen.
Ni venis al la konkludo, ke ni kreis nian propran konekton-pooler, kiu nomiĝas Odiseado. Ni skribis ĝin de nulo.
En 2019, ĉe la PgCon-konferenco, mi prezentis ĉi tiun pooler al la programista komunumo. Nun ni havas iom malpli ol 2 stelojn en GitHub, t.e. la projekto vivas, la projekto estas populara.
Kaj se vi kreas Postgres-grupon en Yandex.Cloud, tiam ĝi estos areto kun enkonstruita Odiseado, kiu estas reagordita kiam grimpas la areton antaŭen aŭ reen.
Kion ni lernis el ĉi tiu projekto? Lanĉi konkurantan projekton ĉiam estas agresema paŝo, ĝi estas ekstrema mezuro, kiam ni diras, ke estas problemoj, kiuj ne sufiĉe rapide solviĝas, ne solviĝas en la tempaj intervaloj, kiuj konvenus al ni. Sed ĉi tio estas efika mezuro.
PgBouncer komencis formiĝi pli rapide.
Kaj nun aperis aliaj projektoj. Ekzemple, pgagroal, kiu estas evoluigita fare de Red Hat programistoj. Ili celas similajn celojn kaj efektivigas similajn ideojn, sed, kompreneble, kun siaj propraj specifaĵoj, kiuj estas pli proksimaj al pgagroal-programistoj.
Alia kazo de laborado kun la postgres-komunumo restarigas al tempopunkto. Ĉi tio estas reakiro post fiasko, ĉi tio estas reakiro de sekurkopio.
Estas multaj sekurkopioj kaj ili ĉiuj estas malsamaj. Preskaŭ ĉiu vendisto de Postgres havas sian propran rezervan solvon.
Se vi prenas ĉiujn sekurkopiajn sistemojn, kreas trajtomatricon kaj ŝerce kalkulas la determinanton en ĉi tiu matrico, ĝi estos nulo. Kion ĉi tio signifas? Kio se vi prenas specifan rezervan dosieron, tiam ĝi ne povas esti kunvenita el pecoj de ĉiuj aliaj. Ĝi estas unika en sia efektivigo, ĝi estas unika en sia celo, ĝi estas unika en la ideoj kiuj estas enigitaj en ĝi. Kaj ili ĉiuj estas specifaj.
Dum ni laboris pri ĉi tiu afero, CitusData lanĉis la projekton WAL-G. Ĉi tio estas rezerva sistemo, kiu estis farita kun okulo al la nuba medio. Nun CitusData jam estas parto de Microsoft. Kaj en tiu momento, ni tre ŝatis la ideojn kiuj estis fiksitaj en la komencaj eldonoj de WAL-G. Kaj ni komencis kontribui al ĉi tiu projekto.
Nun estas multaj dekoj da programistoj en ĉi tiu projekto, sed la plej bonaj 10 kontribuantoj al WAL-G inkluzivas 6 Yandexoids. Ni alportis multajn niajn ideojn tien. Kaj, kompreneble, ni mem efektivigis ilin, testis ilin mem, ruligis ilin en produktadon mem, ni mem uzas ilin, ni mem eltrovas kien movi poste, dum interagado kun la granda komunumo WAL-G.
Kaj de nia vidpunkto, nun ĉi tiu rezerva sistemo, inkluzive de konsidero de niaj klopodoj, fariĝis optimuma por nuba medio. Ĉi tio estas la plej bona kosto por subteni Postgres en la nubo.
Kion ĝi signifas? Ni reklamis sufiĉe grandan ideon: sekurkopio devus esti sekura, malmultekosta por funkcii kaj kiel eble plej rapide restaŭri.
Kial ĝi devus esti malmultekosta funkcii? Kiam nenio estas rompita, vi ne devus scii, ke vi havas sekurkopiojn. Ĉio funkcias bone, vi malŝparas kiel eble plej malmulte da CPU, vi uzas kiel eble plej malmulte da viaj diskresursoj, kaj vi sendas kiel eble plej malmultajn bajtojn al la reto por ne malhelpi la utilan ŝarĝon de viaj valoraj servoj.
Kaj kiam ĉio rompiĝas, ekzemple, la administranto faligis la datumojn, io misfunkciis, kaj vi urĝe bezonas reiri al la pasinteco, vi resaniĝas kun la tuta mono, ĉar vi volas viajn datumojn reen rapide kaj sendifektaj.
Kaj ni reklamis ĉi tiun simplan ideon. Kaj, ŝajnas al ni, ni sukcesis efektivigi ĝin.
Sed tio ne estas ĉio. Ni volis ankoraŭ unu malgrandan aferon. Ni volis multajn malsamajn datumbazojn. Ne ĉiuj niaj klientoj uzas Postgres. Iuj homoj uzas MySQL, MongoDB. En la komunumo, aliaj programistoj subtenis FoundationDB. Kaj ĉi tiu listo konstante plivastiĝas.
La komunumo ŝatas la ideon, ke la datumbazo funkcias en administrita medio en la nubo. Kaj programistoj konservas siajn datumbazojn, kiuj povas esti sekurkopiitaj unuforme kune kun Postgres per nia rezerva sistemo.
Kion ni lernis el ĉi tiu rakonto? Nia produkto, kiel disvolva divido, ne estas linioj de kodo, ĝi ne estas deklaroj, ĝi ne estas dosieroj. Nia produkto ne estas tirpetoj. Ĉi tiuj estas la ideoj, kiujn ni transdonas al la komunumo. Ĉi tio estas teknologia kompetenteco kaj la movado de teknologio al nuba medio.
Estas tia datumbazo kiel Postgres. Mi plej ŝatas la Postgres-kernon. Mi pasigas multan tempon disvolvante la Postgres-kernon kun la komunumo.
Sed ĉi tie oni devas diri, ke Yandex.Cloud havas internan instaladon de administritaj datumbazoj. Kaj ĝi komenciĝis antaŭ longe en Yandex.Mail. La kompetenteco, kiu nun kondukis al administrita Postgres, akumuliĝis kiam la poŝto volis translokiĝi en Postgres.
Poŝto havas tre similajn postulojn al la nubo. Ĝi bezonas, ke vi povu grimpi al neatendita eksponenta kresko en iu ajn punkto de viaj datumoj. Kaj la poŝto jam havis ŝarĝon kun kelkaj centoj da milionoj da leterkestoj de grandega nombro da uzantoj, kiuj konstante faras multajn petojn.
Kaj ĉi tio estis sufiĉe grava defio por la teamo, kiu disvolvis Postgres. Tiam, iuj problemoj, kiujn ni renkontis, estis raportitaj al la komunumo. Kaj ĉi tiuj problemoj estis korektitaj, kaj korektitaj de la komunumo kelkloke eĉ je la nivelo de pagita subteno por iuj aliaj datumbazoj kaj eĉ pli bone. Tio estas, vi povas sendi leteron al PgSQL-pirato kaj ricevi respondon ene de 40 minutoj. Pagita subteno en iuj datumbazoj povas pensi, ke estas pli da prioritataj aferoj ol via cimo.
Nun la interna instalado de Postgres estas kelkaj petabajtoj da datumoj. Ĉi tiuj estas kelkaj milionoj da petoj sekundo. Ĉi tiuj estas miloj da aretoj. Ĝi estas tre grandskala.
Sed estas nuanco. Ĝi vivas ne sur elegantaj retaj diskoj, sed sur sufiĉe simpla aparataro. Kaj ekzistas prova medio specife por interesaj novaj aferoj.
Kaj en certa momento en la testa medio ni ricevis mesaĝon indikante, ke la internaj invariantoj de la datumbazaj indeksoj estis malobservitaj.
Nevarianto estas ia rilato, kiun ni atendas ĉiam teni.
Tre maltrankviliga situacio por ni. Ĝi indikas ke iuj datumoj eble estis perditaj. Kaj perdo de datumoj estas io tute katastrofa.
La ĝenerala ideo, kiun ni sekvas en administritaj datumbazoj, estas, ke eĉ kun peno, estos malfacile perdi datumojn. Eĉ se vi intence forigas ilin, vi ankoraŭ devos ignori ilian foreston dum longa tempo. Sekureco de datumoj estas religio, kiun ni sekvas sufiĉe diligente.
Kaj ĉi tie aperas situacio, kiu sugestas, ke povas esti situacio, por kiu ni eble ne estas pretaj. Kaj ni komencis prepari por ĉi tiu situacio.
La unua afero, kiun ni faris, estis enterigi la ŝtipojn el ĉi tiuj miloj da aretoj. Ni trovis, kiuj el la aretoj troviĝis sur diskoj kun problema firmvaro, kiuj perdis ĝisdatigojn pri datumoj. Markis ĉiujn datumojn de Postgres. Kaj ni markis tiujn mesaĝojn, kiuj indikas malobservojn de internaj invariantoj per kodo desegnita por detekti datuman korupton.
Tiu ĉi flikaĵo estis praktike akceptita de la komunumo sen multe da diskuto, ĉar en ĉiu specifa kazo estis evidente, ke io malbona okazis kaj necesas raporti al la protokolo.
Post ĉi tio, ni venis al la punkto, ke ni havas monitoradon, kiu skanas protokolojn. Kaj en kazo de suspektindaj mesaĝoj, li vekas la deĵoran oficiron, kaj la deĵoranon riparas ĝin.
Sed! Skanado de protokoloj estas malmultekosta operacio sur unu areto kaj katastrofe multekosta por mil aretoj.
Ni skribis etendon nomitan . Ĝi kreas vidon de la datumbazo en kiu vi povas malmultekoste kaj rapide elekti statistikojn pri pasintaj eraroj. Kaj se ni bezonas veki la deĵoran oficiron, tiam ni ekscios pri tio sen skanado de gigabajtaj dosieroj, sed ĉerpante kelkajn bajtojn el la hashtabelo.
Ĉi tiu etendo estis adoptita, ekzemple, en la deponejo por . Se vi volas uzi ĝin, vi povas instali ĝin mem. Kompreneble ĝi estas malferma fonto.
Sed tio ne estas ĉio. Ni komencis uzi Amcheck, komunum-konstruitan etendon, por trovi senvariajn malobservojn en indeksoj.
Kaj ni eksciis, ke se vi funkciigas ĝin laŭskale, estas cimoj. Ni komencis ripari ilin. Niaj korektoj estas akceptitaj.
Ni malkovris, ke ĉi tiu etendo ne povas analizi GiST & GIT-indeksojn. Ni igis ilin subteni. Sed ĉi tiu subteno ankoraŭ estas diskutata de la komunumo, ĉar ĉi tio estas relative nova funkcio kaj estas multaj detaloj tie.
Kaj ni ankaŭ malkovris, ke kiam oni kontrolas indeksojn pri malobservoj ĉe la reprodukta gvidanto, ĉe la majstro, ĉio funkcias bone, sed ĉe la kopioj, ĉe la sekvanto, la serĉado de korupto ne estas tiel efika. Ne ĉiuj invariantoj estas kontrolitaj. Kaj unu nevarianto tre ĝenis nin. Kaj ni pasigis jaron kaj duonon komunikante kun la komunumo por ebligi ĉi tiun kontrolon pri kopioj.
Ni skribis kodon kiu devus sekvi ĉiujn povas... protokoloj. Ni diskutis ĉi tiun diakilon dum sufiĉe da tempo kun Peter Gaghan de Crunchy Data. Li devis iomete modifi la ekzistantan B-arbon en Postgres por akcepti ĉi tiun peceton. Li estis akceptita. Kaj nun kontroli indeksojn sur kopioj ankaŭ fariĝis sufiĉe efika por detekti la malobservojn, kiujn ni renkontis. Tio estas, ĉi tiuj estas la malobservoj, kiuj povas esti kaŭzitaj de eraroj en diskfirmvaro, eraroj en Postgres, eraroj en la Linukso-kerno kaj aparataj problemoj. Sufiĉe ampleksa listo de fontoj de problemoj por kiuj ni prepariĝis.
Sed krom indeksoj, ekzistas tia parto kiel amaso, t.e. la loko kie la datumoj estas stokitaj. Kaj ne estas multaj invariantoj, kiuj povus esti kontrolitaj.
Ni havas etendon nomitan Heapcheck. Ni komencis disvolvi ĝin. Kaj paralele, kune kun ni, la kompanio EnterpriseDB ankaŭ komencis verki modulon, kiun ili sammaniere nomis Heapcheck. Nur ni nomis ĝin PgHeapcheck, kaj ili nur nomis ĝin Heapcheck. Ili havas ĝin kun similaj funkcioj, iomete malsama subskribo, sed kun la samaj ideoj. Ili efektivigis ilin iom pli bone en kelkaj lokoj. Kaj ili afiŝis ĝin en malferma fonto antaŭe.
Kaj nun ni disvolvas ilian vastiĝon, ĉar ĝi ne plu estas ilia ekspansio, sed la ekspansio de la komunumo. Kaj estonte, ĉi tio estas parto de la kerno, kiu estos liverita al ĉiuj, por ke ili anticipe povu scii pri estontaj problemoj.
En kelkaj lokoj, ni eĉ alvenis al la konkludo, ke ni havas falsajn pozitivojn en niaj monitoraj sistemoj. Ekzemple, la sistemo 1C. Kiam vi uzas datumbazon, Postgres foje skribas en ĝi datumojn, kiujn ĝi povas legi, sed pg_dump ne povas legi.
Ĉi tiu situacio aspektis korupto al nia problemo-detekta sistemo. La deĵoranto estis vekita. La deĵoroficiro rigardis kio okazis. Post iom da tempo venis kliento kaj diris, ke mi havas problemojn. La deĵoranto klarigis, kio estas la problemo. Sed la problemo estas en la kerno de Postgres.
Mi trovis diskuton pri ĉi tiu funkcio. Kaj li skribis, ke ni renkontis ĉi tiun funkcion kaj ĝi estis malagrabla, persono vekiĝis nokte por ekscii, kio ĝi estas.
La komunumo respondis, "Ho, ni vere devas ripari ĝin."
Mi havas simplan analogion. Se vi promenas en ŝuo, kiu havas sablograjnon en ĝi, tiam, principe, vi povas pluiri - neniu problemo. Se vi vendas botojn al miloj da homoj, tiam ni faru botojn tute sen sablo. Kaj se unu el la uzantoj de viaj ŝuoj kuros maratonon, tiam vi volas fari tre bonajn ŝuojn, kaj poste grimpi ilin al ĉiuj viaj uzantoj. Kaj tiaj neatenditaj uzantoj ĉiam estas en la nuba medio. Ĉiam estas uzantoj kiuj ekspluatas la areton en iu originala maniero. Vi ĉiam devas prepari por ĉi tio.
Kion ni lernis ĉi tie? Ni lernis simplan aferon: la plej grava afero estas klarigi al la komunumo, ke ekzistas problemo. Se la komunumo rekonis la problemon, tiam estiĝas natura konkurenco por solvi la problemon. Ĉar ĉiuj volas solvi gravan problemon. Ĉiuj vendistoj, ĉiuj hakistoj komprenas, ke ili mem povas paŝi sur ĉi tiun rastilon, do ili volas forigi ilin.
Se vi laboras pri problemo, sed ĝi ĝenas neniun krom vi, sed vi laboras pri ĝi sisteme kaj ĝi finfine estas konsiderata problemo, tiam via tira peto certe estos akceptita. Via flikaĵo estos akceptita, viaj plibonigoj aŭ eĉ petoj por plibonigoj estos reviziitaj de la komunumo. Fine de la tago, ni plibonigas la datumbazon unu por la alia.
Interesa datumbazo estas Greenplum. Ĝi estas tre paralela datumbazo bazita sur la kodbazo Postgres, kiun mi tre konas.
Kaj Greenplum havas interesajn funkciojn - aldonu optimumigitajn tabelojn. Ĉi tiuj estas tabeloj, kiujn vi povas rapide aldoni. Ili povas esti aŭ kolonecaj aŭ vicaj.
Sed ne estis grupigo, t.e. ne estis funkcio, kie vi povas aranĝi la datumojn situantajn en la tabelo laŭ la ordo kiu estas en unu el la indeksoj.
La uloj de la taksio venis al mi kaj diris: “Andrey, vi konas Postgres. Kaj ĉi tie estas preskaŭ la sama. Ŝanĝu al 20 minutoj. Vi prenu ĝin kaj faru ĝin." Mi pensis, ke jes, mi konas Postgres, ŝanĝante dum 20 minutoj - mi devas fari ĉi tion.
Sed ne, ĝi ne estis 20 minutoj, mi skribis ĝin dum monatoj. En la konferenco de PgConf.Russia, mi kontaktis Heikki Linakangas el Pivotal kaj demandis: “Ĉu estas problemoj pri ĉi tio? Kial ne ekzistas aldona optimumigita tabelgrupo?" Li diras: "Vi prenas la datumojn. Vi ordigas, vi rearanĝas. Ĝi estas nur laboro." Mi: "Ho jes, vi nur bezonas preni ĝin kaj fari ĝin." Li diras: "Jes, ni bezonas liberajn manojn por fari ĉi tion." Mi pensis, ke mi certe devas fari ĉi tion.
Kaj kelkajn monatojn poste mi prezentis tiran peton kiu efektivigis ĉi tiun funkcion. Ĉi tiu tirpeto estis reviziita de Pivotal kune kun la komunumo. Kompreneble, estis cimoj.
Sed la plej interesa afero estas, ke kiam ĉi tiu tirpeto estis kunfandita, cimoj estis trovitaj en Greenplum mem. Ni trovis, ke amasaj tabeloj foje rompas transakcecon kiam amasigitaj. Kaj ĉi tio estas afero, kiu devas esti riparita. Kaj ŝi estas en la loko, kiun mi ĵus tuŝis. Kaj mia natura reago estis - bone, mi ankaŭ faru ĉi tion.
Mi riparis ĉi tiun cimon. Sendis tirpeton al la fiksistoj. Li estis mortigita.
Post tio montriĝis, ke ĉi tiu funkcieco devas esti akirita en la versio de Greenplum por PostgreSQL 12. Tio estas, la 20-minuta aventuro daŭras kun novaj interesaj aventuroj. Estis interese tuŝi la nunan evoluon, kie la komunumo tranĉas novajn kaj plej gravajn funkciojn. Ĝi estas frostigita.
Sed ĝi ne finiĝis tie. Post ĉio, montriĝis, ke ni bezonas verki dokumentadon por ĉio ĉi.
Mi komencis verki dokumentadon. Feliĉe venis la dokumentaristoj de Pivotal. La angla estas ilia gepatra lingvo. Ili helpis min pri la dokumentado. Fakte, ili mem reverkis tion, kion mi proponis, en realan anglan.
Kaj ĉi tie, ŝajne, la aventuro finiĝis. Kaj ĉu vi scias, kio okazis tiam? La uloj de la taksio venis al mi kaj diris: "Estas ankoraŭ du aventuroj, ĉiu por 10 minutoj." Kaj kion mi diru al ili? Mi diris, ke nun mi donos raporton laŭskale, poste ni vidos viajn aventurojn, ĉar ĉi tio estas interesa laboro.
Kion ni lernis el ĉi tiu kazo? Ĉar labori kun malferma fonto ĉiam laboras kun specifa persono, ĝi ĉiam laboras kun la komunumo. Ĉar en ĉiu etapo mi laboris kun iu programisto, iu testisto, iu retpirato, iu dokumentaristo, iu arkitekto. Mi ne laboris kun Greenplum, mi laboris kun homoj ĉirkaŭ Greenplum.
Sed! Estas alia grava punkto - ĝi estas nur laboro. Tio estas, vi venas, trinkas kafon, skribas kodon. Ĉiaj simplaj invariantoj funkcias. Faru ĝin normale - estos bone! Kaj ĝi estas sufiĉe interesa laboro. Estas peto por ĉi tiu laboro de Yandex.Cloud-klientoj, uzantoj de niaj aretoj kaj ene de Yandex kaj ekstere. Kaj mi pensas, ke pliiĝos la nombro da projektoj, en kiuj ni partoprenas, kaj ankaŭ pliiĝos la profundo de nia engaĝiĝo.
Tio estas ĉio. Ni transiru al la demandoj.
Demanda sesio
Saluton! Ni havas alian demandon kaj respondsesion. Kaj en la studio Andrej Borodin. Ĉi tiu estas la persono, kiu ĵus rakontis al vi pri la kontribuo de Yandex.Cloud kaj Yandex al malferma fonto. Nia raporto nun ne temas tute pri la Nubo, sed samtempe ni baziĝas sur tiaj teknologioj. Sen tio, kion vi faris en Yandex, ne ekzistus servo en Yandex.Cloud, do dankon de mi persone. Kaj la unua demando de la elsendo: "Sur kio estas skribita ĉiu el la projektoj, kiujn vi menciis?"
La rezerva sistemo en WAL-G estas skribita en Go. Ĉi tiu estas unu el la pli novaj projektoj pri kiuj ni laboris. Li estas laŭvorte nur 3 jarojn maljuna. Kaj datumbazo ofte temas pri fidindeco. Kaj tio signifas, ke la datumbazoj estas sufiĉe malnovaj kaj ili estas kutime skribitaj en C. La projekto Postgres komenciĝis antaŭ ĉirkaŭ 30 jaroj. Tiam la C89 estis la ĝusta elekto. Kaj Postgres estas skribita sur ĝi. Pli modernaj datumbazoj kiel ekzemple ClickHouse estas kutime skribitaj en C++. Ĉiu sistema evoluo baziĝas ĉirkaŭ C kaj C++.
Demando de nia financa administranto, kiu respondecas pri elspezoj ĉe Cloud: "Kial Cloud elspezas monon por subteni malferman fonton?"
Estas simpla respondo por la financa administranto ĉi tie. Ni faras ĉi tion por plibonigi niajn servojn. En kiaj manieroj ni povas fari pli bone? Ni povas fari aferojn pli efike, pli rapide kaj fari aferojn pli skaleblaj. Sed por ni ĉi tiu rakonto temas ĉefe pri fidindeco. Ekzemple, en rezerva sistemo ni revizias 100% de la diakiloj kiuj aplikas al ĝi. Ni scias, kio estas la kodo. Kaj ni pli komfortas lanĉi novajn versiojn al produktado. Tio estas, antaŭ ĉio, temas pri konfido, pri preteco por disvolviĝo kaj pri fidindeco
Alia demando: "Ĉu la postuloj de eksteraj uzantoj, kiuj loĝas en Yandex.Cloud, diferencas de internaj uzantoj, kiuj loĝas en la interna Nubo?"
La ŝarĝa profilo estas, kompreneble, malsama. Sed el la vidpunkto de mia fako, ĉiuj specialaj kaj interesaj kazoj estas kreitaj sur ne-norma ŝarĝo. Programistoj kun imago, programistoj kiuj faras la neatenditan, estas same verŝajne troviĝi kaj interne kaj ekstere. Ĉi-rilate, ni ĉiuj estas proksimume samaj. Kaj, verŝajne, la sola grava trajto ene de la Yandex-operacio de datumbazoj estos, ke en Yandex ni havas instruon. Iam iu havebleca zono tute iras en ombron, kaj ĉiuj Yandex-servoj devas iel daŭre funkcii malgraŭ tio. Ĉi tio estas malgranda diferenco. Sed ĝi kreas multan esplordisvolviĝon ĉe la interfaco de la datumbazo kaj reto-stako. Alie, eksteraj kaj internaj instalaĵoj generas la samajn petojn por funkcioj kaj similajn petojn por plibonigi fidindecon kaj rendimenton.
Sekva demando: "Kiel vi persone sentas pri tio, ke multe de tio, kion vi faras, estas uzata de aliaj Nuboj?" Ni ne nomos specifajn, sed multaj projektoj, kiuj estis faritaj en Yandex.Cloud, estas uzataj en aliulaj nuboj.
Ĉi tio estas mojosa. Unue, ĝi estas signo, ke ni faris ion ĝuste. Kaj ĝi gratas la egoon. Kaj ni estas pli certaj, ke ni faris la ĝustan decidon. Aliflanke, jen la espero, ke estonte tio alportos al ni novajn ideojn, novajn petojn de triaj uzantoj. Plej multaj aferoj en GitHub estas kreitaj de individuaj sistemadministrantoj, individuaj DBA-oj, individuaj arkitektoj, individuaj inĝenieroj, sed foje homoj kun sistema sperto venas kaj diras, ke en 30% de certaj kazoj ni havas ĉi tiun problemon kaj ni pensu pri kiel solvi ĝin. Jen kion ni plej antaŭĝojas. Ni antaŭĝojas kunhavigi spertojn kun aliaj nubaj platformoj.
Vi multe parolis pri la maratono. Mi scias, ke vi kuris maratonon en Moskvo. Tial? Superis la ulojn de PostgreSQL?
Ne, Oleg Bartunov kuras tre rapide. Li finis unu horon antaŭ mi. Ĝenerale, mi estas kontenta pri kiom malproksime mi atingis. Por mi, nur fini estis atingo. Ĝenerale, estas surprize, ke estas tiom da kuristoj en la postgresa komunumo. Ŝajnas al mi, ke ekzistas ia rilato inter aerobiaj sportoj kaj la deziro por sistemaj programado.
Ĉu vi diras, ke ne estas kuristoj ĉe ClickHouse?
Mi certe scias, ke ili estas tie. ClickHouse ankaŭ estas datumbazo. Cetere, Oleg nun skribas al mi: "Ĉu ni kuru post la raporto?" Ĉi tio estas bonega ideo.
Alia demando de la elsendo de Nikita: "Kial vi riparis la cimon en Greenplum mem kaj ne donis ĝin al junuloj?" Vere, ne estas tre klare, kio estas la cimo kaj en kiu servo, sed ĝi verŝajne signifas tiun, pri kiu vi parolis.
Jes, principe, oni povus doni ĝin al iu. Estis nur la kodo, kiun mi ĵus ŝanĝis. Kaj estis nature daŭrigi fari ĝin tuj. Principe, la ideo kunhavigi kompetentecon kun la teamo estas bona ideo. Ni certe dividos taskojn de Greenplum inter ĉiuj membroj de nia divizio.
Ĉar ni parolas pri junuloj, jen demando. La persono decidis krei la unuan kommit en Postgres. Kion li devas fari por fari la unuan kompromiti?
Jen interesa demando: "Kie komenci?" Kutime estas sufiĉe malfacile komenci per io en la kerno. En Postgres, ekzemple, estas farenda listo. Sed fakte, ĉi tio estas folio de tio, kion ili provis fari, sed ne sukcesis. Ĉi tiuj estas komplikaj aferoj. Kaj kutime vi povas trovi kelkajn utilecojn en la ekosistemo, kelkajn etendojn plibonigeblajn, kiuj altiras malpli atenton de kernaj programistoj. Kaj, sekve, ekzistas pli da punktoj por kresko tie. Ĉe la Google Summer of code-programo, ĉiujare la postgres-komunumo prezentas multajn malsamajn temojn, kiuj povus esti traktitaj. Ĉi-jare ni havis, mi pensas, tri studentojn. Oni eĉ skribis en WAL-G pri temoj, kiuj estas gravaj por Yandex. En Greenplum, ĉio estas pli simpla ol en la Postgres-komunumo, ĉar Greenplum-piratoj tre bone traktas tirpetojn kaj komencas revizii tuj. Sendi flikaĵon al Postgres estas demando de monatoj, sed Greenplum venos post unu tago kaj vidos, kion vi faris. Alia afero estas, ke Greenplum bezonas solvi aktualajn problemojn. Greenplum ne estas vaste uzata, do trovi vian problemon estas sufiĉe malfacila. Kaj antaŭ ĉio, ni devas solvi problemojn, kompreneble.
fonto: www.habr.com