नामांकन तालिका september_2010 समय पर निर्भर बड़े डेटा सेट के लिए स्वीकार्य और कुशल है?

Question

मुझे प्रति दिन लगभग 73,200 रिकॉर्ड स्टोर करने की आवश्यकता है जिसमें डेटा के 3 अंक होते हैं: आईडी, दिनांक और पूर्णांक।

अपनी टीम के कुछ सदस्यों महीने का उपयोग करते हुए तालिका नाम (september_2010) के रूप में तालिका बनाने का सुझाव देते हैं, जबकि दूसरों को सुझाव दे उस में डेटा के बहुत सारे के साथ एक मेज ...

कर रहे हैं कि यह कैसे से निपटने के लिए पर कोई सुझाव डाटा की मात्रा? धन्यवाद।

========== सभी प्रतिक्रियाओं के लिए धन्यवाद।

Answer 1

से बढ़ेगा के लिए मैं कि के खिलाफ सलाह देते हैं। मैं इसे antipatternमेटाडाटा ट्रिबल्स पर कॉल करता हूं। यह कई समस्याएं पैदा करता है:

• आपको हर साल एक नई तालिका बनाने के लिए याद रखना होगा या फिर आपका ऐप टूट जाएगा।
• वर्ष के बावजूद सभी पंक्तियों के खिलाफ समेकन योग कठिन है।
• एक तिथि को अद्यतन करने का मतलब संभावित रूप से एक तालिका से दूसरी पंक्ति में एक पंक्ति को स्थानांतरित करना है।
• एकाधिक तालिकाओं में छद्मकी की विशिष्टता की गारंटी देना मुश्किल है।

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

Answer 2

इस बात पर निर्भर करता है कि आपको किन खोजों की आवश्यकता होगी। यदि आमतौर पर तिथि से बाधित होता है, तो विभाजन अच्छा होता है।

यदि आप विभाजित करते हैं, तो foo_2010_09 जैसी तालिकाओं का नामकरण करने पर विचार करें ताकि तालिकाएं अल्फान्यूमेरिक रूप से क्रमबद्ध हों।

Answer 3

ऐसा लगता है कि यह एक टेबल में सबकुछ ठीक से होना चाहिए। यह प्रति वर्ष 12 टेबल के विपरीत, 1 तालिका बनाए रखने के लिए भविष्य में पुनर्प्राप्ति को अधिक आसान बना देगा। प्रति दिन 73,200 रिकॉर्ड पर आपको 100,000,000 हिट करने में लगभग 4 साल लगेंगे जो अभी भी MySQLs क्षमताओं के भीतर अच्छी तरह से है।

Answer 4

आपका डीबी मंच क्या है?

SQL सर्वर 2K5 + में आप दिनांक पर विभाजन कर सकते हैं।

मेरा बुरा, मैंने टैग को नोटिस नहीं किया। @thetaiko सही है और यह इस से निपटने के लिए MySQL क्षमताओं के भीतर अच्छी तरह से है।

Answer 5

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

नामकरण के लिए मैं tablename_yyyymm करूँगा।

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

Answer 6

बिलकुल नहीं।
यह तालिकाओं के बीच संबंध बर्बाद कर देगा।
तालिका संबंधों के आधार पर फ़ील्ड संबंध मूल्य के आधार पर बनाया जा रहा है।

विशेष रूप से यह बहुत ही मेज कि सिर्फ 300MB/वर्ष

Answer 7

अपनी टीम के कुछ सदस्यों महीने का उपयोग करते हुए तालिका नाम (september_2010) के रूप में तालिका बनाने का सुझाव देते हैं, जबकि दूसरों को सुझाव दे उस में डेटा के बहुत सारे के साथ एक मेज ...

सुनने मत हो रही है उनको। आप पहले ही डेट स्टैंप संग्रहीत कर रहे हैं, अलग-अलग महीनों के बारे में क्या डेटा को इस तरह विभाजित करना अच्छा विचार है? इंजन बड़े डेटा सेट को ठीक से संभाल लेगा, इसलिए महीने के आधार पर विभाजित करने से कृत्रिम रूप से डेटा अलग नहीं होता है।

Answer 8

इसलिए 100 दिनों में आपके पास 7.3 एम पंक्तियां हैं, जो लगभग 25 एम साल या उससे भी कम है। 25 एम पंक्तियां अब बहुत कुछ नहीं है। MySQL लाखों पंक्तियों के साथ तालिकाओं को संभाल सकता है। यह वास्तव में आपके हार्डवेयर और आपके क्वेरी प्रकार और क्वेरी आवृत्ति पर निर्भर करता है।

लेकिन आप उस तालिका को विभाजित करने में सक्षम होना चाहिए (यदि MySQL विभाजन का समर्थन करता है), जो आप वर्णन कर रहे हैं वह विभाजन का पुराना SQL सर्वर तरीका है। उन मासिक तालिकाओं के निर्माण के बाद आप एक ऐसा दृश्य तैयार करेंगे जो उन्हें एक बड़ी तालिका की तरह दिखने के लिए एक साथ जोड़ता है ... जो अनिवार्य रूप से विभाजन करता है लेकिन यह सभी अंडर-द-कवर और पूरी तरह अनुकूलित है।

Answer 9

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

हम एक (माईआईएसएएम) तालिका में 200+ मिलियन समय आधारित रिकॉर्ड स्टोर करते हैं, और प्रश्न अभी भी तेज हैं।

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

ऐसी चीज जो बड़ी संख्या में रिकॉर्ड्स के साथ बहुत दर्दनाक हो जाती है, जब आपको पुराने डेटा को हटाना होता है, तो इसमें काफी समय लग सकता है (10 मिनटों से 2 घंटे उदाहरण के लिए सैकड़ों mullions पंक्तियों के साथ तालिकाओं में एक महीने के लायक डेटा पोंछते हैं)। इसी कारण से हम partitioning टेबल हैं, और एक समय_डिमेंशन का उपयोग करें (उदाहरण के लिए टाइम_डिमेंशन टेबल थोड़ा नीचे here) प्रबंधन के लिए संबंध तालिका सिम के बजाय अवधि तारीख दिनांक/डेटाटाइम कॉलम या स्ट्रिंग्स/वर्चर्स तिथियों का प्रतिनिधित्व करते हैं।

Answer 10

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

Answer 11

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

हालांकि यह भी इस बात पर निर्भर करता है कि आप इसे कैसे एक्सेस करना चाहते हैं। यदि पुरानी प्रविष्टियां वास्तव में केवल अभिलेखीय उद्देश्यों के लिए हैं, तो संग्रह पैटर्न एक विकल्प है।वर्जनिंग सिस्टम के लिए यह बेहद आम तौर पर इस्तेमाल किए गए डेटा को अलग करने के लिए आम है। आपके मामले में आप केवल मुख्य तालिका से बाहर निकलने के लिए सबकुछ> 1 वर्ष चाहते हैं। और यह सख्ती से डेटाबेस प्रशासन कार्य है, न कि अनुप्रयोग व्यवहार। आवेदन केवल वर्तमान सूची और _archive सूची में शामिल होगा, अगर बिल्कुल भी। फिर, यह अत्यधिक उपयोग मामले पर निर्भर करता है। क्या पुरानी प्रविष्टियों को आम तौर पर जरूरी है? क्या नियमित रूप से प्रक्रिया करने के लिए बहुत अधिक डेटा है?

Answer 12

मेरी पहली प्रतिक्रिया है: आहाहाह्ह्ह्ह्ह्ह्ह्ह्ह !!!!!!

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

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

सभी डेटा एक उचित-सामान्यीकृत तालिका में, उपरोक्त प्रश्नों के साथ बहुत ही मामूली हैं। प्रत्येक महीने के लिए अलग तालिकाओं के साथ, वे एक दुःस्वप्न हैं।

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