File 使用GUID'；s作为文件夹名称+；分裂

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

我在这里看到一个问题。如果你希望得到至少10000件物品，可能是几十万件或超过一百万件呢。我不想把这么多的项目（子文件夹）在一个文件夹

我想通过拆分guid来解决这个问题。使用前两个字符在第一级创建子文件夹，然后使用下两个字符并创建子文件夹。 上面的示例是-->“x:\items\uuid\F3\B1\6318-4236-4E45-92B3-3C2C3F31D44F…”

如果guid的前4个字符真的像预期的那样随机，那么经过一段时间后，我在256个文件夹中找到了256个文件夹，并且我总是在每个文件夹中找到合理数量的项目 例如，如果您有100万个项目，则每个文件夹将获得-->1 000 000/256/256=15.25个项目

在过去，我已经测试了第一个字符的随机性。（通过vb.net应用程序）。结果：分散的项目在文件夹上均匀退出。 也有人得出了同样的结论。看

我想到的可能拆分（例如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（对于第一级的多个文件夹！）

我的问题是：

• 有人看到这种实现的缺点吗。（方案：*C1C2\C3C4\Guid的其余部分）
• 是否有一些分割guid的标准，或者一种通用的方法
• 如果在一个文件夹中放置了几十万个子文件夹，会发生什么情况（如果可能，我仍然不希望使用任何拆分）

---

谢谢，Mumblic

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

关于如何实现，这在一定程度上取决于生成GUID所使用的库—是以字节数组（甚至是

struct

）格式获取它们，然后需要将其转换为字符表示以显示它，还是以已格式化的ASCII数组获取它们？在第一种情况下，您需要提取适当的字节并自己格式化，在第二种情况下，您只需要提取一个子字符串

---

就在一个文件夹中放置极端数量的子文件夹（甚至文件）而言，确切的性能特征在很大程度上取决于实际使用的文件系统。有些目录的性能比其他目录好，但几乎所有目录的性能都会随着每个目录的条目数的增加而显著下降。

谢谢，这证实了我关于每个文件夹不放置多个文件/子文件夹的想法。我认为CPU开销确实是最小的（nihil）。我从基于字符串的GUID开始。文件系统是NTFS。