DatabasesDatabases

Part of the Cloud knowledge base — AWS deep dive. Complements DevOps Roadmap.

Tổng quan

AWS cung cấp một database chuyên dụng cho mỗi hình dạng dữ liệu, và nước đi thắng cuộc là khớp database với mẫu truy cập thay vì ép mọi thứ vào một engine duy nhất. Cần giao dịch ACID và join? Một database quan hệ (RDS, Aurora). Cần tra cứu key với độ trễ vài mili-giây ở bất kỳ quy mô nào? Một kho key-value (DynamoDB). Cần cache dữ liệu nóng hoặc giữ session? Một kho in-memory (ElastiCache). Cần quét hàng tỷ dòng cho analytics? Một warehouse dạng cột (Redshift) hoặc truy vấn tại chỗ trên S3 (Athena). Bản năng quan-hệ-vs-mọi-thứ-khác từ thời on-prem chính là cái bẫy mà danh mục được quản lý của AWS cho phép bạn thoát ra.

Trang này bao gồm RDS (các engine quan hệ được quản lý, Multi-AZ vs read replica, parameter/option group), Aurora (MySQL/PostgreSQL cloud-native với Serverless v2 và Global Database), DynamoDB (partition/sort key, chế độ capacity, GSI/LSI, single-table design, DAX), ElastiCache (Redis/Memcached), và cặp analytics Redshift và Athena, cộng với DMS cho di chuyển. Nó kết thúc bằng hướng dẫn chọn một database và một bảng DynamoDB thực hành cùng các mẫu truy vấn.

Một cách nhìn hữu ích: các database được quản lý chuyển gánh nặng không tạo khác biệt — vá lỗi, backup, failover, replication — sang AWS, để bạn dành thời gian cho việc mô hình hóa dữ liệu và truy vấn, nơi có đòn bẩy thực sự. Phần khó không còn là vận hành database nữa; đó là chọn đúng cái và mô hình hóa dữ liệu cho khớp với thớ của nó. Một bảng DynamoDB được mô hình hóa tốt scale nhẹ nhàng; một bảng mô hình hóa tệ tạo hot-spot và bị throttle bất kể bạn trả bao nhiêu.

Tại sao lựa chọn database là quyết định dính chặt nhất

Trong mọi quyết định hạ tầng, database là cái khó đảo ngược nhất — dữ liệu có trọng lực, việc di chuyển rủi ro, và code ứng dụng ràng buộc chặt với mô hình dữ liệu. Một schema quan hệ bị ép lên một workload key-value sẽ bị throttle dưới tải; một kho key-value bị yêu cầu làm join tùy ý thì không làm được. Chọn đúng engine và mô hình hóa cho các thế mạnh của nó ngay từ ngày đầu tránh được lần tái nền tảng đau đớn nhất mà một đội có thể đối mặt. Đây là quyết định cần chậm lại và làm cho đúng.

Kiến thức nền tảng

RDS — Relational Database Service

RDS là các database quan hệ được quản lý: AWS lo provisioning, vá lỗi, backup và failover trong khi bạn có một SQL engine tiêu chuẩn. Các engine được hỗ trợ:

Engine	Ghi chú
PostgreSQL	Giàu tính năng, mở rộng được; mặc định phổ biến cho app mới
MySQL / MariaDB	Phổ biến khắp nơi, được hiểu rõ
Oracle / SQL Server	Các engine thương mại (BYOL hoặc bao gồm license) cho lift-and-shift
Aurora (tương thích MySQL/PostgreSQL)	Bản tái thiết kế cloud-native của AWS — đề cập bên dưới

Multi-AZ vs read replica — hai tính năng khác nhau mà người ta liên tục gộp lẫn:

	Multi-AZ	Read replica
Mục đích	Tính sẵn sàng cao / failover	Scale thông lượng đọc
Cách thức	Standby đồng bộ ở một AZ khác	Bản sao bất đồng bộ (cùng hoặc cross-Region)
Khi primary lỗi	Failover tự động sang standby (~60–120s)	Không failover tự động (replica là để đọc)
Đọc được?	Standby không đọc được (Multi-AZ instance); Multi-AZ cluster thêm các standby đọc được	Có — phục vụ lưu lượng đọc
Độ trễ (lag)	Không (đồng bộ)	Một chút (bất đồng bộ)

Dùng Multi-AZ cho tính sẵn sàng (database production luôn nên là Multi-AZ) và read replica cho scale đọc (giảm tải cho báo cáo, lưu lượng nặng đọc; promote một cái thành DB độc lập cho di chuyển hoặc DR). Chúng bổ trợ cho nhau — một database production thường vừa là Multi-AZ vừa có read replica.

Parameter group kiểm soát cấu hình engine (kích thước buffer, timeout, logging, max_connections) — tương đương được quản lý của việc sửa postgresql.conf/my.cnf. Một số thay đổi là động; số khác cần reboot. Option group bật các tính năng tùy chọn đặc thù engine (Oracle TDE, SQL Server Audit, v.v.). Cả hai đều được gắn vào instance và cho phép bạn version hóa và tái sử dụng cấu hình giữa các database.

Backup & khôi phục — RDS cho backup tự động hằng ngày với point-in-time recovery (khôi phục về bất kỳ giây nào trong cửa sổ giữ lại, tới 35 ngày) cộng với các snapshot thủ công. Storage tự động scale, và mã hóa lúc nghỉ (KMS) nên luôn được bật.

Aurora

Aurora là engine quan hệ cloud-native của AWS, tương thích ở mức giao thức với MySQL và PostgreSQL nhưng được tái kiến trúc: nó tách compute khỏi một lớp storage phân tán, tự chữa lành, replicate dữ liệu sáu chiều trên ba AZ và tự động scale tới 128 TiB. Kết quả là hiệu năng và tính sẵn sàng tốt hơn hẳn RDS thường, với failover nhanh hơn và tới 15 read replica độ-trễ-thấp dùng chung cùng storage (không có lag sao chép replication theo nghĩa truyền thống).

• Aurora Serverless v2 scale dung lượng (ACU) lên và xuống theo các bước tinh để phản hồi tải, bao gồm scale hướng về zero khi nhàn rỗi — lý tưởng cho các workload biến động, khó dự đoán, hoặc gián đoạn nơi bạn không muốn provision cho đỉnh. Bạn trả tiền cho dung lượng đã dùng thay vì một instance cố định.
• Aurora Global Database replicate một cluster tới tối đa năm Region thứ cấp với độ trễ thường <1 giây, cho khôi phục thảm họa cross-Region (RPO vài giây, RTO ~vài phút) và các lần đọc cục bộ độ trễ thấp trên toàn thế giới. Promote một Region thứ cấp khi có sự cố toàn vùng.
• Aurora vs RDS: chọn Aurora cho các workload đòi hỏi cao, hướng tăng trưởng, hoặc tính sẵn sàng cao và khi bạn muốn các tính năng serverless/global; chọn RDS thường cho các nhu cầu đơn giản hơn, các engine đặc biệt (Oracle/SQL Server), hoặc kiểm soát chi phí chặt hơn trên các database nhỏ, ổn định.

DynamoDB — NoSQL key-value được quản lý

DynamoDB là một database key-value và document serverless, được quản lý hoàn toàn, cho độ trễ vài mili-giây ở bất kỳ quy mô nào, không có server nào phải quản lý và thông lượng gần như không giới hạn. Đây là lựa chọn hàng đầu cho các workload quy mô lớn, tốc độ cao với các mẫu truy cập đã biết.

Key định nghĩa cách dữ liệu được phân vùng và sắp xếp:

• Partition key (hash key) — quyết định một item nằm trên phân vùng vật lý nào. DynamoDB băm nó để trải dữ liệu; một partition key tốt có độ phân biệt cao (cardinality) và truy cập đều để không phân vùng nào bị nện dồn (một “hot partition”).
• Sort key (range key, tùy chọn) — sắp xếp các item trong một phân vùng, cho phép truy vấn theo khoảng (begins_with, between, >) và mô hình hóa một-nhiều. Partition key + sort key cùng nhau tạo thành composite primary key.

Chế độ capacity — cách bạn trả tiền cho thông lượng:

Chế độ	Tính phí theo	Tốt nhất cho
On-Demand	Theo request	Lưu lượng biến động/chưa biết, app mới, không-muốn-quản-lý-capacity
Provisioned	RCU/WCU đã reserve (+ auto-scaling)	Lưu lượng dễ dự đoán, ổn định; rẻ hơn ở khối lượng cao ổn định

Bắt đầu bằng On-Demand; chuyển sang Provisioned với auto-scaling khi lưu lượng đã dự đoán được và khối lượng khiến mức reserved rẻ hơn.

Secondary index cho phép bạn truy vấn trên các thuộc tính không phải key:

	GSI (Global Secondary Index)	LSI (Local Secondary Index)
Partition key	Khác với bảng gốc	Giống bảng gốc
Khi tạo	Bất kỳ lúc nào	Chỉ lúc tạo bảng
Thông lượng	Capacity riêng của nó	Dùng chung capacity của bảng
Nhất quán	Chỉ nhất quán cuối cùng	Có nhất quán mạnh
Dùng	Mẫu truy vấn mới trên bất kỳ thuộc tính nào	Sắp xếp thay thế trong cùng phân vùng

GSI là con ngựa kéo — bạn thêm chúng để hỗ trợ các mẫu truy cập bổ sung. LSI là ngách hẹp và phải được định nghĩa từ trước.

Single-table design — mẫu chuẩn mực của DynamoDB là lưu nhiều loại thực thể (user, order, item) trong một bảng, dùng các thuộc tính PK/SK chung chung và các GSI được nạp chồng (overloaded) để phục vụ mọi mẫu truy cập với càng ít truy vấn càng tốt. Nó cảm giác xa lạ với người mô hình hóa SQL nhưng là cách bạn có được truy cập một-request tới dữ liệu liên quan ở quy mô lớn. Kỷ luật: liệt kê mọi mẫu truy cập trước, rồi thiết kế key để thỏa mãn chúng — DynamoDB thưởng cho việc biết trước các truy vấn của bạn và phạt việc truy vấn tùy ý.

DAX (DynamoDB Accelerator) là một cache in-memory đặt trước DynamoDB cho các lần đọc ở mức micro-giây cho các workload nặng đọc, nhạy độ trễ, với một API tương thích DynamoDB (drop-in, không cần viết lại app). Dùng nó khi ngay cả vài mili-giây cũng quá chậm hoặc để giảm chi phí đọc trên các item nóng.

Các tính năng khác đáng biết: TTL (tự hết hạn item theo timestamp — tuyệt cho session/dữ liệu tạm thời), DynamoDB Streams (change-data-capture cấp cho Lambda), global table (đa Region active-active), và transaction (ACID trên nhiều item).

ElastiCache — caching in-memory

ElastiCache là các kho dữ liệu in-memory được quản lý đặt trước database của bạn để cắt độ trễ và giảm tải đọc. Hai engine:

	Redis (và Valkey)	Memcached
Cấu trúc dữ liệu	Phong phú (string, hash, list, set, sorted set, stream, pub/sub)	Chỉ key-value đơn giản
Persistence	Tùy chọn (snapshot, AOF)	Không (cache thuần)
Replication / HA	Có (replica, Multi-AZ, cluster mode)	Không (sharded, không replication)
Dùng cho	Bảng xếp hạng, session, queue, caching phong phú, nhu cầu HA	Cache object đơn giản, scale ngang

Chọn Redis cho gần như mọi thứ — nó có năng lực hơn, hỗ trợ HA và persistence, và làm nhiều hơn caching (rate limiting, bảng xếp hạng, pub/sub, kho session). Memcached chỉ hợp trường hợp hẹp của một cache đơn giản, đa luồng, sharded không cần replication hay cấu trúc dữ liệu. Các mẫu phổ biến: cache-aside (app kiểm tra cache, rơi về DB khi miss, nạp cache), và dùng Redis cho lưu trữ session để các app server giữ trạng thái không có (stateless).

Redshift và Athena — analytics

Khi bạn cần phân tích khối lượng lớn thay vì phục vụ giao dịch, các database OLTP là công cụ sai.

Redshift là một data warehouse dạng cột, song song ồ ạt (MPP) được quản lý cho analytics quy mô petabyte — các phép tổng hợp và join phức tạp trên hàng tỷ dòng, cấp cho các dashboard BI. Storage dạng cột và MPP làm các lần quét phân tích nhanh. Redshift Serverless loại bỏ việc quản lý cluster (trả theo mức dùng), và Redshift Spectrum truy vấn dữ liệu trực tiếp trong S3. Dùng nó làm warehouse trung tâm cho analytics có cấu trúc với tải truy vấn liên tục.

Athena là truy vấn SQL serverless trực tiếp trên dữ liệu trong S3 — không cluster, không load. Trỏ nó vào S3 (CSV, JSON, Parquet), định nghĩa một schema (qua Glue Data Catalog), và trả theo TB đã quét. Lý tưởng cho các truy vấn tùy ý, phân tích log, và analytics không thường xuyên nơi việc dựng lên một warehouse không đáng. Dùng các định dạng cột (Parquet/ORC) và phân vùng để cắt mạnh lượng dữ liệu được quét — và do đó cả chi phí.

Redshift vs Athena: Athena cho các truy vấn thỉnh thoảng, tùy ý, hoặc khám phá trên S3 với không hạ tầng; Redshift cho warehousing liên tục, đồng thời cao, quan trọng về hiệu năng. Nhiều kiến trúc dùng cả hai — Athena trên data lake S3 thô, Redshift cho các mart đã tinh chế, được truy vấn nặng.

DMS — Database Migration Service

DMS di chuyển database sang AWS với downtime tối thiểu: nó replicate từ một nguồn (on-prem hoặc cloud, hầu hết engine) tới một đích, hỗ trợ di chuyển đồng nhất (Oracle→Oracle) và khác chủng (Oracle→Aurora PostgreSQL, ghép với Schema Conversion Tool). Replication liên tục (CDC) của nó giữ nguồn và đích đồng bộ trong lúc cutover, để bạn di chuyển các hệ thống đang sống với một cửa sổ chuyển đổi ngắn. Dùng nó cho lift-and-shift sang RDS/Aurora, hiện đại hóa xuyên engine, và replication liên tục vào một data lake.

Khái niệm chính

Chọn một database: quan hệ vs KV vs analytics

Khớp engine với mẫu truy cập, không theo thói quen.

Nhu cầu	Chọn	Tại sao
Giao dịch ACID, join, SQL tùy ý, quy mô vừa	RDS / Aurora	Toàn vẹn quan hệ, truy vấn linh hoạt
Quan hệ cloud-native, quy mô/HA cao, serverless hoặc global	Aurora	Storage phân tán, failover nhanh, serverless v2
Key-value/document ở quy mô khổng lồ, mẫu truy cập đã biết, độ trễ ms	DynamoDB	Serverless, thông lượng không giới hạn, độ trễ dễ dự đoán
Cache, session, bảng xếp hạng, rate limiting	ElastiCache (Redis)	Truy cập in-memory micro-giây
Analytics petabyte, BI, tổng hợp phức tạp	Redshift	Warehouse MPP dạng cột
SQL tùy ý trên S3, phân tích log, không hạ tầng	Athena	Truy vấn tại-chỗ serverless
Tìm kiếm full-text/vector, tìm kiếm log	OpenSearch	Search engine dạng inverted-index
Quan hệ đồ thị, sổ cái, chuỗi thời gian	Neptune / QLDB / Timestream	Các engine chuyên biệt chuyên dụng

Kinh nghiệm ra quyết định:

1. Bạn cần join, giao dịch, và SQL tùy ý? → Quan hệ (Aurora nếu bạn muốn scale/HA/serverless; RDS nếu không).
2. Bạn biết các mẫu truy cập của mình và cần quy mô khổng lồ với độ trễ dễ dự đoán? → DynamoDB (và mô hình hóa cho các mẫu đó từ trước).
3. Bạn đang giảm tải đọc hoặc lưu trạng thái nóng tạm thời? → ElastiCache đặt trước hệ thống bản ghi gốc.
4. Bạn đang phân tích khối lượng lớn, không phục vụ giao dịch? → Athena (thỉnh thoảng, S3) hoặc Redshift (warehouse liên tục).

Cạm bẫy: dùng DynamoDB khi bạn thực sự cần join tùy ý và truy vấn linh hoạt (bạn sẽ vật lộn với nó); chạy các lần quét phân tích trên RDS OLTP của bạn (nó sẽ làm nghẹt các giao dịch — replicate sang một warehouse); provision DynamoDB trước khi bạn biết các mẫu truy cập (bạn sẽ hot-partition); và coi một cache như một hệ thống bản ghi gốc (cache được phép mất dữ liệu).

Ví dụ thực hành: bảng DynamoDB + các mẫu truy vấn

Một single-table design cho một app thương mại điện tử, phục vụ nhiều mẫu truy cập từ một bảng. Đầu tiên, các mẫu truy cập chúng ta thiết kế cho:

1. Lấy một user theo ID.
2. Lấy mọi order của một user (mới nhất trước).
3. Lấy một order đơn theo ID.
4. Lấy mọi order ở một trạng thái cho trước (khung nhìn admin).

Thiết kế key — PK/SK được nạp chồng, với một GSI cho truy vấn trạng thái:

Thực thể	PK	SK	GSI1PK	GSI1SK
User	USER#u123	USER#u123	—	—
Order	USER#u123	ORDER#2026-07-18#o987	STATUS#SHIPPED	2026-07-18

Tạo bảng với một GSI (CLI):

aws dynamodb create-table \
  --table-name Commerce \
  --attribute-definitions \
      AttributeName=PK,AttributeType=S \
      AttributeName=SK,AttributeType=S \
      AttributeName=GSI1PK,AttributeType=S \
      AttributeName=GSI1SK,AttributeType=S \
  --key-schema \
      AttributeName=PK,KeyType=HASH \
      AttributeName=SK,KeyType=RANGE \
  --global-secondary-indexes \
      '[{"IndexName":"GSI1",
         "KeySchema":[{"AttributeName":"GSI1PK","KeyType":"HASH"},
                      {"AttributeName":"GSI1SK","KeyType":"RANGE"}],
         "Projection":{"ProjectionType":"ALL"}}]' \
  --billing-mode PAY_PER_REQUEST

PAY_PER_REQUEST là On-Demand — không có capacity phải quản lý khi lưu lượng còn chưa biết.

Các mẫu truy vấn:

# Pattern 1 & 2: get the user AND all their orders in ONE query.
# The user item and all order items share PK=USER#u123, so a single
# partition query returns everything; sort key ordering gives newest-first.
aws dynamodb query \
  --table-name Commerce \
  --key-condition-expression "PK = :pk" \
  --expression-attribute-values '{":pk":{"S":"USER#u123"}}' \
  --scan-index-forward false            # descending: most recent orders first

# Pattern 2 only: just the orders (SK begins with ORDER#)
aws dynamodb query \
  --table-name Commerce \
  --key-condition-expression "PK = :pk AND begins_with(SK, :o)" \
  --expression-attribute-values '{":pk":{"S":"USER#u123"},":o":{"S":"ORDER#"}}'

# Pattern 4: all SHIPPED orders (admin) — served by the GSI
aws dynamodb query \
  --table-name Commerce \
  --index-name GSI1 \
  --key-condition-expression "GSI1PK = :s" \
  --expression-attribute-values '{":s":{"S":"STATUS#SHIPPED"}}'

Điều cốt lõi: bởi vì user và các order của họ dùng chung một partition key, “lấy user + các order của họ” là một truy vấn duy nhất không có join — mẫu mà SQL sẽ cần nhiều vòng round-trip hoặc một join, DynamoDB làm trong một request. GSI đánh chỉ mục lại các order theo trạng thái nên khung nhìn admin cũng hiệu quả tương đương. Đây là single-table design thu nhỏ: liệt kê các mẫu truy cập, rồi định hình key và index sao cho mỗi mẫu là một truy vấn rẻ — không bao giờ là một Scan, thứ đọc cả bảng và là anti-pattern kinh điển của DynamoDB.

Best Practices

1. Luôn chạy RDS/Aurora production Multi-AZ — một database single-AZ biến việc bảo trì thường lệ hoặc một cú chớp AZ thành một sự cố. Multi-AZ cho failover tự động với một khoản phụ phí khiêm tốn; đó là mốc cơ sở cho bất cứ thứ gì bạn không thể để mất.
2. Tách các lần đọc bằng replica, đừng nhầm chúng với HA — Multi-AZ là cho tính sẵn sàng, read replica là cho thông lượng đọc. Giảm tải báo cáo và lưu lượng nặng đọc sang replica, và để dành primary cho ghi và các lần đọc nhất quán.
3. Mã hóa lúc nghỉ và khi truyền, luôn luôn — bật mã hóa KMS khi tạo database (nó không thể được thêm vào một RDS instance chưa mã hóa hiện có mà không snapshot-restore) và ép buộc kết nối TLS. Đây là điều kiện tối thiểu cho bất kỳ kho dữ liệu nào.
4. Không bao giờ đặt database trong public subnet — đặt RDS/Aurora/ElastiCache trong private subnet, chỉ tiếp cận được từ các security group của app. Một database mở ra internet là một vụ vi phạm đang chờ xảy ra; truy cập nó qua một bastion hoặc SSM, không bao giờ trực tiếp.
5. Quản lý credential bằng Secrets Manager và xoay vòng chúng — lưu credential DB trong Secrets Manager với xoay vòng tự động, và ưu tiên IAM database authentication nơi được hỗ trợ để các app nhận token ngắn hạn thay vì mật khẩu tĩnh.
6. Liệt kê các mẫu truy cập DynamoDB trước khi mô hình hóa — DynamoDB thưởng cho việc biết mọi truy vấn từ trước và phạt truy cập tùy ý. Thiết kế partition/sort key và GSI để phục vụ mỗi mẫu như một truy vấn; một Scan trên đường nóng nghĩa là mô hình sai.
7. Chọn partition key có cardinality cao và truy cập đều — một key cardinality thấp hoặc lệch tạo ra các hot partition bị throttle bất kể bạn mua bao nhiêu capacity. Trải tải; thêm hậu tố/sharding nếu một key tự nhiên tập trung lưu lượng.
8. Bắt đầu DynamoDB bằng On-Demand, chuyển sang Provisioned khi lưu lượng dễ dự đoán — On-Demand loại bỏ việc đoán capacity cho các workload mới/biến động; chuyển sang Provisioned với auto-scaling khi khối lượng đủ ổn định để mức reserved tiết kiệm tiền.
9. Cache bằng ElastiCache để bảo vệ hệ thống bản ghi gốc — đặt Redis (cache-aside) trước các database nặng đọc để cắt độ trễ và giảm tải, và giữ session trong Redis để các app server giữ trạng thái không có. Thiết kế cho các lần cache miss và coi cache là có thể vứt bỏ.
10. Ưu tiên Redis (Valkey) hơn Memcached — Redis cho HA, persistence, và cấu trúc dữ liệu phong phú; Memcached chỉ hợp trường hợp cache-sharded-đơn-giản hẹp. Mặc định dùng Redis trừ khi bạn có lý do cụ thể để không.
11. Right-size và giám sát; bật Performance Insights — bật RDS/Aurora Performance Insights và CloudWatch để bắt các truy vấn chậm, bão hòa kết nối, và under/over-provisioning. Database thường bị over-provision về compute và under-tune về truy vấn.
12. Tự động hóa backup và test khôi phục; sao chép các backup quan trọng cross-Region — backup tự động và PITR bật theo mặc định, nhưng một backup chưa được test là một hy vọng, không phải một kế hoạch. Định kỳ khôi phục, và sao chép các snapshot quan trọng cho DR sang một Region/tài khoản thứ hai.
13. Dùng Aurora Serverless v2 cho các workload biến động hoặc gián đoạn — nó scale dung lượng (hướng về zero khi nhàn rỗi) nên bạn trả cho tải, không phải provision đỉnh. Lý tưởng cho dev/test, lưu lượng biến động, và hợp nhất nhiều database nhỏ.
14. Chọn công cụ analytics theo tần suất truy vấn — Athena cho SQL tùy ý/thỉnh thoảng trên S3 với không hạ tầng; Redshift cho warehousing liên tục, đồng thời cao. Không bao giờ chạy các lần quét phân tích trên database OLTP của bạn — thay vào đó replicate sang warehouse.
15. Tối ưu chi phí Athena và warehouse bằng định dạng cột và phân vùng — lưu dữ liệu dạng Parquet/ORC và phân vùng theo các bộ lọc phổ biến (ngày, region) để cắt số byte được quét, thứ chính xác là cái Athena tính phí. Điều này thường xuyên giảm chi phí cả một bậc độ lớn.
16. Dùng DMS cho các di chuyển ít downtime, với CDC cho cutover — DMS cộng với Schema Conversion Tool xử lý hiện đại hóa xuyên engine, và replication liên tục giữ nguồn và đích đồng bộ để cửa sổ chuyển đổi giữ ngắn.

Tài liệu tham khảo

• roadmap.sh — DevOps Roadmap
• Amazon RDS Documentation
• RDS Multi-AZ Deployments
• RDS Read Replicas
• RDS Parameter Groups
• Amazon Aurora Documentation
• Aurora Serverless v2
• Aurora Global Database
• Amazon DynamoDB Documentation
• DynamoDB Core Components (keys, indexes)
• DynamoDB Single-Table Design & Best Practices
• DynamoDB Accelerator (DAX)
• Amazon ElastiCache Documentation
• Amazon Redshift Documentation
• Amazon Athena Documentation
• AWS Database Migration Service (DMS)
• AWS Secrets Manager — RDS rotation

aws dynamodb create-table \
  --table-name Commerce \
  --attribute-definitions \
      AttributeName=PK,AttributeType=S \
      AttributeName=SK,AttributeType=S \
      AttributeName=GSI1PK,AttributeType=S \
      AttributeName=GSI1SK,AttributeType=S \
  --key-schema \
      AttributeName=PK,KeyType=HASH \
      AttributeName=SK,KeyType=RANGE \
  --global-secondary-indexes \
      '[{"IndexName":"GSI1",
         "KeySchema":[{"AttributeName":"GSI1PK","KeyType":"HASH"},
                      {"AttributeName":"GSI1SK","KeyType":"RANGE"}],
         "Projection":{"ProjectionType":"ALL"}}]' \
  --billing-mode PAY_PER_REQUEST

# Pattern 1 & 2: get the user AND all their orders in ONE query.
# The user item and all order items share PK=USER#u123, so a single
# partition query returns everything; sort key ordering gives newest-first.
aws dynamodb query \
  --table-name Commerce \
  --key-condition-expression "PK = :pk" \
  --expression-attribute-values '{":pk":{"S":"USER#u123"}}' \
  --scan-index-forward false            # descending: most recent orders first

# Pattern 2 only: just the orders (SK begins with ORDER#)
aws dynamodb query \
  --table-name Commerce \
  --key-condition-expression "PK = :pk AND begins_with(SK, :o)" \
  --expression-attribute-values '{":pk":{"S":"USER#u123"},":o":{"S":"ORDER#"}}'

# Pattern 4: all SHIPPED orders (admin) — served by the GSI
aws dynamodb query \
  --table-name Commerce \
  --index-name GSI1 \
  --key-condition-expression "GSI1PK = :s" \
  --expression-attribute-values '{":s":{"S":"STATUS#SHIPPED"}}'