我想使用GUID(uuid)来命名一个巨大的文件存储中的文件夹.每个存储项都有自己的文件夹和guid.最简单的方法是"x:\ items\uuid\{uuid} ..."
示例:"x:\ items\uuid\F3B16318-4236-4E45-92B3-3C2C3F31D44F ......"
我在这看到一个问题.如果您希望获得至少10,000件物品,可能会有100,000件甚至100万件以上,那该怎么办？我不想把这么多项目(子文件夹)放在一个文件夹中.
我想通过拆分guid来解决这个问题.取2个第一个字符在第一级创建子文件夹,然后取下两个字符,并创建子文件夹.上面的例子是 - >"x:\ items\uuid\F3\B1\6318-4236-4E45-92B3-3C2C3F31D44F ......"
如果guid的前4个字符实际上和预期的一样随机,那么我会在256个文件夹中找到256个文件夹,并且我总是在每个文件夹中找到合理数量的项目例如,如果你有100万个项目那么你得到 - > 1 000 000/256/256 =每个文件夹15.25项
在过去,我已经测试了第一个字符的随机性.(通过vb.net应用程序).结果:传播的项目均匀地退出文件夹.其他人也得出了同样的结论.看看在.NET中创建的Guid的前四个字节是如何均匀分布的？
我想到的可能分裂(例如100万个项目)C1 = GUID的字符1,C2 =字符2等
- C1\C2 \其他GUID - > 16*16*3906(差不多4000还是很多文件夹)
- C1\C2\C3\C4\Guid的其余部分 - > 16*16*16*16*15(不必要的文件夹分割)
- C1C2\C3C4\Guid的其余部分 - > 256*256*15(对我来说是最好的选择吗？)
- C1C2C3\Guid的其余部分 - > 4096*244(第一级的许多文件夹??)
- C1C2C3C4\Guid的其余部分 - > 65536*15(第一级的许多文件夹!)
我的问题是:
谢谢,Mumblic
这与该方法非常相似git这与用于对其对象数据库进行分片的与任何算法一样，都有优点和缺点，但我认为在这种情况下没有任何明显的缺点会超过明确的优点。计算目录结构会产生一些额外的 CPU 开销，但从长远来看，该开销可能明显低于重复搜索包含一百万个文件的单个目录所需的开销。
关于如何做到这一点，这在一定程度上取决于您使用什么库来生成 GUID - 您是否以字节数组（甚至是struct格式获取它们，然后需要将其转换为字符表示形式才能显示或者你把它们放在一个已经格式化的 ASCII 数组中？在第一种情况下，您需要提取适当的字节并自行格式化它们，在第二种情况下，您只需要提取子字符串。
至于将大量子文件夹（甚至文件）放入一个文件夹中，确切的性能特征很大程度上取决于所使用的实际文件系统。有些性能比其他更好，但几乎所有目录都会显示出随着每个目录拥有的条目越多，性能显着下降。