File 如何存储数百万张大小约为2k的图片

我们正在创建一个ASP.NETMVC站点，该站点将需要存储100多万张图片，大小约为2k-5k。从以前的ressearch来看，文件服务器可能比db更好（如果不是这样，请随意评论）

---

当存储这么多文件时，有什么特别的需要考虑吗？如果一个文件夹中有这么多文件，Windows是否可以快速找到照片？是否需要创建分段目录结构，例如，按文件名将其分割？如果解决方案能够扩展到至少1000万张图片，以满足未来潜在的扩展需求，那就太好了。

4Kb是NTFS的默认集群大小。您可以根据通常的图片大小调整此设置。

我将构建一个带有子目录的树，以便能够从一个FS移动到另一个FS： 避免一些问题：

您还可以使用包含关联图片的存档，以便在仅打开一个文件的情况下加载它们。这些档案可能是压缩的，瓶颈是I/O，如果是CPU，则是未压缩的

---

DB更容易维护，但速度较慢。。。所以这取决于你

假设使用NTFS，则每个卷有40亿个文件的限制（2^32-1）。这是卷上所有文件夹（包括操作系统文件等）的总限制

单个文件夹中的大量文件不应该是问题；NTFS使用B+树进行快速检索。Microsoft建议您禁用短文件名生成功能（该功能允许您将mypictureofyou.html检索为mypic~1.htm）

我不知道将它们分割成多个目录是否有任何性能优势；我猜这不会有什么优势，因为NTFS是为大目录的性能而设计的

---

如果您决定将它们分割为多个目录，请在文件名上使用哈希函数来获取目录名（而不是目录名是文件名的第一个字母），以便每个子目录的文件数大致相同。

我不排除使用内容交付网络。它们是为解决这个问题而设计的。我在AmazonS3上取得了很多成功。因为您使用的是基于Microsoft的解决方案，所以Azure可能非常适合

---

是否有某种要求阻止您使用第三方解决方案？

有关目录结构的讨论，另请参阅。

问题不在于文件系统无法在一个目录中存储这么多文件，而在于如果您想使用windows资源管理器访问该目录，则需要花费很长时间，因此，如果您需要手动访问该文件夹，您应该对其进行分段，例如，每个名称的2-3个首字母/数字都有一个目录，甚至更深层的结构

---

如果您可以将其划分为1k个文件夹，每个文件夹包含1k个文件，那么就足够了，而且这样做的代码非常简单。

虽然代码可以读取包含大量文件的目录中的文件，但这仍然不是一个好主意。如果您曾经尝试在资源管理器中打开一个包含数千个文件的目录，那么速度会非常慢。散列到子目录中有很大帮助。资源管理器中的速度慢可能更多地是因为资源管理器试图处理所有这些文件名，而不是检索文件名本身。例如，读取所有文件和显示缩略图需要很长时间。如果您已经知道文件名应该很快，则检索单个文件。如果您编写自己的系统来存储和检索文件，您可能会也可能不会获得比NTFS更好的性能。