/tags/tidb/ Recent content in tidb on Hugo -- gohugo.io en Tue, 08 Sep 2026 13:37:38 +0800 /posts/distributed-id-uuidv4-uuidv7-ulid/ Tue, 08 Sep 2026 13:37:38 +0800 /posts/distributed-id-uuidv4-uuidv7-ulid/ 分布式系统里的 ID 要在互不协调的多个节点上各自生成，所以候选基本都是 128 位：UUIDv4 全是随机数，UUIDv7 和 ULID 前面放毫秒时间戳、后面放随机数。 三个里选哪个，绕不开一句常见的建议：主键最好递增。选型真正在选的只有两件事：键占几个字节，同一毫秒内有没有顺序。这两件事各换来什么、要付什么，取决于几个进程在写、数据靠什么分布。 一个写入者的 InnoDB 表上递增的收益最大：同一张 30 万行的表，主键从纯随机换成同一毫秒内严格递增，聚簇索引少近四成的页。四个实例各带计数器时只剩两成，键存成 CHAR(36) 时反而比纯随机多两成页；按主键范围分片的库上递增变成写热点；按 hash 分布的库不看这一项。 只有前两种形态是我自己量的：单节点 MySQL 能在一台笔记本上反复跑，而且它的 fill factor 规则手册里写着，可以拿实测去对。分片那两种按各家文档说，不报没测过的数。 环境是 MySQL 8.0.46（mysql:8.0 容器，innodb_buffer_pool_size=128M，binlog 开着）。建表脚本、灌数脚本和原始输出在 distributed-id-demo：八张表的页数在 results/2026-09-08-innodb.txt，OPTIMIZE TABLE 前后的对照在 results/2026-09-08-innodb-reclaim.txt。 一处口径先交代清楚：灌数用的键是脚本预先生成的，键里的毫秒时间戳每 500 行进一格，模拟每毫秒写 500 条，不是灌数时的真实速率。 三种 ID 的位段：时间戳在前，随机位在后 三种 ID 都是 128 位，差别在这 128 位怎么切。随机位的宽度取自规范本身，不是谁的实测。 时间戳 随机位 文本形态 出处 UUIDv4 无 122 36 字符十六进制，带连字符 RFC 9562 §5.4 UUIDv7 48 位，Unix 毫秒 74（rand_a 12 + rand_b 62） 36 字符十六进制 RFC 9562 §5. /posts/oceanbase-tidb-stress-test/ Tue, 04 Aug 2026 07:18:15 +0800 /posts/oceanbase-tidb-stress-test/ 背景 这轮压测的对象是一套用 WebFlux / R2DBC 写的响应式服务。数据库先从 OceanBase（下称 OB）换到 TiDB Cloud，又换回来，最后跑了一轮同拓扑 A/B 对照。被测接口每笔请求展开约 27 条串行 SQL（其中约 9 条写），外加 16.6 次 Redis 往返。 先把口径摆出来，后面所有数字都在这套配置下： 项 这次的取值 被测服务 WebFlux + R2DBC 响应式服务，跑在 K8s 的 perf 命名空间 OB 规格 3 × 8c32g observer + OBProxy 专属集群 6c12g × 2（最后一轮升到 32c70g × 3） TiDB TiDB Cloud 按 RU 计费的那一版，4 台 tidb-server 网关，store 从 5 台加到 8 台 发压端 k6，先是笔记本走公网，之后改成集群内 Pod 直连 Service 阶梯 起始 200/s，步长 100/s，每档跑满 3 分钟，只取稳态窗口 负载打散 10 万玩家，最后一轮 100 万 应用连接池 R2DBC，max-size 一路从 10 调到 400、50、200、250，最后一轮收到 100 两边计费方式不同，对比方案要跟着改。OB 买的是固定规格，按 AWS 上的 vCPU 和内存付费，压不压成本都一样；我测的这版 TiDB 按 RU 计费，用多少算多少。直接比吞吐没有意义，所以顺序是先跑 OB，在固定规格下压出一个延迟可接受的 RPS 当基准，再看 TiDB 在相近延迟、相近 RPS 下要花多少。后面反推「每笔业务消耗多少 RU」，就是为了算这笔账。