4

网络和 StackOverflow 上有大量关于 GUID 的信息。关于独特性的问题确实无穷无尽。这不是关于 2^128 uniqueness 的问题。

我的问题是确定第一部分的随机性，特别是 GUID的前四个字节在 .NET 中。根据研究，它应该是时间戳的最低有效 32 位。但是时间戳是如何转换的呢？这是多么随机？

有谁知道第一部分是如何由 .NET 构建的，是否真的均匀分布在 4 个字节中？

时间戳如何用于构造前 32 位？

时钟精度如何影响它？

Microsoft 是否尝试过确保前 4 个字节是随机的？

为什么：大容量 Guid 使用在前 4 个字节中有 2 个主要业务案例，用于良好的随机 guid。如果每个新 GUID 的分布均匀，则可以根据需要的分区数量使用基于前 1、2、3 或 4 个字节的表分区。我见过一个 20 亿行的表，每天有 1000 万次插入，其中 128 个分区使用前 2 个字节作为分区键。注意在 DB2 下，必须使用密钥的第一部分。引用 DB2 DBA。这大大提高了数据库的吞吐量。第二种用途是批处理作业并行键分配。如果您知道您有大约 N 行作为批处理任务，则可以将键范围分配给并行作业。如果没有同构拆分，调度程序必须首先计算每个作业的 from 和 to 键。如果这意味着读取 1 亿条数据并在内存中管理它们只是为了调度工作，前 x 分钟因作业调度而丢失。在我看到的示例中，大约需要 15 分钟。因此，有两个很好的理由使用并希望均匀分布 GUId。

SAP Banking 系统实际上引入了一个自定义 GUID 例程来解决 GUID 第一部分中缺乏随机性的问题。对于可以访问 SAP 银行系统的用户，函数是 BANK_DISTRIBUTED_ID_CREATE。代码中的注释解释了他们为什么这样做。那些可以访问 SAP 支持的人有一个注释 496904 解释了为什么他们认为有必要修复 guid。

在自定义例程之前，AIX 下的 GUID 中存在明显的偏差。C++ 内核。唯一是的，但是随机的，尤其是第一部分，显然不是。

更新：当我决定编写一个程序进行调查时：Windows XP 上的 .net 4，戴尔 Intel Core 2 Duo。

如果有兴趣，我已经包含了测试程序结果。使用生成的指南

var G = Guid.NewGuid();

结果在 SAMPLE 100,000,000 guid 上看起来不错。（更大的集仍在运行）出于我的目的，看起来分布均匀，足以假设 OK。

Byte 0: with Value 6A was least frequent : 389140 times
Byte 0: with Value 58 was most  frequent : 392241 times
Byte 1: with Value 25 was least frequent : 388905 times
Byte 1: with Value B3 was most  frequent : 392552 times
Byte 2: with Value D2 was least frequent : 389114 times
Byte 2: with Value CC was most  frequent : 391984 times
Byte 3: with Value 66 was least frequent : 388744 times
Byte 3: with Value 16 was most  frequent : 392838 times

编辑：根据评论添加背景研究

我在 AIX 系统上看到了 GUID 示例。我们已经有超过 20 亿。它们分布不均。2 个字节有明显的偏差。因此，引入了一个特殊的例程来生成同质的 guid。我想知道.net 是否有类似的偏差

4

1 回答 1

1

Guids 似乎分布均匀。对 10 亿个 Guid 的测试看起来不错。如果考虑前 4 个字节。这意味着它们对分区很有用，并且可以粗略推断而不是从 Db 中读取范围。

于 2012-12-05T12:49:48.390 回答