5

我想使用 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 应用程序）。结果：分布在文件夹中的项目均匀退出。也有人得出了同样的结论。请参阅在 .NET 中创建的 Guid 的前四个字节分布有多均匀？

我想到的可能拆分（以 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\Guid 的其余部分）
  • 是否有一些拆分Guids的标准，或者这样做的一般方法。
  • 如果您将几十万个子文件夹放在一个文件夹中会发生什么（如果可能，我仍然不喜欢使用任何拆分）

谢谢， 穆布利克

4

1 回答 1

3

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

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

至于将极端数量的子文件夹（甚至文件）放在一个文件夹中，确切的性能特征高度依赖于使用的实际文件系统。有些性能比其他性能好，但几乎所有目录的条目越多，性能就会显着下降。

于 2012-12-12T15:55:43.050 回答