800M ChatGPT यूज़र्स के लिए PostgreSQL को स्केल करना

कई वर्षों से, PostgreSQL सबसे महत्वपूर्ण पर्दे के पीछे काम करने वाले डेटा सिस्टम्स में से एक रहा है, जो ChatGPT और OpenAI के API जैसे मुख्य उत्पादों को शक्ति प्रदान करता है. जैसे-जैसे हमारा यूज़र बेस तेज़ी से बढ़ रहा है, हमारे डेटाबेस पर मांग भी घातीय रूप से बढ़ गई है. पिछले वर्ष में, हमारा PostgreSQL लोड 10 गुना से भी अधिक बढ़ गया है, और यह तेजी से बढ़ता जा रहा है.

इस वृद्धि को बनाए रखने के लिए हमारे प्रोडक्शन इंफ्रास्ट्रक्चर को उन्नत करने के प्रयासों से एक नई समझ सामने आई: PostgreSQL को इस तरह स्केल किया जा सकता है कि यह पहले से अधिक बड़े रीड-हेवी वर्कलोड्स को भी भरोसेमंद तरीके से सपोर्ट कर सके. इस सिस्टम (जिसे शुरू में University of California, Berkeley में वैज्ञानिकों की एक टीम ने बनाया था) की मदद से हम एक सिंगल प्राइमरी Azure PostgreSQL फ्लेक्सिबल सर्वर इंस्टेंस⁠(एक नई विंडो में खुलेगा) और दुनिया भर के कई रीज़न में फैले लगभग 50 रीड रेप्लिका के साथ बड़े ग्लोबल ट्रैफ़िक को सपोर्ट कर पाए हैं. यह कहानी है कि हमने कठोर ऑप्टिमाइज़ेशन और मज़बूत इंजीनियरिंग के ज़रिए OpenAI में PostgreSQL को कैसे स्केल किया, ताकि 800 मिलियन यूज़र्स के लिए प्रति सेकंड लाखों क्वेरीज़ को सपोर्ट किया जा सके; साथ ही, हम रास्ते में सीखी गई मुख्य सीखों को भी कवर करेंगे.

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

यह सुनकर आश्चर्य हो सकता है कि एक सिंगल-प्राइमरी आर्किटेक्चर OpenAI के पैमाने की मांगों को पूरा कर सकता है; हालांकि, इसे व्यवहार में लाना सरल नहीं है. हमने Postgres ओवरलोड के कारण कई SEVs देखे हैं, और वे अक्सर एक ही पैटर्न का पालन करते हैं: कोई अपस्ट्रीम समस्या डेटाबेस लोड में अचानक वृद्धि का कारण बनती है, जैसे caching-layer के फेल होने से व्यापक cache misses, महंगे multi-way joins का उछाल जो CPU को संतृप्त कर देता है, या नए फीचर लॉन्च से लेखन का तूफान. जैसे-जैसे संसाधन उपयोग बढ़ता है, क्वेरी विलंबता बढ़ती है और अनुरोध समय समाप्त होने लगते हैं. रिट्राइज़ लोड को और बढ़ा देते हैं, जिससे एक दुष्चक्र शुरू हो जाता है, जो पूरे ChatGPT और API सेवाओं के प्रदर्शन को गिरा सकता है.

हालांकि PostgreSQL हमारे पढ़ाई-प्रधान वर्कलोड्स के लिए अच्छी तरह स्केल करता है, फिर भी उच्च लेखन ट्रैफिक के दौरान हमें चुनौतियों का सामना करना पड़ता है. यह मुख्य रूप से PostgreSQL के मल्टीवर्जन कन्सकरेंसी कंट्रोल (MVCC) कार्यान्वयन के कारण है, जो इसे लेखन-प्रधान कार्यभार के लिए कम प्रभावी बनाता है. उदाहरण के लिए, जब कोई क्वेरी किसी ट्यूपल या किसी एक फील्ड को अपडेट करती है, तो नया संस्करण बनाने के लिए पूरी पंक्ति की प्रतिलिपि बनाई जाती है. भारी लेखन लोड के तहत, इससे महत्वपूर्ण लेखन प्रवर्धन होता है. यह पढ़ने की प्रवर्धन भी बढ़ाता है, क्योंकि नवीनतम संस्करण प्राप्त करने के लिए क्वेरीज़ को कई ट्यूपल संस्करणों (मृत ट्यूपल) के माध्यम से स्कैन करना पड़ता है. MVCC अतिरिक्त चुनौतियाँ प्रस्तुत करता है, जैसे टेबल और इंडेक्स ब्लोट, इंडेक्स मेंटेनेंस ओवरहेड में वृद्धि, और जटिल ऑटोवैक्यूम ट्यूनिंग. (तुम इन मुद्दों पर गहराई से अध्ययन एक ब्लॉग में पा सकते हो, जो मैंने Carnegie Mellon University में प्रोफेसर एंडी पाव्लो के साथ लिखा था, जिसका नाम The Part of PostgreSQL We Hate the Most⁠(एक नई विंडो में खुलेगा) है, जिसे PostgreSQL Wikipedia पेज में उद्धृत⁠(एक नई विंडो में खुलेगा) किया गया है.)

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

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

आने वाले सेक्शनों में, हम उन चुनौतियों पर गहराई से चर्चा करेंगे जिनका हमने सामना किया, और उन व्यापक अनुकूलनों पर भी जिन्हें हमने उन्हें हल करने और भविष्य में होने वाले आउटेज को रोकने के लिए लागू किया. PostgreSQL को उसकी सीमाओं तक ले जाकर और उसे प्रति सेकंड लाखों क्वेरी (QPS) तक स्केल करके.

चुनौती: केवल एक लेखक के साथ, एकल-प्राथमिक सेटअप लेखन को स्केल नहीं कर सकता. भारी लिखने की स्पाइक्स प्राथमिक को जल्दी से ओवरलोड कर सकती हैं और ChatGPT और हमारी API जैसी सेवाओं को प्रभावित कर सकती हैं.

समाधान: हम मुख्य सर्वर पर लोड को जितना संभव हो उतना कम करते हैं—पढ़ने और लिखने, दोनों—ताकि यह लिखने में आने वाले स्पाइक्स को संभालने के लिए पर्याप्त क्षमता रख सके. जहाँ भी संभव हो, पढ़ने का ट्रैफ़िक रेप्लिकाज़ पर ऑफ़लोड किया जाता है. हालांकि, कुछ रीड क्वेरीज़ को प्राइमरी पर ही रहना चाहिए क्योंकि वे राइट ट्रांज़ैक्शन्स का हिस्सा हैं. उनके लिए, हम यह सुनिश्चित करने पर ध्यान केंद्रित करते हैं कि वे कुशल हों और धीमी क्वेरीज़ से बचें. लिखने के ट्रैफ़िक के लिए, हमने विभाज्य, भारी लेखन वर्कलोड्स को Azure CosmosDB जैसे विभाजित सिस्टम्स में माइग्रेट किया है. जिन वर्कलोड्स को शार्ड करना कठिन है, लेकिन वे फिर भी उच्च लेखन मात्रा उत्पन्न करते हैं, उन्हें माइग्रेट करने में अधिक समय लगता है, और यह प्रक्रिया अभी भी चल रही है. हमने write load को कम करने के लिए अपने एप्लिकेशन्स को आक्रामक रूप से ऑप्टिमाइज़ किया; उदाहरण के लिए, हमने एप्लिकेशन बग्स को ठीक किया जो redundant writes का कारण बन रहे थे और जहाँ उपयुक्त था, वहाँ lazy writes को लागू किया, ताकि traffic spikes के दौरान ट्रैफ़िक को सुचारू किया जा सके. इसके अलावा, जब टेबल फ़ील्ड्स को बैकफ़िल किया जाता है, तो हम अत्यधिक लेखन दबाव को रोकने के लिए सख्त रेट सीमाएँ लागू करते हैं.

चुनौती: हमने PostgreSQL में कई महंगी क्वेरीज़ की पहचान की. अतीत में, इन क्वेरीज़ में अचानक वॉल्यूम स्पाइक्स CPU का अधिक उपयोग कर लेते थे, जिससे ChatGPT और API अनुरोध दोनों धीमे हो जाते थे.

समाधान: कुछ महंगी क्वेरीज़, जैसे वे जो कई टेबल्स को एक साथ जोड़ती हैं, सेवा के प्रदर्शन को काफी हद तक गिरा सकती हैं या पूरी सेवा को भी ठप कर सकती हैं. हमें PostgreSQL क्वेरीज़ को लगातार ऑप्टिमाइज़ करने की ज़रूरत है ताकि यह पक्का हो सके कि वे कुशल हैं और आम ऑनलाइन ट्रांज़ैक्शन प्रोसेसिंग (OLTP) एंटी-पैटर्न से बचा जा सके. उदाहरण के लिए, हमने एक बार एक अत्यधिक महंगी क्वेरी की पहचान की थी जो 12 तालिकाओं को जोड़ती थी, और इस क्वेरी में आने वाले स्पाइक्स पहले के उच्च-गंभीरता वाले SEVs के लिए जिम्मेदार थे. हमें जहाँ तक संभव हो, जटिल मल्टी-टेबल जॉइन्स से बचना चाहिए. अगर जोड़ आवश्यक हों, तो हमने सीखा कि क्वेरी को तोड़कर देखें और जटिल जोड़ लॉजिक को इसके बजाय एप्लिकेशन लेयर में ले जाएँ. इनमें से कई समस्याग्रस्त क्वेरीज़ Object-Relational Mapping frameworks (ORMs) द्वारा उत्पन्न की जाती हैं, इसलिए उनके द्वारा तैयार की गई SQL की सावधानीपूर्वक समीक्षा करना और यह सुनिश्चित करना महत्वपूर्ण है कि वह अपेक्षित रूप से कार्य करे. PostgreSQL में लंबे समय तक चलने वाली निष्क्रिय क्वेरीज़ का मिलना भी सामान्य है. idle_in_transaction_session_timeout जैसे टाइमआउट को कॉन्फ़िगर करना autovacuum को ब्लॉक होने से रोकने के लिए आवश्यक है.

चुनौती: अगर कोई read replica डाउन हो जाता है, तो ट्रैफ़िक को फिर भी अन्य प्रतिकृतियों पर रूट किया जा सकता है. हालांकि, एक ही लेखक पर निर्भर रहने का मतलब है कि फेल होने का एक ही बिंदु होना—अगर वह बंद हो जाता है, तो पूरी सेवा प्रभावित होती है.

Solution: सबसे क्रिटिकल अनुरोधों में आम तौर पर केवल रीड क्वेरीज़ शामिल होती हैं. प्राइमरी में एकल विफलता बिंदु को कम करने के लिए, हमने लेखक से उन पढ़ाई को प्रतिकृतियों पर स्थानांतरित कर दिया, ताकि अगर प्राइमरी बंद हो जाए तो भी वे अनुरोध जारी रह सकें. हालांकि राइट ऑपरेशन अभी भी फेल होंगे, लेकिन इसका असर कम हो जाएगा; अब यह SEV0 नहीं है क्योंकि रीड ऑपरेशन उपलब्ध रहेंगे.

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

चुनौती: हम अक्सर ऐसी स्थितियों का सामना करते हैं जहाँ कुछ अनुरोध PostgreSQL इंस्टेंसेस पर संसाधनों का असमानुपातिक मात्रा में उपभोग करते हैं. इससे समान इंस्टैंसेज़ पर चल रहे अन्य वर्कलोड्स के प्रदर्शन में गिरावट आ सकती है. उदाहरण के लिए, एक नए फीचर का लॉन्च अक्षम क्वेरीज़ पेश कर सकता है जो PostgreSQL CPU का अत्यधिक उपयोग करती हैं, जिससे अन्य महत्वपूर्ण फीचर्स के लिए अनुरोध धीमा हो जाता है.

समाधान: “noisy neighbor” की समस्या को कम करने के लिए, हम वर्कलोड को डेडिकेटेड इंस्टेंस पर अलग करते हैं ताकि यह पक्का हो सके कि रिसोर्स-इंटेंसिव रिक्वेस्ट में अचानक बढ़ोतरी से दूसरे ट्रैफिक पर असर न पड़े. विशेष रूप से, हम अनुरोधों को निम्न-प्राथमिकता और उच्च-प्राथमिकता स्तरों में विभाजित करते हैं और उन्हें अलग-अलग उदाहरणों पर मार्गित करते हैं. इस तरह, भले ही कोई कम-प्राथमिकता वाला वर्कलोड संसाधन-गहन हो जाए, यह उच्च-प्राथमिकता वाले अनुरोधों की प्रदर्शन क्षमता को प्रभावित नहीं करेगा. हम विभिन्न उत्पादों और सेवाओं में भी वही रणनीति अपनाते हैं, ताकि एक उत्पाद की गतिविधि दूसरे के प्रदर्शन या विश्वसनीयता को प्रभावित न करे.

चुनौती: प्रत्येक इंस्टेंस की अधिकतम कनेक्शन सीमा होती है (Azure PostgreSQL में 5,000). कनेक्शन खत्म होना या बहुत सारे निष्क्रिय कनेक्शन इकट्ठा होना आसान है. हमने पहले भी कनेक्शन तूफानों के कारण घटनाओं का सामना किया है, जिनसे सभी उपलब्ध कनेक्शन समाप्त हो गए.

समाधान: हमने डेटाबेस कनेक्शनों को पूल करने के लिए प्रॉक्सी लेयर के रूप में PgBouncer को तैनात किया. इसे स्टेटमेंट या ट्रांज़ैक्शन पूलिंग मोड में चलाने से हम कनेक्शनों का कुशलतापूर्वक पुनः उपयोग कर सकते हैं, जिससे सक्रिय क्लाइंट कनेक्शनों की संख्या काफी कम हो जाती है. इससे कनेक्शन सेटअप लेटेंसी भी कम हो जाती है: हमारे बेंचमार्क में, औसत कनेक्शन समय 50 मिलिसेकंड (ms) से घटकर 5 ms हो गया. इंटर-रीजन कनेक्शन और अनुरोध महंगे हो सकते हैं, इसलिए हम नेटवर्क ओवरहेड और कनेक्शन उपयोग समय को कम करने के लिए प्रॉक्सी, क्लाइंट और प्रतिकृतियों को एक ही क्षेत्र में सह-स्थित करते हैं. इसके अलावा, PgBouncer को सावधानी से कॉन्फ़िगर करना चाहिए. idle timeouts जैसी सेटिंग्स कनेक्शन की समाप्ति से बचाने के लिए महत्वपूर्ण हैं.

चुनौती: cache misses में अचानक वृद्धि PostgreSQL database पर पढ़ने की संख्या में उछाल ला सकती है, जिससे CPU संतृप्त हो जाता है और उपयोगकर्ता अनुरोध धीमे हो जाते हैं.

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

चुनौती: प्राथमिक स्ट्रीम Write Ahead Log (WAL) डेटा को हर read replica तक स्ट्रीम करती है. जैसे-जैसे प्रतिकृतियों की संख्या बढ़ती है, प्राथमिक को अधिक उदाहरणों को WAL भेजना पड़ता है, जिससे नेटवर्क बैंडविड्थ और CPU दोनों पर दबाव बढ़ता है. इससे प्रतिकृति विलंब अधिक और अधिक अस्थिर हो जाता है, जिससे सिस्टम को विश्वसनीय तरीके से स्केल करना कठिन हो जाता है.

समाधान: हम लेटेंसी को कम करने के लिए कई भौगोलिक क्षेत्रों में लगभग 50 रीड रेप्लिका चलाते हैं. हालांकि, मौजूदा आर्किटेक्चर के साथ, प्राइमरी को प्रत्येक रेप्लिका को WAL स्ट्रीम करना आवश्यक है. हालांकि यह वर्तमान में बहुत बड़े इंस्टेंस प्रकारों और उच्च-नेटवर्क बैंडविड्थ के साथ अच्छी तरह से स्केल करता है, हम प्राइमरी को अंततः ओवरलोड किए बिना अनिश्चितकाल तक रेप्लिका नहीं जोड़ सकते. इसे हल करने के लिए, हम Azure PostgreSQL टीम के साथ कास्केडिंग रेप्लिकेशन⁠(एक नई विंडो में खुलेगा) पर काम कर रहे हैं, जहां मध्यवर्ती प्रतिकृतियां डाउनस्ट्रीम प्रतिकृतियों को WAL भेजती हैं. यह तरीका हमें मुख्य प्रणाली पर बोझ डाले बिना, संभावित रूप से सौ से अधिक प्रतिकृतियों तक विस्तार करने की अनुमति देता है. हालांकि, यह अतिरिक्त परिचालन जटिलता भी लाता है, विशेष रूप से फेलओवर प्रबंधन के मामले में. यह फीचर अभी भी परीक्षण में है; हम इसे उत्पादन में लागू करने से पहले सुनिश्चित करेंगे कि यह मजबूत हो और सुरक्षित रूप से फेलओवर कर सके.

चुनौती: कुछ खास एंडपॉइंट्स पर अचानक ट्रैफिक बढ़ने, महंगी क्वेरीज़ की बाढ़ आने, या रिट्राई स्टॉर्म से CPU, I/O, और कनेक्शन जैसे ज़रूरी रिसोर्स तेज़ी से खत्म हो सकते हैं, जिससे सर्विस की क्वालिटी में बड़े पैमाने पर गिरावट आती है.

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

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

समाधान: केवल हल्के स्कीमा परिवर्तन की अनुमति है, जैसे कुछ कॉलम जोड़ना या हटाना जो पूरी तालिका को फिर से लिखने की प्रक्रिया को ट्रिगर नहीं करते. हम स्कीमा परिवर्तनों पर पाँच-सेकंड का सख्त टाइमआउट लागू करते हैं. इंडेक्स को एक साथ बनाना और हटाना अनुमत है. स्कीमा परिवर्तन केवल मौजूदा तालिकाओं तक सीमित हैं. अगर किसी नए फीचर के लिए अतिरिक्त टेबल की आवश्यकता होती है, तो उन्हें PostgreSQL के बजाय Azure CosmosDB जैसे वैकल्पिक शार्डेड सिस्टम में होना चाहिए. टेबल फ़ील्ड को बैकफ़िल करते समय, हम राइट स्पाइक्स को रोकने के लिए सख्त रेट लिमिट लागू करते हैं. हालांकि इस प्रक्रिया में कभी-कभी एक हफ्ते से अधिक समय लग सकता है, यह स्थिरता सुनिश्चित करती है और उत्पादन पर किसी भी प्रभाव से बचाती है.

यह प्रयास दिखाता है कि सही डिज़ाइन और अनुकूलन के साथ, Azure PostgreSQL को सबसे बड़े उत्पादन वर्कलोड्स को संभालने के लिए स्केल किया जा सकता है. PostgreSQL रीड-हेवी वर्कलोड्स के लिए लाखों QPS संभालता है, जो OpenAI के सबसे महत्वपूर्ण प्रोडक्ट्स जैसे ChatGPT और API प्लेटफॉर्म को शक्ति प्रदान करता है. हमने लगभग 50 रीड रेप्लिका जोड़े, जबकि रेप्लिकेशन लैग को लगभग ज़ीरो रखा, जियो-डिस्ट्रिब्यूटेड क्षेत्रों में लो-लेटेंसी रीड बनाए रखी, और भविष्य की ग्रोथ को सपोर्ट करने के लिए पर्याप्त कैपेसिटी हेडरुम बनाया.

यह स्केलिंग लेटेंसी को न्यूनतम करते हुए और विश्वसनीयता में सुधार करते हुए काम करती है. हम प्रोडक्शन में लगातार कम डबल-डिजिट मिलीसेकंड p99 क्लाइंट-साइड लेटेंसी और 99.999% उपलब्धता प्रदान करते हैं. और पिछले 12 महीनों में, हमारे पास केवल एक SEV-0 PostgreSQL घटना हुई है (यह ChatGPT ImageGen के वायरल लॉन्च⁠(एक नई विंडो में खुलेगा) के दौरान हुई थी, जब 100 मिलियन से अधिक नए उपयोगकर्ताओं ने एक सप्ताह के भीतर साइन अप किया और लिखने का ट्रैफ़िक अचानक 10 गुना से अधिक बढ़ गया.)

हालांकि हम PostgreSQL के साथ अब तक की प्रगति से खुश हैं, हम इसकी सीमाओं को और आगे बढ़ाते रहते हैं ताकि भविष्य की वृद्धि के लिए हमारे पास पर्याप्त अवसर हो. हमने पहले ही shardable write-heavy workloads को CosmosDB जैसे हमारे sharded सिस्टम्स में माइग्रेट कर दिया है. शेष write-heavy वर्कलोड्स को शार्ड करना अधिक चुनौतीपूर्ण है—हम PostgreSQL प्राइमरी से लेखन को और अधिक ऑफ़लोड करने के लिए उन्हें भी सक्रिय रूप से माइग्रेट कर रहे हैं. हम Azure के साथ मिलकर cascading replication को सक्षम करने पर भी काम कर रहे हैं, ताकि हम सुरक्षित रूप से अधिक पढ़ने की प्रतिकृतियों तक स्केल कर सकें.

आगे देखते हुए, हम स्केलिंग के लिए अतिरिक्त तरीकों की खोज जारी रखेंगे, जैसे कि sharded PostgreSQL या अन्य वितरित प्रणालियाँ, क्योंकि हमारी इन्फ्रास्ट्रक्चर की मांगें बढ़ती जा रही हैं.