Google Cloud Professional Cloud Database Engineer
अंतिम समीक्षा: मई 2026
PCDE परीक्षा द्वारा परखे जाने वाले architectural patterns का स्कैन-योग्य संदर्भ। ऊपर से नीचे पढ़ें या किसी section पर जाएं।
एक वैश्विक ई-कॉमर्स प्लेटफॉर्म जिसके लिए कई महाद्वीपों में ACID लेनदेन, मजबूत सुसंगतता और 99.999% उपलब्धता की आवश्यकता है।
मल्टी-रीजन कॉन्फ़िगरेशन (जैसे, nam-eur-asia) के साथ Cloud Spanner।
क्यों: Spanner एकमात्र GCP प्रबंधित सेवा है जो 99.999% SLA के साथ वैश्विक रूप से वितरित, मजबूत सुसंगत ACID लेनदेन प्रदान करती है।
जटिल स्टोर्ड प्रोसीजर और विश्लेषणात्मक क्वेरी आवश्यकताओं के साथ एक बड़े, उच्च-प्रदर्शन वाले Oracle OLTP डेटाबेस को माइग्रेट करना।
AlloyDB for PostgreSQL।
क्यों: AlloyDB बेहतर PostgreSQL प्रदर्शन, Oracle अनुकूलता सुविधाएँ, और लेनदेन संबंधी वर्कलोड को प्रभावित किए बिना विश्लेषणात्मक प्रश्नों (HTAP) को तेज करने के लिए एक कॉलमिनर इंजन प्रदान करता है।
समय-श्रृंखला डेटा (जैसे, IoT, लॉग) का उच्च-थ्रूपुट (लाखों OPS) अंतर्ग्रहण जिसके लिए कम-विलंबता रीड और स्वचालित डेटा समाप्ति की आवश्यकता होती है।
`(entity_id)#(reverse_timestamp)` की पंक्ति कुंजी डिज़ाइन और कचरा संग्रह नीति के साथ Cloud Bigtable।
क्यों: Bigtable बड़े पैमाने पर, कम-विलंबता कुंजी/मान वर्कलोड के लिए डिज़ाइन किया गया है। पंक्ति कुंजी में एक रिवर्स टाइमस्टैम्प कुशल स्कैन के लिए हाल के डेटा को सह-स्थानित करता है। कचरा संग्रह TTL को संभालता है।
मोबाइल या वेब एप्लिकेशन जिसके लिए लचीली स्कीमा, क्लाइंट के लिए रीयल-टाइम डेटा सिंक्रनाइज़ेशन और ऑफ़लाइन समर्थन की आवश्यकता होती है।
नेटिव मोड में Firestore।
क्यों: Firestore इस सर्वरलेस ऐप बैकएंड पैटर्न के लिए विशेष रूप से बनाया गया है, जो अपने क्लाइंट SDK के माध्यम से आउट-ऑफ-द-बॉक्स रीयल-टाइम लिसनर्स और ऑफ़लाइन परसिस्टेंस प्रदान करता है।
AI/ML अनुप्रयोगों (जैसे, RAG, अनुशंसाएँ) के लिए बड़े पैमाने पर (10M+ वेक्टर्स) समानता खोज जिसके लिए सब-100ms विलंबता की आवश्यकता होती है।
pgvector एक्सटेंशन और ScaNN इंडेक्स के साथ AlloyDB for PostgreSQL।
क्यों: AlloyDB अनुमानित निकटतम पड़ोसी (ANN) खोज के लिए Google's उच्च-प्रदर्शन वाले ScaNN एल्गोरिथम को एकीकृत करता है, जो बड़े पैमाने पर मानक वेक्टर खोज कार्यान्वयन से बेहतर प्रदर्शन करता है।
एक राइट-हेवी वर्कलोड के लिए Cloud Spanner स्कीमा डिज़ाइन करना ताकि एक ही सर्वर पर हॉटस्पॉट को रोका जा सके।
प्राथमिक कुंजी डिज़ाइन करें जो पहले कुंजी भाग के रूप में मोनोटोनिक रूप से बढ़ते हुए मानों (जैसे, अनुक्रमिक ID, टाइमस्टैम्प) का उपयोग न करें। इसके बजाय UUIDs, हैश किए गए मान, या बिट-रिवर्स किए गए अनुक्रमों का उपयोग करें।
क्यों: Spanner डेटा को प्राथमिक कुंजी द्वारा लेक्सिकोग्राफिक रूप से वितरित करता है। अनुक्रमिक कुंजियाँ सभी राइट्स को एक ही स्प्लिट पर निर्देशित करती हैं, जिससे एक हॉटस्पॉट बनता है। यादृच्छिक रूप से वितरित कुंजियाँ सभी स्प्लिट्स में राइट्स को फैलाती हैं।
एक Spanner स्कीमा में एक मजबूत पैरेंट-चाइल्ड संबंध (जैसे, ग्राहक और ऑर्डर) है और क्वेरी अक्सर अपने सभी बच्चों के साथ एक पैरेंट को फेच करती हैं।
इंटरलीव्ड तालिकाओं का उपयोग करें, चाइल्ड तालिका को `INTERLEAVE IN PARENT` के साथ परिभाषित करें।
क्यों: इंटरलीविंग चाइल्ड पंक्तियों को उनके पैरेंट पंक्ति के साथ स्टोरेज में भौतिक रूप से सह-स्थानित करता है। यह पैरेंट-चाइल्ड जॉइन को अत्यधिक कुशल बनाता है, क्योंकि यह एक ही स्प्लिट पर एक अत्यधिक अनुकूलित रेंज स्कैन बन जाता है।
एक बड़े वाहन बेड़े (50k+ writes/sec) के लिए रीयल-टाइम स्थानों को ट्रैक करना, जिसमें भौगोलिक क्षेत्र के भीतर वाहनों को खोजने के लिए क्वेरी शामिल हैं।
वाहन के GeoHash द्वारा उपसर्गित पंक्ति कुंजी के साथ Cloud Bigtable।
क्यों: Bigtable अत्यधिक राइट थ्रूपुट को संभालता है। GeoHash एन्कोडिंग 2D निर्देशांकों को एक 1D स्ट्रिंग में परिवर्तित करता है जहां उपसर्ग भौगोलिक निकटता का प्रतिनिधित्व करते हैं, जिससे कुशल भू-स्थानिक रेंज स्कैन सक्षम होते हैं।
जटिल विश्लेषणात्मक SQL क्वेरी के साथ पेटाबाइट-स्केल डेटा (जैसे, जीनोमिक डेटा, लॉग) को संग्रहीत और विश्लेषण करना।
Cloud Storage में रॉ डेटा संग्रहीत करें और बाहरी तालिकाओं का उपयोग करके सीधे BigQuery से क्वेरी करें, या नेटिव BigQuery स्टोरेज में लोड करें।
क्यों: BigQuery पेटाबाइट-स्केल एनालिटिक्स के लिए बनाया गया एक सर्वरलेस डेटा वेयरहाउस है। स्टोरेज और कंप्यूट का इसका अलगाव OLAP वर्कलोड के लिए अद्वितीय क्वेरी प्रदर्शन और लागत-प्रभावशीलता प्रदान करता है।
जटिल डेटा संरचनाओं (हैश, सेट) के लिए एक उच्च-उपलब्धता इन-मेमोरी कैश जिसमें कैश अमान्यकरण के लिए पब/सब क्षमताएं हों।
रीड रेप्लिका के साथ Memorystore for Redis Standard Tier।
क्यों: Standard Tier स्वचालित फेलओवर के साथ 99.9% SLA प्रदान करता है। Redis Memcached के विपरीत, जटिल डेटा प्रकारों और पब/सब का समर्थन करता है। रीड रेप्लिका रीड थ्रूपुट को स्केल कर सकते हैं।
Spanner पर एक मल्टी-टेनेंट SaaS एप्लिकेशन डिज़ाइन करना जिसके लिए प्रति टेनेंट मजबूत डेटा अलगाव और प्रदर्शन गारंटी की आवश्यकता होती है।
सभी तालिकाओं के लिए प्राथमिक कुंजी के पहले घटक के रूप में tenant_id का उपयोग करें। मजबूत अलगाव के लिए, एक ही Spanner इंस्टेंस के भीतर डेटाबेस-प्रति-टेनेंट मॉडल का उपयोग करें।
क्यों: एक tenant_id उपसर्ग स्वाभाविक रूप से एक ही टेनेंट के सभी डेटा को सह-स्थानित करता है, क्वेरी को अनुकूलित करता है और Spanner को टेनेंट द्वारा डेटा को विभाजित करने की अनुमति देता है। डेटाबेस-प्रति-टेनेंट सबसे मजबूत लॉजिकल अलगाव प्रदान करता है।
एक Cloud SQL डेटाबेस धीमी क्वेरी प्रदर्शन और उच्च CPU उपयोग का अनुभव कर रहा है।
सबसे अधिक संसाधन-गहन क्वेरी की पहचान करने, उनकी निष्पादन योजनाओं का विश्लेषण करने और गुम अनुक्रमित या अक्षम पैटर्न की पहचान करने के लिए Query Insights का उपयोग करें।
क्यों: Query Insights Cloud SQL में क्वेरी प्रदर्शन का निदान करने के लिए प्राथमिक, अंतर्निहित उपकरण है। यह क्वेरी लोड को विज़ुअलाइज़ करता है, प्रतीक्षा घटनाओं की पहचान करता है, और तीसरे पक्ष के उपकरणों के बिना मूल कारण का पता लगाने में मदद करता है।
एक संगठन को कई GCP प्रोजेक्ट्स में फैले दर्जनों डेटाबेस इंस्टेंस के लिए एक सिंगल डैशबोर्ड और अलर्टिंग नीति सेट की आवश्यकता है।
एक केंद्रीय प्रोजेक्ट में एक Cloud Monitoring वर्कस्पेस बनाएं और डेटाबेस इंस्टेंस वाले सभी प्रोजेक्ट्स को शामिल करने के लिए इसकी "मेट्रिक्स स्कोप" को कॉन्फ़िगर करें।
क्यों: मेट्रिक्स स्कोप एक सिंगल Monitoring वर्कस्पेस को कई प्रोजेक्ट्स से मेट्रिक्स को एकत्रित और प्रदर्शित करने की अनुमति देते हैं, जिससे डेटा दोहराव या जटिल कॉन्फ़िगरेशन के बिना एक एकीकृत दृश्य प्रदान होता है।
देव, स्टेजिंग और प्रोडक्शन वातावरण में Cloud SQL इंस्टेंस को लगातार और संस्करण नियंत्रण के साथ प्रोविजन और प्रबंधित करने की आवश्यकता है।
Google Cloud प्रदाता के साथ Terraform का उपयोग करें। एक Cloud SQL मॉड्यूल परिभाषित करें और प्रत्येक वातावरण के लिए अलग-अलग `.tfvars` फ़ाइलों का उपयोग करें।
क्यों: Terraform Infrastructure as Code (IaC) प्रदान करता है, जो दोहराए जाने योग्य, ऑडिट करने योग्य और संस्करण-नियंत्रित डिप्लॉयमेंट को सक्षम बनाता है। यह मैन्युअल कॉन्फ़िगरेशन त्रुटियों से बचता है और वातावरण में स्थिरता सुनिश्चित करता है।
एक ठेकेदार को अस्थायी रूप से बढ़ाए गए डेटाबेस एक्सेस की आवश्यकता है जिसे 4 घंटे के बाद स्वचालित रूप से रद्द कर दिया जाना चाहिए।
आवश्यक IAM भूमिका को एक IAM कंडीशन के साथ प्रदान करें जो एक समय-आधारित अभिव्यक्ति (`request.time < timestamp(...)`) का उपयोग करती है।
क्यों: IAM कंडीशंस मैन्युअल सफाई के बिना समय-सीमित एक्सेस प्रदान करने का एक मूल, सुरक्षित तरीका प्रदान करती हैं, जो त्रुटि-प्रवण है। टाइमस्टैम्प समाप्त होने के बाद एक्सेस स्वचालित रूप से अस्वीकृत हो जाता है।
एक सुरक्षा नीति के लिए आवश्यक है कि सभी डेटाबेस डिस्क एन्क्रिप्शन ग्राहक-प्रबंधित कुंजियों (CMEK) का उपयोग नियंत्रित रोटेशन के साथ करें।
Cloud KMS से एक कुंजी का उपयोग करने के लिए Cloud SQL या AlloyDB इंस्टेंस को कॉन्फ़िगर करें। KMS कुंजी पर स्वचालित रोटेशन कॉन्फ़िगर करें।
क्यों: CMEK आराम पर एन्क्रिप्शन के लिए उपयोग की जाने वाली कुंजियों पर नियंत्रण और ऑडिट करने की क्षमता प्रदान करता है। Cloud KMS कुंजी जीवनचक्र प्रबंधन को सहजता से संभालता है, जिसमें स्वचालित रोटेशन भी शामिल है।
अनुपालन के लिए Cloud SQL for PostgreSQL इंस्टेंस पर निष्पादित सभी SQL क्वेरी को कैप्चर करने की आवश्यकता है, जिसमें लॉग 7 वर्षों तक बनाए रखा जाए।
इंस्टेंस पर `pgaudit` एक्सटेंशन सक्षम करें। डेटा एक्सेस के लिए Cloud Audit Logs कॉन्फ़िगर करें। दीर्घकालिक प्रतिधारण और विश्लेषण के लिए Cloud Logging से BigQuery तक एक लॉग सिंक बनाएं।
क्यों: pgaudit विस्तृत SQL-स्तर ऑडिटिंग प्रदान करता है। BigQuery में लॉग को सिंक करना Cloud Logging के डिफ़ॉल्ट से परे दीर्घकालिक, खोजने योग्य लॉग प्रतिधारण के लिए मानक, लागत-प्रभावी पैटर्न है।
डेटा विश्लेषकों को लेनदेन संबंधी वर्कलोड को प्रभावित किए बिना प्रोडक्शन Cloud SQL डेटा पर भारी विश्लेषणात्मक क्वेरी चलाने की आवश्यकता है।
एक रीड रेप्लिका बनाएं और सभी विश्लेषणात्मक क्वेरी को उस पर निर्देशित करें। अधिक जटिल एनालिटिक्स के लिए, रीड रेप्लिका के विरुद्ध BigQuery फेडरेटेड क्वेरी का उपयोग करें।
क्यों: एक रीड रेप्लिका एनालिटिकल रीड ट्रैफिक को प्राइमरी इंस्टेंस से पूरी तरह से अलग कर देता है, जिससे OLTP प्रदर्शन सुरक्षित रहता है। फेडरेशन एक अलग ETL पाइपलाइन के बिना BigQuery के शक्तिशाली इंजन का उपयोग करने की अनुमति देता है।
एक Bigtable क्लस्टर असमान CPU लोड दिखाता है, जिसमें कुछ नोड्स का भारी उपयोग होता है जबकि अन्य निष्क्रिय होते हैं, जो एक प्रदर्शन बाधा का संकेत देता है।
एक्सेस पैटर्न का विश्लेषण करने और उन विशिष्ट पंक्ति कुंजी श्रेणियों की पहचान करने के लिए Cloud Console में Key Visualizer टूल का उपयोग करें जिन्हें बहुत बार एक्सेस किया जा रहा है (हॉटस्पॉटिंग)।
क्यों: Key Visualizer Bigtable प्रदर्शन समस्याओं के लिए उद्देश्य-निर्मित नैदानिक उपकरण है। यह कुंजी एक्सेस का एक हीट मैप प्रदान करता है, जिससे स्कीमा रीडिजाइन के माध्यम से संबोधित किए जाने वाले हॉटस्पॉट की पहचान करना आसान हो जाता है।
Cloud SQL OLTP डेटाबेस से BigQuery डेटा वेयरहाउस में लगभग रीयल-टाइम में परिवर्तनों को दोहराने की आवश्यकता है।
सोर्स Cloud SQL इंस्टेंस से सीधे BigQuery तक एक चेंज डेटा कैप्चर (CDC) स्ट्रीम कॉन्फ़िगर करने के लिए Datastream का उपयोग करें।
क्यों: Datastream एक प्रबंधित, कम-विलंबता CDC सेवा है जो डेटाबेस लॉग को पढ़ती है, स्रोत पर प्रभाव को कम करती है। यह स्कीमा बहाव को संभालती है और BigQuery को परिवर्तनों को मज़बूती से वितरित करती है।
ट्रैफिक स्पाइक्स के दौरान तेजी से स्केलिंग के कारण एक Cloud Run एप्लिकेशन डेटाबेस कनेक्शन को समाप्त कर रहा है।
Cloud SQL Auth Proxy को एक साइडकार कंटेनर के रूप में डिप्लॉय करें और इसे कनेक्शन पूलिंग के लिए कॉन्फ़िगर करें (या PgBouncer जैसे समर्पित पूलर के साथ इसका उपयोग करें)।
क्यों: सर्वरलेस प्लेटफॉर्म हजारों इंस्टेंस तक स्केल कर सकते हैं, जिससे डेटाबेस कनेक्शन सीमाएं अभिभूत हो जाती हैं। एक कनेक्शन पूलर इन कई, अल्पकालिक एप्लिकेशन कनेक्शनों को डेटाबेस कनेक्शन के एक छोटे, स्थिर सेट पर मल्टीप्लेक्स करता है।
अधिकतम 30 मिनट के डाउनटाइम के साथ एक बड़े (5TB) ऑन-प्रिमाइसेस MySQL डेटाबेस को Cloud SQL for MySQL में माइग्रेट करना।
एक निरंतर प्रतिकृति कार्य को कॉन्फ़िगर करने के लिए Database Migration Service (DMS) का उपयोग करें। DMS एक प्रारंभिक लोड करता है और फिर कटओवर तक परिवर्तनों को स्ट्रीम करता है।
क्यों: DMS न्यूनतम-डाउनटाइम माइग्रेशन के लिए प्रबंधित समाधान है। निरंतर प्रतिकृति का अर्थ है कि एकमात्र डाउनटाइम वह समय है जो राइट्स को रोकने, अंतिम सिंक की प्रतीक्षा करने और एप्लिकेशन को नए डेटाबेस पर इंगित करने में लगता है।
Oracle डेटाबेस को AlloyDB for PostgreSQL में माइग्रेट करना, जिसमें जटिल PL/SQL स्टोर्ड प्रोसीजर शामिल हैं।
डेटा माइग्रेशन के लिए DMS का उपयोग करें। स्कीमा और PL/SQL को PL/pgSQL में बदलने के लिए स्कीमा रूपांतरण टूल (जैसे Ora2Pg या DMS Schema Conversion) का उपयोग करें, जिसके बाद मैन्युअल समीक्षा और परीक्षण करें।
क्यों: विषम माइग्रेशन के लिए डेटा माइग्रेशन (DMS द्वारा नियंत्रित) और स्कीमा/कोड रूपांतरण दोनों की आवश्यकता होती है। स्वचालित उपकरण रूपांतरण का ~80% संभालते हैं, लेकिन Oracle-विशिष्ट सुविधाओं के लिए हमेशा मैन्युअल प्रयास की आवश्यकता होती है।
एक डेटाबेस को ऑन-प्रिमाइसेस डेटासेंटर से Google Cloud में माइग्रेट करने के बाद डेटा अखंडता और पूर्णता को सत्यापित करने की आवश्यकता है।
ओपन-सोर्स Data Validation Tool (DVT) का उपयोग करें। स्रोत और लक्ष्य के बीच पंक्ति गणना, कॉलम-स्तरीय एकत्रीकरण (न्यूनतम, अधिकतम, योग), और पंक्ति-स्तरीय हैश की तुलना करने के लिए इसे कॉन्फ़िगर करें।
क्यों: DVT डेटा सत्यापन के लिए एक व्यापक, स्केलेबल और अनुकूलन योग्य ढांचा प्रदान करता है जो सरल पंक्ति गणना से परे जाता है, सूक्ष्म डेटा भ्रष्टाचार या परिवर्तन मुद्दों को पकड़ता है।
एक शार्ड किए गए MySQL एप्लिकेशन को एक सिंगल, विश्व स्तर पर सुसंगत डेटाबेस में माइग्रेट करना।
प्रत्येक शार्ड को एक साथ एक ही Cloud Spanner डेटाबेस में माइग्रेट करने के लिए कई समानांतर Dataflow जॉब्स का उपयोग करें। एप्लिकेशन-स्तर की शार्डिंग की आवश्यकता को समाप्त करने के लिए स्कीमा को रीडिजाइन करें।
क्यों: Spanner जटिल शार्ड किए गए आर्किटेक्चर को बदलने के लिए डिज़ाइन किया गया है। Dataflow के साथ एक समानांतर माइग्रेशन दृष्टिकोण बड़े, शार्ड किए गए डेटासेट को Spanner में समेकित करने का सबसे समय-कुशल तरीका है।
Windows Authentication (Active Directory) का उपयोग करके SQL Server डेटाबेस को Cloud SQL for PostgreSQL में माइग्रेट करना।
IAM डेटाबेस प्रमाणीकरण का उपयोग करके Cloud SQL को Cloud Identity के साथ एकीकृत करें। AD समूहों को GCDS के माध्यम से Google Groups में सिंक करें, और डेटाबेस भूमिकाओं को इन समूहों पर मैप करें।
क्यों: यह दृष्टिकोण AD के केंद्रीकृत, समूह-आधारित एक्सेस कंट्रोल मॉडल को क्लाउड-नेटिव तरीके से दोहराता है, जिससे मैन्युअल उपयोगकर्ता/पासवर्ड प्रबंधन से बचा जाता है और मौजूदा पहचान संरचनाओं का लाभ उठाया जाता है।
Amazon DynamoDB से Cloud Bigtable में एक एप्लिकेशन को माइग्रेट करना।
DynamoDB कंपोजिट प्राथमिक कुंजी (पार्टिशन कुंजी + सॉर्ट कुंजी) को एक डेलीमीटर (जैसे, `partitionKey#sortKey`) द्वारा अलग किए गए एक संयोजित Bigtable पंक्ति कुंजी पर मैप करें।
क्यों: यह पंक्ति कुंजी डिज़ाइन DynamoDB कंपोजिट कुंजी की क्वेरी क्षमताओं को संरक्षित करता है, जिससे पार्टिशन कुंजी उपसर्ग द्वारा कुशल लुकअप और सॉर्ट कुंजी हिस्से पर रेंज स्कैन की अनुमति मिलती है।
एक हाई-उपलब्धता Cloud SQL इंस्टेंस से कनेक्ट होने वाले एप्लिकेशन को मैन्युअल हस्तक्षेप के बिना एक ज़ोनल फेलओवर से बचना चाहिए।
स्थिर IP पते के बजाय इंस्टेंस कनेक्शन नाम (project:region:instance) के साथ Cloud SQL Auth Proxy का उपयोग करके डेटाबेस से कनेक्ट करें।
क्यों: फेलओवर के दौरान इंस्टेंस का IP पता बदल जाता है। Auth Proxy और इंस्टेंस कनेक्शन नाम एक स्थिर एंडपॉइंट प्रदान करते हैं जो स्वचालित रूप से वर्तमान प्राइमरी इंस्टेंस के IP पते पर हल हो जाता है।
एक वैश्विक Spanner एप्लिकेशन के उपयोगकर्ता उत्तरी अमेरिका और एशिया में हैं। राइट्स मुख्य रूप से NA से उत्पन्न होते हैं, लेकिन एशियाई उपयोगकर्ताओं को कम-विलंबता रीड की आवश्यकता होती है।
उत्तरी अमेरिका (`nam*`) में लीडर रीजन के साथ एक मल्टी-रीजन कॉन्फ़िगरेशन का उपयोग करें। एशिया में रीड्स स्थानीय रीड-ओनली रेप्लिका द्वारा परोसे जाएंगे।
क्यों: Spanner में राइट्स लीडर रीजन के माध्यम से रूट किए जाते हैं, इसलिए इसे राइट स्रोत के पास रखने से राइट विलंबता कम होती है। रीड रेप्लिका अन्य रीजनों में विश्व स्तर पर वितरित उपयोगकर्ताओं के लिए कम-विलंबता रीड प्रदान करते हैं।
एक AlloyDB-समर्थित एप्लिकेशन में 10:1 रीड-टू-राइट अनुपात है और इसे 99.99% उपलब्धता बनाए रखते हुए उच्च रीड ट्रैफिक को संभालने के लिए स्केल करने की आवश्यकता है।
उच्च उपलब्धता के साथ प्राथमिक इंस्टेंस को कॉन्फ़िगर करें और कई रीड पूल इंस्टेंस जोड़ें। रीड ट्रैफिक को रीड पूल पर निर्देशित करें।
क्यों: AlloyDB उच्च उपलब्धता 99.99% SLA प्रदान करती है। रीड पूल इंस्टेंस क्षैतिज रीड स्केलिंग के लिए डिज़ाइन किए गए हैं, जो प्राथमिक इंस्टेंस से समर्पित रीड-अनुकूलित नोड्स पर ट्रैफिक को ऑफलोड करते हैं।
SSD स्टोरेज के साथ एक विलंबता-संवेदनशील Cloud SQL इंस्टेंस में अपर्याप्त I/O प्रदर्शन है।
इंस्टेंस के प्रोविजन किए गए स्टोरेज आकार को बढ़ाएँ।
क्यों: Cloud SQL में, रीड और राइट दोनों IOPS प्रोविजन किए गए परसिस्टेंट डिस्क स्टोरेज की मात्रा के साथ रैखिक रूप से बढ़ते हैं। डिस्क आकार बढ़ाना उपलब्ध IOPS बढ़ाने का सीधा तरीका है।
एक महत्वपूर्ण Cloud SQL डेटाबेस में एक जोखिम भरा स्कीमा परिवर्तन को तेजी से रोलबैक क्षमता के साथ डिप्लॉय करने की आवश्यकता है।
प्रोडक्शन (ब्लू) इंस्टेंस का एक रीड रेप्लिका बनाएं। रेप्लिका को एक स्टैंडअलोन इंस्टेंस (ग्रीन) में प्रमोट करें, स्कीमा परिवर्तनों को लागू करें और सत्यापित करें। फिर, एप्लिकेशन ट्रैफिक को ग्रीन इंस्टेंस पर रीडायरेक्ट करें। रोलबैक के लिए ब्लू को चालू रखें।
क्यों: यह पैटर्न लाइव सिस्टम को प्रभावित किए बिना डेटा की उत्पादन-स्तर की प्रतिलिपि पर परिवर्तनों के पूर्ण परीक्षण की अनुमति देता है। ट्रैफिक को तुरंत स्विच किया जा सकता है, और रोलबैक ब्लू इंस्टेंस पर ट्रैफिक को वापस इंगित करने जितना ही सरल है।
उत्पादन वातावरण को प्रभावित किए बिना तिमाही आधार पर डेटाबेस आपदा रिकवरी योजना का परीक्षण करने की आवश्यकता है।
हाल के उत्पादन बैकअप से पुनर्स्थापित करके एक अस्थायी परीक्षण इंस्टेंस बनाएं। इस परीक्षण इंस्टेंस के खिलाफ प्रलेखित DR प्रक्रियाओं को निष्पादित करें, जिसमें सिम्युलेटेड फेलओवर और एप्लिकेशन रीकनेक्शन परीक्षण शामिल हैं।
क्यों: पुनर्स्थापित बैकअप पर परीक्षण RTO/RPO और रिकवरी प्रक्रियाओं को मान्य करने के लिए एक यथार्थवादी वातावरण प्रदान करता है, जिससे उत्पादन आउटेज का कारण बनने का जोखिम नहीं होता है।
एक Cloud Run सेवा को सार्वजनिक इंटरनेट पर ट्रैफिक गुजारे बिना एक Cloud SQL इंस्टेंस से सुरक्षित रूप से कनेक्ट करने की आवश्यकता है।
एक निजी IP के साथ Cloud SQL को कॉन्फ़िगर करें। उसी VPC में एक Serverless VPC Access कनेक्टर बनाएं और ट्रैफिक को उसके माध्यम से रूट करने के लिए Cloud Run सेवा को कॉन्फ़िगर करें।
क्यों: यह सर्वरलेस कंप्यूट को VPC-नेटिव संसाधनों से कनेक्ट करने के लिए मानक, सुरक्षित पैटर्न है। कनेक्टर सर्वरलेस वातावरण और आपके VPC को जोड़ता है, जिससे सभी ट्रैफिक Google के निजी नेटवर्क पर रहता है।
डाउनटाइम के बिना एक विशाल, सक्रिय रूप से लिखे गए Cloud Spanner तालिका में एक नया, गैर-शून्य कॉलम जोड़ना।
1. कॉलम को नल्लेबल के रूप में जोड़ें। 2. नए कॉलम में लिखने के लिए एप्लिकेशन कोड अपडेट करें। 3. Dataflow का उपयोग करके बैचों में मौजूदा पंक्तियों को बैकफिल करें। 4. बैकफिल के बाद, कॉलम को NOT NULL में बदलें।
क्यों: यह बहु-चरणीय प्रक्रिया बड़ी तालिकाओं के लिए मानक ऑनलाइन स्कीमा परिवर्तन पैटर्न है। यह लंबी अवधि के लिए तालिका को लॉक करने या एक ही लेनदेन में बड़े पैमाने पर, प्रदर्शन-प्रभावित बैकफिल ऑपरेशन का कारण बनने से बचता है।
