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

Question

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

我在这里看到一个问题。如果您期望获得至少 10.000 件物品，并且可能有 100.000 件或更多，然后是 100 万件，该怎么办。我不想将这么多项目（子文件夹）放在一个文件夹中。

我想通过拆分 guid 来解决这个问题。使用前 2 个字符在第一级创建子文件夹，然后使用接下来的 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 应用程序）。结果：分布在文件夹中的项目均匀退出。 也有人得出了同样的结论。见How evenly spread are the first four bytes of a Guid created in .NET?

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

• C1\C2\Rest of GUID --> 16 * 16 * 3906（几乎 4000 仍然是很多文件夹）
• C1\C2\C3\C4\Rest of Guid --> 16 * 16 * 16 * 16 * 15（不必要的文件夹拆分）
• C1C2\C3C4\Rest of Guid --> 256 * 256 * 15（对我来说是最佳选择？）
• C1C2C3\Rest of Guid --> 4096 * 244（到第一级的许多文件夹？？）
• C1C2C3C4\Rest of Guid --> 65536 * 15（到第一级的许多文件夹！）

我的问题是：

• 有没有人看到这种实现的缺点。 （方案：*C1C2\C3C4\Rest of Guid）
• 是否有一些拆分 Guid 的标准，或执行此操作的一般方法。
• 如果您将几十万个子文件夹放在一个文件夹中会发生什么情况（如果可能，我仍然不喜欢使用任何拆分）

谢谢，Mumblic

Answer 1

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

关于如何操作，这在一定程度上取决于您用于生成 GUID 的库 - 您是否以字节数组（甚至是 struct）格式获取它们，然后需要将其转换为字符表示以显示它，还是将它们放在已经格式化的 ASCII 数组中？在第一种情况下，您需要提取适当的字节并自行格式化，在第二种情况下，您只需要提取一个子字符串。

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