Üle vaadatakse Yandexi panus järgmistesse andmebaasidesse.
- Klõpsake nuppu Maja
- Odyssey
- Taastumine teatud ajahetkeni (WAL-G)
- PostgreSQL (sh logerrors, Amcheck, heapcheck)
- Roheline ploom
Video:
Tere, Maailm! Minu nimi on Andrei Borodin. Ja see, mida ma Yandex.Cloudis teen, on avatud relatsiooniandmebaaside arendamine Yandex.Cloudi ja Yandex.Cloudi klientide huvides.
Selles kõnes räägime väljakutsetest, millega avatud andmebaasid mastaapselt silmitsi seisavad. Miks see oluline on? Sest väikesed-väikesed probleemid, millest nagu sääsedki saavad siis elevandid. Nad muutuvad suureks, kui teil on palju klastreid.
Kuid see pole peamine. Juhtub uskumatuid asju. Asjad, mis juhtuvad ühel juhul miljonist. Ja pilvekeskkonnas peate selleks valmis olema, sest uskumatud asjad muutuvad suure tõenäosusega, kui midagi on mastaapselt olemas.
Aga! Mis on avatud andmebaaside eelis? Fakt on see, et teil on teoreetiline võimalus mis tahes probleemiga tegelemiseks. Teil on lähtekood, teil on programmeerimisalased teadmised. Kombineerime ja töötab.
Milliseid lähenemisviise on avatud lähtekoodiga tarkvaraga töötamisel?
- Kõige lihtsam on kasutada tarkvara. Kui kasutad protokolle, kui kasutad standardeid, kui kasutad vorminguid, kui kirjutad päringuid avatud lähtekoodiga tarkvaras, siis sa juba toetad seda.
- Te muudate selle ökosüsteemi suuremaks. Suurendate vea varajase avastamise tõenäosust. Suurendate selle süsteemi töökindlust. Suurendate arendajate kättesaadavust turul. Parandate seda tarkvara. Olete juba kaastööline, kui olete lihtsalt stiili hankinud ja seal midagi välja nuputanud.
- Teine arusaadav lähenemisviis on avatud lähtekoodiga tarkvara sponsoreerimine. Näiteks tuntud Google Summer of Code programm, kui Google maksab suurele hulgale õpilastele üle maailma arusaadavat raha, et nad arendaksid avatud tarkvaraprojekte, mis vastavad teatud litsentsimisnõuetele.
- See on väga huvitav lähenemine, sest see võimaldab tarkvaral areneda ilma fookust kogukonnalt eemale nihutamata. Google kui tehnoloogiagigant ei ütle, et me tahame seda funktsiooni, me tahame selle vea parandada ja see on koht, kus me peame kaevama. Google ütleb: "Tehke seda, mida teete. Jätkake tööd nii, nagu olete töötanud, ja kõik saab korda."
- Järgmine lähenemine avatud lähtekoodiga programmis osalemiseks on osalemine. Kui teil on probleem avatud lähtekoodiga tarkvaraga ja seal on arendajad, hakkavad teie arendajad probleeme lahendama. Need muudavad teie infrastruktuuri tõhusamaks, teie programme kiiremaks ja töökindlamaks.
Üks kuulsamaid Yandexi projekte avatud lähtekoodiga tarkvara valdkonnas on ClickHouse. See on andmebaas, mis sündis vastusena Yandex.Metrica ees seisvatele väljakutsetele.
Ja andmebaasina tehti see avatud lähtekoodiga, et luua ökosüsteem ja arendada seda koos teiste arendajatega (mitte ainult Yandexis). Ja nüüd on see suur projekt, millesse on kaasatud palju erinevaid ettevõtteid.
Yandex.Cloudis lõime ClickHouse'i Yandexi objektide salvestusruumi peale, st pilvesalvestuse peale.
Miks on see pilves oluline? Sest mis tahes andmebaas töötab selles kolmnurgas, selles püramiidis, selles mälutüüpide hierarhias. Teil on kiired, kuid väikesed registrid ja odavad suured, kuid aeglased SSD-d, kõvakettad ja mõned muud plokkseadmed. Ja kui olete püramiidi tipus tõhus, on teil kiire andmebaas. Kui olete selle püramiidi allosas tõhus, siis on teil skaleeritud andmebaas. Ja sellega seoses on altpoolt teise kihi lisamine loogiline lähenemine andmebaasi skaleeritavuse suurendamisele.
Kuidas seda teha saaks? See on selle raporti oluline punkt.
- Võiksime ClickHouse'i rakendada MDS-i kaudu. MDS on Yandexi sisemine pilvesalvestusliides. See on keerulisem kui tavaline S3 protokoll, kuid sobib paremini plokkseadme jaoks. See on parem andmete salvestamiseks. See nõuab rohkem programmeerimist. Programmeerijad programmeerivad, see on isegi hea, huvitav.
- S3 on levinum lähenemisviis, mis muudab liidese lihtsamaks teatud tüüpi töökoormusega väiksema kohandumise hinnaga.
Loomulikult, soovides pakkuda funktsionaalsust kogu ClickHouse'i ökosüsteemile ja teha Yandex.Cloudis vajalikke ülesandeid, otsustasime veenduda, et kogu ClickHouse'i kogukond saaks sellest kasu. Rakendasime ClickHouse'i üle S3, mitte ClickHouse'i üle MDS-i. Ja see on palju tööd.
Lingid:
"Failisüsteemi abstraktsioonikiht"
"AWS SDK S3 integreerimine"
"IDiski liidese baasrakendus S3 jaoks"
"Logisalvestusmootorite integreerimine IDiski liidesega"
"S3 ja SeekableReadBufferi logimootori tugi"
"Storage Stripe Log S3 tugi"
"Storage MergeTree esialgne tugi S3 jaoks"
"MergeTree täielik tugi S3 jaoks"
"Support ReplicatedMergeTree over S3"
"Lisa s3 salvestusruumi vaikemandaadid ja kohandatud päised"
"S3 dünaamilise puhverserveri konfiguratsiooniga"
"S3 puhverserveri lahendajaga"
See on tõmbetaotluste loend virtuaalse failisüsteemi juurutamiseks ClickHouse'is. See on suur hulk tõmbamistaotlusi.
Lingid:
"DiskS3 kõvalinkide optimaalne rakendamine"
"S3 HTTP klient – vältige vastusevoo mällu kopeerimist"
Vältige S3 HTTP-s kogu vastusevoo mällu kopeerimist
klient"
"Võimalus S3 ketta faile vahemällu märkida ja indekseerida"
"Teisalda osad DiskLocalist DiskS3-le paralleelselt"
Kuid töö sellega ei lõppenud. Pärast funktsiooni loomist tuli selle funktsiooni optimeerimiseks veel tööd teha.
Lingid:
"Lisa SelectedRows ja SelectedBytes sündmused"
"Lisa profiilisündmused S3 päringust saidile system.events"
"Lisa QueryTimeMicroseconds, SelectQueryTimeMicroseconds ja InsertQueryTimeMicroseconds"
Ja siis oli vaja teha see diagnoositavaks, seadistada monitooring ja muuta see juhitavaks.
Ja seda kõike tehti selleks, et kogu kogukond, kogu ClickHouse'i ökosüsteem sai selle töö tulemuse.
Liigume edasi tehingute andmebaaside juurde, OLTP andmebaaside juurde, mis on mulle isiklikult lähedasemad.
See on avatud lähtekoodiga DBMS-i arendusosakond. Need tüübid teevad tänavamaagiat tehingute avatud andmebaaside täiustamiseks.
Üks projektidest, mille näitel saame rääkida, kuidas ja mida me teeme, on Connection Pooler Postgresis.
Postgres on protsesside andmebaas. See tähendab, et andmebaasis peaks olema võimalikult vähe tehinguid käsitlevaid võrguühendusi.
Seevastu pilvekeskkonnas on tüüpiline olukord, kui ühte klastrisse tuleb korraga tuhat ühendust. Ja ühenduste ühendaja ülesanne on pakkida tuhat ühendust väikesesse arvu serveriühendustesse.
Võime öelda, et ühenduse ühendaja on telefonioperaator, kes korraldab baidid ümber nii, et need jõuaksid tõhusalt andmebaasi.
Kahjuks ei ole ühtegi head venekeelset sõna ühenduse ühendaja jaoks. Mõnikord nimetatakse seda multiplekseriühendusteks. Kui tead, kuidas ühenduspoolerit nimetada, siis öelge mulle kindlasti, räägin väga hea meelega õiges vene tehnikakeeles.
Uurisime hallatava postgresi klastri jaoks sobivaid ühenduste ühendajaid. Ja PgBouncer oli meie jaoks parim valik. Kuid meil tekkis PgBounceriga mitmeid probleeme. Palju aastaid tagasi andis Volodya Borodin aruandeid, et kasutame PgBouncerit, meile meeldib kõik, kuid on nüansse, on, mille kallal töötada.
Ja me töötasime. Parandasime tekkinud probleemid, parandasime Bouncerit ja proovisime tõmbetaotlusi ülesvoolu suunata. Kuid põhimõttelise ühe keermega oli raske töötada.
Pidime lapitud Bounceritelt kaskaade koguma. Kui meil on palju ühe keermega põrkemängijaid, kantakse ülemise kihi ühendused üle põrkeseadmete sisemisele kihile. See on halvasti juhitud süsteem, mida on raske ehitada ja edasi-tagasi skaleerida.
Jõudsime järeldusele, et lõime oma ühenduse ühendaja, mille nimi on Odyssey. Kirjutasime selle nullist.
2019. aastal esitlesin PgConi konverentsil seda basseini arendajate kogukonnale. Nüüd on meil GitHubis veidi alla 2 tärni, st projekt on elus, projekt on populaarne.
Ja kui loote Yandex.Cloudis Postgresi klastri, on see sisseehitatud Odysseyga klaster, mis klastri edasi-tagasi skaleerimisel konfigureeritakse ümber.
Mida me sellest projektist õppisime? Konkureeriva projekti käivitamine on alati agressiivne samm, see on äärmuslik meede, kui ütleme, et on probleeme, mis ei lahene piisavalt kiiresti, ei lahene meile sobivate ajavahemike järel. Kuid see on tõhus meede.
PgBouncer hakkas kiiremini arenema.
Ja nüüd on ilmunud teised projektid. Näiteks pgagroal, mille on välja töötanud Red Hati arendajad. Nad taotlevad sarnaseid eesmärke ja viivad ellu sarnaseid ideid, kuid loomulikult oma spetsiifikaga, mis on pgagroali arendajatele lähemal.
Teine postgresi kogukonnaga töötamise juhtum on ajahetke taastamine. See on taastumine pärast ebaõnnestumist, see on taastamine varukoopiast.
Varukoopiaid on palju ja need on kõik erinevad. Peaaegu igal Postgresi tarnijal on oma varulahendus.
Kui võtta kõik varusüsteemid, luua tunnusmaatriks ja naljaga pooleks arvutada selles maatriksis determinant, on see null. Mida see tähendab? Mis siis, kui võtate konkreetse varukoopiafaili, ei saa seda kõigist teistest tükkidest kokku panna. See on ainulaadne oma teostuselt, unikaalne oma eesmärgi poolest, see on ainulaadne ideede poolest, mis sellesse on põimitud. Ja nad kõik on spetsiifilised.
Sel ajal, kui me selle probleemiga töötasime, käivitas CitusData WAL-G projekti. See on varusüsteem, mis loodi pilvekeskkonda silmas pidades. Nüüd on CitusData juba Microsofti osa. Ja sel hetkel meeldisid meile väga WAL-G esialgsetes väljaannetes esitatud ideed. Ja me hakkasime sellesse projekti panustama.
Nüüd on selles projektis palju kümneid arendajaid, kuid WAL-G 10 parima panustaja hulgas on 6 Yandexoidi. Tõime sinna palju oma ideid. Ja loomulikult juurutasime need ise, katsetasime ise, rullisime ise tootmisse, kasutame ise, mõtleme ise välja, kuhu edasi liikuda, samas suheldes suure WAL-G kogukonnaga.
Ja meie vaatenurgast on nüüd see varusüsteem, sealhulgas meie jõupingutusi arvesse võttes, muutunud pilvekeskkonna jaoks optimaalseks. See on Postgresi pilves varundamise parim hind.
Mida see tähendab? Propageerisime üsna suurt ideed: varundamine peaks olema turvaline, odav ja võimalikult kiire taastamine.
Miks peaks opereerimine odav olema? Kui midagi pole katki, ei peaks te teadma, et teil on varukoopiaid. Kõik töötab hästi, raiskate võimalikult vähe protsessorit, kasutate võimalikult vähe kettaressursse ja saadate võrku võimalikult vähe baite, et mitte segada oma väärtuslike teenuste koormust.
Ja kui kõik läheb katki, näiteks admin kukutas andmed, midagi läks valesti ja teil on vaja kiiresti minevikku tagasi minna, saate kogu rahaga taastuda, sest soovite, et teie andmed oleksid kiiresti ja terved.
Ja me propageerisime seda lihtsat ideed. Ja meile tundub, et meil õnnestus see ellu viia.
Kuid see pole veel kõik. Tahtsime veel üht väikest asja. Tahtsime palju erinevaid andmebaase. Mitte kõik meie kliendid ei kasuta Postgresi. Mõned inimesed kasutavad MySQL-i, MongoDB-d. Kogukonnas on FoundationDB-d toetanud teised arendajad. Ja see nimekiri täieneb pidevalt.
Kogukonnale meeldib idee, et andmebaasi käitatakse hallatud keskkonnas pilves. Ja arendajad haldavad oma andmebaase, mida saab meie varundussüsteemiga koos Postgresiga ühtlaselt varundada.
Mida me sellest loost õppisime? Meie kui arendusdivisjoni toode ei ole koodiread, see ei ole avaldused, see ei ole failid. Meie toode ei ole pull taotlused. Need on ideed, mida me kogukonnale edastame. See on tehnoloogiline ekspertiis ja tehnoloogia liikumine pilvekeskkonna suunas.
On olemas selline andmebaas nagu Postgres. Mulle meeldib kõige rohkem Postgresi tuum. Veedan palju aega Postgresi tuuma arendamisel kogukonnaga.
Kuid siin tuleb öelda, et Yandex.Cloudil on hallatavate andmebaaside sisemine installimine. Ja see algas juba ammu Yandex.Mailis. Teadmised, mis on nüüdseks juhtinud Postgresi, kogunesid siis, kui post tahtis Postgresi kolida.
Mailil on pilvele väga sarnased nõuded. See nõuab, et saaksite oma andmete mis tahes punktis ootamatult eksponentsiaalselt kasvada. Ja meil oli juba koormatud sadade miljonite postkastidega tohutul hulgal kasutajatel, kes esitavad pidevalt palju taotlusi.
Ja see oli Postgresi arendavale meeskonnale üsna tõsine väljakutse. Sel ajal teavitati kogukonda kõigist tekkinud probleemidest. Ja need probleemid said parandatud ja kogukonna poolt kohati parandatud isegi mõne teise andmebaasi tasulise toe tasemel ja isegi paremini. See tähendab, et saate saata PgSQL-häkkerile kirja ja saada vastuse 40 minuti jooksul. Tasuline tugi mõnes andmebaasis võib arvata, et prioriteetseid asju on rohkem kui teie viga.
Nüüd on Postgresi sisemine installimine mõned petabaidid andmeid. Need on mõned miljonid päringud sekundis. Need on tuhanded klastrid. See on väga mastaapne.
Kuid on nüanss. See elab mitte väljamõeldud võrgudraividel, vaid üsna lihtsal riistvaral. Ja seal on testkeskkond spetsiaalselt huvitavate uute asjade jaoks.
Ja teatud hetkel saime testkeskkonnas teate, mis viitas andmebaasiindeksite sisemiste invariantide rikkumisele.
Invariant on mingi suhe, mida me eeldame alati hoidma.
Meie jaoks väga kriitiline olukord. See näitab, et mõned andmed võivad olla kadunud. Ja andmete kadu on midagi täiesti katastroofilist.
Üldine idee, mida me hallatavates andmebaasides järgime, on see, et isegi pingutades on andmete kaotamine keeruline. Isegi kui eemaldate need tahtlikult, peate siiski pikka aega nende puudumist ignoreerima. Andmeturve on religioon, mida me üsna usinalt järgime.
Ja siin tekib olukord, mis viitab sellele, et võib tekkida olukord, milleks me ei pruugi olla valmis. Ja me hakkasime selleks olukorraks valmistuma.
Esimese asjana matsime nende tuhandete kobarate palgid maha. Leidsime, millised klastrid asusid probleemse püsivaraga ketastel, mis kaotasid andmelehtede värskendused. Märgistas kõik Postgresi andmekoodid. Ja need sõnumid, mis viitavad sisemiste invariantide rikkumistele, märkisime koodiga, mis on mõeldud andmete riknemise tuvastamiseks.
Selle plaastri võttis kogukond praktiliselt ilma suurema aruteluta omaks, sest igal konkreetsel juhul oli näha, et midagi halba on juhtunud ja sellest tuli logile teatada.
Pärast seda jõudsime selleni, et meil on seire, mis kontrollib logisid. Ja kahtlaste teadete korral äratab ta korrapidaja üles ja korrapidaja parandab ära.
Aga! Logide skannimine on odav operatsioon ühes klastris ja tuhande klastri jaoks katastroofiliselt kallis.
Kirjutasime laiendi nimega . See loob vaate andmebaasist, kus saab odavalt ja kiiresti valida statistikat varasemate vigade kohta. Ja kui meil on vaja valveametnikku äratada, saame sellest teada ilma gigabaidiste failide skannimiseta, vaid räsitabelist paar baiti eraldades.
See laiendus on vastu võetud näiteks hoidlas for . Kui soovite seda kasutada, saate selle ise installida. Loomulikult on see avatud lähtekoodiga.
Kuid see pole veel kõik. Hakkasime kasutama kogukonna loodud laiendust Amcheck, et leida indeksitest muutumatuid rikkumisi.
Ja saime teada, et kui kasutate seda suures mahus, on vigu. Hakkasime neid parandama. Meie parandused on vastu võetud.
Avastasime, et see laiendus ei saa analüüsida GiST ja GIT indekseid. Panime neid toetama. Kuid kogukond alles arutab seda toetust, sest see on suhteliselt uus funktsioon ja seal on palju üksikasju.
Ja avastasime ka, et kontrollides indekseid rikkumiste suhtes replikatsioonijuhil, ülemseadmel, töötab kõik hästi, kuid koopiatel, jälgijal pole korruptsiooniotsing nii tõhus. Kõiki invariante ei kontrollita. Ja üks invariant häiris meid väga. Ja me veetsime poolteist aastat kogukonnaga suheldes, et võimaldada koopiate kontrollimist.
Kirjutasime koodi, mis peaks järgima kõiki can... protokolle. Arutasime seda plaastrit mõnda aega Peter Gaghaniga Crunchy Datast. Selle paiga vastuvõtmiseks pidi ta Postgresis olemasolevat B-puud veidi muutma. Ta võeti vastu. Ja nüüd on ka koopiate indeksite kontrollimine muutunud piisavalt tõhusaks, et tuvastada leitud rikkumisi. See tähendab, et need on rikkumised, mida võivad põhjustada ketta püsivara vead, Postgresi vead, Linuxi tuuma vead ja riistvaraprobleemid. Üsna ulatuslik loetelu probleemide allikatest, mille jaoks me valmistusime.
Kuid peale indeksite on veel selline osa nagu hunnik ehk koht, kus andmeid hoitakse. Ja invariante pole palju, mida saaks kontrollida.
Meil on laiendus nimega Heapcheck. Hakkasime seda arendama. Ja paralleelselt hakkas EnterpriseDB ettevõte koos meiega ka moodulit kirjutama, mida nad nimetasid samamoodi Heapcheckiks. Ainult meie nimetasime seda PgHeapcheckiks ja nemad nimetasid seda lihtsalt Heapcheckiks. Neil on see sarnaste funktsioonidega, veidi erinev signatuur, kuid samade ideedega. Nad rakendasid neid mõnes kohas veidi paremini. Ja nad postitasid selle varem avatud lähtekoodiga.
Ja nüüd me arendame nende laienemist, sest see pole enam nende laienemine, vaid kogukonna laienemine. Ja tulevikus on see osa tuumast, mida tarnitakse kõigile, et nad saaksid tulevastest probleemidest ette teada.
Kohati jõudsime isegi järeldusele, et meie seiresüsteemides on valepositiivseid tulemusi. Näiteks 1C süsteem. Andmebaasi kasutamisel kirjutab Postgres sinna mõnikord andmeid, mida ta saab lugeda, kuid pg_dump ei saa lugeda.
See olukord näis meie probleemide tuvastamise süsteemi jaoks korruptsioonina. Korrapidaja äratati. Korrapidaja vaatas, mis toimub. Mõne aja pärast tuli klient ja ütles, et mul on probleeme. Teenindaja selgitas, milles probleem. Kuid probleem on Postgresi tuumas.
Leidsin selle funktsiooni kohta arutelu. Ja ta kirjutas, et puutusime kokku selle funktsiooniga ja see oli ebameeldiv, inimene ärkas öösel üles, et aru saada, mis see on.
Kogukond vastas: "Oh, me peame selle tõesti parandama."
Mul on lihtne analoogia. Kui kõnnid jalanõus, mille sees on liivatera, siis põhimõtteliselt võid edasi liikuda – pole probleemi. Kui müüte saapaid tuhandetele inimestele, siis tehkem saapad üldse ilma liivata. Ja kui üks teie kingade kasutajatest jookseb maratoni, siis soovite teha väga häid jalatseid ja seejärel skaleerida need kõigile oma kasutajatele. Ja sellised ootamatud kasutajad on alati pilvekeskkonnas. Alati leidub kasutajaid, kes kasutavad klastrit mingil originaalsel viisil ära. Selleks peate alati valmistuma.
Mida me siin õppisime? Õppisime lihtsa asja: kõige tähtsam on kogukonnale selgitada, et probleem on olemas. Kui kogukond on probleemi teadvustanud, siis tekib loomulik konkurents probleemi lahendamiseks. Sest kõik tahavad lahendada olulist probleemi. Kõik müüjad, kõik häkkerid mõistavad, et nad võivad ise sellele rehale astuda, seega tahavad nad need kõrvaldada.
Kui töötate probleemi kallal, kuid see ei häiri kedagi peale teie, kuid töötate selle kallal süstemaatiliselt ja lõpuks peetakse seda probleemiks, siis võetakse teie tõmbamistaotlus kindlasti vastu. Teie plaaster võetakse vastu, kogukond vaatab teie parandused või isegi parendustaotlused üle. Päeva lõpuks muudame andmebaasi üksteise jaoks paremaks.
Huvitav andmebaas on Greenplum. See on väga paralleelne andmebaas, mis põhineb Postgresi koodibaasil, millega olen väga tuttav.
Ja Greenplumil on huvitav funktsionaalsus – lisage optimeeritud tabelid. Need on tabelid, mida saate kiiresti lisada. Need võivad olla kas veerud või rida.
Kuid puudus klasterdamine, st puudus funktsionaalsus, kus saaks tabelis olevaid andmeid järjestada vastavalt järjestusele, mis on ühes indeksitest.
Taksopoisid tulid minu juurde ja ütlesid: "Andrey, tead Postgresi. Ja siin on see peaaegu sama. Lülituge 20 minutile. Sa võtad selle ja teed seda." Mõtlesin, et jah, ma tean Postgresi, lülitub 20 minutiks – ma pean seda tegema.
Aga ei, see ei olnud 20 minutit, ma kirjutasin seda kuude jooksul. PgConf.Russia konverentsil pöördusin Pivotalist Heikki Linakangase poole ja küsisin: “Kas sellega on probleeme? Miks pole lisatud optimeeritud tabeliklastrit? Ta ütleb: "Te võtate andmed. Sorteerite, korraldate ümber. See on lihtsalt töö." Mina: "Oh, jah, sa pead lihtsalt võtma ja tegema." Ta ütleb: "Jah, selleks on meil vaja vabu käsi." Mõtlesin, et pean seda kindlasti tegema.
Ja paar kuud hiljem esitasin tõmbamistaotluse, mis seda funktsiooni rakendas. Pivotal vaatas selle tõmbamistaotluse koos kogukonnaga üle. Muidugi oli vigu.
Kuid kõige huvitavam on see, et selle tõmbamistaotluse ühendamisel leiti vead Greenplumis endas. Oleme avastanud, et kuhjatabelid rikuvad mõnikord klasterdamisel tehinguid. Ja see on asi, mis vajab parandamist. Ja ta on kohas, mida ma just puudutasin. Ja minu loomulik reaktsioon oli – olgu, las ma teen ka seda.
Parandasin selle vea. Saatis tõmbetaotluse fikseerijatele. Ta tapeti.
Pärast mida selgus, et see funktsionaalsus tuleb hankida Greenplumi versioonis PostgreSQL 12 jaoks. See tähendab, et 20-minutiline seiklus jätkub uute huvitavate seiklustega. Huvitav oli puudutada praegust arengut, kus kogukond lõikab uusi ja kõige olulisemaid jooni. See on külmunud.
Kuid see ei lõppenud sellega. Pärast kõike selgus, et selleks kõigeks on vaja dokumentatsioon kirjutada.
Hakkasin dokumente kirjutama. Õnneks tulid Pivotali dokumentalistid kaasa. Inglise keel on nende emakeel. Nad aitasid mind dokumentatsiooniga. Tegelikult kirjutasid nad ise minu pakutu päris inglise keelde ümber.
Ja siin näib, et seiklus lõppes. Ja kas sa tead, mis siis juhtus? Taksopoisid tulid minu juurde ja ütlesid: "On veel kaks seiklust, kumbki 10 minutit." Ja mida ma peaksin neile ütlema? Ütlesin, et nüüd annan mastaapse ettekande, siis näeme teie seiklusi, sest see on huvitav töö.
Mida me sellest juhtumist õppisime? Kuna avatud lähtekoodiga töötamine on alati töötamine konkreetse inimesega, on see alati koostöö kogukonnaga. Sest igal etapil töötasin mõne arendaja, mõne testija, mõne häkkeri, mõne dokumentalisti, mõne arhitektiga. Ma ei töötanud Greenplumiga, ma töötasin Greenplumi ümbritsevate inimestega.
Aga! On veel üks oluline punkt - see on lihtsalt töö. See tähendab, et tuled, jood kohvi, kirjutad koodi. Igasugused lihtsad invariandid töötavad. Tehke seda tavaliselt - see läheb hästi! Ja see on päris huvitav töö. Selle töö jaoks on taotluse esitanud Yandex.Cloudi kliendid, meie klastrite kasutajad nii Yandexis kui ka väljaspool. Ja ma arvan, et projektide arv, milles me osaleme, suureneb ja ka meie kaasamise sügavus suureneb.
See on kõik. Liigume edasi küsimuste juurde.
Küsimuste seanss
Tere! Meil on veel üks küsimuste ja vastuste seanss. Ja stuudios Andrei Borodin. See on inimene, kes just rääkis teile Yandex.Cloudi ja Yandexi panusest avatud lähtekoodiga. Meie praegune aruanne ei puuduta ainult pilve, kuid samal ajal põhineme sellistel tehnoloogiatel. Ilma selleta, mida te Yandexis tegite, poleks Yandex.Cloudis teenust, seega tänan teid isiklikult. Ja esimene küsimus saatest: "Millele on kirjutatud iga teie mainitud projekt?"
Varundussüsteem WAL-G-s on kirjutatud Go keeles. See on üks uuemaid projekte, millega oleme töötanud. Ta on sõna otseses mõttes vaid 3-aastane. Ja andmebaas on sageli seotud usaldusväärsusega. Ja see tähendab, et andmebaasid on üsna vanad ja need on tavaliselt kirjutatud C keeles. Postgresi projekt sai alguse umbes 30 aastat tagasi. Siis oli C89 õige valik. Ja sellele on kirjutatud Postgres. Moodsamad andmebaasid nagu ClickHouse on tavaliselt kirjutatud C++ keeles. Kogu süsteemiarendus põhineb C-l ja C++-l.
Küsimus meie finantsjuhilt, kes vastutab Cloudis kulude eest: "Miks kulutab Cloud raha avatud lähtekoodiga toetamiseks?"
Siin on finantsjuhi jaoks lihtne vastus. Teeme seda oma teenuste paremaks muutmiseks. Millistel viisidel saame paremini hakkama? Saame teha asju tõhusamalt, kiiremini ja muuta asjad skaleeritavamaks. Kuid meie jaoks on see lugu eelkõige usaldusväärsus. Näiteks varusüsteemis vaatame üle 100% sellele kehtivatest paikadest. Me teame, mis kood on. Ja meil on mugavam uusi versioone tootmisse viia. See tähendab ennekõike kindlustunnet, arenguvalmidust ja usaldusväärsust
Teine küsimus: "Kas Yandex.Cloudis elavate väliste kasutajate nõuded erinevad sisemises pilves elavate kasutajate nõuded?"
Koormusprofiil on muidugi erinev. Kuid minu osakonna seisukohast on kõik erilised ja huvitavad juhtumid loodud mittestandardse koormusega. Fantaasiaga arendajaid, arendajaid, kes teevad ootamatusi, leidub tõenäoliselt nii sisemiselt kui ka väliselt. Selles suhtes oleme kõik ligikaudu ühesugused. Ja ilmselt on Yandexi andmebaaside toimimise ainus oluline funktsioon see, et Yandexis on meil õpetus. Mingil hetkel läheb mõni saadavuse tsoon täielikult varju ja kõik Yandexi teenused peavad sellest hoolimata kuidagi edasi toimima. See on väike erinevus. Kuid see loob andmebaasi ja võrguvirna liideses palju uurimistööd. Vastasel juhul genereerivad välis- ja sisepaigaldised samu taotlusi funktsioonide kohta ja sarnaseid taotlusi töökindluse ja jõudluse parandamiseks.
Järgmine küsimus: "Kuidas te isiklikult suhtute sellesse, et suurt osa teie tegemistest kasutavad teised pilved?" Me ei nimeta konkreetseid, kuid paljusid Yandex.Cloudis tehtud projekte kasutatakse teiste inimeste pilvedes.
See on lahe. Esiteks on see märk sellest, et oleme midagi õigesti teinud. Ja see kriibib ego. Ja oleme kindlamad, et tegime õige otsuse. Teisest küljest on see lootus, et tulevikus toob see meile uusi ideid, uusi taotlusi kolmandate osapoolte kasutajatelt. Enamiku GitHubi probleeme tekitavad üksikud süsteemiadministraatorid, üksikud DBA-d, üksikud arhitektid, üksikud insenerid, kuid mõnikord tulevad süstemaatilise kogemusega inimesed ja ütlevad, et 30% juhtudest on meil see probleem ja mõtleme, kuidas seda lahendada. See on see, mida me kõige rohkem ootame. Ootame kogemusi teiste pilveplatvormidega.
Sa rääkisid palju maratonist. Ma tean, et jooksite Moskvas maratoni. Tulemusena? Möödusid PostgreSQL-i poistest?
Ei, Oleg Bartunov jookseb väga kiiresti. Ta lõpetas minust tund aega ees. Üldiselt olen rahul sellega, kui kaugele ma jõudsin. Minu jaoks oli lihtsalt lõpetamine saavutus. Üldiselt on üllatav, et postgresi kogukonnas on nii palju jooksjaid. Mulle tundub, et aeroobse spordi ja süsteemse programmeerimise soovi vahel on mingi seos.
Kas soovite öelda, et ClickHouse'is pole jooksjaid?
Ma tean kindlalt, et nad on seal. ClickHouse on ka andmebaas. Muide, Oleg kirjutab mulle nüüd: "Kas lähme raporti järel jooksma?" See on suurepärane idee.
Veel üks küsimus Nikita saatest: "Miks te Greenplumi vea ise parandasite ega andnud seda juunioridele?" Tõsi, pole päris selge, mis viga on ja millises teenuses, kuid tõenäoliselt tähendab see seda, millest rääkisite.
Jah, põhimõtteliselt oleks võinud kellelegi kinkida. See oli lihtsalt kood, mille ma just muutsin. Ja oli loomulik seda kohe edasi teha. Põhimõtteliselt on idee jagada meeskonnaga teadmisi. Kindlasti jagame Greenplumi ülesandeid kõigi oma divisjoni liikmete vahel.
Kuna me räägime juunioridest, siis siin on küsimus. Isik otsustas luua esimese kohustuse Postgresis. Mida ta peab tegema, et teha esimene kohustus?
See on huvitav küsimus: "Kust alustada?" Tavaliselt on tuumas millegagi üsna raske alustada. Näiteks Postgresis on ülesannete nimekiri. Kuid tegelikult on see leht sellest, mida nad üritasid teha, kuid see ei õnnestunud. Need on keerulised asjad. Ja tavaliselt võite leida ökosüsteemist utiliite, laiendusi, mida saab täiustada, mis tõmbavad vähem tähelepanu kerneli arendajatele. Ja vastavalt sellele on seal kasvupunkte rohkem. Programmi Google Summer of code raames esitab postgresi kogukond igal aastal palju erinevaid teemasid, mida võiks käsitleda. Sel aastal oli meil vist kolm õpilast. Üks kirjutas isegi WAL-G-s Yandexi jaoks olulistel teemadel. Greenplumis on kõik lihtsam kui Postgresi kogukonnas, sest Greenplumi häkkerid suhtuvad tõmbetaotlustesse väga hästi ja hakkavad kohe üle vaatama. Plaastri saatmine Postgresile on kuude küsimus, kuid Greenplum tuleb päeva pärast ja vaatab, mida olete teinud. Teine asi on see, et Greenplum peab lahendama praegused probleemid. Greenplumi ei kasutata laialdaselt, seega on probleemi leidmine üsna keeruline. Ja ennekõike peame loomulikult lahendama probleemid.
Allikas: www.habr.com