问题
我正在寻找关于本地唯一的GUID替代的探索的反馈,具有以下要求:
为了满足要求,我决定采用 64位无符号整数的形式。它很容易在CPU上使用,对于主键使用很好和很小,半人类可读,仅数字,并且在手动查询时易于复制/粘贴。 (作为反例,BLOB严重阻碍了对大多数SQL数据库的手动查询。)
此外,Percona demonstrates 单调增加值作为主键表现得更好,特别是在插入速度方面,因此这是一个目标特征。
建议的结构
从左到右,最重要的位在左侧
碰撞
在任何时候都有1/1024(~0.1%)的碰撞机会:
限制
有趣的是,我们似乎满足了要求(#2是一个狡猾的要求)。让我们来看看一些限制。
考虑
限制#1和#2必须符合公司的要求。
限制#3似乎在现有的GUID实施中被认为是可接受的,并且是我愿意接受的。
限制#4是一个棘手的问题。这些信息有多敏感? "因此我们每分钟进行10K插入,进入未知数量的表格。"相对数量确实提供了更多的洞察力:"在08:00-09:00之间,活动的时间是一小时前的两倍。"不过,这通常是特定领域的常识。意外的峰值可能会泄漏更多信息。 "因此系统在早上03:00努力工作。"这有多糟糕?从公开自动增量标识符的公司数量来看,我们可能会说它经常是一种改进......但它可能是一个交易破坏者。
我们可以使用(加密)随机位作为处理限制#4的唯一文件,但这会引入第三个碰撞机会:每当系统在一毫秒内生成多个标识符时。生日悖论在那里特别成问题。
如果我们允许时间戳已经在2527中回绕,我们可以释放2位。自私和对后代不敏感,或傲慢地假设我们的代码会被更长时间使用? : - )
还有什么?
我欢迎您错过了我的反馈,改进,想法和限制!你会如何解决这个问题?
答案 0 :(得分:2)
有可能成为那个回应的人#34;你为什么要那样做?" - 我想知道你的潜在业务问题是什么,阻止你使用GUID?
BIGINT,GUID和HashTables ..
我使用BIGINT
作为主键,它可以保持所有顺序,非浮动和快速。这适用于所有内部工作,即在我的存储过程中,在SQL连接等上。然后我有一个带有GUID
的哈希表,它成为外部调用者的起点。
由于我使用表继承,BIGINT
ID可用作哈希表中的顺序主键,因为所有ID都是在整个数据库中都是唯一的(但仍然是顺序的)。然后进一步研究我在哈希表上创建一个包含GUID
的最后几位数字的复合键,然后在这些值上对哈希表进行分区,使每个值分别存储在磁盘上并且仍然是顺序的,然而,我给了我一个自然的方法来索引GUID
我正在查找。
当我最初开始这样做时,我在这里发布了一个操作方法(不包括分区部分):
What is the fastest way to look for duplicate uniqueidentifier in Sql Server?
初步的性能测试对100,000,000条记录的反应很快。
不是你问题的答案,但对某人来说可能值2美分。