数据库主键 ID 生成战略
系统独一 ID 是我们在设计一个系统的时候常常会碰见的问题,下面介绍一些常见的 ID 生成战略。
● Sequence ID
● UUID
● GUID
● COMB
● Snowflake
最开端的自增 ID 为了实现分库离别的需求,会在自增的前提下,使用不一样起点,但需要做数据库拓展时,极其费事。 比方刚开端时,我们设计某个系统的数据库时,这个数据库中会有 10 个表,那么我们关于每个表的内容都需要不一样的 ID 我们就可以使用不一样不长自增的情势,比方,第一张表的是 1、11、21、31。。。 第二张表是 2、12、22、32。。。 第三张表是 3、13、23、33。。。 第十张表就是 10、20、30。。。 但是这样的问题就是,假如有一天我发明这个系统的 10 张表已经不足用了,我想要再增加一张表,那么这时的主键应当如何分配呢? 别的,假如关于多个数据库的数据但愿合并,但是关于这种简便的生成 ID 方式,反复的大概性很大,所以几乎必然会发生反复这种状况。 明显,假如使用此前的办法的可扩展性会比力差。
比拟自增 ID,UUID 生成独一主键愈加利便(数据量非常大的状况下,存在反复的大概),但由于 UUID 的无序性,机能不如自增 ID,字符串贮存,贮存空间大,查询效力低。关键:使用 uuid 的缺陷是查询效力低啊!
COMB 相关于 UUID,增添了生成 ID 的有序性,插入与查询效力都有所提高。 这篇文章有简便的剖析。
Sonwflake 是 Twitter 主键生成战略,可以看做是 COMB 的一种改善,用 64 位的长整型代替 128 位的字符串。ID 构成:第一位 0 + 41 位的时间前缀 + 10 位的节点标识 + 12 位的 sequence 幸免并发的数字。
第一部分:Sequence ID
数据库自增长序列或字段,最常见的方式。由数据库保护,数据库独一。
长处:
简便,代码利便,机能可以接受。
数字 ID 自然排序,对分页或者需要排序的结果很有帮忙。
缺陷:
不一样数据库语法和实现不一样,数据库迁移的时候或多数据库版本支撑的时候需要处置。
在单个数据库或读写别离或一主多从的状况下,只要一个主库可以生成。有单点故障的风险。
在机能达不到要求的状况下,比力难于扩展。
假如碰见多个系统需要合并或者触及到数据迁移会相当疾苦。
分表分库的时候会有费事。
优化方案:
针对主库单点,假如有多个 Master 库,则每个 Master 库设定的起始数字不一样,步长一样,可以是 Master 的个数。
比方:Master1 生成的是 1,4,7,10,Master2 生成的是 2,5,8,11 Master3 生成的是 3,6,9,12。这样就可以有效生成集群中的独一 ID,也可以大大落低 ID 生成数据库操纵的负载。
第二部分:UUID
npm 治理 https://www.npmjs.com/package/uuid
常见的方式,128 位。可以利用数据库也可以利用程序生成,一样来说环球独一。
UUID 是 128 位的全局独一标识符,平常由 32 字节的字符串表示。它可以包管时间和空间的独一性,也称为 GUID,全称为:UUID ―― Universally Unique IDentifier,Python 中叫 UUID。
它通过 MAC 地址、时间戳、命名空间、随机数、伪随机数来包管生成 ID 的独一性。
UUID 主要有五个算法,也就是五种办法来实现。
(1)、uuid1()
――基于时间戳。由 MAC 地址、当前时间戳、随机数生成。可以包管环球范畴内的独一性,但 MAC 的使用同时带来平安性问题,局域网中可以使用 IP 来代替 MAC。
(2)、uuid2()
基于分布式运算环境 DCE(Python 中没有这个函数)。算法与 uuid1 雷同,不一样的是把时间戳的前 4 位置换为 POSIX 的 UID。实际中很少用到该办法。
(3)、uuid3()
基于名字的 MD5 散列值。通过运算名字和命名空间的 MD5 散列值得到,包管了统一命名空间中不一样名字的独一性,和不一样命名空间的独一性,但统一命名空间的统一名字生成雷同的 uuid。
(4)、uuid4()
基于随机数。由伪随机数得到,有必然的反复概率,该概率可以运算出来。
(5)、uuid5()
基于名字的 SHA-1 散列值。算法与 uuid3 雷同,不一样的是使用 Secure Hash Algorithm 1 算法。
长处:
简便,代码利便。
环球独一,在碰见数据迁移,系统数据合并,或者数据库变动等状况下,可以沉着应对。
缺陷:
没有排序,没法包管趋势递增。
UUID 往往是使用字符串储备,查询的效力比力低。
储备空间比力大,假如是海量数据库,就需要思考储备量的问题。
传输数据量大
不成读。
优化方案:
为理解决 UUID 不成读,可以使用 UUID to Int64 的办法。
第三部分: GUID
GUID:是微软对 UUID 这个标准的实现。UUID 还有其它各种实现,不止 GUID 一种。优缺陷同 UUID。
第四部分: COMB
COMB(combine)型是数据库特有的一种设计思想,可以懂得为一种改善的 GUID,它通过组合 GUID 和系统时间,以使其在索引和检索事有更优的机能。
数据库中没有 COMB 类型,它是 Jimmy Nilsson 在他的 “The Cost of GUIDs as Primary Keys” 一文中设计出来的。\
COMB 数据类型的根本设计思绪是这样的:既然 UniqueIdentifier 数据因毫无纪律可言造成索引效力低下,影响了系统的机能,那么我们能不克不及通过组合的方式,保存 UniqueIdentifier 的前 10 个字节,用后 6 个字节表示 GUID 生成的时间(DateTime),这样我们将时间信息与 UniqueIdentifier 组合起来,在保存 UniqueIdentifier 的独一性的同时增添了有序性,以此来提高索引效力。
长处:
解决 UUID 无序的问题,在其主键生成方式中供给了 Comb 算法 (combined guid/timestamp)。保存 GUID 的 10 个字节,用另 6 个字节表示 GUID 生成的时间 (DateTime)。
机能优于 UUID。
第五部分: Twitter 的 snowflake 算法
snowflake 是 Twitter 开源的分布式 ID 生成算法,结果是一个 long 型的 ID。其中心思想是:使用 41bit 作为毫秒数,10bit 作为机器的 ID(5 个 bit 是数据中心,5 个 bit 的机器 ID),12bit 作为毫秒内的流水号(意味着每个节点在每毫秒可以发生 4096 个 ID),最后还有一个符号位,永久是 0。snowflake 算法可以按照本身项目的需要停止必然的修改。比方预算将来的数据中心个数,每个数据中心的机器数乃至统一毫秒可以能的并发数来调整在算法中所需要的 bit 数。
长处:
不依靠于数据库,灵敏利便,且机能优于数据库。
ID 依照时间在单机上是递增的。
缺陷:
在单机上是递增的,但是由于触及到分布式环境,每台机器上的时钟不成能完全同步,或许有时候也会显现不是全局递增的状况。
六、使用
这个使用起来是真的利便:
npm install uuid --save
然后就可以使用啦!
const uuidv1 = require(‘uuid/v1‘); console.log(‘随机uuid字符串‘, uuidv1());
这样,我们就可以打印出来 uuid 字符串了。 每次的都不一样。
以上就是数据库主键 ID 生成战略的具体内容,更多请关注百分百源码网其它相关文章!