在一个目录中保存多少文件有关系吗?如果是,一个目录中有多少文件是太多的,拥有太多文件的影响是什么?(这是在Linux服务器上。)

Background: I have a photo album website, and every image uploaded is renamed to an 8-hex-digit id (say, a58f375c.jpg). This is to avoid filename conflicts (if lots of "IMG0001.JPG" files are uploaded, for example). The original filename and any useful metadata is stored in a database. Right now, I have somewhere around 1500 files in the images directory. This makes listing the files in the directory (through FTP or SSH client) take a few seconds. But I can't see that it has any effect other than that. In particular, there doesn't seem to be any impact on how quickly an image file is served to the user.

我想过通过创建16个子目录来减少图像的数量:0-9和a-f。然后我将根据文件名的第一个十六进制数字将图像移动到子目录中。但是除了偶尔通过FTP/SSH列出目录之外,我不确定这样做是否有任何理由。


当前回答

我现在正在研究一个类似的问题。我们有一个层次结构的目录结构,并使用映像id作为文件名。例如,其中放置了id=1234567的图像

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

使用最后4位数字来确定文件的位置。

对于几千张图像,您可以使用一级层次结构。出于效率/备份/其他考虑,系统管理员建议在任何给定目录(ext3)中不超过几千个文件。

其他回答

我尊重这并不能完全回答你的问题,多少是太多了,但解决长期问题的一个想法是,除了存储原始文件元数据外,还存储它存储在磁盘上的哪个文件夹-规范化元数据。一旦一个文件夹的增长超出了性能、美观或其他原因的限制,你只需创建第二个文件夹并开始在那里放置文件……

FAT32:

最大文件数:268,173,300 每个目录的最大文件数:216 - 1 (65,535) 最大文件大小:2 GiB - 1无LFS, 4 GiB - 1有

NTFS:

最大文件数:232 - 1 (4,294,967,295) 最大文件大小 实现:244 - 26字节(16 TiB - 64 KiB) 理论:264 - 26字节(16 EiB - 64 KiB) 最大卷大小 实现:232 - 1个集群(256tib - 64kib) 理论:264 - 1个集群(1 YiB - 64 KiB)

ext2:

最大文件数:1018 每个目录的最大文件数:~1.3 × 1020(性能问题超过10,000) 最大文件大小 16gib(每块大小为1kib) 256gib(区块大小为2kib) 2 TiB(区块大小4 KiB) 2 TiB(块大小为8 KiB) 最大卷大小 4 TiB(区块大小为1kib) 8 TiB(区块大小为2 KiB) 16 TiB(区块大小为4 KiB) 32 TiB(块大小为8 KiB)

ext3:

最大文件数:min(volumeSize / 213, numberOfBlocks) 最大文件大小:与ext2相同 最大卷大小:与ext2相同

ext4:

最大文件数:232 - 1 (4,294,967,295) 每个目录的最大文件数:无限制 最大文件大小:244 - 1字节(16tib - 1) 最大卷大小:248 - 1字节(256tib - 1)

不是答案,只是一些建议。

选择一个更合适的FS(文件系统)。因为从历史的角度来看,你们所有的问题都是足够明智的,在过去几十年里曾经是金融服务体系演变的核心。我的意思是更现代的FS更好地支持你的问题。首先从FS列表中做出一个基于你最终目的的比较决策表。

我认为是时候改变你的思维模式了。所以我个人建议使用分布式系统支持的FS,这意味着在大小、文件数量等方面没有任何限制。否则,你迟早会遇到意想不到的新问题。

我不确定这是否有效,但如果您没有提到一些实验,请尝试一下当前文件系统上的AUFS。我想它可以将多个文件夹模拟为单个虚拟文件夹。

为了克服硬件限制,可以使用RAID-0。

“取决于文件系统” 一些用户提到性能影响取决于所使用的文件系统。当然可以。像EXT3这样的文件系统可能非常慢。但是即使您使用EXT4或XFS,也不能防止通过ls或查找或通过FTP等外部连接列出文件夹会变得越来越慢。

解决方案 我喜欢和@armandino一样的方式。为此,我使用PHP中的这个小函数将id转换为每个目录1000个文件的文件路径:

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)) . '/';
}

或者你可以使用第二个版本,如果你想使用字母数字字符:

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)) . '/';
}

结果:

<?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每个文件夹最多包含1000个文件和99个目录,其中包含1000个文件和99个目录…

但是不要忘记,许多目录会导致相同的性能问题!

最后,您应该考虑如何减少文件总数。根据你的目标,你可以使用CSS精灵组合多个小图像,如头像,图标,微笑等,或者如果你使用许多小的非媒体文件,考虑将它们组合在JSON格式。以我为例,我有数千个迷你缓存,最后我决定将它们组合成10个。

没有一个数字是“太多”的,只要它不超过操作系统的限制。然而,不管哪种操作系统,一个目录中的文件越多,访问任何单个文件所需的时间就越长,而且在大多数操作系统上,性能是非线性的,因此从10,000个文件中找到一个文件所需的时间是在1,000个文件中找到一个文件所需的时间的10倍以上。

与目录中有大量文件相关的次要问题包括通配符展开失败。为了降低风险,您可以考虑根据上传日期或其他有用的元数据对目录进行排序。