1 अरब से अधिक ChatGPT उपयोगकर्ताओं के लिए ऑनलाइन स्टोरेज का तेज विस्तार

OpenAI का हर उत्पाद डेटा तक तेज और भरोसेमंद पहुंच पर निर्भर है, चाहे कोई लॉग इन कर रहा हो, अपनी Codex सेटिंग देख रहा हो या ChatGPT में नई बातचीत शुरू कर रहा हो. उत्पाद के जवाब देने से पहले इनमें से हर कार्रवाई के लिए कई अलग-अलग डेटा खोज करनी पड़ सकती हैं. अगर ये अनुरोध धीमे हों, तो उत्पाद भी धीमा लगता है. अगर ये अनुरोध विफल हों, तो उत्पाद पूरी तरह काम करना बंद कर देता है.

Habitat वह ऑनलाइन स्टोरेज प्लेटफ़ॉर्म है जिसे हमने OpenAI उत्पादों को जरूरी जानकारी तक तेज और भरोसेमंद पहुंच देने के लिए बनाया. Habitat अब लगभग 40 भौगोलिक क्षेत्रों में हर सप्ताह 1 अरब से अधिक लोगों द्वारा इस्तेमाल किए जाने वाले उत्पादों के लिए प्रति सेकंड 7 करोड़ से अधिक अनुरोध संभालता है. Habitat पहली बार DevDay 2023 में GPTs के समर्थन के लिए लॉन्च हुआ था. इसकी शुरुआत एक डेटाबेस से जुड़ी सरल Python क्लाइंट-साइड लाइब्रेरी के रूप में हुई. आज यह एक जटिल वितरित प्रणाली है जो 500 पेटाबाइट से अधिक डेटा उपलब्ध कराती है.

इस पैमाने की अवसंरचना बनाना और चलाना आसान उपलब्धि नहीं है, लेकिन अपने आप में बहुत कठिन भी नहीं. हमारी स्थिति को अनोखा बनाने वाली बात वह अभूतपूर्व गति थी जिससे हमें अत्यधिक उपयोगकर्ता वृद्धि और उत्पाद मांग संभालने के साथ-साथ एक परिपक्व प्लेटफ़ॉर्म बनाते हुए विस्तार करना पड़ा. सिस्टम इंजीनियर अक्सर 10 गुना पैमाने के लिए निर्माण करते हैं और अगली 10 गुना वृद्धि की तैयारी के दौरान उसके कुछ वर्ष टिकने की उम्मीद रखते हैं. हमारे मामले में पिछले तीन वर्षों से हर वर्ष वृद्धि 10 गुना से अधिक रही है. इसलिए Habitat का निर्माण और संचालन रणनीतिक निर्णयों व उनके क्रम की शृंखला रहा है: मौजूदा स्टैक से अधिकतम लाभ लेने के लिए हर घटक को सबसे निचले स्तर तक समझना, और आधारभूत निवेश के लिए समय निकालने हेतु स्टोरेज व कंप्यूट क्षमता की कमी से जूझना.

OpenAI के बढ़ने के साथ Habitat को भी बढ़ना पड़ा: पहले अहम उत्पाद ट्रैफ़िक के लिए पर्याप्त भरोसेमंद बनकर, फिर वैश्विक उपयोगकर्ताओं के लिए पर्याप्त तेज बनकर और अंततः विशाल पैमाने पर कुशलता से काम करके. यह पोस्ट ऑनलाइन स्टोरेज के हमारे विस्तार पर दो भागों वाली शृंखला की पहली कड़ी है. इस पोस्ट में हम बताएंगे कि Habitat कैसे विकसित हुआ, हमने इसे लाइब्रेरी से सेवा क्यों बनाया और सेवा स्टैक में असामान्य भाषा Python में लिखी सेवा को कैसे एक भरोसेमंद स्टोरेज प्लेटफ़ॉर्म परत बनाया.

भावी पोस्ट में हम विस्तार से बताएंगे कि बड़े पैमाने पर बहु-किरायेदारी को भरोसेमंद कैसे बनाया, रीड प्रदर्शन सुधारने की हमारी स्तरीय रणनीति क्या थी और अभूतपूर्व मांग भरोसेमंद ढंग से संभालने के लिए Azure Cosmos DB के साथ साझेदारी कैसे बढ़ाई.

Habitat की शुरुआत एक सरल विचार से हुई: उत्पाद इंजीनियरों को डेटाबेस प्रबंधन के बारे में सोचने की जरूरत नहीं होनी चाहिए. Habitat पहली बार DevDay 2023 में GPTs के समर्थन के लिए एक छोटी Python लाइब्रेरी के रूप में लॉन्च हुआ, जो ChatGPT के मुख्य सर्वर से संवाद करती थी. यह कुछ सीमित कार्रवाइयों का समर्थन करती थी, जिन्हें आंतरिक रूप से डेटाबेस अनुप्रयोग Azure Cosmos DB से जोड़ा गया था.

लाइब्रेरी का काम उत्पाद टीमों को आंतरिक बारीकियां समझे बिना डेटा संग्रहित और प्राप्त करने का सरल तरीका देना था. Habitat जरूरी काम संभालता था: डेटा का प्रकार पता करना, वह कहां से आए या जाए, अनुरोध की अनुमति है या नहीं, आदि.

उत्पाद इंजीनियरों को स्कीमा खोज, रूटिंग, प्राधिकरण, एन्क्रिप्शन, सीरियलाइज़ेशन, अनुरोध आकार निर्धारण और कनेक्शन पूलिंग की चिंता नहीं करनी पड़ती. उन्हें यह भी सोचने की जरूरत नहीं थी कि डेटा Azure Cosmos DB, कैश या किसी अन्य स्टोरेज से आता है.

यह Python लाइब्रेरी अच्छी चली और OpenAI के उत्पाद इंजीनियरों ने Habitat को तेजी से अपनाया, जबकि स्व-सेवा Postgres और Azure Cosmos DB से दूर जाने का कोई समन्वित केंद्रीय प्रयास नहीं था.

उत्पाद जरूरतें बदलने पर डेवलपरों के लिए साझा लाइब्रेरी में क्लाइंट-साइड कैशिंग, संपीड़न या एन्क्रिप्शन जैसी सुविधाओं का समर्थन जोड़ना भी आसान था.

2025 के मध्य तक Habitat क्लाइंट-साइड कार्यान्वयन के रूप में अपनी सीमा पर पहुंच चुका था. Habitat परत अधिक जटिल होने और OpenAI की सेवाओं की संख्या बढ़ने से पश्चगामी संगत प्रोटोकॉल परिवर्तन अव्यावहारिक हो गए थे.

एक मामले में हम अपने सबसे महत्वपूर्ण डेटा सेट को क्षेत्रीय रूप से वितरित Azure Cosmos DB खातों में माइग्रेट करके किसी एक क्षेत्र की विफलता का प्रभाव सीमित करना चाहते थे. इस बदलाव के लिए क्लाइंट में अतिरिक्त रूटिंग तर्क जोड़ना, उसे फ़ीचर फ़्लैग के पीछे निष्क्रिय रखना, सभी क्लाइंट तक उसका रोलआउट सुनिश्चित करना और फिर फ़्लैग सक्रिय करना जरूरी था.

दर्जनों सेवाओं में डिप्लॉयमेंट का समन्वय और हर टीम के साथ रोलआउट करने में कई दिन लगे. इसे सक्रिय करने से पहले हमें एहसास हुआ कि शार्डिंग तर्क सही होने की पुष्टि के लिए कुछ शैडोइंग जोड़नी चाहिए. उसके रोलआउट में दो दिन और लगे. फिर गलत निकली किसी चीज का बग सुधारना था? उसमें दो दिन और लगे. आखिरकार हम फ़्लैग सक्रिय करने को तैयार थे, लेकिन एक टीम ने असंबंधित कारण से अपनी सेवा को पुराने त्रुटिपूर्ण क्लाइंट पर वापस कर दिया, जिससे वही सेवा बाधित हुई जिसे टालने के लिए हमने इतनी मेहनत की थी.

क्लाइंट लाइब्रेरी में बदलाव के लिए दर्जनों सेवाओं में जटिल समन्वय जरूरी था. यह प्रक्रिया लगातार अधिक नाजुक, अक्षम और संचालन संबंधी विफलताओं के प्रति संवेदनशील होती गई. भावी डिप्लॉयमेंट में इस संचालनात्मक फैलाव को घटाने के लिए हमने Habitat को अलग सेवा बनाने का निर्णय लिया.

स्टोरेज तर्क को स्वतंत्र सेवा में अलग करके हमने डिप्लॉयमेंट, प्रेक्षणीयता और प्लेटफ़ॉर्म सुधारों के लिए एक नियंत्रण बिंदु स्थापित किया. बिखरे अपडेट प्रबंधित करने के बजाय हम सुधारों को केंद्रीय रूप से लागू कर सकते थे, जिससे हर OpenAI उत्पाद को तुरंत लाभ मिलता.

केंद्रीकृत सेवा हमें सबसे मजबूत डेटा सुरक्षा और गोपनीयता आधारभूत सुविधाएं देने के लिए एकल नियंत्रण बिंदु भी देती है. Habitat सेवा में हम केंद्रीय रूप से पहुंच-नियंत्रण नीतियां लागू कर सकते हैं, ऑडिट लॉगिंग कर सकते हैं और Azure Cosmos DB जैसे अंतर्निहित स्टोरेज संसाधनों तक पहुंच सीमित कर सकते हैं. Habitat उपयोगकर्ता डेटा की रक्षा और बाहरी, आंतरिक तथा एजेंट इकाइयों की अनधिकृत पहुंच रोकने में महत्वपूर्ण भूमिका निभाता है.

हमें पता था कि सेवा की जरूरत है, लेकिन सेवा के रूप में Python के अतिरिक्त भार के बावजूद हम अभी Python छोड़ना नहीं चाहते थे. उच्च थ्रूपुट वाली सेवा में Python इस्तेमाल करने से स्थानीय लाइब्रेरी निष्पादन की तुलना में नेटवर्क विलंबता और CPU व मेमोरी के विस्तार की लागत काफी बढ़ी. साथ ही, हमें एहसास था कि 100 गुना पैमाने पर Python की अक्षमताएं स्वीकार्य नहीं होंगी, इसलिए अंततः इसे दोबारा लिखना लगभग तय था.

हालांकि, हमने इसे सोच-समझकर लिया गया तकनीकी ऋण माना. तब हमारा मुख्य उद्देश्य लागत या संसाधनों का अनुकूलन नहीं, बल्कि उत्पाद डेवलपरों की बाधाएं दूर करना और प्लेटफ़ॉर्म को स्थिर बनाना था. अल्पावधि में Python सेवा के प्रदर्शन संबंधी समझौते स्वीकार करके हम अधिक तात्कालिक चुनौतियों को प्राथमिकता दे सके, अपने मुख्य API स्थापित कर सके और मजबूत अवसंरचना बना सके.

हमने सोच-समझकर यह दांव भी लगाया कि हमारे अपने कोडिंग मॉडल की तेज प्रगति भविष्य में तकनीकी राह आसान कर देगी. हमारा दांव था कि Python से पूर्ण माइग्रेशन जरूरी होने तक Codex और GPT उसे संभव बना देंगे. आखिरकार यह दांव सही साबित हुआ.

प्रदर्शन की दृष्टि से Habitat को Python सेवा के रूप में चलाना आदर्श नहीं था, लेकिन जरूरी था. Python हमें तेजी से आगे बढ़ने देता है, पर इसका मतलब यह नहीं कि हम सावधानी छोड़कर काफी अधिक विलंबता स्वीकार कर सकते थे. जब औसत उपयोगकर्ता अनुरोध से सैकड़ों डेटाबेस कॉल होती हैं, तो उपयोगकर्ता को सबसे धीमी कॉल का असर महसूस होता है. हमने पाया कि इस पैमाने पर Python सेवा चलाने की मुख्य चुनौती अंतिम छोर की इन विलंबताओं को संभालना है.

Asyncio, Python को I/O-बाउंड कार्यभार समवर्ती रूप से चलाने में मदद करता है, लेकिन Python GIL से बचने या CPU समानांतरता देने में नहीं. I/O-हेवी अनुरोध प्रॉक्सी के अलावा Habitat कई CPU-प्रधान जिम्मेदारियां और पृष्ठभूमि कार्य संभालता है: रूटिंग, संपीड़न, एन्क्रिप्शन, चेकसम बनाना, डाउनस्ट्रीम स्वास्थ्य जांच, अनुरोध शैडोइंग और हेजिंग.

हमारी सेवा में इतने CPU-प्रधान कार्यभार और पृष्ठभूमि कार्य होने से asyncio शेड्यूलिंग विलंब आसानी से अनुरोध की अंतिम छोर वाली विलंबता का मुख्य कारण बन सकता है. आरंभिक सेवा लॉन्च के लिए ट्यूनिंग से पहले हमने p99 और अधिक विलंबता वाले अनुरोधों के ट्रेस में देखा कि डाउनस्ट्रीम स्टोरेज जल्दी जवाब देता था, फिर भी प्रतिक्रिया पार्स करने वाली कोरूटीन के दोबारा शेड्यूल होने की प्रतीक्षा में अनुरोध अक्सर अटक जाते थे.

OpenAI की Python सेवाओं में मेमोरी, CPU, नेटवर्क और डिस्क उपयोग के मानक उपयोग व संतृप्ति मेट्रिक मापने के साथ asyncio लूप और उसकी व्यस्तता की निगरानी करना तथा उसके अनुसार ट्यूनिंग करना भी अत्यंत जरूरी है.

पृष्ठभूमि कार्यों को समय-समय पर शेड्यूल करके और अपेक्षित व वास्तविक निष्पादन समय का अंतर दर्ज करके हम इवेंट लूप शेड्यूलिंग विलंब को रीयल टाइम में अनुभवजन्य रूप से माप पाते हैं. अधिक उपयोग और कई महंगे कार्यों की स्थिति में हर प्रोसेस पर समवर्ती अनुरोधों की मामूली संख्या भी उल्लेखनीय शेड्यूलिंग उतार-चढ़ाव पैदा कर सकती है, जो सैकड़ों मिलीसेकंड और कुछ सीमांत मामलों में कई सेकंड तक होता है.

इसलिए हम हर प्रोसेस से केवल थोड़े समवर्ती अनुरोध संभलवाते हैं और इसके बजाय Python वर्कर प्रोसेस की संख्या बहुत बड़े पैमाने पर बढ़ाते हैं.

आरंभिक सेवा लॉन्च में लाइव CPU प्रोफ़ाइलिंग से हमें अधिक asyncio विलंब और उससे पैदा हुई अधिक अंतिम छोर विलंबता का एक मूल कारण मिला: Statsig के जरिए फ़ीचर फ़्लैग कॉन्फ़िगरेशन की आवधिक JSON पार्सिंग. Statsig फ़ीचर फ़्लैग प्रबंधित करता है और A/B परीक्षण आदि चला सकता है.

डिफ़ॉल्ट रूप से Statsig हर मिनट बिना किसी समय-विचलन के नया कॉन्फ़िगरेशन जांचता था और कॉन्फ़िगरेशन में हर सेवा का प्रत्येक प्रोडक्शन नियम शामिल था. अन्यत्र, अधिक CPU उपयोग और कम विलंबता के लिए हर पॉड में अधिकतम 8 Python प्रोसेस चलाने का वास्तुशिल्पीय निर्णय लिया गया था. इन दोनों बातों के कारण हर मिनट प्रत्येक पॉड में एक क्षण ऐसा आता था जब उसके सभी वर्कर जारी अनुरोधों को संसाधित करना रोककर अपने CPU चक्र एक विशाल कॉन्फ़िगरेशन फ़ाइल पार्स करने में लगाते थे.

CPU प्रोफ़ाइलिंग से मूल कारण मिलने के बाद समाधान सीधा था: छोटा और लक्षित कॉन्फ़िगरेशन लागू करना, रीफ़्रेश अंतराल बढ़ाना और ऐसे पृष्ठभूमि कार्यों में कुछ समय-विचलन जोड़ना.

Asyncio विलंब कम रखने के लिए सर्वर प्रोसेस में अनुरोधों का अच्छा लोड संतुलन बनाए रखना भी जरूरी है. ट्यूनिंग के बिना कनेक्शन पूलिंग इसके विपरीत काम कर सकती है.

क्लाइंट-साइड कनेक्शन पूलिंग में कई समवर्ती अनुरोध करने वाला एक क्लाइंट प्रोसेस केवल कुछ सर्वर कनेक्शन बना सकता है और नतीजतन अपना पूरा भार केवल कुछ प्रोसेस को भेज सकता है. लोड संतुलन का तरीका बदलने से पहले हमारी सेवा में उपयोग का अंतर बहुत अधिक था. अंतिम छोर के कुछ प्रोसेस औसत की तुलना में 5–10 गुना समवर्ती अनुरोध संभालते थे.

हमें संयोगवश हुई एक घटना में इसका पता चला. हमारी सेवा के एक हिस्से पर अत्यधिक भार डालने वाले क्लाइंट को रोकने के बाद भी कुछ प्रोसेस अचानक बढ़े ट्रैफ़िक के काफी देर बाद तक खराब स्थिति में रहे. वास्तव में, हमने देखा कि उन प्रोसेस की स्थिति अनियंत्रित रूप से बिगड़ती गई और दोबारा शुरू किए जाने तक उन्हें लगातार अधिक अनुरोध मिलते रहे. किसी पॉड के अतिभारित होते ही कोई व्यवहार अधिक ट्रैफ़िक को उसी पॉड पर बांध रहा था. हमारे कुछ साथी पिछले काम से इस तरह की विफलता से अच्छी तरह परिचित थे: मेटास्टेबल विफलता⁠(एक नई विंडो में खुलेगा).

हमें कनेक्शन पूल पर संदेह था. अधिकतम कनेक्शन पुनः उपयोग अवधि सीमित करके इसे परखा गया, जिससे गिरावट सच में सीमित हुई और हमारी जांच की दिशा की पुष्टि हुई. आगे की जांच में पता चला कि Python का aiohttp TCPConnector डिफ़ॉल्ट रूप से LIFO कनेक्शन पुनः उपयोग करता है: अगला अनुरोध सबसे हाल में लौटे कनेक्शन को चुनता है. आमतौर पर यह उचित डिफ़ॉल्ट है: हाल के कनेक्शन का पुनः उपयोग अचानक बढ़े ट्रैफ़िक के लिए बने अतिरिक्त कनेक्शन को निष्क्रियता के कारण समयबाह्य होने देता है, जिससे उन्हें बनाए रखने का भार घटता है. इस मामले में इससे हमारे लिए मेटास्टेबल विफलता पैदा हुई. अनुरोधों में अचानक वृद्धि के दौरान धीमे और अतिभारित सर्वरों के अनुरोध कनेक्शन को पूल में देर से लौटाते थे. इसलिए बाद के अनुरोध उन्हें अधिक बार चुनते और पहले से जूझ रहे पॉड पर धीरे-धीरे अधिक ट्रैफ़िक केंद्रित होता गया. FIFO पुनः उपयोग के लिए कनेक्शन पूल में सुधार ने यह प्रतिपुष्टि चक्र तोड़ दिया और स्थिर अवस्था में अनुरोधों का अंतर भी घटाया.

आज हम पूरे OpenAI अवसंरचना में कनेक्शन पूलिंग और सर्वर लोड को बेहतर समझने वाली संतुलन रणनीतियों के लिए मुख्यतः Istio और Envoy पर निर्भर हैं, जिससे यह समस्या पूरी तरह टल जाती है.

Asyncio विलंब कम रखने के लिए ट्यूनिंग और इतने Python प्रोसेस होने का एक दुष्प्रभाव यह है कि बड़ी संख्या में कनेक्शन से डाउनस्ट्रीम निर्भरताओं पर बहुत आसानी से अत्यधिक भार पड़ सकता है. इसे “एक साथ उमड़ी भीड़” कहते हैं.

नियमित दैनिक डिप्लॉयमेंट को धीमा रखने के लिए ट्यून न किया जाए, तो कनेक्शन के बार-बार बदलने से CPU पर काफी उथल-पुथल हो सकती है. या कनेक्शन रिसाव NAT गेटवे को संतृप्त करके नेटवर्क ठप कर सकता है. ये समस्याएं अन्य सेवाओं में भी असामान्य नहीं हैं, लेकिन दस गुना अधिक प्रोसेस होने से इनके शुरू होने की सीमा काफी घट जाती है. अक्सर ऐसे नेटवर्क संसाधन संतृप्त हो जाते हैं जिन्हें केवल थ्रूपुट के आधार पर क्लाइंट स्थिर अवस्था में संभालने की जरूरत की अपेक्षा नहीं करते.

कनेक्शन समेकन अधिकतम करने के लिए भी हम Envoy पर निर्भर हैं. हम इसका उपयोग Python के HTTP/1 कनेक्शन को HTTP/2 में उन्नत करके बहुसंकेतन का लाभ लेने, फिर उन कनेक्शन को पूल करने और उनकी अवधि बढ़ाने के लिए करते हैं. Envoy हमें दर सीमाएं और सर्किट ब्रेकर लागू करने के लिए केंद्रीय स्थान भी देता है, क्योंकि हर स्वतंत्र Python प्रोसेस में वे कम प्रभावी होते.

Python को इतना विस्तारित कर पाने का एक कारण Habitat का सीमित API था, जो अनुरोध की लागत को पूर्वानुमेय रखता है. क्लाइंट को मनमानी SQL क्वेरी बनाने देने के बजाय, जिनसे बड़ी तालिकाओं का स्कैन या कई तालिकाओं में जॉइन हो सकते हैं, Habitat एक सरल NoSQL API देता है. शक्तिशाली API का अभाव Habitat के डिज़ाइन में जानबूझकर किया गया समझौता है.

हम सरल, पूर्वानुमेय और निश्चित कार्य वाले अनुरोधों के लिए अनुकूलन करना चाहते हैं. हमारे अनुभव में इन प्रणालियों को विस्तारित करना काफी आसान है और इनमें गलती या दुरुपयोग करना कठिन है. अप्रत्याशित फैलाव वाले अनुरोध संचालन की दृष्टि से खतरनाक हैं: वे पृथक्करण और लोड संतुलन को जटिल बनाते हैं तथा अचानक बढ़ती ऐसी विलंबता लाते हैं जिसके अनुरूप सेवा और क्लाइंट, दोनों को विस्तारित करना कठिन होता है.

Habitat और Azure Cosmos DB अपनाने से पहले OpenAI का अधिकांश ऑनलाइन डेटा Postgres में संग्रहित था. तब प्रोडक्शन में भेजने से पहले सभी क्वेरी और स्कीमा परिवर्तनों की समीक्षा करके यह सुनिश्चित करना आसान था कि वे उचित व्यवहार करें और इंडेक्स किए गए डेटा पर चलें. टीम और उत्पाद बढ़ने पर यह जल्द ही असंभव हो गया और अक्सर सेवा ठप होने का कारण बना, क्योंकि अत्यधिक उपयोग वाले मार्ग पर एक नई महंगी क्वेरी ही डेटाबेस को ठप कर देती थी.

यहां समस्या लागत का असंतुलन है: ऐसी SQL क्वेरी लिखना सस्ता और आसान है जिन्हें चलाना महंगा और कठिन होता है. Habitat में हम इससे बचते हैं और महंगी क्वेरी को क्लाइंट की ओर बेहद स्पष्ट बना देते हैं. Habitat पर अत्यधिक भार डाल सकने वाली कोई असीमित क्वेरी नहीं है. जटिल जॉइन और ग्राफ़ ट्रैवर्सल के लिए उत्पाद टीमों को कुछ कठिन काम स्वयं करना पड़ता है, जिससे समग्र रूप से अधिक कुशल डिज़ाइन को बढ़ावा मिलता है.

Habitat, क्लाइंट द्वारा परिभाषित ऑब्जेक्ट और एज प्रकारों पर आधारित NoSQL API देता है, जिसकी प्रेरणा TAO⁠(एक नई विंडो में खुलेगा) से मिली है. क्लाइंट ऑब्जेक्ट और एज तथा उनके आपसी संबंध पहले से परिभाषित करते हैं, लेकिन प्रत्येक प्रकार की सामग्री नहीं. इससे बने संबंध ग्राफ़ जैसे दिखते हैं, लेकिन किसी विशेष ऑब्जेक्ट के सीधे एज की क्वेरी के अलावा Habitat स्वयं सामान्य ग्राफ़ ट्रैवर्सल क्वेरी का समर्थन नहीं करता.

हम इस ग्राफ़ को इस तरह विभाजित करते हैं कि हर ऑब्जेक्ट और उसके संबंधित एज स्टोरेज-स्तरीय पार्टिशन में साथ रहें, लेकिन डेटाबेस स्तर पर ऑब्जेक्ट और उन दूरस्थ ऑब्जेक्ट को साथ रखने का कोई विशेष प्रयास नहीं करते जिनकी ओर उनके एज संकेत करते हैं. नतीजतन, मॉडल को क्षैतिज विस्तार के लिए आसानी से विभाजित किया जा सकता है, लेकिन ग्राफ़ ट्रैवर्सल अक्षम होते हैं क्योंकि ऑब्जेक्ट के बीच किसी चरण में अलग-अलग क्षेत्रों में संग्रहित दो बिल्कुल अलग Azure Cosmos DB खातों से डेटा लाना पड़ सकता है.

अधिक जटिल क्वेरी जरूरतों वाले क्लाइंट के लिए हम Rockset के जरिए उपलब्ध Habitat का ऑफ़लाइन द्वितीयक दृश्य देते हैं. हम परिवर्तन डेटा कैप्चर (CDC) से ऑनलाइन स्टोरेज के बदलावों को लगभग रीयल टाइम में पृथक Rockset इंस्टेंस तक स्ट्रीम करते हैं. हर क्लाइंट टीम अपनी जटिल क्वेरी जरूरतों के अनुसार अपने Rockset इंस्टेंस को विस्तारित करने के लिए जिम्मेदार है.

Rockset उपलब्ध कराने से क्लाइंट के लिए अतिरिक्त बाधा आती है, लेकिन अभी हमें यही उचित समझौता लगता है: सरल क्वेरी को डिफ़ॉल्ट रखना और जटिल क्वेरी चाहने वालों को वैकल्पिक रास्ता देना. यह डिज़ाइन हमारे ऑनलाइन स्टोरेज को अधिक रीड वाले विश्लेषणात्मक और खोज कार्यभार से अलग रखता है.

Python में दोबारा लिखने का काम एक वर्ष टालने से हम अत्यधिक वृद्धि के दौरान अधिक तात्कालिक और प्रभावशाली चुनौतियों पर ध्यान दे सके. प्लेटफ़ॉर्म के परिपक्व होने और वृद्धि में तेजी जारी रहने के साथ, तथा OpenAI में कोर संख्या के अनुसार दूसरी सबसे बड़ी सेवा और Envoy उपस्थिति में चौथी होने के कारण, आखिरकार Python से आगे बढ़ने का समय आ गया था. चरम पर Python ने हमें हर सेकंड 2 करोड़ से अधिक अनुरोध संभालने में मदद की.

2026 की दूसरी तिमाही में केवल 2 इंजीनियरों, Codex और GPT‑5.5 की मदद से हम पूरी सेवा को Rust में दोबारा लिख सके. यह नई Rust सेवा अब हमारे 95% प्रोडक्शन अनुरोध संभाल रही है. आने वाले सप्ताहों में हम Python को पूरी तरह बंद कर देंगे. हमारे डेटा के अनुसार Rust सेवा Python संस्करण से CPU में 6 गुना और मेमोरी में 15 गुना अधिक कुशल है तथा इसकी औसत और अंतिम छोर की विलंबताएं काफी कम हैं. हम भावी ब्लॉग में और सीख साझा करने की योजना बना रहे हैं.

Python और अब Rust सेवा, Habitat का केवल एक पहलू है. 1 अरब से अधिक ChatGPT उपयोगकर्ताओं के लिए ऑनलाइन स्टोरेज को तेजी से विस्तारित करने की इस शृंखला के भाग II में हम स्टोरेज परत और यह बताएंगे कि Habitat कैसे 500 पेटाबाइट से अधिक डेटा और प्रति सेकंड 7 करोड़ से अधिक अनुरोध संभालता है.

अगर आप अत्याधुनिक पैमाने की OLTP प्रणालियों पर काम करना चाहते हैं और ऐसी इंजीनियरिंग में रुचि रखते हैं, तो हमारी टीम में इस रिक्त पद को देखें⁠.