डाटाबेस डिज़ाइन - एक टेबल में रिकॉर्ड के अरबों?

Question

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

क्या सभी चैट रूम के लिए संदेशों को संग्रहीत करने के लिए एक विशाल टेबल बनाने के लिए गलत होना चाहिए, यह जानकर कि अंततः उस तालिका में अरबों रिकॉर्ड हो सकते हैं?

क्या यह प्रत्येक कमरे के लिए गतिशील रूप से एक टेबल बनाने के लिए और समझदार होगा कि उस कमरे के उस कमरे में केवल उस तालिका में स्टोर करें?

Answer 1

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

Answer 2

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

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

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

Answer 3

रिकॉर्ड के अरबों?

मान लीजिए कि आपके पास लगातार 1000 सक्रिय उपयोगकर्ता 1 संदेश प्रति मिनट हैं, इसके परिणामस्वरूप प्रति दिन 1.5mio संदेश और प्रति वर्ष लगभग 500mio संदेश होते हैं।

यदि आपको अभी भी कई वर्षों के चैट संदेशों को स्टोर करने की आवश्यकता है (क्या?), तो आप उन्हें साल-आधारित टेबल में संग्रहित कर सकते हैं।

मैं निश्चित रूप से कमरे-आधारित तालिकाओं के गतिशील निर्माण के खिलाफ बहस करता हूं।

Answer 4

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

आप श्रेणी आधारित विभाजन के बारे में सोचना चाहेंगे। एक वर्ष उपसर्ग के साथ अपनी तालिका की 'प्रतियां'। या शायद एक 'वर्तमान' और संग्रह तालिका

इन दोनों दृष्टिकोणों का अर्थ है कि आपकी क्वेरी अर्थपूर्ण अधिक जटिल है {मान लें कि किसी ने बहु-वर्ष की खोज की है}, तो आपको कई तालिकाओं से पूछना होगा।

हालांकि, उल्टा यह है कि आपकी 'वर्तमान' तालिका लगभग स्थिर आकार में रहेगी, और संग्रह अधिक सरल है। - {तुम सिर्फ तालिका 2005_Chat ड्रॉप कर सकते हैं जब आप 2005 के आंकड़ों को संग्रहीत करना चाहते}

-Ace