DynamoDB

Amazon DynamoDB เป็น fully managed NoSQL key-value/document database ที่ออกแบบเพื่อ performance ระดับ millisecond และ scale สูง แต่ต้องออกแบบ access pattern และ key ให้ถูกตั้งแต่ต้น

NoSQL และ access pattern

DynamoDB ไม่ได้เริ่มจาก normalize table แบบ relational database แต่เริ่มจากคำถามว่า application จะ query ข้อมูลอย่างไร เช่น “ดู order ตาม user”, “ดู event ล่าสุดของ device” หรือ “หา session จาก token”

Partition Key และ Sort Key

• Partition Key: ใช้กระจายข้อมูลและเป็น key หลักสำหรับ lookup
• Sort Key: ใช้เรียงและ query range ภายใน partition เดียวกัน
• Composite key: Partition Key + Sort Key ช่วยรองรับหลาย item ต่อ partition

Table: Orders
Partition key: customerId
Sort key: orderDate

Query: orders for customer C123 between 2026-01 and 2026-06

Capacity mode

Mode	เหมาะกับ	ข้อควรระวัง
On-demand	traffic ไม่แน่นอน, เริ่มต้นเร็ว	ราคาต่อ request สูงกว่าเมื่อ traffic predictable
Provisioned	traffic คาดการณ์ได้	ต้องตั้ง capacity/auto scaling ให้พอ

GSI, TTL, Streams และ Global Tables

• Global Secondary Index: query ด้วย key pattern อื่นนอกจาก primary key
• TTL: ลบ item อัตโนมัติเมื่อหมดอายุ เช่น session หรือ temporary token
• DynamoDB Streams: capture item-level changes เพื่อ trigger downstream processing
• Global Tables: multi-Region active-active replication สำหรับ low-latency global apps

Query vs Scan

Query ใช้ key condition และมีประสิทธิภาพกว่าเมื่อออกแบบ key ถูก Scan อ่านทั้ง table/index และมักแพง/ช้ากว่าใน table ใหญ่ ใช้สำหรับ admin งานเฉพาะหรือ table เล็กเท่านั้น

Common mistakes

• ออกแบบ table เหมือน SQL แล้วต้อง Scan ตลอด
• เลือก partition key ที่ทำให้ hot partition
• สร้าง GSI เยอะโดยไม่เข้าใจ write/cost impact
• ใช้ Global Tables โดยไม่เข้าใจ conflict และ regional failure behavior

Review questions

1. ทำไม DynamoDB ต้องเริ่มจาก access pattern?
2. Query ต่างจาก Scan อย่างไร?
3. GSI ช่วยแก้ปัญหาอะไรและเพิ่ม cost อย่างไร?