我有一个基于Linux的应用程序（Drupal - PHP + Apache + MySQL），可快速扩展以在同一文件夹中保存数千张图片。我现在可能接近2000。在一个文件夹中有这么多图像有什么缺点吗？它能否代表性能方面的影响？
我不打算浏览该文件夹中的文件，服务器只是在请求其URL时提供图像，但我想知道将来是否会出现问题（应用程序正在扩展，缩放数量）图片，它可以达到20,000，30,000张图片...）。也许我应该计划一个策略，将这个怪异的图像文件夹分成子文件夹，比如使用子文件夹的用户名，或上传图片的年月。
简而言之，问题是：在Linux服务器的同一文件夹中有数千张图片是不是很糟糕（不确定我的应用程序使用的是哪种风格，它实际上是在共享托管环境中）？我应该做些什么来避免这种方法并将这些项目拆分成子文件夹吗？是否有关于每个文件夹的文件数或每个文件夹的最大文件数的建议？
感谢您分享您的想法。
答案 0 :(得分：1)
它在很大程度上取决于文件系统（以及挂载选项）。
最近的文件系统（ext4，btrfs ....）能够处理包含大量文件的大型目录（因此可能处理包含50万个文件的目录）
但是，在您需要fsck多TB文件系统的极少数情况下，您会感到高兴！
但是，shell（和globbing函数 - 读glob(7)和glob(3)等...）可能对数千个条目的目录不满意。 （考虑交互式shell中的autocomplete可能需要扫描目录）。如果ls需要一分钟来回答数千行，那么人类用户（例如某些系统管理员）可能会生气....
我建议每个目录只有几千个文件（包括子目录）。考虑组织您的图片，例如a0/001.png ... a0/999.png a1/001.png ... a1/999.png .... b9/等...
如果你真的有很多文件，你可能想为它们使用不同的文件系统（例如a0/ ... a9/在一个磁盘上b0/ .. 。b9/另一个）....或者使用LVM，或者OpenStack Swift 对象存储或 Cinder 块存储等等。
同时查看Nosql个数据库......
顺便说一下，如果你的目标是扩展到PB级存储，那么事情就会变得不那么容易了....您可能希望在某个数据库中至少存储文件名。