"अब - आप वर्णित समस्या से कैसे निपटेंगे?"
साधारण फ्लैट फाइलों के साथ।
यही कारण है
आपके पास 2.000.000 निकाय हैं। इकाई संख्या के आधार पर विभाजन:
level1= entity/10000
level2= (entity/100)%100
level3= entity%100
डेटा की प्रत्येक फ़ाइल level1/level2/level3/batch_of_data . है
फिर आप प्रसंस्करण के लिए नमूने वापस करने के लिए निर्देशिका के किसी दिए गए हिस्से में सभी फाइलों को पढ़ सकते हैं।
अगर कोई रिलेशनल डेटाबेस चाहता है, तो किसी दिए गए entity_id के लिए फ़ाइलों को उनके उपयोग के लिए डेटाबेस में लोड करें।
संपादित करें दिन संख्या पर।
-
date_id/entity_idविशिष्टता नियम नहीं है कुछ ऐसा जिसे संभालना है। यह (ए) फ़ाइल नामों पर मामूली रूप से लगाया गया है और (बी) पूछताछ के लिए अप्रासंगिक है। -
date_id"रोलओवर" का कोई मतलब नहीं है -- कोई प्रश्न नहीं है, इसलिए कुछ भी नाम बदलने की कोई आवश्यकता नहीं है।date_idयुग की तारीख से बंधे बिना बस बढ़ना चाहिए। यदि आप पुराने डेटा को शुद्ध करना चाहते हैं, तो पुरानी फ़ाइलों को हटा दें।
चूंकि कोई भी क्वेरी date_id पर निर्भर नहीं करती है , इसके साथ कभी कुछ करने की आवश्यकता नहीं है। यह उन सभी के लिए फ़ाइल नाम हो सकता है जो यह मायने रखता है।
date_id शामिल करने के लिए परिणाम सेट में, इसे फ़ाइल में अन्य चार विशेषताओं के साथ लिखें जो फ़ाइल की प्रत्येक पंक्ति में हैं।
संपादित करें खुले/बंद पर
लिखने के लिए, आपको फाइल (फाइलों) को खुला छोड़ना होगा। आप यह सुनिश्चित करने के लिए समय-समय पर फ्लश (या बंद/फिर से खोलें) करते हैं कि सामान वास्तव में डिस्क पर जा रहा है।
आपके लेखक की वास्तुकला के लिए आपके पास दो विकल्प हैं।
-
एक एकल "लेखक" प्रक्रिया है जो विभिन्न स्रोतों से डेटा को समेकित करती है। यदि प्रश्न अपेक्षाकृत बार-बार होते हैं तो यह सहायक होता है। आप लिखने के समय डेटा मर्ज करने के लिए भुगतान करते हैं।
-
लेखन के लिए एक साथ कई फाइलें खुली रखें। क्वेरी करते समय, इन फ़ाइलों को एक परिणाम में मर्ज करें। यह सहायक है क्योंकि प्रश्न अपेक्षाकृत दुर्लभ हैं। आप क्वेरी के समय डेटा मर्ज करने के लिए भुगतान करते हैं।
