सवाल फाइल सिस्टम में एक लाख छवियों को संग्रहित करना


मेरे पास एक प्रोजेक्ट है जो बड़ी संख्या में छवियां उत्पन्न करेगा। शुरू करने के लिए लगभग 1,000,000। वे बड़ी छवियां नहीं हैं इसलिए मैं उन्हें शुरुआत में एक मशीन पर स्टोर करूंगा।

इन छवियों को कुशलता से संग्रहीत करने पर आपने अनुशंसा की है? (वर्तमान में एनटीएफएस फाइल सिस्टम)

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

बेहतर नामकरण योजना क्या होगी:

ए / बी / सी / 0 ... जेड / जेड / जेड / 99 9

या

ए / बी / सी / 000 ... जेड / जेड / जेड / 99 9

इस पर कोई विचार है?


75
2017-12-17 16:52


मूल


क्या वे विशिष्ट उपयोगकर्ताओं या सिर्फ जेनेरिक से बंधे हैं? क्या वे किसी भी फैशन में समूहित हैं?
केवल सामान्य कुछ तकनीकी उपकरणों द्वारा उत्पन्न छवियों का एक गुच्छा। मैं उन्हें समय बिताने के बारे में सोचने के लिए 1 अप से वृद्धिशील नाम दे रहा हूं। - s.mihai
वे कैसे उपयोग / उपयोग किए जा रहे हैं? एक bespoke ऐप के माध्यम से या क्या? - dove
क्या यह आप हो? i46.tinypic.com/1z55k7q.jpg
:)) हाँ ... 1 मिलियन। अश्लील छवियाँ :)) - s.mihai


जवाब:


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

डेटाबेस के लिए वास्तविक पथ स्टोर न करें। छवि के अनुक्रम संख्या को डेटाबेस में संग्रहीत करने के लिए बेहतर है और फ़ंक्शन है जो अनुक्रम संख्या से पथ उत्पन्न कर सकता है। उदाहरण के लिए:

 File path = generatePathFromSequenceNumber(sequenceNumber);

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

मैं निर्देशिका संरचना उत्पन्न करने के लिए इस तरह के एल्गोरिदम का उपयोग करूंगा:

  1. पहले पैड जब तक आपके पास कम से कम 12 अंकों की स्ट्रिंग न हो, तब तक आप प्रमुख शून्यों के साथ अनुक्रम संख्या। यह आपकी फाइल का नाम है। आप एक प्रत्यय जोड़ना चाह सकते हैं:
    • 12345 -> 000000012345.jpg
  2. फिर स्ट्रिंग को 2 या 3 वर्ण ब्लॉक में विभाजित करें जहां प्रत्येक ब्लॉक निर्देशिका स्तर को दर्शाता है। निर्देशिका स्तर की एक निश्चित संख्या है (उदाहरण के लिए 3):
    • 000000012345 -> 000/000/012
  3. फ़ाइल को जेनरेट की गई निर्देशिका में स्टोर करें:
    • इस प्रकार अनुक्रम आईडी के साथ फ़ाइल के लिए पूर्ण पथ और फ़ाइल फ़ाइल नाम 123 है 000/000/012/00000000012345.jpg
    • अनुक्रम आईडी के साथ फ़ाइल के लिए 12345678901234 रास्ता होगा 123/456/789/12345678901234.jpg

निर्देशिका संरचनाओं और फ़ाइल भंडारण के बारे में कुछ बातें विचार करने के लिए:

  • उपरोक्त एल्गोरिदम आपको एक प्रणाली देता है जहां प्रत्येक पत्ती निर्देशिका में अधिकतम 1000 फाइलें होती हैं (यदि आपके पास कुल 1 000 000 000 000 फाइलें हैं)
  • उदाहरण के लिए, निर्देशिका में कितनी फ़ाइलें और उप-निर्देशिकाएं हो सकती हैं, इस सीमाएं हो सकती हैं लिनक्स पर ext3 फाइल सिस्टम प्रति निर्देशिका में 31998 उप-निर्देशिकाओं की सीमा है।
  • सामान्य उपकरण (WinZip, Windows Explorer, कमांड लाइन, बैश खोल इत्यादि) बहुत अच्छी तरह से काम नहीं कर सकते हैं यदि आपके पास प्रति निर्देशिका बड़ी संख्या में फाइलें हैं (> 1000)
  • निर्देशिका संरचना स्वयं कुछ डिस्क स्थान लेगी, इसलिए आप बहुत अधिक निर्देशिका नहीं चाहते हैं।
  • उपरोक्त संरचना के साथ आप फ़ाइल फ़ाइल को देखकर छवि फ़ाइल के लिए हमेशा सही पथ पा सकते हैं, अगर आप अपनी निर्देशिका संरचनाओं को गड़बड़ कर देते हैं।
  • यदि आपको कई मशीनों से फ़ाइलों तक पहुंचने की आवश्यकता है, तो फ़ाइलों को नेटवर्क फ़ाइल सिस्टम के माध्यम से साझा करने पर विचार करें।
  • यदि आप बहुत सारी फाइलें हटाते हैं तो उपर्युक्त निर्देशिका संरचना काम नहीं करेगी। यह निर्देशिका संरचना में "छेद" छोड़ देता है। लेकिन चूंकि आप किसी भी फाइल को हटा नहीं रहे हैं, यह ठीक होना चाहिए।

70
2017-12-17 17:32



बहुत ही रोचक! फ़ाइल नाम को विभाजित करना ... मैंने इसके बारे में सोचा नहीं था। मुझे लगता है कि यह करने का यह शानदार तरीका है: -? - s.mihai
फ़ाइल के नाम के साथ ही हैश (जैसे एमडी 5) का उपयोग करना, साथ ही निर्देशिका वितरण, काम करेगा। न केवल फाइलों की अखंडता नामकरण योजना (आसानी से चेक की गई) के लिए एक साइड लाभ होगी, लेकिन आपके पास निर्देशिका पदानुक्रम में एक उचित वितरण भी होगा। तो अगर आपके पास "f6a5b1236dbba1647257cc4646308326.jpg" नाम की एक फ़ाइल है, तो आप इसे "/ f / 6" (या जितनी गहरी आवश्यकता हो) में स्टोर करेंगे। गहराई से 2 स्तर प्रारंभिक 1 एम फ़ाइलों के लिए 256 निर्देशिका, या प्रति निर्देशिका 4000 फाइलों के तहत देता है। एक गहरी योजना में पुनर्वितरण को स्वचालित करना भी बहुत आसान होगा।
+1 मैंने अभी देखा है कि यह उत्तर मैंने पोस्ट किए गए जैसा ही था। - 3dinfluence
मैं निश्चित रूप से फाइलसिस्टम का उपयोग करने और फ़ोल्डर नामों में "टुकड़ा" करने के लिए एक आधिकारिक पहचानकर्ता बनाने पर सहमत हूं। लेकिन आपको पहचानकर्ताओं का यादृच्छिक वितरण प्राप्त करने का भी प्रयास करना चाहिए, यानी अनुक्रम संख्या का उपयोग न करें। इससे आपको फ़ोल्डर का अधिक संतुलित पेड़ मिल जाएगा। इसके अलावा, यादृच्छिक वितरण के साथ आप कई फाइल सिस्टम में पेड़ को आसानी से विभाजित कर सकते हैं। मैं एक जेडएफएस आधारित SAN का भी उपयोग करता हूं जिसमें कटअप चालू होता है और प्रत्येक फाइल सिस्टम के लिए एक स्पैस वॉल्यूम होता है। SAN का उपयोग करने के लिए आप अभी भी iSCSI का उपयोग कर NTFS का उपयोग कर सकते हैं। - Michael Dillon
यदि आप चरण 2 में दाएं से बाएं से जाते हैं तो फ़ाइलों को समान रूप से वितरित किया जाता है। इसके अलावा आपको चिंता करने की ज़रूरत नहीं है कि आप पर्याप्त शून्य से भर नहीं रहे हैं क्योंकि आप असीमित फाइलों को प्राप्त कर सकते हैं - ropo


मैं नकारात्मक सलाह के टुकड़े पर अपने 2 सेंट लायक लगाने जा रहा हूं: डेटाबेस के साथ मत जाओ।

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

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


29
2017-12-17 17:12



हाँ। नोट लिया! - s.mihai
क्या आपने SQL 2008 के FILESTREAM डेटा प्रकार को देखा है? यह डेटाबेस और फ़ाइल सिस्टम भंडारण के बीच एक क्रॉस है। - NotMe
डेटाबेस के बजाए फ़ाइल सर्वर के साथ चिपकने पर +1 जब आप तेज़ और कम आईओ ऑपरेशंस कर रहे हैं।
क्या होगा यदि आप केवल कुछ सौ दस्तावेज़ या चित्र प्रति डेटाबेस संग्रहीत कर रहे हैं - भंडारण के लिए डेटाबेस का उपयोग करने के लिए कोई नकारात्मक? - Beep beep
+1 ... एक फाइल सिस्टम किसी भी तरह का "डेटाबेस" है (निश्चित रूप से ntfs), तो इसे अत्यधिक जटिल क्यों बनाएं। - akira


मुझे लगता है कि इस साइट से निपटने के लिए ज्यादातर साइटों को यह सुनिश्चित करने के लिए किसी प्रकार का हैश है कि फ़ाइलों को फ़ोल्डरों में समान रूप से वितरित किया जाता है।

तो कहें कि आपके पास एक फ़ाइल हैश है जो इस तरह कुछ है 515d7eab9c29349e0cde90381ee8f810
आप इसे निम्न स्थान पर संग्रहीत कर सकते हैं और आप प्रत्येक फ़ोल्डर में फ़ाइलों की संख्या को रखने के लिए कितने स्तरों की गहराई से उपयोग कर सकते हैं।
\51\5d\7e\ab\9c\29\349e0cde90381ee8f810.jpg

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


12
2017-12-17 20:17



गिट एक समान दृष्टिकोण का उपयोग करता है: git-scm.com/book/en/v2/Git-Internals-Git-Objects (इस जवाब को वापस करने के लिए) - aexl


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

मान लें कि आपके पास फ़ाइल नामों पर नियंत्रण है, मैं उन्हें प्रति निर्देशिका 1000s के स्तर पर विभाजित करता हूं। आपके द्वारा जोड़े जाने वाले अधिक निर्देशिका स्तर, आपके द्वारा जलाए जाने वाले अधिक इनोड्स, इसलिए यहां एक पुश-पुल है।

जैसे,

/ जड़ / [0-99] / [0-99] / फ़ाइल नाम

ध्यान दें, http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx एनटीएफएस सेटअप पर अधिक जानकारी है। विशेष रूप से, "यदि आप एनटीएफएस फ़ोल्डर (300,000 या उससे अधिक) में बड़ी संख्या में फाइलों का उपयोग करते हैं, तो बेहतर प्रदर्शन के लिए शोर्ट-फ़ाइल नाम पीढ़ी को अक्षम करें, और विशेष रूप से यदि लंबे फ़ाइल नामों के पहले छः वर्ण समान हैं।"

आपको उन फाइल सिस्टम सुविधाओं को अक्षम करने में भी देखना चाहिए जिनकी आपको आवश्यकता नहीं है (उदा।, अंतिम पहुंच समय)। http://www.pctools.com/guides/registry/detail/50/


11
2017-12-17 17:01



8.3 फाइलनाम पीढ़ी और अंतिम पहुंच समय अक्षम करने के लिए +1; जब मैं "बड़ी संख्या में [फाइल]" और "एनटीएफएस" (विंडोज) पढ़ता हूं तो वे पहली बात थीं। - rob
नीचे लिंक........................ - Pacerier


आप जो कुछ भी करते हैं, उन्हें सभी को एक निर्देशिका में स्टोर न करें।

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

इसलिए:

फ़ोल्डर img\a\b\c\d\e\f\g\ 'abcdefg' से शुरू होने वाली छवियां शामिल होंगी और इसी तरह।

आप अपनी खुद की उपयुक्त गहराई की आवश्यकता हो सकती है।

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


7
2017-12-17 16:58



\ a \ b \ c \ d \ e \ f \ मैं अब कर रहा हूं, मैं सोच रहा था कि ऐसा करने का एक बुद्धिमान तरीका है। - s.mihai
शारीरिक रूप से उन्हें कैसे स्टोर किया जाए, यह आमतौर पर स्वीकार्य समाधान है। स्पष्ट रूप से छवि यूआरएल उत्पन्न करना ऐसा कुछ है जिसे आसानी से छवि फ़ाइल नाम के आधार पर गतिशील रूप से किया जा सकता है। साथ ही, उन्हें सेवा देने के लिए, यदि आप लोड करना चाहते हैं, तो आप इमेज सर्वर पर img-a, img-b सबडोमेन भी पेश कर सकते हैं।
और +1 "उन्हें सभी को एक निर्देशिका में स्टोर न करें" के लिए +1। मैं एक विरासत प्रणाली का समर्थन कर रहा हूं जिसने एक फ़ोल्डर में सर्वर पर 47000 से अधिक फाइलें रखी हैं, और फ़ोल्डर को खोलने के लिए एक्सप्लोरर के लिए लगभग एक मिनट लगते हैं। - Mark Ransom
एक \ b \ c \ d \ e \ f \ g करना निर्देशिका संरचना बहुत गहरा बनाता है और प्रत्येक निर्देशिका में केवल कुछ फ़ाइलें होती हैं। प्रति निर्देशिका स्तर पर एक अक्षर का उपयोग करने के लिए बेहतर है उदा। ab \ cd \ ef \ या abc \ def \। निर्देशिकाएं डिस्क से भी स्थान लेती हैं ताकि आप उनमें से बहुत से नहीं चाहते हैं। - Juha Syrjälä
मुझे एक ऐसे एप्लिकेशन का समर्थन करना पड़ा जिसमें 4 + मिलियन फाइलें एक निर्देशिका में थीं; यह आश्चर्यजनक रूप से अच्छी तरह से काम करता था, लेकिन आप फोल्डर को खोलने के लिए कभी भी एक्सप्लोरर नहीं प्राप्त कर सकते थे, यह लगातार नए जोड़ों को सॉर्ट करेगा। एनटीएफएस के लिए +1 मरने के बिना इसे संभालने में सक्षम है। - SqlACID


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

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


5
2017-12-17 16:59



छवियों का उपयोग लगातार पहुंच के लिए नहीं किया जाता है। इसलिए इसमें कोई समस्या नहीं है। उनकी संख्या काफी तेजी से बढ़ेगी। मुझे लगता है कि 1 मिलीलीटर होगा। 1 महीने में चिह्नित करें। - s.mihai
मुझे प्रोग्रामर व्यू में दिलचस्पी है ताकि मैं इसे बहुत ज्यादा नहीं समझूंगा - s.mihai
तो अगर आपको तेजी से पहुंच की आवश्यकता नहीं है तो हैस्टैक शायद आपके लिए नहीं है। विभाजन के लिए निर्देशिकाओं का उपयोग करना मेरे विचार में सबसे आसान समाधान है। - Lukasz


हमारे पास 4 मिलियन छवियों के साथ एक फोटो स्टोर सिस्टम है। हम केवल मेटा डेटा के लिए डेटाबेस का उपयोग करते हैं और सभी छवियों को एक उलटा नामकरण प्रणाली का उपयोग कर फ़ाइल सिस्टम पर संग्रहीत किया जाता है, जहां फ़ाइल के अंतिम अंक, अंतिम -1, और इसी तरह से फ़ोल्डर नाम उत्पन्न होते हैं। उदा .: 000001234.jpg निर्देशिका संरचना में 4 \ 3 \ 2 \ 1 \ 000001234.jpg जैसे संग्रहीत है।

यह योजना डेटाबेस में पहचान सूचकांक के साथ बहुत अच्छी तरह से काम करती है, क्योंकि यह समान रूप से संपूर्ण निर्देशिका संरचना को भरती है।


5
2017-12-30 22:10





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


4
2017-12-17 17:18



: -? अच्छा त्वरित बिंदु। बस अब मेरे पास पथ उत्पन्न करने के लिए एल्गोरिदम नहीं है। - s.mihai