DynamoDB

DynamoDB là gì và mô hình cốt lõi

Amazon DynamoDB là database NoSQL fully managed trên cloud của Amazon: bạn có thể tăng giảm throughput của bảng một cách động mà không tự vận hành server.¹ Grokking xếp DynamoDB vào nhóm key-value database: dữ liệu lưu theo cặp key-value, dễ chia partition và scale ngang.²

Tên gọi gợi nhớ thiết kế Dynamo mà Grokking dùng làm nền cho chương Key-value Store: consistent hashing, virtual node, replication, quorum r + w > n, vector clock.³ Bài này không khẳng định dịch vụ DynamoDB hiện nay cài đặt đúng từng chi tiết đó; thư viện chưa có sách về kiến trúc bên trong của dịch vụ.⁴

Mô hình dữ liệu:

• Table chứa các item (giống row nhưng linh hoạt hơn: item là tập thuộc tính có tên, có thể lồng nhau như JSON và chứa cả một aggregate).⁵ Giới hạn kích thước item là số liệu của sản phẩm, hãy tra tài liệu hiện hành.⁴
• Mỗi item có primary key, gồm:
  • Partition key (PK): dùng để chọn partition lưu trữ của item.⁶
  • Sort key (SK) (tuỳ chọn): sắp xếp các item cùng PK. Cặp PK + SK phải duy nhất.⁶
• Các thuộc tính khác không cần schema. Hai item trong cùng bảng có thể có thuộc tính hoàn toàn khác nhau (schema định nghĩa theo từng item).²

Nhóm các item có cùng PK gọi là item collection. Đây là ý tưởng trung tâm: một lần Query trả các item có partition key chỉ định, sort key nằm trong khoảng cho trước, thoả filter tuỳ chọn, theo thứ tự sort key.⁶

Mô tả Query, PutItem, UpdateItem theo Microservices Patterns.⁷⁶ Các thao tác batch, transaction và chi phí tương đối của từng thao tác là kiến thức sản phẩm chưa có sách kiểm chứng.⁴

Kiến trúc bên dưới

Sơ đồ trên là hình dung của khoá học về cách một dịch vụ key-value được phân partition và nhân bản; chi tiết nội bộ của DynamoDB chưa có sách trong thư viện.⁴ Những ý có nguồn:

• Partition key được dùng để chọn partition của item: đây là scale theo trục Z (chia dữ liệu theo key).⁶
• Một hệ kiểu Dynamo nhân bản mỗi key ra n node và dùng r + w > n để đọc thấy lần ghi mới nhất; giảm r hoặc w đổi lấy tốc độ nhưng có thể đọc dữ liệu cũ.⁸ DynamoDB cho chọn đọc eventually consistent hay strongly consistent, ở mức khái niệm tương tự.⁴
• Một key nóng chỉ chịu được tải của một nhóm node, nên thiết kế key phải trải đều tải.⁹ Giới hạn cụ thể mỗi partition của sản phẩm cần tra tài liệu.⁴

Data model: partition key, sort key và single-table design

Chọn key bắt đầu từ access pattern

Giống Cassandra, DynamoDB yêu cầu bạn liệt kê câu truy vấn trước: Microservices Patterns nhận xét thao tác truy cập dữ liệu của DynamoDB kém mạnh hơn RDBMS nên query thường quyết định schema.⁵ Ví dụ một hệ thống thương mại điện tử nhỏ cần:

1. Lấy hồ sơ user.
2. Lấy 20 đơn hàng mới nhất của user.
3. Lấy một đơn hàng và các dòng hàng của nó.
4. Tìm đơn hàng theo trạng thái để xử lý (ví dụ PENDING).

Single-table design

Thay vì mỗi entity một bảng, ta đặt nhiều loại entity vào một bảng, dùng PK/SK dạng chuỗi có tiền tố:

• Query 1: GetItem(PK=USER#42, SK=PROFILE).
• Query 2: Query(PK=USER#42, SK begins_with "ORDER#"), sắp giảm dần. Vì SK chứa ngày theo định dạng ISO, thứ tự chuỗi chính là thứ tự thời gian.
• Query 3: Query(PK=ORDER#A91).
• Query 4: cần một secondary index (xem dưới).¹⁰

Lợi ích: một request lấy được nhiều loại item liên quan, giống một join đã tính sẵn. Cái giá: mô hình khó đọc với người mới, và thêm access pattern mới về sau có thể phải backfill dữ liệu. Single-table design là thực hành riêng của cộng đồng DynamoDB, chưa có sách trong thư viện;⁴ điều sách có là việc lưu cả aggregate trong một item và chọn partition key + sort key theo query.⁵

Code mẫu (Node.js, AWS SDK v3)

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand, QueryCommand } from "@aws-sdk/lib-dynamodb";

const ddb = DynamoDBDocumentClient.from(new DynamoDBClient({ region: "ap-southeast-1" }));

// Tạo đơn hàng, chỉ thành công nếu chưa tồn tại (chống ghi trùng khi retry)
await ddb.send(new PutCommand({
  TableName: "shop",
  Item: { PK: "USER#42", SK: "ORDER#2026-11-02#A91", status: "PENDING", total: 350000 },
  ConditionExpression: "attribute_not_exists(PK)",
}));

// 20 đơn mới nhất của user
const { Items, LastEvaluatedKey } = await ddb.send(new QueryCommand({
  TableName: "shop",
  KeyConditionExpression: "PK = :pk AND begins_with(SK, :prefix)",
  ExpressionAttributeValues: { ":pk": "USER#42", ":prefix": "ORDER#" },
  ScanIndexForward: false,
  Limit: 20,
}));
// LastEvaluatedKey dùng làm cursor cho trang sau (ExclusiveStartKey)

ConditionExpression là công cụ quan trọng nhất cho tính đúng. Microservices Patterns dùng conditional update để bỏ qua sự kiện trùng (idempotency) và nhắc DynamoDB có cơ chế optimistic locking để tránh lost update.¹¹⁷ Dùng cho version = :expected hay stock >= :qty là áp dụng cùng cơ chế (ví dụ của khoá học).

GSI, LSI, Streams, TTL và transaction

Secondary index

Bảng chỉ truy cập nhanh theo primary key. Để có query theo thuộc tính khác (ví dụ lấy các đơn của một consumer theo thời gian), Microservices Patterns dùng một global secondary index với khoá (consumerId, orderCreationTime), không cần duy nhất. Index tự cập nhật khi bảng đổi và, khác index RDBMS, có thể mang thêm thuộc tính không thuộc khoá để query khỏi phải đọc bảng.¹⁰

Với access pattern 4 ở trên, ta thêm thuộc tính GSI1PK = STATUS#PENDING, GSI1SK = <ngày tạo> cho các đơn hàng đang chờ, rồi tạo index trên hai thuộc tính này. Khi đơn chuyển sang SHIPPED, xoá GSI1PK để item rời khỏi index (sparse index, kỹ thuật của cộng đồng DynamoDB).⁴

Sự khác nhau giữa GSI và LSI (thời điểm tạo, số lượng tối đa, mức consistency, capacity) là chi tiết sản phẩm, chưa có sách trong thư viện nên bài không liệt kê.⁴

DynamoDB Streams

Streams chứa chuỗi thay đổi theo thứ tự thời gian (tạo, sửa, xoá) trên các item của bảng trong 24 giờ gần nhất; ứng dụng đọc stream để, ví dụ, phát thành event.¹³ Dùng để:

• Kích hoạt xử lý phía sau: gửi email khi đơn hàng được tạo, cập nhật bộ đếm.
• Đồng bộ sang Elasticsearch hoặc data lake. Đây là một dạng Change Data Capture: Microservices Patterns liệt kê DynamoDB streams cùng Debezium và Databus trong nhóm cách đọc thay đổi từ database.¹³
• Làm nền cho outbox pattern: ghi item và để stream phát event, không cần dual write.¹³

TTL và transaction

TTL tự xoá item hết hạn và transaction ghi nguyên tử nhiều item đều là tính năng của sản phẩm, thư viện chưa có sách mô tả; hạn mức và chi phí cần tra tài liệu hiện hành.⁴ Nguyên tắc chung: dùng transaction cho các bất biến nhỏ như "trừ tồn kho và tạo đơn cùng lúc" (Flash sale, Đặt vé sự kiện), và đừng dùng để thay thế một hệ quan hệ. Microservices Patterns lưu ý nhiều NoSQL không hỗ trợ transaction phân tán, nên khi cần nhất quán nhiều service phải dùng saga.¹⁴

Capacity mode, hot partition và chi phí

Capacity mode

Microservices Patterns nói DynamoDB cho phép tăng giảm throughput capacity của bảng một cách động.¹ Thư viện chưa có sách về đơn vị đo, các chế độ capacity, quota hay giá nên bài không đưa con số.⁴ Nguyên tắc chọn (ước lượng của khoá học, cần so sánh với bảng giá hiện hành):

• Traffic khó đoán, sản phẩm mới: chọn chế độ trả theo request.
• Traffic ổn định, dự đoán được: chế độ đặt trước capacity thường rẻ hơn.
• Kích thước item ảnh hưởng chi phí ghi: tách phần lớn, ít đổi (mô tả dài, ảnh) ra object storage.
• Mỗi secondary index thêm chi phí ghi, vì ghi bảng chính phải cập nhật cả index.¹⁰

Hot partition

Hot partition xảy ra khi một PK nhận phần lớn traffic: một sản phẩm flash sale, một người nổi tiếng, một bộ đếm toàn cục. Vì partition key quyết định node lưu, dồn vào một key là dồn vào một nhóm node, dù tổng capacity của bảng còn dư.⁹

Cách xử lý:

• Write sharding: PRODUCT#99#0 ... PRODUCT#99#9, ghi ngẫu nhiên, đọc thì gộp. Đây là ý tưởng sharded counter của Grokking: chia một counter nóng thành nhiều shard rồi cộng lại khi đọc.¹² Xem Scale ghi.
• Cache đọc bằng Redis hoặc cache khác cho key đọc nhiều.
• Gom ghi trong bộ nhớ hoặc qua Kafka rồi ghi tổng định kỳ, thay vì tăng counter từng lượt.

Mốc đối chiếu: Grokking dùng khoảng 10.000 QPS cho một server key-value và độ trễ cùng datacenter cỡ 0,5 ms (số tham khảo, không phải giới hạn của DynamoDB).¹⁵

Khi nào dùng và khi nào không

Vận hành ở quy mô nhỏ và lớn

Thư viện chưa có sách về vận hành DynamoDB (backup, auto scaling, multi-region, công cụ giám sát), nên phần này chỉ nêu nguyên tắc.⁴

Quy mô nhỏ. Bắt đầu với chế độ trả theo request, một bảng, một hai index. Bật backup từ đầu và test bằng bản chạy local.

Quy mô lớn. Những việc cần làm:

• Chuyển bảng tải ổn định sang capacity đặt trước nếu rẻ hơn.
• Giám sát throttling và key nóng nhất.
• Multi-region: nhớ xung đột được giải quyết theo last-write-wins.¹⁶
• Phân tích bằng export thay vì quét bảng production.
• Đặt TTL cho dữ liệu tạm để không trả tiền lưu trữ mãi mãi.

Điểm nói chuyện trong phỏng vấn

Checklist:

1. Liệt kê access pattern, rồi mới đặt PK/SK.⁵
2. Dùng ConditionExpression cho idempotency và chống race condition.¹¹
3. Hot key: write sharding, cache, gom ghi.
4. Streams cho side effect và đồng bộ sang hệ khác.¹³
5. TTL cho dữ liệu tạm. Transaction cho bất biến nhỏ (giới hạn cụ thể tra tài liệu).
6. Chọn capacity mode theo hình dạng traffic, ước lượng chi phí theo kích thước item.

Các bài toán hay dùng DynamoDB hoặc key-value store tương tự:

• URL shortener: GetItem theo short code, đọc rất nhiều.
• Đặt vé sự kiện và Flash sale: conditional write và transaction để không bán quá.
• Rate limiter: bộ đếm theo key với TTL (thường đi cùng Redis).
• Dropbox: metadata file, nội dung lưu S3.
• Notification system: trạng thái gửi, idempotency key.
• Tinder: lưu lượt swipe theo user.

Nguồn trích dẫn

1. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4 Implementing a CQRS view with AWS DynamoDB, đoạn mở đầu (tr. 242). ↩ ↩²

2. Grokking Modern System Design · ch.9 Databases · mục "Key-value database" (trong "Types of NoSQL databases"). ↩ ↩² ↩³ ↩⁴

3. Grokking Modern System Design · ch.10 Key-value Store · thiết kế key-value store kiểu Dynamo. ↩

4. Chưa có nguồn trong thư viện: thư viện không có sách về kiến trúc nội bộ, giới hạn, giá hay tính năng chi tiết của DynamoDB (single-table design, GSI/LSI, TTL, transaction, capacity mode); phần này chỉ nêu khái niệm cơ bản, không đưa số liệu của sản phẩm. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²

5. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4.2 Data modeling and query design with DynamoDB, mục "Designing the ftgo-order-history table" (tr. 244–245). ↩ ↩² ↩³ ↩⁴ ↩⁵

6. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4.2, mục "Defining an index for the findOrderHistory query" (tr. 245–246): partition key, sort key, thao tác query(). ↩ ↩² ↩³ ↩⁴ ↩⁵

7. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4.2, mục "Paginating the query results" và "Updating orders" (tr. 247–248). ↩ ↩²

8. Grokking Modern System Design · ch.10 Key-value Store · mục "Usage of r and w" (r + w > n). ↩

9. Grokking Modern System Design · ch.9 Databases · mục "Sharding", "Hash-based sharding". ↩ ↩²

10. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4.2, mục "Defining an index for the findOrderHistory query" và "Implementing the findOrderHistory query" (tr. 246–247). ↩ ↩² ↩³

11. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.4.2, mục "Detecting duplicate events" (tr. 248–249). ↩ ↩²

12. Grokking Modern System Design · ch.24 Sharded Counters · mục "High-level solution sketch" và "Detailed design". ↩ ↩² ↩³

13. Microservices Patterns (file .zip, tải về giải nén) · ch.3 · §3.3.7 Transactional messaging, mục "Transaction log tailing" (DynamoDB streams) và "Polling publisher" cùng outbox (tr. 97–100). ↩ ↩² ↩³ ↩⁴

14. Microservices Patterns (file .zip, tải về giải nén) · ch.4 · §4.1.2 The trouble with distributed transactions: một số NoSQL như MongoDB và Cassandra không hỗ trợ chúng. ↩

15. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · mục "Standard numbers to remember". ↩

16. Grokking Modern System Design · ch.9 Databases · mục "Handle conflicts", "Last-write-wins". ↩ ↩²