Příspěvek Yandexu do následujících databází bude zkontrolován.
- clickhouse
- Odysea
- Obnova do určitého bodu v čase (WAL-G)
- PostgreSQL (včetně logerrors, Amcheck, heapcheck)
- Zelená švestka
Video:
Ahoj světe! Jmenuji se Andrey Borodin. A to, co dělám v Yandex.Cloud, je vývoj otevřených relačních databází v zájmu klientů Yandex.Cloud a Yandex.Cloud.
V této přednášce budeme hovořit o výzvách, kterým čelí otevřené databáze ve velkém měřítku. Proč je to důležité? Protože malé, malé problémy, ze kterých se jako z komárů stanou sloni. Jsou velké, když máte mnoho shluků.
Ale to není to hlavní. Dějí se neuvěřitelné věci. Věci, které se stávají v jednom z milionu případů. A v cloudovém prostředí na to musíte být připraveni, protože neuvěřitelné věci se stávají vysoce pravděpodobnými, když něco existuje ve velkém měřítku.
Ale! Jaká je výhoda otevřených databází? Faktem je, že máte teoretickou možnost poradit si s jakýmkoliv problémem. Máte zdrojový kód, máte znalosti programování. Kombinujeme to a funguje to.
Jaké přístupy existují při práci na softwaru s otevřeným zdrojovým kódem?
- Nejpřímějším přístupem je použití softwaru. Pokud používáte protokoly, pokud používáte standardy, pokud používáte formáty, pokud píšete dotazy v open source softwaru, pak to již podporujete.
- Rozšiřujete jeho ekosystém. Zvýšíte tím pravděpodobnost včasného odhalení chyby. Zvyšujete spolehlivost tohoto systému. Zvyšujete dostupnost vývojářů na trhu. Vylepšujete tento software. Jste již přispěvatelem, pokud jste právě udělali styl a něco tam vymysleli.
- Dalším pochopitelným přístupem je sponzorování softwaru s otevřeným zdrojovým kódem. Například známý program Google Summer of Code, kdy Google platí velkému množství studentů z celého světa pochopitelné peníze, aby vyvíjeli otevřené softwarové projekty splňující určité licenční požadavky.
- Jedná se o velmi zajímavý přístup, protože umožňuje vyvíjet se softwaru, aniž by se pozornost přesunula pryč od komunity. Google, jako technologický gigant, neříká, že tuto funkci chceme, chceme tuto chybu opravit a tady se musíme pohrabat. Google říká: „Dělejte to, co děláte. Pokračujte v práci tak, jak jste pracovali, a všechno bude v pořádku."
- Dalším přístupem k účasti na open source je participace. Když máte problém s open source softwarem a jsou tam vývojáři, vaši vývojáři začnou problémy řešit. Začnou dělat vaši infrastrukturu efektivnější, vaše programy rychlejší a spolehlivější.
Jedním z nejznámějších projektů Yandex v oblasti open source softwaru je ClickHouse. Toto je databáze, která se zrodila jako odpověď na výzvy, kterým čelí Yandex.Metrica.
A jako databáze byla vytvořena v open source za účelem vytvoření ekosystému a jeho rozvoje společně s dalšími vývojáři (nejen v rámci Yandexu). A nyní jde o velký projekt, do kterého je zapojeno mnoho různých společností.
V Yandex.Cloud jsme vytvořili ClickHouse nad Yandex Object Storage, tedy nad cloudovým úložištěm.
Proč je to důležité v cloudu? Protože jakákoli databáze funguje v tomto trojúhelníku, v této pyramidě, v této hierarchii typů paměti. Máte rychlé, ale malé registry a levné velké, ale pomalé SSD, pevné disky a některá další bloková zařízení. A pokud jste efektivní na vrcholu pyramidy, pak máte rychlou databázi. pokud jste efektivní na dně této pyramidy, pak máte škálovanou databázi. A v tomto ohledu je přidání další vrstvy zespodu logickým přístupem ke zvýšení škálovatelnosti databáze.
Jak by se to dalo udělat? To je důležitý bod této zprávy.
- Mohli bychom implementovat ClickHouse přes MDS. MDS je interní rozhraní cloudového úložiště Yandex. Je složitější než běžný protokol S3, ale je vhodnější pro blokové zařízení. Je to lepší pro záznam dat. Vyžaduje to více programování. Programátoři budou programovat, je to dokonce dobré, je to zajímavé.
- S3 je běžnější přístup, který zjednodušuje rozhraní za cenu menšího přizpůsobení určitým typům zátěže.
Přirozeně, že chceme poskytnout funkčnost celému ekosystému ClickHouse a udělat úkol, který je v Yandex.Cloud potřeba, rozhodli jsme se zajistit, aby z toho měla prospěch celá komunita ClickHouse. Implementovali jsme ClickHouse přes S3, ne ClickHouse přes MDS. A to je hodně práce.
Odkazy:
"Abstrakce systému souborů"
"Integrace AWS SDK S3"
“Základní implementace rozhraní IDisk pro S3”
"Integrace modulů pro ukládání protokolů s rozhraním IDisk"
"Podpora logovacího jádra pro S3 a SeekableReadBuffer"
"Podpora úložiště Stripe Log S3"
"Počáteční podpora úložiště MergeTree pro S3"
"MergeTree plná podpora pro S3"
"Podpora ReplicatedMergeTree přes S3"
"Přidat výchozí přihlašovací údaje a vlastní záhlaví pro úložiště S3"
"S3 s dynamickou konfigurací proxy"
"S3 s proxy resolverem"
Toto je seznam požadavků na stažení pro implementaci virtuálního souborového systému v ClickHouse. Jedná se o velký počet žádostí o stažení.
Odkazy:
"Optimální implementace pevných odkazů DiskS3"
„S3 HTTP klient — Nekopírujte tok odpovědí do paměti“
„Vyhněte se kopírování celého toku odpovědí do paměti v S3 HTTP
klient"
„Schopnost ukládat do mezipaměti označovat a indexovat soubory pro disk S3“
"Paralelně přesunout části z DiskLocal do DiskS3"
Tím ale práce neskončila. Poté, co byla tato funkce vytvořena, bylo zapotřebí provést další práci, aby byla tato funkce optimalizována.
Odkazy:
"Přidat události SelectedRows a SelectedBytes"
"Přidat profilovací události z požadavku S3 do system.events"
"Přidat QueryTimeMicroseconds, SelectQueryTimeMicroseconds a InsertQueryTimeMicroseconds"
A pak bylo potřeba udělat to diagnostikovatelné, nastavit sledování a udělat to zvládnutelné.
A to vše bylo provedeno proto, aby výsledek této práce obdržela celá komunita, celý ekosystém ClickHouse.
Přejděme k transakčním databázím, k OLTP databázím, které jsou mi osobně bližší.
Toto je open source vývojová divize DBMS. Tihle kluci dělají pouliční magii, aby zlepšili transakční otevřené databáze.
Jedním z projektů, na jehož příkladu můžeme mluvit o tom, jak a co děláme, je Connection Pooler v Postgresu.
Postgres je databáze procesů. To znamená, že databáze by měla mít co nejméně síťových připojení, která zpracovávají transakce.
Na druhou stranu v cloudovém prostředí je typická situace, kdy do jednoho clusteru přichází tisíc spojení najednou. A úkolem pooleru připojení je sbalit tisíc připojení do malého počtu připojení k serveru.
Dá se říci, že pooler připojení je telefonní operátor, který přeskupuje bajty tak, aby se efektivně dostaly do databáze.
Bohužel neexistuje dobré ruské slovo pro připojení pooler. Někdy se tomu říká spojení multiplexeru. Pokud víte, jak nazvat pooler připojení, pak mi to určitě řekněte, velmi rád budu mluvit správným ruským technickým jazykem.
Zkoumali jsme poolery připojení, které byly vhodné pro spravovaný postgres cluster. A PgBouncer byl pro nás nejlepší volbou. S PgBouncerem jsme ale narazili na řadu problémů. Před mnoha lety dal Volodya Borodin zprávy, že používáme PgBouncer, líbí se nám všechno, ale jsou tu nuance, je na čem pracovat.
A pracovali jsme. Opravili jsme problémy, se kterými jsme se setkali, opravili jsme Bouncer a pokusili se poslat požadavky na stahování upstream. Ale se základním single-threadingem bylo těžké pracovat.
Museli jsme sbírat kaskády ze záplatovaných vyhazovačů. Když máme mnoho jednovláknových vyhazovačů, spojení na horní vrstvě se přenesou do vnitřní vrstvy vyhazovačů. Jedná se o špatně spravovaný systém, který je obtížné vybudovat a škálovat tam a zpět.
Došli jsme k závěru, že jsme vytvořili vlastní pooler připojení, který se jmenuje Odyssey. Napsali jsme to od začátku.
V roce 2019 jsem na konferenci PgCon představil tento pooler komunitě vývojářů. Nyní máme na GitHubu o něco méně než 2 000 hvězdiček, tj. projekt žije, projekt je populární.
A pokud vytvoříte cluster Postgres v Yandex.Cloud, pak to bude cluster s vestavěným Odyssey, který se překonfiguruje při škálování clusteru tam nebo zpět.
Co jsme se z tohoto projektu naučili? Spuštění konkurenčního projektu je vždy agresivní krok, je to krajní opatření, kdy říkáme, že jsou problémy, které se neřeší dostatečně rychle, neřeší se v časových intervalech, které by nám vyhovovaly. Ale to je účinné opatření.
PgBouncer se začal vyvíjet rychleji.
A nyní se objevily další projekty. Například pgagroal, který je vyvíjen vývojáři Red Hat. Sledují podobné cíle a realizují podobné nápady, ale samozřejmě s vlastními specifiky, která jsou bližší vývojářům pgagroal.
Dalším případem spolupráce s postgres komunitou je obnovení do určitého bodu v čase. Toto je obnova po selhání, to je obnova ze zálohy.
Existuje mnoho záloh a všechny jsou jiné. Téměř každý dodavatel Postgres má své vlastní řešení zálohování.
Pokud vezmete všechny záložní systémy, vytvoříte matici funkcí a vtipně vypočítáte determinant v této matici, bude nula. Co to znamená? Co když vezmete konkrétní záložní soubor, pak jej nelze sestavit z částí všech ostatních. Je jedinečný svou realizací, je jedinečný svým účelem, je jedinečný myšlenkami, které jsou v něm vloženy. A všechny jsou specifické.
Zatímco jsme na tomto problému pracovali, CitusData spustil projekt WAL-G. Jedná se o zálohovací systém, který byl vytvořen s ohledem na cloudové prostředí. Nyní je CitusData již součástí Microsoftu. A v tu chvíli se nám opravdu líbily myšlenky, které byly stanoveny v počátečních verzích WAL-G. A začali jsme na tento projekt přispívat.
Nyní je v tomto projektu mnoho desítek vývojářů, ale mezi 10 nejlepších přispěvatelů do WAL-G patří 6 Yandexoidů. Přinesli jsme tam spoustu našich nápadů. A samozřejmě jsme je sami implementovali, sami testovali, sami zavedli do výroby, sami je používáme, sami vymýšlíme, kam se dále posunout, a přitom jsme v interakci s velkou komunitou WAL-G.
A z našeho pohledu se nyní tento zálohovací systém, včetně zohlednění našeho úsilí, stal optimálním pro cloudové prostředí. To jsou nejlepší náklady na zálohování Postgresu v cloudu.
Co to znamená? Prosazovali jsme poměrně velkou myšlenku: zálohování by mělo být bezpečné, levné na provoz a co nejrychlejší obnovení.
Proč by měl být provoz levný? Když není nic rozbité, neměli byste vědět, že máte zálohy. Vše funguje v pořádku, plýtváte co nejméně CPU, spotřebováváte co nejméně diskových prostředků a do sítě posíláte co nejméně bajtů, abyste nezasahovali do užitečného zatížení vašich cenných služeb.
A když se vše pokazí, například admin zahodil data, něco se pokazilo a vy se nutně potřebujete vrátit do minulosti, obnovíte se se všemi penězi, protože chcete svá data rychle a nepoškozená.
A tento jednoduchý nápad jsme prosadili. A jak se nám zdá, podařilo se nám to zrealizovat.
Ale to není vše. Chtěli jsme ještě jednu maličkost. Chtěli jsme mnoho různých databází. Ne všichni naši klienti používají Postgres. Někteří lidé používají MySQL, MongoDB. V komunitě podporují FoundationDB další vývojáři. A tento seznam se neustále rozšiřuje.
Komunitě se líbí myšlenka, že databáze běží ve spravovaném prostředí v cloudu. A vývojáři udržují své databáze, které lze jednotně zálohovat společně s Postgres s naším zálohovacím systémem.
Co jsme se z tohoto příběhu naučili? Náš produkt, jakožto vývojová divize, nejsou řádky kódu, nejsou to příkazy, nejsou to soubory. Náš produkt nejsou požadavky na vytažení. To jsou myšlenky, které předáváme komunitě. Jedná se o technologickou odbornost a posun technologií směrem ke cloudovému prostředí.
Existuje taková databáze jako Postgres. Nejvíce se mi líbí jádro Postgres. Hodně času trávím vývojem jádra Postgres s komunitou.
Zde je ale třeba říci, že Yandex.Cloud má vnitřní instalaci spravovaných databází. A začalo to už dávno v Yandex.Mail. Odborné znalosti, které nyní vedly ke správě Postgresu, byly nashromážděny, když se pošta chtěla přesunout do Postgresu.
Mail má velmi podobné požadavky jako cloud. Potřebuje, abyste byli schopni škálovat na neočekávaný exponenciální růst v libovolném bodě vašich dat. A pošta už byla zatížena několika stovkami milionů poštovních schránek velkého počtu uživatelů, kteří neustále zadávají mnoho požadavků.
A to byla docela vážná výzva pro tým, který vyvíjel Postgres. Tehdy byly všechny problémy, na které jsme narazili, hlášeny komunitě. A tyto problémy byly opraveny a komunitou na některých místech opraveny i na úrovni placené podpory některých jiných databází a ještě lépe. To znamená, že můžete poslat dopis hackerovi PgSQL a obdržet odpověď do 40 minut. Placená podpora v některých databázích si může myslet, že jsou prioritnější věci než vaše chyba.
Nyní je vnitřní instalace Postgresu několik petabajtů dat. Jedná se o několik milionů požadavků za sekundu. Jedná se o tisíce shluků. Je to velmi rozsáhlé.
Ale je tu nuance. Nežije na vychytaných síťových discích, ale na poměrně jednoduchém hardwaru. A existuje testovací prostředí speciálně pro zajímavé nové věci.
A v určitém okamžiku v testovacím prostředí jsme obdrželi zprávu oznamující, že byly porušeny interní invarianty databázových indexů.
Invariant je nějaký druh vztahu, který očekáváme, že bude vždy držet.
Pro nás velmi kritická situace. Znamená to, že některá data mohla být ztracena. A ztráta dat je něco přímo katastrofálního.
Obecná myšlenka, kterou se řídíme ve spravovaných databázích, je taková, že i při vynaložení úsilí bude obtížné o data přijít. I když je úmyslně odstraníte, budete muset jejich nepřítomnost po dlouhou dobu ignorovat. Bezpečnost dat je náboženství, které docela pilně dodržujeme.
A zde nastává situace, která naznačuje, že může nastat situace, na kterou možná nejsme připraveni. A začali jsme se na tuto situaci připravovat.
První věc, kterou jsme udělali, bylo zahrabat klády z těchto tisíců shluků. Zjistili jsme, které z clusterů byly umístěny na discích s problematickým firmwarem, které ztrácely aktualizace datových stránek. Označil veškerý datový kód Postgres. A ty zprávy, které indikují porušení interních invariantů, jsme označili kódem, který je určen k detekci poškození dat.
Tento patch byl komunitou prakticky přijat bez větších diskuzí, protože v každém konkrétním případě bylo zřejmé, že se stalo něco špatného a je potřeba to nahlásit do logu.
Poté jsme se dostali k bodu, že máme monitorování, které skenuje protokoly. A v případě podezřelých zpráv probudí strážníka a ten to opraví.
Ale! Skenování logů je levná operace na jednom clusteru a katastrofálně drahá pro tisíc clusterů.
Napsali jsme rozšíření tzv . Vytváří pohled na databázi, ve kterém lze levně a rychle vybírat statistiky o minulých chybách. A pokud potřebujeme probudit důstojníka, zjistíme to bez skenování gigabajtových souborů, ale extrahováním několika bajtů z hashovací tabulky.
Toto rozšíření bylo přijato například v úložišti pro . Pokud jej chcete používat, můžete si jej nainstalovat sami. Samozřejmě je to open source.
Ale to není vše. Začali jsme používat Amcheck, komunitní rozšíření, abychom našli invariantní porušení v indexech.
A zjistili jsme, že pokud to provozujete ve velkém, jsou tam chyby. Začali jsme je opravovat. Naše opravy byly přijaty.
Zjistili jsme, že toto rozšíření neumí analyzovat indexy GiST & GIT. Přinutili jsme je podporovat. Ale o této podpoře se stále diskutuje v komunitě, protože se jedná o relativně novou funkci a je tam spousta detailů.
A také jsme zjistili, že při kontrole indexů na porušení na replikačním lídru, na hlavním serveru, vše funguje dobře, ale na replikách, na followeru není hledání korupce tak efektivní. Ne všechny invarianty jsou kontrolovány. A jeden invariant nám velmi vadil. A strávili jsme rok a půl komunikací s komunitou, abychom umožnili tuto kontrolu replik.
Napsali jsme kód, který by se měl řídit všemi možnými... protokoly. O tomto patchi jsme diskutovali poměrně dlouho s Peterem Gaghanem z Crunchy Data. Aby mohl přijmout tento patch, musel mírně upravit stávající B-strom v Postgresu. Byl přijat. A nyní je kontrola indexů na replikách také dostatečně účinná, aby odhalila porušení, na která jsme narazili. To znamená, že toto jsou porušení, která mohou být způsobena chybami ve firmwaru disku, chybami v Postgresu, chybami v jádře Linuxu a hardwarovými problémy. Docela obsáhlý seznam zdrojů problémů, na které jsme se připravovali.
Ale kromě indexů existuje i taková část, jako je halda, tedy místo, kde jsou data uložena. A není mnoho invariantů, které by bylo možné zkontrolovat.
Máme rozšíření s názvem Heapcheck. Začali jsme to vyvíjet. A paralelně s námi začala společnost EnterpriseDB psát také modul, který nazvali stejným způsobem Heapcheck. Jen my jsme tomu říkali PgHeapcheck a oni tomu říkali Heapcheck. Mají to s podobnými funkcemi, trochu jiným podpisem, ale se stejnými nápady. Na některých místech je implementovali trochu lépe. A předtím to zveřejnili v open source.
A nyní rozvíjíme jejich expanzi, protože už to není jejich rozšiřování, ale rozšiřování komunity. A v budoucnu je to část jádra, která bude dodávána všem, aby mohli předem vědět o budoucích problémech.
Na některých místech jsme dokonce došli k závěru, že v našich monitorovacích systémech máme falešně pozitivní výsledky. Například systém 1C. Při používání databáze do ní Postgres někdy zapisuje data, která umí číst, ale pg_dump číst neumí.
Tato situace vypadala jako korupce našeho systému detekce problémů. Služební důstojník byl probuzen. Služební důstojník se podíval, co se děje. Po nějaké době přišel klient a řekl, že mám problémy. Obsluha vysvětlila, v čem je problém. Problém je ale v jádru Postgresu.
Našel jsem diskuzi o této funkci. A napsal, že jsme se s touto funkcí setkali a bylo to nepříjemné, člověk se v noci budil, aby zjistil, co to je.
Komunita odpověděla: "Oh, opravdu to musíme opravit."
Mám jednoduché přirovnání. Pokud chodíte v botě, která má v sobě zrnko písku, pak v zásadě můžete jít dál - žádný problém. Pokud prodáváte boty tisícům lidí, vyrobme boty úplně bez písku. A pokud se jeden z uživatelů vašich bot chystá uběhnout maraton, pak chcete vyrobit velmi dobré boty a poté je přizpůsobit všem svým uživatelům. A takoví nečekaní uživatelé jsou vždy v cloudovém prostředí. Vždy se najdou uživatelé, kteří cluster nějakým originálním způsobem zneužívají. Na to se musíte vždy připravit.
Co jsme se tady naučili? Naučili jsme se jednoduchou věc: nejdůležitější je vysvětlit komunitě, že existuje problém. Pokud komunita rozpoznala problém, pak vzniká přirozená konkurence, která problém vyřeší. Protože každý chce vyřešit důležitý problém. Všichni prodejci, všichni hackeři chápou, že oni sami mohou šlápnout na tento hrábě, takže je chtějí eliminovat.
Pokud na problému pracujete, ale netrápí nikoho kromě vás, ale pracujete na něm systematicky a je to nakonec považováno za problém, pak váš požadavek na stažení bude určitě akceptován. Váš patch bude přijat, vaše vylepšení nebo dokonce žádosti o vylepšení budou přezkoumány komunitou. Na konci dne si databázi vzájemně vylepšujeme.
Zajímavou databází je Greenplum. Je to vysoce paralelní databáze založená na kódové základně Postgres, kterou velmi dobře znám.
A Greenplum má zajímavou funkcionalitu - připojování optimalizovaných tabulek. Jedná se o tabulky, které můžete rychle přidat. Mohou být sloupcové nebo řádkové.
Ale neexistovalo žádné shlukování, tj. neexistovala žádná funkce, kde byste mohli uspořádat data umístěná v tabulce podle pořadí, které je v jednom z indexů.
Přišli za mnou kluci z taxíku a řekli: „Andrey, znáš Postgres. A tady je to skoro to samé. Přepněte na 20 minut. Vezmi to a udělej to." Myslel jsem, že ano, znám Postgres, přepínání na 20 minut - musím to udělat.
Ale ne, nebylo to 20 minut, psal jsem to měsíce. Na konferenci PgConf.Russia jsem oslovil Heikkiho Linakangase z Pivotal a zeptal jsem se: „Jsou s tím nějaké problémy? Proč neexistuje žádné shlukování tabulek optimalizovaných pro připojení? Říká: „Vezmi si data. Třídíte, přeskupujete. Je to jen práce.“ Já: "Ach ano, prostě to musíš vzít a udělat." Říká: "Ano, potřebujeme k tomu volné ruce." Myslel jsem, že to rozhodně musím udělat.
A o několik měsíců později jsem odeslal požadavek na stažení, který implementoval tuto funkci. Tato žádost o stažení byla přezkoumána společností Pivotal společně s komunitou. Samozřejmě tam byly chyby.
Ale nejzajímavější je, že když byl tento požadavek na stažení začleněn, byly nalezeny chyby v samotném Greenplum. Zjistili jsme, že haldové tabulky někdy porušují transakční schopnost, když jsou klastrovány. A to je věc, kterou je potřeba napravit. A je na místě, kterého jsem se právě dotkl. A moje přirozená reakce byla – dobře, nech mě to udělat taky.
Opravil jsem tuto chybu. Odeslali opravářům požadavek na stažení. Byl zabit.
Poté se ukázalo, že tuto funkcionalitu je potřeba získat ve verzi Greenplum pro PostgreSQL 12. To znamená, že 20minutové dobrodružství pokračuje novými zajímavými dobrodružstvími. Bylo zajímavé osahat si současný vývoj, kdy komunita seká nové a nejdůležitější funkce. Je to zmrzlé.
Tím to ale neskončilo. Po všem se ukázalo, že k tomu všemu potřebujeme napsat dokumentaci.
Začal jsem psát dokumentaci. Naštěstí přišli dokumentaristé z Pivotalu. Angličtina je jejich rodným jazykem. Pomohli mi s dokumentací. Ve skutečnosti sami přepsali to, co jsem navrhoval, do skutečné angličtiny.
A tady, zdá se, dobrodružství skončilo. A víte, co se stalo potom? Přišli za mnou kluci z taxíku a řekli: "Stále jsou dvě dobrodružství, každé na 10 minut." A co jim mám říct? Řekl jsem, že teď podám zprávu v měřítku a pak uvidíme vaše dobrodružství, protože je to zajímavá práce.
Co jsme se z tohoto případu dozvěděli? Protože práce s open source je vždy práce s konkrétní osobou, je to vždy práce s komunitou. Protože v každé jednotlivé fázi jsem pracoval s nějakým vývojářem, nějakým testerem, nějakým hackerem, nějakým dokumentaristou, nějakým architektem. Nepracoval jsem s Greenplum, pracoval jsem s lidmi kolem Greenplum.
Ale! Je tu další důležitý bod - je to jen práce. To znamená, že přijdete, vypijete kávu, napíšete kód. Fungují všechny druhy jednoduchých invariantů. Dělejte to normálně - bude to v pořádku! A je to docela zajímavá práce. Existuje požadavek na tuto práci od klientů Yandex.Cloud, uživatelů našich clusterů uvnitř Yandexu i mimo něj. A myslím si, že bude přibývat projektů, na kterých se podílíme, a bude se zvyšovat i hloubka našeho zapojení.
To je vše. Přejděme k otázkám.
Sezení otázek
Ahoj! Máme další relaci otázek a odpovědí. A ve studiu Andrei Borodin. Toto je osoba, která vám právě řekla o příspěvku Yandex.Cloud a Yandex k open source. Naše zpráva nyní není úplně o Cloudu, ale zároveň na takových technologiích vycházíme. Bez toho, co jste udělali v Yandexu, by v Yandex.Cloud nebyla žádná služba, takže vám osobně děkuji. A první otázka z vysílání: "Na čem je každý z projektů, které jste zmínil?"
Záložní systém ve WAL-G je napsán v Go. Toto je jeden z novějších projektů, na kterém jsme pracovali. Jsou mu doslova pouhé 3 roky. A databáze je často o spolehlivosti. A to znamená, že databáze jsou poměrně staré a jsou obvykle psány v C. Projekt Postgres začal asi před 30 lety. Pak byla C89 tou správnou volbou. A je na něm napsáno Postgres. Modernější databáze jako ClickHouse jsou obvykle napsány v C++. Veškerý vývoj systému je založen na C a C++.
Otázka od našeho finančního manažera, který je v Cloudu zodpovědný za výdaje: „Proč Cloud utrácí peníze na podporu open source?“
Zde je jednoduchá odpověď pro finančního manažera. Děláme to pro zlepšení našich služeb. Jakými způsoby se můžeme zlepšit? Můžeme dělat věci efektivněji, rychleji a dělat věci škálovatelnějšími. Pro nás je ale tento příběh především o spolehlivosti. Například v zálohovacím systému kontrolujeme 100 % záplat, které se na něj vztahují. Víme, jaký je kód. A je pro nás pohodlnější zavádět do výroby nové verze. Tedy v první řadě jde o důvěru, o připravenost k vývoji a o spolehlivost
Další otázka: „Liší se požadavky externích uživatelů, kteří žijí v Yandex.Cloud, od interních uživatelů, kteří žijí v interním cloudu?
Zátěžový profil je samozřejmě jiný. Ale z pohledu mého oddělení všechny speciální a zajímavé případy vznikají na nestandardní zátěži. Vývojáři s představivostí, vývojáři, kteří dělají neočekávané, se pravděpodobně najdou jak interně, tak externě. V tomto ohledu jsme na tom všichni přibližně stejně. A pravděpodobně jedinou důležitou vlastností v rámci provozu databází Yandex bude to, že uvnitř Yandexu máme učení. V určitém okamžiku se některá zóna dostupnosti úplně dostane do stínu a všechny služby Yandex musí i přes to nějak dál fungovat. To je malý rozdíl. Ale vytváří mnoho výzkumného vývoje na rozhraní databáze a síťového zásobníku. Jinak externí a interní instalace generují stejné požadavky na funkce a podobné požadavky na zlepšení spolehlivosti a výkonu.
Další otázka: „Jak vy osobně vnímáte skutečnost, že mnoho z toho, co děláte, využívají ostatní Clouds?“ Nebudeme jmenovat konkrétní, ale mnoho projektů, které byly provedeny v Yandex.Cloud, se používá v cloudech jiných lidí.
To je hustý. Za prvé, je to znamení, že jsme něco udělali správně. A škrábe to ego. A jsme si jistější, že jsme se rozhodli správně. Na druhou stranu je to naděje, že nám to v budoucnu přinese nové nápady, nové požadavky od uživatelů třetích stran. Většinu problémů na GitHubu vytvářejí jednotliví správci systému, jednotliví DBA, jednotliví architekti, jednotliví inženýři, ale někdy přijdou lidé se systematickými zkušenostmi a řeknou, že ve 30 % určitých případů tento problém máme a pojďme se zamyslet, jak ho vyřešit. Na to se těšíme nejvíc. Těšíme se na sdílení zkušeností s dalšími cloudovými platformami.
Hodně jste mluvil o maratonu. Vím, že jsi běžel maraton v Moskvě. Jako výsledek? Předběhl kluky z PostgreSQL?
Ne, Oleg Bartunov běží velmi rychle. Skončil hodinu přede mnou. Celkově jsem spokojený s tím, jak daleko jsem se dostal. Pro mě bylo úspěchem už jen dokončení. Celkově je překvapivé, že v postgres komunitě je tolik běžců. Zdá se mi, že existuje určitý vztah mezi aerobním sportem a touhou po systémovém programování.
Říkáte, že v ClickHouse nejsou žádní běžci?
Vím jistě, že tam jsou. ClickHouse je také databáze. Mimochodem, Oleg mi teď píše: "Půjdeme si po hlášení zaběhat?" To je skvělý nápad.
Další otázka z vysílání od Nikity: „Proč jste chybu v Greenplum opravili sami a nedali ji juniorům?“ Je pravda, že není příliš jasné, co je chyba a ve které službě, ale pravděpodobně to znamená tu, o které jste mluvili.
Ano, v zásadě to mohlo být někomu dáno. Byl to jen kód, který jsem právě změnil. A bylo přirozené v tom hned pokračovat. V zásadě je myšlenka sdílení odborných znalostí s týmem dobrý nápad. O úkoly Greenplum se určitě podělíme mezi všechny členy naší divize.
Protože se bavíme o juniorech, je tu otázka. Osoba se rozhodla vytvořit první commit v Postgresu. Co musí udělat, aby provedl první závazek?
To je zajímavá otázka: "Kde začít?" Obvykle je docela těžké začít s něčím v jádře. V Postgresu je například seznam úkolů. Ale ve skutečnosti je to list toho, co se pokusili udělat, ale neuspěli. To jsou složité věci. A obvykle můžete v ekosystému najít nějaké nástroje, některá rozšíření, která lze vylepšit, která přitahují menší pozornost vývojářů jádra. A podle toho tam je více bodů pro růst. V programu Google Summer of code komunita postgres každý rok předkládá mnoho různých témat, která by se dala řešit. Letos jsme měli, myslím, tři studenty. Jeden dokonce psal ve WAL-G o tématech, která jsou pro Yandex důležitá. V Greenplum je vše jednodušší než v komunitě Postgres, protože hackeři Greenplum velmi dobře ošetřují pull requesty a hned začnou revidovat. Odeslání patche do Postgresu je otázkou měsíců, ale Greenplum přijde za den a uvidí, co jste udělali. Další věc je, že Greenplum potřebuje řešit současné problémy. Greenplum se příliš nepoužívá, takže nalezení vašeho problému je poměrně obtížné. A v první řadě musíme samozřejmě řešit problémy.
Zdroj: www.habr.com