使用GUID作为文件夹名称+拆分

Question

我想使用GUID（uuid）在巨大的文件存储中命名文件夹。每个存储项都有自己的文件夹和guid。 最简单的方法是“x：\ items \ uuid \ {uuid} ...”
例如：“x：\ items \ uuid \ F3B16318-4236-4E45-92B3-3C2C3F31D44F ...”

我在这里看到一个问题。如果您希望获得至少10,000件物品，可能会有100,000件甚至100万件以上，那该怎么办？我不想将这么多项目（子文件夹）放在一个文件夹中。

我想通过拆分guid来解决这个问题。取2个第一个字符在第一级创建子文件夹，然后取下两个字符，并创建子文件夹。 上面的例子是 - ＆gt; “×：\项目\ UUID \ F3 \ B1 \ 6318-4236-4E45-92B3-3C2C3F31D44F ...”

如果guid的前4个字符实际上和预期的一样随机，那么我会在256个文件夹中找到256个文件夹，并且我总是在每个文件夹中找到合理数量的项目 例如，如果您有100万件商品，那么您将获得 - ＆gt; 1 000 000/256/256 =每个文件夹15.25项

过去我已经测试了第一个字符的随机性。 （通过vb.net应用程序）。结果：传播的项目均匀地退出文件夹。 其他人也得出了同样的结论。见How evenly spread are the first four bytes of a Guid created in .NET?

我想到的可能分裂（以100万项为例） C1 = GUID的字符1，C2 =字符2等

  

  
• C1 \ C2 \其他GUID - ＆gt; 16 * 16 * 3906（差不多4000个仍然是很多文件夹）
  
• C1 \ C2 \ C3 \ C4 \ Guid的其余部分 - ＆gt; 16 * 16 * 16 * 16 * 15（不必要拆分文件夹）
  
• C1C2 \ C3C4 \ Guid的其余部分 - ＆gt; 256 * 256 * 15（对我来说是最佳选择？）
  
• C1C2C3 \ Guid的其余部分 - ＆gt; 4096 * 244（第一级的许多文件夹??）
  
• C1C2C3C4 \ Guid的其余部分 - ＆gt; 65536 * 15（第一级的许多文件夹！）
  

我的问题是：

• 有没有人看到这种实现的缺点。 （计划：* C1C2 \ C3C4 \ Guid的其余部分）
• 是否存在拆分Guids的一些标准，或者这样做的一般方法。
• 如果您在一个文件夹中放置了几十万个子文件夹会发生什么情况（如果可能的话，我仍然不想使用任何拆分）

谢谢，Mumblic

Answer 1

这与用于分片对象数据库的方法git非常相似（尽管使用SHA1哈希而不是GUID ...）。与任何算法一样，有利有弊，但我不认为在这种情况下有任何重大缺点会超过明确的专业人士。计算目录结构有一点额外的CPU开销，但从长远来看，这个开销可能远远低于重复搜索一百万个文件的单个目录所需的开销。

关于如何做，它取决于你用来生成GUID的库 - 你是否以字节数组（甚至是struct）格式获取它们然后需要转换一个字符表示，以显示它，或者你在已经格式化的ASCII数组中得到它们？在第一种情况下，您需要提取适当的字节并自行格式化，在第二种情况下，您只需要提取子字符串。

至于将极端数量的子文件夹（甚至文件）放在一个文件夹中，确切的性能特征在很大程度上取决于所使用的实际文件系统。有些表现比其他表现更好，但是每个目录的条目越多，几乎所有表现都会显着降低性能。