构建可扩展的文件上载站点

Mik*_*den 5 performance couchdb scalability file-upload file

我正在尝试构建一个文件上传站点作为辅助项目,我从来没有构建任何需要处理大量这样的文件的东西.据我所知,存储和检索文件有三个主要选项(请注意,每次上传可能有多个文件,因此,例如,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)似乎并不是更好.

Jas*_*ith 0

我推荐您个人可以在最短的时间内完成的解决方案。如果您已经有了可用的 CouchDB 原型,那就去做吧!对于面向关系或面向文件系统的解决方案也是如此。

上市时间比架构更重要,原因有二:

  1. 这是一个副业项目,你应该尽可能地进行下去。
  2. 如果该网站变得流行,由于主要目的是文件上传,您可能会在网站的生命周期内至少重建一次核心服务,甚至可能多次。