文章摘要
UUIDv47结合了UUIDv4的隐私性和UUIDv7的性能优势，旨在提供更高效且安全的唯一标识符生成方案。
文章总结
GitHub 项目：UUIDv47 - 结合 v4 隐私与 v7 性能
项目简介： UUIDv47 是一个开源项目，旨在结合 UUIDv4 的隐私特性和 UUIDv7 的性能优势。通过使用 SipHash-2-4 算法对 UUIDv7 的时间戳字段进行掩码处理，UUIDv47 可以在数据库中存储可排序的 UUIDv7，同时在 API 边界输出类似 UUIDv4 的标识符。
主要特点： 1. 数据库友好：UUIDv7 具有时间排序特性，有助于提高索引局部性和分页效率。 2. 外部中立：输出的 UUIDv4 外观隐藏了时间模式，对外部系统和客户端保持中立。 3. 安全性：使用 SipHash-2-4 伪随机函数（PRF），确保密钥不会泄露。
技术细节： - UUIDv7 位布局：包含 48 位大端时间戳、版本号（v7 或 v4）、12 位随机数、RFC 变体和 62 位随机数。 - 掩码映射：通过 XOR 掩码处理时间戳字段，确保编码和解码过程可逆。 - SipHash 输入：从随机字段中提取 10 字节作为 SipHash 的输入消息。 - 安全性模型：使用 128 位密钥，确保即使通过选择输入也无法恢复密钥。
使用场景： - API 边界处理：在 API 边界进行 UUIDv7 到 UUIDv4 的编码和解码。 - 数据库扩展：为 PostgreSQL 等数据库编写小型 C 扩展。 - 分片处理：使用 xxh3 或 SipHash 对 UUIDv4 外观进行哈希处理。
性能： SipHash-2-4 在 10 字节消息上的处理速度极快，且无需内存分配。
许可证： 该项目采用 MIT 许可证，版权归 Stateless Limited 所有。
相关主题： - UUID - 数据库 - SipHash - 仅头文件 - C89 - UUIDv4 - UUIDv7
项目状态： - 星标：104 - 关注者：0 - 分支：1
语言： - C：83.8% - Makefile：16.2%
评论总结
主要观点总结：
UUIDv7的改进与安全性：
- 作者aabbdev提出了一种将UUIDv7内部用于数据库索引和排序，但对外显示为UUIDv4的方案，以隐藏时间戳信息。通过SipHash算法进行加密，确保安全性，且性能开销极低。
- 引用：“The idea is simple: keep UUIDv7 internally for database indexing and sortability, but emit UUIDv4-looking façades externally so clients don’t see timing patterns.”
- 引用：“Security: SipHash is a PRF, so observing façades doesn’t leak the key.”
- 作者aabbdev提出了一种将UUIDv7内部用于数据库索引和排序，但对外显示为UUIDv4的方案，以隐藏时间戳信息。通过SipHash算法进行加密，确保安全性，且性能开销极低。
数据库处理的建议：
- miningape认为这种转换应由数据库处理，以便在查询中灵活使用两种UUID格式。
- 引用：“This is interesting, but is almost something I’d rather have the DB handle for me.”
- miningape认为这种转换应由数据库处理，以便在查询中灵活使用两种UUID格式。
时间戳暴露的风险：
- tracker1询问暴露UUIDv7时间戳部分的具体风险。
- 引用：“could you give something resembling a couple practical examples of the risk of exposing the time portion of a v7 UUID?”
- tracker1询问暴露UUIDv7时间戳部分的具体风险。
视觉区分与用户体验：
- bismark指出UUIDv7在视觉上难以区分，建议在显示时进行视觉转换以提升用户体验。
- 引用：“My biggest issue w/ UUIDv7 is how challenging they are to visually diff when looking at a list.”
- bismark指出UUIDv7在视觉上难以区分，建议在显示时进行视觉转换以提升用户体验。
其他类似方案：
- chrismorgan和jppope分别提到使用Speck加密算法和ULID来实现类似的目标。
- 引用：“I made a scheme whereby you could use sequential numeric IDs in your database, but expose them as short random strings.”
- 引用：“Sounds like its trying to achieve something similar to what ULID is going for.”
- chrismorgan和jppope分别提到使用Speck加密算法和ULID来实现类似的目标。
技术实现细节：
- taminka建议在单头文件实现中加入STB风格的IMPL块以避免重复包含问题。
- 引用：“why not also do the stb-style IMPL block + definitions block such that you avoid the issues from accidentally including the header multiple times?”
- taminka建议在单头文件实现中加入STB风格的IMPL块以避免重复包含问题。
客户端需求与时间戳暴露：
- LeicaLatte指出移动应用可能需要单独的时间戳字段，因为客户端只能看到加密后的UUID。
- 引用：“Mobile apps often sort by creation time in the UI. Since clients only see the masked version, there might be a need to expose a separate timestamp field.”
- LeicaLatte指出移动应用可能需要单独的时间戳字段，因为客户端只能看到加密后的UUID。
UUIDv8的替代方案：
- themafia建议直接使用UUIDv8，因为它允许在格式中自定义时间戳和随机值。
- 引用：“Why not just use UUIDv8? The format allows you to use the upper bits for a timestamp and the lower bits for any value you like.”
- themafia建议直接使用UUIDv8，因为它允许在格式中自定义时间戳和随机值。
加密数据库ID的实践：
- gwbas1c提到通过加密数据库ID并生成GUID的实践。
- 引用：“I started encrypting database IDs and deriving GUIDs from that.”
- gwbas1c提到通过加密数据库ID并生成GUID的实践。
总结：
评论主要围绕UUIDv7的改进方案展开，讨论了其安全性、性能、用户体验以及与其他类似方案的对比。部分评论者提出了数据库处理、时间戳暴露风险、视觉区分等问题，并建议了其他替代方案如UUIDv8和ULID。