2011-03-02 16 views
9

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

विशेषताएं मैं 1) लिखने में सक्षम रहा हूँ/डिस्क 2 से फाइल) नई फ़ाइलें 2) संस्करण/लेखा परीक्षा प्रदान करें (वैकल्पिक)

मैं के लिए यादृच्छिक निर्देशिका/उप-निर्देशिका बनाएं करने में सक्षम पढ़ जेसीआर एपीआई को देख रहा था और यह आशाजनक लग रहा है लेकिन यह एक कार्यक्षेत्र के साथ शुरू होता है और यह सुनिश्चित नहीं करता कि कई नोड्स होने पर प्रदर्शन क्या होगा।

उत्तर

0

अपने स्वयं के कस्टम समाधान के साथ java.io पैकेज में कार्यक्षमता को संयोजित करें।

java.io पैकेज डिस्क से फ़ाइलों को लिख और पढ़ सकता है और नई फ़ाइलों के लिए मनमानी निर्देशिका या उप-निर्देशिका बना सकता है। कोई बाहरी एपीआई आवश्यक नहीं है।

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

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

ऐसा लगता है कि आपकी आवश्यकताओं के अनुरूप एक समाधान इंजीनियर करना कहीं अधिक आसान होगा।

1

संपादित करें: जेसीपी बहुत अच्छा दिखता है। मैं यह देखने का सुझाव दूंगा कि यह वास्तव में आपके उपयोग-मामले के लिए कैसे प्रदर्शन करता है।

यदि आप विंडोज़ पर अपना सिस्टम चला रहे हैं और किसी बिंदु पर एक भयानक एन^2 प्रदर्शन हिट देखा है, तो आप शायद स्वचालित 8.3 फाइलनाम पीढ़ी द्वारा किए गए प्रदर्शन हिट के खिलाफ चल रहे हैं। बेशक, आप disable 8.3 filename generation कर सकते हैं, लेकिन जैसा कि आपने बताया है, फिर भी एक बड़ी निर्देशिका में बड़ी संख्या में फ़ाइलों को स्टोर करना एक अच्छा विचार नहीं होगा।

बड़ी संख्या में फ़ाइलों को संभालने के लिए मैंने देखा एक आम रणनीति फ़ाइल नाम के पहले एन अक्षरों के लिए निर्देशिका बनाना है। उदाहरण के लिए, document.pdf d/o/c/u/m/document.pdf में संग्रहीत किया जाएगा। मुझे जावा में ऐसा करने के लिए लाइब्रेरी को कभी भी याद नहीं है, लेकिन यह बहुत सरल लगता है। यदि आवश्यक हो, तो आप लुकअप टेबल (समान रूप से वितरित यादृच्छिक फ़ाइल नामों के लिए मैपिंग कुंजियों) को स्टोर करने के लिए डेटाबेस बना सकते हैं, इसलिए आपको हर बार अपनी अनुक्रमणिका को पुनर्निर्माण नहीं करना पड़ेगा। यदि आप स्वचालित समर्पण का लाभ प्राप्त करना चाहते हैं, तो आप प्रत्येक फ़ाइल की सामग्री को हश कर सकते हैं और चेकसम को फ़ाइल नाम के रूप में उपयोग कर सकते हैं (लेकिन आप एक चेक भी जोड़ना चाहते हैं ताकि आप गलती से उस फ़ाइल को त्याग न दें जिसका चेकसम एक मौजूदा फ़ाइल से मेल खाता हो हालांकि सामग्री वास्तव में अलग हैं)।

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

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