Question

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

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

注册用户将获得个人存储空间的固定金额（可能在将来增加）以及访问文件管理器以轻松管理和组织其所有文件。他们还可以将他们的文件设置为私有（除了他们自己不能下载）或公开。

什么是可能的目录设置？

我正在考虑一个“个人”目录，其中包含用户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个用户提供服务，则可能有“其他”文件夹，如果您针对的是100万用户，则可能需要大量“其他”文件夹。如果您也不想限制用户上传的文件数，您可能需要选择扩展每个用户的文件夹。就个人而言，我应用的政策是文件夹中的项目不超过1000个。
搜索引擎优化要求：如果您的服务需要成为搜索引擎优化投诉，则需要能够向用户提供说话名称 - 理想情况下不需要一般分类，例如“个人”/“其他”。您提出的结构可能符合此要求。但是，操作系统限制可能会迫使您进入更技术性的物理结构（例如，块项目ID为3位数，并使用它们来构成您的文件夹和文件结构）。最重要的是，您可以实现一个逻辑结构，然后将ID转换为名称。但是，这种实现意味着通过服务器端脚本进行文件访问，因此需要更多的资源。或者，您可以使用webserver url重写...
一致性+可用性+分区容差：使您的服务成为一种服务可能需要您根据这些设置进行平衡设置。将野兽分成物理和逻辑层有助于实现这一目标。一致性+可用性+分区容差将在逻辑层处理。 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数据库（而不是文件系统）中的键值存储中是一个非常小的步骤，这使得系统可以伸缩。这意味着您将为元数据和结构数据使用sql数据库，为文件内容使用nosql数据库。

顺便说一下。为了覆盖你的公共文件我会假设你有一个ID为1的用户“public”。这最终导致一些数据硬编码，这意味着难看。然而，由于功能“公共”是您应用程序中的一个核心元素，您可以通过以适当的方式记录，从而为不成文的法律做出贡献。或者，您可以添加更多表格并将代码放大，以“干净”的方式覆盖两个不同的事物。

Answer 2

在我看来，实际上您所拥有的文件夹结构并不重要。当然（如前所述），存在操作系统和FS限制，您可能需要花一两分钱进行扩展。

但最后，我建议采用更灵活的存储和检索方法：

好的，文件存储在文件系统的某个地方。
但是：应该有一个数据库，其中包含有关文件的元信息，如类别，标签，描述，修改日期，甚至可能更改修订版。当然，它还会存储文件的物理位置，可能存在也可能不存在于同一台计算机上。
此数据库将针对按这些条件进行搜索进行优化。（根据您的语言/框架，有几个用于语义索引/搜索的库。）

这样，您可以分离逻辑/语义问题的物理问题。如果您或您的用户仍然需要分层方法，您可以随时使用类别逻辑。

最后，您将拥有更灵活，更具吸引力的文件托管服务。

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

2 个答案: