UUIDs早已成为许多云和大数据应用中最受欢迎的标识符格式。这些标识符广泛应用于需要唯一标识数据记录、资源和实体的许多应用程序中：数据库中的记录、资源ID、会话ID、事务ID、对象存储等。
对于非开发者来说： UUID 是一个带有短横杠分隔的一长串的数字和字母（模式：8-4-4-4-12），看着就让人头晕，比如**1e7cacb7-af9f-4f07-88fd-45370c25ab62**
开发人员 🛠️ 🚀 现在正 使用 其他 ID 生成方法，这些方法可能更符合他们的需求。
虽然UUID被广泛使用（仍然是最常用的ID类型），但它们较大的体积和缺乏自然排序（至少在某些版本中——见下文）会导致在大规模使用时性能、存储和索引上的效率低下。
此外，依赖于带有时间戳的或可排序的字母数字ID（如KSUID或ULID）的系统的越来越受欢迎，使这些选项更加吸引人。
我们将会看看一些可用的替代选项、它们的使用方法和优缺点。我不会告诉你们该用哪一个，因为这真的要看你们的使用场景。即使是简单的内部测试，使用顺序ID可能也足够了（虽然通常不建议使用）。
更新啦！(2024年11月4日更新)注意：发布之后，一些用户（见评论） 指出你可以使用其他 替代或较新的 UUID 版本，这可能会解决之前对它的批评问题。这一点确实有道理。
我还添加了一些关于其他UUID版本的信息。
当然，具体还要看你的应用场景。 主要目的只是展示非UUID的一些替代选择，并没有特别强调哪一个更好（这一点我在文章中也提到过了）。但大家的反馈非常有用且信息量大，真的非常感谢！
这里有一些有用的评论（请参阅评论部分中的作者完整评论），我将会更新文章的某些部分
- “如果某个数据库系统有自己的特定ID，请使用它！” (Jarrod Roberson)
- “用 UUID v7 或 v8 替代 UUID v4，性能更佳且可排序 :)" (Jeremy Teichmann)
- “直接用 UUIDv1、UUIDv6（最好是 UUIDv7）就行了。” (Miles Elam)
- “如果能包含不同版本的 UUID，例如 v7，会更好。” (Jean-Paul de Jong)
- “CUID 已因一些非常合理的原因被弃用，现在使用 CUID2 作为不透明标识符是最优选择。” (Jarrod Roberson)
- “给使用 MongoDB 的人一个小提示。请使用 ObjectIds。千万不要用其他任何 ID 替代它们，特别是不要用连续的 ID。” (Scott Molinari)
更多关于UUID的讨论：戳这里看 更多关于UUID的讨论：**** 该用哪个UUID版本？
换句话说，UUID 有不同版本。我不会详细介绍每个，但知道有其他选择也不错。
- v1（基于时间）: 由当前时间戳和机器MAC地址组成的组合，具有唯一性但可能会暴露硬件信息。
- v2 (DCE 安全): 类似版本1，但包含POSIX UID和GID信息，适用于需要用户或组识别的应用。
- v3 (基于名称的，MD5): 使用MD5算法对命名空间标识符和名称进行哈希，对于相同输入数据生成一致的UUID。
- v4 (随机): 使用随机数，提供简单性并降低重复概率。
- v5 (基于名称的，SHA-1): 与版本3类似，但使用SHA-1哈希算法，提供更安全的哈希函数，用于从名称生成UUID。
- v6 (有序的时间基于): 重新排列版本1的UUID，以改进数据库索引，将时间戳放在最显著的位上，便于按时间顺序排序。可能适合需要数据库键排序的一些情况。
- v7 (Unix 纪元时间戳): 在最显著的48位中编码具有毫秒精度的Unix时间戳，后面跟随随机数据，确保唯一性和时间排序。
- v8 (自定义): 保留用于自定义实现，允许在UUID结构中包含应用程序特定的数据。
我们先来看看UUIDv4，这是UUID标准的一个较新版本。 它是一个128位的值（16个字节），其中122位是随机生成的，剩下的位包含版本和变体信息。
比如: 1e7cacb7-af9f-4f07-88fd-45370c25ab62
https://www.npmjs.com/package/uuid （也可以使用 node.js 中的 crypto 模块）
- 维基百科：全局唯一识别码
UUIDv4的优点包括:
- 高度的独特性，由于其拥有122位的随机空间，使得发生碰撞的可能性极低。
- 广受认可的标准，使其在许多平台、数据库和编程语言中得到广泛支持。
- 不需要系统之间的协调，意味着UUIDv4可以在分布式系统中独立生成，而无需担心发生碰撞。
- 适用于众多不同机器或服务独立生成ID的环境。
- UUID在URL或文件中传递时不会遇到编码问题。
- Python的标准库和Node.js的crypto库都支持生成UUID。
UUIDv4的一些缺点:
- 对于某些应用场景来说，UUIDv4太大且没有必要，导致存储和带宽使用增加。
- 在需要索引记录的数据库中可能效率不高，因为 UUIDv4 不支持自然排序。更新：你可以通过 UUIDv6 获得排序。
- UUID是一串长且看起来随机的字符串，人类阅读和记忆起来都不容易。
- 虽然 UUIDv4 非常随机，但如果随机数生成器较弱或可预测，其唯一性可能会受到影响，从而可能导致潜在的冲突。
- 在更容易保证唯一性的系统中（例如单个数据库内部），使用 UUIDv4 可能显得过于冗余且效率不高，与简单的 ID（例如自动递增的整数）相比。
如下是9种以上替代UUID用于生成软件系统中唯一标识符的方案及其优缺点：
- 自动递增ID（顺序ID）
- Snowflake ID（Twitter Snowflake）
- KSUID（K-排序唯一标识符）
- ULID（全局唯一有序标识符）
- NanoID（小型随机ID）
- 基于随机哈希的ID（如SHA-256或MD5）
- ObjectID（MongoDB ObjectID）
- CUID（抗碰撞唯一标识符）
- 其他（较少见的）
自增ID（自增编号）是数值，每次添加新记录时自动加一，通常用于关系数据库中。
这个替代方案仅供参考，许多人在学习简单实现时会接触到……但这很可能不是你需要的，通常认为这样做是不好的，除非你有特定的应用场景。
这些原因说明了为什么正规的生产系统不采用连续的标识符（连续ID）。
示例: 56482
好的地方：
- 实现简单且易于理解。
- 存储占用少（较小的数值数据类型）。
- 索引方便，从而提升数据库性能。
- 适用于小型系统或数据库，这些系统或数据库更关注顺序而不需要全局唯一标识符，例如关系数据库中的主键。
不足的地方：
- 不适合用于分布式系统，因为这可能会导致冲突。
- 可预测性高，可能带来安全风险（如可猜测的ID）。
- 需要数据库协调来避免分片系统中的重复数据。
参阅以下链接的文章，看看这种方法存在的一些问题。
你还在用连续ID作为主键吗？这里有三个理由告诉你为什么不应该这么做jefferey-cave.medium.com 2. Snowflake ID（推特雪花ID）一种生成分布式ID的算法，通过结合时间戳、机器ID和序列号生成64位唯一ID。
一个由时间戳、机器标识和序列号构成的64位唯一编号。
示例:5643574219214851220
好处：
- 分布式且可扩展的， 适合分布式系统。
- 时间戳 组件提供 近似的时间顺序。
- 生成具有 跨系统唯一性保证 的 ID。
- 如果你需要可扩展、按时间排序的唯一 ID，尤其是在社交媒体或消息应用中
不足：
- 实现起来稍微比简单的ID复杂一些。
- 基于时间戳的ID可能会泄露时间信息。
- 需要细心设置机器标识符以避免冲突。
你可以在这里查看有关雪花ID的信息：[https://zh.wikipedia.org/wiki/Snowflake_ID 或 https://en.wikipedia.org/wiki/Snowflake_ID（英文版）]
NPM: https://www.npmjs.com/package/snowflake-id (一个用于生成Snowflake ID的NPM包)
PyPI：Python 包指数 https://pypi.org/project/snowflake-id/ （点击链接访问）
☁️ ⚡️ 限时优惠！ 我在 SystemsArchitect.io 商店 有一些 PDF，其中这本非常适合用于检查清单和细节，涵盖大数据技术的 ✅ AWS 云架构师最佳实践，涵盖 AWS Kinesis, Athena, Glue, Glue Studio, Lambda, EMR, AWS Batch, Amazon S3, DynamoDB, Amazon RDS, Aurora, AWS Redshift, AWS Data Exchange, AWS Data Pipeline, QuickSight, OpenSearch, MSK, AWS Glue DataBrew, AWS Lake Formation, Step Functions 等。
点击图片或链接了解更多信息关于云审计和大数据。
3 KSUID（K-排序可唯一标识符）KSUIDs 是一种包含时间戳的 UUID 版本，可以按创建时间排序。
一个由时间戳和随机生成的位组成的字符串，确保k排序性，长度为27字符。
NPM包ksuid：https://www.npmjs.com/package/ksuid
PyPI: , 或者可以访问 https://pypi.org/project/svix-ksuid/ 和 https://pypi.org/project/ksuid/
示例1avvTqCSFGnD5LDc4hN6GFFCAXD
好处：
- 按时间排序的同时保持全局唯一性。
- 简洁高效的表示形式。
- 如果您需要更好时间排序的唯一标识符以及独特的用户生成内容标识。
不足：
- 仍然大于基础数字ID。
- 相比连续ID，稍微复杂一点。
- 如果隐私是一个顾虑，这种标识可能会暴露时间戳信息。
🥰 谢谢阅读我的文章……喜欢的话，点个赞、关注下，再分享一下，谢谢！🚀
4. 全局唯一且可排序的标识符（ULID）类似于 KSUID，ULID 是一种结合时间戳和随机数据以保证唯一性的 ID 格式，能够按字典顺序排序。
这是一串基于时间和随机性的组合，确保按照字典顺序排列的26个字母数字的字符串。
NPM: https://www.npmjs.com/package/ulid (包)
PyPI: https://pypi.org/project/python-ulid/ 你可以在这里找到它。
比如说:**22H1UECHZX3FGGSZ7A9Y9BVC1**
好的地方 ：
- 可以根据创建时间来排序。
- 比UUID更易读。
- 适用于大规模的分布式系统。
- 在需要字母顺序排序以及全局唯一标识符的情况下，比如在电子商务或文档管理等系统中。
不足
- 与 KSUID 类似，时间戳也是公开的，这可能不利于隐私保护。
- 生成稍微复杂一点，相比 UUID 来说。
NanoID 是一个小巧、快速且安全的 UUID 替代方案，设计上便于用于 URL，并且长度可定制。
一个短的、随机的字符串，适合URL，长度和字符集可调。（字符串 string）
npm: https://www.npmjs.com/package/nanoid （NPM，一个npm包管理网站）
PyPI: https://pypi.org/project/nanoid/ 项目页面
例子: **E9SxJKL8_K5emHi2B-noZ**
优点：，
- 小巧的尺寸和可自定义的长度。
- URL安全且非连续性，这提高了安全性。
- 快速生成，占用存储空间更少且比UUID占用更少的存储空间。
- 非常适合前端应用或类似公共网址或会话标识符等需要短、URL友好的唯一标识符的场景。
不足：
- 可自定义的大小可能会导致更小的命名空间和潜在的冲突问题。
- 相比之下，在大型企业系统中不如UUID流行。
使用如SHA-256和MD5等哈希函数生成随机字符串，从而创建唯一的标识符。
一个通过哈希（例如，时间戳和用户数据组合）生成的固定长度的32或64字符的字符串。
例如：
Node.js 的内置功能：https://nodejs.org/api/crypto.html
Python自带的hashlib库
示例（SHA-256）: 1d214892da28032151d0e36c2dc6291673603d1d61ab3dd32a11e2321d1542f2
好处：
- 可以生成非常大的唯一空间，几乎不产生冲突。
- 可以使用输入数据（如用户信息）生成唯一的确定性ID。
- 使用加密哈希函数（如SHA-256）时，安全性有保障。
- 如果你需要加密的唯一性，例如用于文件哈希以进行去重，或当标识符必须跨系统保持一致时。
缺点:
- 占用更大的存储空间，与数字ID相比。
- 生成和验证的速度较慢，由于计算复杂性。
- 根据不同的哈希函数，可能无法完全避免碰撞。
MongoDB的ObjectID（BSON中的二进制JSON）是一个12字节的唯一标识，包含有时间戳（时间戳）、机器标识符、进程ID（进程ID）和一个计数器（计数器）等信息。
NPM: 一个包管理器，可以在 https://www.npmjs.com/package/bson-objectid 找到
PyPI: https://pypi.org/project/pymongo/ (一个用于管理Python包的仓库，其中包含了pymongo这个库)
示例: 102e1b71bcd16cd721434331
一个包含时间戳、机器ID和进程ID的24位的十六进制字符串。
优点：
- 提供独特的分布式ID，几乎不需要协调工作。
- 包含时间戳，允许按创建时间排序。
- 仅12字节，比UUID更节省存储空间（12字节（bytes），比UUID更小）。
- 优化用于像MongoDB这样的NoSQL数据库，特别适合需要带时间戳的唯一ID的文档存储系统中。
不足：
- 显示创建时间，这可能不那么利于保护隐私。
- 与MongoDB绑定；在其他系统中使用时可能需要一些调整。
- 相比基本的数字ID稍微复杂一点。
Cuid2 被设计用于减少分布式系统中发生冲突的可能性，提供一个既安全又易读且不易冲突的 URL ID。
https://www.npmjs.com/package/@paralleldrive/cuid2
一个以 "c" 开头，由 base-36 编码的时间戳和随机数构成，以确保重复几率很低的字符串。
优点：
- 高碰撞容错性，即使在分布式系统中也是如此。
- 易读和URL友好。
- 包含时间戳和随机计数器来确保唯一性。
- “水平可扩展：在多台机器上生成ID，无需协调工作。” — 上方链接的npm库
- “离线兼容：无需网络连接就可以生成ID。” — 上方链接的npm库
- 为了获得稳健且唯一的标识符，降低碰撞风险，例如在分布式数据库或微服务中。
不足：
- 比NanoID或Snowflake等简单格式的ID要长。
- 能够暴露一些细节（如时间戳和机器信息）。
- 与顺序或数字ID相比，生成起来更复杂。
这里还有一些我在研究中找到的选项，但这些相对少见。如果你还没找到最适合你情况的ID，或许可以考虑一下：
Flake ID ：包含时间戳、机器标识符和序列号。如果您需要独一无二且按时间排序的标识符，以便更容易进行排序和调试。
示例：304857642123456
时间戳ID：通常是将Unix时间戳与一些随机位或其它唯一数据拼接而成。适用于需要按时间顺序排列的情况，如日志记录或事件跟踪。
例子：16972283871234567890（将时间戳1697228387与一个随机后缀结合）
顺序GUID (SQL Server)：适合索引的GUID，通常包含一个按照时间顺序排列的部分。当需要GUID且有序索引能提高数据库性能时使用。
例如：6E4F6A80-4F64-11EE-B4FA-0242AC120002
ShortID : 生成一个紧凑、唯一的字母数字字符串，通常用于缩短URL或创建用户友好的标识符。
例子 : 2K5czP8
ZUID（零宽唯一标识符）：使用零宽字符（例如，零宽空格），这些字符是不可见的，但可以用于确保唯一性。如果你需要用于追踪或元数据的不可见标识符，而这些标识符不会影响视觉布局。
示例：内部看起来像 \u200B\u200C\u200D
好了，结束了！我们详细讨论了UUID的替代选项，希望这能帮助你更好地了解这个对某些人来说不太熟悉的主题，从而开发出更棒的应用。
🥰 感谢阅读我的文章……如果你喜欢，请点个赞，关注我并分享这篇文章，谢谢支持！🚀
[云审计 2合套 - 云审计入门 + 云审计：大数据/分析1. 大数据/分析领域的云审计最佳实践...
这份云最佳实践指南旨在帮助您轻松搞定许多任务…
store.systemsarchitect.io](https://store.systemsarchitect.io/l/bundle-essentials-big-data?source=post_page-----9410f194b4d1--------------------------------)
图片来源：主要图片由AI生成，其他截图
关于我：的一些信息我是一名云架构师，资深开发者和技术主管，喜欢用创新的方法解决高价值的难题。
我随时愿意讨论项目。 如果你需要帮助、有机会合作或只是想聊天，可以通过csjcode@gmail.com与我联系。
我有超过20年的软件开发经验，既有在企业如NIKE和最初的MP3.com工作，也有在创业公司如FreshPatents、SystemsArchitect.io、API.cc和Instantiate.io工作。
我的经验涵盖从云电商、API设计/实现、无服务器、开发中的AI集成、内容管理和前端UI/UX架构、登录/认证。我做技术演讲、教程，并分享架构软件的文档。此外，我之前曾获得AWS解决方案架构师认证。
Cloud Ebook Store — 浏览云架构与工程领域的电子书，例如“云指标”（超过800页）和“云审计”（超过800页）等 — https://store.systemsarchitect.io
我的网站是：https://systemsarchitect.io/
最近我在研究 Instantiate.io，一个利用AI帮助初创企业规划的价值创造工具。此外，我还写了一本关于云指标的参考手册。
此外，作为一名热衷于区块链的人，我积极参与开发应用于创新的Solana区块链生态系统的应用程序。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
