Ing. Calogero Bono
GitHub ने Rubicon का वर्णन किया है, वह नई Git storage आर्किटेक्चर जिसकी घोषणा GitHub Universe में हुई। कंपनी के अनुसार, आंतरिक परीक्षणों में इसने एक ही repository पर 5,000 समवर्ती एजेंट्स को संभाला, 7,200 push प्रति सेकंड के साथ और कम विलंबता वाली reads के साथ। यह मायने रखता है क्योंकि प्रोग्रामिंग एजेंट्स repositories पर पड़ने वाले भार को बदल रहे हैं, और जो आज GitHub संभाल रहा है, वह एक साल में पर्याप्त नहीं हो सकता।
कुछ शब्द, तथ्यों में उतरने से पहले। एजेंट एक AI प्रोग्राम है जो खुद कोड लिखता है और push करता है। Reference किसी commit का पॉइंटर है, जैसे एक branch। Pack वह फ़ाइल है जिसमें Git objects इकट्ठा होते हैं। Compare-and-swap एक ऐसी क्रिया है जो किसी मान को तभी अपडेट करती है जब इस बीच किसी ने उसे न बदला हो। Blob Storage Azure की object storage सेवा है।
Rubicon क्या है और GitHub ने इसे क्यों बनाया?
Rubicon उस परियोजना का नाम है जिसके साथ GitHub ने यह नया रूप दिया कि वह Git डेटा को कैसे संग्रहीत और परोसता है। GitHub के लेख के अनुसार, यह काम मई 2026 में शुरू हुआ, Azure की ओर प्रारंभिक migration के ठीक बाद।
कारण भार है। GitHub का कहना है कि आज सबसे व्यस्त repositories को अधिकतम दर्जनों लेखन प्रति सेकंड मिलते हैं, छोटे विस्फोटों में। एजेंट्स के समानांतर और लगातार काम करने पर, उसे उम्मीद है कि एक साल के भीतर यह स्थिर गति बन जाएगी। इसलिए उसने कम से कम दो गुना अधिक क्षमता का लक्ष्य रखा है।
GitHub ने कौन सी स्केलिंग आवश्यकताएँ तय कीं?
GitHub दो आयाम अलग करता है। हॉरिज़ॉन्टल स्केलिंग कई repositories से जुड़ी है, और यहाँ partitioning और भार के आधार पर routing जैसे पहले से परखे समाधान बने रहते हैं। वर्टिकल स्केलिंग एक ही बहुत बड़े और व्यस्त repository से जुड़ी है, और लगभग सभी आवश्यकताएँ यहीं से आती हैं।
एक repository के लिए आर्किटेक्चर को प्रति सेकंड हज़ारों लेखन सँभालने चाहिए और कई write nodes को सपोर्ट करना चाहिए। उसे commit की विलंबता भी घटानी होगी, क्योंकि एजेंट अगले कदम से पहले हर push का इंतज़ार करता है। हर push के साथ CI, deploy और अन्य एजेंट्स की ओर से और reads भी होते हैं, और GitHub इस बढ़ोतरी को बहुत तेज़ बताता है।
एक उदाहरण में बताया गया है कि एक repository का दैनिक ट्रैफ़िक मार्च और मई के बीच लगभग 4 गुना बढ़ गया।
नई आर्किटेक्चर कैसे काम करती है?
मूल विचार यह है कि समझौते की ज़रूरत केवल reference अपडेट पर होती है। Git objects अपरिवर्तनीय हैं और उनकी पहचान उनकी सामग्री से होती है, इसलिए कई लेखक उन्हें एक साथ सहेज सकते हैं। इस तरह storage, अनुरोध सेवा और रखरखाव स्वतंत्र रूप से स्केल होते हैं।
अनुरोध Spokes तक पहुँचते हैं, जो अब भी routing और load balancing सँभालता है। उसके नीचे एक नया data plane है, जिसमें वर्चुअल रेप्लिकाएँ हैं और अस्थायी कंप्यूट है जिसकी लोकल डिस्क केवल पुनर्निर्मित होने वाली cache है। टिकाऊ स्थिति दो जगह रहती है।
- Pack और त्वरण डेटा Azure Blob Storage में।
- Reference और pack की सूची (manifest) Ref-CAS में, जो एक replicated log सेवा है।
एक लेखन pack को index करता है, उसे Blob Storage पर अपलोड करता है और Ref-CAS पर एक ही transaction करता है। एक पठन reference संस्करण जाँचता है, गायब pack डाउनलोड करता है और cache से उत्तर देता है। Pack compaction अलग nodes पर चलता है, कभी replicas पर नहीं।
क्या यह रोज़ Git इस्तेमाल करने वालों को प्रभावित करता है?
GitHub के अनुसार नहीं। Git वैसा ही रहता है, push, fetch और branch उसी तरह और उन्हीं सुरक्षा उपायों के साथ काम करते हैं। बदलाव पर्दे के पीछे है और प्लेटफ़ॉर्म चालू रहते हुए लागू किया जा रहा है।
यह विषय Git टूल्स में एजेंट्स के लिए हो रहे बदलावों से भी जुड़ता है, जैसे OpenAI का Pierre का अधिग्रहण। जो लोग Git bisect और blame जैसे बुनियादी कमांड अच्छी तरह जानते हैं, उन्हें अपनी आदतें बदलने की ज़रूरत नहीं है।
जानने योग्य सीमाएँ
5,000 एजेंट्स और 7,200 push प्रति सेकंड वाले आंकड़े GitHub द्वारा घोषित आंतरिक परीक्षणों से आते हैं, जिनकी बाहरी पुष्टि नहीं हुई है। दिया गया पाठ उन दो घटकों के विवरण से पहले ही रुक जाता है जिन पर गहराई से चर्चा होनी थी, इसलिए तकनीकी समझौतों के बारे में हमें पता नहीं है। सभी repositories के लिए पूरी अपनाने की तारीखें उपलब्ध नहीं हैं।
डिजिटल क्षेत्र में काम करने वालों के लिए क्या बदलता है
किसी एजेंसी या छोटी टीम के लिए तत्काल रूप से लगभग कुछ नहीं बदलता। असली बात कुछ और है। यदि आपके workflows ऐसे एजेंट्स का उपयोग करते हैं जो बहुत सारे push करते हैं, तो GitHub इन्हें टिकाऊ बनाने की तैयारी कर रहा है। अपनी pipeline के बारे में सोचना उपयोगी रहेगा, क्योंकि हर push के साथ आगे कई reads होते हैं, जैसा कि GitLab CI/CD और GitHub Actions की तुलना में भी बताया गया है। जो लोग कई ग्राहकों वाले प्लेटफ़ॉर्म बनाते हैं, वे कंप्यूट और डेटा को अलग रखने के सिद्धांत पर ध्यान दे सकते हैं, जो multi-tenant से जुड़ा विषय है।
हमारा मत
Rubicon एक गंभीर इंजीनियरिंग परियोजना है, और केवल reference अपडेट्स का समन्वय करने का विचार सुरुचिपूर्ण है। लेकिन नाम कुछ और भी कहता है। GitHub एजेंट्स के भार को वापसी न होने वाला बिंदु मानता है और उसे निश्चित मानकर चलता है। देखना होगा कि वृद्धि सचमुच उतनी ही होती है या नहीं, या सिंथेटिक परीक्षण वास्तविक उपयोग को बढ़ा-चढ़ाकर दिखाते हैं। इसके लिए विक्रेता के आंकड़ों से अलग स्वतंत्र डेटा चाहिए।
अक्सर पूछे जाने वाले प्रश्न
GitHub का Project Rubicon क्या है?
यह GitHub की नई Git storage आर्किटेक्चर है, जिसकी घोषणा GitHub Universe में हुई। यह storage और compute को अलग करती है और केवल reference अपडेट्स का समन्वय करती है।
यह कितने push प्रति सेकंड संभाल सकता है?
आंतरिक परीक्षणों में GitHub ने एक repository पर 5,000 समवर्ती एजेंट्स के साथ 7,200 push प्रति सेकंड का दावा किया है। ये कंपनी के आंकड़े हैं, किसी तीसरे पक्ष द्वारा सत्यापित नहीं।
क्या मुझे अपना Git इस्तेमाल बदलना होगा?
नहीं। GitHub के अनुसार push, fetch और branch पहले की तरह ही काम करेंगे, उन्हीं सुरक्षा उपायों के साथ।
डेटा कहाँ सहेजा जाता है?
Pack Azure Blob Storage में रहते हैं। Reference और pack की सूची Ref-CAS में रहती है, जो एक replicated log सेवा है।
एक repository के लिए अधिक रेप्लिका क्यों चाहिए?
क्योंकि pack को index करना और object connectivity की जाँच करना बहुत CPU खपत करता है। अधिक nodes काम बाँटते हैं और fault tolerance बेहतर करते हैं।
जब Rubicon सबकी repositories तक पहुँचेगा, तब क्या देखें
असली परीक्षा आंतरिक आंकड़ों से वास्तविक repositories तक पहुँचने पर होगी। इन बातों पर नज़र रखें।
- समझौते समझने के लिए GitHub की आने वाली श्रृंखला के लेख देखते रहें, जो दो गहराई से जाँचे गए घटकों पर होंगे।
- आने वाले महीनों में अपनी repositories के push और fetch समय में बदलाव जाँचें।
- देखें कि GitHub बहुत अधिक समानांतर push करने वाले एजेंट्स के लिए सीमाएँ या उपयोग-नियम प्रकाशित करता है या नहीं।
