分布式主键 - UUID,简单自动增量或自定义顺序值？

Question

我知道之前已经问过这类问题,但我找不到一个比较我想到的选项.所以我打算在这里发帖,如果有重复,请发帖链接.

这已经结束了一个相当长的帖子,如果你有时间请阅读它,因为问题在最后

编辑2:我已经接受了答案,因为我认为这将是目前最好的解决方案.但是我想我还想回答另外两个问题来回答关于连接数字的问题.它们可以在这里找到:结合两个整数来创建一个唯一的数字和C#中的Concatenate整数.如果我打算尝试对数字进行编码(如下所示,如51122222),我认为这会很有用.虽然在c#中使用像String.Format这样的东西对我的小应用程序来说足够快.

我目前正在尝试找到一种方法来设置使用相同数据库模式的分布式应用程序,并且可以与一个主数据库同步,其他所有数据库也同步.

我目前计划的程序将作为一个相当简单的程序来跟踪信息.第一个版本可能包含两个表:Items和ItemHistory.这是可能字段的示例:

项目
ItemID(PK)？
Name String
Content String

ItemHistory
ItemHistoryID(PK)？
ItemID(FK)？
EventName String
CreatedOn DateTime

我已经列出了字段名称和类型,这个问题是关于PK类型的用途,因此它们缺失.

第一个版本将是一个标准的桌面应用程序,我目前正在计划使用带有WPF前端的C#和用于数据库的SQLite.最后我还想创建一个在我的Android手机上运行的版本.这是分布式部件的用武之地.我并不总是有信号,因此需要应用程序脱机运行并允许再次联机时同步.

以下是我到目前为止关于如何处理ID的想法:

1. 对ID使用UUID,因此不存在合并冲突
2. 使用自动增量字段并在某个增量中为每个版本的应用程序设置起始编号,例如1表示第一个app,10000表示秒,20000表示第三个等
3. 使用带偏移值的自动增量字段以避免冲突而数字之间没有大的间隙(mysql具有auto_increment_increment和auto_increment_offset)
4. 生成我自己的ID,为每个数据库编码一个ID,这样它们就可以拥有自己的自动增量值而不会引起冲突.我发现其他人也有同样的想法:建议ID列使用哪种数据类型？

虽然选项1可行,我过去曾使用它,但我想看看其他选项可能避免UUID问题.我希望有一个解决方案,在调试时更容易阅读并且可以排序.

选项2可行,但它确实限制了记录数量.我知道在我的小应用程序中它几乎不会超过那么多,但我想尝试看看是否有一个解决方案不需要这样的限制.选项3通过使用交替数字来避免限制,但我认为您需要知道要使用多少数据库,否则您可能会填写所有数字.在DB1上使用1的开头和1的增量,在DB2上使用2的开头和2的增量将使用每个数字.您可以使用50作为增量,但之后您只有另一个限制,但现在它可以使用它的应用程序数量.我再次知道它的限制在我的情况下不会受到影响,但在一个突然变得非常受欢迎的应用程序中可能是一个问题.

选项4似乎可以为我解决问题,但我不确定它是否会在实践中起作用.我的一个想法是允许在每个应用程序上设置前缀,然后可以使用自动递增值.例如PC1,PC2用于PC上的记录,也可能是PHONE1,PHONE2等来自Android的记录.这可以工作但是在字符串中使用数字会导致1,1,1,100的排序问题显示在彼此旁边,即使用较少的前导零,然后再次返回到有限数量的记录.

我想知道是否可以使用数字作为DB ID和自动增量.例如,PC = 1,PHONE = 2.那么我们的PC有11,12,13等,第11条记录可能有111条,PHONE则有304条记录为2304条.但我不知道如何做到这一点,或者是否可以轻松完成并且不会导致产生值的额外开销.

在工作中他们使用了类似的编号系统,他们使用类似于51122222的东西.5将引用应用程序的实例,然后是2位数年份,最后是自动递增数字.我还没有得到一个明确的答案,如果我们在一年内超过99999条记录会发生什么.我认为他们可能已经认为它不会发生并且很高兴他们已经计算了风险.

最后一个问题,有没有办法为分布式应用程序创建一个主键系统,允许排序而不强制限制(除了数据类型本身的大小,例如最大整数)？

编辑:这是我打算写的应用程序的更多信息.我想创建一些东西,让我可以存储我可能获得的任何类型的信息,系统将包括标记条目的能力,以便我可以搜索主题.到目前为止,我看到的信息类型可能是关于书籍,DVD,网站等的建议.或者也许是我居住地方的当地提示.一个总体思路是停止将这些信息分散在不同格式的多台计算机/笔记本电脑/手机上.

Answer 1

从广义上讲，有两种方法。

1. 您使用顺序值。这些可以分为几组，交错的，等等。它们是最有效的方法，但需要协作和协调。

2. 您使用随机值（这包括 UID）。这些更简单，但需要更多空间。从“生日冲突”中我们知道，如果您需要存储 N 个值，则必须从（超过）N*N 的范围中选择一个随机密钥 - http://en.wikipedia.org/wiki/Birthday_problem。向后推算，如果用作随机密钥，64 位整数可以容纳大约 32 位数据，即大约 40 亿个值。但这是针对 50% 碰撞的概率而言的。您想要更低的概率，因此实际限制约为 1000 万个条目。

因此，简单来说，如果您有 64 位密钥，则随机方法适用于大约 1000 万个条目，而顺序方法适用于更多条目。无论哪种情况，这可能都超出您的需要。

如果您有 32 位密钥，则随机方法适用于大约 1000 个值（顺序方法适用于大约 40 亿个值，如上所述）。

显然，如果你有一个文本值，那么你需要相应地修改它，但 UUID 被设计为具有“足够”的值无论如何http://en.wikipedia.org/wiki/Universally_unique_identifier

通常，数据库会提供一个顺序 ID，这就是您所需要的。如果没有，64 位随机方法通常是最简单的并且值得额外的空间。