本地唯一标识符
问题：当您有一个用于插入数据库的 .NET GUID 时，它的结构如下：
60 bits of timestamp,
48 bits of computer identifier,
14 bits of uniquifier, and
6 bits are fixed,
----
128 bits total
现在我遇到 GUID 问题，因为它是 128 位数字，而我使用的一些数据库仅支持 64 位数字。
现在我不想通过使用自动增量 bigint 值来解决这个困境，因为我希望能够进行离线复制。
所以我想到了创建一个本地唯一标识符类，它基本上是一个缩小到 64 位值的 GUID。
我想出了这个：
day 9 bit (12*31=372 d)
year 8 bit (2266-2010 = 256 y)
seconds 17 bit (24*60*60=86400 s)
hostname 12 bit (2^12=4096)
random 18 bit (2^18=262144)
------------------------
64 bits total
我现在的问题是：时间戳几乎固定在 34 位，留给我 64-34=30 位的主机名 + 随机数。
现在我的问题是： 1）您愿意增加主机名哈希位大小并减少随机位大小，还是增加随机位大小并减少主机名哈希位大小。
2）是否存在将每个字符串减少到n位的哈希算法？ n 理想情况下 = 12 或尽可能接近。
Question: When you have a .NET GUID for inserting in a database, it's structure is like this:
60 bits of timestamp,
48 bits of computer identifier,
14 bits of uniquifier, and
6 bits are fixed,
----
128 bits total
Now I have problem with a GUID, because it's a 128 bit number, and some of the DBs I'm using only support 64 bit numbers.
Now I don't want to solve the dilemma by using an autoincrement bigint value, since I want to be able to do offline replication.
So I got the idea of creating a locally unique identifier class, which is basically a GUID downsized to a 64 bit value.
I came up with this:
day 9 bit (12*31=372 d)
year 8 bit (2266-2010 = 256 y)
seconds 17 bit (24*60*60=86400 s)
hostname 12 bit (2^12=4096)
random 18 bit (2^18=262144)
------------------------
64 bits total
My question now is: The timestamp is pretty much fixed at 34 bits, leaving me with 64-34=30 bits for the hostname + random number.
Now my question:
1) Would you rather increase the hostname-hash bitsize and decrease the random bitsize, or increase the random bitsize and decrease the hostname-hash bitsize.
2) Exists there a hash algorithm that reduces every string to n-Bits?
n being ideally = 12 or as near as possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上，.NET 生成的 GUID 是 6 个固定位和 122 位随机位。
您可以考虑仅使用 64 位随机性，由于位长度较小，因此发生冲突的可能性会增加。它会比哈希工作得更好。
Actually, .NET-generated GUIDs are 6 fixed bits and 122 bits of randomness.
You could consider just using 64 bits of randomness, with an increased chance of collision due to the smaller bit length. It would work better than a hash.
如果空间不是问题，那么为什么不只使用 64 位宽的 2 列，然后使用每个 8 字节将 guid 分成两半，然后将它们转换为 64 位数字并将其存储在 2 列中，那么如果即使您确实需要升级到另一个系统，您仍然是独一无二的，您只需要考虑两列的重新连接。
If space isn't a concern, then why don't you just use 2 columns that are 64bits wide, then split the guid in half using 8bytes for each then just convert those to your 64bit numbers and store it in 2 columns, then if you ever do need to upsize to another system, you'll still be unique you'll just need to factor in the rejoining of the 2 columns.
为什么要自己写？为什么不直接生成一个均匀随机数呢？它会很好地完成这项工作。只需获取前 X 位数字，其中 X 是您想要的任何大小......比如说 64 位。
有关
的信息，请参阅此处 RAND()与 SQL Server 中的NEWID()，这实际上只是对 GUID 与随机数生成器的控诉。另外，如果您需要比更随机的内容，请参阅此处系统.随机。Why write your own? Why not just generate a uniformly random number? It will do the job nicely. Just grab the first X digits where X is whatever size you want... say 64-bits.
See here for info about
RAND()vs.NEWID()in SQL Server, which is really just an indictment of GUIDs vs. random number generators. Also, see here if you need something more random thanSystem.Random.