मैं डेटाबेस डिज़ाइन संग्रहण लागत की गणना कैसे कर सकता हूं?

Question

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

इसके अलावा, आरडीबीएमएस ऑब्जेक्ट या कुंजी-मूल्य डेटाबेस की तुलना में डेटा स्टोरेज के लिए एक पूरी तरह से अलग दृष्टिकोण का उपयोग करते हैं।

डेटाबेस संग्रहण के लिए लागत (या कमरे की आवश्यकता) को जानने का प्रयास करने के लिए कुछ अच्छे संसाधन क्या हैं?

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

Answer 1

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

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

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

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

इन बातों

• जोड़ने और समय के साथ अनुक्रमित छोड़ने के सभी
• जोड़ने और समय के साथ की कमी छोड़ने,
• जोड़ने और समय के साथ कॉलम छोड़ने,
• जोड़ने और छोड़ने में समय के साथ टेबल ,

डिस्क उपयोग का कोई अनुमान समय की बर्बादी की तरह दिखता है। अकेले उनमें से किसी एक काफी डिस्क एक डेटाबेस के लिए आवश्यक स्थान बदल सकते हैं।

आप एक पंक्ति और एक पृष्ठ द्वारा आवश्यक स्थान की सटीकता से गणना कर सकते हैं। ("YourDBMSname पंक्ति लेआउट" और "YourDBMSname पृष्ठ लेआउट" के लिए Google आज़माएं।) लेकिन जब आप पंक्तियों की संख्या से गुणा करने की कोशिश करते हैं तो आपको पंक्तियों की संख्या का आकलन करना होगा। इससे आपको स्टीव मैककनेल ने "cone of uncertainty" के बड़े अंत में रखा है।

यदि आपने अपनी कंपनी में समय के साथ कई परियोजनाओं में डिस्क उपयोग को माप नहीं लिया है, तो अनुमान लगाया गया है कि उपरोक्त उन बुलेट बिंदुओं का प्रभाव अनुमान लगा रहा है।

पिछले फॉर्च्यून 100 कंपनी के लिए मैंने एक परिचालन डेटाबेस था जो 1 9 70 के दशक से उत्पादन में था। 40 वर्षों के दौरान 25 से अधिक प्रोग्रामिंग भाषाओं में लिखे गए सैकड़ों आवेदनों ने हर दिन उस चीज़ को मारा। (मुझे लगता है कि यह मूल रूप से आईबीएम के आईएमएस पर बनाया गया था; आज यह ओरेकल पर चलता है।)

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

तो, आप डेटाबेस डिज़ाइन और तैनाती पर्यावरण में अनुमान लगाने के जोखिम को कैसे कम करते हैं? 1 9 72 से एक सबक लें।

प्रोटोटाइप बनाएं, और इसे मापें।

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

। । । प्रोजेक्ट के बाद परियोजना एल्गोरिदम का एक सेट डिज़ाइन करती है और फिर उस समय पर ग्राहक-डिलिवरेबल सॉफ़्टवेयर के निर्माण में उतर जाती है जो पहली चीज़ के वितरण की मांग करती है। । । ।

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

फ्रेड ब्रूक्स, जूनियर, में पौराणिक मैन महीना, पी 116

Answer 2

यहां एक AskTom आलेख है जो मुझे उपयोगी पाया गया है। हालांकि ओरेकल-विशिष्ट है।

http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203