directory - 在线文件存储服务的目录设置

Question

我正在开发主要使用PHP和MySQL的在线文件存储服务，用户可以在其中上传最大10到20 GB的文件。

未注册用户将能够上传文件，但不能在个人存储空间中上传文件，而只能在其中存储未注册用户的所有文件上传目录。

注册用户将获得固定数量(将来可能会增加)的个人存储空间，并可以使用文件管理器轻松管理和整理其所有文件。他们还可以将自己的文件设置为 private (除了自己之外，其他任何人都不能下载)或公开。

什么是可能的良好目录设置？

我正在考虑一个“个人”目录，该目录将包含带有用户ID的文件夹，作为每个注册用户的文件夹名称。

在个人目录旁边，将有一个“其他”文件夹，其中仅包含未注册用户上载的每个文件。

这两个都将包含上载的文件，每个文件的相应行ID(来自数据库中的文件表)均作为文件名。

ROOT
  FOLDER uploads
    FOLDER personal
      FOLDER 1
        FILE file_id1
        FILE file_id2
             (...)
      FOLDER 2
        FILE file_id3
        FILE file_id4
             (...)
        (...)
    FOLDER other
      FILE file_id5
      FILE file_id6
           (...)

这是我第一次处理这样的情况，但是到目前为止，我仍然可以想到这个概念。任何建议也欢迎!

Answer 1

基本上，您需要解决以下主题:

安全性:根据您的描述，目前还不清楚谁被允许读取文件。如果始终是“每个人都读懂所有内容”，则可以在Web服务器虚拟服务器中设置文件结构。否则，您可以在“隐藏”区域中设置文件夹结构，并且只能通过服务器端脚本(例如，按需复制)进行访问。安全的方法占用了更多资源，但为设置技术上经过优化的文件夹结构打开了空间。

操作系统限制:每个操作系统在每个文件夹中限制项目和/或文件的数量。限制的实际数字取决于文件系统的操作系统特定配置。如果我没记错的话，有些LINUX设置支持每个文件夹32000个项目。最终，这个例子并不重要。但是，重要的事实是，您的利用率计划不会超出服务器上的限制。因此，如果您打算向10个用户提供服务，则可能会有一个“其他”文件夹；如果定位到一百万个用户，则可能需要很多“其他”文件夹。如果您也不想限制用户上传的文件数量，则可能需要选择扩展每个用户的文件夹的选项。就我个人而言，我应用的策略是文件夹中的项目不能超过1000个。

SEO要求:如果您的服务需要SEO投诉，则它需要能够向用户显示语音名称-理想情况下，无需常规分类，例如“个人” /“其他”。您建议的结构可能满足此要求。但是，操作系统的限制可能会迫使您进入更具技术性的物理结构(例如，块项ID变成3位数字，然后使用这些数字来构成您的文件夹和文件结构)。最重要的是，您可以实现一个逻辑结构，然后将ID转换为名称。但是，这种实现方式意味着通过服务器端脚本进行文件访问，因此需要更多资源。另外，您也可以使用网络服务器的网址重写...

一致性+可用性+分区容限:要使服务成为服务，可能需要您根据这些要求进行平衡设置。将野兽分为物理层和逻辑层很有帮助。一致性+可用性+分区容限将在逻辑层处理。 http://en.wikipedia.org/wiki/NoSQL可能是您前进的方法。 http://en.wikipedia.org/wiki/CAP_theorem有关该主题的详细信息。

=====================更新

通过这些注释，我们现在知道您将元数据存储在关系数据库中，具有物理层(磁盘上的文件)和逻辑层(通过php脚本进行访问)，并且物理文件/文件夹层基于ID。

这为将所有结构上的注意事项完全移到关系数据库中提供了空间，并可能从一开始就改善了物理层。因此，这是我将创建的sql数据库表:

 ======
 users
 ======
 id (unsigned INT, primary key)
 username
 password
 isregisteredflag
 ...any other not relevant for the topic...

 ======
 files
 ======     
 id (unsigned INT,primary key)
 filename
 _userid (foreign key to users.id)
 createddate
 fileattributes
 ...any other not relevant for the topic...

 ======
 tag2file
 ======
 _fileid (foreign key to files.id)
 _tagid (foreign key to tag.id)

 ======
 tags
 ======
 id  (unsigned INT,primary key)
 tagname

由于此结构允许您从用户ID派生文件，也可以从文件中派生userID，因此您不需要将该关系存储为文件夹结构的一部分。您只需在物理层files.id上命名文件，这是数据库生成的数字值。由于ID是由日期数据库生成的，因此请确保它们具有唯一性。现在，您还可以使用标签，为用户提供更丰富的分类体验(如果您不喜欢标签，也可以在数据库中添加文件夹)。

注意第4点对您的设计有很大影响。如果您在设置完所有内容后都小心翼翼，则可能会加倍努力。由于一切都可以通过数字ID构建文件，因此，将物理文件存储在no-sql数据库(而不是文件系统)中的键值存储中非常简单，这使您的系统可扩展为 hell 。这意味着您将使用一个用于元数据和结构数据的sql数据库和一个用于文件内容的nosql数据库。

顺便说一句。覆盖您的 public 文件，我假设您有一个ID = 1的用户“public”。这最终导致某些数据硬编码很丑陋。但是，由于“ public ”功能是应用程序中的核心元素，因此您可以通过以适当的方式进行记录来为不成文的法律做出贡献。或者，您可以添加更多表并以“干净”的方式扩展代码以覆盖两个不同的内容。