Data Modelling & Indexes

Service เปลี่ยนได้ใน 1 ไตรมาส แต่ data model ที่ผิดอยู่กับคุณเป็นปีๆ และการแก้มันคือการ migrate ข้อมูลสดขณะที่ลูกค้ากำลังใช้งาน Part นี้จึงเป็นส่วนที่ตัดสินว่าระบบของคุณจะอยู่รอดหรือไม่

Access-pattern-first modelling#

การทำ data model มี 2 แบบ และเหมาะกับเวลาที่ต่างกัน

Modelling checklist#

• เขียน access pattern table ก่อน (บทที่ 5) — ไม่มีข้อยกเว้น
• ต่อ entity: natural key คืออะไร, surrogate key คืออะไร, อะไรต้อง unique, อะไรต้องไม่เป็น null เลย
• ผลัก invariant ลงไปในฐานข้อมูล (ดูกล่องล่าง)
• ตัดสินมิติเวลา: แถวนี้ mutable หรือ append-only พร้อมประวัติ version — เงินและข้อมูล audit ต้อง append-only คุณไม่ UPDATE ledger entry
• ตัดสิน partition/shard key แม้จะยังไม่ shard แล้วเขียนไว้ใน design doc — model ที่มี shard key ที่เป็นไปได้จะ shard ทีหลังได้ถูก ที่ไม่มีคือการเขียนใหม่
• วางแผนขนาด: ตารางไหนจะมี 1 พันล้านแถว, โตวันละเท่าไหร่, query จะเป็นอย่างไรเมื่อมันใหญ่ขึ้น 100 เท่า

เลือก datastore ด้วยคำถาม 6 ข้อ#

B-tree กับ LSM-tree#

กฎ index ที่แก้ query ช้าได้ส่วนใหญ่#

1. ลำดับคอลัมน์ใน composite index: equality → range → sort#

-- Query: "transfer 20 รายการล่าสุดของ account นี้"
SELECT * FROM transfers
 WHERE source_account_id = $1
 ORDER BY created_at DESC, transfer_id DESC
 LIMIT 20;

-- ถูก: equality ก่อน แล้ว sort
CREATE INDEX ok ON transfers (source_account_id, created_at DESC, transfer_id DESC);

-- ผิด: index นี้ serve query ข้างบนไม่ได้เลย
CREATE INDEX bad ON transfers (created_at, source_account_id);

2. Covering index#

ถ้า index มีทุกคอลัมน์ที่ query ต้องใช้ ฐานข้อมูลไม่ต้องแตะตารางเลย บน hot read path นี่คือชัยชนะระดับ 10 เท่า ใน Postgres ใช้ INCLUDE

CREATE INDEX transfers_list_covering
  ON transfers (source_account_id, created_at DESC)
  INCLUDE (transfer_id, amount_minor, currency, status);

3. Partial index — เทคนิคที่มีค่าที่สุดใน Postgres#

Index บน boolean หรือบน status ที่มี 3 ค่ามักไม่ช่วยอะไรเลย แต่ partial index ช่วยมาก เพราะ index แค่ส่วนย่อยที่ร้อน

-- Work queue / outbox: hot set เล็กมากแม้ตารางจะมี 1 พันล้านแถว
CREATE INDEX transfers_pending ON transfers (created_at)
  WHERE status = 'PENDING';

CREATE INDEX outbox_unpublished ON outbox (created_at)
  WHERE published_at IS NULL;

4. ทุก index เก็บภาษีจากทุก write#

และกิน memory ที่ควรใช้ cache ข้อมูล Audit หา index ที่ไม่มีใครใช้ (pg_stat_user_indexes) แล้วลบทิ้ง

5. อ่าน plan อย่าเดา#

EXPLAIN (ANALYZE, BUFFERS)
SELECT ... ;   -- ต้องรันบนปริมาณข้อมูลจริง

6. Keyset (seek) pagination ไม่ใช่ OFFSET#

-- ผิด: OFFSET 100000 ทำให้ DB เดินผ่าน 100,000 แถวแล้วทิ้ง
-- ต้นทุนโตตามค่า offset -> หน้าท้ายๆ ช้าลงเรื่อยๆ
SELECT * FROM transfers WHERE source_account_id = $1
 ORDER BY created_at DESC LIMIT 20 OFFSET 100000;

-- ดีกว่า: seek จากตำแหน่งล่าสุด ต้นทุนไม่ขึ้นกับว่าอยู่หน้าที่เท่าไหร่
SELECT * FROM transfers
 WHERE source_account_id = $1
   AND (created_at, transfer_id) < ($2, $3)   -- tuple comparison
 ORDER BY created_at DESC, transfer_id DESC
 LIMIT 20;

Transaction และ isolation#

ACID บรรทัดละข้อ: Atomic (ทั้งหมดหรือไม่มีเลย), Consistent (invariant ยังคงอยู่), Isolated (transaction ที่ทำพร้อมกันไม่ทำลายกัน), Durable (commit แล้วรอด crash)

Lost update — bug ที่สร้างเงินขึ้นมาแบบเงียบ#

-- ทั้ง 2 transaction รันที่ READ COMMITTED ห่างกัน 3 ms:
T1: SELECT balance FROM accounts WHERE id=1;      -- อ่านได้ 1000
T2: SELECT balance FROM accounts WHERE id=1;      -- อ่านได้ 1000
T1: UPDATE accounts SET balance = 1000 - 300 ...  -- เขียน 700
T2: UPDATE accounts SET balance = 1000 - 500 ...  -- เขียน 500
-- COMMIT ทั้งคู่ ถอนเงิน 2 ครั้งรวม 800 ยอดสุดท้ายเหลือ 500
-- 300 บาทถูกสร้างขึ้นจากอากาศ และไม่มี error เกิดขึ้นที่ไหนเลย

4 ทางแก้ที่ถูกต้อง:

-- 1. Atomic arithmetic ในฐานข้อมูล (ง่ายที่สุด — ใช้อันนี้เป็น default)
UPDATE accounts SET balance_minor = balance_minor - 300
 WHERE account_id = 1 AND balance_minor >= 300;
-- แล้ว *เช็ค affected row count* — 0 แถว = เงินไม่พอ
-- invariant ถูกบังคับโดยฐานข้อมูล ไม่ใช่โดย if ของคุณ

-- 2. Pessimistic lock — เมื่อต้องอ่าน คำนวณ แล้วเขียน
SELECT balance_minor FROM accounts WHERE account_id = 1 FOR UPDATE;
-- serialize บนแถวนั้น; transaction อื่นรอ
-- ให้ *สั้น* และ *ล็อกแถวในลำดับที่คงที่เสมอ* เพื่อเลี่ยง deadlock

-- 3. Optimistic concurrency — ดีที่สุดสำหรับการแก้ที่ผู้ใช้เป็นคนกด
UPDATE accounts SET balance_minor = $1, version = version + 1
 WHERE account_id = 1 AND version = $2;
-- 0 แถว = คนอื่นชนะ -> โหลดใหม่แล้ว retry
-- ไม่ถือ lock ไว้ระหว่างที่ผู้ใช้กำลังคิด

-- 4. SERIALIZABLE + retry loop เมื่อเกิด serialization failure

ALTER TABLE accounts ADD CONSTRAINT balance_non_negative
  CHECK (balance_minor >= 0);

Write skew — anomaly ที่รอดจาก Repeatable Read#

Transaction 2 ตัวอ่านชุดของแถว, แต่ละตัวตรวจว่ากฎยังเป็นจริง, แล้วแต่ละตัวเขียน — และผลรวมทำลายกฎนั้น

ตัวอย่างคลาสสิก: "ต้องมีหมออยู่เวรอย่างน้อย 1 คน"
  T1 เห็นหมอ 2 คนอยู่เวร -> อนุญาตให้หมอ A ออก
  T2 เห็นหมอ 2 คนอยู่เวร -> อนุญาตให้หมอ B ออก
  --> ตอนนี้ไม่มีใครอยู่เวร

ใน fintech: transfer 2 รายการพร้อมกัน แต่ละรายการเช็ค
"ยังไม่เกิน daily limit" กับผลรวม ผ่านทั้งคู่ แต่รวมกันเกิน limit

-- Materialize the conflict สำหรับ daily limit
-- มีแถวเดียวต่อ (account, วันที่) ที่แทนยอดใช้ไปของวันนั้น
CREATE TABLE daily_limits (
  account_id   TEXT        NOT NULL,
  limit_date   DATE        NOT NULL,
  used_minor   BIGINT      NOT NULL DEFAULT 0,
  cap_minor    BIGINT      NOT NULL,
  PRIMARY KEY (account_id, limit_date)
);

BEGIN;
  -- ล็อกแถวที่แทน aggregate -> ตอนนี้มีของให้แย่งกันจริงๆ
  SELECT used_minor, cap_minor FROM daily_limits
   WHERE account_id = $1 AND limit_date = current_date
     FOR UPDATE;

  UPDATE daily_limits
     SET used_minor = used_minor + $2
   WHERE account_id = $1 AND limit_date = current_date
     AND used_minor + $2 <= cap_minor;      -- กฎถูกบังคับที่นี่
  -- 0 แถว -> เกิน limit ยกเลิก transaction

  INSERT INTO transfers (...) VALUES (...);
COMMIT;

Deadlock และ transaction ที่ยาว#

กฎข้อเดียวที่กำจัด deadlock ที่พบบ่อยที่สุดในระบบ payment#

Transaction 1: โอน A -> B    ล็อก min(A,B)=A แล้ว B
Transaction 2: โอน B -> A    ล็อก min(A,B)=A แล้ว B   <-- ลำดับเดียวกัน
--> ไม่มี deadlock

Deadlock ยังจะเกิดอยู่ดี#

ฐานข้อมูลตรวจจับแล้ว abort 1 transaction โค้ดของคุณต้องจับแล้ว retry ด้วย delay สั้นๆ ที่มี jitter — retry-on-deadlock เป็นสิ่งที่ต้องมีบน production ไม่ใช่ตัวเลือก

ห้ามเปิด transaction ค้างข้ามการเรียก network#

ตั้ง timeout ให้ transaction#

-- ตั้งที่ระดับ role หรือ session — กัน client ที่ค้างถือ lock ไม่มีที่สิ้นสุด
SET statement_timeout = '5s';
SET idle_in_transaction_session_timeout = '10s';
SET lock_timeout = '2s';        -- สำคัญมากตอนรัน migration

Checklist data modelling#

• Access pattern table เขียนก่อน schema
• Source of truth normalize · read model ทั้งหมด derive และ rebuild ได้
• ไม่มีข้อเท็จจริงใดที่มีสำเนา authoritative 2 ชุด
• Invariant สำคัญทุกข้ออยู่ใน constraint ของฐานข้อมูล
• ตาราง ledger / audit เป็น append-only
• Shard key ตัดสินแล้วและเขียนไว้ แม้ยังไม่ shard
• Partition scheme ตามเวลาออกแบบแล้ว ก่อนตารางจะใหญ่
• Index ทุกตัว serve pattern ที่ระบุไว้ · index ที่ไม่มีใครใช้ถูกลบแล้ว
• Pagination ใช้ keyset ไม่ใช่ OFFSET
• Read-modify-write ทุกจุดใช้ atomic statement, FOR UPDATE, version หรือ SERIALIZABLE
• มี CHECK กันยอดติดลบ
• Aggregate rule (limit ต่อวัน) ถูก materialize เป็นแถวให้ล็อก
• ล็อกในลำดับที่คงที่ (min(id) ก่อน) และมี retry-on-deadlock
• ไม่มี transaction ไหนครอบการเรียก network
• ตั้ง statement_timeout, idle_in_transaction_session_timeout, lock_timeout