我打算在网络服务器上存储很多图像（> 100,000）。如何在网络服务器上存储许多图像？
该文件名将用于前。
324-2012-07-25-143544.jpg
的文件名是建立这样的：
用户id年 - 月 - 日 - HHMMSS.jpg
这个文件名将被保存在一个mysqldatabase中，并将被读取，并从文件名中知道文件路径 - >
个图像/用户名/年/月/日/用户id年 - 月 - 日 - HHMMSS.jpg
所以在本例中是
图像/ 324/2012/07/25/324-2012-07-25-143544.jpg
将everythin保存在basefolder/images中时可能发生的任何性能问题？
谢谢！
分割文件，就像你正在做的那样，避免在一个目录中有很多文件时出现性能问题的好方法：在这种方法中，你要确保只有几个条目（目录或文件）在任何给定的目录中。如果需要的话，还可以轻松分割多个卷 - 只需在不同的位置安装一些高级目录即可。
你应该考虑一些事情。
如果你打算对这些图像的基本永久存储，你可能希望根据ID来碎片。从数据库方面处理起来更容易一些（出于同样的原因，我们在数据库设计中使用了任意的主键）。
Like @Veger建议：imageid 123456变成/12/1234/123456.jpg。
使用日期，用户ID或自动增加的编号可能会带来安全风险，虽然，因为它们相对容易猜到，因此它很容易为别人收获的所有图像。
此外，如果没有理由让用户知道上传日期，那么在URL中包含日期可能会泄漏信息。
如果您使用的是非常难猜的密钥，它可以提供一定程度的安全性，以防收获和信息泄露。例如，您可以使用GUID：图像ID 6f33395e-eda8-4486-8b8e-51ea0f91751b被存储为/6/6f33/6f33395e/6f33395e-eda8-4486-8b8e-51ea0f91751b.jpg。
有一个疯狂的高数量的GUID（它是128位），所以它可能需要数百万年的时间才能收获一切（即使你没有采取任何额外的步骤，如每小时每IP限制连接等） 。
如果你的图片是挥发性的 - 也就是说，他们一定量的时间之后过期 - 那么它实际上可能是最好的基于日期结构，如/2012/12/14/2012-12-14-hhmmss-userid.jpg到分片，也可以结合这与一个GUID并得到。
如果你想删除2011年的所有文件，你只需要rm -rf 2011。一个很好的例子是什么时候使用这个日志文件。
您必须记住，这只对非常有用很高的图像数量，因为您可以在数据库中查询以查找基于日期的过期图像，然后只是一个一个地删除它们-一。
使用碎片的多个图像的粒度更高您计划最终商店，但请记住，如果你去过于详尽，你会失去很多的开销磁盘空间目录条目。
目标是将每个目录的条目数保持为文件系统可以处理的条目数;好的经验法则似乎是大约10,000最大。你必须预测你的网站将在下一段时间获得的流量。不要发疯，想一下你可能每天会有数百万用户。重新碎片并不是不可能的，但这是一种痛苦。预测未来几年你的增长并处理它。如果你的增长速度更快，并且必须重新分片，那么解决这个问题是一个很好的问题。如果你的磁盘空间不足，因为你的目录条目比你的图片占用更多的空间，那么这是一个愚蠢的问题。
我会做这样的：
例如，图像编号1存储为/0/1.jpg，图像编号1234567存储为/123/1234567.jpg（您可以存储10000个文件到目录中）。
最容易，噪音最小，并优化目录中的文件数量（而不是浪费大量的半满目录）。
如果你真的要存储很多的图像，使用2个子目录！像/0/0/1.jpg和/1/12345/123456789.jpg
如果你想使用日期部分作为目录结构，那么确保你将它们唯一地存储在数据库中 - 如果它只用于绝对文件访问，这没问题。如果他们有可能会以编程方式使用（列出有图像的有效年限），则将其存储为单独的字段。没有比尝试将一个Dd字段拆分为多个来处理更糟糕的事情了...... – Basic