OpenAI-യിൽ Git വിപുലീകരിക്കുന്നു

കഴിഞ്ഞ വർഷം ഞങ്ങളുടെ മോണോറിപ്പോയുടെ വലുപ്പവും അതിന്മേലുള്ള ആവശ്യങ്ങളും അതിവേഗം വർധിച്ചു. Codex സാധ്യമാക്കുന്ന തോതിലുള്ള സമാന്തര ജോലി കൈകാര്യം ചെയ്യാൻ സോഴ്സ് നിയന്ത്രണ സംവിധാനം പുതുക്കേണ്ടതുണ്ടെന്ന് വ്യക്തമായി.

എൻജിനീയറിങ് ജോലികൾ തടസ്സപ്പെടുത്താതെയും ടീം Git ഉപയോഗിക്കുന്ന രീതി മാറ്റാതെയും, Git റിപ്പോസിറ്ററികൾക്കായി Pando എന്ന പുതിയ ബാക്കെൻഡ് ഞങ്ങൾ നിർമിച്ചു. OpenAI-യുടെ മോണോറിപ്പോയിലെ എല്ലാ വികസനപ്രവർത്തനങ്ങളും ഇപ്പോൾ Pando-യിലാണ് നടക്കുന്നത്. രണ്ട് വലിയ ലക്ഷ്യങ്ങൾക്കായാണ് Pando രൂപകൽപ്പന ചെയ്തത്: ഒന്നാമത്, അനേകം ബ്രാഞ്ചുകളിലേക്കുള്ള സമാന്തര പുഷുകൾക്കായി ഒപ്റ്റിമൈസ് ചെയ്ത, കൂടുതൽ യൂണിറ്റുകൾ ചേർത്ത് വിപുലീകരിക്കാവുന്ന എഴുത്തുകൾ. രണ്ടാമത്, ലഭ്യമായ നെറ്റ്‌വർക്ക് ബാൻഡ്‌വിഡ്ത്ത് പൂർണമായി ഉപയോഗിക്കുന്ന വേഗത്തിൽ ക്ലയന്റുകൾക്ക് ഡാറ്റ ഡൗൺലോഡ് ചെയ്യാനായി വായനയുടെ ത്രൂപുട്ട് പരമാവധിയാക്കുക.

Git പ്രോട്ടോക്കോളും ക്ലയന്റുമായുള്ള അനുയോജ്യത നിലനിർത്തിക്കൊണ്ടാണ് ഈ ലക്ഷ്യങ്ങൾ കൈവരിച്ചത്. അതിനാൽ എൻജിനീയർമാർക്കും ഏജന്റുകൾക്കും നിലവിലെ പ്രവർത്തനക്രമങ്ങളിൽ Pando സുഗമമായി സ്വീകരിക്കാനായി. പ്രൊഡക്ഷനിൽ, പുഷ് കാലതാമസത്തിന്റെ മധ്യകമൂല്യം Pando ഏകദേശം അഞ്ചിലൊന്നാക്കി. ഇപ്പോൾ പ്രതിദിനം ഏകദേശം ഒരു പെറ്റാബൈറ്റ് Git ഡാറ്റ ഇത് നൽകുന്നു.

പുതിയ സോഴ്സ് നിയന്ത്രണ സംവിധാനം നിർമിക്കാനുള്ള പ്രേരണകളും Git അനുയോജ്യത നിലനിർത്താൻ തീരുമാനിച്ചതിന്റെ കാരണങ്ങളും ഇവിടെ വിശദീകരിക്കുന്നു. Git വിപുലീകരിക്കാനുള്ള പതിവ് സമീപനങ്ങളുമായി ഞങ്ങളുടെ സംവിധാനത്തെ താരതമ്യം ചെയ്ത്, OpenAI-യുടെ വളർച്ചാവശ്യങ്ങൾ നിറവേറ്റാൻ Pando-യ്ക്ക് സവിശേഷമായി കഴിയുന്നത് എന്തുകൊണ്ടെന്ന് വിശദീകരിക്കും. അടുത്ത ഘട്ടങ്ങളും ഏജന്റുകളുടെ പ്രവർത്തനത്തോത് പിന്തുണയ്ക്കാൻ Git-ലേക്ക് തുടർന്നും എങ്ങനെ സംഭാവന നൽകുമെന്നതും ചർച്ച ചെയ്യുന്നു.

Codex, OpenAI-യിലെ വികസനത്തിന്റെ തോതും വേഗവും മാറ്റി; എൻജിനീയർമാർക്ക് കൂടുതൽ ജോലികൾ സമാന്തരമായി ചെയ്യാനായി. ഇതിനർഥം കൂടുതൽ ബ്രാഞ്ചുകളും പുഷുകളും മെർജുകളും, വികസന പരിസരങ്ങൾ, ഗവേഷണ ജോലികൾ, CI എന്നിവയിൽനിന്ന് കൂടുതൽ ഫെച്ചുകളും ക്ലോണുകളും എന്നാണ്.

ഈ ആവശ്യങ്ങൾ പരസ്പരം പെരുകുന്നു. ഇപ്പോൾ ഒറ്റ എൻജിനീയർക്ക് ഒരേസമയം പല മാറ്റങ്ങളും CI-ക്കായി തയ്യാറുണ്ടാകും; ഓരോ പുഷും ഒരേ കമ്മിറ്റ് ഫെച്ച് ചെയ്യുന്ന പല ജോലികൾക്കും തുടക്കമിടാം.

കഴിഞ്ഞ വർഷാവസാനത്തോടെ മോണോറിപ്പോയെ പിന്തുണയ്ക്കുന്ന സംവിധാനങ്ങൾക്ക് ഈ വേഗത്തിനൊപ്പമെത്താൻ പ്രയാസമായി. മന്ദഗതിയിലുള്ള ഫെച്ചുകളും പുഷുകളും പരാജയപ്പെട്ട മെർജുകളും ഞങ്ങൾ നേരിട്ടു; വിശ്വാസ്യത ചിലപ്പോൾ 90%-ൽ താഴെയായി. Git-ന്റെ സ്വന്തം പരിധിയിലാണോ, അതോ മോണോറിപ്പോ ലഭ്യമാക്കുന്ന രീതിയുടെ പരിധിയിലാണോ ഞങ്ങൾ എത്തിയിരുന്നത്? കേർണൽ പാച്ചുകൾ ഇമെയിലിലൂടെ കൈമാറിയിരുന്ന ഒരു സമൂഹത്തിൽനിന്നാണ് Git വളർന്നത്. രണ്ട് പതിറ്റാണ്ടിലേറെയായി സോഫ്റ്റ്‌വെയർ നിർമാണരീതികൾ മാറിയപ്പോൾ, ഡെവലപ്പർമാർ Git-നെ അടിസ്ഥാനമാക്കി തങ്ങളുടെ ഉപകരണങ്ങളും മാറ്റിയെടുത്തു. സ്വന്തം മോണോറിപ്പോയിൽ തടസ്സങ്ങൾ അനുഭവപ്പെട്ടപ്പോൾ, ആ പ്രവർത്തനത്തെ അടിസ്ഥാനമാക്കി മുന്നോട്ടുപോകാനാകുക എന്നത് ഞങ്ങൾക്ക് പ്രധാനമായിരുന്നു.

വ്യത്യസ്ത ബ്രാഞ്ചുകളിലേക്കുള്ള പുഷുകൾ സമാന്തരമായി കൈകാര്യം ചെയ്യാനും ഒരേ ചരിത്രം പല വായനക്കാർക്കും ഒരേസമയം നൽകാനും ബാക്കെൻഡ് പുനർനിർമിച്ചുകൊണ്ട് പരിചിതമായ പ്രവർത്തനക്രമം നിലനിർത്താനുള്ള വഴി ഞങ്ങൾ കണ്ടെത്തി. സോഴ്സ് നിയന്ത്രണ പ്രവർത്തനക്രമത്തിന്റെ അടിത്തറയായി Git ഉപയോഗിച്ചതിനാൽ ക്ലയന്റിലെ മെച്ചപ്പെടുത്തലുകൾ OpenAI-ക്ക് പുറത്തും പ്രയോജനപ്പെടുമായിരുന്നു. ഞങ്ങളുടെ Git പകർപ്പിലെ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആ മെച്ചപ്പെടുത്തലുകൾ മുഖ്യ പ്രോജക്റ്റിലേക്ക് സംഭാവന ചെയ്ത് വിശാലമായ സമൂഹവുമായി പങ്കിടാനാണ് ഞങ്ങൾ ആഗ്രഹിച്ചത്.

സോഴ്സ് നിയന്ത്രണ സംവിധാനം വിപുലീകരിക്കുന്നതിന് രണ്ട് പ്രധാന വശങ്ങളുണ്ട്: വ്യത്യസ്ത ബ്രാഞ്ചുകളിലേക്ക് പുഷ് ചെയ്യുന്ന അനേകം എഴുത്തുകാരും ഒരേ ചരിത്രം ഫെച്ച് ചെയ്യുന്ന അനേകം വായനക്കാരും. രണ്ടിനും അനുയോജ്യമായാണ് Pando ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നത്.

ഒന്നാമതായി, ഓരോ ബ്രാഞ്ചിന്റെയും അപ്ഡേറ്റുകൾ Pando സ്വതന്ത്രമായി ഏകോപിപ്പിക്കുന്നു. ബന്ധമില്ലാത്ത ബ്രാഞ്ചുകളിലെ അപ്ഡേറ്റുകൾ സമാന്തരമായി നടക്കാം; ബ്രാഞ്ച് ഫെച്ച് ചെയ്യുന്ന വായനക്കാരന് ആ പതിപ്പിനാവശ്യമായ ചരിത്രം ലഭിക്കും. പകരമായി, പല ബ്രാഞ്ചുകളും പരിശോധിക്കുന്ന വായനക്കാരന് അവയുടെ വ്യത്യസ്ത സമയങ്ങളിലെ അവസ്ഥകൾ കാണേണ്ടിവരാം.

രണ്ടാമതായി, ഓരോ ക്ലയന്റിനും പ്രത്യേകം പാക്ക്ഫയൽ സൃഷ്ടിക്കുന്നതിനുപകരം Pando ഫെച്ചുകളിലുടനീളം പാക്ക്ഫയലുകൾ പുനരുപയോഗിക്കുന്നു. ഒന്നിലധികം ഒബ്ജക്റ്റുകൾ ഒരുമിച്ച് കംപ്രസ് ചെയ്യുന്ന Git ഫോർമാറ്റാണ് പാക്ക്ഫയൽ. ക്ലയന്റ് ഇതിനകം കൈവശമുള്ള ചില ഒബ്ജക്റ്റുകൾ ഡൗൺലോഡ് ചെയ്തേക്കാം; പക്ഷേ ചെറിയ കണക്കുകൂട്ടലിലൂടെ സെർവറിന് ഒരേ ബൈറ്റുകൾ പല ക്ലയന്റുകൾക്കും നൽകാം.

ഈ തിരഞ്ഞെടുപ്പുകൾ ബ്രാഞ്ചുകളിലുടനീളമുള്ള എഴുത്തുകൾ വിപുലീകരിക്കാനും കാഷുകളിൽനിന്ന് വായനകൾ ലഭ്യമാക്കാനും സഹായിക്കുന്നു. ഇവ എങ്ങനെ ഒത്തുചേരുന്നുവെന്ന് മനസ്സിലാക്കാൻ, Git ചരിത്രം സംഭരിക്കുകയും കൈമാറുകയും ചെയ്യുന്ന രീതി നോക്കാം.

റിപ്പോസിറ്ററിയുടെ രണ്ട് ഭാഗങ്ങൾ Git സമന്വയത്തിൽ നിലനിർത്തണം: ഒബ്ജക്റ്റുകളും റഫറൻസുകളും.

ഫയലുകളുടെ സ്നാപ്ഷോട്ടുകളും അവയെ ബന്ധിപ്പിക്കുന്ന ചരിത്രവും ഒബ്ജക്റ്റുകളുടെ ഗ്രാഫായി Git റിപ്പോസിറ്ററി രേഖപ്പെടുത്തുന്നു. ഒരു ഒബ്ജക്റ്റ് ബ്ലോബ്, ട്രീ, കമ്മിറ്റ്, ടാഗ് എന്നിവയിലേതുമാകാം. ബ്ലോബുകൾ ഓരോ ഫയലിന്റെയും ഉള്ളടക്കം സൂക്ഷിക്കുന്നു; ട്രീകൾ പേരുകളെ ബ്ലോബുകളുമായോ മറ്റു ട്രീകളുമായോ ബന്ധിപ്പിച്ച് ഡയറക്ടറി ഘടന സൃഷ്ടിക്കുന്നു. കമ്മിറ്റുകൾ ഒരു റൂട്ട് ട്രീയിലേക്കും പൂജ്യമോ അതിലധികമോ പാരന്റ് കമ്മിറ്റുകളിലേക്കും ചൂണ്ടുന്നു. ഇവ റിപ്പോസിറ്ററിയുടെ ചരിത്രം രൂപപ്പെടുത്തുന്നു.

ഒബ്ജക്റ്റുകളുടെ തരവും ഉള്ളടക്കവും ചേർന്ന ഹാഷാണ് അവയെ തിരിച്ചറിയുന്നത്. ഒബ്ജക്റ്റുകൾ മാറ്റാനാകാത്തവയുമാണ്: മാറിയ ഫയൽ രേഖപ്പെടുത്തുമ്പോൾ പുതിയ ബ്ലോബ് സൃഷ്ടിക്കുന്നു; മാറാത്ത ഫയലുകൾക്കും ഡയറക്ടറികൾക്കും നിലവിലെ ഒബ്ജക്റ്റുകൾ പുനരുപയോഗിക്കാം.

കമ്മിറ്റുകളിലേക്ക് ചൂണ്ടുന്ന റഫറൻസുകളാണ്, അഥവാ “റെഫുകളാണ്”, ബ്രാഞ്ചുകളും ടാഗുകളും. ബ്രാഞ്ചിൽ കമ്മിറ്റ് ചെയ്യുമ്പോൾ പുതിയ കമ്മിറ്റ് സൃഷ്ടിക്കുകയും അതിലേക്ക് ചൂണ്ടാൻ ബ്രാഞ്ചിന്റെ റെഫ് അപ്ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.

Git ഒബ്ജക്റ്റുകൾ “വേറിട്ട” അല്ലെങ്കിൽ “പാക്ക് ചെയ്ത” നിലയിൽ സംഭരിക്കുന്നു. വേറിട്ട ഒബ്ജക്റ്റുകൾ അവയുടെ ഒബ്ജക്റ്റ് ഐഡി ഉപയോഗിച്ച് തിരിച്ചറിയുന്ന പ്രത്യേക ഫയലുകളിൽ സൂക്ഷിക്കുന്നു. പാക്ക് ചെയ്ത ഒബ്ജക്റ്റുകൾ ഒരു പാക്ക്ഫയലിൽ ഒരുമിച്ച് സൂക്ഷിക്കുന്നു. ഇതിലൂടെ സമാന ഒബ്ജക്റ്റുകളെ പരസ്പരമുള്ള വ്യത്യാസങ്ങളായി സംഭരിക്കാം.

ഒരു കമ്മിറ്റിൽനിന്ന് അതിന്റെ പാരന്റുകൾ, ട്രീകൾ, ബ്ലോബുകൾ എന്നിവയിലൂടെയുള്ള ലിങ്കുകൾ പിന്തുടർന്ന് Git-ന് ഒബ്ജക്റ്റ് കണ്ടെത്താനാകുമെങ്കിൽ, അതിനെ ആ കമ്മിറ്റിൽനിന്ന് എത്തിച്ചേരാവുന്നത് എന്നു പറയുന്നു. ഫെച്ചിനിടെ, ഏതെല്ലാം കമ്മിറ്റുകൾ വേണമെന്നും ഏതെല്ലാം കൈവശമുണ്ടെന്നും ക്ലയന്റ് സെർവറിനെ അറിയിക്കുന്നു. ആവശ്യമുള്ള കമ്മിറ്റുകളിൽ നിന്ന് ലഭ്യമാകുന്ന ഒബ്ജക്റ്റുകൾ സെർവർ കണ്ടെത്തുകയും ക്ലയന്റിന്റെ കൈവശം ഇതിനകം ഉണ്ടെന്ന് സെർവർ അറിയുന്നവ ഒഴിവാക്കുകയും ബാക്കി ഭാഗങ്ങൾ ഡിസ്കിൽ Git ഉപയോഗിക്കുന്ന അതേ ഫോർമാറ്റിലുള്ള ഒരു പാക്ക് ഫയലായി അയയ്ച്ചു നൽകുകയും ചെയ്യുന്നു. ഒരു ഫുൾ ക്ലോൺ ആരംഭിക്കുന്നത് ഒബ്ജക്റ്റുകൾ ഒന്നും ഇല്ലാതെയാണ്, അതിനാൽ ക്ലോൺ ചെയ്യപ്പെടുന്ന ഹിസ്റ്ററിയിൽനിന്ന് ലഭ്യമാകുന്ന എല്ലാ ഒബ്ജക്റ്റുകളും അതിന് ആവശ്യമാണ്.

ഒരു പുഷ്, സെർവറിനോട് ഒന്നോ അതിലധികമോ റെഫറൻസുകൾ അപ്ഡേറ്റ് ചെയ്യാൻ ആവശ്യപ്പെട്ടുകൊണ്ട്, ഒബ്ജക്റ്റുകളെ വിപരീത ദിശയിലേക്ക് ട്രാൻസ്ഫർ ചെയ്യുന്നു. സെർവറിൽ ഇതിനകം തന്നെയുള്ള ഒബ്ജക്റ്റുകൾ വീണ്ടും അയയ്ക്കുന്നത് ഒഴിവാക്കാൻ, സെർവർ പരസ്യപ്പെടുത്തിയിട്ടുള്ള റെഫറൻസുകളുടെ ലിസ്റ്റാണ് ക്ലയന്റ് ഉപയോഗിക്കുന്നത്. അതുകൊണ്ട് തന്നെ, അയയ്ക്കുന്ന പാക്ക് നിലവിലുള്ള ഒബ്ജക്റ്റുകളെ ആശ്രയിച്ചായിരിക്കാം നിലകൊള്ളുന്നത്; പുതിയ ഹിസ്റ്ററി പുനർനിർമ്മിക്കാൻ ഈ പാക്ക് മാത്രം ലഭിച്ചതുകൊണ്ട് സാധ്യമാകില്ല.

ഒരു Git റിപ്പോസിറ്ററി പകർപ്പുകളായി നിലനിർത്തുക എന്നത്, ഒന്നിലധികം സെർവറുകളിൽ ഒബ്ജക്റ്റുകളും റഫറൻസുകളും ലഭ്യമാക്കുക എന്നാണ്. ഒരു റഫറൻസിന്റെ പുതിയ മൂല്യം ഒരു പകർപ്പിന് ലഭ്യമാക്കണമെങ്കിൽ, ആദ്യം ആ മൂല്യത്തിൽ നിന്നും എത്താവുന്ന ഒബ്ജക്റ്റുകൾ നൽകാൻ കഴിയണം. ഒരേസമയം വരുന്ന റഫറൻസ് അപ്ഡേറ്റുകളെ ഏകോപിപ്പിക്കേണ്ടതും ഈ സേവനത്തിന്റെ ആവശ്യമാണ്; അതായത്, ഒരേ പഴയ ടിപ്പിൽ നിന്നും ഒരേ ബ്രാഞ്ചിനെ വ്യത്യസ്തമായ പുതിയ കമ്മിറ്റുകളിലേക്ക് മാറ്റാൻ ശ്രമിക്കുന്ന പുഷുകളെ കൈകാര്യം ചെയ്യുക എന്നത്. ഒരു റിപ്പോസിറ്ററിയിലെ എല്ലാ റൈറ്റുകൾക്കും ഒരൊറ്റ ക്രമം നിർബന്ധമാക്കുന്ന സംവിധാനങ്ങളിൽ, പരസ്പര ബന്ധമില്ലാത്ത ബ്രാഞ്ചുകളിലേക്ക് നടക്കുന്ന പുഷുകൾക്ക് പോലും ഒന്നിനു പുറകെ ഒന്നായി കാത്തിരിക്കേണ്ടിവരാം.

Pando രൂപകൽപ്പന ചെയ്യുമ്പോൾ, Git ഉപയോഗിച്ചുള്ള സോഴ്സ് കൺട്രോൾ വിപുലീകരിക്കുന്നതിനുള്ള പരമ്പരാഗതമായ രണ്ട് രീതികൾ ഞങ്ങൾ വിലയിരുത്തുന്നു: അതിലൊന്ന്, ത്രീ-ഫേസ് കമ്മിറ്റ് (3 PC, ഒന്നിലധികം നോഡുകളിലുടനീളം ഒരു കമ്മിറ്റ് ഏകോപിപ്പിക്കാനുള്ള പ്രോട്ടോക്കോൾ) ഉപയോഗിച്ച് റിപ്പോസിറ്ററി പകർപ്പുകളിലുടനീളം റെഫ് അപ്ഡേറ്റുകളെ ഏകോപിപ്പിക്കുന്ന രീതിയാണ്. രണ്ടാമത്തേത്, ബ്ലോബ് സ്റ്റോറേജിലുള്ള ഒരു പങ്കിട്ട റൈറ്റ്-അഹെഡ്-ലോഗ് (WAL, മാറ്റങ്ങൾ വരുത്തുന്നതിന് തൊട്ടുമുമ്പ് അവ രേഖപ്പെടുത്തുന്ന സിസ്റ്റം) വഴി അപ്ഡേറ്റുകളെ കൃത്യമായ ക്രമത്തിലാക്കുന്ന രീതിയുമാണ്.

ഞങ്ങൾ മാതൃകയാക്കിയ ത്രീ-ഫേസ് കമ്മിറ്റ് രൂപകൽപ്പനയിൽ, Git സേവനം നിരവധി പകർപ്പുകളിൽ റിപ്പോസിറ്ററിയുടെ ഒരു പൂർണ്ണമായ കോപ്പി സൂക്ഷിക്കുന്നു. ഏതെങ്കിലും ഒരു സെർവറിലേക്ക് ഒരു പുഷ് വരുമ്പോൾ അതിലൊപ്പമുള്ള പാക്ക്ഫയൽ കോപ്പി ചെയ്യപ്പെടുകയും ഒരേസമയം എല്ലാ പകർപ്പുകളിലേക്കും സമാന്തരമായി അയയ്ക്കുകയും ചെയ്യും. ഈ പുഷ് പ്രസിദ്ധീകരിക്കണമെങ്കിൽ, ഭൂരിഭാഗം പകർപ്പുകളും ആ റെഫ് അപ്ഡേറ്റ് അംഗീകരിക്കേണ്ടതുണ്ട്. ഈ പ്രക്രിയ നിയന്ത്രിക്കുന്ന സെർവറാണ് കോർഡിനേറ്റർ. ഇതിനായി കോർഡിനേറ്ററും മറ്റ് പകർപ്പുകളും തമ്മിൽ പല തവണ ആശയവിനിമയം നടത്തേണ്ടത് ആവശ്യമാണ്.

ഒരു റഫറൻസ് അപ്ഡേറ്റ് സ്വീകരിക്കുന്നതിനായി, ഓരോ പകർപ്പും അതിന്റെ പക്കലുള്ള റെഫിന്റെ കോപ്പി ലോക്ക് ചെയ്യുകയും, ക്ലയന്റ് പ്രതീക്ഷിക്കുന്ന കമ്മിറ്റിലേക്ക് തന്നെയാണ് അതിപ്പോഴും പോയിന്റ് ചെയ്യുന്നതെന്ന് ഉറപ്പുവരുത്തുകയും ചെയ്യുന്നു. തുടർന്ന്, ഇത് അംഗീകരിക്കുന്ന പകർപ്പുകളിലേക്ക് കോർഡിനേറ്റർ ഒരു പ്രീകമ്മിറ്റ് സന്ദേശമയയ്ക്കുന്നു. ഭൂരിഭാഗം പകർപ്പുകളും ഈ പ്രീകമ്മിറ്റ് സന്ദേശം സ്വീകരിച്ചതായി സ്ഥിരീകരിച്ചുകഴിഞ്ഞാൽ അപ്ഡേറ്റ് നടപ്പിലാക്കാൻ കോർഡിനേറ്റർ അവരോട് ആവശ്യപ്പെടുന്നു. ഇതിന് ശേഷം, ഏറ്റവും പുതിയ വിവരങ്ങളുള്ള ഏത് പകർപ്പിനും റിപ്പോസിറ്ററിയുടെ ലോക്കൽ കോപ്പിയിൽ നിന്ന് പുതിയ ബ്രാഞ്ച് ടിപ്പ് പരസ്യപ്പെടുത്താൻ സാധിക്കും.

പൂർണ്ണമായ പകർപ്പുകൾ സൂക്ഷിക്കുന്നത് റീഡുകൾ ലോക്കലായി തന്നെ ലഭ്യമാക്കാൻ സഹായിക്കുന്നു, കൂടാതെ, ക്ലയന്റുകൾ ഏത് പകർപ്പ് തിരഞ്ഞെടുത്താലും എല്ലാ റഫറൻസുകളുടെയും കൃത്യവും സമാനവുമായ ഒരു രൂപം അവർക്ക് ലഭിക്കുമെന്ന് ഇത് ഉറപ്പുനൽകുന്നു. ഇതിന്റെ ഫലമായി, റഫറൻസുകൾ ഓരോന്നായി മാത്രമേ അപ്ഡേറ്റ് ചെയ്യപ്പെടുകയുള്ളൂ, കൂടാതെ പകർപ്പുകൾക്കിടയിൽ ഓരോ റെഫ് അപ്ഡേറ്റും കോർഡിനെറ്റ് ചെയ്യുന്നതിന് ഓരോ പുഷിനും ഒന്നിലധികം റൗണ്ട്-ട്രിപ്പുകൾ ആവശ്യമായി വരുകയും ചെയ്യുന്നു.

ആവശ്യമായ ഭൂരിപക്ഷത്തിനായി കാത്തുനിൽക്കേണ്ടി വരുന്നത് പുഷ് പാത്തിൽ റെപ്ലിക്ക ഡിസ്കിന്റെ പ്രകടനത്തെയും കമ്മ്യൂണിക്കേഷൻ ലേറ്റൻസിയെയും ബാധിക്കുന്നു. റൈറ്റ് വോള്യം വർദ്ധിക്കുന്നതിനനുസരിച്ച് പകർപ്പുകൾക്ക് റീഡ് അഭ്യർത്ഥനകൾക്കൊപ്പം തന്നെ ഇൻകമിംഗ് പാക്കുകളുടെ വേഗതയുമായും പൊരുത്തപ്പെട്ടു പോകേണ്ടതുണ്ട്.

ഞങ്ങൾ മാതൃകയാക്കിയ WAL അധിഷ്ഠിത രൂപകൽപ്പനയിൽ, റിപ്പോസിറ്ററിയാകെയുള്ള അപ്ഡേറ്റുകൾ ക്രമപ്പെടുത്താൻ Git സേവനം ബ്ലോബ് സംഭരണത്തിലെ പങ്കിട്ട മാനിഫെസ്റ്റ് ഉപയോഗിക്കുന്നു. ഒരു സെർവറിലേക്ക് ഒരു പുഷ് ലഭിക്കുമ്പോൾ, അത് ഇൻകമിംഗ് പാക്ക്ഫയലിനെ ഒരു ബ്ലോബ് സ്റ്റോറിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും റിപ്പോസിറ്ററിയുടെ സ്വന്തം ലോക്കൽ കോപ്പിയിൽ റെഫ് അപ്ഡേറ്റ് തയ്യാറാക്കുകയും ചെയ്യുന്നു. ഈ പുഷ് പ്രസിദ്ധീകരിക്കാൻ, ബ്ലോബ് സ്റ്റോറിൽ സൂക്ഷിച്ചിരിക്കുന്ന പങ്കിട്ട മാനിഫെസ്റ്റിലേക്ക് അത് ഒരു എൻട്രി ചേർക്കുന്നു; ഈ എൻട്രി റെഫ് അപ്ഡേറ്റ് രേഖപ്പെടുത്തുകയും ആ പാക്ക്ഫയലിലേക്ക് പോയിന്റ് ചെയ്യുകയും ചെയ്യുന്നു. തുടർന്ന് Git സെർവർ ഒരു കംപെയർ-ആൻഡ്-സ്വാപ്പ് ഓപ്പറേഷൻ ഉപയോഗിച്ച് ഈ മാനിഫെസ്റ്റ് അപ്ഡേറ്റ് ചെയ്യുന്നു. ഇത് മാനിഫെസ്റ്റിനെ അറ്റോമിക്കായി മാറ്റി സ്ഥാപിക്കുന്നു, അല്ലെങ്കിൽ മാറ്റത്തെ നിരസിക്കുന്നു. ഈ സമയത്തിനിടയിൽ മറ്റ് ഏതെങ്കിലുമൊരു റൈറ്റർ ഇത് അപ്ഡേറ്റ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, സെർവർ അതിനിടയിൽ വന്ന എൻട്രികൾ വായിക്കുകയും തന്റെ റെഫ് അപ്ഡേറ്റ് ഇപ്പോഴും സാധുവാണോ എന്ന് പരിശോധിക്കുകയും ഇതിനകം അപ്‌ലോഡ് ചെയ്ത പാക്ക്ഫയൽ ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കുകയും ചെയ്യുന്നു.

റൈറ്റേഴ്സിന് ഒരേസമയം അവരുടെ പാക്ക്ഫയലുകൾ സമാന്തരമായി അപ്‌ലോഡ് ചെയ്യാമെങ്കിലും പരസ്പര ബന്ധമില്ലാത്ത ബ്രാഞ്ചുകളിലേക്ക് നടക്കുന്ന പുഷുകൾക്കുപോലും ഒരേ മാനിഫെസ്റ്റ് തന്നെ അപ്ഡേറ്റ് ചെയ്യേണ്ടി വരുന്നു. ഒരു കംപയർ-ആൻഡ്-സ്വാപ്പ് പ്രക്രിയ വിജയകരമായി പൂർത്തിയാക്കാൻ എടുക്കുന്ന റൗണ്ട്-ട്രിപ്പ് സമയം ഒരു റിപ്പോസിറ്ററിക്ക് എത്രത്തോളം വേഗത്തിൽ പുതിയൊരു മാനിഫെസ്റ്റ് പ്രസിദ്ധീകരിക്കാൻ സാധിക്കും എന്നതിന് പരിധി നിശ്ചയിക്കുന്നു. ലേറ്റൻസി കുറഞ്ഞ ഒരു ബ്ലോബ് സ്റ്റോർ ഈ ഘട്ടത്തെ വേഗത്തിലാക്കാൻ സഹായിക്കും. ബാച്ചിംഗ് രീതി ഉപയോഗിക്കുന്നത് വഴി ഒരൊറ്റ മാനിഫെസ്റ്റ് അപ്ഡേറ്റിലൂടെ ഒരേസമയം ഒന്നിലധികം റഫറൻസുകൾ മാറ്റാൻ സാധിക്കും; എങ്കിലും, ഇത് അപ്ഡേറ്റുകളെ ക്യൂവിലാക്കുകയും ലേറ്റൻസി വർദ്ധിപ്പിക്കുകയും ചെയ്യും.

ബ്ലോബ് സ്റ്റോറിന് ഒരേസമയം ഒന്നിലധികം പാക്ക്ഫയലുകൾ സമാന്തരമായി സ്വീകരിക്കാൻ സാധിക്കുമെങ്കിലും പങ്കിട്ട മാനിഫെസ്റ്റിലേക്ക് വരുന്ന അപ്ഡേറ്റുകൾ ഇപ്പോഴും പരസ്പരം മത്സരിച്ചുകൊണ്ടിരിക്കുന്നു. ബ്ലോബ് സ്റ്റോറിന്റെ ശേഷി മാത്രം വർദ്ധിപ്പിച്ചതുകൊണ്ട് ഈ തടസ്സം പരിഹരിക്കാൻ കഴിയില്ല. ഓരോ പകർപ്പിനും വിവരങ്ങൾ ലോക്കലായി ലഭ്യമാക്കണമെങ്കിൽ, അതിന് മുമ്പ് ബ്ലോബ് സ്റ്റോറിൽ നിന്നുള്ള വാക്കുകൾ റീഡ് ചെയ്യാനും ഇൻഡക്സ് ചെയ്യാനും സാധിക്കണം. പുതുതായി വരുന്ന റൈറ്റുകളുടെ വേഗത ഈ പ്രക്രിയയേക്കാൾ കൂടുതലായാൽ, പകർപ്പുകൾ പിന്നിലാവുകയും ക്ലയന്റുകൾക്ക് പുതുതായി പുഷ് ചെയ്ത കമ്മിറ്റുകൾ ഫെച്ച് ചെയ്യാൻ കൂടുതൽ സമയം കാത്തിരിക്കേണ്ടിവരികയും ചെയ്യും.

ഇവിടെയാണ് Pando പ്രസക്തമാകുന്നത്. ഒരേസമയം നിരവധി ക്ലയന്റുകൾ പുഷ് ചെയ്യുന്ന സാഹചര്യത്തിലും കാര്യക്ഷമമായി പ്രവർത്തിക്കുക എന്ന ലക്ഷ്യത്തോടെ Git റിപ്പോസിറ്ററികൾ കൈകാര്യം ചെയ്യാൻ രൂപകൽപ്പന ചെയ്ത ഒരു പുതിയ നിർമ്മിതിയാണ് Pando. ഇത് എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്ന് താഴെ വിവരിക്കുന്നു:

Pando വികസിപ്പിക്കുന്നതിന് മുമ്പ് തന്നെ, Git-ന്റെ സവിശേഷതകളിൽ വിട്ടുവീഴ്ച ചെയ്യാതെ ഞങ്ങളുടെ ആവശ്യങ്ങൾ നിറവേറ്റാനാകുമെന്ന ഒരു തോന്നൽ ഞങ്ങൾക്ക് ഉണ്ടായിരിന്നു, എന്നാൽ ഭൂരിഭാഗം മറ്റ് സിസ്റ്റങ്ങളും നിർബന്ധമായും ഉണ്ടായിരിക്കണം എന്ന് കരുതുന്ന ചില കാര്യങ്ങളിൽ ഞങ്ങൾക്ക് വിട്ടുവീഴ്ച ചെയ്യേണ്ടി വന്നു:

• റിപ്പോസിറ്ററിയിലുടനീളമുള്ള സ്ഥിരത: എല്ലാ റെഫുകളുടെയും കൃത്യമായ ഒരു പോയിന്റ്-ഇൻ-ടൈം സ്നാപ്ഷോട്ട് നൽകുന്നതിന് റിപ്പോസിറ്ററിയിലുടനീളം ഏകോപനം വേണം. എല്ലാ റെഫ് അപ്ഡേറ്റുകളും ഒരുമിച്ച് ക്രമപ്പെടുത്തുന്ന സംവിധാനത്തിൽ, പരസ്പരം ബന്ധമില്ലാത്ത ബ്രാഞ്ചുകളിലേക്കുള്ള പുഷുകൾ പോലും ഒരൊറ്റ ഏകോപന കേന്ദ്രത്തിനായി പരസ്പരം മത്സരിക്കേണ്ടിവരുന്നു.

• ഓരോ ക്ലയന്റിനും പ്രത്യേക പാക്ക്ഫയലുകൾ: വ്യത്യസ്തമായ ലോക്കൽ ഹിസ്റ്ററിയുള്ള രണ്ട് ക്ലയന്റുകൾ ഒരേ ബ്രാഞ്ച് ഫെച്ച് ചെയ്യുമ്പോൾ, അവയ്ക്കുള്ള ഒബ്ജക്റ്റുകൾ വീണ്ടും അയയ്ക്കാതിരിക്കാൻ സെർവർ ഓരോന്നിനും വ്യത്യസ്ത പാക്ക് സൃഷ്ടിക്കേണ്ടിവരാം. ഈ പ്രതികരണങ്ങൾ സൃഷ്ടിക്കാൻ CPU-വും ഡിസ്ക് I/O-യും ആവശ്യമാണ്. അതിനാൽ ഉയർന്ന തോതിലുള്ള റീഡേഴ്സിനെ പിന്തുണയ്ക്കാൻ പ്രയാസമാണ്.

പകരം, റൈറ്റുകൾ കൂട്ടാൻ 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 ഈ രീതി മാത്രം ഉപയോഗിക്കുകയും പ്രതികരണത്തിനുള്ളിൽ ശൂന്യമായ പാക്ക്ഫയൽ അയയ്ക്കുകയും ചെയ്യുന്നു. ഈ സവിശേഷത പിന്തുണയ്ക്കാൻ OpenAI, packfile-uri-യിലെ നിരവധി മെച്ചപ്പെടുത്തലുകൾ മുഖ്യ പ്രോജക്റ്റിലേക്ക് സംഭാവന ചെയ്തു.

OpenAI-യുടെ സംവിധാനങ്ങൾ വ്യത്യസ്ത ഭൂമിശാസ്ത്ര മേഖലകളിൽ പ്രവർത്തിക്കുന്നതിനാൽ, ഞങ്ങൾ ഓരോ പ്രദേശത്തും ലോക്കൽ കാഷെകളുള്ള Pando ക്ലസ്റ്ററുകൾ നിലനിർത്തുന്നു. Express എന്ന പാക്ക് വിതരണ സേവനം ഞങ്ങളുടെ ബ്ലോബ് സ്റ്റോറിനെ കാഷെ ചെയ്യുന്നു; മറ്റൊരു പ്രത്യേക സേവനം മെറ്റാഡാറ്റ സ്റ്റോറിനെയും കാഷെ ചെയ്യുന്നുണ്ട്. ഈ കാഷെകൾ ഉള്ളതുകൊണ്ട് തന്നെ ഒരു കമ്മിറ്റ് ഐഡിക്കായുള്ള അഭ്യർത്ഥനകളോ ഒരു റെഫിന്റെ സ്പെഷ്യൽ റീഡ് അഭ്യർത്ഥനകളോ പൂർണ്ണമായും ആ ക്ലസ്റ്ററിലെ കാഷെ സ്റ്റേറ്റിൽ നിന്നുതന്നെ കൈകാര്യം ചെയ്യാൻ Pando-യ്ക്ക് സാധിക്കുന്നു. പാക്ക്ഫയലുകൾക്കായുള്ള അഭ്യർത്ഥനകൾ Express സെർവറുകളിലേക്ക് റൂട്ട് ചെയ്യുന്നതിനായി ഞങ്ങൾ കൺസിസ്റ്റന്റ് കാഷിംഗ് ഉപയോഗിക്കുന്നു: ഇതിലൂടെ 99%-ലധികം കാഷെ ഹിറ്റ് നിരക്കുകൾ ലഭിക്കാറുണ്ട്.

ക്ലയന്റുകൾക്കും Pando-യ്ക്കുമിടയിലെ നെറ്റ്‌വർക്ക് ശേഷി പൂർണമായി ഉപയോഗിക്കുന്നത്ര ഉയർന്ന ത്രൂപുട്ട് ഈ കാഷ് സംവിധാനം നൽകുന്നു. ഈ പാക്ക്ഫയൽ URI-കളും ലോക്കൽ കാഷുകളും ഉപയോഗിച്ച്, സാധാരണ ക്ലൗഡ് ദാതാക്കളുടെ വെർച്വൽ മെഷീനുകളിൽ മാത്രം പ്രവർത്തിക്കുമ്പോഴും ക്ലോൺ, ഫെച്ച് പ്രവർത്തനങ്ങൾ 10 Gbps നെറ്റ്‌വർക്ക് കണക്ഷനുകളുടെ പൂർണ ശേഷി ഉപയോഗിക്കുന്നുവെന്ന് ഞങ്ങൾ സ്ഥിരീകരിച്ചു.

വളരുന്ന റിപ്പോസിറ്ററിയുടെ പ്രകടനം നിലനിർത്താൻ മിക്ക Git സെർവറുകളിലും വീണ്ടും പാക്ക് ചെയ്യലും ഉപയോഗശൂന്യ ഡാറ്റ നീക്കലും ആവശ്യമാണ്. ഈ രണ്ട് പ്രക്രിയകളും സ്റ്റോറേജ് സ്പേസ് വീണ്ടെടുക്കാൻ സഹായിക്കുമെങ്കിലും ഇവയ്ക്ക് വലിയ തോതിൽ കമ്പ്യൂട്ട്, I/O എന്നിവ ആവശ്യമാണ്.

OpenAI-യുടെ മോണോറെപ്പോ പോലെ വളരെവേഗത്തിൽ മാറ്റങ്ങൾ സംഭവിച്ചുകൊണ്ടിരിക്കുന്ന ഒരു റിപ്പോസിറ്ററിയിൽ, അവസാനത്തെ ഫെച്ചിന് ശേഷം നടന്നിട്ടുള്ള ഓരോ പുഷിനും പ്രത്യേകം പ്രത്യേകം പാക്ക്ഫയൽ URI-കൾ അയയ്ക്കുക എന്നത് പ്രായോഗികമല്ല. ട്രങ്ക് പുതുക്കാൻ ക്ലയന്റിന് ദിവസവും പതിനായിരക്കണക്കിന് പാക്ക്ഫയലുകൾ ഡൗൺലോഡ് ചെയ്യേണ്ടിവരും.

പകരം, ഈ അധിക ഭാരം കുറയ്ക്കുന്നതിനായി Pando പശ്ചാത്തലത്തിൽ പാക്കുകൾ ഒരുമിച്ച് ചേർക്കുന്നു; ലോഗ് ഘടനയുള്ള മെർജ് ട്രീകളിലെ കമ്പാക്ഷന് സമാനമായ ഒരു രൂപകൽപ്പനയാണ് ഇതിനായി സ്വീകരിച്ചിരിക്കുന്നത്. ഓരോ പുഷും Pando “L0” പാക്ക്ഫയൽ എന്ന് വിളിക്കുന്ന ഒന്നാണ് ഉണ്ടാക്കുന്നത്; Pando-യ്ക്ക് കൈമാറാൻ കഴിയുന്ന ഏറ്റവും ചെറിയ ഡാറ്റ യൂണിറ്റാണിത്. കാലക്രമേണ, പശ്ചാത്തലത്തിലുള്ള വർക്കറുകൾ ഈ പാക്ക്ഫയലുകളെ ഒരു കൂട്ടം റെഫ് പതിപ്പുകളിലായി പരന്നു കിടക്കുന്ന കവറുകളിലേക്ക് ശേഖരിക്കുന്നു. ഇത് L0-യിൽനിന്ന് ജ്യാമിതിപരമായി വലുതാകുന്നു. നിലവിൽ, ഞങ്ങളുടെ മോണോറെപ്പോ L4 വരെയുള്ള പാക്ക്ഫയൽ കവറുകൾ ഉപയോഗിക്കുന്നു.

ഈ കവറുകൾ ഒരേസമയം രണ്ട് ലക്ഷ്യങ്ങൾ നിറവേറ്റുന്നു. ഒരു കവർ ആവശ്യത്തിന് നിറഞ്ഞു കഴിഞ്ഞാൽ, ഒരു കമ്പാക്ഷൻ വർക്കർ അത് ഏറ്റെടുക്കുകയും അതിൽ നിന്ന് ഒരൊറ്റ പാക്ക്ഫയൽ നിർമ്മിക്കുകയും ചെയ്യുന്നു. പാക്ക്ഫയലിനുള്ളിലെ ഒബ്ജക്റ്റുകളെ പുനക്രമീകരിക്കുന്നതിലൂടെ ഇത് കംപ്രഷൻ അനുപാതം മെച്ചപ്പെടുത്തുന്നു. അതോടൊപ്പം തന്നെ, റെഫ് പതിപ്പുകൾക്ക് മുകളിലൂടെയുള്ള ഒരു സ്കിപ്പ് ലിസ്റ്റ് ആയി പ്രവർത്തിച്ചുകൊണ്ട് ഫെച്ച് നെഗോഷിയേഷൻ പ്രകടനം ഇത് വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു. ഓരോ തലത്തിലുമുള്ള ഇൻഡെസ്കുകൾ ഒരേസമയം സ്കാൻ ചെയ്യുന്നതിലൂടെ, ലോഗരിതമിക് സമയത്തിനുള്ളിൽ ക്ലയന്റിന് അയയ്ക്കേണ്ട പാക്കുകൾ തിരഞ്ഞെടുക്കാൻ Pando-യ്ക്ക് സാധിക്കുന്നു. റീപാക്ക് ചെയ്തതാണെങ്കിലും അല്ലെങ്കിലും ഈ പാക്ക്ഫയൽ കവറുകൾ ഫെച്ച് പ്ലാനിംഗിനെ കൂടുതൽ കാര്യക്ഷമമാക്കുകയും Pando-യുടെ ത്രൂപുട്ട്, ലേറ്റൻസി ആവശ്യകതകൾ കുറയ്ക്കുകയും ചെയ്യുന്നു.

പല Git സെർവറുകളിൽനിന്നും വ്യത്യസ്തമായി, എല്ലാ തലത്തിലെയും പാക്ക്ഫയലുകൾ സൂക്ഷിക്കുന്നു; അവ ഉപേക്ഷിക്കുകയോ ഉപയോഗശൂന്യ ഡാറ്റയായി നീക്കുകയോ ചെയ്യുന്നില്ല. ഫെച്ചിൽ ക്ലയന്റുകൾ അഭ്യർഥിക്കുന്ന have-കൾ want-കൾ എന്നിവയുടെ അടിസ്ഥാനത്തിൽ എല്ലാ തലത്തിലെയും പാക്കുകൾ തുടർച്ചയായി സേവനം നൽകാൻ ഉപയോഗിക്കുന്നു. Pando-യെ API ആയി ഉപയോഗിക്കുന്ന ക്ലയന്റുകൾക്ക്, പാക്ക്ഫയലിൽനിന്ന് ഏതെങ്കിലും ഒബ്ജക്റ്റ് റീഡ് ചെയ്യുമ്പോൾ L4-നെക്കാൾ L0-യിൽ കുറച്ച് ഡാറ്റ റീഡ് ചെയ്താൽ മതിയാകാറുണ്ട്; അതിൽ കംപ്രസ് ചെയ്തിരിക്കാനുള്ള സാധ്യത കുറവാണ്.

Pando-യിലെ കമ്പാക്ഷൻ ക്ലയന്റുകളിലേക്ക് അയയ്ക്കുന്ന ആകെ ഡാറ്റയുടെ വലിപ്പം ഗണ്യമായി കുറയ്ക്കുന്നു; അതോടൊപ്പം തന്നെ ഒരു ക്ലയന്റ് എത്രത്തോളം പുറകിലാണെന്നതിനെ ആശ്രയിക്കാതെ പാക്ക് പ്ലാനിംഗ് സബ്-ലീനിയറായി വിപുലീകരിക്കാൻ ഇത് സഹായിക്കുന്നു. സോഫ്റ്റ്‌വെയർ ഡെവലപ്മെന്റിൽ ഇനി സർവ്വ സാധാരണമാകാൻ സാധ്യതയുള്ള വളരെ വേഗത്തിൽ മാറിക്കൊണ്ടിരിക്കുന്ന വലിയ റിപ്പോസിറ്ററികൾക്ക് ഈ സവിശേഷത പ്രത്യേകിച്ച് വളരെ പ്രധാനപ്പെട്ടതാണ്.

Codex ഉപയോഗിച്ച് വെറും 10 ആഴ്ചകൾക്കൊണ്ടാണ് ഞങ്ങൾ Pando വികസിപ്പിച്ച് പ്രൊഡക്ഷനിലേക്ക് മാറ്റിയത്. ഒരു എഞ്ചിനീയർ രൂപകൽപ്പന ചെയ്ത Pando-യുടെ പ്രധാന ഭാഗം, ഏജന്റുകളുടെ വിവിധ ടീമുകൾ ചേർന്നാണ് നടപ്പിലാക്കിയത്; തുടർന്ന് ചുരുക്കം ചില എഞ്ചിനീയർമാർ ചേർന്ന് ഇത് വിന്യസിക്കുകയും ചെയ്തു. ഈ വർഷം ഏപ്രിലിലാണ് Pando പ്രൊഡക്ഷൻ അഭ്യർത്ഥന കൈകാര്യം ചെയ്യാൻ തുടങ്ങിയത്. OpenAI-യിൽ ഉപയോഗിക്കുന്ന വലിയൊരു സോഴ്സ് കൺട്രോൾ മാനേജ്മെന്റ് സിസ്റ്റത്തിന്റെ ഒരു ഭാഗം മാത്രമാണിത്.

Pando-യുടെ രൂപകൽപ്പനയുടെ സാധുത പരിശോധിക്കാൻ ഞങ്ങൾ പലവിധ സമീപനങ്ങൾ ഉപയോഗിച്ചു. കൂടുതൽ സുരക്ഷിതമായ സോഫ്റ്റ്‌വെയർ അടിത്തറകൾ നിർമിക്കുന്നതിനുള്ള⁠ ഞങ്ങളുടെ തത്ത്വങ്ങൾ പ്രയോഗിച്ചു. പുതുതായി തുടങ്ങിയ പ്രോജക്റ്റായതിനാൽ, പഴയ ആശ്രിത ഘടകങ്ങളില്ലാതെ Rust-ൽ Pando നടപ്പാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഏജന്റുകൾക്ക് തങ്ങളുടെ മാറ്റങ്ങൾ സാധാരണ Git പ്രവർത്തനവുമായി ഒത്തുനോക്കാൻ ഞങ്ങൾ അനുരൂപതാ പരിശോധനാസഞ്ചയം എഴുതി. സിസ്റ്റത്തിന്റെ മാറ്റമില്ലാ നിബന്ധനകളും ഗുണങ്ങളും പരിശോധിക്കാൻ നിർണിതഫലമുള്ള സിമുലേഷൻ പരിശോധനാ ഹാർനെസുകളും വികസിപ്പിച്ചു. നെഗോഷിയേഷനിലെയും പാക്ക് ആസൂത്രണത്തിലെയും സൂക്ഷ്മമായ മത്സരാവസ്ഥകളും പ്രവർത്തനത്തകരാറുകളും കണ്ടെത്തി ലഘൂകരിക്കാൻ ഇവ സഹായിച്ചു.

നിരവധി മോഡലുകൾ ഈ സിസ്റ്റത്തിന്റെ വികസനത്തിന് സംഭാവന നൽകിയിട്ടുണ്ട്; പുതിയ മോഡലുകൾ ലഭ്യമാകുന്നതിനനുസരിച്ച് Pando-യുടെ പ്രകടനവും വിശ്വാസ്യതയും മെച്ചപ്പെടുത്താൻ ഞങ്ങൾ അവ ഉപയോഗിച്ചു. GPT‑6 Astra ഉപയോഗിച്ച് ഏജന്റുകൾ Lean-ഉം TLA+ഉം എഴുതി ഒരു “Pando-യുടെ സിദ്ധാന്തം” രൂപീകരിക്കുകയും ഇത് ഉപയോഗിച്ച് സിസ്റ്റത്തിലെ ബഗ്ഗുകൾ കണ്ടെത്താനും പരിഹരിക്കാനും അതിന്റെ സവിശേഷതകൾ തെളിയിക്കാനും സാധിച്ചു. Pando-യിലെ സങ്കീർണ്ണമായ പ്രശ്നങ്ങൾ കണ്ടെത്തി പരിഹരിക്കുന്നതിനായി നൂറുകണക്കിന് മണിക്കൂറുകൾ നീണ്ടുനിന്ന ഒന്നിലധികം തുടർച്ചയായ സെഷനുകൾ പ്രവർത്തിക്കുകയുണ്ടായി. കൂടാതെ, Daybreak-ശേഷിയുള്ള മോഡലുകളുപയോഗിച്ച് Git-ന്റെയും Pando-യുടെയും റെഡ്-ടീം നടത്താൻ ഞങ്ങൾ ഏജന്റുകളെ 24 മണിക്കൂറും പ്രവർത്തിപ്പിക്കുന്നുണ്ട്.

നിലവിലുള്ള ഞങ്ങളുടെ സോഴ്സ് കൺട്രോൾ സംവിധാനത്തിലേക്ക് റീഡ്-ആൻഡ്-റൈറ്റ്-ത്രൂ പ്രോക്സി ആയാണ് Pando ഞങ്ങൾ ആദ്യം ഞങ്ങൾ വിന്യസിച്ചത്. ഇത് Pando-യെയും മുമ്പത്തെ സിസ്റ്റത്തെയും പരസ്പരം സമന്വയിപ്പിച്ച് നിലനിർത്താൻ സഹായിച്ചു; അതിലൂടെ പ്രവർത്തന തടസ്സങ്ങൾ ഒന്നും കൂടാതെ തന്നെ അഭ്യർത്ഥന സുരക്ഷിതമായി Pando-യിലേക്ക് മാറ്റാൻ ഞങ്ങൾക്ക് സാധിച്ചു.

കാഷിങ് രൂപകൽപ്പനയുടെ ഭാഗമായി, പ്രോക്സി വഴി കൈമാറുന്നതിനുമുമ്പ് അഭ്യർഥനകളിലെ ആവർത്തനം നീക്കാനും അവ സംയോജിപ്പിക്കാനും Pando-യ്ക്ക് കഴിയും. സംവിധാനങ്ങളെ ഓരോന്നായി Pando-യിലേക്ക് മാറ്റുമ്പോഴും നിലവിലെ ഉപകരണങ്ങൾ സുഗമമായി പ്രവർത്തിക്കാൻ ഇത് സഹായിച്ചു. കൂടുതൽ ജോലിഭാരങ്ങൾ Pando-യിലേക്ക് മാറ്റിയപ്പോൾ, അവയുടെ പുഷുകൾ Pando-യുടെ കാഷ് നിറയ്ക്കുകയും മുൻ ബാക്കെൻഡിന്റെ വിശ്വാസ്യത മെച്ചപ്പെടുത്തുകയും ചെയ്തു.

Pando ഉപയോഗിക്കുമ്പോഴുള്ള പ്രകടനം മെച്ചപ്പെടുത്താൻ, ഞങ്ങൾ Git-ന്റെ പബ്ലിക് ഡിസ്ട്രിബ്യൂഷൻ ഡെവലപ്പർമാരുടെ കമ്പ്യൂട്ടറുകളിലേക്കും ChatGPT ഡെസ്ക്ടോപ്പ് ആപ്പിലേക്കും ലഭ്യമാക്കാൻ തുടങ്ങി. ക്ലയന്റുകളെ ഘട്ടം ഘട്ടമായി Pando-യിലേക്ക് മാറ്റാൻ Git CLI-യ്ക്ക് ചുറ്റുമുള്ള ഒരു ഇന്റേണൽ റാപ്പർ ഞങ്ങൾ ഉപയോഗിച്ചു. മാറ്റങ്ങൾക്കായുള്ള അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യുന്നതിനും കോഡ് റിവ്യൂവിനും ഓട്ടോമേഷനുകൾക്കായുള്ള API-കൾക്കുമായി ഞങ്ങൾ മറ്റ് നിരവധി ടൂളുകളും നിർമ്മിച്ചു. Git അഭ്യർത്ഥനയ്ക്ക് ഒപ്പം തന്നെ, പഴയ API-കൾ, വെബ് ഹുക്കുകൾ, റിപ്പോസിറ്ററി ഡൗൺലോഡുകൾ എന്നിവയെ ആശ്രയിച്ചിരുന്ന നൂറുകണക്കിന് സംയോജനങ്ങളും ഞങ്ങൾ Pando-യിലേക്ക് മാറ്റി.

ഈ മാറ്റം നടത്താൻ ഡെവലപ്പർമാരെയും ടീമുകളെയും Codex തന്നെ സഹായിച്ചു. നിലവിലെ ചെക്കൗട്ടുകൾ തയ്യാറാക്കാനും പുതിയ സംവിധാനം ഉപയോഗിക്കാൻ ഏജന്റുകളെ നയിക്കാനുമുള്ള നൈപുണ്യങ്ങൾ ഞങ്ങൾ സൃഷ്ടിച്ചു. അതിന്റെ ഫലമായി, വികസന പരിസരങ്ങളും സേവനങ്ങളും മാറ്റാൻ ഡെവലപ്പർമാർക്ക് Codex-നോട് ആവശ്യപ്പെട്ടാൽ മാത്രം മതിയായിരുന്നു.

Pando-യിലേക്ക് മാറിയത് മെർജ് ചെയ്യലിന്റെ വിശ്വാസ്യത വർദ്ധിപ്പിക്കുകയും ശരാശരി പുഷ് ലേറ്റൻസി ഏകദേശം 80%-ത്തോളം കുറയ്ക്കുകയും ചെയ്തു.

ഏതാനും CPU കോറുകൾ മാത്രം ഉപയോഗിച്ച് പ്രതിദിനം ഒരു പെറ്റാബൈറ്റ് Git ഡാറ്റ നൽകാൻ Pando-യ്ക്ക് കഴിയും. ഒറ്റ മണിക്കൂറിൽ 57 ടെറാബൈറ്റിലധികം Git പാക്കുകൾ Pando നൽകിയിട്ടുണ്ട്; ആ ബൈറ്റുകളിൽ 99%-ലേറെയും ലോക്കൽ ഡിസ്ക് കാഷിൽനിന്നായിരുന്നു.

പാക്കുകൾ പുനരുപയോഗിക്കുന്നതിനാൽ, സേവനം നൽകുന്ന നോഡുകളിൽ കുറഞ്ഞ കണക്കുകൂട്ടലോടെ പല ക്ലയന്റുകൾക്കും ഒരേ റിപ്പോസിറ്ററി ചരിത്രം ഡൗൺലോഡ് ചെയ്യാം. ഈ ഉദാഹരണം ഒറ്റ റിപ്പോസിറ്ററിയുടേതാണ്; എന്നാൽ കൂടുതൽ റിപ്പോസിറ്ററികൾ പിന്തുണയ്ക്കാനാണ് Pando രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ആവശ്യം കൂടുമ്പോൾ ഡാറ്റ വിതരണവും Git നെഗോഷിയേഷനും സ്വതന്ത്രമായി വിപുലീകരിക്കാം.

Git പ്രോട്ടോക്കോളും ക്ലയന്റും അടിസ്ഥാനമാക്കി Pando നിർമിച്ചത്, Git-ന്റെ സ്വന്തം പ്രകടനത്തിലെ പിഴവുകളും മെച്ചപ്പെടുത്താനുള്ള അവസരങ്ങളും കണ്ടെത്താൻ സഹായിച്ചു.

ഉദാഹരണത്തിന്, Pando പുനരുപയോഗിക്കാവുന്ന പാക്കുകൾ നേരിട്ട് ക്ലയന്റുകൾക്ക് നൽകുന്നു. അതിനാൽ അവ ഡൗൺലോഡ് ചെയ്യുന്നതും ഇൻഡക്സ് ചെയ്യുന്നതും സിസ്റ്റത്തെ വേഗവും വിശ്വാസ്യതയുമുള്ളതാക്കുന്നതിൽ കേന്ദ്ര ഘടകമായി. സമാന്തര ഡൗൺലോഡുകൾ, തടസ്സപ്പെട്ട കൈമാറ്റങ്ങൾക്കുശേഷമുള്ള വൃത്തിയാക്കൽ, പൂർത്തിയായ ഡൗൺലോഡുകൾ പുനരാരംഭിക്കൽ എന്നിവയിലെ അപൂർവ സാഹചര്യങ്ങൾ ആ പ്രവർത്തനത്തിലൂടെ കണ്ടെത്തി. ഞങ്ങൾ ആ പ്രവർത്തനപഥങ്ങൾ പരിഹരിച്ചു; ഫെച്ചിനായി നിലവിലെ പാക്ക് സ്വീകരിക്കുമ്പോൾ സാധുതാപരിശോധനകൾ ചേർത്തു; ആ പ്രവർത്തനം മുഖ്യ പ്രോജക്റ്റിലേക്ക് സംഭാവന ചെയ്തു.

സമയവും ബാൻഡ്‌വിഡ്ത്തും എവിടെയാണ് ചെലവാകുന്നുത് എന്ന് മനസ്സിലാക്കേണ്ടതും ഞങ്ങൾക്ക് ആവശ്യമായിരുന്നു, അതിനായി, packfile-uri ഡൗൺലോഡുകൾ ട്രാക്ക് ചെയ്യാനുള്ള ട്രേസിങ്ങും പാക്ക് സൃഷ്ടിക്കലിനായുള്ള ബൈറ്റ് കൗണ്ടുകളും ഞങ്ങൾ കൂട്ടിച്ചേർത്തു. ഇതോടെ വേഗത കുറഞ്ഞ ഒരു ഫെച്ച് ഓപ്പറേഷൻ അതിന്റെ സമയം ചിലവഴിക്കുന്നത് പാക്കുകൾ നിർമ്മിക്കാനാണോ അതോ അവ കൈമാറാനാണോ എന്ന് തിരിച്ചറിയുന്നത് കൂടുതൽ എളുപ്പമായി മാറി.

OpenAI-യുടെ Git ബിൽഡിൽ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), ക്ലയന്റുകൾക്ക് ഒരേസമയം ഒന്നിലധികം സ്വതന്ത്ര പാക്കുകൾ സമാന്തരമായി ഡൗൺലോഡ് ചെയ്യാനും ഇൻഡക്സ് ചെയ്യാനും കഴിയും. സെർവറുകൾക്ക് ഒരു ബ്രാഞ്ചിന്റെ നിലവിലുള്ള ഏറ്റവും പുതിയ അപ്ഡേറ്റ് സംരക്ഷിക്കാൻ സഹായിക്കുന്നതിനായി ഞങ്ങൾ "explicit haves“ എന്നൊരു ആശയം ഇതിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഒരു ക്ലയന്റ് പുഷ് ചെയ്യുമ്പോൾ അതിന്റെ പാക്കിൽ ഉൾപ്പെടുത്താതെ ഒഴിവാക്കുന്ന ഹിസ്റ്ററിയിൽ നിന്നും വേറിട്ടു തന്നെ ഈ നിലവിലുള്ള ടിപ്പ് കാണിക്കാൻ ഇത് സെർവറിനെ സഹായിക്കുന്നു. ഫീച്ചർ ബ്രാഞ്ചിൽ മറ്റ് മാറ്റങ്ങളൊന്നും വന്നിട്ടില്ലെന്ന് ഉറപ്പുവരുത്താൻ ക്ലയന്റുകൾക്ക് --force-with-lease ഉപയോഗിക്കാനും ട്രങ്ക് മാത്രം അടിസ്ഥാനമാക്കി പാക്ക് തയ്യാറാക്കാനും ഇത് Pando-യിൽ അവസരമൊരുക്കുന്നു. ട്രങ്ക് ഹിസ്റ്ററിയുള്ള ആർക്കും പിന്നീട് ഇതേ പാക്ക് ഉപയോഗിച്ച് ആ ബ്രാഞ്ച് ഫെച്ച് ചെയ്യാനും സാധിക്കും.

ഇതിൽ പല മെച്ചപ്പെടുത്തലുകളും ഇതിനകം തന്നെ Git-ന്റെ ഔദ്യോഗിക പതിപ്പിൽ ലഭ്യമാക്കിയിട്ടുണ്ട്, ബാക്കിയുള്ളവയിൽ ഭൂരിഭാഗവും ഞങ്ങളുടെ പബ്ലിക് റിപ്പോസിറ്ററിയിലും ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഈ മാറ്റങ്ങൾ Pando-യ്ക്ക് പുറമെ മറ്റുള്ളവർക്കും പ്രയോജനപ്പെടുത്തുന്നതിനായി Git കമ്മ്യൂണിറ്റിയുമായി ചേർന്ന് ഞങ്ങൾ തുടർന്നും പ്രവർത്തിക്കുന്നുണ്ട്. ഈ പ്രവർത്തനങ്ങളുടെ പുരോഗതി ഞങ്ങളുടെ പൊതു പാച്ച് ട്രാക്കറിലൂടെ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) നിങ്ങൾക്ക് നേരിട്ട് മനസ്സിലാക്കാവുന്നതാണ്.

Git റിപ്പോസിറ്ററികൾ വിപുലീകരിക്കുന്നതിനെക്കുറിച്ചുള്ള പതിവ് ധാരണകൾ പുനർവിചിന്തനം ചെയ്തതിലൂടെ, ഞങ്ങളുടെ എൻജിനീയർമാരും ഏജന്റുകളും ഉപയോഗിച്ചുവരുന്ന Git പ്രവർത്തനക്രമങ്ങൾ മാറ്റാതെ മോണോറിപ്പോ വിപുലീകരിക്കാൻ Pando സഹായിക്കുന്നു. ഞങ്ങളുടെ മോണോറിപ്പോയിൽ കൂടുതൽ സമാന്തര പ്രവർത്തനം സാധ്യമാക്കാനും മെർജിന്റെ വിശ്വാസ്യത മെച്ചപ്പെടുത്താനും കോഡ് മാറ്റങ്ങൾ പ്രസിദ്ധീകരിക്കുന്ന സമയം കുറയ്ക്കാനും Pando സഹായിച്ചു. ഞങ്ങളുടെ മോണോറെപ്പോയ്ക്ക് പുറമേ, ഒരു പങ്കിട്ട Git റിപ്പോസിറ്ററിയിൽ വലിയ തോതിൽ ഏജന്റുകൾ ഒന്നിച്ച് പ്രവർത്തിക്കേണ്ടിവരുന്ന വർക്ക് ലോഡുകൾ ഉൾപ്പെടെ OpenAI-യ്ക്കുള്ളിലെ മറ്റ് ആവശ്യങ്ങൾക്കായി Pando എങ്ങനെ ഉപയോഗിക്കാം എന്നതിനെക്കുറിച്ചും ഞങ്ങൾ ആലോചിക്കുന്നുണ്ട്.

എൻജിനീയർമാരും ഏജന്റുകളും കൂടുതൽ സോഫ്റ്റ്‌വെയറുകൾ വികസിപ്പിക്കുമ്പോൾ, സോഴ്സ് കൺട്രോളിൽ ഞങ്ങൾ നേരിട്ട അതേ പരിധികൾ OpenAI-ക്ക് പുറമെയുള്ള മറ്റ് ടീമുകൾക്കും അനുഭവപ്പെടാൻ തുടങ്ങും. അതുകൊണ്ട് Pando-യെ വിജയകരമാക്കിയ ഈ സാങ്കേതികവിദ്യ ഞങ്ങളുടെ ഉപയോക്താക്കളിലേക്ക് എത്തിക്കാനുള്ള വഴികൾ ഞങ്ങൾ ഇപ്പോൾ ആലോചിക്കുന്നുണ്ട്.

Git റിപ്പോസിറ്ററികൾ ഉപയോഗിക്കുന്നവരുടെയും Operator-മാരുടെയും രണ്ട് പതിറ്റാണ്ടുകാലത്തെ പരിചയസമ്പത്തിനെ മുൻനിർത്തിയാണ് Pando നിർമ്മിച്ചിരിക്കുന്നത്. ഓപ്പൺ സോഴ്സ് Git കമ്യൂണിറ്റിയുമായി ചേർന്ന് പ്രവർത്തിക്കുന്നതിനൊപ്പം തന്നെ ഞങ്ങൾ Pando-യെ കൂടുതൽ വികസിപ്പിക്കുന്നത് തുടരും; Git ഉപയോക്താക്കൾക്ക് പൊതുവായി പ്രയോജനപ്പെടുന്ന എല്ലാ മെച്ചപ്പെടുത്തലുകളും അവരുമായി പങ്കുവെക്കുകയും ചെയ്യും.