स्कीमा-कम / लचीला + एसीआईडी ​​डेटाबेस?

Question

मैं छोटे उद्यम ग्राहकों के लिए वेब आधारित क्लोजर एप्लिकेशन के रूप में एक वीबी पर आधारित (स्थानीय रूप से स्थापित) एप्लिकेशन (इनवॉइस + इन्वेंट्री) को फिर से लिखने पर देख रहा हूं। मैं इसे इसी तरह के व्यापार में ग्राहकों के लिए एक सास आवेदन के रूप में पेश करने का इरादा कर रहा हूं।

मैं डेटाबेस विकल्प देख रहा था: मेरी पसंद एक RDBMS था: Postgresql / MySQL। मैं पहले वर्ष में 400 उपयोगकर्ताओं को स्केल कर सकता हूं, आम तौर पर प्रति उपयोगकर्ता 20-40 पृष्ठ / प्रति दिन - ज्यादातर लेन-देन स्थिर विचारों के लिए नहीं। प्रत्येक दृश्य में डेटा और अपडेट डेटा शामिल होंगे। ACID अनुपालन आवश्यक है (या तो मुझे लगता है)। इसलिए लेन-देन की मात्रा बहुत बड़ी नहीं है।

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

1. एक पारंपरिक DBBMS स्कीमा MySQl / Postgresql में एक ही DB कई किरायेदारों की मेजबानी के साथ है। और भविष्य के परिवर्तनों की अनुमति देने के लिए प्रत्येक तालिका में पर्याप्त "मुक्त-फ़्लोटिंग" कॉलम जोड़ें क्योंकि मैं किसी मौजूदा ग्राहक के लिए अधिक ग्राहक या परिवर्तन जोड़ता हूं। हर बार जब स्कीम में एक छोटा सा बदलाव किया जाता है, तो यह डीबी में परिवर्तन के प्रचार का एक नकारात्मक पहलू हो सकता है। मुझे याद है कि Postgresql स्कीमा अपडेट में लॉकिंग के बिना वास्तविक समय में किया जा सकता है। लेकिन यकीन नहीं है, इस उपयोग के मामले में कितना दर्दनाक या कितना व्यावहारिक है। और साथ ही, स्कीमा परिवर्तन के रूप में नए / मामूली SQL परिवर्तनों को भी पेश कर सकते हैं।
2. RDBMS रखें, लेकिन डेटाबेस स्कीमा को लचीले तरीके से डिज़ाइन करें: इकाई-विशेषता-मान के करीब या कुंजी-मान स्टोर के रूप में। (कार्य दिवस, उदाहरण के लिए FriendFeed)
3. संपूर्ण चीज़ को इन-मेमोरी में ऑब्जेक्ट के रूप में रखें और उन्हें लॉग फ़ाइलों में समय-समय पर संग्रहीत करें। (उदाहरण के लिए, edval, lmax)
4. MongoDB या Redis जैसे NoSQL DB के लिए जाएं। लेकिन जो मैं इकट्ठा कर सकता हूं, उसके आधार पर, वे इस उपयोग-मामले के लिए उपयुक्त नहीं हैं और पूरी तरह से एसीआईडी ​​अनुरूप नहीं हैं।
5. कुछ NewSQL Dbs जैसे VoltDb या JustoneDb (क्लाउड आधारित) के लिए जाएं जो SQL और ACID के अनुरूप व्यवहार को बनाए रखते हैं और "नए-जीन" RDBMS हैं।
6. मैंने neo4j (ग्राफडब) को देखा, लेकिन यह सुनिश्चित नहीं हुआ कि यह उपयोग-मामला फिट होगा या नहीं

मेरे उपयोग के मामले में, स्केलेबिलिटी या वितरित कंप्यूटिंग से अधिक, मैं "स्कीमा + एसीआईडी ​​+ कुछ उचित प्रदर्शन में लचीलापन" प्राप्त करने के लिए एक बेहतर तरीका देख रहा हूं। अधिकांश लेख मुझे स्कीमा में लचीलेपन की शुद्ध बात पर मिल सकते हैं, जो ACID / लेन-देन पक्ष से बाहर निकलते समय प्रदर्शन (NoSQL DBs के मामले में) और स्केलेबिलिटी के कारण होता है।

क्या यह 'स्कीमा लचीलेपन बनाम एसीआईडी' लेनदेन का "या तो" मामला है या कोई बेहतर तरीका है?

Comments

PostgreSQL में hstore मॉड्यूल की जाँच करें। SQL डेटाबेस के अंदर "NoSQL": postgresql.org/docs/current/static/hstore.html

— a_horse_with_no_name

@horse: धन्यवाद ... यह एक अच्छा सूचक है। मैंने MySQL के लिए NoSQL प्लग इन सुना है। मैं पोस्टग्रेज के लिए समान दिख रहा था।

— tmbsundar

Answer 1

विकल्प 1

इसके कई कारण हैं, जिन्हें मैं नीचे बताऊंगा। पहले, यहाँ यह कैसे करना है।

• मानक RDBMS प्लेटफ़ॉर्म का अपनी पसंद का उपयोग करें।

• कई उपयोगकर्ता-कॉन्फ़िगर करने योग्य फ़ील्ड के साथ अपना स्कीमा सेट करें, और अपने आवेदन को प्रति-किरायेदार आधार पर कॉन्फ़िगरेशन की सुविधा प्रदान करें।

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

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

इसके पीछे कारण हैं:

• ये डेटाबेस सिस्टम आपके द्वारा साधारण हार्डवेयर पर वर्णित संस्करणों की तरह संभाल लेंगे। आपके पास वास्तव में लेनदेन की मात्रा नहीं है जो एक NoSQL डेटाबेस का गुण है। जब तक आपके पास एक को चाहने के लिए कुछ अन्य वास्तुशिल्पी कारण हैं, तब तक रक्तस्राव होने की संभावना नहीं है।

• वे परिपक्व हैं, अच्छी तरह से समझी जाने वाली प्रौद्योगिकियाँ हैं।

• सिस्टम प्रबंधन, बैकअप / पुनर्स्थापना, प्रतिकृति, रिपोर्टिंग और आपदा वसूली सभी RDBMS प्लेटफार्मों पर अच्छी तरह से सॉर्ट किए जाते हैं।

• आप सभी प्रमुख RDBMS प्लेटफार्मों के लिए JDBC सहित क्लाइंट लाइब्रेरी प्राप्त कर सकते हैं।

• दृश्य प्रति उपयोगकर्ता अनुकूलन और आपके एप्लिकेशन मेटाडेटा को उत्पन्न करने के लिए उपयोग किया जा सकता है।

• यह XML क्षेत्रों या EAV संरचनाओं की तुलना में काफी अधिक कुशल है।

Comments

@ कोट: विस्तृत जवाब के लिए धन्यवाद। एक बड़ी बात जो मैं चिंतित था वह स्कीमा का "प्रत्याशित" परिवर्तन था, जो मुझे लगता है कि मुझे इसके माध्यम से सोचना होगा और इसे यथासंभव "पूर्व-विन्यास" बनाना होगा और बाद में कठोर स्कीमा परिवर्तनों से बचना होगा।

— tmbsundar

यदि वे तालिकाओं को साझा कर रहे हैं तो एक किरायेदार के लिए आपदा वसूली सरल नहीं है। (यदि प्रत्येक पंक्ति में एक किरायेदार आईडी नंबर है।)

— माइक शेरिल 'कैट रिकॉल'

ऐसा करें, लेकिन एक JSON कॉलम का उपयोग करें: gist.github.com/tobyhede/2715918

— mwhite

Answer 2

PostgreSQL के साथ आपके पास अलग-अलग डेटाबेस, अलग-अलग स्कीमा या मल्टी-टेनेंसी से निपटने के लिए विचारों का उपयोग करने का विकल्प है।

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

अलग-अलग स्कीमा बहुत लचीलेपन और सुरक्षा प्रदान करते हैं लेकिन उन्नयन को अधिक जटिल बनाते हैं क्योंकि उन्हें व्यक्तिगत रूप से लागू किया जाना चाहिए और यह केवल तभी आवश्यक है जब आपके किरायेदार पूरी तरह से अलग टेबल संरचनाओं का उपयोग करें; यदि वे उसी एप्लिकेशन का उपयोग कर रहे हैं तो यह संभव नहीं है।

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

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

आपकी एकमात्र संभावित चिंता यह है कि क्या आपको एक नया स्तंभ जोड़ने की आवश्यकता है जिसे मौजूदा सूचकांक में जोड़ने की आवश्यकता है या एक नए सूचकांक की आवश्यकता है। वह यह है कि जब सूचकांक बनाया जा रहा है तब तालिका उपयोग से लॉक हो सकती है - लेकिन PostgreSQL तालिका को लॉक किए बिना अनुक्रमणिका को समवर्ती रूप से बनाने की क्षमता का समर्थन करता है। यह तब तक ठीक काम करता है जब तक कि नए सूचकांक को अद्वितीय होने की आवश्यकता नहीं होती है और एक अद्वितीयता उल्लंघन का पता चलता है।

आपको संभवतः NoSQL डेटाबेस की आवश्यकता नहीं है क्योंकि वे स्कीमा को प्रभावी रूप से डेटाबेस से हटा देते हैं और इसके बजाय इसे प्रबंधित करने के लिए एप्लिकेशन की आवश्यकता होती है। यह आपके संस्करणों की तरह नहीं लगता है कि इस तरह के बलिदान की मांग करता है।

Comments

9.1 के साथ आप तालिका को लॉक किए बिना एक अद्वितीय बाधा या प्राथमिक कुंजी को भी बदल सकते हैं। यहाँ देखें: depesz.com/index.php/2011/02/19/…

— a_horse_with_no_name

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

— डंकन पॉल Dun

@ डंकनपूल: अंतर्दृष्टि के लिए धन्यवाद। मैं आपके उत्तर से समझता हूं कि Postgresql 'ऑनलाइन / लाइव स्कीमा परिवर्तन' की अनुमति देता है। लेकिन, जब मैं गूगल करता हूं, तो मुझे ज्यादातर 'फेसबुक ऑनलाइन स्कीमा चेंज' या 'पीटी-ऑनलाइन ...' आदि मिलते हैं, जो MySQL से संबंधित हैं। क्या आप एक लिंक या सामग्री के बारे में जानते हैं जो मुझे Postgresql के लिए लाइव स्कीमा परिवर्तन को समझने में मदद करता है? आपकी सहायता की सराहना। धन्यवाद।

— tmbsundar

यह लिंक बताता है कि आप टेबल को कैसे बदल सकते हैं postgresql.org/docs/8.1/static/ddl-alter.html । याद रखने के लिए महत्वपूर्ण सिद्धांत यह है कि टेबल या दृश्य बनाना, बदलना और गिराना वस्तुतः तात्कालिक है; इंडेक्स बनाते और बदलते समय कुछ भी लेकिन

— डंकन Pauly