管理大量文件的提示？

关于文件管理和存储在大型项目中,有一些非常好的问题.

在DB中存储图像 - 是还是不？
您会将二进制数据存储在数据库或文件系统中吗？

第一个有一些很好的见解,在我的项目中,我决定采用文件路径,而不是DB路由.

反对使用文件系统的一个主要问题是备份.但在我们的系统中,我们有一个很棒的备份方案,所以我并不担心.

下一个路径是如何存储实际文件.我一直在考虑让文件的位置始终保持静态,并在数据库方面创建一个虚拟目录系统.因此,文件的链接不会改变.

我正在构建的系统将具有一个全局文件管理,因此所有用户都可以访问所有文件.但许多已经走过文件路径的人谈论物理目录大小(例如,如果所有文件都在一个目录中)

所以我的问题是,为这些静态文件创建文件夹有什么技巧或最佳实践方法,或者我根本不应该去虚拟目录路由.

(项目在LAMP堆栈(PHP)上,如果它有帮助的话)

一种方法是为每个文件分配一个唯一的编号,并使用它来查找实际的文件位置.然后,您使用该数字在文件系统中的不同目录中分发文件.例如,您可以使用类似此方案的内容:

/images/{0}/{1}/{2}

{0}: file_number % 100
{1}: (file_number / 100) % 100
{2}: file_number

我前段时间遇到了一个托管大量文件的网站.我们所做的是采用GUID(也是文件的主键字段)(例如BCC46E3F-2F7A-42b1-92CE-DBD6EC6D6301)并存储如下文件:/ B/C/C/BCC46E3F-2F7A-42b1 -92CE-DBD6EC6D6301/FILENAME.EXT

这有一定的优点:

您可以在多个服务器上扩展文件服务器(并为每个服务器分配特定目录)

您不必重命名该文件

您的目录保证是唯一的

希望这可以帮助!

为了避免在单个目录中创建过多的条目,您可能希望基于文件名的片段创建目录.因此,例如,如果您有一个名为d7f5ae9​​b7c5a.png的文件,您可能希望将其存储在media/d7/f5/d7f5ae9​​b7c5a.png中.如果您的文件名都是十六进制的,那么这会将单个目录中的条目数限制为256,直到最终级别.