2010-04-01 21 views
7

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

मेरा प्रश्न यह है: क्या यह एक फ़ाइल (500k-1Mb) होने के लिए तेज़ होगा और मेरे एप्लिकेशन को खोलने, लूप के माध्यम से, फ़ाइल ढूंढने और बंद करने के लिए तेज़ होगा या रिकॉर्ड को अलग करने और नामित करने के लिए तेज़ होगा कुछ उचित सम्मेलन ताकि एप्लिकेशन को आवश्यक डेटा ढूंढने के लिए फ़ाइल नामों पर लूप हो सकता है?

मुझे पता है कि मेरा प्रश्न काफी सामान्य है इसलिए विषय पर किसी भी अच्छे लेख की दिशा के रूप में सुझावों की सराहना की जाती है।

अपने समय के लिए धन्यवाद अग्रिम में बहुत ज्यादा, दान

+1

क्या आपने SQLite माना है? यह आपके आवेदन में कोड जोड़ने से बहुत अलग नहीं है। असल में, आप इसे सचमुच SQLite कोड के साथ कर सकते हैं क्योंकि यह सार्वजनिक डोमेन में है। आप अपने आवेदन के लिए अपनी गति बेंचमार्क करना चाह सकते हैं। – Ioan

उत्तर

7

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

आप निर्देशिकाओं के कई स्तरों का उपयोग करके "एक निर्देशिका में बहुत अधिक फाइलें न डालें" लक्ष्य प्राप्त कर सकते हैं - उदाहरण के लिए, मुख्य FOOBAR के साथ रिकॉर्ड data/FOOBAR की बजाय data/F/FO/FOOBAR में संग्रहीत किया जा सकता है।

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

आप "डेटाबेस का उपयोग नहीं कर सकते" प्रतिबंध पर पुनर्विचार करना चाह सकते हैं, क्योंकि आप प्रभावी ढंग से बस अपना खुद का डेटाबेस बना रहे हैं।

+0

आपके इनपुट के लिए बहुत बहुत धन्यवाद। इंडेक्सिंग निश्चित रूप से विचार करने के लिए कुछ है। डेटाबेस प्रतिबंध एक बाधा नहीं है जिसे हम दुर्भाग्य से नियंत्रित कर चुके हैं ... – Dan

+0

"विभाजित निर्देशिकाओं" का उपयोग करना प्रदर्शन कारणों से आप ऐसा कुछ नहीं करते हैं, जब आप बहुत सारे को संभालने की आवश्यकता होती है तो यह स्केलेबिलिटी जोड़ने का एक तरीका है फाइलें (हम यहां एक ही डीआईआर में सौ हजार फाइलें बोल रहे हैं)। –

+1

... और कारण है कि एक निर्देशिका में हजारों फाइलें खराब हैं: यह धीमी है। – caf

2

आम तौर पर यह कई छोटे फ़ाइलों के लिए बेहतर है। स्मृति उपयोग को कम रखता है और इसके माध्यम से खोज करते समय प्रदर्शन बेहतर होता है।

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

1

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

3

आपका डेटा 1 एमबी दिया गया है, मैं इसे पूरी तरह से स्मृति में संग्रहीत करने पर विचार करता हूं।

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

1

सी में खुली फ़ाइल और समापन फ़ाइल यानी आपके पास 500 फाइलें 2 केबी बहुत अधिक समय लेती हैं ... और यदि आप इसे संसाधित करते हैं तो 1000 एडिटोनल ऑपरेशन आपके एप्लिकेशन में जोड़ा जाएगा (500 ओपनिंग फाइल और 500 क्लोजिंग)। .. जबकि 1 एमबी आकार के साथ केवल 1 फ़ाइल आपको 1000 अतिरिक्त ऑपरेशन बचाएगी ... (यह पूरी तरह से मेरी व्यक्तिगत राय है ...)

4

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

+0

उपयुक्त फ़ाइल नाम का निर्माण बहुत समझ में आता है और काम करने के लिए बहुत कठिन नहीं होना चाहिए। बहुत बहुत धन्यवाद। – Dan

1

यह सब आपके फ़ाइल सिस्टम, ब्लॉक आकार और मेमोरी कैश पर निर्भर करता है।

सामान्य रूप से, मापें और पता लगाएं कि यह वास्तविक समस्या है क्योंकि premature optimization से बचा जाना चाहिए। ऐसा हो सकता है कि एक फ़ाइल बनाम कई छोटी फाइलों का उपयोग अभ्यास में प्रदर्शन के लिए ज्यादा मायने रखता नहीं है और यह विकल्प स्पष्टता और रखरखाव के आधार पर होना चाहिए।

(मैं निश्चित रूप से कह सकता हूं कि आपको रैखिक फ़ाइल खोज का सहारा नहीं लेना चाहिए, इसके बजाय ओ (1) समय में फ़ाइल को इंगित करने के लिए नामकरण सम्मेलन का उपयोग करना चाहिए)।

0

आप डीबी का उपयोग क्यों नहीं कर सकते, मैं उत्सुक हूँ? मैं आपकी वरीयता का सम्मान करता हूं, लेकिन सिर्फ यह सुनिश्चित करना चाहता हूं कि यह सही कारण के लिए है।

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

संबंधित मुद्दे