请注意,虽然类似于它与Storing a million images in the filesystem不太相似.我正在寻找一种方法来帮助使理论概述更通用.
假设
>我有’一些’初始文件数.这个数字是任意的,但很大.说500k到10m.
>我已经考虑了支持这种努力所需的底层物理硬件磁盘IO要求.
换一种方式
随着时间的推移,这家商店将会增长.我想在当前表现和我的需求增加之间取得最佳平衡.说我的存储空间增加一倍或三倍.我需要能够满足当前需求和预计的未来增长.我需要提前计划,而不是牺牲太多的当前表现.
我想出了什么
我已经在考虑使用每多个字符的哈希分割来分割多个目录中的内容并使树保持均匀,非常类似于上述问题中的注释中所述.它还避免了重复文件,这些文件随着时间的推移会很关键.
我确信初始文件夹结构会根据我概述的内容而有所不同,具体取决于初始规模.据我所知,这里没有一个适合所有解决方案.以实验方式开展工作会非常耗费时间.
在开发过程中我问了a similar question to yours but on SA
我在处理大量小文件时做了很多计算,并发现命名文件(假设它们可以是任何东西)由uuid并将它分成3级深度足以满足我的需求.
从内存中我使用前3个字母组成顶级,然后是下一个3来形成级别2,然后使用整个uuid作为文件名.
我的计算基于我想要的文件数量和每个驱动器存储的数据量以及文件系统类型的限制.
对于UUID,如果使用十六进制版本,则得到A-Z,a-z,0-9,如26 26 9或61.对于3级深度,即61 * 61 * 61 = 226,981.我认为226k目录组合是充足的.对于XFS,这很好.但对于NTFS,我不确定.所以你最好找出真正的限制.只需通过打开资源管理器列出许多目录,可能会导致服务器稍微磨损.因此,您可能想要提出一个在顶层没有尽可能多的文件夹的方案.也许使用一个字母,深入4级或其他东西.
