मैं बहु-किरायेदार डिज़ाइन के बारे में PostgreSQL मेलिंग सूचियों पर जानकारी खोजने की सलाह दूंगा। वहाँ बहुत सारी चर्चाएँ हुई हैं, और उत्तर "यह निर्भर करता है" तक उबलता है। गारंटीकृत अलगाव, प्रदर्शन और रखरखाव के बीच हर तरह से ट्रेड-ऑफ हैं।
एकल डेटाबेस का उपयोग करना एक सामान्य तरीका है, लेकिन एक स्कीमा
ए> (नाम स्थान) प्रति ग्राहक प्रत्येक स्कीमा में समान तालिका संरचना के साथ, साथ ही डेटा के लिए एक साझा या सामान्य स्कीमा जो उन सभी में समान है। एक PostgreSQL स्कीमा एक MySQL "डेटाबेस" की तरह है जिसमें आप विभिन्न स्कीमा में क्वेरी कर सकते हैं लेकिन वे डिफ़ॉल्ट रूप से अलग-थलग हैं। अलग स्कीमा में ग्राहक डेटा के साथ आप search_path
सेटिंग, आमतौर पर ALTER USER के माध्यम से
ग्राहक नाम SET search_path ='customerschema, sharedschema' यह सुनिश्चित करने के लिए कि प्रत्येक ग्राहक अपना डेटा और केवल अपना डेटा देखता है।
अतिरिक्त सुरक्षा के लिए, आपको REVOKE करना चाहिए
सार्वजनिक से स्कीमा ग्राहक स्कीमा से सभी फिर GRANT
सभी स्कीमा ग्राहकों पर ग्राहक के लिए स्कीमा इसलिए वे केवल एक ही हैं जिनके पास इसकी पहुंच है, वे अपनी प्रत्येक तालिका में ऐसा ही कर रहे हैं। आपका कनेक्शन पूल तब एक निश्चित उपयोगकर्ता खाते से लॉग इन कर सकता है जिसमें नहीं . है अनुदान किसी भी ग्राहक स्कीमा के लिए एड एक्सेस लेकिन उसके पास भूमिका निर्धारित करें
कोई भी ग्राहक बनने के लिए। (ऐसा करें कि उन्हें NOINHERIT सेट के साथ प्रत्येक ग्राहक भूमिका की सदस्यता देकर अधिकारों का स्पष्ट रूप से दावा किया जाना चाहिए SET ROLE ) कनेक्शन तुरंत सेट रोल . होना चाहिए ग्राहक के लिए यह वर्तमान में के रूप में काम कर रहा है। यह आपको प्रोग्रामर त्रुटि के खिलाफ मजबूत सुरक्षा बनाए रखते हुए प्रत्येक ग्राहक के लिए नए कनेक्शन बनाने के ऊपरी हिस्से से बचने की अनुमति देगा जिससे गलत ग्राहक के डेटा तक पहुंच हो सके। जब तक पूल एक सभी को त्यागें
और/या एक RESET ROLE
अगले क्लाइंट को कनेक्शन सौंपने से पहले, यह आपको प्रति-उपयोगकर्ता व्यक्तिगत कनेक्शन की निराशा के बिना बहुत मजबूत अलगाव प्रदान करने वाला है।
यदि आपके वेब ऐप वातावरण में एक अच्छा कनेक्शन पूल अंतर्निहित नहीं है (कहते हैं, आप लगातार कनेक्शन के साथ PHP का उपयोग कर रहे हैं) तो आप वास्तव में एक अच्छा कनेक्शन पूल
डालने की आवश्यकता है वैसे भी पीजी और वेब सर्वर के बीच में, क्योंकि बैकएंड के लिए बहुत सारे कनेक्शन आपके प्रदर्शन को नुकसान पहुंचाएंगे। PgBouncer
और PgPool-II
सबसे अच्छे विकल्प हैं, और आसानी से सभी को त्यागें करने का ध्यान रख सकते हैं और भूमिका रीसेट करें कनेक्शन हैंड-ऑफ के दौरान आपके लिए।
इस दृष्टिकोण का मुख्य पहलू कई तालिकाओं को बनाए रखने के साथ ओवरहेड है, क्योंकि आपके गैर-साझा तालिकाओं का आधार सेट प्रत्येक ग्राहक के लिए क्लोन किया जाता है। जैसे-जैसे ग्राहक संख्या बढ़ती है, यह उस बिंदु तक जुड़ जाएगा, जहां ऑटोवैक्यूम रन के दौरान जांच करने के लिए तालिकाओं की संख्या महंगी होने लगती है और जहां कोई भी ऑपरेशन जो डीबी में तालिकाओं की कुल संख्या के आधार पर होता है, धीमा हो जाता है। यदि आप एक ही DB में कई हज़ार या दसियों हज़ार ग्राहक रखने की सोच रहे हैं, तो यह एक समस्या है, लेकिन मैं दृढ़ता से अनुशंसा करते हैं कि आप इसे करने से पहले डमी डेटा का उपयोग करके इस डिज़ाइन के साथ कुछ स्केलिंग परीक्षण करें।
आदर्श दृष्टिकोण टपल दृश्यता को नियंत्रित करने वाली स्वचालित पंक्ति-स्तरीय सुरक्षा के साथ सिंगल टेबल होने की संभावना है, लेकिन दुर्भाग्य से ऐसा कुछ है जो PostgreSQL के पास अभी तक नहीं है। ऐसा लगता है कि SEPostgreSQL के काम के लिए उपयुक्त बुनियादी ढांचे और एपीआई को जोड़ने के लिए धन्यवाद, यह रास्ते में है, लेकिन यह 9.1 में नहीं है।
