1-6mil 文件的文件夹结构更好吗?

1-6mil 文件的文件夹结构更好吗?

我正在为一家初创公司做一些开发工作,并被要求负责所服务的所有内容的目录结构以及主机服务器的可扩展性(负载平衡等)。

目前有大约 50 万个文件,但预计会继续增加,每个文件都应该是唯一的,但有些只是同一文件的旧版本。所有文件都将保存在 SQL 数据库中,并包含有关文件的更多信息。每个文件都包含一个标记,标记是它的 id,例如file.coder.project 每个文件都包含一个标记,标记是修订版本,例如:1 或 2 或 14 等

到目前为止,文件一直处于这种结构中(字符串也存储在数据库中):

 File\coder\project\file.coder.project.rev-md5.ext 

(文件编码器和项目实际上并不是片段,只是一个例子)

问题是有些子文件夹会比其他子文件夹更塞,我担心跨多台服务器的复制问题。我一直在考虑将其切换为将其 md5sum 或 sha 的值切割为 3/4 级,然后更新数据库(不是问题,非常简单)

计划的同步过程将是 lsyncd 和 rsync 脚本,因为无论如何数据库都会被复制。

正在寻找其他建议或想法,或者 md5/sha 是否更适合分割文件夹密度?即使完整路径已知,这两种方法是否会影响访问时的文件加载/读取时间?

所有系统都将是 Ubuntu,使用 ext3 或 ext4

答案1

基于哈希的文件存储方法有很多优点,但您必须确保将哈希分割成足够多的块,以使目录不会太大。我记得,对于 EXT3,直接打开一个包含 15,000 个子目录的目录中的特定子目录比打开一个只有 2,000 个子目录的目录要花费更长的时间。不确定 ext4 是否如此。

由于哈希的前几位数字非常独特,因此将哈希分成 5 个部分,其中前 4 个部分是哈希的 3 个字符,最后一个部分大于前 4 个部分,这样可以将第一级目录保持在“非常大”的大小范围内。使用两个 EXT 版本直接访问这种结构中的文件应该非常快。

相关内容