Mchango wa Yandex kwenye hifadhidata zifuatazo utakaguliwa.
- Bonyeza Nyumba
- Odyssey
- Urejeshaji hadi kiwango cha wakati (WAL-G)
- PostgreSQL (pamoja na loja, Amcheck, chunguzi)
- Greenplum
Video:
Salamu, Dunia! Jina langu ni Andrey Borodin. Na ninachofanya katika Yandex.Cloud ni kuunda hifadhidata wazi za uhusiano kwa maslahi ya wateja wa Yandex.Cloud na Yandex.Cloud.
Katika mazungumzo haya, tutazungumza juu ya changamoto zinazokabili hifadhidata wazi kwa kiwango. Kwa nini ni muhimu? Kwa sababu matatizo madogo madogo ambayo, kama mbu, basi huwa tembo. Zinakua kubwa wakati una vikundi vingi.
Lakini hilo si jambo kuu. Mambo ya ajabu hutokea. Mambo ambayo hutokea katika kesi moja katika milioni. Na katika mazingira ya wingu, lazima uwe tayari kwa hilo, kwa sababu vitu vya kushangaza vinawezekana sana wakati kitu kipo kwa kiwango.
Lakini! Je, ni faida gani ya hifadhidata wazi? Ukweli ni kwamba una fursa ya kinadharia ya kukabiliana na tatizo lolote. Una msimbo wa chanzo, una ujuzi wa programu. Tunachanganya na inafanya kazi.
Je, kuna mbinu gani za kufanya kazi kwenye programu huria?
- Njia ya moja kwa moja ni kutumia programu. Ikiwa unatumia itifaki, ikiwa unatumia viwango, ikiwa unatumia fomati, ukiandika maswali katika programu ya chanzo wazi, basi tayari unaunga mkono.
- Unafanya mfumo wake wa ikolojia kuwa mkubwa zaidi. Unaongeza uwezekano wa kugundua mdudu mapema. Unaongeza kuegemea kwa mfumo huu. Unaongeza upatikanaji wa watengenezaji kwenye soko. Unaboresha programu hii. Tayari wewe ni mchangiaji ikiwa ulifanya tu kupata mtindo na kubatilisha kitu hapo.
- Njia nyingine inayoeleweka ni kufadhili programu huria. Kwa mfano, mpango unaojulikana wa Majira ya Msimbo wa Google, wakati Google hulipa idadi kubwa ya wanafunzi kutoka kote ulimwenguni pesa zinazoeleweka ili watengeneze miradi ya programu iliyo wazi ambayo inakidhi mahitaji fulani ya leseni.
- Hii ni mbinu ya kuvutia sana kwa sababu inaruhusu programu kubadilika bila kuhamisha mwelekeo kutoka kwa jumuiya. Google, kama kampuni kubwa ya teknolojia, haisemi kwamba tunataka kipengele hiki, tunataka kurekebisha hitilafu hii na tunahitaji kuchimba hapo. Google inasema: "Fanya unachofanya. Endelea tu kufanya kazi jinsi umekuwa ukifanya kazi na kila kitu kitakuwa sawa."
- Mbinu inayofuata ya kushiriki katika chanzo huria ni ushiriki. Unapokuwa na tatizo katika programu huria na kuna wasanidi, wasanidi wako huanza kutatua matatizo. Wanaanza kufanya miundombinu yako kuwa bora zaidi, programu zako kwa haraka na za kuaminika zaidi.
Moja ya miradi maarufu ya Yandex katika uwanja wa programu ya chanzo wazi ni ClickHouse. Hii ni hifadhidata ambayo ilizaliwa kama jibu la changamoto zinazoikabili Yandex.Metrica.
Na kama hifadhidata, ilitengenezwa kwa chanzo wazi ili kuunda mfumo wa ikolojia na kuukuza pamoja na watengenezaji wengine (sio tu ndani ya Yandex). Na sasa huu ni mradi mkubwa ambao makampuni mengi tofauti yanahusika.
Katika Yandex.Cloud, tuliunda ClickHouse juu ya Hifadhi ya Kitu cha Yandex, i.e. juu ya uhifadhi wa wingu.
Kwa nini hii ni muhimu katika wingu? Kwa sababu hifadhidata yoyote inafanya kazi katika pembetatu hii, kwenye piramidi hii, katika safu hii ya aina za kumbukumbu. Una rejista za haraka lakini ndogo na SSD kubwa za bei nafuu lakini za polepole, anatoa ngumu na vifaa vingine vya kuzuia. Na ikiwa una ufanisi juu ya piramidi, basi unayo hifadhidata ya haraka. ikiwa unafaa chini ya piramidi hii, basi una hifadhidata iliyokuzwa. Na katika suala hili, kuongeza safu nyingine kutoka chini ni mbinu ya kimantiki ya kuongeza scalability ya database.
Ingewezaje kufanywa? Hili ni jambo muhimu katika ripoti hii.
- Tunaweza kutekeleza ClickHouse juu ya MDS. MDS ni kiolesura cha ndani cha hifadhi ya wingu cha Yandex. Ni ngumu zaidi kuliko itifaki ya kawaida ya S3, lakini inafaa zaidi kwa kifaa cha kuzuia. Ni bora kurekodi data. Inahitaji programu zaidi. Watayarishaji wa programu watapanga, ni nzuri hata, inavutia.
- S3 ni mbinu ya kawaida zaidi ambayo hufanya kiolesura kuwa rahisi kwa gharama ya kukabiliana kidogo na aina fulani za mizigo ya kazi.
Kwa kawaida, kwa kutaka kutoa utendaji kwa mfumo mzima wa ikolojia wa ClickHouse na kufanya kazi inayohitajika ndani ya Yandex.Cloud, tuliamua kuhakikisha kwamba jumuiya nzima ya ClickHouse itafaidika nayo. Tulitekeleza ClickHouse juu ya S3, sio ClickHouse juu ya MDS. Na hii ni kazi nyingi.
Marejeo:
"Safu ya uondoaji wa mfumo wa faili"
"Muunganisho wa AWS SDK S3"
"Utekelezaji wa msingi wa mwingiliano wa IDisk kwa S3"
"Muunganisho wa injini za uhifadhi wa logi na kiolesura cha IDisk"
"Msaada wa injini ya logi kwa S3 na SeekableReadBuffer"
Msaada wa "Hifadhi Stripe Log S3"
Msaada wa awali wa MergeTree kwa S3
"MergeTree msaada kamili kwa S3"
"Support ReplicatedMergeTree juu ya S3"
"Ongeza vitambulisho chaguo-msingi na vichwa maalum kwa hifadhi ya s3"
"S3 iliyo na usanidi wa wakala unaobadilika"
"S3 iliyo na kisuluhishi cha wakala"
Hii ni orodha ya ombi la kuvuta kwa ajili ya kutekeleza mfumo wa faili pepe katika ClickHouse. Hii ni idadi kubwa ya maombi ya kuvuta.
Marejeo:
"DiskS3 inaunganisha utekelezaji bora"
"S3 HTTP mteja - Epuka kunakili mkondo wa majibu kwenye kumbukumbu"
"Epuka kunakili mtiririko mzima wa majibu kwenye kumbukumbu katika S3 HTTP
mteja"
"Uwezo wa kuweka alama na index faili za diski ya S3"
"Hamisha sehemu kutoka DiskLocal hadi DiskS3 sambamba"
Lakini kazi haikuishia hapo. Baada ya kipengele kufanywa, kazi nyingine ilihitajika ili kuboresha utendakazi huu.
Marejeo:
"Ongeza SelectedRows na SelectedBytes matukio"
"Ongeza matukio ya wasifu kutoka kwa ombi la S3 hadi system.events"
"Ongeza QueryTimeMicroseconds, SelectQueryTimeMicroseconds na InsertQueryTimeMicroseconds"
Na kisha ilikuwa ni lazima kuifanya uchunguzi, kuanzisha ufuatiliaji na kuifanya kudhibiti.
Na haya yote yalifanyika ili jumuiya nzima, mfumo mzima wa mazingira wa ClickHouse, upate matokeo ya kazi hii.
Wacha tuendelee kwenye hifadhidata za shughuli, hadi hifadhidata za OLTP, ambazo ziko karibu nami kibinafsi.
Hii ni mgawanyiko wa uendelezaji wa DBMS wa chanzo huria. Vijana hawa wanafanya uchawi wa mitaani ili kuboresha hifadhidata wazi za miamala.
Moja ya miradi, kwa kutumia mfano ambao tunaweza kuzungumza juu ya jinsi na kile tunachofanya, ni Connection Pooler katika Postgres.
Postgres ni hifadhidata ya mchakato. Hii ina maana kwamba hifadhidata inapaswa kuwa na miunganisho machache ya mtandao iwezekanavyo ambayo inashughulikia shughuli.
Kwa upande mwingine, katika mazingira ya wingu, hali ya kawaida ni wakati miunganisho elfu inakuja kwenye nguzo moja mara moja. Na kazi ya pooler ya uunganisho ni kufunga miunganisho elfu kwenye idadi ndogo ya miunganisho ya seva.
Tunaweza kusema kwamba kiboreshaji cha unganisho ni mendeshaji wa simu ambaye hupanga upya byte ili zifikie hifadhidata kwa ufanisi.
Kwa bahati mbaya, hakuna neno zuri la Kirusi kwa mtoaji wa unganisho. Wakati mwingine inaitwa miunganisho ya multiplexer. Ikiwa unajua nini cha kumwita mtoaji wa uunganisho, basi hakikisha kuniambia, nitafurahi sana kuzungumza lugha sahihi ya kiufundi ya Kirusi.
Tulichunguza viunganishi vya kuunganisha ambavyo vinafaa kwa nguzo ya posta inayosimamiwa. Na PgBouncer ilikuwa chaguo bora kwetu. Lakini tulikumbana na shida kadhaa na PgBouncer. Miaka mingi iliyopita, Volodya Borodin alitoa ripoti kwamba tunatumia PgBouncer, tunapenda kila kitu, lakini kuna nuances, kuna kitu cha kufanya kazi.
Na tulifanya kazi. Tulirekebisha matatizo ambayo tulikumbana nayo, tukaweka viraka Kidhibiti, na kujaribu kusukuma maombi ya kuvuta juu ya mkondo. Lakini utiaji uzi mmoja ulikuwa mgumu kufanya kazi nao.
Ilitubidi kukusanya misururu kutoka kwa Wachezaji viraka. Tunapokuwa na Viboreshaji vingi vya nyuzi moja, miunganisho kwenye safu ya juu huhamishiwa kwenye safu ya ndani ya Viboreshaji. Huu ni mfumo usiosimamiwa vizuri ambao ni mgumu kuujenga na kuupunguza huku na huko.
Tulifikia hitimisho kwamba tuliunda pooler yetu ya uunganisho, ambayo inaitwa Odyssey. Tuliandika kutoka mwanzo.
Mnamo 2019, kwenye mkutano wa PgCon, niliwasilisha kiboreshaji hiki kwa jumuiya ya wasanidi programu. Sasa tuna nyota zisizozidi 2 kwenye GitHub, yaani, mradi uko hai, mradi ni maarufu.
Na ikiwa utaunda nguzo ya Postgres katika Yandex.Cloud, basi itakuwa nguzo iliyo na Odyssey iliyojengwa, ambayo imeundwa upya wakati wa kuongeza nguzo nyuma au nje.
Tumejifunza nini kutokana na mradi huu? Kuzindua mradi shindani siku zote ni hatua ya fujo, ni kipimo cha kupindukia tunaposema kwamba kuna matatizo ambayo hayatatuliwi haraka vya kutosha, hayatatuliwi kwa muda ambao ungetufaa. Lakini hii ni kipimo cha ufanisi.
PgBouncer ilianza kukuza haraka.
Na sasa miradi mingine imeonekana. Kwa mfano, pgagroal, ambayo inatengenezwa na watengenezaji wa Red Hat. Wanafuata malengo sawa na kutekeleza mawazo sawa, lakini, bila shaka, na maalum yao wenyewe, ambayo ni karibu na watengenezaji wa pgagroal.
Kesi nyingine ya kufanya kazi na jumuia ya postgres ni kurejesha kwa wakati kwa wakati. Huu ni urejeshaji baada ya kutofaulu, hii ni uokoaji kutoka kwa nakala rudufu.
Kuna chelezo nyingi na zote ni tofauti. Karibu kila muuzaji wa Postgres ana suluhisho lake la chelezo.
Ukichukua mifumo yote ya chelezo, unda matrix ya kipengele na ukokote kibainishi kwa utani kwenye matriki hii, itakuwa sifuri. Hii ina maana gani? Nini ikiwa unachukua faili maalum ya chelezo, basi haiwezi kukusanywa kutoka kwa vipande vya wengine wote. Ni ya kipekee katika utekelezaji wake, ni ya pekee katika kusudi lake, ni ya pekee katika mawazo ambayo yameingizwa ndani yake. Na zote ni maalum.
Tulipokuwa tukishughulikia suala hili, CitusData ilizindua mradi wa WAL-G. Huu ni mfumo wa chelezo ambao ulifanywa kwa jicho kwa mazingira ya wingu. Sasa CitusData tayari ni sehemu ya Microsoft. Na wakati huo, tulipenda sana mawazo ambayo yaliwekwa katika matoleo ya awali ya WAL-G. Na tulianza kuchangia mradi huu.
Sasa kuna watengenezaji wengi katika mradi huu, lakini wachangiaji 10 wakuu wa WAL-G ni pamoja na Yandexoids 6. Tulileta mawazo yetu mengi huko. Na, kwa kweli, tulizitekeleza sisi wenyewe, tulizijaribu wenyewe, tukaziingiza katika uzalishaji wenyewe, tunazitumia sisi wenyewe, sisi wenyewe tunaamua wapi pa kusonga mbele, huku tukiingiliana na jumuiya kubwa ya WAL-G.
Na kwa mtazamo wetu, sasa mfumo huu wa chelezo, pamoja na kuzingatia juhudi zetu, umekuwa bora kwa mazingira ya wingu. Hii ndiyo gharama bora zaidi ya kuhifadhi nakala za Postgres katika wingu.
Ina maana gani? Tulikuwa tukikuza wazo kubwa kabisa: hifadhi rudufu inapaswa kuwa salama, nafuu kufanya kazi na kurejesha haraka iwezekanavyo.
Kwa nini iwe rahisi kufanya kazi? Wakati hakuna kitu kimevunjwa, hupaswi kujua una chelezo. Kila kitu hufanya kazi vizuri, unapoteza CPU kidogo iwezekanavyo, unatumia rasilimali kidogo ya diski yako iwezekanavyo, na unatuma baiti chache kwenye mtandao iwezekanavyo ili usiingiliane na upakiaji wa huduma zako muhimu.
Na wakati kila kitu kinapovunjika, kwa mfano, msimamizi aliacha data, kitu kilikwenda vibaya, na unahitaji haraka kurudi nyuma, unapata nafuu na pesa zote, kwa sababu unataka data yako irudi haraka na intact.
Na tulikuza wazo hili rahisi. Na, inaonekana kwetu, tuliweza kutekeleza.
Lakini sio hivyo tu. Tulitaka jambo moja dogo zaidi. Tulitaka hifadhidata nyingi tofauti. Sio wateja wetu wote wanaotumia Postgres. Watu wengine hutumia MySQL, MongoDB. Katika jumuiya, wasanidi programu wengine wamesaidia FoundationDB. Na orodha hii inakua kila wakati.
Jumuiya inapenda wazo la hifadhidata kuendeshwa katika mazingira yanayodhibitiwa kwenye wingu. Na watengenezaji hudumisha hifadhidata zao, ambazo zinaweza kuchelezwa kwa usawa pamoja na Postgres na mfumo wetu wa chelezo.
Tumejifunza nini kutokana na hadithi hii? Bidhaa zetu, kama kitengo cha ukuzaji, sio mistari ya nambari, sio taarifa, sio faili. Bidhaa zetu sio maombi ya kuvuta. Haya ni mawazo tunayowasilisha kwa jamii. Huu ni utaalam wa kiteknolojia na harakati za teknolojia kuelekea mazingira ya wingu.
Kuna hifadhidata kama Postgres. Ninapenda msingi wa Postgres zaidi. Ninatumia muda mwingi kukuza msingi wa Postgres na jamii.
Lakini hapa ni lazima kusema kwamba Yandex.Cloud ina usakinishaji wa ndani wa hifadhidata zilizosimamiwa. Na ilianza muda mrefu uliopita katika Yandex.Mail. Utaalam ambao sasa umesababisha kusimamia Postgres ulikusanywa wakati barua hiyo ilipotaka kuhamia Postgres.
Barua ina mahitaji sawa na wingu. Inahitaji uweze kufikia ukuaji mkubwa usiotarajiwa wakati wowote katika data yako. Na barua tayari ilikuwa na mzigo na mamia ya mamilioni ya masanduku ya barua ya idadi kubwa ya watumiaji ambao hufanya maombi mengi kila wakati.
Na hii ilikuwa changamoto kubwa kwa timu ambayo ilikuwa ikitengeneza Postgres. Wakati huo, matatizo yoyote tuliyokumbana nayo yaliripotiwa kwa jamii. Na matatizo haya yalisahihishwa, na kusahihishwa na jumuiya katika baadhi ya maeneo hata kwa kiwango cha kulipwa kwa hifadhidata zingine na bora zaidi. Hiyo ni, unaweza kutuma barua kwa mdukuzi wa PgSQL na kupokea jibu ndani ya dakika 40. Usaidizi unaolipwa katika hifadhidata fulani unaweza kufikiria kuwa kuna mambo ya kipaumbele zaidi kuliko mdudu wako.
Sasa usakinishaji wa ndani wa Postgres ni baadhi ya petabytes ya data. Haya ni baadhi ya mamilioni ya maombi kwa sekunde. Haya ni maelfu ya makundi. Ni kwa kiwango kikubwa sana.
Lakini kuna nuance. Haiishi kwenye anatoa za mtandao za dhana, lakini kwenye vifaa rahisi. Na kuna mazingira ya majaribio mahsusi kwa vitu vipya vya kupendeza.
Na wakati fulani katika mazingira ya jaribio tulipokea ujumbe ukionyesha kuwa vibadilishi vya ndani vya faharasa za hifadhidata vilikiukwa.
Tofauti ni aina fulani ya uhusiano ambao tunatarajia kushikilia kila wakati.
Hali mbaya sana kwetu. Inaonyesha kuwa data fulani inaweza kuwa imepotea. Na kupoteza data ni janga kabisa.
Wazo la jumla ambalo tunafuata katika hifadhidata zinazosimamiwa ni kwamba hata kwa juhudi, itakuwa ngumu kupoteza data. Hata ikiwa utawaondoa kwa makusudi, bado utahitaji kupuuza kutokuwepo kwao kwa muda mrefu. Usalama wa data ni dini ambayo tunaifuata kwa bidii.
Na hapa kunatokea hali inayoashiria kwamba kunaweza kuwa na hali ambayo hatuwezi kuwa tayari. Na tulianza kujiandaa kwa hali hii.
Jambo la kwanza tulilofanya ni kuzika magogo kutoka kwa maelfu ya vikundi hivi. Tulipata ni nguzo zipi zilizowekwa kwenye diski zilizo na programu dhibiti yenye matatizo ambayo yalikuwa yakipoteza masasisho ya ukurasa wa data. Imeweka alama nambari zote za data za Postgres. Na tulitia alama kwenye jumbe zinazoonyesha ukiukaji wa vibadilishi vya ndani kwa kutumia msimbo ambao umeundwa kutambua upotovu wa data.
Kipande hiki kilikubaliwa kivitendo na jamii bila mjadala mwingi, kwa sababu katika kila hali mahususi ilikuwa dhahiri kuwa kuna jambo baya limetokea na lilihitaji kuripotiwa kwa gogo.
Baada ya hayo, tulifikia hatua ya kuwa tuna ufuatiliaji unaochunguza kumbukumbu. Na ikiwa kuna ujumbe wa kutiliwa shaka, anamwamsha afisa wa zamu, na afisa wa zamu anaitengeneza.
Lakini! Kuchanganua kumbukumbu ni operesheni ya bei nafuu kwenye nguzo moja na ni ghali sana kwa makundi elfu moja.
Tuliandika ugani unaoitwa . Inaunda mtazamo wa hifadhidata ambayo unaweza kuchagua kwa bei nafuu na haraka takwimu za makosa ya zamani. Na ikiwa tunahitaji kuamsha afisa wa wajibu, basi tutajua kuhusu hili bila skanning faili za gigabyte, lakini kwa kutoa byte chache kutoka kwa meza ya hashi.
Ugani huu umepitishwa, kwa mfano, katika ghala la . Ikiwa unataka kuitumia, unaweza kuiweka mwenyewe. Bila shaka ni chanzo wazi.
Lakini sio hivyo tu. Tulianza kutumia Amcheck, kiendelezi kilichojengwa na jumuiya, ili kupata ukiukaji usiobadilika katika faharasa.
Na tuligundua kuwa ikiwa utaiendesha kwa kiwango, kuna mende. Tulianza kuzirekebisha. Marekebisho yetu yamekubaliwa.
Tuligundua kuwa kiendelezi hiki hakiwezi kuchanganua faharasa za GiST na GIT. Tuliwaunga mkono. Lakini usaidizi huu bado unajadiliwa na jumuiya, kwa sababu huu ni utendaji mpya na kuna maelezo mengi huko.
Na pia tuligundua kwamba wakati wa kuangalia indexes kwa ukiukwaji juu ya kiongozi wa replication, kwa bwana, kila kitu kinafanya kazi vizuri, lakini kwenye replicas, kwa mfuasi, utafutaji wa rushwa sio ufanisi sana. Sio tofauti zote zimeangaliwa. Na mtu mmoja asiyebadilika alitusumbua sana. Na tulitumia mwaka mmoja na nusu kuwasiliana na jumuiya ili kuwezesha ukaguzi huu kwenye nakala.
Tuliandika msimbo ambao unapaswa kufuata wote wanaweza... itifaki. Tulijadili kiraka hiki kwa muda mrefu na Peter Gaghan kutoka Crunchy Data. Ilibidi abadilishe kidogo mti wa B uliopo huko Postgres ili kukubali kiraka hiki. Alikubaliwa. Na sasa kuangalia faharasa kwenye nakala pia kumekuwa na ufanisi wa kutosha kugundua ukiukaji ambao tulikumbana nao. Hiyo ni, haya ni ukiukwaji ambao unaweza kusababishwa na makosa katika firmware ya disk, mende katika Postgres, mende katika kernel ya Linux, na matatizo ya vifaa. Orodha kamili ya vyanzo vya shida ambavyo tulikuwa tukitayarisha.
Lakini kando na faharisi, kuna sehemu kama lundo, i.e. mahali ambapo data imehifadhiwa. Na hakuna tofauti nyingi ambazo zinaweza kuangaliwa.
Tuna kiendelezi kinachoitwa Heapcheck. Tulianza kuiendeleza. Na kwa sambamba, pamoja na sisi, kampuni ya EnterpriseDB pia ilianza kuandika moduli, ambayo waliiita Heapcheck kwa njia sawa. Ni sisi tu tuliiita PgHeapcheck, na waliiita Heapcheck. Wanayo na kazi zinazofanana, saini tofauti kidogo, lakini yenye mawazo sawa. Walizitekeleza vyema kidogo katika baadhi ya maeneo. Na waliichapisha kwenye chanzo wazi hapo awali.
Na sasa tunaendeleza upanuzi wao, kwa sababu sio upanuzi wao tena, lakini upanuzi wa jumuiya. Na katika siku zijazo, hii ni sehemu ya kernel ambayo itatolewa kwa kila mtu ili waweze kujua kuhusu matatizo ya baadaye mapema.
Katika baadhi ya maeneo, tulifikia hitimisho kwamba tuna mambo chanya ya uwongo katika mifumo yetu ya ufuatiliaji. Kwa mfano, mfumo wa 1C. Wakati wa kutumia hifadhidata, Postgres wakati mwingine huandika data ndani yake ambayo inaweza kusoma, lakini pg_dump haiwezi kusoma.
Hali hii ilionekana kama ufisadi kwa mfumo wetu wa kutambua matatizo. Afisa wa zamu aliamshwa. Afisa wa zamu aliangalia kinachoendelea. Baada ya muda, mteja alikuja na kusema kwamba nilikuwa na matatizo. Mhudumu alieleza tatizo ni nini. Lakini shida iko kwenye msingi wa Postgres.
Nilipata mjadala kuhusu kipengele hiki. Na aliandika kwamba tulikutana na kipengele hiki na haikuwa ya kupendeza, mtu aliamka usiku ili kujua ni nini.
Jumuiya ilijibu, "Loo, tunahitaji kurekebisha."
Nina mlinganisho rahisi. Ikiwa unatembea katika kiatu kilicho na mchanga ndani yake, basi, kwa kanuni, unaweza kuendelea - hakuna shida. Ikiwa unauza buti kwa maelfu ya watu, basi hebu tufanye buti bila mchanga kabisa. Na ikiwa mmoja wa watumiaji wa viatu vyako atakimbia marathon, basi unataka kutengeneza viatu vizuri sana, na kisha uvipime kwa watumiaji wako wote. Na watumiaji vile zisizotarajiwa ni daima katika mazingira ya wingu. Kuna watumiaji ambao wanatumia kundi kwa njia fulani asili. Lazima kila wakati kujiandaa kwa hili.
Tumejifunza nini hapa? Tulijifunza jambo rahisi: jambo muhimu zaidi ni kueleza jamii kwamba kuna tatizo. Ikiwa jamii imetambua tatizo, basi ushindani wa asili hutokea kutatua tatizo. Kwa sababu kila mtu anataka kutatua tatizo muhimu. Wachuuzi wote, watapeli wote wanaelewa kuwa wao wenyewe wanaweza kuingia kwenye tafuta hii, kwa hivyo wanataka kuwaondoa.
Ikiwa unafanya kazi kwenye tatizo, lakini haisumbui mtu yeyote isipokuwa wewe, lakini unafanya kazi kwa utaratibu na hatimaye inachukuliwa kuwa tatizo, basi ombi lako la kuvuta hakika litakubaliwa. Kiraka chako kitakubaliwa, maboresho yako au hata maombi ya uboreshaji yatakaguliwa na jumuiya. Mwisho wa siku, tunafanya hifadhidata kuwa bora kwa kila mmoja.
Hifadhidata ya kuvutia ni Greenplum. Ni hifadhidata inayolingana sana kulingana na nambari ya postgres, ambayo ninaifahamu sana.
Na Greenplum ina utendaji wa kuvutia - ongeza meza zilizoboreshwa. Hizi ni meza ambazo unaweza kuongeza haraka. Wanaweza kuwa safu au safu.
Lakini hakukuwa na nguzo, i.e. hakukuwa na utendakazi ambapo unaweza kupanga data iliyo kwenye jedwali kulingana na mpangilio ambao uko katika moja ya faharisi.
Vijana kutoka kwenye teksi walikuja kwangu na kusema: "Andrey, unamjua Postgres. Na hapa ni karibu sawa. Badili hadi dakika 20. Wewe ichukue na uifanye.β Nilidhani kuwa ndio, najua Postgres, nikibadilisha kwa dakika 20 - ninahitaji kufanya hivi.
Lakini hapana, haikuwa dakika 20, niliiandika kwa miezi kadhaa. Katika mkutano wa PgConf.Russia, nilimwendea Heikki Linakangas kutoka Pivotal na kumuuliza: βJe, kuna matatizo yoyote katika hili? Kwa nini hakuna mkusanyiko wa jedwali ulioboreshwa wa kuongeza?" Anasema: "Unachukua data. Unapanga, unapanga upya. Ni kazi tu." Mimi: "Oh, ndio, unahitaji tu kuichukua na kuifanya." Anasema: "Ndio, tunahitaji mikono huru kufanya hivi." Nilidhani kwamba hakika ninahitaji kufanya hivi.
Na miezi michache baadaye niliwasilisha ombi la kuvuta ambalo lilitekeleza utendakazi huu. Ombi hili la kuvuta lilikaguliwa na Pivotal pamoja na jumuiya. Bila shaka, kulikuwa na mende.
Lakini jambo la kuvutia zaidi ni kwamba wakati ombi hili la kuvuta liliunganishwa, mende zilipatikana katika Greenplum yenyewe. Tumegundua kuwa majedwali ya lundo wakati mwingine huvunja muamala yanapounganishwa. Na hili ni jambo linalohitaji kurekebishwa. Na yuko mahali nilipogusa tu. Na majibu yangu ya asili yalikuwa - sawa, wacha nifanye hivi pia.
Nilirekebisha hitilafu hii. Ilituma ombi la kuvuta kwa virekebishaji. Aliuawa.
Baada ya hapo ikawa kwamba utendaji huu unahitaji kupatikana katika toleo la Greenplum kwa PostgreSQL 12. Hiyo ni, adventure ya dakika 20 inaendelea na matukio mapya ya kuvutia. Ilikuwa ya kuvutia kugusa maendeleo ya sasa, ambapo jumuiya inapunguza vipengele vipya na muhimu zaidi. Imeganda.
Lakini haikuishia hapo. Baada ya kila kitu, ikawa kwamba tulihitaji kuandika nyaraka kwa haya yote.
Nilianza kuandika nyaraka. Kwa bahati nzuri, waigizaji wa maandishi kutoka Pivotal walikuja. Kiingereza ni lugha yao ya asili. Walinisaidia na nyaraka. Kwa kweli, wao wenyewe waliandika upya kile nilichopendekeza katika Kiingereza halisi.
Na hapa, ingeonekana, adha hiyo iliisha. Na unajua nini kilifanyika basi? Vijana kutoka kwenye teksi walinijia na kusema: "Bado kuna matukio mawili, kila moja kwa dakika 10." Na niwaambie nini? Nilisema kwamba sasa nitatoa ripoti kwa kiwango, basi tutaona adventures yako, kwa sababu hii ni kazi ya kuvutia.
Tumejifunza nini kutokana na kesi hii? Kwa sababu kufanya kazi na chanzo huria daima kunafanya kazi na mtu mahususi, ni kufanya kazi na jumuiya kila wakati. Kwa sababu katika kila hatua nilifanya kazi na msanidi fulani, mjaribu fulani, mdukuzi fulani, mwandishi fulani wa maandishi, mbunifu fulani. Sikufanya kazi na Greenplum, nilifanya kazi na watu karibu na Greenplum.
Lakini! Kuna jambo lingine muhimu - ni kazi tu. Hiyo ni, unakuja, kunywa kahawa, kuandika kanuni. Kila aina ya tofauti rahisi hufanya kazi. Fanya kwa kawaida - itakuwa sawa! Na ni kazi ya kuvutia sana. Kuna ombi la kazi hii kutoka kwa wateja wa Yandex.Cloud, watumiaji wa vikundi vyetu ndani na nje ya Yandex. Na nadhani idadi ya miradi tunayoshiriki itaongezeka na kina cha ushiriki wetu pia kitaongezeka.
Ni hayo tu. Tuendelee na maswali.
Kipindi cha maswali
Habari! Tuna kipindi kingine cha maswali na majibu. Na katika studio Andrei Borodin. Huyu ndiye mtu ambaye amekuambia tu juu ya mchango wa Yandex.Cloud na Yandex kufungua chanzo. Ripoti yetu sasa haihusu Wingu kabisa, lakini wakati huo huo tunategemea teknolojia kama hizo. Bila yale uliyofanya ndani ya Yandex, hakutakuwa na huduma katika Yandex.Cloud, kwa hiyo asante kutoka kwangu binafsi. Na swali la kwanza kutoka kwa matangazo: "Ni nini kila moja ya miradi uliyotaja imeandikwa?"
Mfumo wa chelezo katika WAL-G umeandikwa katika Go. Huu ni mojawapo ya miradi mipya zaidi ambayo tumeifanyia kazi. Ana umri wa miaka 3 tu. Na hifadhidata mara nyingi ni juu ya kuegemea. Na hii ina maana kwamba hifadhidata ni za zamani kabisa na kwa kawaida huandikwa katika C. Mradi wa Postgres ulianza takriban miaka 30 iliyopita. Kisha C89 ilikuwa chaguo sahihi. Na Postgres imeandikwa juu yake. Hifadhidata za kisasa zaidi kama vile ClickHouse kawaida huandikwa katika C++. Maendeleo yote ya mfumo yanategemea C na C++.
Swali kutoka kwa msimamizi wetu wa fedha, ambaye anawajibika kwa gharama katika Cloud: "Kwa nini Cloud hutumia pesa kusaidia chanzo huria?"
Kuna jibu rahisi kwa msimamizi wa fedha hapa. Tunafanya hivi ili kuboresha huduma zetu. Ni kwa njia zipi tunaweza kufanya vyema zaidi? Tunaweza kufanya mambo kwa ufanisi zaidi, kwa haraka zaidi, na kufanya mambo yawe mepesi zaidi. Lakini kwa ajili yetu, hadithi hii ni hasa kuhusu kuaminika. Kwa mfano, katika mfumo wa chelezo tunakagua 100% ya viraka vinavyotumika kwake. Tunajua kanuni ni nini. Na tunafurahi zaidi kusambaza matoleo mapya kwa uzalishaji. Hiyo ni, kwanza kabisa, ni juu ya kujiamini, juu ya utayari wa maendeleo na juu ya kuegemea
Swali lingine: "Je, mahitaji ya watumiaji wa nje wanaoishi katika Yandex.Cloud ni tofauti na watumiaji wa ndani wanaoishi katika Wingu la ndani?"
Wasifu wa mzigo ni, bila shaka, tofauti. Lakini kutoka kwa mtazamo wa idara yangu, kesi zote maalum na za kuvutia zinaundwa kwa mzigo usio wa kawaida. Watengenezaji wenye mawazo, watengenezaji wanaofanya yasiyotarajiwa, wana uwezekano wa kupatikana ndani na nje. Katika suala hili, sisi sote ni takriban sawa. Na, pengine, kipengele muhimu tu ndani ya uendeshaji wa database ya Yandex itakuwa kwamba ndani ya Yandex tuna mafundisho. Kwa wakati fulani, eneo fulani la upatikanaji linaingia kabisa kwenye kivuli, na huduma zote za Yandex lazima kwa namna fulani ziendelee kufanya kazi licha ya hili. Hii ni tofauti ndogo. Lakini inaunda maendeleo mengi ya utafiti kwenye kiolesura cha hifadhidata na stack ya mtandao. Vinginevyo, usakinishaji wa nje na wa ndani hutoa maombi sawa ya vipengele na maombi sawa ya kuboresha kutegemewa na utendaji.
Swali linalofuata: "Je, wewe binafsi unahisije kuhusu ukweli kwamba mengi ya kile unachofanya kinatumiwa na Clouds nyingine?" Hatutataja maalum, lakini miradi mingi iliyofanywa katika Yandex.Cloud hutumiwa kwenye mawingu ya watu wengine.
Hii ni poa. Kwanza, ni ishara kwamba tumefanya jambo sahihi. Na inakuna ego. Na tuna uhakika zaidi kwamba tulifanya uamuzi sahihi. Kwa upande mwingine, hii ni matumaini kwamba katika siku zijazo hii itatuletea mawazo mapya, maombi mapya kutoka kwa watumiaji wa tatu. Masuala mengi kwenye GitHub yanaundwa na wasimamizi wa mfumo wa mtu binafsi, DBA binafsi, wasanifu binafsi, wahandisi binafsi, lakini wakati mwingine watu wenye uzoefu wa utaratibu huja na kusema kwamba katika 30% ya kesi fulani tuna tatizo hili na hebu tufikirie jinsi ya kutatua. Hili ndilo tunalotazamia zaidi. Tunatazamia kushiriki uzoefu na mifumo mingine ya wingu.
Umezungumza mengi kuhusu marathon. Ninajua kuwa ulikimbia marathon huko Moscow. Matokeo yake? Ulipata watu kutoka PostgreSQL?
Hapana, Oleg Bartunov anaendesha haraka sana. Alimaliza saa moja mbele yangu. Kwa ujumla, nina furaha na jinsi nilivyofikia. Kwangu mimi, kumaliza tu ilikuwa mafanikio. Kwa ujumla, inashangaza kwamba kuna wakimbiaji wengi katika jumuiya ya postgres. Inaonekana kwangu kuwa kuna aina fulani ya uhusiano kati ya michezo ya aerobic na hamu ya upangaji wa mifumo.
Je, unasema hakuna wakimbiaji katika ClickHouse?
Ninajua kwa hakika kwamba wapo. ClickHouse pia ni hifadhidata. Kwa njia, Oleg sasa ananiandikia: "Je, tutakimbia baada ya ripoti?" Hili ni wazo zuri.
Swali lingine kutoka kwa matangazo kutoka kwa Nikita: "Kwa nini ulirekebisha mdudu huko Greenplum mwenyewe na usiwape vijana?" Kweli, haijulikani sana ni mdudu gani na katika huduma gani, lakini labda inamaanisha yule uliyezungumza.
Ndio, kwa kanuni, inaweza kutolewa kwa mtu. Ilikuwa tu kanuni kwamba mimi tu iliyopita. Na ilikuwa kawaida kuendelea kuifanya mara moja. Kimsingi, wazo la kushiriki utaalamu na timu ni wazo zuri. Kwa hakika tutashiriki kazi za Greenplum miongoni mwa wanachama wote wa kitengo chetu.
Kwa kuwa tunazungumza juu ya vijana, hapa kuna swali. Mtu huyo aliamua kuunda ahadi ya kwanza katika Postgres. Anahitaji kufanya nini ili kufanya ahadi ya kwanza?
Hili ni swali la kuvutia: "Wapi kuanza?" Kawaida ni ngumu sana kuanza na kitu kwenye kernel. Katika Postgres, kwa mfano, kuna orodha ya kufanya. Lakini kwa kweli, hii ni karatasi ya kile walijaribu kufanya, lakini hawakufanikiwa. Haya ni mambo magumu. Na kwa kawaida unaweza kupata baadhi ya huduma katika mfumo wa ikolojia, baadhi ya viendelezi vinavyoweza kuboreshwa, ambavyo vinavutia umakini mdogo kutoka kwa watengenezaji wa kernel. Na, ipasavyo, kuna pointi zaidi za ukuaji huko. Katika msimu wa joto wa Google wa programu ya msimbo, kila mwaka jumuiya ya postgres huweka mbele mada nyingi tofauti ambazo zinaweza kushughulikiwa. Mwaka huu tulikuwa, nadhani, wanafunzi watatu. Mmoja hata aliandika katika WAL-G juu ya mada ambayo ni muhimu kwa Yandex. Katika Greenplum, kila kitu ni rahisi zaidi kuliko katika jumuiya ya Postgres, kwa sababu wavamizi wa Greenplum hushughulikia maombi ya kuvuta vizuri na kuanza kukagua mara moja. Kutuma kiraka kwa Postgres ni suala la miezi, lakini Greenplum itakuja kwa siku moja na kuona kile umefanya. Jambo jingine ni kwamba Greenplum inahitaji kutatua matatizo ya sasa. Greenplum haitumiwi sana, kwa hivyo kupata shida yako ni ngumu sana. Na kwanza kabisa, tunahitaji kutatua matatizo, bila shaka.
Chanzo: mapenzi.com