सबसे तेज़ फ़ाइल का उपयोग/भंडारण?

Question

मेरे पास डिस्क पर स्टोर करने के लिए लगभग 750,000,000 फ़ाइलें हैं I और भी मुझे इन फ़ाइलों को यादृच्छिक रूप से एक्सेस करने में सक्षम होना चाहिए - किसी भी समय दी गई फ़ाइल - में सबसे कम समय संभव। इन फ़ाइलों को सबसे तेज़ी से एक्सेस करने के लिए मुझे क्या करने की ज़रूरत है?

इसे हैश तालिका की तरह सोचें, केवल हैश कुंजी फ़ाइल नाम हैं और संबंधित मान फ़ाइलें डेटा हैं।

एक सहकर्मी ने उन्हें इस तरह की निर्देशिकाओं में व्यवस्थित करने के लिए कहा: अगर मैं "foobar.txt" नाम की एक फ़ाइल को स्टोर करना चाहता हूं और इसे डी: ड्राइव पर संग्रहीत किया गया है, तो फ़ाइल को "डी: \ f \ o \ o \ b \ एक \ r। \ t \ एक्स \ t "। वह क्यों नहीं समझा सकता हालांकि यह एक अच्छा विचार था। क्या इस विचार के लिए कुछ भी है?

कोई विचार?

इस का क्रूक्स एक फ़ाइल ढूंढ रहा है। फ़ाइल को नाम से खोलने का सबसे तेज़ तरीका क्या है?

संपादित करें:

मैं फाइल सिस्टम है जिस पर इस डेटा संग्रहीत किया जाता है पर कोई नियंत्रण नहीं। यह एनटीएफएस या एफएटी 32 होगा।

डेटाबेस में फ़ाइल डेटा संग्रहीत करना एक विकल्प नहीं है।

फ़ाइलें बहुत छोटी होने वाली हैं - अधिकतम 1 केबी।

ड्राइव ठोस स्थिति होने जा रहे हैं।

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

आइटम लगातार जोड़े जाएंगे, और कभी-कभी हटा दिए जाते हैं।

एकाधिक फ़ाइलों को एकल फ़ाइलों में समेकित करना अव्यवहारिक होगा क्योंकि फ़ाइलों के बीच कोई तार्किक संबंध नहीं है।

मुझे इस सामान पर परीक्षण चलाकर कुछ मीट्रिक इकट्ठा करना अच्छा लगेगा, लेकिन यह प्रयास परियोजना के रूप में उपभोग करने वाला बन सकता है!

EDIT2:

मैं कई पूरी तरह से जवाब वोट दें करने के लिए, चाहे वे स्पॉट पर या नहीं कर रहे हैं चाहते हैं, और नहीं कर सकते हैं क्योंकि मेरे नौसिखिया स्थिति की। क्षमा करें दोस्तों!

Answer 1

क्या व्यक्तिगत फाइलों के बीच कोई संबंध है? जहां तक ​​पहुंच के समय जाते हैं, आप जो फ़ोल्डर्स डालते हैं, वे अधिक प्रभावित नहीं होंगे; डिस्क पर भौतिक स्थान क्या मायने रखता है।

Answer 2

ऐसा लगता है कि यह बड़े पैमाने पर फाइल सिस्टम विकल्प का सवाल होगा। देखने के लिए एक विकल्प ZFS हो सकता है, यह उच्च वॉल्यूम अनुप्रयोगों के लिए डिज़ाइन किया गया है।

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

अद्यतन: आपकी अतिरिक्त जानकारी निश्चित रूप से सहायक है। एफएटी 32 और एनटीएफएस के बीच एक विकल्प को देखते हुए, निश्चित रूप से एनटीएफएस चुनें। एक ही निर्देशिका में बहुत सारी फाइलों को स्टोर न करें, 100,000 विचार करने के लिए ऊपरी सीमा हो सकती है (हालांकि आपको प्रयोग करना होगा, कोई कठोर और तेज़ नियम नहीं है)। प्रत्येक पत्र के लिए आपके मित्र का एक नया निर्देशिका का सुझाव शायद अधिक है, तो आप इसे हर चार अक्षरों या किसी चीज़ पर तोड़ने पर विचार कर सकते हैं। चुनने का सबसे अच्छा मूल्य आपके डेटासेट के आकार पर निर्भर करता है।

नाम तोड़ने का कारण यह एक अच्छा विचार है कि आमतौर पर फाइल सिस्टम का प्रदर्शन घटता है क्योंकि निर्देशिका में फ़ाइलों की संख्या बढ़ जाती है। यह उपयोग में फाइल सिस्टम पर निर्भर करता है, उदाहरण के लिए FAT32 प्रति निर्देशिका केवल कुछ हज़ार फाइलों के साथ भयानक होगा। आप फ़ाइल नाम भी को तोड़ना नहीं चाहते हैं, इसलिए आप फाइल सिस्टम को निर्देशिका लुकअप की संख्या को कम कर देंगे।

Answer 3

डेटाबेस तालिका में पथ को स्वीकार्य क्यों नहीं है?

Answer 4

मेरा अनुमान है कि वह डिस्क पर बनाने के लिए Trie डेटा संरचना के बारे में सोच रहा है जहां नोड एक निर्देशिका है।

Answer 5

यह बेहद कई कारकों पर निर्भर:

• क्या फ़ाइल सिस्टम प्रयोग कर रहे हैं?
• प्रत्येक फ़ाइल कितनी बड़ी है?
• आप किस प्रकार के ड्राइव का उपयोग कर रहे हैं?
• एक्सेस पैटर्न क्या हैं?

यादृच्छिक रूप से फ़ाइलों को पूरी तरह से एक्सेस करना पारंपरिक डिस्क में वास्तव में महंगा है। ठोस राज्य ड्राइव का उपयोग करना एक महत्वपूर्ण सुधार है।

यदि आप एक एक्सेस पैटर्न का कारण बन सकते हैं, तो आप इन फ़ाइलों को रखने के संदर्भ के क्षेत्र का लाभ उठाने में सक्षम हो सकते हैं।

एक और संभावित तरीका डेटाबेस सिस्टम का उपयोग करना है, और सिस्टम की कैशिंग तंत्र का लाभ उठाने के लिए डेटाबेस में इन फ़ाइलों को संग्रहीत करना है।

अद्यतन:

अपने अद्यतन को देखते हुए यह possbile आप कुछ फ़ाइलों को मजबूत है? फ़ाइल सिस्टम (fat32, ntfs) में क्लस्टर आकार के रूप में स्टोर करने के लिए 1k फ़ाइलें बहुत प्रभावी नहीं हैं और क्लस्टर आकार से छोटी होने पर भी प्रत्येक फ़ाइल क्लस्टर आकार का उपयोग करेगी। प्रदर्शन चिंताओं के साथ, प्रत्येक फ़ोल्डर में फ़ाइलों की संख्या पर आमतौर पर एक सीमा होती है। आप एक फ़ोल्डर में 10k फ़ाइलों को डालकर एक साधारण बेंचमार्क कर सकते हैं यह देखने के लिए कि कितना प्रदर्शन घटता है।

यदि आप त्रिभुज संरचना का उपयोग करने के लिए सेट हैं, तो मैं फ़ाइल नामों के वितरण का सर्वेक्षण करने का सुझाव दूंगा और फिर वितरण के आधार पर उन्हें विभिन्न फ़ोल्डर्स में तोड़ दूंगा।

Answer 6

मैं hadoops मॉडल देखता हूं।

पी

Answer 7

यह वही फाइल सिस्टम आप पर फ़ाइलों को स्टोर करने जा रहे हैं पर एक बड़ी हद तक निर्भर करता है। बड़ी संख्या में फाइलों से निपटने में फाइल सिस्टम की क्षमताओं में व्यापक रूप से भिन्नता है।

आपका सहकर्मी अनिवार्य रूप से Trie data structure के उपयोग का सुझाव दे रहा है। ऐसी निर्देशिका संरचना का उपयोग करने का अर्थ यह होगा कि प्रत्येक निर्देशिका स्तर पर चुनने के लिए केवल कुछ मुट्ठी भर फाइलें/निर्देशिकाएं होती हैं; इससे मदद मिल सकती है क्योंकि निर्देशिका में फ़ाइलों की संख्या में से एक तक पहुंचने का समय भी बढ़ जाता है (वास्तविक समय अंतर फ़ाइल सिस्टम प्रकार पर निर्भर करता है।)

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

इसके अलावा, मैं चाहता हूं फाइल को अपने पूरे नाम से स्टोर करें, यदि आवश्यक हो, तो यह मैन्युअल रूप से इस निर्देशिका संरचना को पार करना आसान बनाता है।

तो, मैं foobar.txt संग्रहीत करेंगे रूप f/ओ/ओ/बी/foobar.txt

Answer 8

सबसे पहले, फ़ाइल का आकार बहुत छोटा है। कोई भी फाइल सिस्टम कम से कम 4 गुना अधिक जगह खाएगा। मेरा मतलब है डिस्क पर कोई भी फ़ाइल 1kb फ़ाइल के लिए 4kb पर कब्जा कर लेगी। विशेष रूप से एसएसडी डिस्क पर, 4 केबी क्षेत्र आदर्श होगा।

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

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

यदि आप कर सकते हैं, तो उन्हें कम से कम एनटीएफएस या यूनिक्स स्वाद की कुछ हालिया फाइल सिस्टम के रूप में प्रारूपित न करें। चूंकि फाइलों का कुल आकार इतना बड़ा नहीं है, एनटीएफएस पर्याप्त हो सकता है लेकिन जेएफएस बेहतर विकल्प है ...

Answer 9

वह फ़ाइल एल्गोरिदम काम करेगा, लेकिन यह इष्टतम नहीं है। मुझे लगता है कि 2 या 3 वर्ण "सेगमेंट" का उपयोग प्रदर्शन के लिए बेहतर होगा - खासकर जब आप बैकअप करने पर विचार करना शुरू करते हैं।

उदाहरण के लिए:
घ: \ भंडारण \ लिए \ ओब \ ar \ foobar.txt
या
घ: \ भंडारण \ foo \ बार \ foobar.txt

उपयोग के कुछ लाभ हैं इस प्रकार के एल्गोरिदम:

1. कोई डेटाबेस एक्सेस आवश्यक नहीं है।
2. फ़ाइलों को कई निर्देशिकाओं में फैलाया जाएगा। यदि आप उन्हें बाहर नहीं फैलाते हैं, तो आप गंभीर प्रदर्शन समस्याओं को प्रभावित करेंगे। (मैं किसी फ़ोल्डर में ~ 40,000 फ़ाइलों पर मुद्दों वाले किसी व्यक्ति के बारे में सुनकर याद करता हूं, लेकिन मुझे उस नंबर पर विश्वास नहीं है।)
3. फ़ाइल की खोज करने की कोई आवश्यकता नहीं है। आप फ़ाइल नाम से फ़ाइल कहां से ठीक से पता लगा सकते हैं।
4. सरलता। आप इस एल्गोरिदम को किसी भी भाषा के बारे में बहुत आसानी से पोर्ट कर सकते हैं।

वहाँ यह भी करने के लिए कुछ नीचे पहलू हैं:

1. कई निर्देशिका बैकअप धीमा करने के लिए नेतृत्व कर सकते हैं। इन निर्देशिकाओं पर रिकर्सिव diffs करने की कल्पना करो।
2. स्केलेबिलिटी। जब आप डिस्क स्थान से बाहर निकलते हैं और अधिक संग्रहण जोड़ने की आवश्यकता होती है तो क्या होता है?
3. आपकी फ़ाइल नामों में रिक्त स्थान नहीं हो सकते हैं।

Answer 10

मैं जानता हूँ कि यह एक कुछ वर्षों देर हो चुकी है, लेकिन शायद यह अगले आदमी मदद कर सकते हैं ..

मेरे सुझाव का प्रयोग कर एक सैन, एक जेड ड्राइव जो अन्य सर्वर के रूप में अच्छी तरह से करने के लिए मैप कर सकते हैं करने के लिए मैप किया। मैं आपके दोस्त के साथ जाने वाले फ़ोल्डर पथ के साथ नहीं जाऊंगा, लेकिन ड्राइव के साथ अधिक: \ clientid \ year \ month \ day \ और यदि आप एक दिन में 100k से अधिक दस्तावेज़ों को निगलना चाहते हैं, तो आप घंटे के लिए उप फ़ोल्डर्स जोड़ सकते हैं और यदि आवश्यक हो तो भी मिनट। इस तरह, यदि आवश्यक हो तो सेकंड से नीचे तक जाने के दौरान आपके पास 60 से अधिक उप फ़ोल्डर्स नहीं होते हैं। त्वरित पुनर्प्राप्ति और रिपोर्टिंग के लिए एसक्यूएल में लिंक स्टोर करें। यह फ़ोल्डर पथ को उदाहरण के लिए बहुत छोटा बनाता है: Z: \ 05 \ 2004 \ 02 \ 26 \ 09 \ 55 \ filename.txt ताकि आप बोर्ड में किसी भी 256 सीमाओं में भाग न सकें।

उम्मीद है कि किसी की मदद करता है। :)