PostgreSQL: क्या एक स्कीमा के साथ एक या कई स्कीमा वाले एक डेटाबेस के साथ कई डेटाबेस का उपयोग करना बेहतर है?

Question

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

मेरी स्थिति: मैं एक वेब एप्लिकेशन विकसित कर रहा हूं, जब लोग पंजीकरण करते हैं, तो मैं एक डेटाबेस (वास्तव में) बनाता हूं (नहीं, यह एक सामाजिक नेटवर्क नहीं है: हर किसी के पास अपने स्वयं के डेटा तक पहुंच होनी चाहिए और दूसरे उपयोगकर्ता का डेटा कभी नहीं देखना चाहिए) ।

यही कारण है कि मैंने अपने एप्लिकेशन के पिछले संस्करण के लिए उपयोग किया था (जो अभी भी MySQL पर चल रहा है): Plesk API के माध्यम से, हर पंजीकरण के लिए, मैं करता हूं:

1. सीमित विशेषाधिकार के साथ एक डेटाबेस उपयोगकर्ता बनाएं;
2. एक डेटाबेस बनाएं जिसे केवल पिछले बनाए गए उपयोगकर्ता और सुपरसुसर (रखरखाव के लिए) तक पहुँचा जा सकता है
3. डेटाबेस पॉपुलेट करें

अब, मुझे PostgreSQL के साथ भी ऐसा करने की आवश्यकता होगी (परियोजना परिपक्व हो रही है और MySQL ... सभी आवश्यकताओं को पूरा नहीं करता है)।

मुझे सभी डेटाबेस / स्कीमा बैकअप को स्वतंत्र करने की आवश्यकता है: pg_dump दोनों तरीकों से पूरी तरह से काम करता है, और उन उपयोगकर्ताओं के लिए समान है जिन्हें सिर्फ एक स्कीमा या एक डेटाबेस तक पहुंचने के लिए कॉन्फ़िगर किया जा सकता है।

इसलिए, यह मानते हुए कि आप मुझसे अधिक अनुभवी PostgreSQL उपयोगकर्ता हैं, आपको क्या लगता है कि मेरी स्थिति के लिए सबसे अच्छा समाधान क्या है, और क्यों?

क्या $ x स्कीमा के बजाय $ x डेटाबेस का उपयोग करके प्रदर्शन अंतर होगा? और भविष्य में (विश्वसनीयता) बनाए रखने के लिए क्या समाधान बेहतर होगा?

मेरे सभी डेटाबेस / स्कीमा में हमेशा समान संरचना होगी!

बैकअप समस्या के लिए (pg_dump का उपयोग करके), शायद एक डेटाबेस और कई स्कीमाओं का उपयोग करके बेहतर है, सभी स्कीमाओं को एक ही बार में डंप करना: ठीक होना एक विकास मशीन में मुख्य डंप को लोड करने में काफी सरल होगा और फिर डंप करें और केवल आवश्यक स्कीमा को पुनर्स्थापित करें: वहाँ एक अतिरिक्त कदम है, लेकिन सभी स्कीमा को डंप करना उन्हें एक-एक करके डंप करने की तुलना में तेज लगता है।

2012 अद्यतन

ठीक है, पिछले दो वर्षों के दौरान एप्लिकेशन संरचना और डिजाइन में बहुत बदलाव आया। मैं अभी भी one db with many schemasदृष्टिकोण का उपयोग कर रहा हूं , लेकिन फिर भी, मेरे पास मेरे एप्लिकेशन के प्रत्येक संस्करण के लिए एक डेटाबेस है :

Db myapp_01
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema
Db myapp_02
    \_ my_customer_foo_schema
    \_ my_customer_bar_schema

बैकअप के लिए, मैं नियमित रूप से प्रत्येक डेटाबेस को डंप कर रहा हूं, और फिर बैकअप को विकास सर्वर पर स्थानांतरित कर रहा हूं।

मैं पीआईटीआर / वाल बैकअप का भी उपयोग कर रहा हूं, लेकिन जैसा कि मैंने पहले कहा था, इसकी संभावना नहीं है कि मुझे एक ही बार में सभी डेटाबेस को पुनर्स्थापित करना होगा ... इसलिए यह संभवतः इस वर्ष खारिज कर दिया जाएगा (मेरी स्थिति में सबसे अच्छा तरीका नहीं है )।

एक-डीबी-कई-स्कीमा दृष्टिकोण ने मेरे लिए अब से बहुत अच्छा काम किया, भले ही एप्लिकेशन संरचना पूरी तरह से बदल गई हो:

मैं लगभग भूल गया: मेरे सभी डेटाबेस / स्कीमा में हमेशा एक ही संरचना होगी!

... अब, प्रत्येक स्कीमा की अपनी संरचना होती है जो उपयोगकर्ताओं के डेटा प्रवाह में गतिशील रूप से प्रतिक्रिया करती है।

Comments

"मेरे सभी डेटाबेस / स्कीमा में कभी भी समान संरचना होगी!" क्या आपका मतलब है कि वे सभी एक ही संरचना है? या कभी नही?

— ओसामा अल-मआदेद

क्षमा करें, हाँ, उन सभी के पास हमेशा के लिए एक ही संरचना है: अगर मैं एक को बदल दूंगा, तो मैं उन सभी को बदल दूंगा;)

— स्ट्रै जूल

यदि आपके पास 1000 ग्राहक हैं, तो इसका मतलब है कि आपको 1000 स्कीमा अपडेट करने होंगे?

— जोशुआ भागूगी

@jpartogi: हाँ, लेकिन मुझे सिर्फ टेबल स्ट्रक्चर अपडेट करना है, डेटा नहीं।

— स्ट्रेट

तो, आप आखिर किस लिए गए थे? एक प्रश्न, यद्यपि, हालांकि, प्रश्नों के प्रदर्शन आदि को टेबलस्पेस द्वारा नियंत्रित किया जा सकता है, स्कीमा मल्टी-डीबी बनाम मल्टी-स्कीमा के बराबर प्रदर्शन के परिणामस्वरूप होता है, वाल लॉग पर कोई प्रभाव पड़ता है ???

— कपिल

Answer 1

एक PostgreSQL "स्कीमा" लगभग एक MySQL "डेटाबेस" के समान है। PostgreSQL स्थापना पर कई डेटाबेस होने से समस्याग्रस्त हो सकते हैं; कई स्कीमा होने से कोई परेशानी नहीं होगी। तो आप निश्चित रूप से उस डेटाबेस के भीतर एक डेटाबेस और कई स्कीमाओं के साथ जाना चाहते हैं।

Comments

यह। Postgres आपको डेटाबेस में क्वेरी करने की अनुमति नहीं देता है, जो बहुत कष्टप्रद हो सकता है।

— मैट बी

"एक PostgreSQL स्थापना पर कई डेटाबेस होने से समस्याग्रस्त हो सकते हैं" - कृपया स्पष्ट करें; क्या यह आम तौर पर या इस विशिष्ट मामले में समस्याग्रस्त है, और क्यों?

— एकैहोला

"एक डेटाबेस में कई स्कीमा का उपयोग करने के लिए सबसे आम उपयोग का मामला एक सॉफ्टवेयर-ए-ए-सर्विस एप्लिकेशन का निर्माण कर रहा है, जिसमें प्रत्येक ग्राहक का अपना स्कीमा होता है। जबकि यह तकनीक सम्मोहक लगती है, हम दृढ़ता से इसके खिलाफ अनुशंसा करते हैं क्योंकि इससे कई मामले सामने आए हैं। परिचालन समस्याएँ। उदाहरण के लिए, यहां तक ​​कि एक मध्यम संख्या में स्कीमास (> 50) हेरोकू

— नील

@NeilMcGuigan: दिलचस्प बात यह है कि केक्विन (स्वीकृत) जवाब से विपरीत निष्कर्ष लगता है।

— कार्बोकेशन

कई स्कीमाओं के साथ एक डेटाबेस होने के बावजूद, उन लोगों के एकल स्कीमा को डंप करना लगभग असंभव हो जाएगा। यदि आप एक एकल स्कीमा डंप करने का प्रयास करते हैं तो मैं 3000 से अधिक स्कीमा और pg_dump के साथ एकल पोस्टग्रैज डेटाबेस चला रहा हूँ। मुझे आश्चर्य है कि अगर यह कोई अलग होता तो मेरे पास इसके बजाय 3000 डेटाबेस होते।

— मकिसुजी

Answer 2

निश्चित रूप से, मैं एक-डीबी-कई-स्कीमा दृष्टिकोण के लिए जाऊंगा। यह मुझे सभी डेटाबेस को डंप करने की अनुमति देता है, लेकिन कई तरीकों से, बस एक को बहुत आसानी से पुनर्स्थापित करता है:

1. Db (सभी स्कीमा) को डंप करें, डंप को एक नए db में लोड करें, बस मुझे जिस स्कीमा की आवश्यकता है उसे डंप करें, और मुख्य db में वापस पुनर्स्थापित करें।
2. स्कीमा को अलग से डंप करें, एक-एक करके (लेकिन मुझे लगता है कि मशीन को इस तरह से अधिक नुकसान होगा - और मुझे 500 स्कीमा की तरह उम्मीद है!)

अन्यथा, मैंने चारों ओर गुगली करते हुए देखा कि स्कीमा की नकल करने के लिए कोई ऑटो-प्रक्रिया नहीं है (एक टेम्पलेट के रूप में एक का उपयोग करके), लेकिन कई इस तरह से सुझाव देते हैं:

1. टेम्पलेट-स्कीमा बनाएँ
2. जब डुप्लिकेट करने की आवश्यकता होती है, तो इसे नए नाम के साथ नाम दें
3. इसे फेंक दो
4. इसका नाम बदला
5. डंप को पुनर्स्थापित करें
6. जादू हो गया।

मैंने ऐसा करने के लिए पायथन में दो पंक्तियाँ लिखी हैं; मुझे उम्मीद है कि वे किसी की मदद कर सकते हैं (2-सेकंड-लिखित-कोड, उत्पादन में इसका उपयोग न करें):

import os
import sys
import pg

# Take the new schema name from the second cmd arguments (the first is the filename)
newSchema = sys.argv[1]

# Temperary folder for the dumps
dumpFile = '/test/dumps/' + str(newSchema) + '.sql'

# Settings
db_name = 'db_name'
db_user = 'db_user'
db_pass = 'db_pass'
schema_as_template = 'schema_name'

# Connection
pgConnect = pg.connect(dbname= db_name, host='localhost', user= db_user, passwd= db_pass)

# Rename schema with the new name
pgConnect.query("ALTER SCHEMA " + schema_as_template + " RENAME TO " + str(newSchema))

# Dump it
command = 'export PGPASSWORD="' + db_pass + '" && pg_dump -U ' + db_user + ' -n ' + str(newSchema) + ' ' + db_name + ' > ' + dumpFile
os.system(command)

# Rename back with its default name
pgConnect.query("ALTER SCHEMA " + str(newSchema) + " RENAME TO " + schema_as_template)

# Restore the previous dump to create the new schema
restore = 'export PGPASSWORD="' + db_pass + '" && psql -U ' + db_user + ' -d ' + db_name + ' < ' + dumpFile
os.system(restore)

# Want to delete the dump file?
os.remove(dumpFile)

# Close connection
pgConnect.close()

Answer 3

मैं कहूंगा, कई डेटाबेस और कई स्कीमाओं के साथ जाएं :)

PostgreSQL में स्कीमा ओरेकल में पैकेज की तरह हैं, अगर आप उन लोगों से परिचित हैं। डेटाबेस डेटा के पूरे सेट के बीच अंतर करने के लिए होते हैं, जबकि स्कीमा डेटा संस्थाओं की तरह अधिक होते हैं।

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

डेटाबेस पूरे कार्यक्रम हैं, स्कीमा घटक हैं।

Comments

... और मेरे पास 1 डेटाबेस होगा, स्कीमा के अंदर: $ customer1_user_schema, $ customer2_user_schema, $ customer3_user_schema, $ customer1_documents_schema, $ customer2_documents_schema, $ customer3_documents_schema? Mh ... एक विश्वसनीय तरीका नहीं लगता ... और प्रदर्शन के बारे में क्या? और मेरे आवेदन के कोड के बारे में क्या (php और अजगर होगा)? इतने सारे स्कीमा ..

— स्ट्रे

@Strae: मैं इसे पढ़ रहा हूं: प्रत्येक ग्राहक के पास डेटाबेस customer1_database, customer2_database है और उन डेटाबेसों के भीतर आपके पास user_schema, documents_schema हैं।

— फ्रैंकमर्स

Answer 4

PostgreSQL के संदर्भ में मैं एक db को कई स्कीमाओं के साथ उपयोग करने की सलाह देता हूं, जैसा कि आप कर सकते हैं (जैसे) UNION ALL को स्कीमा में, लेकिन डेटाबेस में नहीं। उस कारण से, एक डेटाबेस दूसरे डेटाबेस से वास्तव में पूरी तरह से अछूता है, जबकि स्कीमा एक ही डेटाबेस के भीतर अन्य स्कीमाओं से अछूता नहीं है।

यदि आप किसी कारण से- भविष्य में डेटा को स्कीमा में समेकित करना चाहते हैं, तो कई स्कीमाओं पर ऐसा करना आसान होगा। कई डेटाबेस के साथ आपको कई डीबी-कनेक्शन की आवश्यकता होगी और एप्लिकेशन लॉजिक द्वारा "मैन्युअल रूप से" प्रत्येक डेटाबेस से डेटा को इकट्ठा और मर्ज करना होगा।

उत्तरार्द्ध के कुछ मामलों में फायदे हैं, लेकिन प्रमुख भाग के लिए मुझे लगता है कि एक-डेटाबेस-मल्टीपल-स्कीमा दृष्टिकोण अधिक उपयोगी है।

Answer 5

कई प्रकार के डेटाबेस की तुलना में स्कीमाओं की संख्या अधिक हल्की होनी चाहिए, हालाँकि मुझे ऐसा संदर्भ नहीं मिल रहा है जो इसकी पुष्टि करता हो।

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