代码之家  ›  专栏  ›  技术社区  ›  Omar

开发文件存储Web应用程序

  •  2
  • Omar  · 技术社区  · 14 年前

    我目前正在开发一个Web应用程序,它的主要用户功能是上传和下载文件。这些文件将存储在硬盘上(还没有云存储)。

    考虑到千兆字节的数据和大量文件的可能性,我是否需要将文件组织到子文件夹中以考虑文件的获取,或者文件系统的索引是否已经非常有效,我可以忽略这个潜在的瓶颈?

    更新:

    另一方面,我计划将文件名和任何附加信息存储在SQL数据库中,并且只在用户真正想要下载文件时查询磁盘。这就是我计划如何检索文件:

    FileStream stream = File.Open("C:\file.txt");
    byte[] fileContent = new byte[stream.Length];
    stream.Read(fileContent, 0, fileContent.Length;
    

    将从数据库中检索任何文件信息。硬盘将仅用于保存和获取文件。

    更新2:

    文件将另存为 GUID + EXTENSION 在硬盘上,而实际文件名存储在数据库中。

    4 回复  |  直到 14 年前
        1
  •  3
  •   Cahit    14 年前

    是的,您需要进一步细分文件,以节省用于目录中文件枚举的时间,尽管使用此方法可以节省多少成本,这可能取决于您使用的O/S。当您需要在文件夹中的数百个文件中请求一个文件时,Windows会非常慢。我相信这是因为如果必须搜索所有文件,它将尝试读取所有文件的所有属性。此外,对于这种类型的应用程序,您可能需要担心文件版本、文件上载超时、感染病毒的文件、对最终用户隐藏真实文件路径、不支持的mime类型等。

        2
  •  2
  •   µBio    14 年前

    再加上@cahitbox所说的,它比这更进一步。如果您期望多个并发用户,那么您应该有多个磁盘,这样您就可以同时检索多个文件(磁盘速度很慢)。

        3
  •  1
  •   mathieu    14 年前

    如果文件“metadata”存储在数据库中,您只需使用guid及其扩展名命名文件。 将它们返回给用户的最简单方法是将它们直接存储在Web应用程序中,因此,如果安全约束不太紧,则可以通过简单的URL使用它们:

    http://my.web.site/files/cbacd260-10ec-4377-bd19-25daa1fd0fe2.pdf
    

    如果你真的想通过和httphandler服务你的文件,我会使用

    Response.TransmitFile( Server.MapPath("path/to/files/cbacd260-10ec-4377-bd19-25daa1fd0fe2.pdf" );
    

    此处的文档: http://msdn.microsoft.com/en-us/library/12s31dhy%28VS.80%29.aspx

    预期的用户数量也非常重要。每天30个用户和30000个用户不同。 文件容量测量也很重要:您谈论的是千兆字节,但在管理300 GB时,您将无法管理30 GB。

    对于文件的物理存储,尽量避免在同一目录中存储太多(我认为是2500多个)文件。但通常,对于文件上传站点,您会在逻辑上对它们进行“分组”,这样您就可以拥有一个子目录。

        4
  •  0
  •   STO    14 年前

    我认为您还需要考虑以下问题:

    • 文件列表将显示给用户,还是用户将使用文件的直接链接操作文件
    • 需要备份吗?
    • 您将使用数据库存储附加信息,还是只使用文件系统?
    • 您的应用程序是否具有任何类型的安全性或权限?
    • 应用程序必须具有什么性能(并发读取数、并发写入数、响应时间、上传/下载速度)?
    • 你需要什么样的搜查吗?
    • 是否需要存储原始文件名?