如何存储数以百万计的大小为2K的图片

我们正在创建一个ASP.Net MVC网站，需要存储100万张图片，大小约为2k-5k。从以前的研究，它看起来像一个文件服务器可能比数据库更好（随意评论，否则）。如何存储数以百万计的大小为2K的图片

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

2010-04-02 alchemical

4Kb是NTFS的默认群集大小。您可能会根据通常的图片大小调整此设置。 http://support.microsoft.com/kb/314878

我将建立与子目录树能够从一个FS移动到另一个：How many files can I put in a directory? ，避免一些问题：http://www.frank4dd.com/howto/various/maxfiles-per-dir.htm

您还可以有一个包含相关图片档案对他们只有一个加载文件打开。可能压缩的档案可能是压缩的瓶颈是I/O，如果是CPU，则不压缩。

数据库比较容易维护，但速度较慢......所以这取决于您！

来源

2010-04-02 16:09:49 Guillaume

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

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

我不知道是否有任何性能优势分割成多个目录;我的猜测是没有优势，因为NTFS是为具有大型目录的性能而设计的。

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

来源

2010-04-02 16:14:13

尽管代码可能能够读取包含大量全部文件的目录中的文件，但它仍不是一个好主意。如果您曾尝试在资源管理器中打开一个包含数千个文件的目录，则它非常缓慢。散列入子目录对此有很大帮助。 – Kleinux 2010-04-02 19:11:28

资源管理器中的缓慢可能是由于Explorer试图处理所有这些文件名而不是自己检索文件名。例如，阅读所有文件并显示缩略图将需要很长时间。如果您已经知道文件名，则检索单个文件应该很快。如果您编写自己的系统来存储和检索文件，您可能会或可能不会获得比NTFS更好的性能。 – 2010-04-05 00:52:43

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

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

来源

2010-04-02 16:18:05

有关目录结构的一些讨论，另请参阅this Server Fault question。

来源

2010-04-02 18:56:02

问题不在于文件系统无法在目录中存储如此多的文件，而是如果您想使用Windows资源管理器访问该目录，则需要永久使用，因此如果您需要手动访问该目录你应该对它进行分段，例如每2-3个名字的首字母/数字或甚至更深的结构。

如果你可以用1k的文件分割1k文件夹，那么每个文件夹就足够了，而且这样做的代码很简单。

来源

2010-04-02 19:05:52

如何存储数以百万计的大小为2K的图片

回答

相关问题