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

Question

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

我发现一个问题。如果您希望获得至少10,000个项目，可能还有几十万或100万个以上。我不想将这么多项目（子文件夹）放在一个文件夹中。

我考虑通过拆分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应用程序）。结果：项目相当均匀地分布在文件夹中。还有其他人得出了同样的结论。请参见在.NET中创建的Guid的前四个字节有多均匀分布？ 我考虑的可能的分裂方式（以100万个项目为例）C1 = GUID的第一个字符，C2 = 第二个字符，等等。

我的问题是：

• 有人看到这种实现方式的缺点吗？（方案：*C1C2\C3C4\Rest of Guid）
• 是否有将Guid分割的标准，或者一般的做法。
• 如果在一个文件夹中放置几十万个子文件夹会发生什么情况（如果可能的话，我仍然不愿使用任何分割）

• C1\C2\其余GUID --> 16 * 16 * 3906（仍然有很多文件夹）
• 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

- Mumblic

Answer 1

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

关于如何实现它，这要取决于您使用哪个库来生成GUID - 您是否以字节数组（甚至是结构）格式获取它们，然后需要将其转换为字符表示形式才能显示它们，还是已经以格式化的ASCII数组获取它们？在第一种情况下，您需要提取适当的字节并自行格式化，而在第二种情况下，您只需要提取子字符串。

至于在一个文件夹中放置极多的子文件夹（甚至是文件），确切的性能特征高度依赖于实际使用的文件系统。有些表现比其他更好，但几乎所有的都会显示出随着每个目录的条目数量增加，性能下降的显著程度。

- twalberg

---

谢谢，这证实了我的想法，即不要在每个文件夹中放置过多的文件/子文件夹。我认为CPU开销确实很小（几乎可以忽略不计）。我从基于字符串的GUID开始。文件系统是NTFS。 - Mumblic