我们正在创建一个ASP.Net MVC网站，需要存储100万张图片，大小约为2k-5k。从以前的ressearch看，它看起来像文件服务器可能比db更好（除此之外可以随意评论）。
存储这么多文件时有什么特别需要考虑的吗？如果一个文件夹中有这么多文件，Windows是否能够快速找到照片有什么问题？是否需要创建分段目录结构，例如将它们按文件名分割？如果解决方案能够扩展到至少1000万张图片以满足未来可能的扩展需求，那就太好了。
答案 0 :(得分：5)
4Kb是NTFS的默认簇大小。您可以根据通常的图片尺寸调整此设置。 http://support.microsoft.com/kb/314878
我会构建一个包含子目录的树，以便能够从一个FS移动到另一个FS：How many files can I put in a directory? 并避免一些问题：http://www.frank4dd.com/howto/various/maxfiles-per-dir.htm
您还可以拥有包含相关图片的存档，只需打开一个文件即可加载它们。可能压缩的档案可能是I / O瓶颈，如果是CPU则未压缩。
数据库更容易维护但速度更慢......所以这取决于你！
答案 1 :(得分：3)
有关目录结构的一些讨论，另请参阅this Server Fault question。
答案 2 :(得分：2)
问题不在于文件系统无法在目录中存储这么多文件，而是如果要使用Windows资源管理器访问该目录，则需要永久保存，因此如果您需要手动访问该文件夹你应该对它进行分割，例如每个2-3个名字的第一个字母/数字的目录，甚至更深的结构。
如果你可以将1k文件夹中的1k文件分开，每个文件都绰绰有余，而且这样做的代码非常简单。
答案 3 :(得分：1)
假设NTFS，每卷的限制为40亿个文件（2 ^ 32 - 1）。这是卷上所有文件夹的总限制（包括操作系统文件等）
单个文件夹中的大量文件应该不是问题; NTFS使用B +树进行快速检索。 Microsoft建议您禁用短文件名生成（允许您将mypictureofyou.html检索为mypic~1.htm的功能）。
我不知道将它们分成多个目录是否有任何性能优势;我的猜测是没有优势，因为NTFS是为大型目录的性能而设计的。
如果您决定将它们分成多个目录，请在文件名上使用哈希函数来获取目录名称（而不是目录名称，例如文件名的第一个字母），以便每个子目录大致相同数量的文件。
答案 4 :(得分：1)
我不排除使用内容分发网络。它们专为此问题而设计。我在Amazon S3上取得了很大的成功。由于您使用的是基于Microsoft的解决方案，因此Azure可能非常合适。
是否存在某种阻止您使用第三方解决方案的要求？