Bir dizine kaç dosya koyabilirim?


561

Tek bir dizinde kaç dosya sakladığım önemli mi? Öyleyse, bir dizindeki kaç dosya çok fazladır ve çok fazla dosyaya sahip olmanın etkileri nelerdir? (Bu bir Linux sunucusundadır.)

Arka plan: Bir fotoğraf albümü web sitem var ve yüklenen her resim 8 haneli onaltılık kimliğe göre yeniden adlandırıldı (örneğin, a58f375c.jpg). Bu, dosya adı çakışmalarını önlemek içindir (örneğin, bir çok "IMG0001.JPG" dosyası yüklenirse). Orijinal dosya adı ve yararlı meta veriler bir veritabanında saklanır. Şu anda, resimler dizininde yaklaşık 1500 dosyam var. Bu, dizindeki dosyaların listelenmesinin (FTP veya SSH istemcisi aracılığıyla) birkaç saniye sürmesini sağlar. Ama bunun dışında bir etkisi olduğunu göremiyorum. Özellikle, bir görüntü dosyasının kullanıcıya ne kadar hızlı sunulduğu üzerinde herhangi bir etkisi görülmemektedir.

16 alt dizin oluşturarak görüntü sayısını azaltmayı düşündüm: 0-9 ve af. Sonra, dosya adının ilk onaltılık basamağının ne olduğuna bağlı olarak görüntüleri alt dizinlere taşırdım. Ancak dizinin FTP / SSH üzerinden ara sıra listelenmesi dışında bunu yapmak için herhangi bir neden olduğundan emin değilim.

Yanıtlar:


736

FAT32 :

  • Maksimum dosya sayısı: 268.173.300
  • Dizin başına Maksimum dosya sayısı: 2 16  - 1 adet (65.535)
  • Maksimum dosya boyutu: 2 GiB - 1 LFS olmadan , 4 GiB - 1 ile

NTFS :

  • Maksimum dosya sayısı: 2 32  - 1 adet (4294967295)
  • Maksimum dosya boyutu
    • Uygulama: 2 44  - 2 6 bayt (16 TiB - 64 KiB)
    • Teorik: 2 64  - 2 6 bayt (16 EIB-- 64 KiB)
  • Maksimum hacim boyutu
    • Uygulama: 2 32  - 1 Küme (256 TiB - 64 KiB)
    • Teorik: 2 64  - 1 kümeleri (1 YIB - 64 KiB)

ext2 :

  • Maksimum dosya sayısı: 10 18
  • Dizin başına maksimum dosya sayısı: ~ 1,3 × 10 20 (10.000'in üzerindeki performans sorunları)
  • Maksimum dosya boyutu
    • 16 GiB (1 KiB blok boyutu)
    • 256 GiB (blok boyutu 2 KiB)
    • 2 TiB (blok boyutu 4 KiB)
    • 2 TiB (blok boyutu 8 KiB)
  • Maksimum hacim boyutu
    • 4 TiB (blok boyutu 1 KiB)
    • 8 TiB (blok boyutu 2 KiB)
    • 16 TiB (blok boyutu 4 KiB)
    • 32 TiB (blok boyutu 8 KiB)

ext3 :

  • Maksimum dosya sayısı: dk (volumeSize / 2 13 , numberOfBlocks)
  • Maksimum dosya boyutu: ext2 ile aynı
  • Maksimum hacim boyutu: ext2 ile aynı

ext4 :

  • Maksimum dosya sayısı: 2 32  - 1 adet (4294967295)
  • Dizin başına maksimum dosya sayısı: sınırsız
  • Maksimum dosya boyutu: 2 44  - 1 baytlık (16 TiB - 1)
  • Maksimum hacim boyutu: 2 48  - 1 baytlık (256 TiB - 1)

24
Bunların bir bölüm değil, tüm bölüm için maksimum dosya sayısı olduğunu varsayıyorum. Bu nedenle, bu bilgi sorunla ilgili olarak çok yararlı değildir, çünkü yönteme bakılmaksızın eşit sayıda dosya olacaktır (dizinleri dosya olarak saymazsanız).
strager

19
Şimdi 2012'de olduğumuzdan, ext4'ün alt dizin sayısı ile ilgili herhangi bir sınırının olmadığını açıkça belirleme zamanının geldiğini düşünüyorum. Ayrıca maksimum dosya boyutu 16 TB'a çıktı. Ayrıca, dosya sisteminin toplam boyutu 1 EB = 1.048.576 TB'ye kadar olabilir.
devsnd

7
Görünüşe göre, ext3 dizin başına 60.000 dosya (veya dizin veya bağlantı) sınırına sahiptir. Bu konuda zor yolu öğrendim.
yığın

8
Eski cevap, biliyorum… ama EXT4 yazdığınızda - Maksimum dosya sayısı: 2³² - 1 (4,294,967,295) ve Dizin başına maksimum dosya sayısı: sınırsız Beni gerçekten karıştırdınız çünkü 2³² - 1! = “Sınırsız”. Sanırım şimdi bir kahveye ihtiyacım var. ;) Yine de +1
e-sushi

11
Sert dosya sistemi sınırları "cevap vermene gerek yok ben tek bir dizinde tutmak kaç dosya fark eder mi? "
Etki

191

Tek bir ext3 dizininde 8 milyondan fazla dosyam var. C kütüphanesi readdir()tarafından kullanılan find, lsdiğer yöntemlerin çoğu listesi büyük dizinleri bu iplik tartışılmıştır.

Bunun nedeni lsve findyavaş olması, readdir()bir seferde yalnızca 32K dizin girdisini okumasıdır, bu nedenle yavaş disklerde bir dizini listelemek için birçok okuma gerekir. Bu hız sorununun bir çözümü var. Bu konuda oldukça ayrıntılı bir makale yazdım: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

Anahtar take uzaklıktadır: Kullanım getdents()doğrudan - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html ziyade şey daha libc'nizdeki dayanıyor readdir()Eğer tampon belirtebilirsiniz böylece diskten dizin girişlerini okurken boyut.


6
İlginç bir okuma! Hangi durumda bir dizinde 8 milyon dosyanız olduğunu sorabilir miyim? haha
Aᴄʜᴇʀᴏɴғᴀɪʟ

Ben de aynıydım. Bir tablonun blob sütununu taşıdım, her blob sütunu dosya olarak dışa aktardım. Yaklaşık 8 milyon dosya :)
Spike

65

İçinde 88.914 dosya içeren bir dizin var. Kendiniz gibi, bu da küçük resimleri ve bir Linux sunucusunda saklamak için kullanılır.

FTP veya php işlevi aracılığıyla listelenen dosyalar yavaş evet, ancak dosyayı görüntülerken bir performans isabeti de var. örneğin, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg 200-400 ms'lik bir bekleme süresine sahiptir. Başka bir sitede karşılaştırma olarak bir dizinde yaklaşık 100 dosya ile görüntü sadece ~ 40ms bekledikten sonra görüntülenir.

Çoğu kişi dizin arama işlevlerinin nasıl çalışacağını yazdıkları için bu cevabı verdim, bir başparmak klasöründe kullanmayacaksınız - sadece statik olarak dosyaları görüntülüyor, ancak dosyaların gerçekte nasıl kullanılabileceğinin performansı ile ilgilenecek .


6
Tek faydalı cevap bu. Benzer deneyimler yaşadık. Sınırımız, yedekleme ile ilgili sorunları azaltmak için 1.000 dosyadır (çok fazla dizin yavaşlar).
mgutt

1

2
Çok yavaşladığı yerde hangi dosya sistemini kullanıyorsunuz? Örneğin XFS, bir dizinde gözle görülür bir yavaşlama olmadan 100.000 dosyayı kolayca işleyebilmelidir.
Ethan

1
Diğerlerinin görüşünün aksine, bu cevabı onaylamak istiyorum. Sosyal ağ web sitemizde yüz binlerce resim var. Performansı artırmak için 100 (veya bazı dosyalar için 1000) alt dizine sahip olmaya ve dosyaları onlara dağıtmaya zorlandık (linux + Apache bizim için ext3).
wmac

57

Biraz Linux sunucusunda kullanılan belirli dosya sistemine bağlıdır. Günümüzde varsayılan dir3dizin ile ext3'tür, bu da büyük dizinleri aramayı çok hızlı yapar.

Dolayısıyla, hız, daha önce not ettiğiniz sorun dışında bir sorun olmamalı, yani listeler daha uzun sürecektir.

Bir dizindeki toplam dosya sayısında bir sınırlama vardır. 32000 dosyaya kadar çalıştığını hatırlıyorum.


4
Gnome ve KDE bir salyangoz hızında büyük dizinler yükler, pencereler dizini önbelleğe alır. Linux'u seviyorum, ancak kde ve gnome kötü yazılmış.
kale

1
Ve ext4 varsayılan olarak dir_index eşdeğeri gibi görünüyor.
Prof. Falken sözleşmesi

22
Ext3 içindeki bir dizinde yaklaşık 32K alt dizin sınırı vardır , ancak OP görüntü dosyaları hakkında konuşuyor. Dizin Dizini etkinleştirilmiş bir ext3 dosya sistemindeki dosyalarda (pratik?) Bir sınır yoktur.
Peter N Lewis

1
Bu cevap eski, günümüzde varsayılan ext4 .
Boris

1
"Dir Dizin etkinleştirilmiş bir ext3 dosya sistemindeki dosyalarda (pratik?) Bir sınır yoktur" - Etkinleştirilmiş bir 4 TB ext4 dosya sistemindeki bir dizinde dosya alanı kalmadı dir_index. Dizinde yaklaşık 17 milyon dosya vardı. Cevap large_dirtune2fs ile açmaktı.
lunixbochs

49

Linux'ta çok fazla dosya içeren bir dizininiz varsa, kabuğun joker karakterleri genişletemeyebileceğini unutmayın. Linux'ta barındırılan bir fotoğraf albümü ile bu sorunu yaşıyorum. Yeniden boyutlandırılan tüm görüntüleri tek bir dizinde saklar. Dosya sistemi birçok dosyayı işleyebilse de, kabuk işleyemez. Misal:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

veya

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve, bu durumlar için find (1) ve / veya xargs (1) kullanın. Aynı nedenle, bu tür araçları komut satırı genişletmesi yerine komut dosyalarında kullanmak iyi bir fikirdir.
Dave C

3
@ Bir klasördeki dosya sayısı arttığında performansın düştüğünü görüyor musunuz? Yoksa bir ilişki yok mu?
Pacerier

6
Bu iyi bir nokta ama nitpick için verilen neden yanlış. Argüman listesi çok uzun ama sistemin içinde değil, kabuğun bir sınırlamadır execuygulanması. Kabuk genellikle joker karakterleri iyi genişletebilir - exechatayı döndüren birçok argümanla yapılan çağrıdır .
jw013

Dün gece (Fedora 15) "rm" (somefiles *) ile bir dizinde yaklaşık ~ 400.000 dosya ile aynı hatayla karşılaştım. Ben bir "joker" ile bir joker "noktasına" noktaya "find" ile eski dosyaları kırpmak mümkün.
PJ Brunet

10.000.000 dosya etx4 üzerinde bir dizine iyi çalışır. Erişirken çok fazla performans isabeti yok. Ancak joker karakterle oldukça yavaş. Dosya adlarını sıralamayı seven kabuk programlarını kullanırken dikkatli olun! :)
Simon Rigét

25

Şu anda benzer bir sorun üzerinde çalışıyorum. Bir hiyerarşik dizin yapımız var ve dosya kimlikleri olarak resim kimlikleri kullanıyoruz. Örneğin, bir görüntü id=1234567yerleştirilir

..../45/67/1234567_<...>.jpg

dosyanın nereye gittiğini belirlemek için son 4 haneyi kullanarak.

Birkaç bin resim ile, tek seviyeli bir hiyerarşi kullanabilirsiniz. Sistem yöneticimiz, verimlilik / yedekleme / aklındaki diğer nedenler için herhangi bir dizinde (ext3) en fazla bin dosya önermedi.


1
Bu oldukça hoş bir çözüm. Eğer 2 basamaklı arıza ile sopa eğer dizinin dosyaya her düzeyde en fazla 100 giriş olacaktır ve en alt dizinde sadece 1 dosya olurdu.
RobKohr


21

Değeri için, ext4içinde 1.000.000 dosya bulunan bir dosya sisteminde bir dizin oluşturdum , sonra bu dosyalara bir web sunucusu üzerinden rastgele eriştim. Sadece 10 dosyaya sahip olanlara erişim konusunda herhangi bir prim fark etmedim.

Bu, bunu birkaç yıl önce yaptığım deneyimlerden kökten farklı ntfs.


ne tür dosyalar? metin veya resim? i ext4 üzerinde ve wordpress altında tek bir dizinde 80000 görüntüleri almak zorunda ve iyi olup olmadığını bilmek istiyorum
Yvon Huynh

1
@YvonHuynh: Dosya türü tamamen alakasız. Dosyayı listeleme / izleme dizinindeki yükü ne olursa olsun aynıdır.
TJ Crowder

14

Karşılaştığım en büyük sorun 32 bit sistemde. Belirli bir sayıyı geçtikten sonra 'ls' gibi araçlar çalışmayı durdurur.

Bariyeri geçtikten sonra bu dizinde herhangi bir şey yapmaya çalışmak büyük bir sorun haline gelir.


9

Aynı sorunu yaşıyorum. Ext4'te bir Ubuntu sunucusunda milyonlarca dosyayı saklamaya çalışıyorum. Kendi kriterlerimi yönetmeye son verdim. Düz dizinin kullanımı daha kolayken daha iyi performans gösterdiğini öğrendim:

kıyaslama

Bir makale yazdı .


Bir çözümün bağlantısı hoş karşılanır, ancak lütfen cevabınızın onsuz faydalı olduğundan emin olun: bağlantınızın çevresine bağlam ekleyin, böylece diğer kullanıcılarınız ne olduğu ve neden orada olduğu hakkında bir fikir sahibi olacak, ardından sayfanın en alakalı bölümünü alıntılayacağız ' hedef sayfanın kullanılamaması durumunda bağlantı kuruluyor. Bir bağlantıdan biraz daha fazlası olan yanıtlar silinebilir.
Samuel Liew

1
İlginç. 10.000 dosyadan sonra bile performansın çok çabuk kullanılamaz hale geldiğini gördük. Optimum performans elde etmek için dosyaları her seviyede yaklaşık 100 alt dizine bölerek yerleştik. Sanırım hikayenin ahlakı, her zaman kendi gereksinimlerinizle kendi sistemlerinizde kıyaslamaktır.
Joshua Pinter

7

Bir dizin bölümleme şemasını uygulamak için gereken süre çok az ise, bunu destekliyorum. İlk kez bir 10000 dosya dizini konsol aracılığıyla manipüle gerektiren bir sorun hata ayıklamak zorunda kalacak.

Örnek olarak, F-Spot fotoğraf dosyalarını YYYY \ AA \ DD \ dosyaadı.ext olarak saklar, yani ~ 20000 fotoğraf koleksiyonumu elle işlerken uğraşmam gereken en büyük dizin yaklaşık 800 dosyadır. Bu, dosyaları bir üçüncü taraf uygulamasından daha kolay göz atılabilir hale getirir. Yazılımınızın dosyalarına erişecek tek şeyin asla yazılımınızın olduğunu varsaymayın.


6
Toplu içe aktarma, dosyaları belirli bir tarihte kümeleyebileceğinden tarihe göre bölümlere ayırmaya karşı reklam veriyorum.
en fazla

İyi bir nokta. Bir bölümleme şeması seçmeden önce kullanım durumlarınızı kesinlikle göz önünde bulundurmalısınız. Nispeten geniş bir dağıtımda birçok gün boyunca fotoğrafları içe aktarıyorum ve fotoğrafları F-Spot tarihi dışında değiştirmek istediğimde onları bulmanın en kolay yolu, bu yüzden benim için çift kazanma.
Sparr

7

Kesinlikle dosya sistemine bağlıdır. Birçok modern dosya sistemi, dizinlerin içeriğini depolamak için iyi veri yapıları kullanır, ancak eski dosya sistemleri genellikle girişleri bir listeye ekledi, bu nedenle bir dosyayı almak O (n) işlemiydi.

Dosya sistemi doğru yapsa bile, dizin içeriklerini listeleyen ve O (n ^ 2) türlerini listeleyen programların kesinlikle güvenli olması için, her zaman dosya sayısını sınırlandırırdım. en fazla 500 dizin.


7

Gerçekten kullanılan dosya sistemine ve ayrıca bazı bayraklara bağlıdır.

Örneğin, ext3 binlerce dosyaya sahip olabilir; ama birkaç bin kişiden sonra çok yavaştı. Çoğunlukla bir dizini listelerken, aynı zamanda tek bir dosyayı açarken. Birkaç yıl önce, bir dosya adı verilen bir inode almak için gereken süreyi önemli ölçüde kısaltan 'htree' seçeneğini kazandı.

Şahsen, alt düzeyleri bin seviyenin altında tutmak için alt dizinleri kullanıyorum. Sizin durumunuzda, kimliğin son iki onaltılık hanesiyle 256 dizin oluştururdum. İlk basamakları değil son basamakları kullanın, böylece yükü dengeleyin.


6
Dosya adları tamamen rastgele olsaydı, hangi rakamların kullanıldığı önemli değildir.
19'da strager

Gerçekten de, bu dosya adları rastgele oluşturulur.
Kip

2
Veya dosya adının SHA-1 özetinin ilk N baytını kullanın.
gawi

6

ext3 aslında dizin boyutu sınırlarına sahiptir ve dosya sisteminin blok boyutuna bağlıdır. Klasör başına "maksimum sayı" değil, klasör başına "dosya girişlerini depolamak için kullanılan maksimum blok sayısı" vardır. Özellikle, dizinin kendisinin boyutu 3 yüksekliğindeki bir b ağacının ötesinde büyüyemez ve ağacın kesimi blok boyutuna bağlıdır. Bazı ayrıntılar için bu bağlantıya bakın.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

Son zamanlarda 2K blokları ile biçimlendirilmiş bir dosya sisteminde ısırıldım, bu warning: ext3_dx_add_entry: Directory index full!da başka bir ext3 dosya sisteminden kopyalarken ucuz bir şekilde dizin dolu çekirdek mesajları alıyordu . Benim durumumda, sadece 480.000 dosya içeren bir dizin hedefe kopyalanamadı.


5

Soru, dosyalarla ne yapacağınızla ilgili.

Windows altında, 2k'den fazla dosya içeren herhangi bir dizin Explorer'da benim için yavaşça açılır. Hepsi resim dosyalarıysa, 1 binden fazla resim küçük resim görünümünde çok yavaş açılır.

Bir zamanlar, sistem tarafından getirilen sınır 32.767 idi. Şimdi daha yüksek, ancak bu bile çoğu durumda bir seferde işlenemeyecek kadar çok dosya.


5

Yukarıdaki cevapların çoğunun gösteremediği şey, orijinal soruya "Tek Beden Herkese Uygun" yanıtı olmamasıdır.

Günümüz ortamında farklı donanım ve yazılımlardan oluşan büyük bir holdingimiz var - bazıları 32 bit, bazıları 64 bit, bazıları son teknoloji ve bazıları denenmiş ve gerçek - güvenilir ve asla değişmiyor. Buna ek olarak çeşitli eski ve yeni donanımlar, eski ve yeni işletim sistemleri, farklı satıcılar (Windows, Unixes, Apple vb.) Ve devam eden sayısız yardımcı program ve sunucu bulunmaktadır. Donanım geliştikçe ve yazılım 64 bit uyumluluğa dönüştürüldüğünden, bu çok büyük ve karmaşık dünyanın tüm parçalarının değişikliklerin hızlı temposuyla iyi bir şekilde oynatılmasında önemli bir gecikme olmuştur.

IMHO Bir sorunu çözmenin tek yolu yok. Çözüm, olasılıkları araştırmak ve daha sonra deneme yanılma yoluyla, özel ihtiyaçlarınıza en uygun olanı bulmaktır. Her kullanıcı bir çerez kesici yaklaşımı kullanmak yerine kendi sistemi için neyin işe yaradığını belirlemelidir.

Örneğin birkaç büyük dosyaya sahip bir medya sunucum var. Sonuç, yalnızca 3 TB sürücüyü dolduran yaklaşık 400 dosyadır. İnotların sadece% 1'i kullanılır, ancak toplam boşluğun% 95'i kullanılır. Çok daha küçük dosyaları olan bir başkası, alanı doldurmaya yaklaşmadan önce inode bitebilir. (Ext4 dosya sistemlerinde genel bir kural olarak, her dosya / dizin için 1 inode kullanılır.) Teorik olarak bir dizinde bulunabilecek toplam dosya sayısı neredeyse sonsuz olsa da, pratiklik genel kullanımın gerçekçi birimleri belirlediğini belirler, sadece dosya sistemi yetenekleri.

Umarım yukarıdaki tüm farklı cevaplar ilerleme için aşılmaz bir engel sunmak yerine düşünce ve problem çözmeyi teşvik etmiştir.


4

Çıktıda büyük miktarda dosya oluşturan bir programı çalıştırdığımı hatırlıyorum. Dosyalar dizin başına 30000 olarak sıralanmıştır. Üretilen çıktıyı yeniden kullanmak zorunda kaldığımda herhangi bir okuma problemi olduğunu hatırlamıyorum. 32-bit bir Ubuntu Linux dizüstü bilgisayarındaydı ve Nautilus bile birkaç saniye sonra bile dizin içeriğini görüntüledi.

ext3 dosya sistemi: 64-bit bir sistemdeki benzer kod, dizin başına 64000 dosya ile iyi işlem yapmıştır.


4

"Dosya sistemine bağlıdır"
Bazı kullanıcılar performans etkisinin kullanılan dosya sistemine bağlı olduğunu belirttiler. Elbette. EXT3 gibi dosya sistemleri çok yavaş olabilir. Ancak EXT4 veya XFS kullansanız bile, bir klasör üzerinden lsveya findFTP gibi harici bir bağlantı üzerinden bir klasör listelemenin daha yavaş olmasını engelleyemezsiniz .

Çözüm @armandino ile
aynı şekilde tercih ederim . Bunun için ben PHP bu küçük işlevi kimlikleri dizin başına 1000 dosya sonuçları bir dosya yoluna dönüştürmek için kullanın:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

veya alfa-sayısal karakterler kullanmak isterseniz ikinci sürümü kullanabilirsiniz:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

Sonuçlar:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

$int-Version için de görebileceğiniz gibi her klasör 1000 dosya ve 1000 dosya ve 99 dizin içeren 99 dizin içerir ...

Ancak birçok dizinde aynı performans sorunlarına neden olduğunu unutmayın!

Son olarak, toplam dosya miktarını nasıl azaltacağınızı düşünmelisiniz. Hedefinize bağlı olarak, avatarlar, simgeler, ifadeler vb. Gibi birden fazla küçük resmi birleştirmek için CSS spritelarını kullanabilirsiniz veya çok sayıda küçük medya olmayan dosya kullanıyorsanız bunları JSON biçiminde birleştirmeyi düşünebilirsiniz. Benim durumumda binlerce mini önbellek vardı ve sonunda onları 10'luk paketler halinde birleştirmeye karar verdim.


3

Bunun kaç tanesinin çok fazla olduğu sorusuna tamamen cevap vermediğine saygı duyuyorum, ancak uzun vadeli problemi çözmek için bir fikir, orijinal dosya meta verilerini depolamanın yanı sıra, hangi klasörü içinde saklandığını - normalleştirin bu meta veri parçasını Bir klasör performans, estetik veya herhangi bir nedenden ötürü rahat olduğunuz bir sınırı aştığında, sadece ikinci bir klasör oluşturur ve dosyaları oraya bırakmaya başlarsınız ...


3

Benzer bir sorunla karşılaştım. İçinde 10.000'den fazla dosya bulunan bir dizine erişmeye çalışıyordum. Dosya listesini oluşturmak ve dosyaların herhangi bir komutunu çalıştırmak çok uzun sürüyordu.

Kendim için bunu yapmak için küçük bir php betiği düşündüm ve tarayıcıda zaman aşımı önlemek için bir yol bulmaya çalıştım.

Sorunu çözmek için yazdığım php betiği aşağıdadır.

FTP için çok fazla dosya içeren bir Dizindeki Dosyaları Listeleme

Birine nasıl yardımcı olur


1

Bir cevap değil, sadece bazı öneriler.

Daha uygun bir FS (dosya sistemi) seçin. Tarihsel bir bakış açısından, tüm sorunlarınız, bir zamanlar on yıllardır gelişen FS'lerin merkezinde olacak kadar akıllıydı. Yani daha modern FS sorunlarınızı daha iyi destekliyor. Öncelikle FS listesinden nihai amacınıza göre bir karşılaştırma karar tablosu yapın .

Sanırım paradigmalarını değiştirme zamanı. Bu yüzden kişisel olarak dağıtılmış bir sistem farkında FS kullanmanızı öneririm , yani boyut, dosya sayısı vb. İle ilgili hiçbir sınır yoktur.

Çalışacağımdan emin değilim, ancak bazı denemelerden bahsetmezseniz, geçerli dosya sisteminiz üzerinde AUFS'yi deneyin. Sanırım birden fazla klasörü tek bir sanal klasör olarak taklit edebilecek olanaklara sahip.

Donanım sınırlarını aşmak için RAID-0 kullanabilirsiniz.


1

İşletim sisteminin sınırlarını aşmadığı sürece "çok fazla" olan tek bir rakam yoktur. Bununla birlikte, bir dizinde ne kadar çok dosya olursa olsun, işletim sistemine bakılmaksızın, herhangi bir dosyaya erişmek daha uzun sürer ve çoğu işletim sisteminde performans doğrusal değildir, bu nedenle 10.000'den bir dosyayı bulmak 10 kat daha uzun sürer sonra 1.000'de bir dosya bulmak için.

Bir dizinde çok sayıda dosya bulunmasıyla ilişkili ikincil sorunlar, joker kart genişletme hatalarını içerir. Riskleri azaltmak için, dizinlerinizi yükleme tarihine veya başka bir yararlı meta veri parçasına göre sipariş etmeyi düşünebilirsiniz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.