UUID的压缩

简介:

概述

UUID,通用唯一识别码(Universally Unique Identifier)。
UUID的目的是让分布式系统中的所有元素都能有唯一的辨识信息,而不需要透过中央控制端来做辨识信息的指定。
UUID的标准型式包含32个16进制数字,以连字号分为五段,形式为8-4-4-4-12的32个字符。
示例:

550e8400-e29b-41d4-a716-446655440000

——以上内容摘自百度百科

实现

UUID有很多实现版本,以下是JDK的一个实现:

    private static class Holder {
        static final SecureRandom numberGenerator = new SecureRandom();
    }

    public static UUID randomUUID() {
        SecureRandom ng = Holder.numberGenerator;

        byte[] randomBytes = new byte[16];
        ng.nextBytes(randomBytes);
        randomBytes[6]  &= 0x0f;  /* clear version        */
        randomBytes[6]  |= 0x40;  /* set to version 4     */
        randomBytes[8]  &= 0x3f;  /* clear variant        */
        randomBytes[8]  |= 0x80;  /* set to IETF variant  */
        return new UUID(randomBytes);
    }

用SecureRandom生成的16字节(128bit)随机数,用掩码打上版本和IETF标识。
实际有效随机位122位。关于冲突概率,可以参考笔者另一片文章,漫谈散列函数

特征

UUID的优点很明显:“分布式”、“唯一”。
这些优点使得UUID被广泛使用,尤其是分布式环境下。

然而其缺点也很明显:无序,长度较长。
这些缺点也极大地限制了其应用范围,比如数据表的主键,通常大家都不会用UUID。

但还是有不少地方用到UUID的:
有时候想给一个对象分配一个标识,但是该对象不好提取唯一特征,然后该环境下又不好统一分配,
这时候很自然就想到UUID了,UUID不需要以对象特征为参数,也不用担心重复(不是说不会重复,只是不用担心,就像不用担心天上掉下陨石砸到自己一样-_-)。

压缩

但是看着这个36个字节长度的UUID,总不自觉地会想有没有优化的余地。
16字节的信息,用16进制显示,有32个字符,加上分隔符,有36字节。
事实上,如果用base64编码这16个字节,可以压缩到22字节。

    public static byte[] hex2Bytes(String hex) {
        if (hex == null || hex.isEmpty()) {
            return new byte[0];
        }
        byte[] bytes = hex.getBytes();
        int n = bytes.length >> 1;
        byte[] buf = new byte[n];
        for (int i = 0; i < n; i++) {
            int index = i << 1;
            buf[i] = (byte) ((byte2Int(bytes[index]) << 4) | byte2Int(bytes[index + 1]));
        }
        return buf;
    }

    private static int byte2Int(byte b) {
        return (b <= '9') ? b - '0' : b - 'a' + 10;
    }

    public static String compressUUID(String uuid){
        String hex = uuid.replace("-", "");
        byte[] bytes = FormatUtils.hex2Bytes(hex);
        return new String(Base64.encode(bytes, Base64.URL_SAFE | Base64.NO_PADDING | Base64.NO_WRAP));
    }

UUID压缩前后:

d44979db-5c64-40f1-b47e-e7f41c4be9e7

3dkJ2-z92fr9DuD9rNvp4A

36字节相对22字节,节约接近40%的长度,对于存储和传输而言,都是较大的提升;
虽然从可读性来说,UUID的可读性更好。
在权衡可读性和性能的时候,笔者通常的想法是,如果阅读和书写比较频繁,选择可读性较好的,如果不怎么需要阅读,选择对机器友好的。
尤其是对于数据库存储这种情况,由于存在规模效应,显然压缩的版本更具性价比。

优化

如果需要压缩版本的UUID,调用JDK的UUID生成字符串,再处理成压缩版的UUID,显然“绕圈子”了。
我们可以仿照JDK的写法直接生成:

    public static String randomUUID() {
        byte[] bytes = new byte[15];
        Holder.numberGenerator.nextBytes(bytes);
        return Base64.encodeToString(bytes, Base64.URL_SAFE | Base64.NO_WRAP);
    }

15字节的随机数,120bit, 和JDK的randomUUID效用上是差不多,然后15是3的倍数,base64编码时不需要PADDING;
生成20字节的字符串(15 / 3 * 4), 相对UUID的36字节,节约近一半的空间。

其他

base64编码有一个逼死强迫症的特点:除了常规字符[A-Za-z0-9]之外,需要另外两个字符才能凑够64个字符。
于是,我们看到base64分化了两个版本,分别以 ['+', '/'] 和 ['-', '_'] 作为补充字符的两个版本。
其中,后者是URL_SAFE的版本,前者编码后可能会包含'/', 而'/'是URL的分隔符。
但无论哪个版本,对于URL而言,有非常规字符确实确实不是很“美观”。
于是,有人想出了base62编码。
base62编码,通常用来给long编码还好,用来编码任意字节数组的话,效率很低。
不过对于long来说,base62编码长度为11字节,而十六进制编码也只是16个字节,而且十六进制可读性更好。

简书的文章ID,十六进制,12字节(48bit)。

12字节的长度,可读性OK;48bit,取值范围有两百多万亿,够用。总的来说,是比较均衡的方案。
我很好奇是怎么构造的:
随机数?可能性不大。
自增序列?不太像。通常纯自增序列的ID长度不固定,如QQ号。

如果让我来写,有可能会混合多个因子来构造ID。
例如Twitter的Snowflake,混合了时间戳,机器ID和序列号。

计算机从16位寄存器,到32位,再到64位,就不往上涨了;
在当前的体系下,对于数据库存储而言,64bit的ID是最适合的。

总结

  • 尽量用整型的ID;
  • 如果要用UUID,尽量用压缩的版本;
  • MD5也是128bit, 作为字符串传输和存储时,base64编码要优于16进制。
相关文章
|
算法 Java
雪花算法生成id
雪花算法生成id
|
7月前
|
存储 人工智能 自然语言处理
Lindorm作为AI搜索基础设施,助力Kimi智能助手升级搜索体验
月之暗面旗下的Kimi智能助手在PC网页、手机APP、小程序等全平台的月度活跃用户已超过3600万。Kimi发布一年多以来不断进化,在搜索场景推出的探索版引入了搜索意图增强、信源分析和链式思考等三大推理能力,可以帮助用户解决更复杂的搜索、调研问题。Lindorm作为一站式数据平台,覆盖数据处理全链路,集成了离线批处理、在线分析、AI推理、融合检索(正排、倒排、全文、向量......)等多项服务,支持Kimi快速构建AI搜索基础设施,显著提升检索效果,并有效应对业务快速发展带来的数据规模膨胀和成本增长。
|
2月前
|
存储 人工智能 关系型数据库
从“听指令”到“当参谋”,阿里云AnalyticDB GraphRAG如何让AI开窍
阿里云瑶池旗下的云原生数据仓库 AnalyticDB PostgreSQL 版 GraphRAG 技术,创新融合知识图谱动态推理+向量语义检索,通过实体关系映射与多跳路径优化,构建可应对复杂场景的决策引擎。本文将通过家电故障诊断和医疗预问诊两大高价值场景,解析其如何实现从“被动应答”到“主动决策”的跨越。
|
安全 Java
UUID太长怎么办?快来试试NanoId(Java版本)
UUID太长怎么办?快来试试NanoId(Java版本)
513 5
|
Java 测试技术
一文读懂如何用Java编写单元测试用例?
一文读懂如何用Java编写单元测试用例?
1135 0
|
消息中间件 Java Kafka
Spring Boot与Kafka的集成应用
Spring Boot与Kafka的集成应用
|
Kubernetes Cloud Native Java
灰度发布、蓝绿部署、金丝雀都是啥?
在滚动部署中,应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间,新旧版本会共存,而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。
灰度发布、蓝绿部署、金丝雀都是啥?
|
存储 关系型数据库 MySQL
【mysql】文本字符串类型
【mysql】文本字符串类型
4192 1
【mysql】文本字符串类型
|
存储 NoSQL Java
redisTemplate.opsForValue() 懂这些就够了
redisTemplate.opsForValue() 懂这些就够了
1840 0
|
存储 算法 安全
使用MD5当做文件的唯一标识,这样安全么?
MD5常用于文件完整性验证。通过对文件进行MD5哈希计算,可以生成唯一的哈希值,用于识别文件的内容是否发生改变。这在文件传输和数据备份中特别有用。 MD5也经常被用于密码存储,将用户密码经过MD5哈希后存储,而不是直接保存明文密码,以增加安全性。
2875 0
使用MD5当做文件的唯一标识,这样安全么?