Complexity และ Scale: สิ่งที่เร็วกับ 100 แถวอาจพังที่ล้านแถว
เข้าใจ “Complexity และ Scale: สิ่งที่เร็วกับ 100 แถวอาจพังที่ล้านแถว” ผ่านงานธุรกิจไทยและผลกระทบต่อความเร็ว ความถูกต้อง และความเป็นธรรม
เป้าหมาย: เลือกโครงสร้างและตั้งคำถามเรื่อง scale ได้โดยไม่ต้องเป็นโปรแกรมเมอร์ · ใช้เวลาประมาณ 15 นาที
Question → Structure → Operation → Trade-off
เลือกโครงสร้างจากคำถามและการเปลี่ยนแปลง ไม่ใช่จากชื่อที่คุ้น
Question
ต้องค้น เรียง เชื่อม คิว หรือเดินตามลำดับอะไร
Structure
เลือก representation และ identifier
Operation
ระบุ read/write/update/delete และความถี่
Trade-off
วัดเวลา พื้นที่ freshness fairness และ failure
แนวคิดที่ใช้คุยกับทีม
complexity
อธิบาย complexity ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
วาดตัวอย่างข้อมูลเล็กก่อนเลือก implementation
scale
อธิบาย scale ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
คิดถึงการเติบโตของเวลา พื้นที่ network และ tool calls เมื่อ input เพิ่ม ไม่ต้องคำนวณสูตรทุกครั้งแต่ต้องวัด load และหลีกเลี่ยงงานซ้ำซ้อน
latency
อธิบาย latency ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
คิดถึงการเติบโตของเวลา พื้นที่ network และ tool calls เมื่อ input เพิ่ม ไม่ต้องคำนวณสูตรทุกครั้งแต่ต้องวัด load และหลีกเลี่ยงงานซ้ำซ้อน
batch
อธิบาย batch ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต
คิดถึงการเติบโตของเวลา พื้นที่ network และ tool calls เมื่อ input เพิ่ม ไม่ต้องคำนวณสูตรทุกครั้งแต่ต้องวัด load และหลีกเลี่ยงงานซ้ำซ้อน
แบบจำลองที่ทำให้ระบบผิด
ไม่มี stable key
ข้อมูลซ้ำหรืออัปเดตผิดคน
กำหนด identity/matching rule
priority ไม่มีเหตุผล
ไม่ยุติธรรมและตรวจไม่ได้
ประกาศ criteria/tie-break
ทดสอบแต่ข้อมูลน้อย
latency/cost ระเบิดเมื่อ scale
load test และ complexity review
ออกแบบโครงสร้างจากงาน
workflow เทียบเอกสารทุกฉบับกับทุกฉบับเมื่อคลังโตขึ้น
กำหนด entity/key, structure, operations, edge cases, scale และ metric
ดูคำตอบตัวอย่าง
ระบุ source of truth และ stable key เลือก list/map/queue/tree/graph/index ตามคำถาม เขียน operations และ tie-break ตรวจ duplicate/cycle/stale index วัด latency, memory, fairness และ cost ที่ปริมาณปัจจุบันกับอนาคต พร้อม fallback เมื่อข้อมูลผิด
- entity/key
- structure
- operations
- edge cases
- scale
- metric/fallback
บันทึกช่วยจำ
- โครงสร้างเดียวอาจมี implementation หลายแบบ ให้ทีมเทคนิควัดกับ workload จริง
- การ ranking คนหรือสิทธิ์ต้องตรวจ bias และผลกระทบ
สรุปบทเรียนนี้
- เริ่มจากคำถาม
- มี key และ operation ชัด
- วัด trade-off เมื่อ scale