我正在尝试构建一个文件上传站点作为辅助项目，我从来没有构建任何需要处理大量这样的文件的东西 . 据我所知，存储和检索文件有三个主要选项（请注意，每次上传可能有多个文件，因此，例如，website.com/a23Fc可能允许您下载单个或多个文件，具体取决于用户最初上传的数量 - 与imgur.com类似：
-
将所有文件粘贴在一个巨大的文件目录中，并使用（关系）数据库确定哪些文件属于哪些URL，然后根据该文件返回文件名列表 . 示例：用户加载website.com/abcde，因此它会向数据库查询与abcde上传相关的所有文件，返回其文件名，并且网站会输出这些文件 .
-
使用CouchDB，因为它允许您实际将文件附加到数据库中的各个记录，因此每个URL /上载可以是附加了文件的DB记录 . 例如，用户加载website.com/abcde，CouchDB使用abcde的ID获取文档，获取附加到该文档的文件，并将其提供给用户 .
-
完全省略使用数据库，并为每次上传创建一个新目录并将文件粘贴到该目录中 . 示例：用户加载website.com/abcde，站点查找/ files / abcde /目录，从中获取所有文件，并将其提供给用户，因此根本不涉及数据库 .
哪些似乎最具可扩展性？就像我说的那样，我在这方面的经验很少，所以如果我完全关闭，或者如果有明显的第四选择，我不仅仅对它持开放态度 . 在单个目录中具有数千或数百万个文件（即，选项1）似乎不是很聪明，但是在目录中具有数千或数百万个目录（即，选项3）似乎不太好 .
3 回答
我建议您在最短的时间内完成个人解决方案 . 如果你已经有CouchDB工作原型，那就去吧！面向关系或面向文件系统的解决方案也是如此 .
由于两个原因，上市时间比架构更重要：
这是一个侧面项目，你应该尽量做到尽可能远 .
If 该网站变得流行，因为主要目的是文件上传，您可能会在网站生命周期内至少重建一次核心服务，也许更多 .
我曾经工作的公司面临着大约一PB的图像文件的确切问题 . 他们的解决方案是使用安德鲁文件系统（请参阅http://en.wikipedia.org/wiki/Andrew_File_System以获取更多信息）将文件存储在与URL结构匹配的目录结构中 . 这在实践中非常好 .
他们还记录了数据库中存在的文件，原因是其应用程序内部的其他原因 .
如果您要使用ASP.NET，请参阅此文章，该文章介绍如何为Web场使用分布式文件系统http://weblogs.asp.net/owscott/archive/2006/06/07/DFS-for-Webfarm-Usage---Content-Replication-and-Failover.aspx