Mục tiêu bài học
Chọn relational hay NoSQL dựa trên mô hình dữ liệu, transaction và access pattern.
Bài giảng chi tiết
Bài toán thực tế
Một hệ thống đặt hàng cần transaction/join, nhưng session và lookup key-value cần scale theo access pattern. Nếu chọn database theo tên phổ biến thay vì consistency, transaction và query pattern, kiến trúc sẽ khó scale hoặc sai semantics.
Đừng học nội dung này như một danh sách tên dịch vụ. Hãy đi theo chuỗi: requirement → khái niệm → quyết định → bằng chứng. Một câu trả lời tốt phải nói được vì sao lựa chọn phù hợp, phương án gần nhất bị loại ở đâu, và kiểm tra nào chứng minh lựa chọn đó hoạt động.
Khái niệm được giải thích theo scenario
- RDS/Aurora là relational managed database; schema, query, IAM và data vẫn là trách nhiệm cần thiết của khách hàng.
- Multi-AZ chủ yếu tăng availability/failover; Read Replica chủ yếu scale read.
- DynamoDB là key-value/document; partition key và access pattern phải thiết kế trước.
- Managed service giảm operational work, không loại bỏ backup, encryption, network và cost management.
Ví dụ khi gặp một scenario mới, hãy thay các từ khóa trong đề bằng một hệ thống cụ thể: ai là người dùng, dữ liệu đi qua đâu, thành phần nào có thể lỗi, quyền nào cần có và điều gì phải được quan sát. Cách làm này giúp phân biệt các đáp án gần đúng thay vì chọn theo trí nhớ tên service.
flowchart LR
A[Scenario / requirement] --> B[Concept and boundary]
B --> C[Service or control choice]
C --> D[Evidence and trade-off]
D --> E[Failure variant]
Khái niệm cốt lõi
RDS managed engine quan hệ, giảm vận hành OS/patching. Multi-AZ chủ yếu tăng availability và failover; Read Replica chủ yếu phục vụ read scaling/replication. Aurora là relational tương thích MySQL/PostgreSQL. DynamoDB là NoSQL key-value/document; partition key quyết định phân phối dữ liệu và access pattern phải được thiết kế trước.
Ví dụ giảng viên: phân loại một quyết định cloud
Bắt đầu từ access pattern: order cần transaction/join/constraint thì relational thường phù hợp; session lookup theo key và throughput lớn có thể phù hợp DynamoDB. Multi-AZ giải quyết failure/failover của database primary trong phạm vi thiết kế; Read Replica giải quyết read scaling/replication lag trade-off; backup/PITR giải quyết recovery, không thay hai mục tiêu kia.
Failure drill: primary lỗi, replica lag, query reporting làm nghẽn transaction, partition key tạo hot partition và database bị public. Với mỗi lỗi ghi signal, impact, control và evidence; không dùng “managed” để bỏ qua schema, IAM, backup hoặc network boundary.
Thực hành có kiểm soát
Vẽ hệ thống đặt hàng cần join/transaction với RDS và session key-value với DynamoDB. Đánh dấu Multi-AZ cho HA, Read Replica cho read-heavy workload. Không tạo database public chỉ để kết nối cho dễ.
Expected state và recovery
Trước khi thực hành, ghi rõ target/account/region, trạng thái hiện tại và output mong đợi. Sau thao tác, kiểm chứng bằng trạng thái thực tế hoặc command phù hợp; nếu kết quả sai, giữ lại evidence, quay về thay đổi nhỏ nhất và cleanup đúng owner. Không coi exit code 0 hoặc thông báo “success” là bằng chứng duy nhất.
- Chọn relational hoặc NoSQL dựa trên requirement, không dựa vào tên service.
- Phân biệt Multi-AZ, Read Replica và backup.
- Giải thích partition key quyết định cách DynamoDB phân phối/access dữ liệu.
- Vẽ network boundary khiến database không nhận inbound Internet trực tiếp.
Bẫy đề thi và cách tự kiểm tra
Managed không có nghĩa AWS chịu trách nhiệm cho schema, query, IAM và dữ liệu. Multi-AZ không phải Read Replica. DynamoDB không phải “RDS không có schema”.