Amazon DynamoDB vs RDS: Khi Nào Dự Án Cần NoSQL Siêu Tốc?

Hồi mình mới học AWS, có lần bị lead hỏi: "Database này tại sao lại dùng RDS thay vì DynamoDB?" — mình đứng hình 5 giây vì không biết trả lời gì. Thật ra, đây không phải câu hỏi khó nếu bạn hiểu rõ bản chất của từng loại. Chọn đúng database từ đầu tiết kiệm cả tháng refactor, sai thì... hỏi lại mình nhé.

DynamoDB và RDS là gì? Tại sao phải chọn?

Amazon RDS (Relational Database Service) là dịch vụ quản lý database quan hệ — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server. Bạn vẫn viết SQL quen thuộc, có schema cố định, hỗ trợ JOIN và transaction ACID đầy đủ. AWS lo phần vá lỗi, backup, failover — bạn chỉ cần thiết kế schema và query.

Amazon DynamoDB là database NoSQL serverless, lưu dữ liệu dạng key-value và document. Không cần quản lý server, tự động scale, độ trễ ổn định ở mức single-digit millisecond dù data tăng từ 1GB lên 100TB. Mỗi item có Partition Key (bắt buộc) và Sort Key (tuỳ chọn) — không có JOIN, không có schema cứng nhắc.

Lý do bạn phải chọn: không có database nào tốt cho mọi bài toán. Dùng DynamoDB cho hệ thống cần schema phức tạp thì query khó khủng khiếp. Dùng RDS cho ứng dụng cần scale hàng triệu request/giây thì tiền bay không kịp thở.

So sánh trực tiếp: DynamoDB vs RDS

Nhìn vào các điểm khác biệt cốt lõi dưới đây:

• Scale: DynamoDB tự động scale không giới hạn, RDS scale dọc (upgrade instance) hoặc ngang qua Read Replica nhưng có giới hạn.
• Pricing: DynamoDB tính theo Read/Write Capacity Unit hoặc on-demand per-request. RDS tính theo giờ chạy instance — instance không tắt là vẫn mất tiền dù không có traffic.
• Query: RDS dùng SQL đầy đủ với JOIN, GROUP BY, subquery. DynamoDB chỉ query được theo Primary Key hoặc GSI — muốn query linh hoạt phải thiết kế index từ đầu.
• Schema: RDS bắt buộc có schema cố định, migration phức tạp với table lớn. DynamoDB schemaless — mỗi item có thể có attributes khác nhau.
• Transaction: RDS hỗ trợ ACID transaction đầy đủ. DynamoDB hỗ trợ transaction nhưng giới hạn 25 item/transaction.
• Latency: DynamoDB luôn ổn định ở 1-9ms. RDS phụ thuộc vào độ phức tạp query và index.

Khi nào dùng DynamoDB?

DynamoDB phù hợp nhất khi bạn biết chính xác pattern truy cập data từ đầu và cần scale cao:

• Session Store / Cart / Real-time Gaming: Hàng triệu user đọc/ghi session data theo userId. DynamoDB trả về data trong 1-2ms nhất quán, không cần JOIN. Ví dụ: Fortnite dùng DynamoDB xử lý 10 triệu concurrent players.
• IoT và Time-series data: Thiết bị gửi hàng nghìn event/giây. DynamoDB nhận ingestion cao, lưu theo deviceId + timestamp làm Sort Key, query range theo thời gian nhanh chóng.
• Catalog sản phẩm e-commerce: Mỗi sản phẩm có attributes khác nhau (quần áo có size/màu, điện tử có thông số kỹ thuật). DynamoDB schemaless xử lý tốt hơn nhiều so với RDS phải dùng EAV pattern.

Khi nào dùng RDS?

RDS vẫn là lựa chọn tốt hơn trong nhiều tình huống quan trọng:

• Hệ thống tài chính / ERP / kế toán: Cần ACID transaction phức tạp, JOIN nhiều bảng, báo cáo với GROUP BY và aggregate. Sai một transaction là mất tiền thật — RDS với PostgreSQL là lựa chọn an toàn nhất.
• Legacy application migration: Ứng dụng đã có SQL schema từ trước, muốn "lift and shift" lên cloud mà không muốn viết lại toàn bộ. RDS là con đường nhanh nhất.
• Báo cáo phức tạp / Analytics: Cần ad-hoc query với nhiều điều kiện JOIN không biết trước. DynamoDB không thể làm được nếu không có index đúng — RDS linh hoạt hơn nhiều.

Framework quyết định trong 5 phút

Trả lời 4 câu hỏi sau để chọn đúng:

• Bạn có biết trước access pattern không? Nếu có → DynamoDB. Nếu cần query ad-hoc linh hoạt → RDS.
• Cần JOIN nhiều bảng không? Có → RDS. Không → DynamoDB (hoặc denormalize data).
• Traffic dự kiến thế nào? Cao, không đoán được, cần scale tự động → DynamoDB. Ổn định, dự đoán được → RDS cost-effective hơn.
• Team quen với gì? SQL → RDS nhanh hơn lúc đầu. Microservices serverless → DynamoDB phù hợp kiến trúc hơn.

Mẹo thực chiến: Nhiều hệ thống production dùng cả hai — DynamoDB cho session/cache/hot path, RDS cho core business data cần transaction. Không phải all-or-nothing.

"Ổ gà" phổ biến khi dùng DynamoDB lần đầu

Mình đã thấy nhiều team mắc những lỗi này khi chuyển sang DynamoDB:

• Thiết kế table như RDS: Tạo nhiều table nhỏ rồi cố JOIN — DynamoDB không có JOIN, phải fetch nhiều lần. Nguyên tắc: một table, nhiều access pattern qua GSI.
• Quên Partition Key hot spot: Dùng userId không đồng đều gây throttling một partition. Phải thiết kế key phân tán đều.
• On-demand mode tốn tiền hơn Provisioned ở steady traffic: On-demand linh hoạt nhưng đắt hơn 6-7x so với Provisioned khi traffic ổn định. Benchmark trước khi chọn.

FAQ thẳng thắn

Q: DynamoDB có hỗ trợ SQL không?

A: Có — PartiQL cho phép viết SQL-like query trên DynamoDB. Nhưng vẫn bị giới hạn bởi schema key-value, không có JOIN thực sự. Đừng nhầm lẫn đây là replacement của RDS.

Q: Chi phí DynamoDB vs RDS cái nào rẻ hơn?

A: Phụ thuộc hoàn toàn vào use case. DynamoDB on-demand rẻ hơn khi traffic thấp hoặc bùng nổ. RDS rẻ hơn khi traffic ổn định và cần nhiều compute. Phải tính toán theo workload cụ thể.

Q: Có thể migrate từ RDS sang DynamoDB không?

A: Được, nhưng không đơn giản. Phải redesign data model hoàn toàn, viết lại query logic, và thường phải denormalize data. AWS DMS hỗ trợ migrate data nhưng không migrate được business logic. Tính kỹ trước khi bắt đầu.

Chọn đúng từ đầu — tiết kiệm cả tháng sau

DynamoDB và RDS không cạnh tranh nhau — chúng giải quyết hai nhóm bài toán khác nhau. Nếu bạn cần scale không giới hạn với access pattern rõ ràng, DynamoDB là vũ khí mạnh nhất trong kho AWS. Nếu bạn cần tính toàn vẹn dữ liệu, query linh hoạt và transaction phức tạp, RDS vẫn là lựa chọn đáng tin cậy nhất. Bài tiếp theo mình sẽ đi vào VPC — cách AWS tạo ra "mạng nội bộ riêng" trên cloud để bảo vệ database của bạn khỏi Internet.