फाइलसिस्टम में एक लाख इमेज स्टोर करना

Question

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

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

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

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

a / b / c / 0 ... z / z / z / 999

या

a / b / c / 000 ... z / z / z / 999

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

Comments

क्या वे विशिष्ट उपयोगकर्ताओं या सिर्फ सामान्य से बंधे हैं? क्या वे किसी भी फैशन में समूहीकृत हैं?

केवल सामान्य। कुछ तकनीकी उपकरणों द्वारा उत्पन्न छवियों का एक गुच्छा। मैं उन्हें 1 से वृद्धिशील नाम दे रहा हूं बस एक समय का विचार है।

— s.mihai

वे कैसे उपयोग / उपयोग किए जा रहे हैं? एक bespoke एप्लिकेशन के माध्यम से या क्या?

— कबूतर

क्या यह आप हो? i46.tinypic.com/1z55k7q.jpg

:)) हाँ ... 1 मील। अश्लील चित्र :))

— s.mihai

Answer 1

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

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

 File path = generatePathFromSequenceNumber(sequenceNumber);

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

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

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) बड़ी संख्या में फाइलें हैं
• निर्देशिका संरचना स्वयं कुछ डिस्क स्थान लेगी, इसलिए आप बहुत सारी निर्देशिका नहीं चाहेंगे।
• उपरोक्त संरचना के साथ, आप हमेशा फ़ाइल नाम को देखकर छवि फ़ाइल के लिए सही रास्ता पा सकते हैं, यदि आप अपनी निर्देशिका संरचनाओं को गड़बड़ाने के लिए होते हैं।
• यदि आपको कई मशीनों से फ़ाइलों तक पहुंचने की आवश्यकता है, तो नेटवर्क फ़ाइल सिस्टम के माध्यम से फ़ाइलों को साझा करने पर विचार करें।
• यदि आप बहुत सारी फ़ाइलों को हटाते हैं तो उपरोक्त निर्देशिका संरचना काम नहीं करेगी। यह निर्देशिका संरचना में "छेद" छोड़ता है। लेकिन चूंकि आप किसी भी फाइल को डिलीट नहीं कर रहे हैं, यह ठीक होना चाहिए।

Comments

बहुत ही रोचक! फ़ाइल नाम को विभाजित करना ... मैंने ऐसा नहीं सोचा था। मुझे लगता है कि यह इसे करने का सुरुचिपूर्ण तरीका है: -?

— शमीहाई

फ़ाइल के नाम, साथ ही निर्देशिका वितरण के रूप में हैश (जैसे एमडी 5) का उपयोग करना काम करेगा। न केवल फाइलों की अखंडता नामकरण योजना (आसानी से जाँच की गई) के लिए एक साइड बेनिफिट होगी, बल्कि आपके पास निर्देशिका पदानुक्रम में एक समान रूप से वितरण भी होगा। इसलिए यदि आपके पास "f6a5b1236dbba1647257cc4646308326.jpg" नाम की फ़ाइल है, तो आप इसे "/ f / 6" (या जितनी आवश्यकता हो उतना गहरा) में संग्रहीत करेंगे। 2 स्तर गहरा 256 निर्देशिका देता है, या प्रारंभिक 1m फ़ाइलों के लिए प्रति निर्देशिका केवल 4000 फ़ाइलों के तहत। पुनर्वितरण को एक गहरी योजना में स्वचालित करना भी बहुत आसान होगा।

+1 मैंने अभी देखा कि यह उत्तर मेरे द्वारा पोस्ट किए गए समान था।

— डी

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

— माइकल डिलन

यदि आप चरण 2 में दाएं से बाएं जाते हैं तो फाइलें समान रूप से वितरित की जाती हैं। इसके अलावा, आपको यह चिंता करने की ज़रूरत नहीं है कि आप पर्याप्त शून्य से नहीं भर रहे हैं क्योंकि आप असीमित संख्या में फाइल कर सकते हैं

— रोपो

Answer 2

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

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

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

Comments

हाँ। ध्यान दिया!

— शमीहाइ

क्या आपने SQL 2008 के FILESTREAM डेटा प्रकार को देखा है? यह डेटाबेस और फाइल सिस्टम स्टोरेज के बीच एक अंतर है।

— NotMe

एक डेटाबेस के बजाय फ़ाइल सर्वर के साथ चिपके रहने पर +1 जैसा कि आप तेजी से और असीम आईओ संचालन कर रहे हैं।

क्या होगा यदि आप प्रति डेटाबेस में केवल कुछ सौ डॉक्स या पिक्स स्टोर कर रहे हैं - स्टोरेज के लिए डेटाबेस का उपयोग करने के लिए कोई नकारात्मक पहलू?

— बीप बीप

+1 ... एक फाइल सिस्टम वैसे भी "डेटाबेस" की तरह है (सुनिश्चित करने के लिए ntfs), इसलिए इसे अत्यधिक जटिल क्यों बनाया जाए।

— अकीरा

Answer 3

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

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

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

Comments

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

— aexl

Answer 4

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

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

उदाहरण के लिए,

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

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

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

Comments

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

— डकैती

लिंक नीचे ……………………

— Pacerier

Answer 5

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

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

इसलिए:

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

आप अपनी आवश्यक गहराई का परिचय दे सकते हैं।

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

Comments

\ a \ b \ c \ d \ e \ f \ i अब कर रहा हूं, मैं सोच रहा था कि ऐसा करने का एक बुद्धिमान तरीका है।

— s.mihai

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

और +1 के लिए "उन सभी को एक निर्देशिका में संग्रहीत न करें"। मैं एक विरासत प्रणाली का समर्थन कर रहा हूं जिसने एक एकल फ़ोल्डर में 47000 से अधिक फ़ाइलों को सर्वर पर रखा है, और यह केवल फ़ोल्डर खोलने के लिए एक्सप्लोरर के लिए लगभग एक मिनट लगता है।

— मार्क रैनसम

\ B \ c \ d \ e \ f \ g करने से निर्देशिका संरचना बहुत गहरी हो जाती है और प्रत्येक निर्देशिका में केवल कुछ फ़ाइलें होती हैं। प्रति निर्देशिका स्तर पर एक अक्षर का उपयोग करने के लिए बेहतर है जैसे ab \ cd \ ef \ या abc \ def \। निर्देशिकाएँ डिस्क से भी स्थान लेती हैं, इसलिए आप उनमें से बहुत अधिक नहीं चाहते हैं।

— जूहा सिरजला

मुझे एक ऐसे एप्लिकेशन का समर्थन करना था जिसमें एक निर्देशिका में 4 + मिलियन फाइलें थीं; यह आश्चर्यजनक रूप से अच्छी तरह से काम किया, लेकिन आप फ़ोल्डर खोलने के लिए कभी भी खोजकर्ता नहीं ला सके, यह लगातार नए परिवर्धन को छांटता रहेगा। NTFS के लिए +1 मरने के बिना इसे संभालने में सक्षम है।

— SqlACID

Answer 6

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

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

Comments

छवियां लगातार पहुंच के लिए नहीं होती हैं। इसलिए इससे कोई समस्या नहीं है। उनकी संख्या काफी तेजी से बढ़ेगी। मुझे लगता है कि वहाँ 1mil हो जाएगा। 1 महीने में निशान।

— s.mihai

मुझे प्रोग्रामर के दृश्य में दिलचस्पी है ताकि मैं इसे बहुत ज्यादा न

— खाऊँ

इसलिए यदि आपको तेज पहुंच की आवश्यकता नहीं है तो हैस्टैक आपके लिए संभवत: नहीं है। विभाजन के लिए निर्देशिकाएँ का उपयोग करना मेरे विचार में सबसे सरल उपाय है।

— लुकाज़

Answer 7

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

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

Answer 8

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

Comments

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

— शमीहाइ

Answer 9

नए MS SQL 2008 में ऐसे मामलों को संभालने के लिए एक नई सुविधा है, इसे FILESTREAM कहा जाता है। जरा देखो तो:

Microsoft TechNet FILESTREAM अवलोकन

Answer 10

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

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

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

imgs\yyyy\mm\filename.ext

where: yyyy = 4 digit year
         mm = 2 digit month

example:  D:\imgs\2009\12\aaa0001.jpg
          D:\imgs\2009\12\aaa0002.jpg
          D:\imgs\2009\12\aaa0003.jpg
          D:\imgs\2009\12\aaa0004.jpg
                   |
          D:\imgs\2009\12\zzz9982.jpg
          D:\imgs\2010\01\aaa0001.jpg (this is why I ask about uniqueness)
          D:\imgs\2010\01\aab0001.jpg

सुरक्षा प्रकार की छवियों के लिए महीना, वर्ष, यहां तक ​​कि दिन भी अच्छा है। यकीन नहीं होता कि यह वही है जो आप कर रहे हैं, लेकिन मैंने ऐसा किया कि हर 10 सेकेंड में एक तस्वीर खिंचवाने वाले एक होम सिक्योरिटी कैमरे के साथ ... इस तरह से आपका एप्लिकेशन विशिष्ट समय या यहां तक ​​कि एक सीमा तक नीचे जा सकता है जहां आपको लगता है कि छवि उत्पन्न हुई थी । या, वर्ष, महीने के बजाय - क्या कुछ अन्य "अर्थ" है जो छवि फ़ाइल से ही प्राप्त किया जा सकता है? मेरे द्वारा दी गई तारीख के उदाहरण के अलावा कुछ अन्य विवरण?

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

जब मैं उत्तर दे रहा था तब आपने / अन्य लोगों ने इन विचारों को संबोधित किया होगा। आशा है कि इससे मदद मिलेगी।

Comments

1. सभी फाइलों को विशिष्ट रूप से नामित किया जाएगा। सिस्टम पहले से बढ़ेगा और बढ़ेगा यह पहली बार बाहर निकलेगा 1mil चित्र और फिर प्रति माह हजारों जोड़े की दर से बढ़ेगा। 3. यह भविष्य में किसी बिंदु पर फ़ाइलों के टैगिंग के कुछ प्रकार होंगे, इसलिए मैं db में कुछ प्रकार के पहचान डेटा को संग्रहीत करना चाहता हूं।

— शमीहाइ

Answer 11

मैं एक ऐसी परियोजना में शामिल हूं जो विभिन्न उपकरणों की स्थिति के दस्तावेजीकरण के लिए एक वर्ष के दौरान 8.4 मिलियन छवियों को संग्रहीत करती है। अधिक हाल की छवियों को अधिक बार एक्सेस किया जाता है, और पुरानी छवियों को शायद ही कभी मांगा जाता है जब तक कि एक शर्त की खोज नहीं की गई थी जिसने किसी को अभिलेखागार में खुदाई करने के लिए प्रेरित किया।

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

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

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

मैं समझता हूं कि यह संभवतः आपके विशेष विवरण से संबंधित नहीं है, लेकिन मुझे लगा कि मैं साझा करूंगा।

Answer 12

शायद एक निर्माण तिथि आधारित नामकरण योजना - या तो फ़ाइल नाम में सभी जानकारी या बाद में ब्राउज़ करने के लिए बेहतर है, इसे निर्देशिका में विभाजित करना। मैं निम्नलिखित के बारे में सोच सकता हूं कि आप कितनी बार छवियों को उत्पन्न करते हैं:

• प्रत्येक दिन कई चित्र उत्पन्न होते हैं: Year/Month/Day/Hour_Minute_Second.png
• एक महीना: Year/Month/Day_Hour_Minute_Second.png

आदि तुम मेरी बात ... =)

Comments

वे समय के साथ लगातार उत्पन्न नहीं होते हैं, इसलिए कुछ फ़ोल्डर्स मोटे हो जाएंगे और अन्य ... स्लिम :))

— s.mihai

ठीक है, आपको स्पष्ट रूप से प्रत्येक फ़ोल्डर बनाने की ज़रूरत नहीं है , सिर्फ इसलिए कि आप इस योजना का पालन कर रहे हैं। आपके पास यह भी हो सकता है Year/Month/Day/Hour/Minute- यह तय करें कि आपको कितने स्तर के फ़ोल्डर्स की आवश्यकता है, यह इस बात पर निर्भर करता है कि जब दर सबसे अधिक होती है तो कितनी बार छवियां उत्पन्न होती हैं - और फिर केवल वे फ़ोल्डर नहीं बनाते हैं जिन्हें खाली छोड़ दिया जाएगा।

— टॉमस एशचन

Answer 13

मुझे दिनांक आधारित फ़ोल्डर संरचना बनाने की इच्छा होगी, जैसे \ year \ month \ _ दिन, और फ़ाइल नाम के लिए टाइमस्टैम्प का उपयोग करना। यदि आवश्यक हो, तो टाइमस्टैम्प में एक अतिरिक्त काउंटर घटक हो सकता है यदि छवियां इतनी तेज़ी से बनाई जाएं कि एक मिलीसेकंड के भीतर एक से अधिक हो सकते हैं। नामकरण छँटाई के लिए सबसे महत्वपूर्ण से कम महत्वपूर्ण अनुक्रम का उपयोग करके, खोजने और रखरखाव एक हवा है। उदा। hmsmssmm [seq] .jpg

Answer 14

क्या आप आपदा वसूली पर विचार कर रहे हैं?

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

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

विचार करें कि मशीनों या फ़ाइल सिस्टम के बीच फ़ाइलों को स्थानांतरित करने के लिए आपको किस प्रकार की प्रक्रियाओं की आवश्यकता होगी। आपके सिस्टम के साथ ऐसा करने की क्षमता लाइव है और ऑनलाइन आपको सड़क के नीचे काफी सिरदर्द से बचा सकती है।

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

यदि उचित हो, तो अमेज़ॅन एस 3 जैसे सीडीएन का उपयोग करने पर विचार करें।

Answer 15

जबकि मैंने उस पैमाने पर चित्र नहीं बनाए हैं, मैंने पहले एक 400MHz मशीन w पर ~ 25k चित्रों को परोसने के लिए एक छोटी गैलरी ऐप लिखी है। 512 एमबी रैम या तो। कुछ अनुभव;

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

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

• समान रूप से डेटा वितरित करें; जब मैंने ऊपर प्रयोग किया, तो मैंने सभी निर्देशिकाओं पर समान रूप से डेटा वितरित करने का प्रयास किया (मैंने URL का एमडी 5 किया और निर्देशिकाओं के लिए इसका इस्तेमाल किया; /1a/2b/1a2b...f.jpg)। इस तरह से जो भी प्रदर्शन सीमा होती है उसे हिट करने में अधिक समय लगता है (और इतने बड़े डेटासेट पर फ़ाइल सिस्टम कैश शून्य है)। (इसके विपरीत, आप यह देखना चाहते हैं कि सीमाएँ कहाँ पर आरंभिक हैं? तो आप पहले उपलब्ध निर्देशिका में सब कुछ फेंकना चाहते हैं।

Answer 16

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

String fileName = "cat.gif";
int hash = fileName.hashCode();
int mask = 255;
int firstDir = hash & mask;
int secondDir = (hash >> 8) & mask;

यह मार्ग होने के परिणामस्वरूप होगा:

/172/029/cat.gif

आप cat.gifएल्गोरिथ्म को पुन: पेश करके निर्देशिका संरचना में पा सकते हैं ।

निर्देशिका नामों के रूप में HEX का उपयोग करना intमूल्यों को परिवर्तित करने के रूप में आसान होगा :

String path = new StringBuilder(File.separator)
        .append(String.format("%02x", firstDir))
        .append(File.separator)
        .append(String.format("%02x", secondDir)
        .toString();

जिसके परिणामस्वरूप:

/AC/1D/cat.gif

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

Comments

हम कुछ इसी तरह का उपयोग करके 1.8 बिलियन आइटम स्टोर करते हैं। यह अच्छा काम करता है। एक हैश का उपयोग करें जो तेज है और कम टकराव की दर है और आप सेट हैं।

— CVVS

Answer 17

यदि आप विंडोज़ पर हैं तो एक्सफ़ैट फिल्टेसिटम पर कैसे

http://msdn.microsoft.com/en-us/library/aa914353.aspx

इसे मीडिया फ़ाइलों को ध्यान में रखते हुए डिज़ाइन किया गया था, और अब उपलब्ध है।

Answer 18

यदि वे सभी तुरंत आवश्यक नहीं हैं और आप उन्हें ऑन-द-फ्लाई उत्पन्न कर सकते हैं और ये छोटी छवियां हैं, तो अपनी छवि जनरेटर के ऊपर LRU मेमोरी- या डिस्क-कैश क्यों लागू नहीं करें?

यह आपको स्टोरेज से बचा सकता है और गर्म छवियों को मेम से परोसा जा सकता है?

Answer 19

मैं सिर्फ zfs पर एक परीक्षण चलाता हूं क्योंकि मैं zfs से प्यार करता हूं, और मेरे पास 500gig विभाजन था जिस पर मुझे संपीड़न था। मैंने एक स्क्रिप्ट लिखी, जिसमें 50-100k फाइलें तैयार कीं और उन्हें नेस्टेड डायरेक्ट्रीज़ 1/2/3/4/5/6/7/8 (5-8 लेवल डीप) में रखा और इसे 1 हफ्ते तक सोचने दिया। (यह एक महान स्क्रिप्ट नहीं थी।) इसने डिस्क को भर दिया और लगभग 25 मिलियन फाइलें या तो समाप्त हो गईं। ज्ञात पथ के साथ किसी भी एक फ़ाइल तक पहुंच तत्काल थी। किसी भी निर्देशिका को किसी ज्ञात पथ से सूचीबद्ध करना तत्काल था।

हालाँकि फाइलों की सूची की गिनती प्राप्त करना (खोज के माध्यम से) में 68 घंटे लगे।

मैंने एक निर्देशिका में बहुत सारी फाइलें डालते हुए एक परीक्षण भी चलाया। मेरे रुकने से पहले मैंने एक निर्देशिका में लगभग 3.7 मिलियन फाइलें जमा कीं। गिनती प्राप्त करने के लिए निर्देशिका को सूचीबद्ध करने में लगभग 5 मिनट का समय लगा। उस निर्देशिका की सभी फ़ाइलों को हटाने में 20 घंटे लगे। लेकिन किसी भी फ़ाइल को देखना और पहुँच तुरंत थी।

Answer 20

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

आप निम्नलिखित विनिर्देशन में दिलचस्पी ले सकते हैं, अधिकांश डिजिटल कैमरे फ़ाइल भंडारण का प्रबंधन करने के लिए इसका अनुसरण करते हैं: https://en.wikipedia.org/wiki/Camera_Image_File_Format

अनिवार्य रूप से, एक फ़ोल्डर बनाया जाता है, जैसे कि 000OLYMPUSऔर फोटो उस फ़ोल्डर में जोड़े जाते हैं (उदाहरण के लिए DSC0000.RAW)। जब फ़ाइल नाम काउंटर पहुंचता है तो DSC9999.RAWएक नया फ़ोल्डर बनाया जाता है ( 001OLYMPUS) और छवि को फिर से जोड़ा जाता है, काउंटर को रीसेट करना, संभवतः एक अलग उपसर्ग (पूर्व:) के साथ P_0000.RAW।

वैकल्पिक रूप से आप फ़ाइल नाम के कुछ हिस्सों (पहले से ही कई बार उल्लिखित) के आधार पर भी फ़ोल्डर बना सकते हैं। उदाहरण के लिए, यदि आप फोटो का नाम रखते हैं IMG_A83743.JPG, तो इसे स्टोर करें IMG_\A8\3\IMG_A83743.JPG। इसे लागू करना अधिक जटिल है लेकिन आपकी फ़ाइलों को ढूंढना आसान बना देगा।

फाइलसिस्टम के आधार पर (इसमें कुछ शोध की आवश्यकता होगी), आप एक ही फ़ोल्डर में सभी छवियों को डंप करने में सक्षम हो सकते हैं, लेकिन, मेरे अनुभव में, यह आमतौर पर प्रदर्शन समस्याओं का कारण होगा।

Answer 21

आप ZFS (फाइल सिस्टम, सन से वॉल्यूम मैनेजर) सादर देखना चाहेंगे

Answer 22

एक बड़ी संख्या से पथ उत्पन्न करने का एक साफ तरीका यह है कि इसे आसानी से हेक्स में बदल दें और फिर इसे विभाजित करें!

उदाहरण के लिए 1099496034834> 0xFFFF1212>FF/FF/12/12

public string GeneratePath(long val)
{  
    string hex = val.ToString("X");
    hex=hex.PadLeft(10, '0');
    string path="";
    for(int i=0; i<hex.Length; i+=2 )
    {
        path += hex.Substring(i,2);
        if(i+2<hex.Length)
            path+="/";
    }
    return path;
}

स्टोर और लोड:

public long Store(Stream doc)
{
   var newId = getNewId();
   var fullpath = GeneratePath(newId)
   // store into fullpath 
   return newId;
}

public Stream Load(long id)
{
   var fullpath = GeneratePath(newId)
   var stream = ... 
   return stream;
}

पूर्ण स्रोत कोड: https://github.com/acrobit/AcroFS

Answer 23

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

डेटाबेस प्रबंधक का उपयोग करना अब तक का सबसे अच्छा विकल्प है; उदाहरण के लिए BDB या GDBM जैसा एक सरल; यहां तक ​​कि MySQL की तरह एक संबंधित DBMS बेहतर होगा। केवल आलसी लोग जो फाइलसिस्टम और डेटाबेस को नहीं समझते हैं (उदाहरण के लिए जो लेनदेन को खारिज करते हैं) डेटाबेस के रूप में फाइलसिस्टम का उपयोग करते हैं (या कुछ और शायद ही कभी, इसके विपरीत)।

Answer 24

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

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

Comments

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

— शैतानिक्यूपी

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

— मार्क रैनसम

हे भगवान नहीं, कृपया एक डेटाबेस का उपयोग बड़े BLOB संग्रहण के रूप में न करें।

— नील एन

EEK। पता नहीं था कि डेटाबेस (अभी भी?) BLOBs के साथ बहुत सारी समस्याएं हैं।

ऐसा बुरा समाधान कैसे हो सकता है जिसमें अभी भी बहुत सारी टिप्पणियां +1 हैं? ओपी के लिए कोई अपराध नहीं है (मुझे लगता है कि यह एसओ से आया था) लेकिन डाउनवोट बटन यहाँ एक कारण के लिए है!

— मार्क हेंडरसन