समर्पित बनाम साझा डेटाबेस: प्रदर्शन और अलगाव

बहु-किरायेदार SaaS अनुप्रयोगों की वास्तुकला पर माइक्रोसॉफ्ट का आधिकारिक दस्तावेज तीन किरायेदारी मॉडल को अलग करता है, जिन्हें आम तौर पर साइलो (प्रति किरायेदार समर्पित संसाधन), पूल (पूरी तरह से साझा संसाधन) और ब्रिज (दोनों का मिश्रण, कुछ अलग किरायेदार, अन्य साझा) कहा जाता है। ये तीन मॉडल स्कीमा, डेटाबेस या संपूर्ण क्लस्टर स्तर पर सीधे पोस्टग्रेज पर लागू होते हैं।

सीधे तौर पर, पोस्टग्रेज बैकएंड के लिए, यह तीन अलग-अलग आर्किटेक्चर देता है। साझा स्कीमा (एक एकल आधार, एक tenant_idकॉलम, आरएलएस नीतियां जो पंक्तियों को फ़िल्टर करती हैं) मल्टी-टेनेंट गाइड में सबसे आम पूल मॉडल है: किफायती, लेकिन दो क्लाइंट के बीच की सीमा तालिका द्वारा मूल्यांकन की गई SQL अभिव्यक्ति बन जाती है। साझा क्लस्टर पर प्रति किरायेदार आधार एक मध्यवर्ती ब्रिज मॉडल है: प्रत्येक किरायेदार का अपना पोस्टग्रेज आधार (एक वास्तविक CREATE DATABASEकमांड) होता है, लेकिन एक ही भौतिक क्लस्टर पर कई आधार सह-अस्तित्व में होते हैं, इसलिए सीपीयू, आईओ और कनेक्शन साझा करते हैं। प्रति किरायेदार पूरी तरह से समर्पित क्लस्टर पूर्ण साइलो मॉडल है: पूरी तरह से पृथक सीपीयू, रैम और आईओ संसाधन, आम तौर पर उच्च अनुपालन या लोड मुद्दों वाले किरायेदारों के लिए आरक्षित होते हैं।

साइलो / पूल / ब्रिज शब्दावली: आधिकारिक Microsoft दस्तावेज़ीकरण, मल्टी-टेनेंट SaaS आर्किटेक्चर पैटर्न (Azure आर्किटेक्चर सेंटर)।

मध्यवर्ती मॉडल, एक साझा क्लस्टर पर प्रति किरायेदार आधार, अक्सर उन गाइडों से अनुपस्थित होता है जो "सभी के लिए एक आधार" और "प्रति ग्राहक एक सर्वर" के बीच विकल्प को बाइनरी के रूप में प्रस्तुत करते हैं। हालाँकि, ऑराबेस डिफ़ॉल्ट रूप से इसी का उपयोग करता है, जिसका विवरण नीचे दिया गया है।

इन तीन मॉडलों के बीच का चुनाव प्रत्येक बहु-किरायेदार वास्तुकला निर्णय के साथ होता है, न कि केवल एक BaaS प्रदाता के साथ: एक टीम जो प्रबंधित पोस्टग्रेज (आरडीएस, क्लाउड एसक्यूएल, या एक स्व-होस्ट किए गए उदाहरण) पर अपना स्वयं का SaaS बैकएंड बनाती है, वही मध्यस्थता करती है, एक ही भौतिक उदाहरण पर कई ग्राहकों को रखे जाने पर समान विवाद तंत्र के साथ।

एक noisy neighbor (शोर पड़ोसी) एक किरायेदार है जो एक ही सर्वर पर अन्य किरायेदारों के नुकसान के लिए बुनियादी ढांचे के साझा संसाधनों का अनुपातहीन हिस्सा उपभोग करता है। यह शब्द सार्वजनिक क्लाउड से आता है, लेकिन सीधे साझा पोस्टग्रेज़ क्लस्टर पर लागू होता है: एक डेटाबेस दूसरों के डेटा को छुए बिना उनके प्रदर्शन को ख़राब कर सकता है।

उत्पादन में छह तंत्र सबसे अधिक बार सामने आते हैं:

• सीपीयू विवाद: एक महंगी क्वेरी (इंडेक्स के बिना, बड़े पैमाने पर सॉर्ट) सीपीयू चक्रों का उपभोग करती है जो कर्नेल क्लस्टर में सभी सक्रिय डेटाबेस के बीच साझा करता है।
• IOPS विवाद: एक बैकअप, एक VACUUM FULL या एक बड़ा आयात क्लस्टर के डिस्क थ्रूपुट को संतृप्त करता है, अन्य डेटाबेस को पढ़ने और लिखने को धीमा कर देता है।
• कनेक्शन समाप्ति: max_connections पूरे क्लस्टर स्तर पर सक्रिय कनेक्शन की संख्या को सीमित करता है, प्रति आधार पर नहीं। जो आधार बहुत ज्यादा खुलता है वह दूसरों का मार्जिन कम कर देता है।
• ऑटोवैक्यूम विवाद: ऑटोवैक्यूम प्रति क्लस्टर सीमित संख्या में श्रमिकों के साथ चलता है; उच्च लेखन दर वाला डेटाबेस दूसरे डेटाबेस की तालिकाओं को साफ़ करने में देरी कर सकता है।
• कैश निष्कासन: shared_buffers पूरे क्लस्टर के लिए एक एकल मेमोरी है; बड़े कामकाजी सेट वाला डेटाबेस छोटे पड़ोसी डेटाबेस के कैश्ड पेजों को हटा सकता है।
• साझा रखरखाव विंडोज़: बैकअप, प्रतिकृति विफलता, या प्रमुख अपग्रेड पूरे क्लस्टर पर लागू होता है, प्रति-आधार के आधार पर नहीं।

संरचनात्मक आरेख, माप परिणाम नहीं: इन दो टोपोलॉजी के लिए आज तक कोई तुलनात्मक प्रदर्शन आंकड़े प्रकाशित नहीं हुए हैं।

विलंबता से पहले भी, कनेक्शन बजट अक्सर उत्पादन में सबसे अधिक दिखाई देने वाला लक्षण होता है। यह हमारे max_connections ट्यूनिंग गाइड और हमारी तुलना PgBouncer, Supavisor और PgCatका विस्तृत विषय है।

A transaction mode pooler (PgBouncer, Supavisor, PgCat) mitigates connection exhaustion, but does not remove CPU or IOPS contention: it reuses existing server connections, it does not add additional CPU cores or disk throughput to the cluster. Our article on transaction pooling mode details what this mode actually changes, and what it doesn't change.

पंक्ति-स्तरीय सुरक्षा एक अलग समस्या का समाधान करती है: यह किसी क्वेरी को तार्किक स्तर पर किसी अन्य किरायेदार की पंक्तियों को पढ़ने या संशोधित करने से रोकती है। यह किसी विशिष्ट किरायेदार के लिए कोई सीपीयू चक्र, कोई कनेक्शन स्लॉट, कोई डिस्क थ्रूपुट आरक्षित नहीं करता है।

दो किरायेदार पूरी तरह से निर्विवाद आरएलएस नीतियां रख सकते हैं और एक ही समय में एक-दूसरे को नीचा दिखा सकते हैं: शोर मचाने वाला पड़ोसी भौतिक संसाधनों की समस्या है, पहुंच अधिकारों की नहीं। ईपीआईआरबी लागू होने के बाद दोनों को भ्रमित करने से परिचालन सुरक्षा की गलत भावना पैदा होती है।

प्रोविजनर कोड (aura-provisioner) प्रोविजनिंग समेकन से एक सक्रिय पोस्टग्रेज प्रोजेक्ट के लिए बिल्कुल दो संभावित आर्किटेक्चर का दस्तावेजीकरण करता है, जिसे कोड टास्क 12 के रूप में संदर्भित करता है: FullyDedicated और SharedClusterDedicated। लीगेसी स्कीमा-ग्रेन्ड मॉडल को प्रावधान पथ से हटा दिया गया है।

enterprise स्तर FullyDedicatedको ट्रिगर करता है: एक संपूर्ण CNPG क्लस्टर, जो इस एकल प्रोजेक्ट के लिए आरक्षित है। अन्य सभी स्तर (निःशुल्क, प्रो, टीम) SharedClusterDedicatedतक जाते हैं: परियोजना संगठन के सीएनपीजी क्लस्टर पर एक पूर्ण पोस्टग्रेज project_<uuid> डेटाबेस। इसलिए यह एक साझा स्कीमा नहीं है: यहां तक ​​कि एक मानक योजना पर भी, आपका डेटाबेस एक संपूर्ण पोस्टग्रेज डेटाबेस है, न कि एक सामान्य तालिका में दूसरों के बीच एक पंक्ति। जो साझा किया गया है वह क्लस्टर (सीपीयू, रैम, डिस्क, कनेक्शन) है, आधार नहीं।

एक संगठन का सीएनपीजी क्लस्टर तब बनाया जाता है जब उसका पहला पोस्टग्रेज प्रोजेक्ट प्रावधानित होता है और कभी भी किसी अन्य संगठन से प्रोजेक्ट होस्ट नहीं करता है, एक डिज़ाइन विकल्प कोड स्तर पर लॉक किया जाता है (org_cluster.rs, निर्माण के समय संगठन द्वारा पोस्टग्रेज सलाहकार लॉक)। इसलिए साझा ऑराबेस लैंडिंग पर एकमात्र संभावित शोर पड़ोसी आपके अपने संगठन का एक अन्य प्रोजेक्ट है, किसी तीसरे पक्ष के ग्राहक का नहीं।

/// किसी संगठनात्मक क्लस्टर की नाममात्र क्षमता (परियोजना आधारों की संख्या)।
/// अवलोकनीयता सीमा: इससे परे, संगठन को पूर्णतः समर्पित की ओर निर्देशित करें।
/// FLEET_CLUSTER_CAPACITY के माध्यम से नियंत्रित करने योग्य (डिफ़ॉल्ट 1000, सीमित [1, 1_000_000])।
pub fn fleet_cluster_capacity() -> i32 {
    std::env::var("FLEET_CLUSTER_CAPACITY")
        .ok()
        .and_then(|v| v.parse::<i32>().ok())
        .filter(|n| (1..=1_000_000).contains(n))
        .unwrap_or(1000)
}

ऑराबेस ने PostgreSQL क्लस्टर आर्किटेक्चर विनिर्देशों को प्रबंधित किया।

प्रति क्लस्टर 1000 आधारों की यह सीमा कोई कठिन सीमा नहीं है: यह एक अवलोकनीयता बेंचमार्क है जो FullyDedicatedपर माइग्रेट करने की अनुशंसा को ट्रिगर करता है, न कि एक स्वचालित ब्लॉक। यह अब किसी भी प्लेसमेंट निर्णय को संचालित नहीं करता है, अब प्रति संगठन केवल एक क्लस्टर संभव है।

प्रत्येक क्लस्टर, समर्पित या बेड़ा, एक सीएनपीजी पूलर (पीजीबीबाउंसर) को उजागर करता है जो दोनों टोपोलॉजी में सक्रिय कनेक्शन पर दबाव का हिस्सा अवशोषित करता है। संसाधन विवाद के लिए यह पूलर वास्तव में क्या बदलता है, इसका विवरण नीचे दिया गया है।

साझा क्लस्टर का सीपीयू/रैम आकार भी संगठनों के बीच एक समान नहीं है: यह एक समर्पित फ़ंक्शन (FleetSizing::from_org_plan, org_cluster.rsमें सत्यापित) के माध्यम से संगठन के स्तर से प्राप्त होता है, और सभी स्तरों पर लागू एक ही आकार से नहीं। टीम स्तर पर एक संगठन अपने क्लस्टर को उसी तरह आकार नहीं देता है जैसे कि मुक्त स्तर पर एक संगठन।

ये दोनों आर्किटेक्चर PostgreSQL 16 पर चलते हैं, न कि संस्करण 17 पर, जो उत्पादन में प्रयुक्त CNPG छवि के डॉकरफाइल में सत्यापित है। संस्करण की इस पसंद के अपने स्वयं के ट्यूनिंग निहितार्थ हैं, जिसका विवरण हमारे पोस्टग्रेज 16 बनाम 17 बनाम 18 तुलनामें दिया गया है।

दस्तावेज़ीकृत भौतिक इन्सुलेशन के लिए संविदात्मक दायित्व के अधीन परियोजनाओं के लिए, हमारे DPA और अनुपालन पृष्ठ विवरण देते हैं कि प्रत्येक स्तर में क्या शामिल है।

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

मल्टी-टेनेंट सॉफ़्टवेयर आर्किटेक्चर में विशेषज्ञता वाले संसाधन, जैसे कि कोडओपिनियन, नियमित रूप से इस मध्यवर्ती दृष्टिकोण (साझा बुनियादी ढांचे पर प्रति किरायेदार के आधार पर) को दो चरम सीमाओं के बीच एक द्विआधारी विकल्प के बजाय, साझा योजना और पूरी तरह से समर्पित क्लस्टर के बीच एक उचित समझौते के रूप में प्रस्तुत करते हैं।

साझा से समर्पित में जाने के लिए स्कीमा को फिर से लिखने या इंजन बदलने की आवश्यकता नहीं होती है: दोनों मामलों में, यह पोस्टग्रेज़ है, उसी pg_dump / pg_restore श्रृंखला के साथ जैसा कि हमारे सुपाबेस से ऑराबेस माइग्रेशन गाइडमें वर्णित है। स्तर बदलना एक टॉगल ऑपरेशन बना हुआ है, एप्लिकेशन पुनर्लेखन नहीं।

समर्पित आधार और साझा आधार डेटा सुरक्षा पर टकराव नहीं करते हैं: दोनों मॉडल तार्किक स्तर पर एक किरायेदार को दूसरे से सही ढंग से अलग कर सकते हैं। वे भौतिक संसाधनों (सीपीयू, आईओपीएस, कनेक्शन, कैश, रखरखाव विंडो) पर एक दूसरे का विरोध करते हैं। यह वह योजना है जो शोर मचाने वाले पड़ोसी को परिभाषित करती है, न कि ख़राब तरीके से लिखी गई आरएलएस नीति को।

प्रोविजनर कोड में सत्यापित ऑराबेस मॉडल, डिफ़ॉल्ट रूप से एक मध्यवर्ती समझौता बरकरार रखता है: प्रति प्रोजेक्ट एक समर्पित पोस्टग्रेज डेटाबेस, एक साझा क्लस्टर पर लेकिन एक ही संगठन के लिए सख्ती से आरक्षित, व्यवसाय स्तर के लिए पूरी तरह से समर्पित क्लस्टर के साथ। सही विकल्प आपकी वास्तविक बाधाओं पर निर्भर करता है, न कि उस प्रतिक्रिया पर जहां समर्पित होना हमेशा सबसे अच्छा विकल्प होगा।