Surrogate vs natural key — UUIDv7 thay UUIDv4 cứu B-tree page split

TaskFlow ban đầu dùng tasks.id BIGSERIAL — append-only, B-tree leaf page chỉ thêm về bên phải. 100k INSERT mỗi giờ chạy ổn. Một ngày nọ, team quyết định switch sang id UUID (random v4) để chuẩn bị cho distributed system. Write throughput rớt 40%, page split tăng đột biến, bloat phình to trong vài tuần. Lý do: UUID v4 random insert vào mọi vị trí trên B-tree — cứ vài insert lại phải split một page, kéo theo write amplification gấp 2–3 lần.

Bài này map 4 dạng primary key phổ biến, giải thích tại sao sequential key và random key ảnh hưởng B-tree khác nhau, phân tích rủi ro enumeration attack với serial PK, và cho decision matrix để chọn đúng key cho từng tình huống.

1. Analogy — Sổ ghi chú có chỗ trống

Hãy tưởng tượng B-tree leaf page là một cuốn sổ ghi chú có số trang cố định. Với BIGSERIAL sequential: mỗi entry mới luôn ghi vào cuối sổ — trang cuối còn trống, ghi tiếp, không cần làm gì thêm. Với UUID v4 random: mỗi entry mới phải chèn vào một vị trí ngẫu nhiên giữa sổ — trang đó đã đầy thì phải xé đôi trang, dồn nội dung, tạo trang mới, cập nhật mục lục. Đây là page split — tốn I/O, gây write amplification.

2. 4 dạng primary key — bảng tradeoff

Nhận xét ngay: BIGSERIAL và UUID v7 đều sequential — page split thấp. UUID v4 random là outlier tệ nhất về page split. Snowflake đạt được cả sequential lẫn distributed nhưng cần coordination infra.

3. Sequential vs random — cơ chế B-tree page split

B-tree leaf page trong PostgreSQL mặc định 8 KB, chứa khoảng 200–400 row tùy row size. Khi insert vào vị trí giữa page đã đầy, PG phải:

1. Cấp phát page mới.
2. Di chuyển nửa số entry sang page mới (split 50/50).
3. Cập nhật parent node trỏ đến page mới.
4. Ghi cả hai page xuống disk.

Với sequential key, bước này hầu như không xảy ra — insert luôn vào page cuối cùng, page đó gần như luôn có chỗ trống.

-- BIGSERIAL: append-only, B-tree leaf page chi them phai
INSERT INTO tasks(id, title) VALUES (1001, 'A'), (1002, 'B'), (1003, 'C');
-- Leaf page [1..1000] day -> page moi [1001, 1002, 1003]
-- Khong split, ghi tiep duoc.

-- UUID v4: random insert moi vi tri
INSERT INTO tasks(id, title) VALUES
  ('a3f2c1e0-9b8c-4d2f-8e1a-7c6b5d4e3f2a', 'A'),  -- page X
  ('e7d1b4c3-2f6a-4a1d-9c8b-5e4d3f2a1b0c', 'B'),  -- page Y (xa)
  ('1c4b8e0d-7f3a-4b2c-8d1e-6a5b4c3d2e1f', 'C');  -- page Z
-- Moi insert co the trigger page split + write amplification 2-3x

Kết quả đo lường thực tế (pgbench, 10M row): BIGSERIAL duy trì fill factor gần 90%, UUID v4 bloat lên 60–70% sau vài triệu insert — nghĩa là 30–40% disk space là dead tuple và half-empty page từ split.

Forward: Module 5 bài 2 của khoá này đi sâu B-tree page split, fill factor tuning, và VACUUM behavior.

4. UUID v4 vs UUID v7 — điểm khác biệt

-- UUID v4: 122 bit random + 6 bit version/variant
-- PG 13+ built-in: gen_random_uuid()
-- 'a3f2c1e0-9b8c-4d2f-8e1a-7c6b5d4e3f2a'
--  ^^^^^^^^ ^^^^ ^^^^                    100% random structure

-- UUID v7: 48 bit timestamp (ms) + 74 bit random (RFC 9562, May 2024)
-- PG 18 native: uuidv7()
-- '01952e8a-3c4d-7000-8000-7c6b5d4e3f2a'
--  ^^^^^^^^ ^^^^              ^^ timestamp prefix -> sequential per ms
--                             random suffix -> unguessable next value

-- Compare sort order:
SELECT gen_random_uuid() AS v4_unsorted;
-- Insert 5 UUID v4 -> B-tree sau 5 insert: 5 vi tri khac nhau tren tree

-- UUID v7 insert theo thu tu thoi gian:
-- '01952e8a-...' < '01952e8b-...' < '01952e8c-...'
-- Sequential trong cung ms, sort tu nhien theo creation time

UUID v7 được chuẩn hoá trong RFC 9562 (May 2024). Hỗ trợ rộng rãi:

• PostgreSQL 18: hàm native uuidv7()
• PostgreSQL 13–17: extension pg_uuidv7 (PGXN)
• npm uuid package v9+: uuidv7()
• Java: UuidCreator.getTimeOrderedEpoch() (uuid-creator)
• Python: package uuid7

Migration từ v4 sang v7: không migrate existing row — PK immutable, migration sẽ cascade update toàn bộ FK. Pattern đúng: chấp nhận mixed schema (row cũ giữ v4, row mới dùng v7). B-tree vẫn hoạt động — chỉ là row cũ (v4, random) không sequential; row mới (v7) sequential. Fill factor cải thiện dần theo thời gian khi data mới chiếm phần lớn.

5. Snowflake — distributed alternative 8 byte

Twitter Snowflake (2010) là giải pháp distributed ID generation 64-bit:

1 bit reserved | 41 bit timestamp (ms) | 10 bit machine ID | 12 bit sequence

Sequential trong mỗi node (machine ID xác định), distributed giữa các node. Ưu điểm:

• 8 byte (bằng BIGINT) — gấp đôi tiết kiệm storage so với UUID 16 byte
• Sequential per node → page split thấp
• Distributed — không có single point of failure như sequence

Nhược điểm:

• Cần coordination để assign machine ID (Zookeeper, etcd, hoặc manual config)
• Nếu machine ID conflict → duplicate key (nghiêm trọng)
• Timestamp visible → expose rough creation time

Real-world: Twitter tweet ID, Discord channel/message ID, Instagram media ID đều là Snowflake variant.

Rule đơn giản: nếu không có infra coordination cho machine ID, UUID v7 là lựa chọn đủ tốt — sequential, uncoordinated, distributed-friendly.

6. Natural key — khi nào hợp lý

Natural key là cột có nghĩa nghiệp vụ đóng vai trò PK, thay vì surrogate (auto-generated ID).

-- Lookup table voi code bat bien: natural key hop ly
CREATE TABLE countries (
  code CHAR(2) PRIMARY KEY,  -- ISO 3166-1 alpha-2: 'US', 'VN', 'JP'
  name TEXT NOT NULL
);

-- Junction table M:N: composite PK tu FK, khong can surrogate
CREATE TABLE project_members (
  user_id    BIGINT REFERENCES users(id),
  project_id BIGINT REFERENCES projects(id),
  joined_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  PRIMARY KEY (user_id, project_id)
);

Natural key phù hợp khi key thoả mãn cả ba điều kiện: immutable (không bao giờ thay đổi), universally unique (không có hai entity nào cùng giá trị), và small (kích thước nhỏ để index hiệu quả).

Không dùng natural key cho:

-- EMAIL: user co the thay doi email -> cascade update toan bo FK
-- SLUG: rebrand doi slug -> break URL, cascade horror
-- USERNAME: rename -> cascade; platform allowance for reuse
-- SSN / CMND: privacy concern + format thay doi theo quy dinh

7. Pitfall — enumeration attack với serial PK

Serial PK (id = 1, 2, 3, ...) lộ thông tin về dataset:

GET /api/users/1234   -> user voi id 1234
GET /api/users/1235   -> guess next -> data leak
GET /api/users/1      -> first user (likely admin account)
GET /api/users/999999 -> 404 -> tong user duoi 1 trieu

Thông tin bị lộ:

• Tổng số user (max id xấp xỉ user count)
• Thứ tự signup (id = 1 là user đầu tiên — thường là admin)
• Có thể enumerate toàn bộ dataset qua HTTP scan

Ba lớp phòng thủ (ngoài authorization):

-- Pattern 1: UUID o public URL
-- GET /api/users/a3f2c1e0-9b8c-...  (khong guess duoc next)

-- Pattern 2: Dual key - BIGSERIAL DB + UUID public_id
CREATE TABLE users (
  id        BIGSERIAL PRIMARY KEY,
  public_id UUID UNIQUE NOT NULL DEFAULT gen_random_uuid(),
  email     TEXT UNIQUE NOT NULL,
  -- ...
);
-- API: GET /api/users/:public_id  (unguessable)
-- DB join: WHERE id = ...         (sequential, fast index)

-- Pattern 3: Hashids / Sqids
-- Encode BIGSERIAL thanh string khong guess duoc: 1234 -> "xKJ9mP"
-- One-way mapping: decode "xKJ9mP" -> 1234 tai app layer
-- Giu BIGSERIAL trong DB, expose string o URL

Pattern dual key (BIGSERIAL internal + UUID public) phổ biến nhất: hưởng lợi B-tree sequential insert từ BIGSERIAL, unguessable public URL từ UUID.

-- TaskFlow ap dung dual key cho tasks:
CREATE TABLE tasks (
  id        BIGSERIAL PRIMARY KEY,
  public_id UUID UNIQUE NOT NULL DEFAULT gen_random_uuid(),
  title     TEXT NOT NULL,
  -- ...
);
-- API route: GET /api/tasks/:public_id
-- Internal query: WHERE id = $1 (sequential B-tree scan)

8. Decision matrix — chọn key theo context

9. Applied — TaskFlow PK rationale

-- users.id BIGSERIAL: single-DB OLTP, no distributed requirement yet
-- B-tree sequential -> page split thap, insert throughput cao
-- public_id UUID v4: unguessable URL /api/users/:public_id

-- tasks.id BIGSERIAL: same reasoning as users
-- tasks.public_id UUID v4: /api/tasks/:public_id

-- project_members: composite PK (user_id, project_id)
-- No surrogate needed: relationship uniqueness is the key
-- Index tren composite PK cover ca hai lookup direction
PRIMARY KEY (user_id, project_id)

-- Future: neu TaskFlow scale distributed (5+ shard)
-- Migration strategy: them column id_v7 UUID NOT NULL DEFAULT uuidv7()
-- Dual write period: ghi ca BIGSERIAL va UUIDv7
-- Switch FK references sang id_v7 tung buoc
-- Drop BIGSERIAL khi tat ca service da migrate
-- (xem Module 10 cua khoa nay cho sharding pattern chi tiet)

Forward: Module 10 của khoá này đi sâu sharding pattern và UUID v7 migration strategy cho distributed setup.

10. Deep Dive — Identity strategy

Liên kết khoá học khác

• Khoá Spring — bài 4.2 Entity Mapping — apply ID strategy vào JPA @GeneratedValue.

11. Tóm tắt

• BIGSERIAL append-only, B-tree sequential — page split thấp, phù hợp OLTP single-DB.
• UUID v4 random insert toàn bộ B-tree — page split cao, write amplification 2–3x, bloat tăng nhanh.
• UUID v7 timestamp-prefix sequential, RFC 9562 (May 2024) — fix page split của v4, giữ distributed-friendly.
• Snowflake 8 byte, sequential per node — distributed có coordination; không có infra thì UUID v7 đủ.
• Natural key chỉ hợp lý khi key immutable + universally unique + small (vd ISO country code, junction PK).
• Dual key pattern: BIGSERIAL PK nội bộ (B-tree friendly) + UUID public_id trên URL (chống enumeration attack).
• Forward: Module 5 bài 2 của khoá này (B-tree page split + fill factor deep dive), Module 10 của khoá này (sharding và UUID v7 migration).

12. Tự kiểm tra

Bài tiếp theo: Migration với Atlas — declarative thay Flyway/Liquibase