A Yandex hozzájárulását a következő adatbázisokhoz felülvizsgáljuk.
- Kattintson a Ház gombra
- Odüsszea
- Helyreállítás egy adott időponthoz (WAL-G)
- PostgreSQL (beleértve a logerrorokat, az Amchecket, a heapchecket)
- Greenplum
videók:
Helló Világ! A nevem Andrej Borodin. A Yandex.Cloudnál pedig nyílt relációs adatbázisokat fejlesztek a Yandex.Cloud és a Yandex.Cloud kliensek érdekében.
Ebben a beszélgetésben azokról a kihívásokról fogunk beszélni, amelyekkel a nyílt adatbázisokkal szembe kell nézni. Miért fontos? Mert apró, apró problémák, amelyekből, mint a szúnyogok, aztán elefántok lesznek. Nagyok lesznek, ha sok klasztered van.
De nem ez a fő. Hihetetlen dolgok történnek. Olyan dolgok, amelyek millióból egy esetben fordulnak elő. Felhőkörnyezetben pedig erre fel kell készülni, mert hihetetlen dolgok válnak valószínűvé, ha valami nagy léptékben létezik.
De! Mi az előnye a nyílt adatbázisoknak? A helyzet az, hogy elméleti lehetősége van bármilyen probléma kezelésére. Megvan a forráskód, van programozási tudásod. Kombináljuk és működik.
Milyen megközelítések léteznek a nyílt forráskódú szoftvereken való munka során?
- A legegyszerűbb megközelítés a szoftver használata. Ha protokollokat használsz, ha szabványokat, ha formátumokat használsz, ha nyílt forráskódú szoftverben írsz lekérdezéseket, akkor már támogatja.
- Nagyobbá teszi az ökoszisztémáját. Ezzel növeli a hiba korai felismerésének valószínűségét. Növeli ennek a rendszernek a megbízhatóságát. Növeli a fejlesztők elérhetőségét a piacon. Ön javítja ezt a szoftvert. Már akkor is közreműködő vagy, ha megcsináltad a stílust, és bütykölsz valamit.
- Egy másik érthető megközelítés a nyílt forráskódú szoftverek szponzorálása. Ilyen például a jól ismert Google Summer of Code program, amikor a Google nagyszámú diáknak a világ minden tájáról fizet érthető pénzt azért, hogy bizonyos licencfeltételeknek megfelelő nyílt szoftverprojekteket dolgozzanak ki.
- Ez egy nagyon érdekes megközelítés, mert lehetővé teszi a szoftver fejlődését anélkül, hogy a hangsúlyt eltennénk a közösségtől. A Google, mint technológiai óriás, nem azt mondja, hogy ezt a funkciót szeretnénk, hanem ezt a hibát akarjuk kijavítani, és ott kell ásnunk. A Google azt mondja: „Tedd, amit csinálsz. Csak dolgozzon tovább úgy, ahogy eddig, és minden rendben lesz.”
- A nyílt forráskódban való részvétel következő megközelítése a részvétel. Ha problémája van a nyílt forráskódú szoftverrel, és vannak fejlesztők, a fejlesztők elkezdik megoldani a problémákat. Kezdik hatékonyabbá tenni infrastruktúráját, gyorsabbá és megbízhatóbbá tenni a programjait.
Az egyik leghíresebb Yandex projekt a nyílt forráskódú szoftverek területén a ClickHouse. Ez egy olyan adatbázis, amely a Yandex.Metrica előtt álló kihívásokra adott válaszként született.
Adatbázisként pedig nyílt forráskódú, hogy létrehozzanak egy ökoszisztémát, és más fejlesztőkkel együtt fejlesszék (nem csak a Yandexen belül). És most ez egy nagy projekt, amelyben sok különböző cég vesz részt.
A Yandex.Cloudban létrehoztuk a ClickHouse-t a Yandex Object Storage, azaz a felhőalapú tárhely tetején.
Miért fontos ez a felhőben? Mert bármilyen adatbázis működik ebben a háromszögben, ebben a piramisban, ebben a memóriatípus-hierarchiában. Gyors, de kicsi regiszterei és olcsó nagy, de lassú SSD-jei, merevlemezei és néhány egyéb blokkeszközei vannak. És ha Ön hatékony a piramis tetején, akkor gyors adatbázisa van. Ha ennek a piramisnak az alján hatékony vagy, akkor van egy skálázott adatbázisod. És ebben a tekintetben egy újabb réteg alulról történő hozzáadása logikus megközelítés az adatbázis skálázhatóságának növelésére.
Hogyan lehetne megcsinálni? Ez egy fontos pont ebben a jelentésben.
- Megvalósíthatnánk a ClickHouse-t MDS-en keresztül. Az MDS egy belső Yandex felhőalapú tárolási felület. Bonyolultabb, mint az elterjedt S3 protokoll, de blokkeszközhöz jobban megfelel. Adatrögzítésre alkalmasabb. Több programozást igényel. A programozók programoznak, ez még jó, érdekes.
- Az S3 egy elterjedtebb megközelítés, amely egyszerűbbé teszi az interfészt bizonyos típusú munkaterhelésekhez való kisebb alkalmazkodás árán.
Természetesen, mivel szeretnénk a teljes ClickHouse ökoszisztéma számára funkcionalitást biztosítani, és a Yandex.Cloudon belül elvégezni a szükséges feladatokat, úgy döntöttünk, hogy gondoskodunk arról, hogy az egész ClickHouse közösség részesüljön belőle. A ClickHouse-t S3-on valósítottuk meg, nem pedig a ClickHouse-t az MDS-n. Ez pedig rengeteg munka.
referenciák:
"Fájlrendszer absztrakciós réteg"
"AWS SDK S3 integráció"
„Az IDisk interfész alap megvalósítása S3-hoz”
"naplótároló motorok integrációja IDisk interfésszel"
"Naplómotor támogatása az S3-hoz és a SeekableReadBufferhez"
"Storage Stripe Log S3 támogatás"
"Storage MergeTree kezdeti támogatása az S3-hoz"
"A MergeTree teljes támogatása az S3-hoz"
"Support ReplicatedMergeTree over S3"
„Alapértelmezett hitelesítő adatok és egyéni fejlécek hozzáadása az s3 tárhelyhez”
"S3 dinamikus proxykonfigurációval"
"S3 proxy megoldóval"
Ez egy lekérési kérelem lista virtuális fájlrendszer megvalósításához a ClickHouse-ban. Ez nagyszámú lehívási kérés.
referenciák:
"A DiskS3 hardlinkek optimális megvalósítása"
„S3 HTTP-kliens – ne másoljon válaszfolyamot a memóriába”
„Kerülje a teljes válaszfolyam memóriába másolását az S3 HTTP-ben
ügyfél"
"Képes a gyorsítótárba jelölni és indexelni a fájlokat S3 lemezen"
"Részek áthelyezése a DiskLocalból a DiskS3-ba párhuzamosan"
De a munka ezzel nem ért véget. A funkció elkészítése után további munkára volt szükség a funkció optimalizálása érdekében.
referenciák:
"Add SelectedRows és SelectedBytes események"
"Profilozási események hozzáadása az S3 kérésből a system.events fájlhoz"
"Add QueryTimeMicroseconds, SelectQueryTimeMicroseconds és InsertQueryTimeMicroseconds"
És akkor diagnosztizálhatóvá kellett tenni, monitorozást beállítani és kezelhetővé tenni.
És mindez azért történt, hogy az egész közösség, az egész ClickHouse ökoszisztéma megkapja ennek a munkának az eredményét.
Térjünk át a tranzakciós adatbázisokra, az OLTP adatbázisokra, amelyek közelebb állnak hozzám személy szerint.
Ez a nyílt forráskódú DBMS-fejlesztési részleg. Ezek a srácok utcai varázslatot csinálnak, hogy javítsák a tranzakciós nyílt adatbázisokat.
Az egyik projekt, amelynek egy példáján beszélhetünk arról, hogyan és mit csinálunk, a Postgres-i Connection Pooler.
A Postgres egy folyamat adatbázis. Ez azt jelenti, hogy az adatbázisnak a lehető legkevesebb hálózati kapcsolattal kell rendelkeznie, amely tranzakciókat kezel.
Másrészt felhőkörnyezetben tipikus helyzet az, amikor egy klaszterbe egyszerre ezer kapcsolat érkezik. A kapcsolattároló feladata pedig az, hogy ezer kapcsolatot csomagoljon néhány szerverkapcsolatba.
Azt mondhatjuk, hogy a kapcsolati pooler a telefonkezelő, aki átrendezi a bájtokat úgy, hogy azok hatékonyan eljussanak az adatbázisba.
Sajnos nincs jó orosz szó a connection poolerre. Néha multiplexer kapcsolatoknak nevezik. Ha tudja, hogy hívja a kapcsolati gyűjtőt, akkor feltétlenül mondja el, nagyon szívesen beszélek a megfelelő orosz szaknyelven.
Megvizsgáltuk a felügyelt postgres fürthöz alkalmas kapcsolat-poolezőket. És a PgBouncer volt a legjobb választás számunkra. De számos problémába ütköztünk a PgBouncerrel. Sok évvel ezelőtt Volodya Borodin arról számolt be, hogy PgBouncer-t használunk, mindent szeretünk, de vannak árnyalatok, van min dolgozni.
És dolgoztunk. Kijavítottuk a felmerült problémákat, javítottuk a Bouncert, és megpróbáltuk a lehívási kérelmeket felfelé tolni. De az alapvető egyszálassal nehéz volt dolgozni.
Cascade-eket kellett gyűjtenünk a foltozott Bouncers-ból. Ha sok egyszálú kidobónk van, a felső rétegen lévő kapcsolatok átkerülnek a Bouncers belső rétegébe. Ez egy rosszul menedzselt rendszer, amelyet nehéz felépíteni és oda-vissza méretezni.
Arra a következtetésre jutottunk, hogy létrehoztuk a saját kapcsolatgyűjtőnket, ami az Odyssey nevet viseli. A nulláról írtuk.
2019-ben a PgCon konferencián bemutattam ezt a poolert a fejlesztői közösségnek. Most valamivel kevesebb, mint 2 csillagunk van a GitHubon, vagyis a projekt él, a projekt népszerű.
És ha létrehoz egy Postgres-fürtöt a Yandex.Cloudban, akkor az egy beépített Odyssey-vel rendelkező fürt lesz, amelyet a fürt oda-vissza méretezésekor újrakonfigurálnak.
Mit tanultunk ebből a projektből? Egy versengő projekt elindítása mindig agresszív lépés, szélsőséges intézkedés, ha azt mondjuk, hogy vannak olyan problémák, amelyek nem oldódnak meg elég gyorsan, nem a számunkra megfelelő időintervallumban oldódnak meg. De ez egy hatékony intézkedés.
A PgBouncer gyorsabban kezdett fejlődni.
És most más projektek is megjelentek. Például a pgagroal, amelyet a Red Hat fejlesztői fejlesztettek ki. Hasonló célokat követnek és hasonló ötleteket valósítanak meg, de természetesen saját sajátosságaikkal, amelyek közelebb állnak a pgagroal fejlesztőihez.
A postgres közösséggel való együttműködés másik esete a visszaállítás egy adott időponthoz. Ez a hiba utáni helyreállítás, ez egy biztonsági mentésből való helyreállítás.
Sok biztonsági másolat létezik, és mindegyik más. Szinte minden Postgres szállító rendelkezik saját biztonsági mentési megoldással.
Ha veszed az összes tartalék rendszert, létrehozol egy jellemző mátrixot és viccesen kiszámolod a determinánst ebben a mátrixban, akkor az nulla lesz. Mit is jelent ez? Mi van akkor, ha vesz egy adott biztonsági mentési fájlt, akkor azt nem lehet összeállítani az összes többi darabból. Egyedi a megvalósításában, egyedi a rendeltetésében, egyedi az ötletekben, amelyek bele vannak ágyazva. És mindegyik konkrét.
Amíg ezen a problémán dolgoztunk, a CitusData elindította a WAL-G projektet. Ez egy biztonsági mentési rendszer, amely a felhőkörnyezet figyelembevételével készült. Most a CitusData már a Microsoft része. És abban a pillanatban nagyon tetszettek a WAL-G kezdeti kiadásaiban megfogalmazott ötletek. És elkezdtünk hozzájárulni ehhez a projekthez.
Jelenleg több tucat fejlesztő vesz részt ebben a projektben, de a WAL-G 10 legnagyobb közreműködője között 6 Yandexoid található. Sok ötletünket elhoztuk oda. És természetesen mi magunk valósítottuk meg, teszteltük, magunk állítottuk be a gyártásba, mi magunk használjuk, mi magunk találjuk ki, merre tovább, miközben a nagy WAL-G közösséggel lépünk kapcsolatba.
És a mi szempontunkból mostanra ez a biztonsági mentési rendszer, beleértve erőfeszítéseinket is, optimális lett a felhőkörnyezet számára. Ez a Postgres felhőben történő biztonsági mentésének legjobb költsége.
Mit jelent? Egy meglehetősen nagy ötletet hirdettünk: a biztonsági mentésnek biztonságosnak, olcsónak és a lehető leggyorsabban visszaállíthatónak kell lennie.
Miért lenne olcsó az üzemeltetése? Ha semmi sem romlik el, nem kell tudnia, hogy vannak biztonsági másolatai. Minden jól működik, a lehető legkevesebb CPU-t vesztegeti, a lehető legkevesebb lemezerőforrást használja fel, és a lehető legkevesebb bájtot küldi a hálózatnak, hogy ne zavarja az értékes szolgáltatásainak terhelését.
És amikor minden elromlik, például az admin eldobta az adatokat, valami elromlott, és sürgősen vissza kell menni a múltba, akkor minden pénzzel helyreállsz, mert gyorsan és sértetlenül szeretnéd visszakapni az adataidat.
És ezt az egyszerű ötletet hirdettük. És nekünk úgy tűnik, sikerült megvalósítanunk.
De ez még nem minden. Még egy apróságot akartunk. Sokféle adatbázist akartunk. Nem minden ügyfelünk használja a Postgrest. Vannak, akik MySQL-t, MongoDB-t használnak. A közösségben más fejlesztők támogatták a FoundationDB-t. És ez a lista folyamatosan bővül.
A közösségnek tetszik az az ötlet, hogy az adatbázis felügyelt környezetben, a felhőben fut. A fejlesztők pedig karbantartják adatbázisaikat, amelyekről biztonsági mentési rendszerünkkel a Postgres-szel együtt egységesen menthetők.
Mit tanultunk ebből a történetből? Termékünk, mint fejlesztési részleg nem kódsorok, nem utasítások, nem fájlok. Termékünk nem pull kérések. Ezeket az ötleteket közvetítjük a közösség felé. Ez a technológiai szakértelem és a technológia elmozdulása a felhőkörnyezet felé.
Van egy ilyen adatbázis, mint a Postgres. Nekem a Postgres mag tetszik a legjobban. Sok időt töltök a Postgres mag fejlesztésével a közösséggel.
De itt meg kell mondani, hogy a Yandex.Cloud rendelkezik a felügyelt adatbázisok belső telepítésével. És ez nagyon régen kezdődött a Yandex.Mailben. Az a szakértelem, amely immár a kezelt Postgreshez vezetett, akkor halmozódott fel, amikor a posta a Postgresbe akart költözni.
A levelezés nagyon hasonló követelményeket támaszt a felhőhöz. Szüksége van arra, hogy az adatok bármely pontján váratlan exponenciális növekedésre tudjon lépni. És a levél már megterhelt néhány százmillió postafiókkal, rengeteg felhasználóval, akik folyamatosan sok kérést intéznek.
Ez pedig elég komoly kihívás volt a Postgrest fejlesztő csapat számára. Akkoriban minden problémát jelentett a közösségnek. És ezeket a problémákat a közösség kijavította, és helyenként kijavította még néhány más adatbázis fizetős támogatásának szintjén is, sőt még jobban is. Ez azt jelenti, hogy levelet küldhet a PgSQL hackernek, és 40 percen belül választ kap. Egyes adatbázisokban a fizetett támogatás azt gondolhatja, hogy fontosabb dolgok vannak, mint a hiba.
Most a Postgres belső telepítése néhány petabájtnyi adatot tartalmaz. Ez néhány millió kérés másodpercenként. Ez több ezer klaszter. Nagyon nagyszabású.
De van egy árnyalat. Nem divatos hálózati meghajtókon él, hanem meglehetősen egyszerű hardvereken. És van egy tesztkörnyezet kifejezetten az érdekes új dolgokhoz.
És egy bizonyos pillanatban a tesztkörnyezetben kaptunk egy üzenetet, amely azt jelezte, hogy az adatbázis-indexek belső invariánsait megsértették.
Az invariáns valamiféle kapcsolat, amelytől elvárjuk, hogy mindig megmaradjon.
Nagyon kritikus helyzet számunkra. Azt jelzi, hogy egyes adatok elveszhettek. Az adatvesztés pedig valami egyenesen katasztrofális.
Az általános elképzelés, amelyet a felügyelt adatbázisokban követünk, az, hogy még erőfeszítéssel is nehéz lesz adatvesztés. Még ha szándékosan távolítja is el őket, akkor is figyelmen kívül kell hagynia a távollétüket hosszú ideig. Az adatbiztonság olyan vallás, amelyet nagyon szorgalmasan követünk.
És itt előáll egy olyan helyzet, ami azt sugallja, hogy adódhat olyan helyzet, amire nem biztos, hogy vagyunk felkészülve. És elkezdtünk felkészülni erre a helyzetre.
Az első dolgunk az volt, hogy elástuk a rönköket ebből a több ezer fürtből. Megtaláltuk, hogy a fürtök közül melyik található olyan problémás firmware-szel rendelkező lemezeken, amelyek elvesztették az adatoldal-frissítéseket. Megjelölte az összes Postgres adatkódot. Azokat az üzeneteket, amelyek a belső invariánsok megsértését jelzik, olyan kóddal jelöltük meg, amely az adatsérülések észlelésére szolgál.
Ezt a foltot gyakorlatilag nagy vita nélkül elfogadta a közösség, mert minden konkrét esetben nyilvánvaló volt, hogy valami rossz történt, és jelenteni kell a naplónak.
Ezek után eljutottunk arra a pontra, hogy van naplókat vizsgáló felügyeletünk. Gyanús üzenetek esetén pedig felébreszti az ügyeleteset, az ügyeletes pedig megjavítja.
De! A naplók szkennelése olcsó művelet egy klaszteren, és katasztrofálisan drága ezer fürt számára.
Írtunk egy kiterjesztést . Létrehoz egy nézetet az adatbázisról, amelyben olcsón és gyorsan kiválaszthatja a múltbeli hibák statisztikai adatait. Ha pedig fel kell ébresztenünk az ügyeletes tisztet, akkor ezt a gigabájtos fájlok szkennelése nélkül, hanem a hash táblából néhány byte-ot kivonva megtudjuk.
Ezt a kiterjesztést például a(z) lerakatában fogadták el . Ha használni szeretné, akkor saját maga is telepítheti. Természetesen nyílt forráskódú.
De ez még nem minden. Elkezdtük használni az Amchecket, egy közösség által épített bővítményt, hogy megtaláljuk a változatlan jogsértéseket az indexekben.
És rájöttünk, hogy ha nagy mennyiségben működteti, akkor vannak hibák. Elkezdtük javítani őket. Javításainkat elfogadtuk.
Felfedeztük, hogy ez a bővítmény nem tudja elemezni a GiST és GIT indexeket. Támogattuk őket. De erről a támogatásról még mindig tárgyal a közösség, mert ez egy viszonylag új funkció, és sok részlet van benne.
És azt is felfedeztük, hogy az indexek megsértésének ellenőrzésekor a replikációs vezetőn, a mesteren minden jól működik, de a replikákon, a követőn a korrupció keresése nem olyan hatékony. Nem minden invariánst ellenőriz. És egy változatlan nagyon zavart minket. Másfél évig kommunikáltunk a közösséggel, hogy lehetővé tegyük a replikák ellenőrzését.
Kódot írtunk, aminek követnie kell az összes can... protokollt. Ezt a javítást elég sokáig tárgyaltuk Peter Gaghannal a Crunchy Data-tól. Kicsit módosítania kellett a meglévő B-fán Postgresben, hogy elfogadja ezt a javítást. Elfogadták. És most már a replikák indexeinek ellenőrzése is elég hatékony lett ahhoz, hogy észlelje az általunk tapasztalt jogsértéseket. Vagyis ezeket a jogsértéseket okozhatják a lemez firmware hibái, a Postgres hibái, a Linux kernel hibái és hardverproblémák. A problémaforrások meglehetősen kiterjedt listája, amelyekre készültünk.
De az indexek mellett van egy olyan rész, mint a heap, vagyis az adatok tárolási helye. És nem sok invariánst lehetne ellenőrizni.
Van egy Heapcheck nevű bővítményünk. Elkezdtük fejleszteni. És ezzel párhuzamosan velünk együtt az EnterpriseDB cég is elkezdett egy modult írni, amit ugyanúgy Heapcheck-nek hívtak. Csak mi hívtuk PgHeapcheck-nek, ők pedig csak Heapcheck-nek. Hasonló funkciókkal, kicsit más aláírással, de ugyanazokkal az ötletekkel rendelkeznek. Néhány helyen kicsit jobban megvalósították őket. És korábban közzétették nyílt forráskódban.
Most pedig az ő terjeszkedésüket fejlesztjük, mert ez már nem az ő terjeszkedésük, hanem a közösség terjeszkedése. És a jövőben ez a kernel része, amelyet mindenki megkap, hogy előre tájékozódhasson a jövőbeli problémákról.
Egyes helyeken arra a következtetésre jutottunk, hogy téves pozitív eredmények vannak a monitoring rendszereinkben. Például az 1C rendszer. Adatbázis használatakor a Postgres néha olyan adatokat ír bele, amelyeket el tud olvasni, de a pg_dump nem tudja olvasni.
Ez a helyzet korrupciónak tűnt a problémaészlelő rendszerünk számára. Az ügyeletes tisztet felébresztették. Az ügyeletes megnézte, mi történik. Egy idő után jött egy ügyfél, és azt mondta, hogy problémáim vannak. A kísérő elmagyarázta, mi a probléma. De a probléma a Postgres magjában van.
Találtam egy vitát erről a funkcióról. És azt írta, hogy találkoztunk ezzel a funkcióval, és ez kellemetlen volt, az ember felébredt éjszaka, hogy kitalálja, mi az.
A közösség így válaszolt: "Ó, tényleg meg kell javítanunk."
Van egy egyszerű hasonlatom. Ha olyan cipőben jársz, amiben van egy homokszem, akkor elvileg tovább tudsz lépni - semmi gond. Ha több ezer embernek ad el csizmát, akkor csináljunk csizmát homok nélkül. És ha a cipőid egyik használója maratont fog futni, akkor nagyon jó cipőt szeretne készíteni, majd az összes felhasználóra méretezni. És az ilyen váratlan felhasználók mindig a felhő környezetben vannak. Mindig vannak olyan felhasználók, akik valamilyen eredeti módon használják ki a fürtöt. Erre mindig fel kell készülni.
Mit tanultunk itt? Egy egyszerű dolgot tanultunk: a legfontosabb, hogy elmagyarázzuk a közösségnek, hogy probléma van. Ha a közösség felismerte a problémát, akkor természetes versengés alakul ki a probléma megoldásáért. Mert mindenki egy fontos problémát akar megoldani. Minden eladó, minden hacker megérti, hogy ők maguk is ráléphetnek erre a rake-re, ezért ki akarják iktatni őket.
Ha dolgozol egy problémán, de az rajtad kívül senkit nem zavar, de szisztematikusan dolgozol rajta, és végső soron problémának számít, akkor a lehívási kérelmed biztosan elfogadásra kerül. A javítást elfogadják, a fejlesztéseit vagy akár a javítási kéréseit a közösség felülvizsgálja. A nap végén jobbá tesszük egymás számára az adatbázist.
Érdekes adatbázis a Greenplum. Ez egy nagyon párhuzamos adatbázis a Postgres kódbázison, amit nagyon ismerek.
A Greenplum pedig érdekes funkciókkal rendelkezik – optimalizált táblázatok hozzáfűzése. Ezek olyan táblázatok, amelyeket gyorsan hozzáadhat. Lehetnek oszloposak vagy sorosak.
De nem volt klaszterezés, azaz nem volt olyan funkció, ahol a táblázatban található adatokat az egyik indexben lévő sorrend szerint rendezhetné el.
A taxis srácok odajöttek hozzám, és azt mondták: „Andrey, ismered Postgrest. És itt is majdnem ugyanaz. Váltson 20 percre. Fogod és csinálod." Azt hittem, igen, ismerem a Postgrest, 20 percre vált – ezt meg kell tennem.
De nem, nem 20 perc volt, hónapokig írtam. A PgConf.Russia konferencián megkerestem Heikki Linakangast a Pivotaltól, és megkérdeztem: „Van ezzel valami probléma? Miért nincs hozzáfűzéssel optimalizált táblafürtözés?” Azt mondja: „Ön veszi az adatokat. Válogatsz, átrendezsz. Ez csak egy munka." Én: "Ó, igen, csak fogni kell, és meg kell csinálni." Azt mondja: „Igen, ehhez szabad kezekre van szükségünk.” Arra gondoltam, hogy ezt mindenképpen meg kell tennem.
És néhány hónappal később benyújtottam egy lehívási kérelmet, amely megvalósította ezt a funkciót. Ezt a lehívási kérelmet a Pivotal a közösséggel együtt felülvizsgálta. Természetesen voltak hibák.
De a legérdekesebb az, hogy amikor ezt a lehívási kérelmet összevonták, magában a Greenplumban is találtak hibákat. Azt tapasztaltuk, hogy a kupactáblák néha megszakítják a tranzakciókat, amikor fürtözöttek. És ez egy olyan dolog, amit javítani kell. És azon a helyen van, amit az imént megérintettem. És a természetes reakcióm az volt: oké, hadd tegyem ezt én is.
Kijavítottam ezt a hibát. Lehívási kérelmet küldött a javítóknak. Megölték.
Utána kiderült, hogy ezt a funkciót a Greenplum PostgreSQL 12-es verziójában kell megszerezni. Vagyis a 20 perces kaland újabb érdekes kalandokkal folytatódik. Érdekes volt megérinteni a jelenlegi fejlesztést, ahol a közösség új és legfontosabb vonásokat vág. Fagyott.
De ezzel nem ért véget. Mindenek után kiderült, hogy mindehhez dokumentációt kell írnunk.
Elkezdtem dokumentációt írni. Szerencsére jöttek a Pivotal dokumentumfilmesei. Az angol az anyanyelvük. Segítettek a dokumentációban. Valójában ők maguk írták át valódi angolra, amit javasoltam.
És itt, úgy tűnik, a kaland véget ért. És tudod, mi történt akkor? A taxis srácok odajöttek hozzám, és azt mondták: "Még mindig van két kaland, mindegyik 10 perces." És mit mondjak nekik? Mondtam, hogy most nagyszabású beszámolót adok, aztán meglátjuk a kalandjaidat, mert ez egy érdekes munka.
Mit tanultunk ebből az esetből? Mivel a nyílt forráskóddal való munka mindig egy adott személlyel, mindig a közösséggel dolgozik. Mert minden egyes szakaszban dolgoztam néhány fejlesztővel, néhány tesztelővel, néhány hackerrel, néhány dokumentumfilmessel, néhány építésszel. Nem Greenplummal dolgoztam, hanem Greenplum körüli emberekkel.
De! Van még egy fontos pont - ez csak munka. Vagyis jössz, iszol kávét, írsz kódot. Mindenféle egyszerű invariáns működik. Csináld normálisan - jó lesz! És ez egy nagyon érdekes munka. Erre a munkára a Yandex.Cloud kliensek, a fürteink felhasználói a Yandexen belül és kívül egyaránt kérték. És úgy gondolom, hogy növekedni fog azoknak a projekteknek a száma, amelyekben részt veszünk, és a részvételünk mélysége is nőni fog.
Ez minden. Térjünk át a kérdésekre.
Kérdések szekciója
Helló! Újabb kérdés-felelet ülésünk van. És a stúdióban Andrei Borodin. Ez az a személy, aki az imént mesélt a Yandex.Cloud és a Yandex hozzájárulásáról a nyílt forráskódhoz. Jelen beszámolónk most nem teljes egészében a Felhőről szól, ugyanakkor ilyen technológiákon is alapulunk. Anélkül, amit a Yandexen belül csináltál, nem lenne szolgáltatás a Yandex.Cloudban, ezért személyesen köszönöm. És az első kérdés az adásból: „Miről írnak az általad említett projektek közül?”
A WAL-G biztonsági mentési rendszere Go nyelven íródott. Ez az egyik újabb projekt, amelyen dolgoztunk. Szó szerint még csak 3 éves. Az adatbázis pedig gyakran a megbízhatóságról szól. Ez pedig azt jelenti, hogy az adatbázisok meglehetősen régiek, és általában C nyelven íródnak. A Postgres projekt körülbelül 30 évvel ezelőtt kezdődött. Akkor a C89 volt a megfelelő választás. És Postgres van ráírva. A modernebb adatbázisok, mint például a ClickHouse, általában C++ nyelven íródnak. Minden rendszerfejlesztés a C és a C++ köré épül.
Pénzügyi vezetőnk kérdése, aki a Cloudnál a költségekért felelős: „Miért költ a Cloud a nyílt forráskód támogatására?”
Itt van egy egyszerű válasz a pénzügyi vezető számára. Ezt azért tesszük, hogy szolgáltatásainkat jobbá tegyük. Milyen módokon tehetünk jobbat? Hatékonyabban, gyorsabban végezhetjük el a dolgokat, és skálázhatóbbá tehetjük a dolgokat. De számunkra ez a történet elsősorban a megbízhatóságról szól. Például egy biztonsági mentési rendszerben a rá vonatkozó javítások 100%-át átnézzük. Tudjuk, mi a kód. És sokkal kényelmesebb az új verziók gyártásba való bevezetése. Vagyis mindenekelőtt a bizalomról, a fejlődésre való felkészültségről és a megbízhatóságról van szó
Egy másik kérdés: „Eltérnek a Yandex.Cloudban élő külső felhasználók követelményei a belső felhőben élő belső felhasználóktól?”
A terhelési profil természetesen más. De az én osztályom szempontjából minden különleges és érdekes eset nem szabványos terhelésen jön létre. A képzelőerővel rendelkező fejlesztők, a váratlan fejlesztők valószínűleg megtalálhatók belülről és kívülről egyaránt. Ebben a tekintetben mindannyian megközelítőleg egyformák vagyunk. És valószínűleg az egyetlen fontos tulajdonság az adatbázisok Yandex-működésén belül az lesz, hogy a Yandexen belül van egy tanítás. Egy bizonyos ponton egy elérhetőségi zóna teljesen árnyékba kerül, és ennek ellenére az összes Yandex szolgáltatásnak valahogy tovább kell működnie. Ez egy kis különbség. De rengeteg kutatási fejlesztést hoz létre az adatbázis és a hálózati verem felületén. Ellenkező esetben a külső és belső telepítések ugyanazokat a funkciókra vonatkozó kéréseket generálják, valamint a megbízhatóság és a teljesítmény javítására vonatkozó hasonló kéréseket.
Következő kérdés: „Hogyan vélekedik arról, hogy tevékenységének nagy részét más Felhők használják?” Konkrétakat nem fogunk megnevezni, de sok, a Yandex.Cloudban végzett projektet mások felhői is használnak.
Ez király. Először is, ez annak a jele, hogy valamit jól csináltunk. És megkarcolja az egót. És jobban bízunk abban, hogy jól döntöttünk. Másrészt ez a remény, hogy a jövőben ez új ötleteket, új kéréseket hoz nekünk a külső felhasználóktól. A GitHubon a legtöbb problémát egyéni rendszeradminisztrátorok, egyéni DBA-k, egyéni építészek, egyéni mérnökök hozzák létre, de néha jönnek szisztematikus tapasztalattal rendelkező emberek, és azt mondják, hogy bizonyos esetek 30%-ában előfordul ez a probléma, és gondoljuk át, hogyan oldjuk meg. Ezt várjuk a legjobban. Várjuk, hogy megosszuk tapasztalatainkat más felhőplatformokkal.
Sokat beszéltél a maratonról. Tudom, hogy lefutott egy maratont Moszkvában. Ennek eredményeként? Megelőzte a PostgreSQL srácait?
Nem, Oleg Bartunov nagyon gyorsan fut. Egy órával előttem végzett. Összességében elégedett vagyok azzal, hogy hova jutottam. Számomra már a befejezés is eredmény volt. Összességében meglepő, hogy ennyi futó van a postgres közösségben. Nekem úgy tűnik, hogy van valamiféle kapcsolat az aerob sportok és a rendszerprogramozás iránti vágy között.
Azt akarod mondani, hogy a ClickHouse-ban nincsenek futók?
Biztosan tudom, hogy ott vannak. A ClickHouse egyben adatbázis is. Egyébként Oleg most ezt írja nekem: "Menjünk futni a jelentés után?" Ez egy nagyszerű ötlet.
Egy másik kérdés Nikita adásából: „Miért javítottad ki magad a Greenplum hibáját, és miért nem adtad oda a junioroknak?” Igaz, nem nagyon világos, hogy mi a hiba, és melyik szolgáltatásban, de valószínűleg azt jelenti, amiről beszéltél.
Igen, elvileg oda lehetett volna adni valakinek. Csak a kódot változtattam meg. És természetes volt, hogy azonnal folytatjuk. Elvileg jó ötlet a szakértelem megosztása a csapattal. A Greenplum feladatokat minden bizonnyal megosztjuk divíziónk minden tagja között.
Mivel juniorokról beszélünk, itt egy kérdés. A személy úgy döntött, hogy létrehozza az első commit Postgresben. Mit kell tennie, hogy megtehesse az első kötelezettséget?
Ez egy érdekes kérdés: "Hol kezdjem?" Általában elég nehéz valamit kezdeni a kernelben. A Postgresben például van egy teendőlista. De valójában ez egy lap arról, amit megpróbáltak megtenni, de nem jártak sikerrel. Ezek bonyolult dolgok. És általában találhatunk az ökoszisztémában néhány segédprogramot, néhány fejleszthető bővítményt, amelyek kevesebb figyelmet vonzanak a kernelfejlesztők részéről. És ennek megfelelően több pont van a növekedéshez. A Google Summer of code programban a postgres közösség minden évben számos különböző témát terjeszt elő, amelyekkel meg lehetne foglalkozni. Ebben az évben, azt hiszem, három diákunk volt. Az egyik még a WAL-G-ben is írt a Yandex számára fontos témákról. A Greenplumban minden egyszerűbb, mint a Postgres közösségben, mert a Greenplum hackerei nagyon jól kezelik a lehívási kéréseket, és azonnal elkezdik az áttekintést. A javítás elküldése a Postgresnek hónapok kérdése, de a Greenplum egy napon belül jön, és meglátja, mit tett. A másik dolog az, hogy a Greenplumnak meg kell oldania a jelenlegi problémákat. A Greenplum-ot nem használják széles körben, így meglehetősen nehéz megtalálni a problémát. És mindenekelőtt természetesen meg kell oldanunk a problémákat.
Forrás: will.com