Príspevok spoločnosti Yandex do nasledujúcich databáz bude skontrolovaný.
- clickhouse
- Odysea
- Zotavenie do určitého bodu v čase (WAL-G)
- PostgreSQL (vrátane logerrors, Amcheck, heapcheck)
- Zelená slivka
Video:
Ahoj svet! Moje meno je Andrey Borodin. A to, čo robím v Yandex.Cloud, je vývoj otvorených relačných databáz v záujme klientov Yandex.Cloud a Yandex.Cloud.
V tejto prednáške budeme hovoriť o výzvach, ktorým čelia otvorené databázy vo veľkom rozsahu. Prečo je to dôležité? Pretože malé, malé problémy, z ktorých sa ako z komárov stanú slony. Zväčšia sa, keď máte veľa zhlukov.
Ale to nie je to hlavné. Dejú sa neuveriteľné veci. Veci, ktoré sa stávajú v jednom z milióna prípadov. A v cloudovom prostredí na to musíte byť pripravení, pretože neuveriteľné veci sa stávajú vysoko pravdepodobné, keď niečo existuje vo veľkom rozsahu.
Ale! Aká je výhoda otvorených databáz? Faktom je, že máte teoretickú možnosť vysporiadať sa s akýmkoľvek problémom. Máte zdrojový kód, máte znalosti programovania. Skombinujeme to a funguje to.
Aké prístupy existujú pri práci na softvéri s otvoreným zdrojovým kódom?
- Najpriamejším prístupom je použitie softvéru. Ak používate protokoly, ak používate štandardy, ak používate formáty, ak píšete dotazy v open source softvéri, tak to už podporujete.
- Rozširujete jeho ekosystém. Zvýšite tým pravdepodobnosť skorého odhalenia chyby. Zvýšite spoľahlivosť tohto systému. Zvyšujete dostupnosť vývojárov na trhu. Vylepšujete tento softvér. Už ste prispievateľom, ak ste práve dostali štýl a niečo si tam pohrali.
- Ďalším pochopiteľným prístupom je sponzorovanie softvéru s otvoreným zdrojovým kódom. Napríklad známy program Google Summer of Code, kedy Google platí veľkému počtu študentov z celého sveta pochopiteľné peniaze, aby vyvíjali otvorené softvérové projekty, ktoré spĺňajú určité licenčné požiadavky.
- Toto je veľmi zaujímavý prístup, pretože umožňuje vývoj softvéru bez toho, aby sa pozornosť presunula od komunity. Google, ako technologický gigant, nehovorí, že túto funkciu chceme, chceme túto chybu opraviť a práve tu musíme kopať. Google hovorí: „Robte to, čo robíte. Len pokračujte v práci tak, ako ste doteraz pracovali a všetko bude v poriadku."
- Ďalším prístupom k účasti na open source je participácia. Keď máte problém s open source softvérom a existujú vývojári, vaši vývojári začnú problémy riešiť. Začnú robiť vašu infraštruktúru efektívnejšou, vaše programy rýchlejšie a spoľahlivejšie.
Jedným z najznámejších projektov Yandex v oblasti softvéru s otvoreným zdrojovým kódom je ClickHouse. Toto je databáza, ktorá sa zrodila ako odpoveď na výzvy, ktorým čelí Yandex.Metrica.
A ako databáza bola vytvorená v open source s cieľom vytvoriť ekosystém a rozvíjať ho spolu s ďalšími vývojármi (nielen v rámci Yandex). A teraz ide o veľký projekt, do ktorého je zapojených mnoho rôznych spoločností.
V Yandex.Cloud sme vytvorili ClickHouse na vrchole Yandex Object Storage, t. j. na vrchole cloudového úložiska.
Prečo je to dôležité v cloude? Pretože akákoľvek databáza funguje v tomto trojuholníku, v tejto pyramíde, v tejto hierarchii pamäťových typov. Máte rýchle, ale malé registre a lacné veľké, ale pomalé SSD, pevné disky a niektoré ďalšie blokové zariadenia. A ak ste efektívny na vrchole pyramídy, potom máte rýchlu databázu. ak ste efektívny na spodku tejto pyramídy, potom máte škálovanú databázu. A v tomto smere je pridanie ďalšej vrstvy zdola logickým prístupom k zvýšeniu škálovateľnosti databázy.
Ako by sa to dalo urobiť? Toto je dôležitý bod tejto správy.
- Mohli by sme implementovať ClickHouse cez MDS. MDS je interné rozhranie cloudového úložiska Yandex. Je zložitejší ako bežný protokol S3, ale je vhodnejší pre blokové zariadenie. Je to lepšie na zaznamenávanie údajov. Vyžaduje si to viac programovania. Programátori budú programovať, je to dokonca dobré, je to zaujímavé.
- S3 je bežnejší prístup, ktorý zjednodušuje rozhranie za cenu menšej adaptácie na určité typy pracovných zaťažení.
Prirodzene, keďže chceme poskytnúť funkčnosť celému ekosystému ClickHouse a vykonať úlohu, ktorá je potrebná v rámci Yandex.Cloud, rozhodli sme sa zabezpečiť, aby z toho mala úžitok celá komunita ClickHouse. Implementovali sme ClickHouse cez S3, nie ClickHouse cez MDS. A to je veľa práce.
odkazy:
"Vrstva abstrakcie súborového systému"
"Integrácia AWS SDK S3"
“Základná implementácia rozhrania IDisk pre S3”
"Integrácia motorov na ukladanie protokolov s rozhraním IDisk"
"Podpora logovacieho nástroja pre S3 a SeekableReadBuffer"
"Podpora Storage Stripe Log S3"
"Počiatočná podpora úložiska MergeTree pre S3"
"MergeTree plná podpora pre S3"
"Podpora ReplicatedMergeTree cez S3"
„Pridať predvolené poverenia a vlastné hlavičky pre úložisko S3“
"S3 s dynamickou konfiguráciou proxy"
"S3 s proxy prekladačom"
Toto je zoznam požiadaviek na stiahnutie na implementáciu virtuálneho súborového systému v ClickHouse. Ide o veľký počet žiadostí o stiahnutie.
odkazy:
"Optimálna implementácia pevných odkazov DiskS3"
„S3 HTTP klient — Vyhnite sa kopírovaniu toku odpovedí do pamäte“
„Vyhnite sa kopírovaniu celého toku odpovedí do pamäte v S3 HTTP
zákazník"
„Schopnosť ukladať do vyrovnávacej pamäte a indexovať súbory pre disk S3“
"Presuňte časti z DiskLocal do DiskS3 paralelne"
Tým sa však práca neskončila. Po vytvorení funkcie bola potrebná ďalšia práca na optimalizáciu tejto funkcie.
odkazy:
"Pridať udalosti SelectedRows a SelectedBytes"
"Pridať udalosti profilovania z požiadavky S3 do system.events"
"Pridať QueryTimeMicroseconds, SelectQueryTimeMicroseconds a InsertQueryTimeMicroseconds"
A potom bolo potrebné urobiť to diagnostikovateľné, nastaviť monitorovanie a urobiť to zvládnuteľné.
A to všetko sa dialo preto, aby výsledok tejto práce dostala celá komunita, celý ekosystém ClickHouse.
Prejdime k transakčným databázam, k databázam OLTP, ktoré sú mne osobne bližšie.
Toto je open source vývojová divízia DBMS. Títo ľudia robia pouličnú mágiu na zlepšenie transakčných otvorených databáz.
Jedným z projektov, na ktorých príklade môžeme hovoriť o tom, ako a čo robíme, je Connection Pooler v Postgrese.
Postgres je databáza procesov. To znamená, že databáza by mala mať čo najmenej sieťových pripojení, ktoré spracovávajú transakcie.
Na druhej strane v cloudovom prostredí je typická situácia, keď do jedného klastra príde naraz tisíc spojení. A úlohou poolera pripojení je zbaliť tisíc pripojení do malého počtu pripojení k serveru.
Dá sa povedať, že združovateľ pripojení je telefónny operátor, ktorý preusporiada bajty tak, aby sa efektívne dostali do databázy.
Bohužiaľ, neexistuje dobré ruské slovo pre spojenie pooler. Niekedy sa to nazýva multiplexné spojenie. Ak viete, ako nazvať pooler pripojení, určite mi to povedzte, veľmi rád budem hovoriť správnym ruským technickým jazykom.
Skúmali sme fondy pripojení, ktoré boli vhodné pre spravovaný postgresový klaster. A PgBouncer bol pre nás tou najlepšou voľbou. S PgBouncer sme však narazili na množstvo problémov. Pred mnohými rokmi dal Volodya Borodin správy, že používame PgBouncer, všetko sa nám páči, ale existujú nuansy, je na čom pracovať.
A pracovali sme. Opravili sme problémy, s ktorými sme sa stretli, opravili sme Bouncer a pokúsili sme sa posunúť požiadavky na stiahnutie smerom hore. Ale so základným single-threadingom bolo ťažké pracovať.
Museli sme zbierať kaskády od zaplátaných Bouncerov. Keď máme veľa jednovláknových vyhadzovačov, spojenia na hornej vrstve sa prenesú do vnútornej vrstvy vyhadzovačov. Toto je zle spravovaný systém, ktorý je ťažké vybudovať a škálovať tam a späť.
Dospeli sme k záveru, že sme vytvorili vlastný pooler pripojení, ktorý sa volá Odyssey. Napísali sme to od začiatku.
V roku 2019 som na konferencii PgCon predstavil tento pooler komunite vývojárov. Teraz máme na GitHub o niečo menej ako 2 000 hviezdičiek, t.j. projekt žije, projekt je populárny.
A ak vytvoríte klaster Postgres v Yandex.Cloud, potom to bude klaster so vstavaným Odyssey, ktorý sa prekonfiguruje pri škálovaní klastra tam alebo späť.
Čo sme sa naučili z tohto projektu? Spustenie konkurenčného projektu je vždy agresívny krok, je to krajné opatrenie, keď hovoríme, že sú problémy, ktoré sa neriešia dostatočne rýchlo, neriešia sa v časových intervaloch, ktoré by nám vyhovovali. Ale toto je účinné opatrenie.
PgBouncer sa začal vyvíjať rýchlejšie.
A teraz sa objavili ďalšie projekty. Napríklad pgagroal, ktorý vyvíjajú vývojári Red Hat. Sledujú podobné ciele a realizujú podobné nápady, no, samozrejme, s vlastnými špecifikami, ktoré sú bližšie vývojárom z pgagroal.
Ďalší prípad spolupráce s postgres komunitou sa vracia do určitého bodu. Toto je obnova po zlyhaní, toto je obnova zo zálohy.
Existuje veľa záloh a všetky sú iné. Takmer každý predajca Postgres má svoje vlastné zálohovacie riešenie.
Ak zoberiete všetky záložné systémy, vytvoríte maticu funkcií a zo žartu vypočítate determinant v tejto matici, bude to nula. Čo to znamená? Čo ak vezmete konkrétny záložný súbor, potom ho nemožno zostaviť z častí všetkých ostatných. Je jedinečná svojou realizáciou, je jedinečná svojim účelom, je jedinečná myšlienkami, ktoré sú v nej vložené. A všetky sú špecifické.
Kým sme pracovali na tomto probléme, CitusData spustil projekt WAL-G. Ide o zálohovací systém, ktorý bol vytvorený s ohľadom na cloudové prostredie. Teraz je CitusData už súčasťou Microsoftu. A v tom momente sa nám naozaj páčili myšlienky, ktoré boli stanovené v počiatočných vydaniach WAL-G. A začali sme prispievať do tohto projektu.
Teraz je v tomto projekte mnoho desiatok vývojárov, ale medzi 10 najlepších prispievateľov do WAL-G patrí 6 Yandexoidov. Priniesli sme tam množstvo našich nápadov. A, samozrejme, sami sme ich implementovali, testovali, sami zaviedli do výroby, sami ich používame, sami vymýšľame, kam sa posunúť ďalej, pri interakcii s veľkou komunitou WAL-G.
A z nášho pohľadu sa teraz tento zálohovací systém, vrátane zohľadnenia nášho úsilia, stal optimálnym pre cloudové prostredie. Ide o najlepšie náklady na zálohovanie Postgresu v cloude.
Čo to znamená? Presadzovali sme pomerne veľkú myšlienku: zálohovanie by malo byť bezpečné, lacné na prevádzku a čo najrýchlejšie obnovenie.
Prečo by mala byť prevádzka lacná? Keď nie je nič poškodené, nemali by ste vedieť, že máte zálohy. Všetko funguje ako má, čo najmenej míňate CPU, využívate čo najmenej diskových zdrojov a do siete posielate čo najmenej bajtov, aby ste nezasahovali do užitočného zaťaženia vašich cenných služieb.
A keď sa všetko pokazí, napríklad admin vypustil dáta, niečo sa pokazilo a vy sa súrne potrebujete vrátiť do minulosti, zotavíte sa so všetkými peniazmi, pretože chcete svoje dáta rýchlo a nedotknuté.
A my sme presadzovali tento jednoduchý nápad. A zdá sa nám, že sa nám to podarilo zrealizovať.
To však nie je všetko. Chceli sme ešte jednu maličkosť. Chceli sme veľa rôznych databáz. Nie všetci naši klienti používajú Postgres. Niektorí ľudia používajú MySQL, MongoDB. V komunite ďalší vývojári podporili FoundationDB. A tento zoznam sa neustále rozširuje.
Komunite sa páči myšlienka, že databáza beží v spravovanom prostredí v cloude. A vývojári udržiavajú svoje databázy, ktoré je možné jednotne zálohovať spolu s Postgres s naším zálohovacím systémom.
Čo sme sa naučili z tohto príbehu? Náš produkt, ako vývojová divízia, nie sú riadky kódu, nie sú to príkazy, nie sú to súbory. Náš produkt nie sú požiadavky na stiahnutie. Toto sú myšlienky, ktoré odovzdávame komunite. Ide o technologickú odbornosť a posun technológií smerom ku cloudovému prostrediu.
Existuje taká databáza ako Postgres. Najviac sa mi páči jadro Postgres. Veľa času trávim vývojom jadra Postgres s komunitou.
Tu však treba povedať, že Yandex.Cloud má internú inštaláciu spravovaných databáz. A začalo to už dávno v Yandex.Mail. Odborné znalosti, ktoré teraz viedli k riadeniu Postgres, sa nahromadili, keď sa pošta chcela presunúť do Postgresu.
Mail má veľmi podobné požiadavky ako cloud. Vyžaduje, aby ste boli schopní škálovať na neočakávaný exponenciálny rast v ktoromkoľvek bode vašich údajov. A pošta už bola zaťažená niekoľkými stovkami miliónov poštových schránok veľkého počtu používateľov, ktorí neustále robia veľa žiadostí.
A to bola dosť vážna výzva pre tím, ktorý vyvíjal Postgres. Všetky problémy, s ktorými sme sa stretli, boli vtedy nahlásené komunite. A tieto problémy boli opravené a na niektorých miestach komunitou opravené dokonca na úrovni platenej podpory niektorých iných databáz a ešte lepšie. To znamená, že môžete poslať list hackerovi PgSQL a dostať odpoveď do 40 minút. Platená podpora v niektorých databázach si môže myslieť, že existujú dôležitejšie veci ako vaša chyba.
Teraz je interná inštalácia Postgresu niekoľko petabajtov údajov. Ide o niekoľko miliónov žiadostí za sekundu. Ide o tisíce zhlukov. Je veľmi rozsiahly.
Ale je tu nuansa. Nežije na vychytených sieťových diskoch, ale na pomerne jednoduchom hardvéri. A existuje testovacie prostredie špeciálne pre zaujímavé nové veci.
A v určitom momente v testovacom prostredí sme dostali správu oznamujúcu, že boli porušené interné invarianty databázových indexov.
Invariant je nejaký druh vzťahu, ktorý očakávame, že bude vždy držať.
Pre nás veľmi kritická situácia. Znamená to, že niektoré údaje sa mohli stratiť. A strata dát je niečo priam katastrofálne.
Všeobecná myšlienka, ktorou sa riadime v riadených databázach, je taká, že aj pri vynaložení námahy bude ťažké stratiť dáta. Aj keď ich úmyselne odstránite, budete musieť ich absenciu dlho ignorovať. Bezpečnosť údajov je náboženstvo, ktoré veľmi usilovne dodržiavame.
A tu nastáva situácia, ktorá naznačuje, že môže nastať situácia, na ktorú možno nebudeme pripravení. A začali sme sa na túto situáciu pripravovať.
Prvá vec, ktorú sme urobili, bolo zakopať polená z týchto tisícok zhlukov. Zistili sme, ktoré z klastrov sa nachádzali na diskoch s problematickým firmvérom, ktoré strácali aktualizácie dátových stránok. Označil všetky dátové kódy Postgres. A tie správy, ktoré naznačujú porušenie interných invariantov, sme označili kódom, ktorý je určený na detekciu poškodenia údajov.
Tento patch bol komunitou prakticky prijatý bez väčších diskusií, pretože v každom konkrétnom prípade bolo zrejmé, že sa stalo niečo zlé a treba to nahlásiť do logu.
Potom sme sa dostali k bodu, že máme monitorovanie, ktoré skenuje protokoly. A v prípade podozrivých správ zobudí strážnika a ten to opraví.
Ale! Skenovanie protokolov je lacná operácia na jednom klastri a katastrofálne drahá pre tisíc klastrov.
Napísali sme rozšírenie tzv . Vytvára pohľad na databázu, v ktorej si môžete lacno a rýchlo vybrať štatistiky o minulých chybách. A ak potrebujeme zobudiť dôstojníka, zistíme to bez skenovania gigabajtových súborov, ale extrahovaním niekoľkých bajtov z tabuľky hash.
Toto rozšírenie bolo prijaté napríklad v úložisku pre . Ak ho chcete použiť, môžete si ho nainštalovať sami. Samozrejme je to open source.
To však nie je všetko. Na nájdenie invariantných porušení v indexoch sme začali používať Amcheck, rozšírenie vytvorené komunitou.
A zistili sme, že ak ho prevádzkujete vo veľkom rozsahu, existujú chyby. Začali sme ich opravovať. Naše opravy boli prijaté.
Zistili sme, že toto rozšírenie nedokáže analyzovať indexy GiST & GIT. Donútili sme ich podporiť. Ale o tejto podpore sa stále diskutuje v komunite, pretože ide o relatívne novú funkciu a je tam veľa detailov.
A tiež sme zistili, že pri kontrole porušení indexov na replikačnom lídrovi, na masteri, všetko funguje dobre, ale na replikách, na nasledovníkovi nie je hľadanie korupcie také efektívne. Nie sú kontrolované všetky invarianty. A jeden invariant nám veľmi vadil. A strávili sme rok a pol komunikáciou s komunitou, aby sme umožnili túto kontrolu replík.
Napísali sme kód, ktorý by mal dodržiavať všetky možné... protokoly. O tomto patchi sme diskutovali pomerne dlho s Petrom Gaghanom z Crunchy Data. Aby akceptoval tento patch, musel mierne upraviť existujúci B-strom v Postgrese. Bol prijatý. A teraz sa kontrola indexov na replikách stala dostatočne efektívnou, aby odhalila porušenia, s ktorými sme sa stretli. To znamená, že toto sú porušenia, ktoré môžu byť spôsobené chybami vo firmvéri disku, chybami v Postgrese, chybami v jadre Linuxu a problémami s hardvérom. Pomerne rozsiahly zoznam zdrojov problémov, na ktoré sme sa pripravovali.
Ale okrem indexov existuje aj taká časť, ako je halda, teda miesto, kde sú dáta uložené. A nie je veľa invariantov, ktoré by sa dali skontrolovať.
Máme rozšírenie s názvom Heapcheck. Začali sme to rozvíjať. A paralelne s nami začala spoločnosť EnterpriseDB písať aj modul, ktorý nazvali rovnakým spôsobom Heapcheck. Len my sme to nazvali PgHeapcheck a oni to nazvali Heapcheck. Majú to s podobnými funkciami, trochu iným podpisom, no s rovnakými nápadmi. Miestami ich implementovali trochu lepšie. A predtým to zverejnili v open source.
A teraz rozvíjame ich expanziu, pretože to už nie je ich rozširovanie, ale rozširovanie komunity. A v budúcnosti je to časť jadra, ktorá bude dodaná každému, aby mohol vopred vedieť o budúcich problémoch.
Miestami sme dokonca prišli na to, že v našich monitorovacích systémoch máme falošné poplachy. Napríklad systém 1C. Pri používaní databázy Postgres do nej niekedy zapisuje údaje, ktoré vie čítať, ale pg_dump čítať nevie.
Táto situácia vyzerala ako korupcia pre náš systém detekcie problémov. Služobný dôstojník bol prebudený. Služobný dôstojník sa pozrel, čo sa deje. Po nejakom čase prišiel klient a povedal, že mám problémy. Obsluha vysvetlila, v čom je problém. Problém je ale v jadre Postgres.
Našiel som diskusiu o tejto funkcii. A napísal, že sme sa s touto funkciou stretli a bolo to nepríjemné, človek sa v noci zobudil, aby zistil, čo to je.
Komunita odpovedala: "Och, naozaj to musíme opraviť."
Mám jednoduché prirovnanie. Ak kráčate v topánke, ktorá má v sebe zrnko piesku, potom v zásade môžete ísť ďalej - žiadny problém. Ak predávate čižmy tisíckam ľudí, potom vyrobme čižmy úplne bez piesku. A ak sa jeden z používateľov vašich topánok chystá zabehnúť maratón, potom chcete vyrobiť veľmi dobré topánky a potom ich prispôsobiť všetkým svojim používateľom. A takíto neočakávaní používatelia sú vždy v cloudovom prostredí. Vždy sa nájdu používatelia, ktorí využívajú klaster nejakým originálnym spôsobom. Na to sa treba vždy pripraviť.
Čo sme sa tu naučili? Naučili sme sa jednoduchú vec: najdôležitejšie je vysvetliť komunite, že existuje problém. Ak komunita rozpoznala problém, potom vzniká prirodzená súťaž o vyriešenie problému. Pretože každý chce vyriešiť dôležitý problém. Všetci predajcovia, všetci hackeri chápu, že oni sami môžu šliapnuť na tento rake, takže ich chcú eliminovať.
Ak pracujete na nejakom probléme, ale netrápi nikoho okrem vás, no pracujete na ňom systematicky a v konečnom dôsledku sa to považuje za problém, tak vaša žiadosť o ťahanie bude určite prijatá. Vaša oprava bude prijatá, vaše vylepšenia alebo dokonca žiadosti o vylepšenia budú posúdené komunitou. Na konci dňa si databázu navzájom vylepšujeme.
Zaujímavou databázou je Greenplum. Je to vysoko paralelná databáza založená na kódovej základni Postgres, ktorú veľmi dobre poznám.
A Greenplum má zaujímavú funkcionalitu - pridávať optimalizované tabuľky. Sú to tabuľky, ktoré môžete rýchlo doplniť. Môžu byť stĺpcové alebo riadkové.
Neexistovalo však žiadne klastrovanie, t. j. neexistovala žiadna funkcia, v ktorej by ste mohli usporiadať údaje umiestnené v tabuľke v súlade s poradím, ktoré je v jednom z indexov.
Prišli ku mne chalani z taxíka a povedali: „Andrey, poznáš Postgres. A tu je to skoro to isté. Prepnite na 20 minút. Vezmi to a urob to." Myslel som si, že áno, poznám Postgres, prepínam na 20 minút - musím to urobiť.
Ale nie, nebolo to 20 minút, písal som to mesiace. Na konferencii PgConf.Russia som oslovil Heikkiho Linakangasa z Pivotalu a spýtal som sa: „Sú s tým nejaké problémy? Prečo neexistuje klastrovanie tabuliek optimalizovaných na pridanie? Hovorí: „Vezmite si údaje. Triediš, preskupuješ. Je to len práca.“ Ja: "Ach, áno, stačí to vziať a urobiť." Hovorí: "Áno, potrebujeme na to voľné ruky." Myslel som, že to určite musím urobiť.
A o niekoľko mesiacov neskôr som odoslal požiadavku na stiahnutie, ktorá implementovala túto funkciu. Túto žiadosť o stiahnutie posúdil Pivotal spolu s komunitou. Samozrejme, boli tam bugy.
Najzaujímavejšie však je, že keď bola táto požiadavka na stiahnutie zlúčená, našli sa chyby v samotnom Greenplum. Zistili sme, že haldové tabuľky niekedy porušujú transakciu, keď sú zoskupené. A toto je vec, ktorú treba opraviť. A je na mieste, ktorého som sa práve dotkol. A moja prirodzená reakcia bola – dobre, dovoľte mi to urobiť tiež.
Opravil som túto chybu. Odoslali požiadavku na vytiahnutie opravárov. Bol zabitý.
Potom sa ukázalo, že túto funkcionalitu je potrebné získať vo verzii Greenplum pre PostgreSQL 12. To znamená, že 20-minútové dobrodružstvo pokračuje novými zaujímavými dobrodružstvami. Bolo zaujímavé dotknúť sa súčasného vývoja, kde komunita seká nové a najdôležitejšie funkcie. Je to zamrznuté.
Tým to ale neskončilo. Po všetkom sa ukázalo, že k tomu všetkému potrebujeme napísať dokumentáciu.
Začal som písať dokumentáciu. Našťastie prišli dokumentaristi z Pivotalu. Angličtina je ich rodným jazykom. Pomohli mi s dokumentáciou. V skutočnosti oni sami prepísali to, čo som navrhol, do skutočnej angličtiny.
A tu sa, zdá sa, dobrodružstvo skončilo. A viete, čo sa stalo potom? Prišli ku mne chalani z taxíka a povedali: "Stále sú tu dve dobrodružstvá, každé na 10 minút." A čo im mám povedať? Povedal som, že teraz podám správu vo veľkom rozsahu, potom uvidíme vaše dobrodružstvá, pretože je to zaujímavá práca.
Čo sme sa z tohto prípadu naučili? Pretože práca s open source je vždy práca s konkrétnym človekom, je to vždy práca s komunitou. Pretože v každej jednej fáze som spolupracoval s nejakým vývojárom, nejakým testerom, nejakým hackerom, nejakým dokumentaristom, nejakým architektom. Nepracoval som s Greenplum, ale s ľuďmi okolo Greenplum.
Ale! Je tu ďalší dôležitý bod - je to len práca. To znamená, že prídete, vypijete kávu, napíšete kód. Fungujú všetky druhy jednoduchých invariantov. Urobte to normálne - bude to v poriadku! A je to celkom zaujímavá práca. Existuje požiadavka na túto prácu od klientov Yandex.Cloud, používateľov našich klastrov vo vnútri Yandexu aj mimo neho. A myslím si, že počet projektov, na ktorých participujeme, bude pribúdať a bude sa zvyšovať aj hĺbka nášho zapojenia.
To je všetko. Prejdime k otázkam.
Relácia otázok
Ahoj! Máme tu ďalšiu reláciu otázok a odpovedí. A v štúdiu Andrei Borodin. Toto je osoba, ktorá vám práve povedala o príspevku Yandex.Cloud a Yandex k open source. Naša správa teraz nie je úplne o cloude, no zároveň vychádzame z takýchto technológií. Bez toho, čo ste urobili v službe Yandex, by v službe Yandex.Cloud neexistovala žiadna služba, takže vám osobne ďakujem. A prvá otázka z vysielania: „Na čom je napísaný každý z projektov, ktoré ste spomínali?“
Záložný systém vo WAL-G je napísaný v Go. Toto je jeden z novších projektov, na ktorých sme pracovali. Má doslova len 3 roky. A databáza je často o spoľahlivosti. A to znamená, že databázy sú dosť staré a zvyčajne sú napísané v C. Projekt Postgres začal asi pred 30 rokmi. Potom bola C89 tou správnou voľbou. A je na ňom napísaný Postgres. Modernejšie databázy ako ClickHouse sú zvyčajne napísané v C++. Celý vývoj systému je založený na C a C++.
Otázka od nášho finančného manažéra, ktorý je v Cloude zodpovedný za výdavky: „Prečo Cloud míňa peniaze na podporu open source?“
Tu je jednoduchá odpoveď pre finančného manažéra. Robíme to preto, aby sme zlepšili naše služby. Akými spôsobmi to môžeme urobiť lepšie? Môžeme robiť veci efektívnejšie, rýchlejšie a robiť veci škálovateľnejšie. Pre nás je však tento príbeh predovšetkým o spoľahlivosti. Napríklad v záložnom systéme kontrolujeme 100 % záplat, ktoré sa naň vzťahujú. Vieme, aký je kód. A je pre nás pohodlnejšie zavádzať do výroby nové verzie. Teda v prvom rade ide o dôveru, o pripravenosť na vývoj a o spoľahlivosť
Ďalšia otázka: „Lišia sa požiadavky externých používateľov, ktorí žijú v Yandex.Cloud, od interných používateľov, ktorí žijú v internom cloude?
Záťažový profil je samozrejme odlišný. Ale z pohľadu môjho rezortu všetky špeciálne a zaujímavé prípady vznikajú na neštandardnej záťaži. Vývojári s fantáziou, vývojári, ktorí robia neočakávané, sa pravdepodobne nájdu interne aj externe. V tomto smere sme na tom všetci približne rovnako. A pravdepodobne jedinou dôležitou vlastnosťou v rámci prevádzky databáz Yandex bude to, že vo vnútri Yandex máme učenie. V určitom okamihu sa určitá zóna dostupnosti úplne dostane do tieňa a všetky služby Yandex musia napriek tomu nejakým spôsobom fungovať. Toto je malý rozdiel. Ale vytvára veľa výskumného vývoja na rozhraní databázy a sieťového zásobníka. V opačnom prípade externé a interné inštalácie generujú rovnaké požiadavky na funkcie a podobné požiadavky na zlepšenie spoľahlivosti a výkonu.
Ďalšia otázka: „Aký máte vy osobne pocit, že veľa z toho, čo robíte, využívajú iné cloudy?“ Nebudeme menovať konkrétne, ale veľa projektov, ktoré boli vykonané v Yandex.Cloud, sa používa v cloudoch iných ľudí.
Toto je super. Po prvé, je to znamenie, že sme urobili niečo správne. A škriabe to ego. A sme si viac istí, že sme sa rozhodli správne. Na druhej strane je to nádej, že nám to v budúcnosti prinesie nové nápady, nové požiadavky používateľov tretích strán. Väčšinu problémov na GitHub vytvárajú individuálni správcovia systému, individuálni DBA, individuálni architekti, individuálni inžinieri, ale niekedy prídu ľudia so systematickými skúsenosťami a povedia, že v 30% určitých prípadov máme tento problém a poďme sa zamyslieť, ako ho vyriešiť. Na toto sa tešíme najviac. Tešíme sa na zdieľanie skúseností s inými cloudovými platformami.
Veľa ste hovorili o maratóne. Viem, že ste bežali maratón v Moskve. Ako výsledok? Predbehol chalanov z PostgreSQL?
Nie, Oleg Bartunov beží veľmi rýchlo. Skončil hodinu predo mnou. Celkovo som spokojný s tým, ako ďaleko som sa dostal. Pre mňa bol úspech už len to, že som skončil. Celkovo je prekvapujúce, že v komunite postgres je toľko bežcov. Zdá sa mi, že medzi aeróbnym športom a túžbou po systémovom programovaní existuje nejaký vzťah.
Hovoríte, že v ClickHouse nie sú žiadni bežci?
Viem s istotou, že tam sú. ClickHouse je tiež databáza. Mimochodom, Oleg mi teraz píše: "Ideme si po správe zabehať?" To je skvelý nápad.
Ďalšia otázka z vysielania od Nikitu: „Prečo ste chybu v Greenplum opravili sami a nedali ju juniorom?“ Je pravda, že nie je úplne jasné, čo je chyba a v ktorej službe, ale pravdepodobne to znamená tú, o ktorej ste hovorili.
Áno, v zásade to mohlo byť niekomu dané. Bol to len kód, ktorý som práve zmenil. A bolo prirodzené v tom hneď pokračovať. V zásade je myšlienka zdieľania odborných znalostí s tímom dobrý nápad. Úlohy Greenplum si určite rozdelíme medzi všetkých členov našej divízie.
Keďže sa bavíme o junioroch, je tu otázka. Osoba sa rozhodla vytvoriť prvý commit v Postgrese. Čo musí urobiť, aby urobil prvý záväzok?
Toto je zaujímavá otázka: "Kde začať?" Zvyčajne je dosť ťažké začať s niečím v jadre. V Postgres je napríklad zoznam úloh. Ale v skutočnosti je to list toho, čo sa pokúsili urobiť, ale neuspeli. Sú to zložité veci. A zvyčajne nájdete v ekosystéme nejaké pomôcky, nejaké rozšírenia, ktoré možno vylepšiť, ktoré priťahujú menšiu pozornosť vývojárov jadra. A preto je tam viac bodov pre rast. V programe Google Summer of code komunita postgres každý rok predkladá mnoho rôznych tém, ktoré by sa dali riešiť. Tento rok sme mali, myslím, troch žiakov. Jeden dokonca písal vo WAL-G o témach, ktoré sú dôležité pre Yandex. V Greenplum je všetko jednoduchšie ako v komunite Postgres, pretože hackeri Greenplum veľmi dobre zaobchádzajú s požiadavkami na stiahnutie a hneď sa pustia do kontroly. Odoslanie opravy Postgresu je otázkou mesiacov, ale Greenplum príde o deň a uvidí, čo ste urobili. Ďalšia vec je, že Greenplum potrebuje riešiť aktuálne problémy. Greenplum sa veľmi nepoužíva, takže nájsť váš problém je dosť ťažké. A v prvom rade musíme vyriešiť problémy, samozrejme.
Zdroj: hab.com