我们正在创建一个 ASP.Net MVC 站点，该站点需要存储 100 万多张图片，大小约为 2k-5k。从以前的研究来看，文件服务器可能比数据库更好（否则请随意评论）。
存储这么多文件时有什么特别需要考虑的吗？如果一个文件夹中有这么多文件，Windows 能否快速找到照片有什么问题吗？是否需要创建分段目录结构，例如按文件名划分它们？如果该解决方案能够扩展到至少 1000 万张图片以满足未来潜在的扩展需求，那就太好了。
问问题
1572 次
5 回答
5
4Kb 是 NTFS 的默认群集大小。您可以根据通常的图片尺寸调整此设置。 http://support.microsoft.com/kb/314878
我会用子目录构建一棵树，以便能够从一个 FS 移动到另一个：我可以在一个目录中放置多少个文件？ 并避免一些问题：http ://www.frank4dd.com/howto/various/maxfiles-per-dir.htm
您还可以拥有包含相关图片的档案，以便在仅打开一个文件的情况下加载它们。这些档案可能会被压缩，瓶颈是 I/O，如果是 CPU，则未压缩。
数据库更容易维护但速度更慢......所以这取决于你！
于 2010-04-02T16:09:49.847 回答
3
有关目录结构的一些讨论，另请参阅此服务器故障问题。
于 2010-04-02T18:56:02.197 回答
2
问题不在于文件系统无法在一个目录中存储这么多文件，而是如果您想使用 Windows 资源管理器访问该目录将需要很长时间，因此如果您需要手动访问该文件夹，您应该分段例如，每个名称的 2-3 个首字母/数字都有一个目录，甚至是更深的结构。
如果您可以将其划分为 1k 个文件夹和 1k 个文件，每个文件夹将绰绰有余，并且执行此操作的代码非常简单。
于 2010-04-02T19:05:52.103 回答
1
假设 NTFS，每个卷有 40 亿个文件的限制 (2^32 - 1)。这是卷上所有文件夹（包括操作系统文件等）的总限制。
单个文件夹中的大量文件应该不是问题；NTFS 使用 B+ 树进行快速检索。Microsoft 建议您禁用短文件名生成（允许您将 mypictureofyou.html 检索为 mypic~1.htm 的功能）。
我不知道将它们分成多个目录是否有任何性能优势；我的猜测是不会有优势，因为 NTFS 是为大型目录的性能而设计的。
如果您决定将它们分成多个目录，请在文件名上使用哈希函数来获取目录名（而不是目录名是文件名的第一个字母），以便每个子目录的编号大致相同的文件。
于 2010-04-02T16:14:13.433 回答
1
我不排除使用内容交付网络。它们是为这个问题而设计的。我在 Amazon S3 上取得了很大的成功。由于您使用的是基于 Microsoft 的解决方案，因此 Azure 可能是一个不错的选择。
是否有某种要求阻止您使用第三方解决方案？
于 2010-04-02T16:18:05.657 回答