ออกแบบโดยยึด access pattern เป็นอันดับแรก จากนั้นเลือก partitioning + index/PK ที่เหมาะสมเพื่อให้ query ใด ๆ ครั้งเดียวแตะเพียง slice ที่เล็กและมีขอบเขต — ไม่มีวันสแกน 10B row การทำ sub-100ms บน 10 พันล้าน record ไม่ได้เกี่ยวกับ disk ที่เร็วขึ้น แต่เกี่ยวกับการทำให้ working set เล็กจิ๋ว
text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
│ (prune 99.9% of data) (B-tree / sort key)
└─▶ Cache (Redis) ─▶ hit? return in <5ms
miss ▼
Columnar store (ClickHouse) for aggregates / scans
Access pattern ขับเคลื่อนทุกอย่าง
ก่อนเลือกเทคโนโลยี ให้ถาม: "ดึง order 20 รายการล่าสุดของ user X" คือ point/range query — คุณต้องการให้ partition และ sort key ตรงกับมันเป๊ะ ๆ "รวมรายได้ตามภูมิภาคเดือนนี้" คือ analytical scan — row store เป็นเครื่องมือที่ผิด การ model query ก่อนคือสิ่งที่แยกดีไซน์ที่ใช้งานได้จริงออกจากดีไซน์ที่ดูสมเหตุสมผลแต่ full-scan