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

TL;DR: Chọn primary key là quyết định thiết kế có hệ quả lâu dài. Sequential key (auto-increment, UUID v7) chèn ở cuối index có thứ tự → page split thấp. Random key (UUID v4) chèn khắp nơi → page split cao, write amplification 2–3 lần, bloat tăng nhanh. UUID v7 (RFC 9562) lấy điểm tốt của cả hai: timestamp-prefix nên sequential, phần random nên unguessable + distributed-friendly. Serial PK lộ thông tin (enumeration attack) → dùng dual key (auto-increment nội bộ + UUID public). Natural key chỉ hợp khi immutable + universally unique + small. Nguyên lý agnostic — đúng cho mọi RDBMS dùng index có thứ tự.

TaskFlow ban đầu dùng tasks.id auto-increment — append-only, leaf page của index có thứ tự 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 cây index — 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 index có thứ tự 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. Tất cả là nguyên lý agnostic — cơ chế chi tiết của index có thứ tự được mổ ở Module 6 — Storage & indexing.

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

Hãy tưởng tượng leaf page của index có thứ tự là một cuốn sổ ghi chú có số trang cố định. Với key sequential (auto-increment): 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.

Sequential key vào cuối, random key vào giữa rồi xé trang:

flowchart TD
  subgraph SEQ["Sequential key (auto-increment / UUID v7)"]
    S1["Insert -> luon vao page cuoi"] --> S2["Page cuoi con cho -> ghi tiep"]
    S2 --> S3["Page split hiem -> fill factor cao"]
  end
  subgraph RND["Random key (UUID v4)"]
    R1["Insert -> vi tri ngau nhien"] --> R2["Trang da day -> xe doi (split)"]
    R2 --> R3["Write amplification + bloat"]
  end

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

Nhận xét ngay: auto-increment BIGINT 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ế page split

Leaf page của index có thứ tự có kích thước cố định (thường vài KB, tuỳ engine), chứa hàng trăm entry tùy row size. Khi insert vào vị trí giữa page đã đầy, engine 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.

-- Auto-increment: append-only, 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ế (benchmark trên ~10M row): key sequential 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à space chết và half-empty page từ split. Con số cụ thể khác nhau theo engine, nhưng xu hướng là phổ quát.

Forward: Module 6 — Storage & indexing đi sâu cơ chế index có thứ tự, page split, và fill factor.

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

-- UUID v4: 122 bit random + 6 bit version/variant
-- 'a3f2c1e0-9b8c-4d2f-8e1a-7c6b5d4e3f2a'  -> 100% random structure
-- Cach sinh la dialect: vai engine co ham gen_random_uuid(), vai engine ham UUID(),
-- hoac sinh o app layer.

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

-- UUID v7 sort tu nhien theo thoi gian tao:
-- '01952e8a-...' < '01952e8b-...' < '01952e8c-...'
-- Sequential trong cung ms -> insert vao cuoi index, page split thap

UUID v7 được chuẩn hoá trong RFC 9562 (May 2024) và được hỗ trợ rộng rãi: nhiều RDBMS có hàm sinh native hoặc extension; thư viện ở các ngôn ngữ (JavaScript, Java, Python...) đều có hàm uuidv7(). Vì cách sinh là dialect, một lựa chọn portable là sinh UUID v7 ở app layer rồi insert giá trị vào — không phụ thuộc engine có hàm native hay không.

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). Index 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ư một sequence trung tâm

Nhược điểm:

• Cần coordination để assign machine ID (service điều phối, 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 VARCHAR(100) 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  TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
  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 - auto-increment DB + UUID public
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  public_id UUID UNIQUE NOT NULL,   -- gan gia tri UUID v4/v7 (sinh la dialect)
  email     VARCHAR(254) UNIQUE NOT NULL
  -- ...
);
-- API: GET /api/users/:public_id  (unguessable)
-- DB join: WHERE id = ...         (sequential, fast index)

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

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

-- TaskFlow ap dung dual key cho tasks:
CREATE TABLE tasks (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  public_id UUID UNIQUE NOT NULL,   -- UUID sinh o app/DB (dialect)
  title     VARCHAR(500) NOT NULL
  -- ...
);
-- API route: GET /api/tasks/:public_id
-- Internal query: WHERE id = $1 (sequential index scan)

8. Decision matrix — chọn key theo context

9. Applied — TaskFlow PK rationale

-- users.id auto-increment (BIGINT IDENTITY): single-DB OLTP, no distributed requirement yet
-- Index co thu tu sequential -> page split thap, insert throughput cao
-- public_id UUID: unguessable URL /api/users/:public_id

-- tasks.id auto-increment: same reasoning as users
-- tasks.public_id UUID: /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 (gan gia tri UUID v7)
-- Dual write period: ghi ca auto-increment va UUIDv7
-- Switch FK references sang id_v7 tung buoc
-- Drop auto-increment khi tat ca service da migrate

Migration đổi PK trên bảng production cần làm online, từng bước — Bài 06 — Schema migration đi sâu pattern an toàn (expand-contract, dual-write, backfill).

10. Deep Dive — Identity strategy

11. Liên hệ các bài khác

• Bài 01 — Data types: UUID, auto-increment đứng ở nhóm "định danh là dialect" — bài này deep dive tradeoff giữa chúng.
• Bài 02 — Constraints: PK/UNIQUE tự sinh index; FK trỏ tới PK — chọn loại PK ảnh hưởng mọi FK trong schema.
• Bài 06 — Schema migration: đổi PK (auto-increment → UUID v7) trên bảng production cần expand-contract online.
• Module 6 — Storage & indexing: cơ chế index có thứ tự, page split, fill factor — vì sao random key tốn kém.

12. Tóm tắt

• Auto-increment append-only, index sequential — page split thấp, phù hợp OLTP single-DB.
• UUID v4 random insert toàn bộ cây index — 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. Cách sinh là dialect; sinh ở app layer cho portable.
• 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: auto-increment PK nội bộ (index friendly) + UUID public_id trên URL (chống enumeration attack).
• Nguyên lý agnostic, đúng ở mọi RDBMS. Forward: Bài 06 — Schema migration, Module 6 — Storage & indexing.

13. Tự kiểm tra

Bài tiếp theo: Schema migration & evolution — versioned migration, expand-contract