OpenAIలో Git విస్తరణ

గత ఏడాది కాలంలో మా మోనోరిపో పరిమాణం, దానిపై అవసరాలు విపరీతమైన వేగంతో పెరిగాయి. Codex సాధ్యం చేస్తున్న ఏకకాల పనుల స్థాయికి విస్తరించాలంటే, మా మూలకోడ్ నియంత్రణ వ్యవస్థను పునర్నిర్మించాల్సిందేనని స్పష్టమైంది.

ఏ ఇంజినీరింగ్ పనికీ అంతరాయం కలిగించకుండా, మా బృందం Gitను ఉపయోగించే తీరు మార్చకుండా, Git రిపోజిటరీల కోసం Pando అనే కొత్త బ్యాకెండ్‌ను నిర్మించాం. ఇప్పుడు OpenAI మోనోరిపోలోని అభివృద్ధి పనులన్నింటికీ Pando ఆధారం. రెండు భారీ లక్ష్యాలను సాధించేలా Pandoను రూపొందించాం. మొదటిది: అనేక శాఖలకు ఏకకాలంలో పుష్ చేయడానికి అనుకూలంగా, మరిన్ని యంత్రాలను జోడిస్తూ రాత సామర్థ్యాన్ని విస్తరించడం. రెండోది: పఠన థ్రూపుట్‌ను గరిష్ఠ స్థాయికి చేర్చి, క్లయింట్లు తమకు అందుబాటులోని నెట్‌వర్క్ బ్యాండ్‌విడ్త్‌ను పూర్తిగా ఉపయోగించుకునేంత వేగంగా డేటాను డౌన్‌లోడ్ చేసుకునేలా చేయడం.

Git ప్రోటోకాల్, క్లయింట్‌తో అనుకూలతను కొనసాగిస్తూనే ఈ లక్ష్యాలను సాధించాం. దీంతో మా ఇంజినీర్లు, ఏజెంట్లు తమ ప్రస్తుత పనివిధానాల్లో Pandoను సులభంగా స్వీకరించగలిగారు. వాస్తవ వినియోగంలో మధ్యస్థ పుష్ ఆలస్యాన్ని Pando దాదాపు ఐదో వంతుకు తగ్గించింది. ఇప్పుడు ఇది రోజుకు దాదాపు ఒక పెటాబైట్ Git డేటాను అందిస్తుంది.

కొత్త మూలకోడ్ నియంత్రణ వ్యవస్థను ఎందుకు నిర్మించామో, Gitతో అనుకూలతను ఎందుకు కొనసాగించామో ఇక్కడ వివరిస్తాం. Gitను విస్తరించే సాధారణ విధానాలతో మా వ్యవస్థను పోలుస్తూ, OpenAI విస్తరణ అవసరాలను తీర్చడంలో Pandoకు ఉన్న ప్రత్యేక సామర్థ్యాన్ని వివరిస్తాం. తర్వాతి అడుగులనూ, ఏజెంట్ల స్థాయిలో జరిగే పనికి మద్దతుగా Gitకు మా సహకారాన్ని ఎలా కొనసాగిస్తామో కూడా చర్చిస్తాం.

Codex వల్ల ఇంజినీర్లు సమాంతరంగా మరింత ఎక్కువ పని చేయగలుగుతున్నారు. దీంతో OpenAIలో అభివృద్ధి పరిమాణం, వేగం మారిపోయాయి. దీని అర్థం మరిన్ని శాఖలు, పుష్‌లు, విలీనాలు. అభివృద్ధి వాతావరణాలు, పరిశోధన పనులు, నిరంతర సమీకరణ నుంచి మరిన్ని ఫెచ్‌లు, క్లోన్‌లు కూడా అవసరమవుతున్నాయి.

ఈ అవసరాలు ఒకదానితో మరొకటి కలిసి మరింత పెరుగుతాయి. ఇప్పుడు ఒక ఇంజినీర్ ఏకకాలంలో అనేక మార్పులను నిరంతర సమీకరణకు సిద్ధం చేయగలరు. ప్రతి పుష్ ఒకే కమిట్‌ను పొందే అనేక పనులను ప్రారంభించవచ్చు.

గత ఏడాది చివరి నుంచి మా మోనోరిపోకు మద్దతిచ్చే వ్యవస్థలు ఈ అవసరాలను అందుకోవడంలో ఇబ్బందిపడ్డాయి. ఫెచ్‌లు, పుష్‌లు నెమ్మదించాయి; విలీనాలు విఫలమయ్యాయి. కొన్నిసార్లు విశ్వసనీయత 90% కంటే దిగువకు పడిపోయింది. మేం చేరుకున్నది Git సామర్థ్య పరిమితినా, లేక మా మోనోరిపో సేవలను అందించే విధానపు పరిమితినా? ఈమెయిల్ ద్వారా కెర్నల్ ప్యాచ్‌లను పంచుకునే సముదాయం నుంచి Git రూపుదిద్దుకుంది. రెండు దశాబ్దాలకు పైగా, సాఫ్ట్‌వేర్‌ను నిర్మించే పద్ధతులు మారుతున్న కొద్దీ డెవలపర్లు తమ సాధనాలను Gitకు అనుగుణంగా మలుచుకున్నారు. మా మోనోరిపోలో ఆటంకాలు మొదలైనప్పుడు, ఆ కృషి ఆధారంగా ముందుకు సాగగలగడం మాకు ముఖ్యమైంది.

తెలిసిన పనివిధానాన్ని కొనసాగిస్తూనే, వేర్వేరు శాఖల పుష్‌లను సమాంతరంగా నిర్వహించేందుకు, ఒకే చరిత్రను అనేక రీడర్లకు ఏకకాలంలో అందించేందుకు బ్యాకెండ్‌ను పునర్నిర్మించే మార్గం కనిపించింది. మా మూలకోడ్ నియంత్రణ పనివిధానానికి Gitను పునాదిగా ఎంచుకోవడం వల్ల, క్లయింట్‌లో చేసే మెరుగుదలలు OpenAI వెలుపల కూడా ఉపయోగపడగలవు. మా Git ప్రతిలోని⁠(కొత్త విండోలో తెరుచుకుంటుంది) ఆ మెరుగుదలలను ప్రధాన Git ప్రాజెక్టుకు అందించి, విస్తృత సముదాయంతో పంచుకోవాలనుకున్నాం.

మూలకోడ్ నియంత్రణ వ్యవస్థను విస్తరించడంలో రెండు కీలక కోణాలున్నాయి: వేర్వేరు శాఖలకు పుష్ చేసే అనేక రైటర్లు, ఒకే చరిత్రను పొందే అనేక రీడర్లు. Pando రెండింటికీ అనుకూలంగా పనిచేస్తుంది.

మొదటగా, ప్రతి శాఖ నవీకరణలను Pando స్వతంత్రంగా సమన్వయపరుస్తుంది. సంబంధం లేని శాఖల నవీకరణలు సమాంతరంగా సాగవచ్చు. ఒక శాఖను పొందే రీడర్‌కు ఆ సంస్కరణకు అవసరమైన చరిత్ర అందుతుంది. అయితే అనేక శాఖలను చూసే రీడర్‌కు అవి వేర్వేరు సమయాల్లోని స్థితుల్లో కనిపించవచ్చు. ఇది అంగీకరించాల్సిన పరిమితి.

రెండవదిగా, ప్రతి క్లయింట్‌కు ప్రత్యేక ప్యాక్‌ఫైల్‌ను రూపొందించే బదులు, Pando ఫెచ్‌ల మధ్య ప్యాక్‌ఫైళ్లను తిరిగి ఉపయోగిస్తుంది. ఇవి అనేక ఆబ్జెక్టులను కలిపి సంకోచించేందుకు Git ఉపయోగించే ఫార్మాట్. క్లయింట్ ఇప్పటికే తన వద్ద ఉన్న కొన్ని ఆబ్జెక్టులను మళ్లీ డౌన్‌లోడ్ చేసుకోవచ్చు. కానీ సర్వర్ చాలా తక్కువ గణనతో అవే బైట్‌లను అనేక క్లయింట్లకు అందించగలదు.

ఈ ఎంపికలతో శాఖల అంతటా రాత సామర్థ్యాన్ని విస్తరించగలం, క్యాష్‌ల నుంచి పఠన అభ్యర్థనలకు సేవలందించగలం. ఇవి కలిసి ఎలా పనిచేస్తాయో తెలుసుకోవడానికి, ముందుగా Git చరిత్రను ఎలా నిల్వ చేసి బదిలీ చేస్తుందో చూద్దాం.

రిపోజిటరీలోని రెండు భాగాలను Git సమకాలీకరించగలగాలి: ఆబ్జెక్టులు, రిఫరెన్స్‌లు.

Git రిపోజిటరీ ఫైళ్ల స్నాప్‌షాట్‌లనూ, వాటిని అనుసంధానించే చరిత్రనూ ఆబ్జెక్టుల గ్రాఫ్‌గా నమోదు చేస్తుంది. ఆబ్జెక్టు అనేది బ్లాబ్, ట్రీ, కమిట్ లేదా ట్యాగ్ కావచ్చు. బ్లాబ్‌లు ఒక్కో ఫైల్‌లోని విషయాన్ని భద్రపరుస్తాయి. ట్రీలు పేర్లను బ్లాబ్‌లకు లేదా ఇతర ట్రీలకు అనుసంధానించి డైరెక్టరీ నిర్మాణాన్ని ఏర్పరుస్తాయి. కమిట్‌లు మూల ట్రీని, సున్నా లేదా అంతకంటే ఎక్కువ మాతృ కమిట్‌లను సూచిస్తూ మీ రిపోజిటరీ చరిత్రను నిర్మిస్తాయి.

ఆబ్జెక్టుల రకం, విషయాల నుంచి రూపొందిన హ్యాష్ ద్వారా వాటిని గుర్తిస్తారు. ఆబ్జెక్టులను మార్చలేరు: మారిన ఫైల్‌ను నమోదు చేస్తే కొత్త బ్లాబ్ ఏర్పడుతుంది. మారని ఫైళ్లు, డైరెక్టరీలు ప్రస్తుత ఆబ్జెక్టులనే తిరిగి ఉపయోగించవచ్చు.

శాఖలు, ట్యాగ్‌లు కమిట్‌లను సూచించే రిఫరెన్స్‌లు లేదా “రెఫ్‌లు”. శాఖలో కమిట్ చేస్తే కొత్త కమిట్ ఏర్పడి, శాఖ రెఫ్ దాన్ని సూచించేలా నవీకరించబడుతుంది.

Git ఆబ్జెక్టులను “విడివిడి” లేదా “ప్యాక్ చేసిన” స్థితిలో నిల్వ చేస్తుంది. విడివిడి ఆబ్జెక్టులు వాటి ఆబ్జెక్టు గుర్తింపుతో విడి ఫైళ్లలో నిల్వ ఉంటాయి. ప్యాక్ చేసిన ఆబ్జెక్టులు ప్యాక్‌ఫైల్‌లో కలిపి నిల్వ ఉంటాయి. దీంతో సారూప్య ఆబ్జెక్టులను ఒకదానితో మరొకటి పోల్చిన తేడాల రూపంలో నిల్వ చేయవచ్చు.

ఒక కమిట్ నుంచి దాని మాతృ కమిట్‌లు, ట్రీలు, బ్లాబ్‌ల లింక్‌లను అనుసరించి Git ఒక ఆబ్జెక్టును కనుగొనగలిగితే, ఆ కమిట్ నుంచి ఆ ఆబ్జెక్టు చేరుకోదగినది అవుతుంది. ఫెచ్ సమయంలో తనకు ఏ కమిట్‌లు కావాలో, ఇప్పటికే ఏవి ఉన్నాయో క్లయింట్ సర్వర్‌కు చెబుతుంది. కావాల్సిన కమిట్‌ల నుంచి చేరుకోగల ఆబ్జెక్టులను సర్వర్ కనుగొంటుంది. క్లయింట్ వద్ద ఇప్పటికే ఉన్నాయని తెలిసినవాటిని మినహాయించి, మిగిలినవాటిని Git డిస్క్‌పై ఉపయోగించే ఫార్మాట్‌లోనే ప్యాక్‌ఫైల్‌గా పంపుతుంది. పూర్తి క్లోన్ ఏ ఆబ్జెక్టులూ లేకుండా ప్రారంభమవుతుంది. కాబట్టి క్లోన్ చేస్తున్న చరిత్ర నుంచి చేరుకోగల అన్ని ఆబ్జెక్టులు దానికి అవసరం.

ఒకటి లేదా అంతకంటే ఎక్కువ రెఫ్‌లను నవీకరించమని సర్వర్‌ను కోరుతూ, పుష్ ఆబ్జెక్టులను వ్యతిరేక దిశలో బదిలీ చేస్తుంది. సర్వర్ వద్ద ఇప్పటికే ఉన్న ఆబ్జెక్టులను పంపకుండా ఉండేందుకు, సర్వర్ ప్రకటించిన రెఫ్‌ల సమితిని క్లయింట్ ఉపయోగిస్తుంది. అందువల్ల పంపే ప్యాక్ ప్రస్తుత ఆబ్జెక్టులపై ఆధారపడవచ్చు. కొత్త చరిత్రను పునర్నిర్మించడానికి ఆ ప్యాక్ ఒక్కటి అందితే సరిపోదు.

Git రిపోజిటరీ ప్రతులను నిర్వహించడం అంటే, అనేక సర్వర్లలో ఆబ్జెక్టులు, రిఫరెన్స్‌లు రెండింటినీ అందుబాటులో ఉంచడం. ప్రతిరూపం ఒక రిఫరెన్స్ కొత్త విలువను అందించే ముందు, ఆ విలువ నుంచి చేరుకోగల ఆబ్జెక్టులను అందించగలగాలి. పోటీ పడే రిఫరెన్స్ నవీకరణలను కూడా సేవ సమన్వయపరచాలి. అంటే ఒకే శాఖను ఒకే పాత చివరి కమిట్ నుంచి వేర్వేరు కొత్త కమిట్‌లకు మార్చేందుకు ప్రయత్నించే పుష్‌లను నిర్వహించాలి. రిపోజిటరీలోని అన్ని రాతలకు ఒకే క్రమాన్ని నిర్దేశించే వ్యవస్థలు, సంబంధం లేని శాఖల పుష్‌లు కూడా ఒకదానికోసం మరొకటి వేచి ఉండేలా చేయవచ్చు.

Pando రూపకల్పనలో Gitతో మూలకోడ్ నియంత్రణను విస్తరించే సంప్రదాయ విధానాలను పరిశీలించాం. ఒకటి మూడు దశల కమిట్‌తో రిపోజిటరీ ప్రతిరూపాల మధ్య రెఫ్ నవీకరణలను సమన్వయపరుస్తుంది. ఇది అనేక నోడ్‌లలో కమిట్‌ను సమన్వయపరిచే ప్రోటోకాల్. మరొకటి బ్లాబ్ నిల్వలో ఉమ్మడి ముందస్తు రాత లాగ్ ద్వారా నవీకరణలను క్రమబద్ధీకరిస్తుంది. ఈ లాగ్ మార్పులను అమలు చేసే ముందే నమోదు చేస్తుంది.

మేం నమూనాగా తీసుకున్న మూడు దశల కమిట్ రూపకల్పనలో, Git సేవ అనేక ప్రతిరూపాల్లో రిపోజిటరీ పూర్తి ప్రతిని ఉంచుతుంది. ఏ సర్వర్ పుష్‌ను స్వీకరించినా, వచ్చే ప్యాక్‌ఫైల్‌ను కాపీ చేసి అన్ని ప్రతిరూపాలకు సమాంతరంగా పంపుతుంది. పుష్‌ను ప్రచురించాలంటే, మెజారిటీ ప్రతిరూపాలు రెఫ్ నవీకరణను అంగీకరించాలి. దీన్ని నిర్వహించే సర్వర్ సమన్వయకర్త. దానికీ ప్రతి ఇతర ప్రతిరూపానికీ మధ్య అనేక విడతల సమాచార మార్పిడి అవసరం.

రిఫరెన్స్ నవీకరణను అంగీకరించేందుకు, ప్రతి ప్రతిరూపం తన రెఫ్ ప్రతిని లాక్ చేసి, అది ఇప్పటికీ క్లయింట్ ఆశించే కమిట్‌నే సూచిస్తోందని తనిఖీ చేస్తుంది. తర్వాత సమన్వయకర్త అంగీకరించిన ప్రతిరూపాలకు కమిట్‌కు ముందు సందేశాన్ని పంపుతుంది. మెజారిటీ ఆ సందేశాన్ని అందుకున్నట్లు ధ్రువీకరించగానే, నవీకరణను అమలు చేయమని సమన్వయకర్త చెబుతుంది. ఆ తర్వాత తాజాగా ఉన్న ఏ ప్రతిరూపమైనా తన స్థానిక రిపోజిటరీ ప్రతి నుంచి శాఖ కొత్త చివరి కమిట్‌ను ప్రకటించగలదు.

పూర్తి ప్రతిరూపాలను ఉంచడం వల్ల స్థానికంగా పఠన సేవలను అందించవచ్చు. క్లయింట్లు ఏ ప్రతిరూపాన్ని ఎంచుకున్నా అన్ని రిఫరెన్స్‌ల ఏకరూప స్థితి లభిస్తుందని హామీ ఉంటుంది. ఫలితంగా, రిఫరెన్స్‌లు ఒక్కొక్కటిగా నవీకరించబడతాయి. ప్రతి పుష్‌లో ప్రతిరూపాల మధ్య రెఫ్ నవీకరణను సమన్వయపరచేందుకు అనేక విడతల సమాచార మార్పిడి అవసరం.

అవసరమైన సంఖ్యలో ప్రతిరూపాల అంగీకారం కోసం వేచి ఉండటం వల్ల, వాటి డిస్క్ పనితీరు, సమాచార మార్పిడి ఆలస్యం పుష్ సమయాన్ని ప్రభావితం చేస్తాయి. రాతల పరిమాణం పెరిగే కొద్దీ, వచ్చే ప్యాక్‌లతోపాటు పఠన ట్రాఫిక్‌ను కూడా ప్రతిరూపాలు అందుకోగలగాలి.

మేం నమూనాగా తీసుకున్న ముందస్తు రాత లాగ్ రూపకల్పనలో, రిపోజిటరీ అంతటా నవీకరణలను క్రమబద్ధీకరించేందుకు Git సేవ బ్లాబ్ నిల్వలో ఉమ్మడి మానిఫెస్ట్‌ను ఉపయోగిస్తుంది. సర్వర్ పుష్‌ను స్వీకరించినప్పుడు, వచ్చే ప్యాక్‌ఫైల్‌ను బ్లాబ్ నిల్వకు అప్‌లోడ్ చేసి, తన స్థానిక రిపోజిటరీ ప్రతిలో రెఫ్ నవీకరణను సిద్ధం చేస్తుంది. పుష్‌ను ప్రచురించేందుకు, బ్లాబ్ నిల్వలోని ఉమ్మడి మానిఫెస్ట్‌కు ఒక నమోదును జోడిస్తుంది. అది రెఫ్ నవీకరణను నమోదు చేసి, ప్యాక్‌ఫైల్‌ను సూచిస్తుంది. తర్వాత Git సర్వర్ పోల్చి మార్చే చర్యతో మానిఫెస్ట్‌ను నవీకరిస్తుంది. ఇది మానిఫెస్ట్‌ను విడదీయలేని ఒకే చర్యగా భర్తీ చేస్తుంది, లేదా మార్పును తిరస్కరిస్తుంది. ఈలోగా మరో రైటర్ దాన్ని నవీకరించి ఉంటే, మధ్యలో చేరిన నమోదులను సర్వర్ చదువుతుంది. తన రెఫ్ నవీకరణ ఇప్పటికీ చెల్లుతుందని తనిఖీ చేసి, ఇప్పటికే అప్‌లోడ్ చేసిన ప్యాక్‌ఫైల్‌తో మళ్లీ ప్రయత్నిస్తుంది.

రైటర్లు తమ ప్యాక్‌ఫైళ్లను సమాంతరంగా అప్‌లోడ్ చేయవచ్చు. కానీ సంబంధం లేని శాఖల పుష్‌లు కూడా అదే మానిఫెస్ట్‌ను నవీకరించాలి. విజయవంతమైన పోల్చి మార్చే చర్యకు పట్టే పూర్తి ప్రతిస్పందన సమయం, రిపోజిటరీ కొత్త మానిఫెస్ట్‌ను ఎంత తరచుగా ప్రచురించగలదో పరిమితం చేస్తుంది. తక్కువ ఆలస్యమున్న బ్లాబ్ నిల్వ ఈ దశను వేగవంతం చేస్తుంది. సమూహాలుగా చేయడం వల్ల ఒకే మానిఫెస్ట్‌తో అనేక రెఫ్‌లను ఏకకాలంలో నవీకరించవచ్చు. అయితే నవీకరణలను వరుసలో వేచి ఉంచడం వల్ల ఆలస్యం పెరుగుతుంది.

బ్లాబ్ నిల్వ ప్యాక్‌ఫైళ్లను సమాంతరంగా స్వీకరించగలిగినా, ఉమ్మడి మానిఫెస్ట్ నవీకరణలు మాత్రం ఒకదానితో మరొకటి పోటీ పడతాయి. బ్లాబ్ నిల్వ సామర్థ్యాన్ని మాత్రమే పెంచితే ఆ అవరోధం తొలగిపోదు. ప్రతి ప్రతిరూపం స్థానికంగా ప్యాక్‌లను అందించే ముందు, వాటిని బ్లాబ్ నిల్వ నుంచి చదివి సూచికలు రూపొందించాల్సిందే. వచ్చే రాతల వేగం ఆ పని వేగాన్ని మించితే, ప్రతిరూపాలు వెనుకబడతాయి. కొత్తగా పుష్ చేసిన కమిట్‌లను పొందడానికి క్లయింట్లు ఎక్కువసేపు వేచి ఉండాలి.

ఇప్పుడు Pando విషయానికి వద్దాం. అనేక క్లయింట్లు ఏకకాలంలో పుష్ చేసినా అందుకోగల స్థాయికి విస్తరించడమే లక్ష్యంగా, Git రిపోజిటరీ సేవల కోసం రూపొందించిన కొత్త నిర్మాణం Pando. ఇది ఇలా పనిచేస్తుంది:

Pando అభివృద్ధికి ముందే, Git విషయంలో రాజీపడకుండా మా అవసరాలను తీర్చగలమని మాకు అనిపించింది. అయితే చాలా Git వ్యవస్థలు తప్పనిసరిగా భావించే కొన్ని అంశాల్లో రాజీపడాల్సి వచ్చింది:

• రిపోజిటరీ అంతటా స్థితి ఏకరూపత: అన్ని రెఫ్‌లనూ ఒకే సమయానికి సంబంధించిన ఏకరూప స్నాప్‌షాట్‌గా అందించాలంటే రిపోజిటరీ అంతటా సమన్వయం అవసరం. అన్ని రెఫ్ నవీకరణలను ఒకే క్రమంలో ఉంచే వ్యవస్థలో, సంబంధం లేని శాఖల పుష్‌లు కూడా ఒకే సమన్వయ కేంద్రం కోసం పోటీ పడతాయి.

• ప్రతి క్లయింట్‌కు ప్రత్యేక ప్యాక్‌ఫైళ్లు: వేర్వేరు స్థానిక చరిత్రలున్న ఇద్దరు క్లయింట్లు ఒకే శాఖను పొందితే, ఇప్పటికే వారి వద్ద ఉన్న ఆబ్జెక్టులను పంపకుండా ఉండేందుకు సర్వర్ ఒక్కొక్కరికీ వేర్వేరు ప్యాక్‌లను తయారుచేయాల్సి రావచ్చు. ఈ ప్రతిస్పందనలను తయారుచేయడానికి ప్రాసెసర్, డిస్క్ ఇన్‌పుట్/అవుట్‌పుట్ వనరులు ఖర్చవుతాయి. దీంతో పెద్ద సంఖ్యలో రీడర్లకు సేవలందించేలా విస్తరించడం కష్టమవుతుంది.

బదులుగా, రాత కార్యకలాపాలను విస్తరించేందుకు Pando సడలించిన స్థితి ఏకరూపత విధానాన్ని (కారణాత్మక ఏకరూపత) అందిస్తుంది. పఠన కార్యకలాపాలను విస్తరించేందుకు ప్యాక్‌ఫైళ్లను తిరిగి ఉపయోగిస్తుంది.

క్లయింట్ ఒక శాఖకు పుష్ చేసినప్పుడు, Pando వచ్చే ప్యాక్‌ఫైల్‌ను మార్చలేని బ్లాబ్‌గా బ్లాబ్ నిల్వలో భద్రపరుస్తుంది. శాఖ మారిన ప్రతిసారీ, కొత్త చివరి కమిట్, దాన్ని అందించిన ప్యాక్, ఆ ప్యాక్ ఆధారపడిన మునుపటి రెఫ్ వెర్షన్‌లతో కూడిన రెఫ్ వెర్షన్‌ను Pando మెటాడేటా నిల్వలో నమోదు చేస్తుంది. బ్లాబ్ నిల్వనూ, మెటాడేటా నిల్వనూ మరిన్ని యంత్రాలను జోడించడం ద్వారా విస్తరించవచ్చు.

Pando నుంచి కమిట్ లేదా రిఫరెన్స్‌ను పొందాలంటే, రెఫ్ వెర్షన్‌ల సమితిని (ప్యాక్‌ఫైళ్లను) క్లయింట్‌కు మళ్లీ అందించాలి. తద్వారా పొందుతున్న రెఫ్ వెర్షన్‌ను సృష్టించిన క్లయింట్ స్థితి పునర్నిర్మితమవుతుంది. ఇది మొత్తం రిపోజిటరీలో తక్కువ కఠినమైన స్థితి ఏకరూపతను అందిస్తూనే, ఒక్కో రెఫ్ నవీకరణలకు వరుసగా అమలైనట్లే ఫలితాలు వచ్చే హామీనిస్తుంది. ఒకే రెఫ్‌కు ఏకకాలంలో పుష్ చేసినప్పుడే క్లయింట్ల మధ్య ఘర్షణ తలెత్తుతుంది. అనేక శాఖలను చదివే క్లయింట్, ఆ పఠనాలన్నీ రిపోజిటరీలో ఒకే సమయపు స్థితిని సూచిస్తున్నాయని భావించకూడదు.

ఇది కారణాత్మక ఏకరూపత యొక్క ఒక రూపం. రిఫరెన్స్‌ను పొందేందుకు, దాన్ని సృష్టించిన రైటర్ చరిత్రను రీడర్ గమనిస్తుంది. పుష్ సమయంలో క్లయింట్, సర్వర్ ఏ ఉమ్మడి చరిత్రపై అంగీకరించాలో Pando నియంత్రిస్తుంది. దీనివల్ల క్లయింట్లు సులభంగా పంచుకోగల ప్యాక్‌ఫైళ్లను సృష్టిస్తాయి.

అందువల్ల Git కార్యకలాపాల సమయంలో అన్ని రిఫరెన్స్‌లకు ఒకే సమయపు స్థితినీ, క్లోన్ లేదా ఫెచ్‌లో రెఫ్ నవీకరణల ఉమ్మడి క్రమాన్నీ Pando అందించదు. ఉదాహరణకు, పూర్తి క్లోన్ కోసం సంప్రదింపులు జరుగుతుండగా foo, bar శాఖలు రెండూ నవీకరించబడ్డాయని అనుకుందాం. ఆ సంప్రదింపుల్లో ఒక క్లయింట్ foo వెర్షన్ 1ను, bar వెర్షన్ 2ను చూడవచ్చు. మరొక క్లయింట్ foo వెర్షన్ 2ను, bar వెర్షన్ 1ను చూడవచ్చు. ఆచరణలో, వినియోగదారులు, ఏజెంట్లు రెఫ్ నవీకరణల మొత్తం క్రమంపై ఆధారపడరు. వారు ఒక్క రిఫరెన్స్‌లోని నవీకరణల క్రమంపైనే ఆధారపడతారు.

ఈ మూడు స్థితి ఏకరూపత విధానాల అనుకరణలో, 1,000 క్లయింట్లలో ప్రతి ఒక్కటి వేర్వేరు శాఖను ఎంచుకుని, ప్రత్యేక కమిట్‌లను పదేపదే పుష్ చేసేలా అమర్చాం. మొత్తం గడిచిన సమయాన్నీ, పుష్ నుంచి ఫెచ్ వరకు ఆలస్యాన్నీ కొలిచాం. రెండో కొలమానం పనిభారాలకు ముఖ్యమైనది. ఎందుకంటే వినియోగదారులు, ఏజెంట్లు కలిసి పనిచేయడానికి లేదా వెర్షన్ నియంత్రణపై ఆధారపడిన ఇతర వ్యవస్థలను ఉపయోగించడానికి పట్టే పూర్తి ప్రతిస్పందన సమయాన్ని ఇది కొలుస్తుంది. ఈ అనుకరణ సాధారణ స్థాయి నుంచి అత్యున్నత స్థాయి వరకు వర్చువల్ యంత్రాలు, బ్లాబ్ నిల్వ వ్యవస్థల హార్డ్‌వేర్‌ను ప్రతిబింబిస్తుంది. ఈ అనుకరణలో, మూడు దశల కమిట్‌కు రిపోజిటరీ అంతటా స్థితి ఏకరూపత నిబంధనను సడలించాం.

నమూనాగా తీసుకున్న మూడు దశల కమిట్ వ్యవస్థలో, భారం పెరిగి డిస్క్‌లు పూర్తి సామర్థ్యానికి చేరినప్పుడు రాత ఆలస్యం గణనీయంగా పెరుగుతుంది. అదే కారణంతో ముందస్తు రాత లాగ్ వ్యవస్థల్లో పఠన ఆలస్యం బాగా పెరుగుతుంది. జర్నల్‌ను చదవడంలో సర్వర్లు అవసరమైన వేగాన్ని అందుకోలేవు. మా మోనోరిపోపై వాస్తవ పరీక్షల్లోనూ, ఈ అనుకరణలోనూ, భారం ఉన్నప్పుడు పనితీరు దెబ్బతినకుండా అనేక వేల క్లయింట్లు ఏకకాలంలో పుష్ చేయడానికి Pando మద్దతిస్తుంది.

పుష్‌ను నిర్వహించేటప్పుడు, Pando వచ్చే ప్యాక్‌ఫైల్‌ను స్థానిక రిపోజిటరీలో విప్పకుండా, బ్లాబ్ నిల్వకు ప్రవాహంగా పంపుతూనే ధ్రువీకరిస్తుంది. క్లయింట్ ఫెచ్‌ను ప్రారంభించినప్పుడు, రీడర్‌కు అవసరమైన నిల్వ ప్యాక్‌లను Pando ఎంచుకుంటుంది. రీడర్ వాటిని డౌన్‌లోడ్ చేసుకుంటుంది. ఏ సర్వరూ స్థానిక రిపోజిటరీకి ప్యాక్‌ఫైళ్లను వర్తింపజేయాల్సిన అవసరం లేదు. అధిక వనరులు అవసరమయ్యే ప్యాక్‌లను విప్పడం, తిరిగి ప్యాక్ చేయడం వంటి పనులూ చేయనవసరం లేదు. ఈ సర్వర్లు ప్రధానంగా సంప్రదింపులు, ప్యాక్‌ఫైళ్ల ఎంపిక పనులే చేస్తాయి కాబట్టి, Pando సర్వర్లు సాధారణ హార్డ్‌వేర్‌పై నడవగలవు.

దీనివల్ల క్లయింట్లు, క్లయింట్లు–Pando మధ్య నెట్‌వర్క్, బ్లాబ్ నిల్వ సేవల సామర్థ్య పరిమితుల వరకు Pando విస్తరించగలదు. తగిన సామర్థ్యం ఉంటే, స్వతంత్ర శాఖలపై పనిచేసే ప్రతి క్లయింట్ తన కనెక్షన్ అనుమతించే గరిష్ఠ వేగంతో ప్యాక్‌లను బదిలీ చేయగలదు. అదే వేగంతో మరింత మంది క్లయింట్లకు సేవలందించేందుకు, Pando సర్వర్లను జోడించి, వాటితోపాటు మెటాడేటా నిల్వనూ, బ్లాబ్ నిల్వనూ విస్తరించవచ్చు.

ఏజెంట్ స్థానికంగా ఫైళ్లను సవరించి, కమిట్‌ను సృష్టించి, git pushను అమలు చేస్తుంది. ఇది శాఖను నవీకరించేందుకు ఆ మార్పులతో ప్యాక్‌ఫైల్‌ను తయారుచేస్తుంది. Pando ప్యాక్‌ను స్వీకరించి, బ్లాబ్ నిల్వకు ప్రవాహంగా పంపుతుంది. వచ్చిన పుష్‌ను ఒక్కసారి డీకోడ్ చేసి ధ్రువీకరించిన తర్వాత, Pando బహుళ కీ లావాదేవీతో మా మెటాడేటా నిల్వలో రెఫ్ వెర్షన్‌ను నమోదు చేసి, రెఫ్ పాయింటర్‌ను విడదీయలేని ఒకే చర్యగా నవీకరిస్తుంది. దీంతో Pando “మీరు రాసినదాన్ని మీరే చదవగల” స్థితి ఏకరూపతను అందిస్తుంది. ఈ మొత్తం రాత కార్యకలాపానికి $O(1)$ మెటాడేటా పఠనాలు, రాతలు అవసరం.

మరొక క్లయింట్ శాఖను పొందేటప్పుడు, దాని వద్ద ఇప్పటికే ఉన్న చరిత్ర ఆధారంగా Pando నిల్వ ప్యాక్‌ల సమితిని ఎంచుకుంటుంది. ఈ కార్యకలాపానికి $O(\log \Delta)$ మెటాడేటా పఠనాలు అవసరం. ఇక్కడ $\Delta$ అనేది క్లయింట్ వద్ద ఉన్నదానికీ, దానికి కావాల్సినదానికీ మధ్య రెఫ్ వెర్షన్‌లలో అతి తక్కువ దూరం. సర్వర్ ప్యాక్‌ఫైల్ URIలను అందిస్తుంది. ప్రాంతీయ క్యాష్‌లలో ప్యాక్‌ఫైళ్లను నిల్వ చేసే Express సేవ ద్వారా క్లయింట్ వాటిని డౌన్‌లోడ్ చేసుకుంటుంది.

ఈ రూపకల్పన Pando నిర్మాణంలోని మూడు ప్రధాన సేవలపై ఆధారపడుతుంది: పుష్‌లు, ఫెచ్‌లు, ప్యాక్‌ల సంకోచనం.

క్లయింట్ పుష్ చేసినప్పుడు, సంప్రదాయ Git సర్వర్ తన పేకముక్కలన్నీ చూపించే పోకర్ ఆటగాడిలా, తన వద్ద ఉన్న ప్రతి శాఖనూ క్లయింట్‌కు వెల్లడిస్తుంది. తర్వాత క్లయింట్ కమిట్‌లు, ట్రీలు, బ్లాబ్‌లను సేకరించి, సర్వర్ వద్ద ఇప్పటికే ఉన్నాయని తెలిసిన ఆబ్జెక్టులను మినహాయించే ప్యాక్‌ఫైల్‌ను తయారుచేస్తుంది.

మరిన్ని రెఫ్‌లను ప్రకటించడం వల్ల పుష్ పరిమాణం తగ్గవచ్చు. కానీ దానివల్ల ప్యాక్‌ను తిరిగి ఉపయోగించడం కష్టమవచ్చు. ఎందుకంటే రైటర్ మినహాయించిన ఆబ్జెక్టులు మరో క్లయింట్ వద్ద లేకపోవచ్చు.

Pando భిన్నమైన విధానాన్ని అనుసరిస్తుంది. తన వద్ద ఉన్నవన్నీ చూపించే బదులు, ఎంచుకున్న కొన్ని శాఖలను మాత్రమే క్లయింట్‌కు ప్రకటిస్తుంది. దీనికి రెండు కారణాలున్నాయి:

1. ప్రతి రెఫ్‌కు ఏకరూప స్థితిని అందించడం అధిక వనరులు అవసరమయ్యే పని. లక్షలాది శాఖలున్నప్పుడు రెఫ్‌ల ప్రకటన ఒక్కటే 100 MiB దాటవచ్చు. దీన్ని అందించాలంటే ప్రతి సర్వర్ తాజా మ్యాపింగ్‌ను నిర్వహించాలి; దీనికి భారీ సమన్వయ భారం ఉంటుంది. లేదా రెఫ్‌ల సంఖ్యతోపాటు పెరిగే డేటాబేస్ క్వెరీని అమలు చేయాలి.

2. రెఫ్‌లలో కొన్నింటినే క్లయింట్‌కు అందిస్తే, సర్వర్ స్పష్టంగా మినహాయించడానికి అనుమతించిన వాటిపైనే ఆధారపడే ప్యాక్‌ను క్లయింట్ తయారుచేస్తుంది. ఈ ఆధారాలను నమోదు చేయడం వల్ల, ఒక పుష్‌లో క్లయింట్ సృష్టించిన ప్యాక్‌ఫైల్‌ను తర్వాతి ఫెచ్‌కు ప్రతిస్పందనగా అందిస్తూ Pando తిరిగి ఉపయోగించగలదు.

Git సర్వర్ మరిన్ని రెఫ్‌లను ప్రకటించే కొద్దీ, పుష్ చేసే క్లయింట్లకు ఆబ్జెక్టులను మినహాయించడానికి మరిన్ని ఆధారాలు లభిస్తాయి. దీంతో చిన్న ప్యాక్‌లను తయారుచేయగలవు. అయితే ఈ ప్యాక్‌ఫైళ్లను తిరిగి ఉపయోగించాలంటే, ఫెచ్ చేసే క్లయింట్ల వద్ద ప్రతి ఆధారం ఉందని సర్వర్ నిర్ధారించగలగాలి. లేకపోతే క్లయింట్‌కు అవసరమైన ఆబ్జెక్టులు ప్యాక్‌ఫైల్‌లో లేకపోవచ్చు.

మరోవైపు, Git సర్వర్ ఏ రెఫ్‌నూ ప్రకటించకపోతే, క్లయింట్ రిపోజిటరీ పూర్తి చరిత్రతో ప్యాక్‌ఫైల్‌ను తయారుచేస్తుంది. ఆ ప్యాక్‌ఫైల్‌ను ఏ ఇతర క్లయింట్ అయినా ఉపయోగించవచ్చు. కానీ ఏ శాఖను పొందాలన్నా దాదాపు పూర్తి క్లోన్ చేయాల్సి రావడం భారీ వ్యయానికి దారితీస్తుంది.

అప్రమేయంగా, క్లయింట్ కొత్త ఫీచర్ శాఖను పుష్ చేసినప్పుడు, Pando ఒక నిర్దేశిత ప్రధాన శాఖను మాత్రమే ఆధారంగా ప్రకటిస్తుంది. దీంతో రిపోజిటరీలో శాఖలు పెరిగినా ప్రకటన పరిమాణం మారదు. అయితే కొన్ని పరిమితులను అంగీకరించాలి. ఇంజినీర్ ఒకే శాఖకు అనేకసార్లు పుష్ చేసినా, ఒక ఫీచర్ శాఖపై మరొకటి నిర్మించినా, ప్రధాన శాఖకు బయట ఉన్న ప్రతిదాన్నీ క్లయింట్ మళ్లీ పంపాలి.

దీంతో వరుస శాఖ పుష్‌లు పెద్దవవుతాయి. వాటిలో అనవసరంగా పునరావృతమయ్యే ఆబ్జెక్టులు ఉండవచ్చు; క్లయింట్ బ్యాండ్‌విడ్త్ అదనంగా వినియోగమవుతుంది. మా మోనోరిపోలో ఇలా తయారైన ప్యాక్‌ఫైళ్ల మధ్యస్థ పరిమాణం 20 KiB లోపు, 99వ శతాంశక పరిమాణం 3 MiB లోపు ఉంది. ఇది మాకు సముచితమైన రాజీగా అనిపించింది. ఎందుకంటే ప్రకటించిన ప్రధాన శాఖ చరిత్ర ఇప్పటికే ఉన్న రీడర్, ఆ ఒక్క ప్యాక్‌ఫైల్‌తోనే శాఖను పొందగలదు.

క్లయింట్‌కు ప్రకటించాల్సిన రెఫ్‌ల సమితిని ఎంచుకున్న తర్వాత, Pando పుష్‌ను అంగీకరించి తన మెటాడేటా నిల్వను నవీకరిస్తుంది. మెటాడేటా నవీకరణను Pando తక్షణ, అసమకాలిక భాగాలుగా విభజిస్తుంది. తక్షణ మెటాడేటా నవీకరణ వల్ల క్లయింట్లు కొత్తగా నవీకరించిన కమిట్‌ను వెంటనే పొందగలవు. ఇది కొత్త రెఫ్ వెర్షన్‌ను రాసి, రెఫ్ పాయింటర్ మ్యాపింగ్‌ను ఆ వెర్షన్‌కు నవీకరిస్తుంది. కొత్త చివరి కమిట్, ప్యాక్‌ఫైల్ సంప్రదింపులకు ఉపయోగించిన ఆధారాలు, పుష్ చేసిన ప్యాక్‌ఫైల్ లింక్ అందులో నిల్వ ఉంటాయి.

అదే సమయంలో ప్యాక్ సంకోచనాన్ని షెడ్యూల్ చేయడం వంటి అసమకాలిక పని కూడా అదే లావాదేవీలో నమోదవుతుంది. చాలా పెద్ద పుష్‌ల విషయంలో కొన్ని కమిట్‌లను మాత్రమే తక్షణంగా రాస్తారు. దీంతో పుష్ ఎంత పెద్దదైనా, మెటాడేటా నిల్వకు స్థిర సంఖ్యలో పఠనాలు, రాతలు మాత్రమే అవసరమవుతాయి.

ముఖ్యంగా, సంబంధం లేని రెఫ్‌ల పుష్‌లను Pando సర్వర్లు స్వతంత్రంగా అంగీకరించగలవు. పోటీ తలెత్తే ఏకైక కీ రెఫ్ పాయింటర్. పోల్చి మార్చే చర్యలాంటి విడదీయలేని కార్యకలాపంతో మేం దాన్ని కాపాడుతాం. Pando సర్వర్లు, మెటాడేటా నిల్వ విస్తరణ యూనిట్లు లేదా బ్లాబ్ నిల్వలను జోడించడం ద్వారా రాత థ్రూపుట్‌ను పెంచవచ్చు.

క్లయింట్ ఫెచ్ చేసినప్పుడు, సర్వర్‌కు రెండు కమిట్ గుర్తింపుల సమితులను అందిస్తుంది. ప్రోటోకాల్‌లో వీటిని have, want సమితులుగా పిలుస్తారు. సంప్రదాయ Git సర్వర్‌లో, ఉన్న కమిట్‌ల నుంచి చేరుకోగల ఆబ్జెక్టులకూ, కావాల్సిన కమిట్‌ల నుంచి చేరుకోగల ఆబ్జెక్టులకూ మధ్య సమితి తేడాను సర్వర్ లెక్కిస్తుంది. వాటిని సంకోచించి ఫలితాన్ని క్లయింట్‌కు పంపుతుంది. ఈ పనిని వేగవంతం చేయడానికి ఓపెన్ సోర్స్ Git సర్వర్‌లో స్థానికంగా పలు సూచికలు ఉన్నా, ఈ ప్యాక్‌ఫైళ్ల తయారీకి ఎక్కువ గణన అవసరం కావచ్చు. సాధారణంగా వీటిని క్యాష్ చేయడం కూడా కష్టం.

బదులుగా, పుష్‌ల సమయంలో నమోదైన కమిట్ మ్యాపింగ్‌లతో క్లయింట్ have, want సమితులను Pando వెతుకుతుంది. వాటిని ఆ కమిట్‌లు ఉన్న రెఫ్ వెర్షన్‌ల సమితికి అనుసంధానిస్తుంది. ఆ రెఫ్ వెర్షన్‌లలో ప్రతి ఒక్కటి Pando గతంలో స్వీకరించిన ప్యాక్‌ఫైల్‌కు లింక్ అవుతుంది. దీన్ని ఉపయోగించి క్లయింట్‌కు ఏమి కావాలో సర్వర్ నిర్ణయించి, అవసరమైన ఆబ్జెక్టుల సమితిని అందించే ప్యాక్‌ఫైళ్లను ఎంచుకుంటుంది.

క్లోన్ లేదా ఫెచ్ సమయంలో HTTP ప్రతిస్పందనలో ఒకే ప్యాక్‌ఫైల్‌ను పంపడానికి Git ప్రోటోకాల్ అనుమతిస్తుంది. అయితే Git ప్రోటోకాల్‌లో అంతగా గుర్తింపు పొందని packfile-uri సదుపాయం ద్వారా అదనపు ప్యాక్‌లను విడిగా డౌన్‌లోడ్ చేసుకునే లింక్‌లను సర్వర్ అందించవచ్చు. Pando దీన్నే ఉపయోగిస్తుంది; ప్రతిస్పందనలో ఖాళీ ప్యాక్‌ఫైల్‌ను పంపుతుంది. ఈ సదుపాయానికి మద్దతుగా, packfile-uriకు పలు మెరుగుదలలను OpenAI ప్రధాన Git ప్రాజెక్టుకు అందించింది.

OpenAI వ్యవస్థలు అనేక భౌగోళిక ప్రాంతాల్లో పనిచేస్తాయి. అందుకే ప్రతి ప్రాంతంలో స్థానిక క్యాష్‌లతో Pando క్లస్టర్‌లను నిర్వహిస్తున్నాం. Express అనే ప్యాక్ పంపిణీ సేవ మా బ్లాబ్ నిల్వను క్యాష్ చేస్తుంది. మరో సేవ మెటాడేటా నిల్వను క్యాష్ చేస్తుంది. ఈ క్యాష్‌ల వల్ల కమిట్ గుర్తింపు అభ్యర్థనలకు లేదా ప్రత్యేక రెఫ్ పఠనానికి ఆ క్లస్టర్‌లో క్యాష్ చేసిన స్థితి నుంచే Pando పూర్తిగా సేవలందించగలదు. ప్యాక్‌ఫైల్ అభ్యర్థనలను Express సర్వర్లకు పంపేందుకు స్థిర హ్యాషింగ్‌ను ఉపయోగిస్తాం. క్యాష్‌లోనే డేటా దొరికే శాతం 99% కంటే ఎక్కువ.

ఈ క్యాష్ వ్యవస్థ అత్యధిక థ్రూపుట్‌ను అందించి, క్లయింట్లు–Pando మధ్య నెట్‌వర్క్ సామర్థ్యాన్ని పూర్తిగా ఉపయోగించగలదు. ఈ ప్యాక్‌ఫైల్ URIలు, స్థానిక క్యాష్‌లతో, క్లౌడ్ ప్రొవైడర్ల సాధారణ వర్చువల్ యంత్రాలను మాత్రమే ఉపయోగించినా క్లోన్, ఫెచ్ కార్యకలాపాలు 10 Gbps నెట్‌వర్క్ లింక్‌లను పూర్తిగా వినియోగించగలవని ధ్రువీకరించాం.

చాలా Git సర్వర్లలో, పెరుగుతున్న రిపోజిటరీ పనితీరును నిలబెట్టేందుకు తిరిగి ప్యాక్ చేయడం, పనికిరాని డేటాను తొలగించడం అవసరం. ఈ రెండు చర్యలూ నిల్వ స్థలాన్ని తిరిగి అందుబాటులోకి తెస్తాయి. కానీ గణన, ఇన్‌పుట్/అవుట్‌పుట్ వనరులను అధికంగా వినియోగిస్తాయి.

OpenAI మోనోరిపోలా వేగంగా మారే రిపోజిటరీలో, గత ఫెచ్ తర్వాత జరిగిన ప్రతి పుష్‌కూ ప్రత్యేక ప్యాక్‌ఫైల్ URI పంపడం ఆచరణ సాధ్యం కాదు. ప్రధాన శాఖను తాజాగా ఉంచుకోవడానికి క్లయింట్ ప్రతిరోజూ పదివేల సంఖ్యలో ప్యాక్‌ఫైళ్లను డౌన్‌లోడ్ చేసుకోవాల్సి ఉంటుంది.

బదులుగా, ఈ అదనపు భారాన్ని తగ్గించేందుకు Pando నేపథ్యంలో ప్యాక్‌లను కలుపుతుంది. ఇందుకు లాగ్ ఆధారిత విలీన ట్రీలలోని సంకోచనం తరహా రూపకల్పనను అనుసరిస్తుంది. ప్రతి పుష్ “L0” ప్యాక్‌ఫైల్‌గా Pando పిలిచే ఫైల్‌ను తయారుచేస్తుంది. ఇది Pando పంపగల అతి చిన్న డేటా యూనిట్. కాలక్రమేణా, నేపథ్య వర్కర్లు ఈ ప్యాక్‌ఫైళ్లను రెఫ్ వెర్షన్‌ల క్రమాన్ని కవర్ చేసే సమూహాలుగా సేకరిస్తాయి. ఇవి L0 నుంచి గుణోత్తర క్రమంలో పెరుగుతాయి. ప్రస్తుతం మా మోనోరిపో L4 వరకు ప్యాక్‌ఫైల్ కవర్‌లను ఉపయోగిస్తోంది.

ఈ కవర్‌లకు రెండు ప్రయోజనాలున్నాయి. కవర్ తగినంత నిండిన తర్వాత, సంకోచన వర్కర్ దాని బాధ్యత తీసుకుని ఒకే ప్యాక్‌ఫైల్‌ను తయారుచేస్తుంది. ప్యాక్‌ఫైల్‌లోని ఆబ్జెక్టులను పునర్వ్యవస్థీకరించడం ద్వారా ఇది సంకోచన నిష్పత్తిని మెరుగుపరుస్తుంది. రెఫ్ వెర్షన్‌లపై స్కిప్ లిస్ట్‌గా పనిచేయడం వల్ల ఫెచ్ సంప్రదింపుల పనితీరును కూడా మెరుగుపరుస్తుంది. ప్రతి స్థాయిలోని సూచికలను ఏకకాలంలో పరిశీలించి, క్లయింట్‌కు పంపాల్సిన ప్యాక్‌ల సమితిని Pando సంవర్గమాన సమయ సంక్లిష్టతతో ఎంచుకోగలదు. తిరిగి ప్యాక్ చేసినా చేయకపోయినా, ఈ ప్యాక్‌ఫైల్ కవర్‌లు ఫెచ్ ప్రణాళికకు మరింత సమర్థ పరిష్కారాన్ని అందిస్తాయి. దీంతో Pandoపై థ్రూపుట్, ఆలస్య అవసరాల భారం తగ్గుతుంది.

అనేక Git సర్వర్లకు భిన్నంగా, ఇక్కడ ప్రతి స్థాయిలో ప్యాక్‌ఫైళ్లను నిలిపి ఉంచుతారు; విస్మరించరు లేదా పనికిరాని డేటాగా తొలగించరు. ఫెచ్‌లో క్లయింట్లు ఇచ్చే have, want సమితుల ఆధారంగా, ప్రతి స్థాయిలోని ప్యాక్‌లు నిరంతరం సేవలందించడానికి ఉపయోగపడతాయి. Pandoను APIగా ఉపయోగించే క్లయింట్లకు, ప్యాక్‌ఫైల్‌లోని ఏదైనా ఆబ్జెక్టును చదవడానికి సాధారణంగా L4 కంటే L0 నుంచి తక్కువ డేటా చదివితే సరిపోతుంది. ఎందుకంటే L0లో అది సంకోచించి ఉండే అవకాశం తక్కువ.

Pandoలో సంకోచనం క్లయింట్లకు పంపే మొత్తం డేటా పరిమాణాన్ని గణనీయంగా తగ్గిస్తుంది. క్లయింట్ ఎంత వెనుకబడిందో దానికంటే తక్కువ నిష్పత్తిలో ప్యాక్ ప్రణాళిక భారం పెరిగేలా కూడా చేస్తుంది. పెద్దవైన, వేగంగా మారే రిపోజిటరీలకు ఇది మరీ ముఖ్యమైనది. సాఫ్ట్‌వేర్ అభివృద్ధిలో ఇలాంటి రిపోజిటరీలు సాధారణంగా మారతాయని మేం భావిస్తున్నాం.

Codexతో Pandoను నిర్మించి, ప్రారంభం నుంచి వాస్తవ వినియోగం వరకు కేవలం 10 వారాల్లో చేరుకున్నాం. Pando మూల నిర్మాణాన్ని ఒక్క ఇంజినీర్ రూపొందించారు, ఏజెంట్ బృందాలు అమలు చేశాయి, కొద్దిమంది ఇంజినీర్లు వినియోగంలోకి తెచ్చారు. ఈ ఏడాది ఏప్రిల్‌లో Pando వాస్తవ వినియోగ ట్రాఫిక్‌కు సేవలందించడం ప్రారంభించింది. OpenAIలో ఉపయోగించే విస్తృత మూలకోడ్ నియంత్రణ నిర్వహణ సాధనాల వ్యవస్థలో ఇది ఒక భాగం.

Pando రూపకల్పనను ధ్రువీకరించేటప్పుడు అనేక రకాల విధానాలను అనుసరించాం. మరింత సురక్షితమైన సాఫ్ట్‌వేర్ పునాదులను నిర్మించడానికి⁠ మా సూత్రాలను వర్తింపజేశాం. ఇది కొత్తగా ప్రారంభించిన ప్రాజెక్టు కాబట్టి, పాత వ్యవస్థలపై ఆధారపడకుండా Rustలో Pandoను అమలు చేయాలని ఎంచుకున్నాం. ఏజెంట్లు తమ మార్పులను ప్రామాణిక Git ప్రవర్తనతో పోల్చి పరీక్షించేందుకు అనుగుణత పరీక్షల సముదాయాన్ని రాశాం. వ్యవస్థలో మారకూడని నియమాలు, లక్షణాలను తనిఖీ చేసేందుకు నిర్ణీత ఫలితాల అనుకరణ పరీక్షా వ్యవస్థలనూ అభివృద్ధి చేశాం. దీంతో సంప్రదింపులు, ప్యాక్ ప్రణాళికలో సూక్ష్మమైన ఏకకాల అమలు ఘర్షణలు, తిరిగి తలెత్తిన లోపాలను గుర్తించి తగ్గించగలిగాం.

ఈ వ్యవస్థ నిర్మాణానికి అనేక మోడళ్లు తోడ్పడ్డాయి. కొత్త మోడళ్లు అందుబాటులోకి వచ్చిన కొద్దీ, Pando పనితీరు, విశ్వసనీయతను మెరుగుపరచేందుకు వాటిని ఉపయోగించాం. GPT‑6 Astraను ఉపయోగించి, ఏజెంట్లు “Pando సిద్ధాంతాన్ని” గణితపరంగా నిర్దేశించేందుకు Lean, TLA+లో రాశాయి. అమలులోని లోపాలను గుర్తించి సరిచేయడానికి, వ్యవస్థ లక్షణాలను నిరూపించడానికి దాన్ని ఉపయోగించాం. Pandoలో అరుదైన పరిస్థితుల లోపాలను గుర్తించి సరిచేస్తూ, అనేక నిరంతర సెషన్‌లు వందల గంటలు నడిచాయి. Daybreak సామర్థ్యమున్న మోడళ్లతో Git, Pandoపై దాడి దృక్కోణంలో భద్రతా పరీక్షలు చేయడానికి ఏజెంట్లను నిరంతరం నడుపుతున్నాం.

మొదట Pandoను మా ప్రస్తుత మూలకోడ్ నియంత్రణ వ్యవస్థకు పఠనాలు, రాతలను పంపే మధ్యవర్తి ప్రాక్సీగా ప్రవేశపెట్టాం. దీనివల్ల Pando, పాత వ్యవస్థ సమకాలీకరణలో ఉండేవి. సేవలకు అంతరాయం లేకుండా ట్రాఫిక్‌ను సురక్షితంగా Pandoకు మళ్లించగలిగాం.

క్యాషింగ్ రూపకల్పనలో భాగంగా, Pando ప్రాక్సీ ద్వారా పంపే ముందు పునరావృత అభ్యర్థనలను తొలగించి, అభ్యర్థనలను కలపగలదు. వ్యవస్థలను ఒక్కొక్కటిగా Pandoకు మార్చేటప్పుడు, మా ప్రస్తుత సాధనాలు సజావుగా పనిచేయడానికి ఇది తోడ్పడింది. మరిన్ని పనిభారాలను Pandoకు మార్చిన కొద్దీ, వాటి పుష్‌లు Pando క్యాష్‌ను నింపి, మా పాత బ్యాకెండ్ విశ్వసనీయతను మెరుగుపరిచాయి.

Pando ఉపయోగంలో పనితీరును మెరుగుపరిచేందుకు, మా బహిరంగ Git పంపిణీని డెవలపర్ల యంత్రాలకు, ChatGPT డెస్క్‌టాప్ యాప్‌లో అందించడం ప్రారంభించాం. క్లయింట్లను దశలవారీగా Pandoకు మార్చడానికి, Git కమాండ్ లైన్ ఇంటర్‌ఫేస్ చుట్టూ అంతర్గత ర్యాపర్‌ను ఉపయోగించాం. మార్పు అభ్యర్థనలు, కోడ్ సమీక్ష, స్వయంచాలక పనుల కోసం APIలను నిర్వహించేందుకు మరెన్నో సాధనాలను తయారుచేశాం. Git ట్రాఫిక్‌తోపాటు పాత APIలు, వెబ్‌హుక్‌లు, రిపోజిటరీ డౌన్‌లోడ్‌లపై ఆధారపడిన వందలాది అనుసంధానాలను మార్చాం.

ఈ మార్పులో డెవలపర్లు, బృందాలకు Codex స్వయంగా సహాయపడింది. ప్రస్తుత చెకౌట్‌లను సిద్ధం చేయడానికి, కొత్త వ్యవస్థను ఉపయోగించేలా ఏజెంట్లకు మార్గనిర్దేశం చేయడానికి నైపుణ్యాలను సృష్టించాం. దీంతో డెవలపర్లు తమ అభివృద్ధి వాతావరణాలు, సేవలను మార్చమని Codexను అడిగితే సరిపోయింది.

Pandoకు మారడం వల్ల విలీన విశ్వసనీయత మెరుగుపడింది. మధ్యస్థ పుష్ ఆలస్యం దాదాపు 80% తగ్గింది.

కేవలం కొన్ని ప్రాసెసర్ కోర్‌లతో Pando రోజుకు ఒక పెటాబైట్ Git డేటాను అందించగలదు. Pando ఒక్క గంటలో 57 టెరాబైట్లకు పైగా Git ప్యాక్‌లను అందించింది. ఆ బైట్‌లలో 99% కంటే ఎక్కువ స్థానిక డిస్క్ క్యాష్ నుంచే వచ్చాయి.

ప్యాక్‌లను తిరిగి ఉపయోగించడం వల్ల, సేవలందించే నోడ్‌లపై అతి తక్కువ గణనతో అనేక క్లయింట్లు ఒకే రిపోజిటరీ చరిత్రను డౌన్‌లోడ్ చేసుకోగలవు. ఈ ఉదాహరణ ఒక రిపోజిటరీని చూపినా, మరెన్నింటికో మద్దతిచ్చేలా Pandoను రూపొందించాం. డిమాండ్ పెరిగే కొద్దీ, డేటా పంపిణీని, Git సంప్రదింపులను స్వతంత్రంగా విస్తరించగలం.

Git ప్రోటోకాల్, క్లయింట్‌పై Pandoను నిర్మించడం వల్ల Gitలోని లోపాలను, దాని పనితీరును మెరుగుపరిచే అవకాశాలను గుర్తించగలిగాం.

ఉదాహరణకు, Pando పునర్వినియోగ ప్యాక్‌లను నేరుగా క్లయింట్లకు అందిస్తుంది. కాబట్టి వాటిని డౌన్‌లోడ్ చేసి సూచికలు రూపొందించడం వ్యవస్థను వేగంగా, విశ్వసనీయంగా చేయడంలో కీలకమైంది. ఆ పనిలో ఏకకాల డౌన్‌లోడ్‌లు, మధ్యలో ఆగిన బదిలీల తర్వాత శుభ్రపరచడం, ఇప్పటికే పూర్తయిన డౌన్‌లోడ్‌లను పునఃప్రారంభించడం వంటి అరుదైన పరిస్థితుల సమస్యలు బయటపడ్డాయి. ఆ అమలు మార్గాలను సరిచేసి, ఫెచ్ కోసం ప్రస్తుత ప్యాక్‌ను అంగీకరించేటప్పుడు ధ్రువీకరణలను జోడించాం. ఆ మార్పులను ప్రధాన Git ప్రాజెక్టుకు అందించాం.

సమయం, బ్యాండ్‌విడ్త్ ఎక్కడ ఖర్చవుతున్నాయో తెలుసుకోవడమూ అవసరమైంది. అందుకే packfile-uri డౌన్‌లోడ్‌లకు ట్రేసింగ్, ప్యాక్ తయారీకి బైట్ లెక్కలను జోడించాం. దీంతో నెమ్మదైన ఫెచ్‌లో సమయం ప్యాక్‌ల తయారీకా, బదిలీకా వెళుతోందో తెలుసుకోవడం సులభమైంది.

OpenAI Git బిల్డ్‌లో⁠(కొత్త విండోలో తెరుచుకుంటుంది), క్లయింట్ స్వతంత్ర ప్యాక్‌లను సమాంతరంగా డౌన్‌లోడ్ చేసి, సూచికలను రూపొందించగలదు. “స్పష్టంగా ఉన్నవిగా తెలిపిన కమిట్‌లు” అనే భావనను జోడించాం. దీంతో పుష్ చేసే క్లయింట్ తన ప్యాక్‌లో మినహాయించగల చరిత్రకు వేరుగా, శాఖ ప్రస్తుత చివరి కమిట్‌ను సర్వర్ ప్రకటించగలదు. Pandoలో దీనివల్ల క్లయింట్లు --force-with-leaseతో ఫీచర్ శాఖ మారలేదని తనిఖీ చేసి, ప్రధాన శాఖను మాత్రమే ఆధారంగా చేసుకుని ప్యాక్‌ను రూపొందించగలవు. ఆ ప్రధాన శాఖ చరిత్ర ఉన్న ఎవరైనా అదే ప్యాక్‌తో శాఖను పొందగలరు.

ఈ మెరుగుదలల్లో కొన్ని ఇప్పటికే ప్రధాన Gitలో ఉన్నాయి. మరెన్నో మా బహిరంగ రిపోజిటరీలో ఉన్నాయి. ఈ మెరుగుదలలు Pando వెలుపల కూడా ఉపయోగపడేలా Git సముదాయంతో కలిసి పనిచేయడం కొనసాగిస్తున్నాం. మా బహిరంగ ప్యాచ్ ట్రాకర్‌లో⁠(కొత్త విండోలో తెరుచుకుంటుంది) ఆ పని పురోగతిని చూడవచ్చు.

Git రిపోజిటరీలను విస్తరించే సంప్రదాయ పద్ధతులను పునరాలోచించడం ద్వారా, మా ఇంజినీర్లు, ఏజెంట్లు ఇప్పటికే ఉపయోగించే Git పనివిధానాలను మార్చకుండానే మోనోరిపోను విస్తరించడానికి Pando తోడ్పడుతుంది. మా మోనోరిపోలో Pando మరిన్ని పనులను సమాంతరంగా చేయడం సాధ్యం చేసింది. విలీన విశ్వసనీయతను మెరుగుపరిచి, కోడ్ మార్పులను ప్రచురించడానికి పట్టే సమయాన్ని తగ్గించింది. మోనోరిపోతోపాటు OpenAIలో Pandoకు ఇతర వినియోగాలనూ పరిశీలిస్తున్నాం. ఉమ్మడి Git రిపోజిటరీపై పెద్ద సంఖ్యలో ఏజెంట్లు కలిసి పనిచేయాల్సిన పనిభారాలు కూడా వీటిలో ఉన్నాయి.

ఇంజినీర్లు, ఏజెంట్లు మరింత సాఫ్ట్‌వేర్‌ను రూపొందిస్తున్న కొద్దీ, మూలకోడ్ నియంత్రణలో మాకు ఎదురైన పరిమితులు OpenAI వెలుపలి మరిన్ని బృందాలకూ ఎదురవుతాయి. Pandoను సాధ్యం చేసిన సాంకేతికతను మా వినియోగదారులతో పంచుకునే మార్గాలను ప్రస్తుతం అన్వేషిస్తున్నాం.

Git రిపోజిటరీల వినియోగదారులు, నిర్వాహకుల రెండు దశాబ్దాల అనుభవం ఆధారంగా Pando రూపొందింది. విస్తృతంగా Git వినియోగదారులకు ఉపయోగపడే మెరుగుదలలను పంచుకునేందుకు ఓపెన్ సోర్స్ Git సముదాయంతో కలిసి పనిచేస్తూ, Pandoను అభివృద్ధి చేయడం కొనసాగిస్తాం.