Tưởng tượng bạn đang xây một app bán thú cưng online, kiểu như “Pet Shop” made in Vietnam. Đột nhiên, một influencer livestream quảng bá, cả triệu người ùa vào xem mèo con, server MySQL của bạn bắt đầu “khóc thét”, truy vấn chậm như rùa bò. Lúc này, AWS thì thầm: “Thử DynamoDB đi, nó sinh ra để xử lý drama này đó!”. Vậy DynamoDB là gì, và nó khác MySQL ở chỗ nào? Hãy cùng tìm hiểu xem nhé!
Kèo căng DynamoDB vs MySQL
DynamoDB là cơ sở dữ liệu NoSQL của AWS, được thiết kế serverless (không cần lo server) và mở rộng vô hạn (AWS nói vậy chứ mình cũng k biết thật ko =)) ). Nó cho phép lưu mọi loại dữ liệu mà không cần bạn định nghĩa trước cấu trúc. Thêm nữa là bạn chỉ trả tiền cho những gì dùng (lưu nhiêu trả nhiêu, read/write nhiêu trả nhiêu, không có thì khỏi trả).
Để ví dụ đơn giản, dễ hiểu nhất thì DynamoDB nó giống như một thằng bạn "chill guy", nói gì với khứa đó cũng được, sẽ ko bị cấm, bị phàn nàn (tào lao quá thì nó đấm thôi =)) ).
MySQL thì ngược lại, là "cô giáo" nghiêm khắc của thế giới RDBMS. Nó yêu cầu bảng, cột, schema rõ ràng, không thì “trừ điểm”. Để hiểu rõ hơn, hãy so sánh chúng qua các khía cạnh cụ thể, với ví dụ minh họa từ app Pet Shop của chúng ta.
1. Data Model: Schema cố định hay tự do bay nhảy?
MySQL: Yêu cầu bạn định nghĩa schema trước, như tạo bảng Pets với các cột cố định: id, name, type, price. Nếu bạn đột nhiên muốn thêm color cho mèo, phải sửa schema, chạy migration.
Ví dụ: Bạn lưu một chú mèo như {id: 1, name: "Bun", type: "cat", price: 500000}. Muốn thêm color: "orange"? --> Cần ALTER TABLE để add nguyên cột mới.
DynamoDB: " Schema là cái gì?! " --> Ko cần define schema gì cả. Mỗi item trong bảng giống như một JSON, bạn muốn thêm gì thì thêm. Trong bảng Pets, bạn lưu chú mèo như {id: 1, name: "Bun", type: "cat", price: 500000}. Muốn thêm color? Cứ thêm {id: 2, name: "Tom", type: "cat", price: 600000, color: "orange"}, bảng vẫn vui vẻ chấp nhận.
Ví dụ: Nếu PetShop muốn lưu thêm thông tin “chứng nhận tiêm phòng” cho một số thú cưng, DynamoDB cho phép thêm thuộc tính này
chỉ cho những item cần, không ảnh hưởng item khác.
2. Scalability: Ai là “siêu nhân” chịu tải?
MySQL: Muốn mở rộng? Thường phải nâng cấp server (scale vertically) hoặc chia dữ liệu ra nhiều server (sharding). Với PetShop, nếu triệu người vào xem mèo cùng lúc, bạn phải thêm RAM, CPU, hoặc chia bảng Pets ra nhiều server. Sharding còn đòi hỏi bạn tự quản lý logic, dễ sai sót. Mình cũng chỉ mới nghe về Sharding ra nhiều server chứ chưa được động vào bao giờ nhưng chắc chắn là rất phức tạp.
DynamoDB: Sinh ra để scale tự động! AWS tự chia dữ liệu thành các partition để lưu trữ. Traffic tự nhiêu nhiều quá hả -> bạn chỉ cần hét lên “tăng nhiệt” là xong (tăng RCU/WCU – Read/Write Capacity Units). Hoặc thậm chí là Auto Scale hoàn toàn luôn với On-demand
Ví dụ: Trong livestream PetShop, DynamoDB tự điều chỉnh để xử lý triệu request mà không cần bạn thức đêm. Bạn có thể chọn on-demand capacity (auto hoàn toàn) hoặc provisioned capacity (tiết kiệm hơn, nhưng cần set up để auto scale), tiện như gọi Grab.
3. Query: JOIN vs Speed
MySQL: SQL là bố! Bạn có thể JOIN, GROUP BY, ORDER BY thoải mái. Với PetShop, muốn tìm tất cả đơn hàng của khách hàng “Nhi”? Dùng query: SELECT * FROM Orders JOIN Users ON Orders.user_id = Users.id WHERE Users.name = 'Nhi'. Mạnh mẽ, nhưng nếu bảng lớn, JOIN có thể chậm như rùa luôn.
DynamoDB: Ếu có JOIN luôn =)) , chỉ tập trung vào truy vấn nhanh dựa trên khóa chính (partition key, sort key) hoặc Index (GSI, LSI). Để lấy đơn hàng của “Nhi”, bạn phải denormalize, tức là lưu thông tin user trực tiếp trong item đơn hàng, như {order_id: 1, user_name: "Nhi", pet_id: 1}. Truy vấn sẽ nhanh như chớp, nhưng cần tư duy thiết kế khác.
Trong ví dụ trên, nếu order_id là PK, thì chỉ cần đánh GSI cho user_name và query user_name = "Nhi" trên GSI đó ta sẽ lấy được đơn hàng của Nhi với tốc độ O(1), ko join jiếc gì hết he he
4. Consistency: Ai đáng tin hơn?
MySQL: Đảm bảo strong consistency với ACID transactions. Khi bạn thêm một đơn hàng vào PetShop, dữ liệu được cập nhật ngay, không sợ sai lệch. Rất hợp cho hệ thống thanh toán, ví dụ: đảm bảo tiền trừ đúng khi khách mua mèo.
DynamoDB: Mặc định là eventual consistency, nghĩa là có thể mất vài giây (thường dưới 1s) để dữ liệu đồng bộ giữa các bản sao, giúp tăng tốc độ. Nhưng bạn có thể chọn strong consistency nếu cần.
Với Pet Shop, nếu khách xem số lượng mèo còn lại, eventual consistency đủ dùng vì độ trễ nhỏ không ảnh hưởng. Nhưng khi đặt hàng, bạn phải bật strong consistency để đảm bảo không bán trùng mèo nhé @@.
5. Chi phí và quản lý: Ai dễ thở hơn?
MySQL: Nếu tự host, bạn lo backup, scaling, vá lỗi – như chăm cún vậy. Dùng AWS RDS thì nhẹ hơn, nhưng vẫn trả tiền cho instance, kể cả khi không dùng.
Với Pet Shop, nếu khách ít, bạn vẫn tốn tiền duy trì server. Đây là một lý do mình quyết định dùng DynamoDb cho Givables vì mình có user nào quái đâu =)))
DynamoDB: Fully managed, AWS lo hết từ A-Z. Bạn chỉ focus vào code và thiết kế dữ liệu. Chi phí dựa trên RCU/WCU và storage, rất linh hoạt.
Pet Shop chỉ đông khách vào cuối tuần? Dùng on-demand capacity, bạn chỉ trả tiền khi có người vào xem để mua mèo.
Vậy chọn cái nào bây giờ?
DynamoDB: Lý tưởng nếu Pet Shop cần xử lý triệu lượt xem, muốn serverless (không quản lý server, hoặc xài nhiêu trả nhiêu), hoặc dữ liệu linh hoạt (như thêm thuộc tính “chứng nhận tiêm phòng” bất kỳ lúc nào). Hiệu suất cao, ổn định, latency thấp (single-digit milliseconds), hợp cho app chat, e-commerce, IoT. MySQL: Latency thấp hơn cả Dynamo nếu db không quá lớn, phù hợp cho app cần báo cáo phức tạp, như phân tích doanh thu theo loại thú cưng, hoặc dữ liệu có quan hệ rõ ràng (bảng Users, Orders, Pets). Cũng hợp nếu team bạn yêu SQL và ngại học NoSQL.
Kết luận: DynamoDB có đáng để “đổi gió”?
DynamoDB không phải Silver bullet, nếu bạn cần tốc độ, scale tự động, và không muốn đau đầu quản lý server, hoặc chỉ đơn giản là ko muốn mất tiền duy trì server khi ít user (giống mình) thì nó là lựa chọn sáng giá. MySQL thì đã quá quen thuộc, đáng tin, cho những thứ cần cấu trúc rõ ràng. Hiểu rõ nhu cầu của bạn – như Pet Shop, muốn bán mèo nhanh hay báo cáo chi tiết – sẽ giúp bạn chọn đúng.
Phần sau, chúng ta sẽ cùng tìm hiểu Single Table Design, bí kíp biến DynamoDB thành “võ công thượng thừa” nhá.