DatabasesDatabases

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

Tổng quan

Google Cloud có một database cho mọi mô hình dữ liệu. Chọn tốt nghĩa là khớp hình dạng dữ liệu, nhu cầu về tính nhất quán, quy mô, và pattern truy vấn của bạn với đúng engine — dùng một DB quan hệ cho analytics hay một DB document cho các join đều là những sai lầm tốn kém.

Nhóm	Dịch vụ	Mô hình dữ liệu	Tương đương AWS
Quan hệ (OLTP)	Cloud SQL	MySQL / PostgreSQL / SQL Server	RDS
Quan hệ (hiệu năng cao)	AlloyDB	Tương thích PostgreSQL	Aurora (PostgreSQL)
Quan hệ (toàn cầu)	Cloud Spanner	SQL scale ngang	Lai Aurora / DynamoDB
Document	Firestore	Document (collection/doc)	DynamoDB / DocumentDB
Wide-column	Bigtable	Key → hàng rộng, NoSQL	DynamoDB / Keyspaces
Analytics (OLAP)	BigQuery	Data warehouse dạng cột	Redshift / Athena
Cache in-memory	Memorystore	Redis / Memcached	ElastiCache

Phân chia bậc nhất: hệ thống giao dịch (OLTP) phục vụ nhiều lần đọc/ghi nhỏ với độ trễ thấp; hệ thống phân tích (OLAP) quét khối lượng khổng lồ để tổng hợp. Đừng chạy analytics trên database OLTP của bạn.

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

Cloud SQL

Cloud SQL là MySQL, PostgreSQL, và SQL Server được quản lý — Google lo việc provisioning, patching, backup, replication, và failover, trong khi bạn có một SQL engine tiêu chuẩn.

Các khả năng chính:

• High Availability (HA) — cấu hình regional giữ một standby đồng bộ ở zone khác; khi có sự cố nó tự động failover. Xấp xỉ gấp đôi chi phí nhưng cho một SLA mạnh.
• Read replicas — các replica bất đồng bộ (cùng hoặc cross-region) để chia tải đọc. Chúng không dùng cho HA (do lag bất đồng bộ) nhưng scale đọc và cho phép đọc gần người dùng.
• Backup tự động + point-in-time recovery (PITR) — backup hàng ngày cộng binary/WAL log cho phép khôi phục về một thời điểm cụ thể.
• Kết nối — private IP (VPC), public IP với authorized network, hoặc Cloud SQL Auth Proxy / connector để truy cập an toàn dựa trên IAM mà không cần mở network.

# Tạo một instance PostgreSQL HA với backup tự động
gcloud sql instances create orders-db \
  --database-version=POSTGRES_16 \
  --tier=db-custom-4-16384 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --enable-point-in-time-recovery

# Thêm một read replica
gcloud sql instances create orders-db-replica \
  --master-instance-name=orders-db \
  --region=us-east1

Khi nào dùng: mặc định cho các workload quan hệ truyền thống dưới ngưỡng scale một region (tới hàng chục TB, single-writer). Cạm bẫy: một primary duy nhất là nút thắt ghi — Cloud SQL scale đọc, không scale ghi, vượt quá một node.

AlloyDB (tóm tắt)

AlloyDB là một engine tương thích PostgreSQL tách rời compute và storage, thêm một accelerator dạng cột in-memory cho các truy vấn phân tích, và cho throughput cao hơn nhiều cùng đọc nhanh hơn so với Cloud SQL Postgres tiêu chuẩn. Dùng nó khi bạn đã vượt quá Cloud SQL Postgres về hiệu năng nhưng muốn giữ tương thích PostgreSQL và single-region (hoặc với replica cross-region). Đây là đối thủ Aurora của Google.

Cloud Spanner

Cloud Spanner là một database quan hệ scale ngang, phân tán toàn cầu cung cấp tính nhất quán ngoài (external consistency) mạnh và SQL quan hệ với schema và secondary index — không cần quản lý sharding. Nó scale ghi và đọc bằng cách thêm node và có thể trải qua các region/châu lục trong khi vẫn nhất quán (nhờ TrueTime).

• Khi nào dùng: bạn cần ngữ nghĩa quan hệ và scale ngang gần như không giới hạn, dấu chân toàn cầu, tính sẵn sàng 99.999%, và không thể chấp nhận ngưỡng single-writer của Cloud SQL (vd tồn kho toàn cầu, sổ cái tài chính, bảng xếp hạng game).
• Cạm bẫy: chi phí và kỷ luật thiết kế — bạn phải chọn primary key tốt để tránh hotspot (tránh key tăng đơn điệu). Quá mức cần thiết cho các ứng dụng nhỏ single-region.

Firestore / Datastore

Firestore là một document database serverless, tự động scale (các collection chứa document, kiểu JSON). Nó cung cấp real-time listener, đồng bộ offline cho mobile/web, và tính nhất quán mạnh. Datastore là phiên bản tiền nhiệm; Firestore ở chế độ Datastore là kế thừa cho các workload server.

// Mô hình dữ liệu Firestore — một collection "users" với subcollection lồng nhau
// users/{userId}
{
  displayName: "Ada",
  email: "ada@example.com",
  createdAt: Timestamp,
  plan: "pro"
}
// users/{userId}/orders/{orderId}   (subcollection)
{
  total: 42.50,
  status: "shipped",
  items: [{ sku: "A1", qty: 2 }]
}

// Truy vấn: các đơn đã giao của người dùng này, mới nhất trước
const snap = await db.collection(`users/${uid}/orders`)
  .where("status", "==", "shipped")
  .orderBy("createdAt", "desc")
  .limit(20)
  .get();

Khi nào dùng: backend cho ứng dụng mobile/web, profile người dùng, ứng dụng real-time, schema thay đổi nhanh. Cạm bẫy: truy vấn phải được hỗ trợ bởi index và không thể join tùy ý hay tổng hợp qua các collection — hãy mô hình hóa dữ liệu quanh pattern đọc, và denormalize.

Bigtable

Cloud Bigtable là một database wide-column NoSQL cho các workload khổng lồ, độ trễ thấp, throughput cao (petabyte, hàng triệu ops/giây ở độ trễ mili-giây một chữ số). Đây là engine phía sau Search, Maps, và Analytics, và nói giao thức HBase API.

• Dữ liệu là một map khổng lồ được sắp xếp, khóa bởi một row key duy nhất; thiết kế row key để khớp pattern truy vấn (truy vấn là quét dải row-key, không phải SQL tùy ý).
• Khi nào dùng: time-series, telemetry IoT, ad-tech, tick tài chính, cá nhân hóa — lượng ghi khổng lồ và tra cứu theo key.
• Cạm bẫy: không có secondary index, không join, không transaction qua các hàng (chỉ atomic một hàng). Thiết kế row-key kém tạo hotspot.

BigQuery

BigQuery là một data warehouse serverless dạng cột cho analytics. Bạn load hoặc stream dữ liệu và chạy SQL trên terabyte/petabyte mà không quản lý hạ tầng — storage và compute tách rời và scale độc lập.

Các mô hình giá:

• On-demand — trả theo mỗi TB được quét bởi từng truy vấn.
• Capacity (slot) — đặt trước compute (slot) cho các workload có thể dự đoán, khối lượng lớn.

Partitioning và clustering là các đòn bẩy chi phí/hiệu năng chính: partitioning (thường theo ngày) cắt bỏ toàn bộ partition để truy vấn quét ít dữ liệu hơn; clustering sắp xếp dữ liệu trong partition theo các cột đã chọn để giảm thêm số byte được quét.

-- Tạo một bảng partitioned + clustered
CREATE TABLE analytics.events
(
  event_time TIMESTAMP,
  user_id    STRING,
  event_type STRING,
  country    STRING,
  revenue    NUMERIC
)
PARTITION BY DATE(event_time)
CLUSTER BY event_type, country;

-- Một truy vấn chỉ quét partition của một ngày và các cột clustered
SELECT country, COUNT(*) AS purchases, SUM(revenue) AS total
FROM analytics.events
WHERE DATE(event_time) = '2026-07-17'   -- cắt xuống một partition
  AND event_type = 'purchase'           -- dùng clustering
GROUP BY country
ORDER BY total DESC;

Khi nào dùng: dashboard, analytics ad-hoc, ELT, ML trên dữ liệu có cấu trúc (BigQuery ML). Cạm bẫy: SELECT * và quét toàn bộ không partition là thứ làm phình hóa đơn on-demand — luôn lọc theo cột partition và chỉ chọn các cột cần thiết.

Memorystore

Memorystore là Redis (và Memcached) được quản lý cho cache in-memory, session store, bảng xếp hạng, và pub/sub. Nó cung cấp HA (Redis với replica + failover tự động), scaling, và patching. Dùng nó trước Cloud SQL/Spanner/Firestore để hấp thụ các lần đọc nóng và cắt độ trễ xuống dưới mili-giây.

Khái niệm chính

Chọn một database

1. ?Truy vấn phân tích / data warehouse / dashboard trên dữ liệu khổng lồ?
   Có

   BigQueryOLAP serverless; partition + cluster
2. ?Cần SQL quan hệ (join, transaction, schema)? Scale toàn cầu + ghi ngang + nhất quán mạnh?
   Có

   Cloud Spanner
3. ?Cần SQL quan hệ? Vượt Postgres về hiệu năng, vẫn kiểu single-region?
   Có

   AlloyDB
4. ?Cần SQL quan hệ? OLTP single-region tiêu chuẩn (MySQL/Postgres/SQLServer)?
   Có

   Cloud SQL
5. ?Mô hình document, backend mobile/web, real-time, schema linh hoạt?
   Có

   Firestore
6. ?NoSQL theo key khổng lồ, time-series/IoT, throughput ghi khổng lồ?
   Có

   Bigtable
7. ?Chỉ cần một cache / session store / bảng xếp hạng?
   Có

   MemorystoreRedis

Đánh đổi giữa nhất quán và quy mô

Dịch vụ	Nhất quán	Scale ghi	Linh hoạt truy vấn
Cloud SQL	Mạnh (một primary)	Một node (dọc)	SQL đầy đủ
AlloyDB	Mạnh (một primary)	Một node + read pool	SQL đầy đủ
Spanner	Mạnh, external	Ngang (thêm node)	SQL (một số giới hạn)
Firestore	Mạnh theo document	Ngang (tự động)	Hạn chế (có index)
Bigtable	Mạnh theo hàng	Ngang (thêm node)	Chỉ quét row-key
BigQuery	Không áp dụng (analytics)	Không áp dụng	SQL đầy đủ (OLAP)

Quan hệ vs document vs wide-column vs analytics

• Quan hệ — dữ liệu chuẩn hóa với join, transaction, và schema chặt chẽ. Tốt nhất khi tính toàn vẹn và truy vấn phức tạp quan trọng (đơn hàng, thanh toán, tồn kho).
• Document — các bản ghi tự chứa có hình dạng như object ứng dụng của bạn; tuyệt cho dữ liệu linh hoạt/lồng nhau và truy cập đọc-theo-key.
• Wide-column — một kho key→hàng khổng lồ được sắp xếp; vô địch cho quy mô lớn và truy cập theo key nhưng không có join.
• Analytics (dạng cột) — tối ưu cho quét và tổng hợp hàng tỷ hàng; tệ cho OLTP mức hàng.

Best Practices

1. Dùng Cloud SQL HA (regional) cho production. Lý do: một standby đồng bộ ở zone khác với failover tự động là khác biệt giữa một cú chớp và một sự cố; chi phí thêm mua được một SLA thực sự.

2. Chia tải đọc sang replica, nhưng đừng bao giờ coi chúng là HA. Lý do: replica bất đồng bộ scale tải đọc và cho phép đọc gần người dùng, nhưng replication lag nghĩa là chúng không thể đảm bảo mất dữ liệu bằng không khi failover.

3. Bật backup tự động và PITR, và test khôi phục. Lý do: backup bạn chưa từng khôi phục là một hy vọng, không phải một kế hoạch; PITR giới hạn mất dữ liệu xuống vài phút.

4. Kết nối qua private IP và Cloud SQL Auth Proxy / connector. Lý do: giữ database tránh xa internet công cộng và dùng credential IAM ngắn hạn thay vì mật khẩu tĩnh trên các port mở.

5. Chọn Spanner chỉ khi bạn thực sự cần scale toàn cầu + nhất quán mạnh. Lý do: nó loại bỏ nỗi đau sharding ở quy mô thực, nhưng tốn kém và quá mức cần thiết cho các ứng dụng single-region mà Cloud SQL xử lý tốt.

6. Thiết kế key của Spanner/Bigtable để tránh hotspot. Lý do: key tăng đơn điệu (timestamp, ID tuần tự) dồn mọi lần ghi vào một server; dùng key hash/đảo/prefix để trải tải.

7. Partition và cluster các bảng BigQuery. Lý do: cắt partition và clustering giảm số byte được quét đi nhiều bậc — động lực chính của cả chi phí và tốc độ truy vấn.

8. Không bao giờ SELECT * trong BigQuery; lọc theo cột partition. Lý do: lưu trữ dạng cột nghĩa là bạn trả tiền cho các cột và partition được quét; chỉ chọn cái cần và cắt partition trực tiếp giảm hóa đơn.

9. Dùng capacity (slot) reservation của BigQuery cho các workload nặng ổn định. Lý do: analytics có thể dự đoán, khối lượng lớn rẻ hơn và ổn định hơn trên slot đặt trước so với giá on-demand theo TB.

10. Mô hình hóa Firestore quanh pattern đọc và denormalize. Lý do: Firestore không thể join hay tổng hợp qua các collection; cấu trúc document/subcollection theo truy vấn của bạn (và nhân bản dữ liệu) là cách giữ đọc nhanh và rẻ.

11. Đặt Memorystore trước các lần đọc nóng. Lý do: cache các truy vấn thường xuyên, tốn kém trong Redis cắt độ trễ xuống dưới mili-giây và giảm tải database chính, cải thiện cả chi phí và tính bền vững.

12. Chọn đúng engine, đừng ép một cái làm mọi thứ. Lý do: chạy analytics trên Cloud SQL hay join trên Bigtable là chống lại công cụ; khớp mô hình dữ liệu với workload tránh việc re-platform đau đớn về sau.

13. Right-size Cloud SQL và bật storage auto-increase. Lý do: tier over-provision lãng phí tiền trong khi storage under-provision gây sự cố; auto-increase ngăn sự cố đầy đĩa.

14. Dùng CMEK và ép mã hóa/TLS khi truyền cho dữ liệu bị quản chế. Lý do: key do khách hàng quản lý cộng kết nối SSL bắt buộc thỏa mãn compliance và kiềm chế bán kính ảnh hưởng của một credential rò rỉ.

15. Đặt maintenance window và theo dõi chúng trong monitoring. Lý do: kiểm soát thời điểm restart liên quan tới patch để chúng rơi vào khung giờ ít lưu lượng thay vì bất ngờ vào giờ cao điểm.

16. Theo dõi replication lag, truy vấn chậm, và số lượng kết nối. Lý do: đây là các metric cảnh báo sớm cho rắc rối database; cạn kiệt kết nối và lag gây ra hầu hết sự cố managed-DB.

Tài liệu tham khảo

• Cloud SQL documentation
• Cloud SQL high availability
• Cloud SQL read replicas
• Cloud SQL Auth Proxy
• AlloyDB for PostgreSQL
• Cloud Spanner documentation
• Spanner schema and key design
• Firestore documentation
• Firestore data model
• Cloud Bigtable documentation
• Bigtable schema design
• BigQuery documentation
• BigQuery partitioned tables
• BigQuery clustered tables
• Memorystore for Redis
• Choosing a database (Google Cloud)

# Create a HA PostgreSQL instance with automated backups
gcloud sql instances create orders-db \
  --database-version=POSTGRES_16 \
  --tier=db-custom-4-16384 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --storage-auto-increase \
  --backup-start-time=03:00 \
  --enable-point-in-time-recovery

# Add a read replica
gcloud sql instances create orders-db-replica \
  --master-instance-name=orders-db \
  --region=us-east1

// Firestore data model — a "users" collection with nested subcollection
// users/{userId}
{
  displayName: "Ada",
  email: "ada@example.com",
  createdAt: Timestamp,
  plan: "pro"
}
// users/{userId}/orders/{orderId}   (subcollection)
{
  total: 42.50,
  status: "shipped",
  items: [{ sku: "A1", qty: 2 }]
}

// Query: this user's shipped orders, newest first
const snap = await db.collection(`users/${uid}/orders`)
  .where("status", "==", "shipped")
  .orderBy("createdAt", "desc")
  .limit(20)
  .get();

-- Create a partitioned + clustered table
CREATE TABLE analytics.events
(
  event_time TIMESTAMP,
  user_id    STRING,
  event_type STRING,
  country    STRING,
  revenue    NUMERIC
)
PARTITION BY DATE(event_time)
CLUSTER BY event_type, country;

-- A query that only scans one day's partition and the clustered columns
SELECT country, COUNT(*) AS purchases, SUM(revenue) AS total
FROM analytics.events
WHERE DATE(event_time) = '2026-07-17'   -- prunes to one partition
  AND event_type = 'purchase'           -- uses clustering
GROUP BY country
ORDER BY total DESC;