Kupanua uwezo wa Git katika OpenAI

Katika mwaka uliopita, ukubwa wa uhifadhi wetu wa pamoja wa msimbo na mahitaji yake yameongezeka kwa kasi ya kushangaza. Ilikuwa wazi kuwa tulihitaji kurekebisha mfumo wetu wa udhibiti wa msimbo chanzo ili uweze kushughulikia kiwango cha kazi za wakati mmoja ambacho Codex inawezesha.

Tuliunda Pando, mfumo mpya wa upande wa seva kwa hifadhi za Git, bila kukatiza kazi yoyote ya uhandisi au kubadilisha jinsi timu yetu inavyotumia Git. Sasa Pando huendesha kazi zote za uundaji wa programu katika uhifadhi wa pamoja wa msimbo wa OpenAI. Pando imeundwa kutimiza malengo mawili makubwa: kwanza, uwezo wa kuandika unaopanuka kwa kuongeza seva, ulioboreshwa kwa utumaji wa wakati mmoja kwenye matawi mengi. Pili, kuongeza utendaji wa usomaji kadiri iwezekanavyo, ili programu za mteja zipakue data kwa kasi inayotumia kikamilifu kipimo data cha mtandao walicho nacho.

Tulitimiza malengo haya huku tukidumisha uoanifu na itifaki na programu mteja ya Git, hivyo kuwezesha wahandisi na mawakala wetu kuingiza Pando kwa urahisi katika taratibu zao zilizopo. Katika matumizi halisi, Pando ilipunguza thamani ya kati ya muda wa utumaji hadi karibu moja ya tano. Sasa inasambaza karibu petabaiti moja ya data ya Git kwa siku.

Hapa, tutaeleza kilichotuchochea kuunda mfumo mpya wa udhibiti wa msimbo chanzo, pamoja na sababu za kuchagua kudumisha uoanifu na Git. Tutalinganisha mfumo wetu na mbinu za kawaida za kupanua Git, tukieleza kinachoifanya Pando iwe na uwezo wa kipekee wa kutimiza mahitaji ya upanuzi ya OpenAI. Pia tunajadili hatua zinazofuata na jinsi tutakavyoendelea kuchangia Git ili iweze kushughulikia kazi kwa kiwango cha mawakala.

Codex imebadilisha kiwango na kasi ya uundaji wa programu katika OpenAI, ikiwezesha wahandisi kufanya kazi nyingi zaidi sambamba. Hii inamaanisha matawi, utumaji na uunganishaji zaidi, pamoja na upakuaji na uundaji zaidi wa nakala kutoka mazingira ya uundaji, kazi za utafiti na CI.

Mahitaji haya huongezana. Sasa mhandisi mmoja huwa na mabadiliko kadhaa yaliyo tayari kwa CI kwa wakati mmoja, na kila utumaji unaweza kuanzisha kazi kadhaa zinazopakua commit ileile.

Kuanzia karibu mwishoni mwa mwaka jana, mifumo inayohudumia uhifadhi wetu wa pamoja wa msimbo ilianza kushindwa kuendana na mahitaji. Tulikumbana na upakuaji na utumaji wa polepole pamoja na uunganishaji ulioshindikana, huku kutegemeka wakati mwingine kukishuka chini ya 90%. Je, tulikuwa tumefikia kikomo cha Git yenyewe, au cha jinsi tulivyohudumia uhifadhi wetu wa pamoja wa msimbo? Git ilitokana na jumuiya iliyobadilishana viraka vya kerneli kupitia barua pepe. Kwa zaidi ya miongo miwili, wasanidi programu wamebadilisha zana zao kulingana na Git kadiri njia zao za kuunda programu zilivyobadilika. Tulipoanza kukumbana na vikwazo katika uhifadhi wetu wa pamoja wa msimbo, ilikuwa muhimu kwetu kuendelea kujenga juu ya kazi hiyo.

Tuliona njia ya kudumisha utaratibu huo tuliozoea huku tukiunda upya mfumo wa upande wa seva ili ushughulikie utumaji kwenye matawi tofauti sambamba na kuhudumia wasomaji wengi kwa historia ileile kwa wakati mmoja. Kutumia Git kama msingi wa utaratibu wetu wa udhibiti wa msimbo chanzo kulimaanisha kuwa maboresho ya programu mteja yangeweza kunufaisha wengine nje ya OpenAI. Tulitaka kuchangia maboresho hayo kutoka nakala yetu ya Git⁠(fungua katika dirisha jipya) kwenye mradi mkuu, ili kuyashirikisha jumuiya pana.

Kupanua mfumo wa udhibiti wa msimbo chanzo kuna vipengele viwili muhimu: waandishi wengi wanaotuma kwenye matawi tofauti, na wasomaji wengi wanaopakua historia ileile. Pando imeboreshwa kwa vyote viwili.

Kwanza, Pando huratibu masasisho ya kila tawi kwa kujitegemea. Masasisho ya matawi yasiyohusiana yanaweza kuendelea sambamba, na msomaji anayepakua tawi hupata historia inayohitajika kwa toleo hilo. Hasara yake ni kwamba msomaji anayetazama matawi kadhaa anaweza kuona hali zake za nyakati tofauti.

Pili, Pando hutumia tena faili za vifurushi (umbizo la Git la kubana vipengee vingi pamoja) katika upakuaji tofauti badala ya kutengeneza faili tofauti kwa kila programu mteja. Programu mteja inaweza kupakua baadhi ya vipengee ambavyo tayari inavyo, lakini seva inaweza kutuma baiti zilezile kwa programu nyingi za mteja kwa ukokotoaji mdogo.

Chaguo hizi hutuwezesha kuongeza uwezo wa kuandika katika matawi mbalimbali na kuhudumia usomaji kutoka hifadhi za muda. Ili kuona jinsi zinavyofanya kazi pamoja, tuanze na jinsi Git inavyohifadhi na kuhamisha historia.

Git lazima iweze kusawazisha sehemu mbili za uhifadhi: vipengee na marejeleo.

Uhifadhi wa Git hurekodi hali za faili na historia inayozihusisha kama grafu ya vipengee. Kipengee kinaweza kuwa blob, mti, commit au lebo. Blob huhifadhi maudhui ya faili moja, na miti huhusisha majina na blob au miti mingine ili kuunda muundo wa saraka. Commit huelekeza kwenye mti wa mzizi na commit mzazi sifuri au zaidi, na hivyo kuunda historia ya uhifadhi wako.

Vipengee hutambuliwa kwa hashi ya aina na maudhui yake. Vipengee pia haviwezi kubadilishwa: kurekodi faili iliyobadilika huunda blob mpya, huku faili na saraka ambazo hazijabadilika zikiweza kutumia tena vipengee vilivyopo.

Matawi na lebo ni marejeleo, au “refs”, yanayoelekeza kwenye commit. Kurekodi mabadiliko kwenye tawi huunda commit mpya na kusasisha rejeleo la tawi ili lielekeze kwenye commit hiyo.

Git huhifadhi vipengee vikiwa “vya pekee” au “vilivyofungashwa”. Vipengee vya pekee huhifadhiwa katika faili tofauti zinazotambuliwa kwa kitambulisho cha kila kipengee. Vipengee vilivyofungashwa huhifadhiwa pamoja katika faili ya kifurushi, hivyo kuwezesha vipengee vinavyofanana kuhifadhiwa kama tofauti kati yake.

Katika Git, kipengee kinafikika kutoka commit ikiwa Git inaweza kukipata kwa kufuata viungo kutoka commit hiyo kupitia commit wazazi wake, miti na blob. Wakati wa upakuaji, programu mteja huiambia seva ni commit zipi inazohitaji na zipi tayari inazo. Seva hutafuta vipengee vinavyofikika kutoka commit zinazohitajika, huacha vile ambavyo inajua programu mteja tayari inavyo, na hutuma vilivyobaki kama faili ya kifurushi katika umbizo lilelile ambalo Git hutumia kwenye diski. Uundaji wa nakala kamili huanza bila vipengee vyovyote, hivyo huhitaji vipengee vyote vinavyofikika kutoka historia inayonakiliwa.

Utumaji huhamisha vipengee upande wa pili kwa kuomba seva isasishe rejeleo moja au zaidi. Programu mteja hutumia seti ya marejeleo yaliyotangazwa na seva ili kuepuka kutuma vipengee ambavyo seva tayari inavyo. Kwa hiyo, kifurushi kinachotumwa kinaweza kutegemea vipengee vilivyopo: kupokea kifurushi pekee hakutoshi kuunda upya historia mpya.

Kunakilisha uhifadhi wa Git kunamaanisha kudumisha upatikanaji wa vipengee na marejeleo katika seva nyingi. Kabla ya seva yenye nakala kutoa thamani mpya ya rejeleo, lazima iweze kutoa vipengee vinavyofikika kutoka thamani hiyo. Huduma pia inahitaji kuratibu masasisho ya marejeleo yanayoshindana, yaani, utumaji unaojaribu kuhamisha tawi lilelile kutoka ncha ileile ya zamani hadi commit mpya tofauti. Mifumo inayolazimisha mfuatano mmoja kwa uandishi wote kwenye uhifadhi inaweza kufanya utumaji kwenye matawi yasiyohusiana usubiriane.

Tulipokuwa tukibuni Pando, tulitathmini mbinu za kawaida za kupanua udhibiti wa msimbo chanzo kwa kutumia Git: moja inayoratibu masasisho ya marejeleo katika nakala za uhifadhi kwa uthibitishaji wa awamu tatu (3PC, itifaki ya kuratibu uthibitishaji katika nodi nyingi), na nyingine inayopanga masasisho kupitia kumbukumbu ya pamoja ya kabla ya kuandika (WAL, rekodi ya mabadiliko inayoandikwa kabla ya kutekelezwa) katika hifadhi ya blob.

Katika muundo wa uthibitishaji wa awamu tatu tulioiga, huduma ya Git hudumisha nakala kamili ya uhifadhi kwenye seva kadhaa za nakala. Seva yoyote inapopokea utumaji, faili ya kifurushi inayoingia hunakiliwa na kutumwa sambamba kwa seva zote za nakala. Ili kuchapisha mabadiliko yaliyotumwa, seva nyingi kati ya hizo lazima zikubali sasisho la rejeleo. Seva inayosimamia hili ndiyo mratibu, na mchakato unahitaji raundi nyingi za mawasiliano kati ya mratibu na kila seva nyingine ya nakala.

Ili kukubali sasisho la rejeleo, kila seva ya nakala hufunga nakala yake ya rejeleo na kukagua kuwa bado inaelekeza kwenye commit inayotarajiwa na programu mteja. Kisha mratibu hutuma ujumbe wa kabla ya uthibitishaji kwa seva za nakala zinazokubali. Seva nyingi zinapokiri kupokea ujumbe huo, mratibu huziagiza zitekeleze sasisho. Seva yoyote ya nakala iliyosasishwa inaweza kisha kutangaza ncha mpya ya tawi kutoka nakala yake ya ndani ya uhifadhi.

Kudumisha nakala kamili huwezesha kuhudumia usomaji kutoka data ya ndani, na huhakikisha kuwa programu za mteja zinapata mwonekano thabiti wa marejeleo yote bila kujali seva ya nakala wanayochagua. Kwa hiyo, marejeleo husasishwa moja baada ya jingine, na kila utumaji huhitaji mizunguko kadhaa ya mawasiliano ili kuratibu sasisho la rejeleo kati ya seva za nakala.

Kusubiri akidi hufanya muda wa utumaji utegemee utendaji wa diski za seva za nakala na ucheleweshaji wa mawasiliano. Kiasi cha uandishi kinapoongezeka, seva za nakala lazima ziendane na kasi ya vifurushi vinavyoingia pamoja na maombi ya usomaji.

Katika muundo unaotegemea WAL tulioiga, huduma ya Git hutumia hati ya pamoja ya maelezo katika hifadhi ya blob kupanga masasisho katika uhifadhi mzima. Seva inapopokea utumaji, hupakia faili ya kifurushi inayoingia kwenye hifadhi ya blob na kuandaa sasisho la rejeleo katika nakala yake ya ndani ya uhifadhi. Ili kuchapisha mabadiliko yaliyotumwa, huongeza ingizo kwenye hati ya pamoja ya maelezo iliyohifadhiwa katika hifadhi ya blob, ambalo hurekodi sasisho la rejeleo na kuelekeza kwenye faili ya kifurushi. Seva ya Git kisha husasisha hati ya maelezo kwa operesheni ya kulinganisha na kubadilisha. Hii hubadilisha hati ya maelezo kama hatua moja isiyogawanyika, au hukataa mabadiliko. Ikiwa mwandishi mwingine ameisasisha wakati huo, seva husoma maingizo yaliyoongezwa, hukagua kuwa sasisho lake la rejeleo bado ni halali, kisha hujaribu tena kwa kutumia faili ya kifurushi ambayo tayari imepakia.

Waandishi wanaweza kupakia faili zao za vifurushi sambamba, lakini hata utumaji kwenye matawi yasiyohusiana huhitaji kusasisha hati ileile ya maelezo. Muda wa mzunguko wa mawasiliano wa operesheni iliyofanikiwa ya kulinganisha na kubadilisha huweka kikomo cha mara ambazo uhifadhi unaweza kuchapisha hati mpya ya maelezo. Hifadhi ya blob yenye ucheleweshaji mdogo huharakisha hatua hii. Kukusanya masasisho katika mafungu huruhusu hati moja ya maelezo kusasisha marejeleo kadhaa kwa wakati mmoja, lakini huhitaji kuyapanga masasisho kwenye foleni na kuongeza muda wa kusubiri.

Hifadhi ya blob inaweza kupokea faili za vifurushi sambamba, lakini masasisho ya hati ya pamoja ya maelezo bado hushindana. Kuongeza uwezo wa hifadhi ya blob pekee hakuondoi kikwazo hicho. Kila seva ya nakala bado inahitaji kusoma vifurushi kutoka hifadhi ya blob na kuviwekea faharasa kabla ya kuvitoa kutoka data yake ya ndani. Kasi ya uandishi unaoingia ikizidi kasi ya kazi hiyo, seva za nakala hubaki nyuma na programu za mteja husubiri muda mrefu zaidi kupakua commit mpya zilizotumwa.

Hapo ndipo Pando inapoingia. Pando ni usanifu mpya wa kuhudumia hifadhi za Git, wenye lengo la kupanua uwezo wa kushughulikia programu nyingi za mteja zinazotuma kwa wakati mmoja. Hivi ndivyo inavyofanya kazi:

Kabla ya kuunda Pando, tulihisi kuwa tungeweza kutimiza mahitaji yetu bila kuacha Git, lakini tulihitaji kulegeza baadhi ya masharti ambayo mifumo mingi ya Git huchukulia kuwa ya lazima:

• Uthabiti katika hifadhi nzima: Kutoa taswira thabiti ya marejeleo yote inayoakisi hali ya wakati mmoja kunahitaji uratibu katika hifadhi nzima. Katika mfumo unaopanga masasisho yote ya marejeleo katika mfuatano mmoja, utumaji wa mabadiliko kwenye matawi yasiyohusiana hushindania sehemu moja ya uratibu.

• Faili tofauti za vifurushi kwa kila programu mteja: Programu mbili za mteja zenye historia tofauti za ndani zinapopakua tawi moja, huenda seva ikahitaji kutengeneza kifurushi tofauti kwa kila programu ili kuepuka kutuma vipengee ambavyo tayari zinavyo. Kutengeneza majibu haya hutumia CPU na shughuli za kusoma na kuandika kwenye diski, hivyo kufanya iwe vigumu kuhudumia wasomaji wengi.

Badala yake, Pando hutumia modeli ya uthabiti usio mkali (uthabiti wa kisababishi) ili kupanua uwezo wa kushughulikia shughuli za uandishi, na hutumia tena faili za vifurushi ili kupanua uwezo wa kushughulikia shughuli za usomaji.

Programu mteja inapotuma mabadiliko kwenye tawi, Pando huhifadhi faili ya kifurushi inayoingia kama blob isiyoweza kubadilishwa katika hifadhi ya blob. Kila tawi linaposonga mbele, Pando hurekodi toleo la rejeleo katika hifadhi ya metadata. Toleo hilo lina ncha mpya, kifurushi kilichoileta, na matoleo yoyote ya awali ya marejeleo ambayo kifurushi kinategemea. Hifadhi ya blob na hifadhi ya metadata zote zinaweza kupanuliwa kwa kuongeza seva.

Kupakua commit au rejeleo kutoka Pando kunahitaji kurudia mfululizo wa matoleo ya marejeleo (faili za vifurushi) kwa programu mteja ili kuunda upya hali ya programu mteja iliyounda toleo la rejeleo linalopakuliwa. Hii hutoa kiwango cha chini zaidi cha uthabiti katika hifadhi nzima, huku ikihakikisha kwamba masasisho ya kila rejeleo yanaweza kutekelezwa kwa mpangilio unaofuatana. Programu za mteja hukinzana tu zinapotuma mabadiliko kwenye rejeleo lilelile kwa wakati mmoja. Programu mteja inayosoma matawi kadhaa haiwezi kudhani kuwa usomaji huo unaonyesha hali ya hifadhi nzima katika wakati mmoja.

Hii ni aina ya uthabiti wa kisababishi. Ili kupakua rejeleo, msomaji huona historia ya mwandishi aliyeliunda. Wakati wa kutuma, Pando hudhibiti historia ya pamoja ambayo programu mteja na seva zinakubaliana nayo, ikihakikisha kuwa programu za mteja zinatengeneza faili za vifurushi zinazoshirikishwa kwa urahisi zaidi.

Kwa hiyo, Pando haitoi hali ya marejeleo yote kwa wakati mmoja wakati wa shughuli za Git, wala mfuatano wa masasisho ya marejeleo ndani ya uundaji wa nakala au upakuaji. Kwa mfano, tuseme matawi foo na bar yanasasishwa wakati wa majadiliano ya kuunda nakala kamili. Wakati wa majadiliano, programu mteja moja inaweza kuona foo katika toleo la 1 na bar katika toleo la 2, huku nyingine ikiona foo katika toleo la 2 na bar katika toleo la 1. Kwa vitendo, watumiaji na mawakala hawategemei mfuatano wa jumla wa masasisho ya marejeleo; badala yake, wanategemea mfuatano wa masasisho ya rejeleo moja.

Katika uigaji huu wa miundo mitatu ya uthabiti wa data, tunasanidi programu mteja 1,000 ili kila moja ichague tawi tofauti na kisha kutuma commit za kipekee mara kwa mara. Tunapima muda wote wa utekelezaji na muda kati ya kutuma na kupakua. Kipimo cha pili ni muhimu kwa aina hizi za kazi kwa sababu hupima muda wa mawasiliano ya kwenda na kurudi unaohitajika ili watumiaji na mawakala washirikiane au watumie mifumo mingine inayotegemea udhibiti wa matoleo. Uigaji huu unaiga maunzi mbalimbali, kuanzia mashine pepe za kawaida hadi za kiwango cha juu, pamoja na mifumo ya hifadhi ya blob. Katika uigaji huu, tumepunguza sharti la uthabiti wa data katika hifadhi nzima kwa mfumo wa kukamilisha muamala kwa awamu tatu.

Mfumo ulioigwa wa uthibitishaji wa awamu tatu unaonyesha ucheleweshaji mkubwa zaidi wa kuandika kazi zinapoongezeka na diski kufikia kikomo cha uwezo wake. Wakati huohuo, mifumo ya kumbukumbu ya kabla ya kuandika inaonyesha ucheleweshaji mkubwa zaidi wa kusoma kwa sababu hiyohiyo, huku seva zikishindwa kuendana na kasi inayohitajika ya kusoma kumbukumbu. Katika majaribio halisi kwenye uhifadhi wetu wa pamoja wa msimbo na katika uigaji huu, Pando huhudumia maelfu mengi ya programu za mteja zinazoweza kutuma kwa wakati mmoja bila kupunguza utendaji kazi zinapoongezeka.

Inaposhughulikia utumaji, Pando hukagua uhalali wa faili ya kifurushi inayoingia huku ikiitiririsha kwenye hifadhi ya blob, bila kuifungua katika hifadhi ya ndani. Programu mteja inapoanza kupakua data, Pando huchagua vifurushi vilivyohifadhiwa ambavyo msomaji anahitaji, naye huvipakua. Hakuna seva inayohitaji kutumia faili za vifurushi kusasisha hifadhi ya ndani au kufanya shughuli za kufungua na kufungasha upya zinazotumia rasilimali nyingi. Kwa kuwa seva hizi hushughulikia hasa majadiliano na uteuzi wa faili za vifurushi, seva za Pando zinaweza kutumia maunzi ya kawaida.

Hii huwezesha Pando kupanuka hadi kufikia vikomo vya programu za mteja, mtandao kati ya programu hizo na Pando, na huduma ya hifadhi ya blob. Uwezo ukiwa wa kutosha, kila programu mteja inayofanya kazi kwenye tawi huru inaweza kuhamisha vifurushi kwa kasi ya juu inayoruhusiwa na muunganisho wake. Ili kuhudumia programu zaidi za mteja kwa kasi hiyo, tunaweza kuongeza seva za Pando na kupanua hifadhi za metadata na blob sambamba nazo.

Wakala huhariri faili na kuunda commit kwenye kompyuta yake, kisha huendesha git push, ambayo huunda faili ya kifurushi cha mabadiliko hayo ili kusasisha tawi. Pando hupokea kifurushi na kukitiririsha kwenye hifadhi ya blob. Baada ya kukagua uhalali wa utumaji unaoingia kwa kusimbua data mara moja, Pando hutumia muamala wa funguo nyingi kurekodi toleo la rejeleo katika hifadhi yetu ya metadata na kusasisha kielekezi cha rejeleo kama operesheni moja isiyogawanyika. Hii huwezesha Pando kuhakikisha uthabiti wa aina ya “soma ulichoandika mwenyewe”. Operesheni hii nzima ya kuandika inahitaji usomaji na uandishi wa metadata wa $O(1)$.

Programu nyingine ya mteja inapopakua tawi, Pando huchagua seti ya vifurushi vilivyohifadhiwa kwa kutumia historia ambayo programu hiyo tayari inayo. Operesheni hii inahitaji usomaji wa metadata wa $O(\log \Delta)$, ambapo $\Delta$ ni umbali mfupi zaidi, ukihesabiwa kwa matoleo ya marejeleo, kati ya kile ambacho programu mteja inacho na kile inachohitaji. Seva hurudisha URI za faili za vifurushi, na programu mteja huzipakua kupitia huduma ya Express, inayohifadhi faili hizo katika hifadhi za muda za kieneo.

Muundo huu unategemea huduma tatu kuu za usanifu wa Pando: utumaji, upakuaji na ujumuishaji wa vifurushi.

Programu mteja inapotuma mabadiliko, seva ya kawaida ya Git ni kama mchezaji wa poka anayeonyesha kadi zake zote: huifunulia programu mteja kila tawi ililo nalo. Programu mteja kisha hukusanya commit, miti na blob ili kuunda faili ya kifurushi ambayo haijumuishi vipengee ambavyo inajua seva tayari inavyo.

Kutangaza marejeleo mengi zaidi kunaweza kupunguza ukubwa wa data inayotumwa. Pia kunaweza kufanya kifurushi kuwa kigumu zaidi kutumia tena, kwa sababu programu nyingine ya mteja huenda isiwe na vipengee ambavyo mwandishi aliacha.

Pando hutumia mbinu tofauti. Badala ya kuonyesha kadi zake zote, huitangazia programu mteja seti teule tu ya matawi. Hii hufanywa kwa sababu mbili:

1. Kutoa mwonekano thabiti wa kila rejeleo kunatumia rasilimali nyingi. Kukiwa na mamilioni ya matawi, tangazo la marejeleo pekee linaweza kuzidi 100 MiB. Kutoa tangazo hilo kunahitaji kila seva kudumisha ramani iliyosasishwa, jambo linalohitaji uratibu mkubwa, au kufanya hoja ya hifadhidata inayokua kulingana na idadi ya marejeleo.

2. Programu mteja ikipewa sehemu tu ya marejeleo, itatengeneza kifurushi kinachotegemea tu vile vipengee ambavyo seva imeiruhusu waziwazi kuacha. Kufuatilia vitegemezi huwezesha Pando kutumia tena faili ya kifurushi iliyotengenezwa na programu mteja wakati wa utumaji mmoja, kwa kuitoa kama jibu la ombi la upakuaji linalofuata.

Kadiri seva ya Git inavyotangaza marejeleo mengi zaidi, programu za mteja zinazotuma huwa na vyanzo vingi zaidi vya kubaini vipengee vya kuacha, hivyo kutengeneza vifurushi vidogo zaidi. Hata hivyo, kutumia tena faili hizi za vifurushi kunahitaji seva iweze kuthibitisha kuwa programu za mteja zinazopakua zina kila kitegemezi. Vinginevyo, faili ya kifurushi inaweza kuacha vipengee ambavyo programu mteja inahitaji.

Kwa upande mwingine, seva ya Git isipotangaza rejeleo lolote, programu mteja itatengeneza faili ya kifurushi yenye historia nzima ya uhifadhi. Faili hiyo inaweza kutumiwa na programu nyingine yoyote ya mteja, lakini ina gharama kubwa: kupakua tawi lolote kunakuwa sawa na kuunda nakala kamili.

Kwa chaguomsingi, programu mteja inapotuma tawi jipya la kipengele, Pando hutangaza tawi kuu lililoteuliwa pekee kama msingi. Hii hudumisha ukubwa uleule wa tangazo matawi yanapoongezeka katika uhifadhi, lakini ina mapungufu yake. Mhandisi anapotuma kwenye tawi moja mara nyingi, au anapojenga tawi moja la kipengele juu ya jingine, programu mteja hulazimika kutuma tena kila kitu kisicho kwenye tawi kuu.

Hii hufanya utumaji unaofuatana wa tawi kuwa mkubwa zaidi, ukiwa na vipengee vinavyoweza kuwa vya kurudiwa, na kutumia kipimo data cha ziada cha programu mteja. Katika uhifadhi wetu wa pamoja wa msimbo, thamani ya kati ya ukubwa wa faili za vifurushi zilizotengenezwa hivi ilikuwa chini ya 20 KiB, na asilimia 99 zilikuwa chini ya 3 MiB. Kwetu, hili lilikuwa suluhu lenye uwiano mzuri kwa sababu msomaji ambaye tayari ana historia iliyotangazwa ya tawi kuu anaweza kupakua tawi kwa faili hiyo moja ya kifurushi.

Baada ya kuchagua seti ya marejeleo ya kuitangazia programu mteja, Pando hukubali utumaji na kusasisha hifadhi yake ya metadata. Pando hugawa usasishaji wa metadata katika sehemu ya papo hapo na sehemu ya kutekelezwa baadaye. Usasishaji wa metadata wa papo hapo huhakikisha kuwa programu za mteja zinaweza kupakua mara moja commit iliyosasishwa. Huu huandika toleo jipya la rejeleo na kusasisha kielekezi cha rejeleo ili kielekeze kwenye toleo hilo, ukihifadhi ncha mpya, vitegemezi vilivyotumika katika majadiliano ya faili ya kifurushi, na kiungo cha faili ya kifurushi iliyotumwa.

Wakati huohuo, kazi za kutekelezwa baadaye, kama vile kuratibu ujumuishaji wa vifurushi, hurekodiwa katika muamala huohuo. Kwa utumaji mkubwa sana, sehemu tu ya commit huandikwa papo hapo. Hii hutuwezesha kuhitaji idadi isiyobadilika tu ya usomaji na uandishi kwenye hifadhi ya metadata, bila kujali ukubwa wa utumaji.

Muhimu zaidi, seva za Pando zinaweza kukubali utumaji kwenye marejeleo yasiyohusiana kwa kujitegemea. Ufunguo pekee unaogombaniwa ni kielekezi cha rejeleo, ambacho tunakilinda kwa operesheni isiyogawanyika inayofanana na kulinganisha na kubadilisha. Tunaweza kuongeza utendaji wa uandishi kwa kuongeza seva za Pando, vitengo vya kupanua hifadhi ya metadata, au hifadhi za blob.

Programu mteja inapopakua, huipa seva seti mbili za vitambulisho vya commit, zinazojulikana katika itifaki kama have na want. Katika seva ya kawaida ya Git, seva hukokotoa tofauti kati ya seti ya vipengee vinavyofikika kutoka commit zilizopo na ile ya vipengee vinavyofikika kutoka commit zinazohitajika, huvibana, kisha hutuma matokeo kwa programu mteja. Ingawa seva huria ya Git ina faharasa mbalimbali za ndani za kuharakisha operesheni hii, kutengeneza faili hizi za vifurushi kunaweza kutumia rasilimali nyingi, na kwa ujumla ni vigumu kuzitumia kupitia hifadhi ya muda.

Badala yake, Pando hutumia ramani za commit zilizorekodiwa wakati wa utumaji kutafuta have na want za programu mteja na kuzihusisha na seti ya matoleo ya marejeleo yenye commit hizo. Kila toleo la rejeleo kati ya hayo lina kiungo cha faili ya kifurushi iliyopokewa awali na Pando. Seva hutumia hili kubaini mahitaji ya programu mteja, ikichagua faili za vifurushi zenye seti ya vipengee ambavyo programu hiyo inahitaji.

Itifaki ya Git huruhusu faili moja tu ya kifurushi kutumwa katika jibu la HTTP wakati wa kuunda nakala au kupakua. Hata hivyo, kipengele cha itifaki ya Git kisichothaminiwa vya kutosha, packfile-uri, huruhusu seva kurudisha viungo vya kupakua vifurushi vya ziada kando. Pando hutumia njia hii pekee, na hutuma faili tupu ya kifurushi ndani ya jibu lenyewe. Ili kuwezesha kipengele hiki, OpenAI ilichangia maboresho kadhaa ya packfile-uri kwenye mradi mkuu.

Mifumo ya OpenAI hufanya kazi katika maeneo mengi ya kijiografia, kwa hiyo tunadumisha makundi ya seva za Pando yenye hifadhi za muda za ndani katika kila eneo. Huduma ya kusambaza vifurushi, Express, huhifadhi kwa muda data kutoka hifadhi yetu ya blob, na huduma tofauti huhifadhi kwa muda data kutoka hifadhi ya metadata. Hifadhi hizi za muda huwezesha Pando kuhudumia maombi ya kitambulisho cha commit au usomaji maalumu wa rejeleo kwa kutumia tu hali iliyohifadhiwa kwa muda katika kundi hilo la seva. Tunatumia uhashi thabiti kuelekeza maombi ya faili za vifurushi kwenye seva za Express, huku zaidi ya 99% ya maombi yakipata data katika hifadhi ya muda.

Mfumo huu wa hifadhi za muda hutoa utendaji wa juu sana, unaoweza kutumia kikamilifu uwezo wa mtandao kati ya programu za mteja na Pando. Kwa kutumia URI hizi za faili za vifurushi na hifadhi za muda za ndani, tumethibitisha kuwa mashine pepe za kawaida tu za watoa huduma za wingu zinatosha kufanya uundaji wa nakala na upakuaji utumie kikamilifu miunganisho ya mtandao ya 10 Gbps.

Kwa seva nyingi za Git, kufungasha upya na kuondoa data isiyotumika ni muhimu ili kudumisha utendaji wa uhifadhi unaokua. Hatua hizi mbili hurejesha nafasi, lakini hutumia sana uwezo wa ukokotoaji na wa kusoma na kuandika data.

Katika uhifadhi unaobadilika haraka kama uhifadhi wa pamoja wa msimbo wa OpenAI, haiwezekani kwa vitendo kutuma URI tofauti ya faili ya kifurushi kwa kila utumaji uliofanyika tangu upakuaji wa mwisho. Kila siku, programu mteja ingehitaji kupakua makumi ya maelfu ya faili za vifurushi ili kusasisha tawi lake kuu.

Badala yake, Pando huunganisha vifurushi chinichini ili kupunguza mzigo huu wa ziada, ikitumia muundo unaofanana na ujumuishaji katika miti ya uunganishaji yenye muundo wa kumbukumbu. Kila utumaji hutengeneza faili ya kifurushi ambayo Pando huiita “L0”, inayowakilisha kitengo kidogo zaidi cha data ambacho Pando inaweza kutuma. Baada ya muda, michakato ya chinichini hukusanya faili hizi za vifurushi katika makundi yanayofunika mfuatano wa matoleo ya marejeleo, yakikua kwa uwiano wa kijiometri kuanzia L0. Kwa sasa, uhifadhi wetu wa pamoja wa msimbo hutumia makundi ya faili za vifurushi hadi kiwango cha L4.

Makundi haya yana kazi mbili. Kundi linapojaa vya kutosha, mchakato wa ujumuishaji hulichukua na kutengeneza faili moja ya kifurushi. Hii huboresha uwiano wa ubanaji kwa kupanga upya vipengee ndani ya faili ya kifurushi. Pia huboresha utendaji wa majadiliano ya upakuaji kwa kufanya kazi kama orodha ya kuruka katika matoleo ya marejeleo. Kwa kuchanganua faharasa za kila kiwango kwa wakati mmoja, Pando inaweza kuchagua seti ya vifurushi vya kutuma kwa programu mteja kwa muda wa kilogariti. Makundi haya ya faili za vifurushi, yawe yamefungashwa upya au la, huwezesha upangaji bora zaidi wa upakuaji.

Tofauti na seva nyingi za Git, faili za vifurushi huhifadhiwa katika kila kiwango na hazitupwi wala kuondolewa kama data isiyotumika. Vifurushi vya kila kiwango hutumika kuhudumia programu za mteja mfululizo, kulingana na have na want zinazotuma katika ombi la upakuaji. Na kwa programu za mteja zinazotumia Pando kama API, kusoma kipengee chochote kutoka faili ya kifurushi kwa kawaida huhitaji kusoma data chache kutoka L0 kuliko L4, kwa sababu kuna uwezekano mdogo zaidi wa kipengee hicho kuwa kimebanwa.

Ujumuishaji wa vifurushi katika Pando hupunguza sana jumla ya data inayotumwa kwa programu za mteja na kuwezesha muda na gharama ya kupanga vifurushi kukua kwa kiwango cha chini kuliko ongezeko la kiasi ambacho programu mteja imebaki nyuma. Hili ni muhimu hasa kwa hifadhi kubwa zinazobadilika haraka, ambazo tunatarajia kuwa hali ya kawaida katika uundaji wa programu.

Tuliunda Pando kwa kutumia Codex, kutoka kuanzisha mradi hadi matumizi halisi, kwa wiki 10 tu. Kiini cha Pando kilibuniwa na mhandisi mmoja, kikatekelezwa na timu za mawakala, na kuanzishwa katika matumizi na wahandisi wachache. Pando ilianza kuhudumia maombi ya matumizi halisi mwezi Aprili mwaka huu, na ni sehemu moja ya mfumo mkubwa wa zana za usimamizi wa udhibiti wa msimbo chanzo zinazotumiwa katika OpenAI.

Tulitumia mbinu mbalimbali sana kuthibitisha uhalali wa muundo wa Pando. Tulitumia kanuni zetu za kujenga misingi salama zaidi ya programu⁠. Kwa kuwa ulikuwa mradi mpya kabisa, tulichagua kuunda Pando kwa Rust bila vitegemezi vya mifumo ya zamani. Tuliandika mkusanyiko wa majaribio ya ulinganifu ili mawakala waweze kupima mabadiliko yao dhidi ya tabia ya kawaida ya Git. Pia tuliunda mazingira ya uendeshaji ya majaribio ya uigaji yenye matokeo yanayorudiwa kwa ingizo lilelile. Haya yalituwezesha kukagua sifa zisizopaswa kubadilika na tabia za mfumo, na kubaini na kupunguza migongano fiche ya utekelezaji wa wakati mmoja pamoja na kurudi nyuma kwa utendaji katika majadiliano na upangaji wa vifurushi.

Miundo mingi ilichangia mfumo huu; miundo mipya ilipopatikana, tuliitumia kuboresha utendaji na kutegemeka kwa Pando. Kwa kutumia GPT‑6 Astra, mawakala waliandika Lean na TLA+ kufafanua rasmi “nadharia ya Pando” ambayo tuliitumia kutafuta na kurekebisha hitilafu za utekelezaji, na kuthibitisha sifa za mfumo. Vipindi kadhaa vya kazi visivyokatizwa viliendelea kwa mamia ya saa, vikitafuta na kurekebisha hali zisizo za kawaida katika Pando. Pia tunaendesha mawakala saa zote ili kufanya majaribio ya kiadui ya usalama wa Git na Pando kwa kutumia miundo yenye uwezo wa Daybreak.

Mwanzoni tuliweka Pando kama seva mbadala inayopitisha usomaji na uandishi kwenye mfumo wetu uliokuwepo wa udhibiti wa msimbo chanzo. Hii ilituwezesha kusawazisha Pando na mfumo wa awali, ili tuweze kuhamishia maombi kwenye Pando kwa usalama bila kukatiza huduma.

Kama sehemu ya muundo wake wa hifadhi ya muda, Pando pia inaweza kuondoa maombi yanayojirudia na kuyaunganisha kabla ya kuyapitisha. Hii ilituwezesha kudumisha utendaji mzuri wa zana zetu zilizokuwepo huku tukihamishia mifumo kwenye Pando mmoja baada ya mwingine. Tulipohamishia kazi zaidi kwenye Pando, utumaji wake ulijaza hifadhi ya muda ya Pando na kuboresha kutegemeka kwa mfumo wetu wa awali wa upande wa seva.

Ili kuboresha utendaji wakati wa kutumia Pando, tulianza kusambaza toleo letu la Git linalopatikana hadharani kwenye kompyuta za wasanidi programu na ndani ya programu ya ChatGPT ya kompyuta. Ili kuhamishia programu za mteja kwenye Pando, tulitumia zana yetu ya ndani inayozunguka CLI ya Git kufanya uhamishaji kwa awamu. Tuliunda zana nyingine nyingi za kushughulikia maombi ya mabadiliko, ukaguzi wa msimbo na API za kazi za kiotomatiki. Tulihamisha mamia ya miunganisho iliyotegemea API za zamani, webhook na upakuaji wa hifadhi, pamoja na mawasiliano ya Git.

Codex yenyewe ilisaidia wasanidi programu na timu kufanya uhamishaji huo. Tuliunda ujuzi wa kuandaa nakala za kazi zilizokuwepo na wa kuwaelekeza mawakala kutumia mfumo mpya. Kwa hiyo, wasanidi programu wangeweza kuomba tu Codex ihamishe mazingira yao ya uundaji na huduma zao.

Kuhamia Pando kuliboresha kutegemeka kwa uunganishaji wa msimbo na kupunguza thamani ya kati ya muda wa utumaji kwa karibu 80%.

Pando inaweza kusambaza petabaiti moja ya data ya Git kwa siku kwa kutumia viini vichache tu vya CPU. Pando imesambaza zaidi ya terabaiti 57 za vifurushi vya Git ndani ya saa moja, huku zaidi ya 99% ya baiti hizo zikitoka kwenye hifadhi ya muda ya diski ya ndani.

Kutumia tena vifurushi huwezesha programu nyingi za mteja kupakua historia ileile ya uhifadhi kwa ukokotoaji mdogo kwenye nodi zinazozihudumia. Mfano huu unaonyesha uhifadhi mmoja, lakini Pando imeundwa kuhudumia hifadhi nyingi zaidi. Mahitaji yanapoongezeka, tunaweza kupanua uwezo wa usambazaji wa data na wa majadiliano ya Git kila mmoja kivyake.

Kuunda Pando kwa kutegemea itifaki na programu mteja ya Git kulitusaidia kubaini hitilafu na fursa za kuboresha utendaji wa Git yenyewe.

Kwa mfano, Pando hutuma vifurushi vinavyoweza kutumiwa tena moja kwa moja kwa programu za mteja, hivyo kupakua na kuweka faharasa za vifurushi hivyo kukawa sehemu kuu ya kuufanya mfumo kuwa wa kasi na wa kutegemeka. Kazi hiyo ilifichua hali zisizo za kawaida katika upakuaji wa wakati mmoja, usafishaji baada ya uhamishaji uliokatizwa, na kuendeleza upakuaji ambao tayari ulikuwa umekamilika. Tulirekebisha njia hizo za utekelezaji, tukaongeza ukaguzi wakati wa kukubali kifurushi kilichopo kwa upakuaji, na kuchangia kazi hiyo kwenye mradi mkuu.

Pia tulihitaji kuona muda na kipimo data vilivyokuwa vikitumika, hivyo tukaongeza ufuatiliaji wa upakuaji wa packfile-uri na hesabu za baiti za utengenezaji wa vifurushi. Hii ilirahisisha kubaini kama upakuaji wa polepole ulikuwa unatumia muda kutengeneza vifurushi au kuvihamisha.

Katika toleo la Git la OpenAI⁠(fungua katika dirisha jipya), programu mteja inaweza kupakua vifurushi visivyotegemeana na kuviwekea faharasa sambamba. Tuliongeza dhana ya “commit zilizopo zilizobainishwa wazi” ili seva iweze kutangaza ncha ya sasa ya tawi kando na historia ambayo programu mteja inayotuma inaweza kuacha katika kifurushi chake. Katika Pando, hili huwezesha programu za mteja kutumia --force-with-lease kukagua kuwa tawi la kipengele halijasonga, na kuunda kifurushi chake kwa kutegemea tawi kuu pekee. Yeyote mwenye historia hiyo ya tawi kuu anaweza kisha kupakua tawi kwa kutumia kifurushi kilekile.

Maboresho kadhaa kati ya haya tayari yamo katika mradi mkuu wa Git, na mengine mengi katika uhifadhi wetu wa umma. Tunaendelea kushirikiana na jumuiya ya Git ili maboresho haya yawe na manufaa nje ya Pando pia. Unaweza kufuatilia kazi hiyo katika kifuatiliaji chetu cha umma cha marekebisho⁠(fungua katika dirisha jipya).

Kwa kutathmini upya dhana zilizozoeleka kuhusu kupanua hifadhi za Git, Pando hutuwezesha kupanua uhifadhi wetu wa pamoja wa msimbo bila kubadilisha taratibu za Git ambazo wahandisi na mawakala wetu tayari wanatumia. Katika uhifadhi wetu wa pamoja wa msimbo, Pando imewezesha kazi nyingi zaidi kufanyika sambamba, imeongeza kutegemeka kwa uunganishaji wa msimbo na kupunguza muda wa kuchapisha mabadiliko ya msimbo. Mbali na uhifadhi wetu wa pamoja wa msimbo, tunachunguza pia matumizi mengine ya Pando ndani ya OpenAI, yakiwemo kazi ambazo zinahitaji mawakala wengi kushirikiana kwenye uhifadhi mmoja wa Git.

Kadiri wahandisi na mawakala wanavyotengeneza programu zaidi, timu nyingi zaidi nje ya OpenAI zitakumbana na vikomo tulivyofikia katika udhibiti wa msimbo chanzo. Kwa sasa tunachunguza njia za kushirikisha watumiaji wetu teknolojia inayowezesha Pando.

Pando imejengwa kwa kutegemea uzoefu wa miongo miwili wa watumiaji na waendeshaji wa hifadhi za Git. Tutaendelea kuboresha Pando huku tukishirikiana na jumuiya ya Git ya programu huria kushirikisha maboresho yoyote yanayowanufaisha watumiaji wa Git kwa upana zaidi.