2012-01-05 7 views
10

यह अच्छी तरह से ज्ञात है कि विंडोज़ में बहुत से फाइलों वाली निर्देशिका में एक भयानक प्रदर्शन होगा जब आप उनमें से एक खोलने का प्रयास करेंगे। मेरे पास एक प्रोग्राम है जो केवल लिनक्स में निष्पादित करना है (वर्तमान में यह डेबियन-लेनी पर है, लेकिन मैं इस distro के बारे में विशिष्ट नहीं होना चाहता) और एक ही निर्देशिका में कई फाइलें लिखता है (जो कुछ हद तक एक भंडार के रूप में कार्य करता है)। "कई" से मेरा मतलब हर दिन दसियों का मतलब है, जिसका अर्थ है कि एक वर्ष बाद मुझे 5000-10000 फाइलों की तरह कुछ होने की उम्मीद है। उन्हें रखा जाना है (फ़ाइल बनाने के बाद, इसे कभी नहीं हटाया जाता है) और यह माना जाता है कि हार्ड डिस्क में आवश्यक क्षमता है (यदि नहीं, इसे अपग्रेड किया जाना चाहिए)। उन फ़ाइलों में आकारों की एक विस्तृत श्रृंखला है, कुछ केबी से लेकर एमबी तक (लेकिन उससे ज्यादा नहीं)। नाम हमेशा संख्यात्मक मान होते हैं, जो वृद्धिशील रूप से उत्पन्न होते हैं। मैं लंबी अवधि के प्रदर्शन में ख़राबी बारे में चिंतित हूँ, इसलिए मैं पूछना चाहता हूँ:क्या यह ठीक है (प्रदर्शन के अनुसार) एक ही लिनक्स निर्देशिका में सैकड़ों या हजारों फाइलें हैं?

  • क्या यह ठीक है एक ही निर्देशिका करने के लिए सभी लिखने के लिए? या मुझे हर एक्स फाइलों के लिए उपनिर्देशिका का एक सेट बनाने के बारे में सोचना चाहिए?
  • क्या मुझे ऐसी निर्देशिका के लिए उपयोग करने के लिए एक विशिष्ट फाइल सिस्टम की आवश्यकता होनी चाहिए?
  • अधिक मजबूत विकल्प क्या होगा? विशिष्ट फाइल सिस्टम? कौन कौन से?
  • कोई अन्य विचार/सिफारिशें?
+0

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

+0

चूंकि फाइलें हर दिन आती हैं, जैसे संरचना बनाएं 2012/1/1/35 9 8673958.png इत्यादि। यह देखना आसान होगा कि यातायात आदि के मामले में क्या चल रहा है। –

+0

संबंधित: http://stackoverflow.com/questions/5019371/storing-accessing-up-to-10-million-files-in-linux –

उत्तर

11

यह फाइल सिस्टम पर बहुत ज्यादा निर्भर करता है उपयोग करने पर विचार कर सकता है कहने के लिए उपेक्षित।

ext2 और ext3 प्रति निर्देशिका 32,000 फ़ाइलों की एक हार्ड सीमा है। यह कुछ हद तक अधिक है जो आप पूछ रहे हैं, लेकिन इतना करीब है कि मैं इसे जोखिम नहीं दूंगा। साथ ही, ext2 और ext3 निर्देशिका में नाम से फ़ाइल तक पहुंचने पर हर बार एक रैखिक स्कैन करेगा।

ext4 इन समस्याओं को ठीक से हल करता है, लेकिन मैं इसे व्यक्तिगत रूप से नहीं देख सकता।

एक्सएफएस को इस तरह की चीज के लिए शुरुआत से डिजाइन किया गया था और यदि आप निर्देशिका में लाखों फाइलें डालते हैं तो भी अच्छा काम करेगा।

तो यदि आपको वास्तव में बड़ी संख्या में फाइलों की आवश्यकता है, तो मैं एक्सएफएस या शायद ext4 का उपयोग करूंगा।

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

आपके द्वारा वर्णित आवेदन के लिए, मैं शायद इसके बजाय पदानुक्रम तैयार करूंगा, क्योंकि यह किसी को देखने के लिए शायद ही कोई अतिरिक्त कोडिंग या मानसिक प्रयास है। विशेष रूप से, आप "000001" के बजाय अपनी पहली फ़ाइल "00/00/01" नाम दे सकते हैं।

+0

एस 3 की ऐसी कोई सीमा नहीं है , क्योंकि इसमें वास्तव में कोई फ़ोल्डर्स नहीं है। आप रूट पर 10 मिलियन ऑब्जेक्ट्स को टॉस कर सकते हैं। लेकिन फिर आप एस 3 पर 'फंस गए' हैं, क्योंकि एक्सटी * में स्वरूपित पृथ्वी पर चलने वाले पृथ्वी पर बैकअप भी बहुत अच्छा काम नहीं करेगा। –

+0

I एक्सटी 4 के बारे में भी सुनाई देने से पहले कई 32,000 फाइल निर्देशिकाएं थीं। इसलिए डिफ़ॉल्ट फाइल सिस्टम इन बार जहां ext3 मुझे लगता है। क्या सीमा में कॉन्फ़िगरेशन चीज का उल्लेख किया गया है? – dronus

+0

@ ड्रोनस: मुझे यकीन है कि मुझे वह नंबर कहीं मिला है, लेकिन स्पष्ट रूप से मेरी जानकारी ext3 के लिए पुराना है (http://serverfault.com/a/187196 देखें)। व्यक्तिगत रूप से, मैं अभी भी XFS के अलावा निर्देशिका में लाखों फ़ाइलों को डालने की कोशिश नहीं करता। – Nemo

3

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

बस अपनी पसंद की फाइल सिस्टम का उपयोग करें। 100, 1000 और 10000 प्रविष्टियों के लिए कुछ यादृच्छिक परीक्षण डेटा बनाएं। फिर, उस समय को मापें जो आपके सिस्टम को समय-समय पर संबंधित कार्रवाई करने के लिए लेता है (फ़ाइल खोलना, 100 यादृच्छिक फाइलें पढ़ना आदि)।

फिर, आप समय की तुलना करें और सर्वोत्तम समाधान का उपयोग करें (उन्हें सभी को एक निर्देशिका में रखें; प्रत्येक वर्ष एक नई निर्देशिका में रखें; प्रत्येक वर्ष प्रत्येक महीने एक नई निर्देशिका में रखें)।

मुझे विस्तार से पता नहीं है कि आप क्या उपयोग कर रहे हैं, लेकिन एक निर्देशिका बनाना एक बार (और शायद काफी आसान) ऑपरेशन है, तो फाइल सिस्टम को बदलने या कुछ और समय लेने वाली चीजों को बदलने की बजाय ऐसा क्यों नहीं करते?

0
  • क्या सभी एक ही निर्देशिका में लिखना ठीक है? या मुझे हर एक्स फाइलों के लिए उपनिर्देशिका का एक सेट बनाने के बारे में सोचना चाहिए?

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

  • मैं ऐसे निर्देशिका के लिए प्रयोग की जाने वाली एक विशेष फाइल सिस्टम की आवश्यकता है?

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

  • क्या और अधिक मजबूत विकल्प हो सकता है? विशिष्ट फाइल सिस्टम? कौन कौन से?

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

  • कोई अन्य विचार/सिफारिशें?

ऊपर देखें। इसके अलावा एक निर्देशिका में 5000 से 10000 फाइलें होने की समस्या नहीं होनी चाहिए। अभ्यास में यह "एलएस" और "आरएम" जैसी उपयोगिताओं को छोड़कर, जहां तक ​​मुझे पता है, फाइल सिस्टम को मनमाने ढंग से धीमा नहीं करता है। लेकिन तुम कर सकते हो:

find * | xargs echo 
find * | xargs rm 

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

मैं आपको कुछ "स्पार्स फ़ाइलों" कहा जाता है http://en.wikipedia.org/wiki/Sparse_file

+2

एक्सएफएस का उपयोग करने के सुझाव के अलावा, यह ज्यादातर गलत है। प्रत्येक बार जब आप एक सामान्य लिनक्स फ़ाइल सिस्टम पर फ़ाइल खोलने का प्रयास करते हैं, तो सिस्टम उस फ़ाइल को नाम से ढूंढने के लिए शुरुआत से पूरी निर्देशिका सूची स्कैन करेगा। तो, उदाहरण के लिए, निर्देशिका में प्रत्येक फ़ाइल "स्टेट" करने के लिए एक ओ (एन^2) ऑपरेशन है। हजारों फाइलों पर बहुत ध्यान देने योग्य। – Nemo

+2

निर्देशिका वितरण को कुछ वितरणों में डिफ़ॉल्ट रूप से ext3 में सक्षम किया गया है (Centos5, निश्चित रूप से)। निर्देशिका अनुक्रमण विकल्प (dir_index) का निरीक्षण और परिवर्तन करने के लिए tune2fs का उपयोग करें। – MarkR

+1

"एक्सएफएस का उपयोग करने के सुझाव के अलावा, यह ज्यादातर गलत है।" क्या गलत है विस्तार से नहीं है। सिर्फ यह कहकर "यह गलत है" बिल्कुल सहायक नहीं है। मेरे व्यावहारिक अनुभव में धीमी गति से या यहां तक ​​कि "एलएस" और "आरएम की अच्छी तरह से काम करने की अक्षमता या फाइलों के कई 1000s के साथ भी किसी भी संभावित मंदी की तुलना में अधिक ध्यान देने योग्य है। जिसे भी ट्यून किया जा सकता है। – aseq

0

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

+0

कुछ वितरण (Centos5, निश्चित रूप से) में डिफ़ॉल्ट रूप से ext3 में निर्देशिका अनुक्रमण सक्षम है। निर्देशिका अनुक्रमण विकल्प (dir_index) का निरीक्षण और परिवर्तन करने के लिए tune2fs का उपयोग करें। – MarkR

5

यदि आप निर्देशिका-अनुक्रमण के बिना फाइल सिस्टम का उपयोग करते हैं, तो यह एक बहुत ही बुरा विचार है कि एक निर्देशिका में बहुत सारी फाइलें हों (कहें,> 5000)।

हालांकि, यदि आपके पास निर्देशिका अनुक्रमणिका है (जिसे डिफ़ॉल्ट रूप से ext3 में हाल ही में डिस्ट्रोज़ पर डिफ़ॉल्ट रूप से सक्षम किया गया है), तो यह ऐसी समस्या नहीं है।

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

लेकिन इसे अधिक न करें। नेस्टेड उपनिर्देशिका के कई स्तरों को अनावश्यक रूप से उपयोग न करें, यह बहुत सारे इनोड्स का उपयोग करता है और मेटाडाटा संचालन धीमा कर देता है।

मैंने "प्रति निर्देशिका बहुत अधिक फाइलों" के मुकाबले "नेस्टेड निर्देशिकाओं के बहुत से स्तर" के अधिक मामलों को देखा है।

1

अन्य उत्तर के अलावा, अगर विशाल निर्देशिका एक ज्ञात आवेदन या पुस्तकालय द्वारा किया जाता है, तो आप कुछ और के द्वारा जगह पर विचार कर सकते उदाहरण के लिए:

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

ऊपर दृष्टिकोण के लाभ में शामिल हैं: छोटे आइटम (एक किलोबाइट प्रत्येक से कम) का एक बड़ा संग्रह के लिए

  1. अंतरिक्ष प्रदर्शन। एक फाइल सिस्टम को प्रत्येक आइटम के लिए एक इनोड की आवश्यकता होती है। इंडेक्स्ड प्रणालियों के विवरण का स्तर बहुत कम
  2. समय प्रदर्शन हो सकता है: अनुक्रमित दृष्टिकोण बड़ी जरूरतों को फिट करने के लिए तैयार कर रहे हैं: आप हर आइटम
  3. scalability के लिए फाइल सिस्टम का उपयोग नहीं करते या तो एक GDBM इंडेक्स फ़ाइल, या एक डेटाबेस कई लाखों संभाल कर सकते हैं वस्तुओं का मुझे यकीन नहीं है कि आपकी निर्देशिका दृष्टिकोण आसानी से स्केल करेगा।

इस तरह के दृष्टिकोण का नुकसान यह है कि वे फाइलों के रूप में नहीं दिखते हैं। लेकिन MarkR's answer आपको याद दिलाता है, ls विशाल निर्देशिकाओं पर काफी खराब व्यवहार कर रहा है।

आप एक फाइल सिस्टम दृष्टिकोण पर कायम हैं, तो कई सॉफ्टवेयर फ़ाइलों की बड़ी संख्या का उपयोग कर aa/ab/ac/ तरह उपनिर्देशिका में उन्हें आयोजन कर रहे हैं ... ay/az/ba/ ... bz/ ...

+0

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

+0

किसी भी डेटाबेस को समय-समय पर बैक अप लेना चाहिए (उदा। 'Mysqldump' के साथ)। मैं अच्छी तरह से प्रशासित और अच्छी तरह से डिजाइन किए गए MySQL डेटाबेस के लिए डरावनी कहानियों से परिचित नहीं हूं। और जीडीबीएम MySQL से सरल है। लेकिन बैकअप बनाना हमेशा आवश्यक है (हार्डवेयर डिस्क विफल हो रही हैं!)। –

+1

बेशक, आपको डेटा को बैकअप लेना चाहिए, न केवल उस फ़ाइल में। MySQL के लिए, 'mysqldump' का उपयोग कर; जीडीबीएम के लिए, अपना बैकअप दिनचर्या लिखें या 'gdbmexport' का उपयोग करें –

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