एकल वी / एस एकाधिक डेटाबेस

Question

मैंने इस वेब ऐप (php & mysql) का निर्माण किया है जो विभिन्न संगठनों (वर्तमान में लगभग 20 ग्राहक) के लिए जानकारी संग्रहीत करता है।

वर्तमान परिदृश्य ग्राहक-संबंधित जानकारी को अलग-अलग डेटाबेस में संग्रहीत करता है, इसलिए 20 ग्राहक डेटाबेस और 1 मास्टर डेटाबेस है।

यहाँ एक मुख्य लाभ यह है कि जैसा कि प्रत्येक ग्राहक db अलग-थलग है, क्लाइंट कलाकृतियों की संख्या (रिपोर्ट, ऑडिट) आदि अनुक्रमित हैं; हमारे ग्राहकों को सुरक्षा की भावना देना।

प्रत्येक DB में लगभग 15 टेबल हैं, और एक टेबल में सबसे अधिक पंक्तियां लगभग 2000 हैं। यह 5000 रिकॉर्ड तक टकराए जाने की उम्मीद है, सबसे अधिक।

एकल db-level परिवर्तन को प्रबंधित करने का अर्थ है 20 डेटाबेस बदलना, लेकिन इस दुर्लभ घटना में कि मुझे ऐसा बदलाव करने की आवश्यकता है, मैं एक स्क्रिप्ट का उपयोग करता हूं जो एकल फ़ंक्शन कॉल में ऐसा करता है।

हम एक साझा होस्टिंग व्यवस्था पर हैं, और हमारा आईएसपी हमें सीमित संख्या में आपूर्ति करता है। डेटाबेस के; और यही मुझे डेटाबेस को केंद्रीकृत करने के मामले में सोचने के लिए प्रेरित करता है; ताकि सभी क्लाइंट डेटा को मास्टर डेटाबेस में स्टोर किया जा सके।

बेशक, कुछ महत्वपूर्ण मुद्दे जो फसल करते हैं:

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

भविष्य में, हमें एक संगठन के डेटासेट की दूसरे के साथ तुलना करने पर विचार करने की आवश्यकता हो सकती है, लेकिन मेरा मानना ​​है कि यह एक केंद्रीकृत जीबी पर भी प्राप्त किया जा सकता है। मैं केंद्रीकृत डेटाबेस में जाने के लिए कुछ हद तक (प्रदर्शन और रखरखाव के कारणों के लिए) इच्छुक हूं।

क्या आपको लगता है कि एक केंद्रीकृत डेटाबेस में जाने से अधिक समझ में आता है जैसे हम (व्यक्तिगत डेटाबेस पर) हैं?

आपके सुझाव के लिए धन्यवाद।

Comments

यह एक StackOverflow सवाल की तुलना में अधिक लगता है कि एक वेबमास्टर्स मेरे लिए मुद्दा?

— कंधार

यह stackoverflow.com के लिए है।

— vamquez

यहां महान सुझावों के अलावा, यह भी पता लगाना बुद्धिमानी है कि आपके क्षेत्र में कोई विशेष कानून कैसे संग्रहीत किए जा सकते हैं। इसके अलावा, एक उल्लंघन के मामले में, एक जोखिम / देयता कारक है जिसके साथ आपको आराम करने की आवश्यकता है। सिर्फ एक विचार।

— अनाम कायर

या PostgreSQL पर स्विच करें जहाँ आप MySQL के विपरीत SQL स्कीम की परिभाषा का पालन करते हुए इसके स्कीमा का लाभ उठाएँगे। PostgreSQL में आपके पास database.schema.table है जबकि MySQL डेटाबेस और स्कीमा पर्यायवाची हैं।

— मारियो

Answer 1

दोनों सिस्टम में विरासत में जोखिम और पुरस्कार हैं। मैंने एक वित्तीय फर्म के लिए काम किया जिसने 1 डेटाबेस पर लगभग 40 ग्राहकों (राष्ट्रीय बैंकों) का समर्थन किया। हमने फिर एक और कंपनी खरीदी जो समान सॉफ्टवेयर बेचती थी और जो प्रति ग्राहक 1 डेटाबेस के साथ जाती थी। अंत में, कंपनी दिवालिया हो गई और हमें सभी उपयोगकर्ता डेटा निर्यात करना पड़ा। यहाँ लोगों ने मेरे साथ काम किया और मैंने पाया:

एकल DB के प्रो:

1. सॉफ्टवेयर अपडेट और बग फिक्स आसान हैं।
2. सभी क्लाइंट डेटा पर प्रबंधन और रिपोर्ट करना आसान है।
3. डेटा अपडेट करना आसान हो जाता है।
4. मॉड्यूलर कार्यक्षमता बनाना आसान है जो 1 ग्राहक चाहता है, यदि अन्य ग्राहकों के लिए बंद हो, और तब इसे चालू करें जब वे भविष्य में इसकी इच्छा करें।

सिंगल DB का कॉन:

1. डेटा अखंडता - हमारे पास 2 या 3 मामले थे जहां 1 बैंक के उपयोगकर्ताओं ने दूसरे बैंक के डेटा को देखा। यह एक बुरा सपना था। विशेष रूप से क्योंकि साइट उपयोगकर्ता केवल बैंक कर्मचारी नहीं थे, लेकिन बैंक के ग्राहकों के वास्तविक खाते थे! यह 1 डेटाबेस के साथ अब तक का सबसे बड़ा मुद्दा है
2. क्लाइंट डेटा निर्यात करना -जब हमारे पास यह था तो यह आमतौर पर एक बड़ी बात नहीं थी। आप 1 टेबल के साथ समाप्त होते हैं जिसमें सभी क्लाइंट होते हैं और आप अपने क्लाइंट के विशिष्ट डेटा को प्राप्त करने के लिए उस टेबल की कुंजी बंद करते हैं।

कई DB के प्रो:

1. क्रॉस क्लाइंट डेटा संदूषण या उल्लंघनों की कोई चिंता नहीं है
2. क्लाइंट डेटा निर्यात करना आसान है।

एकाधिक DB के कोन:

1. अपडेट और बग फिक्स - यह वास्तविक दुःस्वप्न था। जब आपके पास 20 अलग-अलग डेटाबेस पर 20 क्लाइंट होते हैं, तो आप जल्दी से एक ऐसे मामले में भाग लेते हैं, जहां 1 क्लाइंट एक फिक्स्ड बग चाहता है और दूसरे को लगता है कि बग एक विशेषता है या अपडेट को जोखिम में नहीं डालना चाहता। इसके अलावा, आपके पास ऐसे उदाहरण होंगे जहां 1 ग्राहक एक खेल को बढ़ाना चाहता है, लेकिन अन्य ग्राहक नहीं करते हैं। जब ऐसा होता है तो आप डेटाबेस को विचलन करना शुरू कर देंगे। अचानक आपको 1 स्क्रिप्ट 16-19 के साथ 1-15 और दूसरे के साथ 20 के साथ ग्राहकों को 1-15 अपडेट करना होगा। हमने देखा कि यह एक ऐसा मुद्दा बन गया है कि बग फिक्स कंपनी ने हमारे लिए खरीदी गई कंपनी के लिए 15 से 20 गुना समय लिया होगा क्योंकि उन्हें हर ग्राहक के लिए सभी परीक्षण चलाने थे और प्रत्येक ग्राहक विशेष कोड के साथ सौदा करना था। प्रभावी रूप से, उन्हें हर नए ग्राहक के लिए एक नए समर्थन व्यक्ति की आवश्यकता थी,
2. DB प्रबंधन - जब आप सभी डेटाबेस को प्रबंधित करने वाले बड़ी संख्या में क्लाइंट प्राप्त करते हैं, तो यह एक वास्तविक परेशानी बन जाती है। आप एक शक के बिना उन्हें प्रबंधित करने के लिए अधिक DBA समय की आवश्यकता होगी।

अंत में मेरी सिफारिश को देखा और किया गया कि दोनों में "अनुशासन" है! मुझे लगता है कि मल्टी-डीबी विकल्प थोड़ा बेहतर है क्योंकि यह आपकी सुरक्षा करता है लेकिन आप कभी भी ग्राहकों को ऐसा विकल्प नहीं दे सकते जिससे आपको केवल उनके लिए कार्यक्षमता मिल सके या आप खुद को असफलता के रास्ते पर लाएंगे।

Comments

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

— नारायण

Answer 2

मैं अलग ग्राहकों के लिए अलग डेटाबेस होगा। एक ग्राहक सुरक्षा कारणों से यह मांग कर सकता है - यानी केवल उनकी साइट पर उनके डेटा तक पहुंच है। इसका मतलब यह भी है कि यदि कोई ग्राहक अपना डेटा स्थानांतरित करना चाहता है तो उसे प्रबंधित करना बहुत आसान हो जाएगा ।

इसका मतलब यह भी है कि अगर एक ग्राहक के डेटाबेस में कोई समस्या है तो यह अन्य सभी को प्रभावित नहीं करता है।

यदि आप ग्राहकों के बीच डेटा की तुलना करना चाहते हैं तो आपको अलग से ऐसा करना चाहिए।

यदि आप उन डेटाबेस से बाहर चल रहे हैं जो आपके पास हो सकते हैं तो शायद आपको अपने होस्ट प्रदाता को बदलने पर विचार करना चाहिए।

Comments

ग्राहकों के लिए +1 उनके डेटा के लिए पूछ रहा है। अलग-अलग डेटाबेस के लिए भुगतान करने की तुलना में केवल उस डेटा को निकालने के लिए कुछ लिखना लिखना अधिक महंगा हो सकता है।

— कार्सन

इतना ही नहीं, यह अलग-अलग क्लाइंट्स को अलग-अलग दरों पर 'स्केल' देता है, जो कि एक प्रमुख प्लस है।

— टिम पोस्ट

@ समय - अच्छा बिंदु।

— क्रिस एफआर

यकायक उठना भूल गए। +1 :)

— टिम पोस्ट

धन्यवाद @Tim और @ क्रिस, आपकी अंतर्दृष्टि मददगार रही है।

— नारायण

Answer 3

केवल एक कारण मेरे पास प्रत्येक ग्राहक के लिए एक व्यक्तिगत डेटाबेस नहीं होगा यदि आप 100s या अधिक क्लाइंट / डेटाबेस रखने वाले हैं। यह डेटाबेस के परिवर्तन या सभी डेटाबेस में कुछ करने सहित प्रबंधन करने के लिए वास्तव में बालों वाला हो सकता है। कई डेटाबेस में बड़ी संख्या में होने वाले कार्य भी धीमे हो सकते हैं क्योंकि आपको कई तालिकाओं को खोलने (और इसलिए बंद करने) की आवश्यकता होती है।

लेकिन इस मामले से अलग, मुझे लगता है कि कई डेटाबेस बेहतर हैं।

एक लाभ, जो महत्वपूर्ण नहीं हो सकता है, लेकिन उपयोगी हो सकता है, यह है कि प्रत्येक ग्राहक को अपनी स्वयं की अनुक्रमिक आईडी मिलती है (संभवतः एक गुच्छा को छोड़ देने के कारण क्योंकि एक और ग्राहक (एस) ने रिकॉर्ड जोड़ा है)।

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

Answer 4

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

मुझे लगता है कि आपके मामले में कॉन्फ़िगरेशन प्रबंधन आपको एकल डेटाबेस पर ले जाएगा। डेटाबेस को बनाए रखने और अपग्रेड करने में समय लगता है। सॉफ़्टवेयर की प्रत्येक रिलीज़ के साथ क्या लागतें जुड़ी हैं? इसके अलावा उस लागत के बारे में सोचें जब आपको एक नया ग्राहक मिलता है और उसके लिए एक डीबी बनाना होता है और इसके लिए ऐप को कॉन्फ़िगर करना होता है। कुछ भी स्वचालित किया जा सकता है, सवाल यह है कि क्या आपके पास 100 डेटाबेस होने पर यह इसके लायक होगा?

सड़क के नीचे, 100 डेटाबेस के लिए भी ऐसा ही करना है।

मुझे लगता है कि अन्य पोस्टरों ने कुछ उत्कृष्ट बिंदु बनाए हैं, इसलिए मैं उन पर नहीं जाऊँगा।

Answer 5

समर्थक / चोर को अभी तक सूचीबद्ध करने के लिए:

कई डेटाबेस के प्रो:

1. लॉकिंग मुद्दों से बचा जाता है; हमें ऐसे डेटाबेस मिले हैं जहां क्लाइंट कुछ टेबलों पर DDL-बदलावों को ट्रिगर कर सकते हैं। बड़ी तालिकाओं (> 2 मी रिकॉर्ड) के लिए यह तालिका को काफी समय के लिए बंद कर देता है। एक नुकसान में एकमात्र लोग अपने स्वयं के उपयोगकर्ता हैं, इसलिए यह स्वीकार्य की तरह है।

2. लचीलापन - कुछ क्लाइंट के पास उन डेटा के बारे में विशिष्ट इच्छाएं होती हैं जिन्हें वे संग्रहीत करना चाहते हैं; मल्टी-डेटाबेस ने हमें अन्य क्लाइंट्स के लिए डेटा मॉडल को अव्यवस्थित किए बिना, विशेष रूप से अपने डेटाबेस को बदलने की सुविधा दी।

विपक्ष:

1. प्रमुख शंकु: अन्य तालिकाओं पर जुड़ना अधिक बोझिल है। हमें एक मुख्य डेटाबेस मिला है जिसमें अधिकांश मेटा-डेटा हैं। क्लाइंट-विशिष्ट डेटाबेस उपयोगकर्ताओं के पास इस डेटाबेस तक पहुंच नहीं है, इसलिए सभी उस डेटाबेस में तालिकाओं के बीच जुड़ते हैं और क्लाइंट-विशिष्ट एक डेटाबेस के बजाय एप्लिकेशन में संभाला जाता है। आप क्लाइंट-विशिष्ट उपयोगकर्ताओं को मुख्य डेटाबेस तक पहुंच प्रदान करके इसे हल कर सकते हैं, लेकिन तब ऐप फिर से जानकारी लीक कर सकता है।

चुनने में सौभाग्य!

Answer 6

मुझे पता है कि आपने पहले ही एक उत्तर चुन लिया है, लेकिन ऐसा लगता है कि एक और समाधान है जो सुझाया नहीं गया था:

सब कुछ एक डेटाबेस में ले जाएं, लेकिन प्रत्येक ग्राहक के लिए एक उपसर्ग का उपयोग करके टेबल बनाएं, जैसे:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

यह दोनों दुनिया के सर्वश्रेष्ठ की तरह है।

• अपने वर्तमान सेटअप से नए सेट अप में माइग्रेट करना बहुत आसान है।
• आप प्रति ग्राहक 1 उपयोगकर्ता बना सकते हैं और उसके विशेषाधिकारों को उसकी कंपनी की तालिकाओं तक सीमित कर सकते हैं और कुछ नहीं
• यदि आपको ऐसा करने की आवश्यकता है तो आप एक सुपरयूज़र और आसानी से डेटा एकत्र कर सकते हैं।
• केवल एक डेटाबेस का उपयोग करें

Comments

मुझे यकीन है कि इस दृष्टिकोण के बारे में नहीं सोचा था। यह काफी काम का लगता है, लेकिन फिर स्केलिंग करते समय यह किस जटिलता को सीमित करता है। यह देखते हुए कि मेरे पास प्रति ग्राहक कम से कम 18 टेबल होंगे, एक 20-क्लाइंट सेटअप का मतलब डेटाबेस में 360 टेबल से शुरू होगा। और अगर हम अपने बिक्री अनुमानों के पास कहीं भी पहुंचते हैं, तो 1800 टेबल डेटाबेस का प्रबंधन करना दर्दनाक होगा। तुलनात्मक रूप से, प्रत्येक 18 टेबल के साथ 100 डेटाबेस का प्रबंधन करना बेहतर होगा। आपकी टिप्पणियों के लिए आभार।

— नारायण

@ नारायण: आपका स्वागत है। वह बहुत सारी टेबल है। दूसरे छोर पर, इन सभी तालिका संचालन को आसानी से स्वचालित किया जा सकता है, इसलिए यह उतना बड़ा सौदा नहीं है जितना दिखता है। आप सभी की जरूरत है एक ग्राहक तालिका तालिका नामों की सूची है। यह वास्तव में 100 विभिन्न डेटाबेस से कनेक्ट / डिस्कनेक्ट करने की तुलना में आसान बनाता है। वैसे भी, यह सिर्फ एक सुझाव था। बिल्ली के लिए त्वचा के कई तरीके हैं।

— सिल्वर

पीएस: आपके पास मौजूद तालिकाओं की संख्या की एकमात्र वास्तविक सीमा फाइलों की संख्या है जो आपके ओएस पर समवर्ती रूप से खोली जा सकती हैं। एक विशिष्ट लिनक्स मशीन के लिए, यह डिफ़ॉल्ट रूप से 75,000 है। अन्यथा, Ms SQL सर्वर 2bn टेबल तक की अनुमति देगा।

— सिल्वर