PostgreSQL

PostgreSQL là gì và vì sao là lựa chọn mặc định

PostgreSQL là database quan hệ mã nguồn mở, có lịch sử từ dự án Postgres ở Berkeley. Nó cho bạn:

• ACID đầy đủ: transaction, foreign key, unique constraint, check constraint. Seven Databases định nghĩa ACID là Atomic, Consistent, Isolated, Durable và lưu ý "consistency" của ACID khác consistency của CAP.¹
• SQL mạnh: join, window function, full-text search (tsvector/tsquery), thêm CTE và JSONB.²
• Index đa dạng: B-tree, hash, GiST, GIN và nhiều loại khác.³
• Extension: thêm kiểu dữ liệu, hàm và index mới thông qua các module đóng góp (contrib) như fuzzystrmatch, pg_trgm, cube;⁴ Microservices Patterns cũng nhắc các extension geospatial của Postgres.⁵ Các extension khác (pgvector, TimescaleDB, Citus) là kiến thức sản phẩm chưa có sách kiểm chứng.⁶

Trong phỏng vấn, câu "tôi bắt đầu với PostgreSQL" gần như luôn được chấp nhận, miễn là bạn chứng minh được nó chịu được tải. Một node Postgres thường đủ cho tải vừa; mốc tham khảo trong sách là khoảng 1.000 QPS cho một server MySQL (xem phần sizing).⁷ Các con số cao hơn trong bài là ước lượng của khoá học. Rất nhiều sản phẩm không bao giờ vượt qua ngưỡng một node.

Điều quan trọng là biết giới hạn của nó: ghi chỉ đi qua một primary (mô hình primary-secondary của Grokking),⁸ connection tốn bộ nhớ, và bảng cập nhật nhiều cần VACUUM (hai ý sau là kiến thức sản phẩm, chưa có sách).⁶ Phần còn lại của bài đi qua từng điểm. Xem thêm Chọn database và Mô hình dữ liệu.

Kiến trúc: process, WAL và replication

• Mỗi connection là một process của hệ điều hành và tốn bộ nhớ, nên Postgres không chịu được hàng nghìn connection trực tiếp (kiến thức sản phẩm, chưa có sách).⁶
• Mọi thay đổi được ghi vào WAL (write-ahead log) trước, rồi mới ghi vào file dữ liệu. Grokking mô tả primary lưu câu lệnh vào file WAL trước khi thực thi và dùng log đó để copy dữ liệu sang secondary; kỹ thuật này dùng trong PostgreSQL.⁹ Microservices Patterns cũng nhắc Postgres WAL là nguồn để đọc thay đổi cho outbox/CDC.¹⁰
• Shared buffers là cache trang dữ liệu của Postgres; phần RAM còn lại để OS page cache làm tầng cache thứ hai (khuyến nghị cấu hình của khoá học, cần tra tài liệu).⁶

Replication

Ba kiểu trên khớp phân loại sync/async và WAL shipping / logical log của Grokking.⁸⁹ Với replication bất đồng bộ, đọc từ secondary có thể thấy dữ liệu cũ (replication lag), nên luồng "ghi xong đọc lại ngay" (read-your-writes) nên đọc từ primary.⁸ Công cụ failover tự động và cách đặt tên cấu hình cụ thể là kiến thức sản phẩm, chưa có sách.⁶ Xem Scale đọc.

MVCC và VACUUM

Postgres dùng MVCC (multi-version concurrency control): người đọc không chặn người ghi, người ghi không chặn người đọc. Thư viện chưa có sách mô tả MVCC, VACUUM hay mức isolation của Postgres, nên phần này chỉ nêu khái niệm cơ bản.⁶

• Mỗi row (tuple) mang thông tin transaction tạo ra và transaction xoá nó.
• UPDATE không sửa tại chỗ. Nó đánh dấu bản cũ là đã chết và ghi một bản mới.
• Mỗi transaction có một snapshot và chỉ thấy các phiên bản hợp lệ với snapshot đó.

Hệ quả thực tế:

• Bản cũ (dead tuple) chiếm chỗ cho tới khi VACUUM dọn. Autovacuum chạy nền, nhưng bảng cập nhật rất nhiều (bộ đếm, trạng thái job) có thể phình to (bloat) và chậm dần.
• Một transaction mở quá lâu (ví dụ một job báo cáo chạy 2 giờ, hoặc session quên commit) chặn VACUUM dọn mọi bản cũ hơn nó.
• Nếu VACUUM bị chặn quá lâu, Postgres có nguy cơ phải dừng ghi để tránh lỗi tràn ID transaction (wraparound).
• Một số kiểu update chỉ đổi cột không có index được tối ưu để rẻ hơn (HOT update); chi tiết cấu hình tra tài liệu.

Transaction và mức isolation

Bảng này là mô tả khái quát của khoá học; Seven Databases chỉ nêu thuộc tính Isolated của ACID (transaction không can thiệp lẫn nhau), chưa có sách mô tả từng mức của Postgres.¹⁶

Với các bài toán tranh chấp tài nguyên như đặt vé, bạn có ba công cụ chính:

-- 1. Khoá bi quan: giữ khoá row tới khi commit
BEGIN;
SELECT status FROM seats WHERE id = $1 FOR UPDATE;
UPDATE seats SET status = 'HELD', held_by = $2, held_until = now() + interval '10 minutes'
WHERE id = $1 AND status = 'AVAILABLE';
COMMIT;

-- 2. Cập nhật có điều kiện (atomic, không cần SELECT trước)
UPDATE inventory SET stock = stock - $2
WHERE sku = $1 AND stock >= $2
RETURNING stock;

-- 3. Hàng đợi job: nhiều worker lấy job không đụng nhau
SELECT id FROM jobs WHERE state = 'queued'
ORDER BY run_at LIMIT 10
FOR UPDATE SKIP LOCKED;

Ở mức Serializable hoặc Repeatable Read, ứng dụng phải retry khi gặp lỗi serialization failure (kiến thức sản phẩm).⁶ Ba đoạn SQL trên là ví dụ của khoá học cho các kỹ thuật khoá bi quan, cập nhật có điều kiện và hàng đợi job; Microservices Patterns cũng dùng optimistic locking kiểu kiểm tra điều kiện khi ghi.¹² Xem chi tiết các lựa chọn ở Tranh chấp tài nguyên.

Index, partitioning và extension

Các loại index

B-tree lưu giá trị dạng cây cân bằng, khớp được truy vấn theo khoảng; hash index chỉ khớp bằng; GiST là API index tổng quát; GIN dùng cho full-text trên tsvector.³¹³ Các loại khác (BRIN cho bảng rất lớn theo thời gian, index trên JSONB/mảng) là kiến thức sản phẩm chưa có sách.⁶

Thêm vài biến thể rất hữu ích:

• Expression index: ON users (lower(email)), Seven Databases dùng index trên lower(title) cho tìm không phân biệt hoa thường.¹⁴
• Partial index (CREATE INDEX ... WHERE state = 'queued') và covering index (INCLUDE) là tính năng sản phẩm, nhỏ và nhanh theo kinh nghiệm của khoá học.⁶
• Dùng CREATE INDEX CONCURRENTLY trên bảng đang chạy production để không khoá ghi: tuỳ chọn CONCURRENTLY có trong cú pháp CREATE INDEX mà Seven Databases in ra.¹⁵

Mỗi index làm chậm ghi và tốn bộ nhớ (nguyên tắc chung của khoá học). Xem Database index.

Partitioning

Partitioning chia một bảng logic thành nhiều bảng con theo khoảng, danh sách hoặc hash. Ý tưởng chia theo khoảng khoá và theo hash được Grokking mô tả ở phần sharding (key-range, hash-based).¹⁶ Cú pháp declarative của Postgres dưới đây là kiến thức sản phẩm.⁶

CREATE TABLE events (
  id bigint GENERATED ALWAYS AS IDENTITY,
  user_id bigint NOT NULL,
  created_at timestamptz NOT NULL,
  payload jsonb
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_11 PARTITION OF events
  FOR VALUES FROM ('2026-11-01') TO ('2026-12-01');

Lợi ích: query có điều kiện thời gian chỉ chạm vào partition liên quan, và xoá dữ liệu cũ bằng DROP TABLE events_2025_01 thay vì DELETE hàng loạt. Partitioning vẫn nằm trên một node, nó giúp quản lý dữ liệu, không tăng sức ghi.⁶

Extension đáng nhớ

Seven Databases dùng bộ contrib fuzzystrmatch, pg_trgm và cube để làm hệ tìm phim: tìm tên gõ sai bằng trigram, so khớp gần đúng, tìm theo vector đặc trưng.⁴ Microservices Patterns nhắc Postgres và MySQL có extension geospatial để lưu dữ liệu vị trí.⁵ Các extension còn lại chưa có sách trong thư viện:⁶

• PostGIS: kiểu geography, query "trong bán kính"; đủ cho Yelp và nhiều bài tìm kiếm gần ở quy mô vừa.
• pgvector: lưu embedding cho tìm kiếm tương đồng, trước khi cần vector database riêng.
• pg_stat_statements: thống kê query chậm nhất.
• TimescaleDB, Citus: biến Postgres thành time-series store hoặc database phân tán.

Connection pooling và sizing theo cấu hình

Vì sao cần connection pooler

Ứng dụng nhiều instance, mỗi instance một pool connection, cộng thêm worker, cron job, serverless function, tổng số connection tới database tăng rất nhanh. Vì mỗi connection tốn tài nguyên trong Postgres, số connection thật tới database nên nhỏ và được chia sẻ qua một tầng pooling (kiến thức sản phẩm, chưa có sách).⁶

Tầng pooling (ví dụ PgBouncer) có ba chế độ phổ biến: theo phiên, theo transaction (phổ biến nhất, cần cẩn thận với trạng thái theo session) và theo câu lệnh.⁶ Số connection thật tới Postgres nên được chọn theo số core và đo bằng load test, không có con số trong sách.

Bảng sizing (giả định của khoá học)

Các con số dưới đây là giả định của khoá học (ước lượng, cần load test) cho query đơn giản có index, dữ liệu nóng nằm trong RAM. Query nặng, join lớn, hoặc dữ liệu không vừa RAM sẽ thấp hơn nhiều. Mốc từ sách: Grokking dùng khoảng 1.000 QPS cho MySQL, 10.000 QPS cho key-value store, và 100.000 đến 1 triệu QPS cho cache server.⁷

Hãy coi 1.000 QPS của Grokking là mức an toàn cho query thực tế có join, còn bảng trên là mức tốt nhất cho tra cứu theo khoá.

Ví dụ (giả định): hệ thống 1 triệu DAU, mỗi người 50 request/ngày, 30% request chạm DB với trung bình 2 query → 30 triệu query/ngày ≈ 350 QPS trung bình, peak ×5 ≈ 1.750 QPS. Chia theo ngày/giây theo Grokking ch.5;¹⁷ hệ số peak ×5 là giả định. Với mốc 1.000 QPS mỗi server, một primary cùng một replica đủ dùng. Xem thêm Con số cần thuộc.

Khi nào dùng, khi nào rời Postgres

Dấu hiệu nên tách hoặc shard

1. Ghi vượt sức một primary: mọi ghi đi qua một primary nên đây là trần của mô hình này;⁸ CPU primary cao kéo dài (ngưỡng là giả định của khoá học).
2. Working set không vừa RAM của máy lớn nhất bạn chấp nhận trả tiền (giả định của khoá học).
3. Thời gian vận hành quá dài: backup, restore, tạo replica mới mất quá lâu (giả định của khoá học).
4. Multi-region ghi: người dùng nhiều châu lục cần ghi với độ trễ thấp.

Trước khi shard, hãy làm các bước rẻ hơn: thêm index đúng, cache đọc, chuyển đọc sang replica, tách bảng ít liên quan sang database riêng theo chức năng, partition và xoá dữ liệu cũ, nâng cấp phần cứng. Grokking nêu sharding theo chiều dọc (tách bảng/cột) và theo chiều ngang (tách row) là hai hướng, kèm nhược điểm của sharding.¹⁶ Building Microservices cũng khuyên: khi chạm giới hạn ghi, mua máy to hơn thường là cách nhanh nhất, rồi mới tính sharding.¹⁸

Khi thật sự cần shard:

• Extension phân tán (ví dụ Citus): bảng phân tán theo một cột như tenant_id; query theo cột đó đi thẳng tới một node (chưa có sách trong thư viện).⁶
• Shard ở tầng ứng dụng: tự định tuyến theo user_id tới N cluster Postgres. Đơn giản về công nghệ, phức tạp về vận hành (resharding, query xuyên shard), đúng các nhược điểm Grokking nêu cho hash-based sharding.¹⁶
• Database phân tán tương thích Postgres hoặc tầng proxy shard: đổi lại độ trễ ghi cao hơn và một số tính năng không có (nhận định của khoá học).⁶

Xem Sharding và Scale ghi.

Vận hành ở quy mô nhỏ và lớn, và điểm nói trong phỏng vấn

Quy mô nhỏ. Dùng dịch vụ managed để khỏi tự vận hành, bật backup tự động và point-in-time recovery, dùng migration có version. Chi phí và danh sách nhà cung cấp là thông tin thay đổi theo thời gian, thư viện không có sách nên bài không liệt kê.⁶

Quy mô lớn. Một primary lớn, vài replica, tầng pooling, công cụ failover. Theo dõi: replication lag, số connection, tỉ lệ cache hit, dead tuple và tuổi transaction cũ nhất, query chậm nhất (danh sách theo kinh nghiệm của khoá học).⁶ Đổi schema trên bảng lớn phải làm theo kiểu không khoá: thêm cột nullable, backfill theo lô, rồi mới thêm constraint.

Các bài toán dùng PostgreSQL làm nguồn sự thật (gợi ý của khoá học):

• Đặt vé sự kiện, Flash sale: FOR UPDATE, update có điều kiện.
• Payment system, Stock trading: transaction, idempotency key unique.
• Job scheduler: FOR UPDATE SKIP LOCKED cho hàng đợi.
• Yelp, Local delivery: PostGIS cho tìm theo vị trí.
• URL shortener, LeetCode, Online auction: dữ liệu quan hệ, tải vừa phải.

Nguồn trích dẫn

1. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 2, mục về transaction ("PostgreSQL transactions follow ACID compliance", tr. 25). ↩ ↩² ↩³

2. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 2 (window function, tr. 22–24) và Day 3 (TSVector and TSQuery). ↩

3. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 1, mục về index (hash index, B-tree, bảng thuật ngữ Index/B-tree, tr. 20–21). ↩ ↩²

4. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 1 (gói contrib: tablefunc, dict_xsyn, fuzzystrmatch, pg_trgm, cube) và Day 3, mục về fuzzy matching bằng trigram. ↩ ↩²

5. Microservices Patterns (file .zip, tải về giải nén) · ch.7 · §7.3.1 Choosing a view datastore, đoạn nhắc MongoDB và extension geospatial của Postgres và MySQL. ↩ ↩²

6. Chưa có nguồn trong thư viện: thư viện không có sách riêng về nội bộ PostgreSQL (MVCC, VACUUM, mức isolation, partitioning declarative, connection pooling, extension hiện đại); phần này chỉ nêu khái niệm cơ bản, không đưa số liệu hay phiên bản của sản phẩm. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹

7. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · mục "Standard numbers to remember" (bảng Important Rates). ↩ ↩² ↩³

8. Grokking Modern System Design · ch.9 Databases · mục "Replication", "Synchronous versus asynchronous", "Single leader/primary-secondary replication". ↩ ↩² ↩³ ↩⁴

9. Grokking Modern System Design · ch.9 Databases · mục "Primary-secondary replication methods", "Write-ahead log (WAL) shipping" và "Logical (row-based) log replication". ↩ ↩²

10. Microservices Patterns (file .zip, tải về giải nén) · ch.3 · §3.3.7 Transactional messaging, mục "Transaction log tailing" (Eventuate Tram dùng Postgres WAL, tr. 99–100). ↩

11. Grokking Modern System Design · ch.24 Sharded Counters · mục "High-level solution sketch". ↩

12. 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 "Updating orders" (optimistic locking, conditional update, tr. 247–248). ↩

13. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 3, mục "TSVector and TSQuery" và phần tạo index GIN cho full-text. ↩

14. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 3, tạo index movies_title_pattern trên lower(title). ↩

15. Seven Databases in Seven Weeks (file .zip, tải về giải nén) · ch.2 PostgreSQL · Day 1, mục trợ giúp \h CREATE INDEX (cú pháp có tuỳ chọn CONCURRENTLY). ↩

16. Grokking Modern System Design · ch.9 Databases · mục "Sharding", "Key-range based sharding", "Hash-based sharding", "Advantages" và "Disadvantages". ↩ ↩² ↩³ ↩⁴

17. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · mục "Requests estimation" và "Number of servers required". ↩

18. Building Microservices (file .zip, tải về giải nén) · ch.11 Microservices at Scale · mục "Scaling for Writes" (tr. 223). ↩