Tuần 6 - Ngày 3: DynamoDB Deep Dive

Mục tiêu học tập

• Chọn đúng capacity mode (Provisioned vs On-Demand) theo traffic pattern và chi phí
• Phân biệt GSI vs LSI và hiểu tác động throttling
• Nắm DAX, Transactions, TTL và single-table design pattern ở mức Professional

1. DynamoDB Capacity Modes

2. Secondary Indexes

3. DynamoDB Accelerator (DAX)

4. DynamoDB Transactions

TransactWriteItems:
- Up to 100 items
- Atomic (all or nothing)
- Consumes 2x WCU

TransactGetItems:
- Up to 100 items
- Consumes 2x RCU

Use cases:
- Financial transactions
- Gaming leaderboards
- Multi-item updates

5. Time To Live (TTL)

Auto-delete expired items:
- No extra cost
- Eventually deleted (within 48 hours)
- Define TTL attribute (epoch timestamp)

Use cases:
- Session data
- Temporary tokens
- Log cleanup

6. Patterns

Single Table Design

PK          | SK              | Data
------------+-----------------+--------
USER#123    | METADATA        | {name, email}
USER#123    | ORDER#001       | {order details}
USER#123    | ORDER#002       | {order details}
PRODUCT#A   | METADATA        | {product info}
ORDER#001   | PRODUCT#A       | {line item}

Benefits:
- Single query for all user data
- Reduced latency
- Cost optimization

7. Câu hỏi ôn tập

1. Khi nào chọn On-Demand thay vì Provisioned?

   Xem đáp án

   On-Demand khi: traffic unpredictable/spiky, workload mới chưa có baseline, hoặc muốn zero capacity planning ("least operational overhead"). Provisioned khi: traffic ổn định/dự báo được — rẻ hơn ~3.5× ở steady state (sau đợt giảm giá on-demand 50% tháng 11/2024; trước đó chênh ~6–7×), có thể mua reserved capacity. Kết hợp Provisioned + Auto Scaling là middle ground cho traffic dao động có pattern.

2. GSI khác LSI ở những điểm nào và GSI throttle base table khi nào?

   Xem đáp án

   LSI: cùng partition key, khác sort key; chỉ tạo lúc create table; max 5; share RCU/WCU với table; hỗ trợ strongly consistent read. GSI: partition key khác được; tạo bất kỳ lúc nào; max 20; RCU/WCU riêng; chỉ eventually consistent. Bẫy quan trọng: nếu GSI thiếu WCU, write vào base table bị throttle dù table còn capacity — vì mọi write phải propagate sang GSI. Provision GSI WCU ≥ base table WCU cho attribute được index.

3. DAX phù hợp use case nào, không phù hợp use case nào?

   Xem đáp án

   Phù hợp: read-heavy, read-mostly workload cần microsecond latency (item cache cho GetItem, query cache cho Query/Scan), giảm RCU cost khi hot key được đọc lặp lại. Không phù hợp: workload write-heavy, cần strongly consistent reads (DAX chỉ serve eventually consistent), hoặc app không dùng SDK tương thích DAX. Nếu cần cache chung cho nhiều nguồn dữ liệu → ElastiCache thay vì DAX.

4. TTL có tính phí không và độ trễ xoá là bao lâu?

   Xem đáp án

   TTL miễn phí (không tiêu WCU khi xoá). Item quá hạn bị xoá eventually — thường trong vòng vài ngày, không tức thì (docs: typically within 48 hours), nên filter expired items trong query nếu app nhạy cảm. Item bị TTL xoá xuất hiện trong DynamoDB Streams (dạng REMOVE với userIdentity là dynamodb.amazonaws.com) — pattern hay: TTL + Streams + Lambda để archive data hết hạn sang S3.

8. Bài tập thực hành

1. So sánh capacity modes: tạo 2 table giống nhau (1 On-Demand, 1 Provisioned 5 RCU/5 WCU), chạy load test nhỏ vượt provisioned capacity và quan sát ThrottledRequests metric; ước tính chi phí tháng cho cùng workload steady 50 req/s trên cả 2 mode.

2. GSI throttling: tạo GSI với WCU thấp hơn hẳn base table, ghi dồn dập và quan sát write vào base table bị throttle — xác nhận bẫy "GSI có thể throttle base table".

3. TTL + Streams archive: bật TTL trên attribute epoch, bật Streams, gắn Lambda ghi item expired sang S3. Verify record REMOVE do TTL có userIdentity đặc trưng.

---

Tài liệu tham khảo chính thức

• Amazon DynamoDB Developer Guide
• DynamoDB Best Practices
• DynamoDB Global Tables
• DynamoDB Accelerator (DAX)

---

Ngày tiếp theo: Data Analytics Services