Giới thiệu & Khái niệm RDBMSIntroduction & RDBMS Concepts

Thuộc bộ kiến thức PostgreSQL DBA Roadmap.

Tổng quan

Một RDBMS (Relational Database Management System — hệ quản trị cơ sở dữ liệu quan hệ) lưu trữ dữ liệu dưới dạng tập hợp các bảng (table) — lưới gồm các hàng (row) và cột (column) — và cho phép bạn liên kết bảng này với bảng khác thông qua các giá trị khóa dùng chung, thay vì thông qua con trỏ hay lồng ghép vật lý. Bạn không cần chỉ cho RDBMS biết cách tìm dữ liệu (đi theo con trỏ này, rồi con trỏ kia); bạn chỉ cần nói điều bạn muốn bằng một ngôn ngữ khai báo — SQL (Structured Query Language) — và bộ tối ưu truy vấn (query planner) của database sẽ tự tìm ra cách nhanh nhất để lấy dữ liệu đó. Sự tách biệt giữa “cái gì” và “làm thế nào” này là lý do lớn nhất khiến mô hình quan hệ thống trị việc lưu trữ dữ liệu nghiệp vụ quan trọng suốt hơn năm mươi năm qua: code ứng dụng có thể thay đổi liên tục, nhưng query planner vẫn có thể được viết lại, nâng cấp và tối ưu hóa lại mà không ai phải động vào một câu lệnh SELECT nào.

Database không phải lúc nào cũng hoạt động theo cách này. Trước mô hình quan hệ của Codd (1970), hai cách tiếp cận thống trị là mô hình phân cấp (hierarchical model) (IMS của IBM, 1966) — dữ liệu được tổ chức thành cây nghiêm ngặt, mỗi bản ghi chỉ có đúng một bản ghi cha, giống cấu trúc filesystem — và mô hình mạng (network model) (CODASYL, cuối thập niên 1960) — một đồ thị các bản ghi kết nối bằng con trỏ tường minh, linh hoạt hơn cây nhưng vẫn phải duyệt bằng code đi theo con trỏ. Cả hai đều yêu cầu lập trình viên ứng dụng phải biết bố cục vật lý của dữ liệu và viết code mệnh lệnh (imperative) để đi qua từng liên kết vật lý, từng bản ghi một. Tổ chức lại cấu trúc vật lý — thêm một đường truy cập mới, đổi chuỗi con trỏ — đồng nghĩa phải viết lại mọi chương trình có động đến nó. Điểm mấu chốt trong ý tưởng của Codd là tách biệt cấu trúc logic của dữ liệu (các quan hệ, được định nghĩa bởi cột và ràng buộc) khỏi cách lưu trữ vật lý và đường truy cập, đồng thời để ngôn ngữ truy vấn thể hiện ý định thay vì thao tác điều hướng. Sự tách biệt đó chính là lý do mô hình quan hệ chiến thắng: schema có thể tiến hóa, storage engine có thể được tối ưu, index có thể được thêm vào — tất cả mà không phá vỡ các ứng dụng xây dựng bên trên, miễn là hình dạng logic của dữ liệu (schema) vẫn tương thích.

PostgreSQL là một cách hiện thực hóa mô hình này — nhưng là một cách hiện thực hóa đầy tham vọng. Nó khởi đầu là POSTGRES, một dự án nghiên cứu tại UC Berkeley do Michael Stonebraker dẫn dắt (cũng chính là người đứng sau Ingres, một trong những hệ quản trị quan hệ sớm nhất), được thiết kế rõ ràng để vượt ra ngoài mô hình quan hệ của thập niên 1980 bằng cách hỗ trợ kiểu dữ liệu tự định nghĩa (user-defined type), rule, và khả năng mở rộng. Khi hỗ trợ SQL được thêm vào năm 1995, dự án được đổi tên thành Postgres95, và đến năm 1996 trở thành PostgreSQL dưới sự quản trị cộng đồng mã nguồn mở như hiện nay. Chính “gen” nghiên cứu đó — “để người dùng mở rộng hệ thống kiểu dữ liệu và cả bản thân database” — vẫn là đặc điểm định hình phân biệt PostgreSQL với MySQL, Oracle, và SQL Server ngày nay, và đó cũng là lý do PostgreSQL có thể vừa là một engine quan hệ tuân thủ chuẩn nghiêm ngặt, vừa là nền tảng cho những thứ như lưu trữ document JSON đầy đủ hay tìm kiếm tương đồng vector, mà không cần rời khỏi cùng một hệ thống.

Bài viết này là điểm khởi đầu của roadmap PostgreSQL DBA: nó thiết lập nền tảng khái niệm (mô hình quan hệ, ACID, OLTP/OLAP) mà mọi chủ đề sau này — cài đặt, thiết kế schema, indexing, transaction, replication, bảo mật — đều xây dựng dựa trên đó.

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

Mô hình quan hệ, một cách chính thức

Mô hình quan hệ của Codd đặt tên chính xác, mang tính toán học cho những gì hầu hết mọi người đã hình dung là “một bảng”:

Thuật ngữ thông thường	Thuật ngữ chính thức	Định nghĩa
Bảng (table)	Quan hệ (relation)	Một tập hợp các tuple có tên, tất cả cùng chia sẻ chung các thuộc tính (cột)
Hàng / bản ghi	Tuple	Một tập giá trị có thứ tự duy nhất, mỗi giá trị ứng với một thuộc tính, trong một quan hệ
Cột / trường	Thuộc tính (attribute)	Một thành phần có tên, có kiểu của tuple (ví dụ: email TEXT)
Cấu trúc bảng	Schema (của quan hệ)	Tập tên thuộc tính và miền giá trị (domain/type) của chúng
Miền giá trị	Domain	Tập các giá trị hợp lệ mà một thuộc tính có thể nhận (ví dụ: INTEGER, BOOLEAN)

Hai đảm bảo sau xuất phát trực tiếp từ việc coi một quan hệ như một tập hợp (set) toán học của các tuple, và chúng có ý nghĩa thực tiễn, không chỉ là lý thuyết:

• Không có tuple trùng lặp. Một tập hợp không thể chứa hai phần tử giống hệt nhau, nên trong mô hình quan hệ thuần túy, một quan hệ không thể chứa hai hàng hoàn toàn giống nhau. Trong các engine SQL thực tế — kể cả PostgreSQL — bảng có thể chứa các hàng trùng lặp về mặt vật lý trừ khi bạn thêm ràng buộc PRIMARY KEY hoặc UNIQUE, bởi vì bảng SQL về mặt kỹ thuật là multiset (bag), không phải quan hệ toán học thuần túy. Đây là một sự nới lỏng thực tiễn có chủ đích, nhưng nó có nghĩa là tính duy nhất là thứ bạn phải khai báo, không tự nhiên mà có — một trong những điều đầu tiên một DBA nên kiểm tra trên bất kỳ bảng nào không có khóa tự nhiên rõ ràng.
• Thuộc tính không có thứ tự (và về nguyên tắc, tuple cũng vậy). Một quan hệ không có thứ tự hàng hay thứ tự cột nội tại; {name, age} và {age, name} mô tả cùng một quan hệ. Đây là lý do SELECT * trả về cột theo thứ tự định nghĩa bảng chỉ là một sự tiện lợi, không phải một đảm bảo, và tại sao dựa vào thứ tự hàng vật lý mà không có ORDER BY là một lỗi logic tiềm ẩn, chỉ chờ lộ ra sau khi VACUUM FULL hay việc rebuild index tiếp theo làm thay đổi bố cục vật lý.

Các quan hệ kết nối với nhau thông qua khóa (key): một khóa chính (primary key) xác định duy nhất mỗi tuple trong chính quan hệ của nó, và một khóa ngoại (foreign key) trong một quan hệ tham chiếu đến khóa chính (hoặc khóa duy nhất) trong quan hệ khác, mã hóa một mối quan hệ mà không cần nhân bản dữ liệu. Đây là điều cho phép bạn tách orders và customers thành các bảng riêng biệt mà vẫn có thể tái tạo lại “khách hàng nào đặt đơn hàng nào” — thông qua join — thay vì nhân bản dữ liệu khách hàng vào mọi hàng đơn hàng, và cho phép database thực thi tính toàn vẹn tham chiếu (referential integrity) (bạn không thể chèn một đơn hàng cho khách hàng không tồn tại) như một đảm bảo hạng nhất thay vì một quy ước ở tầng ứng dụng.

Lợi ích và hạn chế của RDBMS

Nền tảng toán học của mô hình quan hệ chuyển hóa thành những lợi ích kỹ thuật cụ thể, nhưng nó cũng tạo ra những ràng buộc thực sự — hiểu cả hai mặt là điều giúp một DBA lựa chọn (hoặc bảo vệ) PostgreSQL cho một workload cụ thể thay vì chọn nó chỉ vì thói quen.

Lợi ích	Hạn chế
Đảm bảo consistency mạnh mẽ thông qua transaction ACID	Horizontal scaling (sharding trên nhiều node) khó hơn so với các hệ NoSQL được xây dựng chuyên biệt cho việc đó
Ngôn ngữ truy vấn (SQL) trưởng thành, chuẩn hóa, khả chuyển giữa các hệ thống và kỹ năng	Thay đổi schema đòi hỏi migration tường minh; thêm một cột vào bảng khổng lồ có thể gây lock hoặc rewrite toàn bảng
Join khai báo (declarative), mạnh mẽ trên các bảng đã chuẩn hóa	Không phù hợp với dữ liệu ghi cực nhiều, ít cấu trúc (ví dụ: telemetry IoT thô, log phi cấu trúc ở quy mô khổng lồ)
Query optimizer khai báo giải phóng developer khỏi việc tự viết đường truy cập dữ liệu	Vertical scaling (máy lớn hơn) là con đường mở rộng mặc định trước khi sharding trở nên cần thiết
Hệ sinh thái phong phú: hàng chục năm công cụ, ORM, giám sát, DBA đã quen với mô hình này	Kiểu dữ liệu/ràng buộc chặt chẽ làm tăng chi phí thiết kế schema ban đầu so với các kho lưu trữ schema-on-read

Không hạn chế nào là chí mạng — chúng đều là đánh đổi. Một schema quan hệ được mô hình hóa tốt cùng index phù hợp sẽ vượt trội hơn một kho NoSQL được dùng một cách ngây thơ, đối với hầu hết ứng dụng transactional. Và bản thân PostgreSQL còn chủ động giảm nhẹ nhiều hạn chế kể trên (JSONB cho dữ liệu bán cấu trúc, logical replication và các extension như Citus cho horizontal scaling), đó là một phần lý do nó trở thành lựa chọn mặc định cho rất nhiều loại workload, thay vì chỉ là một RDBMS chuyên biệt hẹp.

Khái niệm chính

PostgreSQL so với các RDBMS khác

Mọi RDBMS lớn đều triển khai cùng một lõi quan hệ, nhưng chúng khác biệt rõ rệt về khả năng mở rộng, mức độ tuân thủ chuẩn, và kiến trúc concurrency — và những khác biệt đó thường mới là thứ thực sự quyết định bạn chọn hệ nào.

Khía cạnh	PostgreSQL	MySQL	Oracle	SQL Server	SQLite
Giấy phép / chi phí	Mã nguồn mở, giấy phép PostgreSQL rất khoáng đạt (miễn phí)	Mã nguồn mở (GPL) + gói Enterprise trả phí	Độc quyền, chi phí license đắt đỏ	Độc quyền, license theo core	Public domain, nhúng (embedded), miễn phí
Khả năng mở rộng	Rất cao: kiểu dữ liệu tùy chỉnh, toán tử, index access method, ngôn ngữ thủ tục, extension (pgvector, PostGIS, TimescaleDB)	Hạn chế; storage engine có thể thay (InnoDB, MyISAM) nhưng hệ thống kiểu là đóng	Cao nhưng độc quyền (package PL/SQL)	Trung bình (tích hợp CLR, T-SQL)	Tối thiểu; không nhắm đến việc mở rộng
Tuân thủ chuẩn SQL	Rất cao — bám sát chuẩn SQL	Trước đây lỏng lẻo hơn (ép kiểu ngầm, cắt bớt giá trị âm thầm)	Cao, kèm nhiều phần mở rộng độc quyền	Cao, kèm phương ngữ mở rộng T-SQL	Một phần; kiểu dữ liệu động đi lệch khỏi chuẩn
Mô hình concurrency	MVCC qua các phiên bản tuple trong heap + vacuum	MVCC trong InnoDB (undo log, gần với cách tiếp cận của Oracle)	MVCC qua undo segment/rollback	Mặc định dựa trên lock, tùy chọn MVCC (snapshot isolation)	Ghi đơn (single-writer), khóa ở mức file
Tùy chọn indexing	B-tree, Hash, GiST, SP-GiST, GIN, BRIN — index access method có thể cắm thêm	Chủ yếu B-tree (+ full-text, spatial hạn chế)	B-tree, bitmap, function-based, domain index	B-tree (clustered/non-clustered), columnstore	Chỉ B-tree
Trường hợp dùng điển hình	OLTP đa dụng, dữ liệu địa lý, JSON, analytics nhờ extension	Ứng dụng web, workload nặng đọc, thiết lập ưu tiên đơn giản	Doanh nghiệp lớn, hệ thống legacy trọng yếu	Hệ sinh thái doanh nghiệp thiên về Windows/.NET	Nhúng, mobile, lưu trữ cục bộ một file

Hai điểm khác biệt đáng ghi nhớ nhất trong bảng trên là khả năng mở rộng và cách hiện thực MVCC. Cơ chế extension của PostgreSQL (CREATE EXTENSION) cho phép bạn thêm những kiểu dữ liệu và phương thức index thực sự mới mà không cần fork database — đây chính là cách pgvector (tìm kiếm tương đồng vector) và PostGIS (dữ liệu địa lý) tồn tại như những công dân hạng nhất, thay vì các hack chắp vá thêm vào. Và thiết kế MVCC cụ thể của PostgreSQL — lưu nhiều phiên bản của một hàng ngay trong heap của bảng và dựa vào VACUUM để thu hồi các phiên bản đã chết — đánh đổi một chút overhead lưu trữ/bảo trì (bloat, nhu cầu vacuum) để lấy về một đường đọc đơn giản, không blocking, nơi reader không bao giờ chặn writer và writer không bao giờ chặn reader. Hãy so sánh điều này với mô hình lock mặc định của SQL Server, nơi truy cập đồng thời một cách ngây thơ có thể tạo ra chuỗi blocking mà Postgres, MySQL/InnoDB, hay Oracle sẽ không gặp phải.

PostgreSQL so với các database NoSQL

Ranh giới lịch sử “dùng Postgres cho dữ liệu quan hệ có cấu trúc, dùng kho NoSQL cho dữ liệu linh hoạt/quy mô khổng lồ” đã mờ đi khá nhiều, chủ yếu nhờ hai tính năng của PostgreSQL: JSONB, một kiểu cột JSON nhị phân, có thể index, cho phép bạn lưu và truy vấn các document linh hoạt về schema ngay bên trong một bảng quan hệ thông thường, và các extension như pgvector, biến PostgreSQL thành một vector database khả thi cho embedding và tìm kiếm tương đồng. Giờ đây hoàn toàn có thể chạy một workload kiểu document store, một workload full-text search, và một workload semantic search, tất cả trong cùng một instance PostgreSQL.

Tuy vậy, đánh đổi cơ bản được mô tả trong NoSQL Databases vẫn đúng, và JSONB không xóa bỏ nó — nó chỉ tạo ra một lối thoát bên trong một hệ thống quan hệ. Hãy chọn PostgreSQL (mô hình hóa quan hệ, kể cả khi có cột JSONB) khi:

• Dữ liệu có các thực thể và mối quan hệ rõ ràng, hưởng lợi từ foreign key, join, và tính toàn vẹn tham chiếu.
• Transaction cần tuân thủ ACID trên nhiều lần ghi liên quan đến nhau (ví dụ: chuyển tiền giữa hai tài khoản).
• Bạn cần truy vấn ad-hoc, khai báo (kết hợp WHERE/JOIN/aggregate tùy ý) thay vì một tập nhỏ các access pattern định trước.

Hãy chọn một kho NoSQL chuyên biệt thay vào đó khi:

• Khối lượng dữ liệu và throughput ghi vượt quá những gì một primary duy nhất (cộng thêm read replica) có thể phục vụ, và bạn cần horizontal scaling gần như tuyến tính, minh bạch, như một mục tiêu thiết kế hạng nhất chứ không phải bổ sung sau (ví dụ: Cassandra, DynamoDB).
• Schema thực sự khó đoán trước và việc truy cập gần như luôn theo một khóa duy nhất hoặc một tập nhỏ pattern đã biết (ví dụ: document store theo khóa document ID), nên bạn có được rất ít lợi ích từ việc mô hình hóa quan hệ.
• Bạn cần một mô hình dữ liệu chuyên biệt — graph database cho việc duyệt quan hệ sâu, wide-column store cho time-series ở quy mô khổng lồ — mà một engine quan hệ hoặc document tổng quát xử lý kém.

Quy tắc thực tế mà hầu hết DBA đi đến: mặc định chọn PostgreSQL cho các workload transactional và đa dụng, và chỉ áp dụng một hệ NoSQL chuyên biệt khi có lý do cụ thể, đã được đo lường (một access pattern hay yêu cầu quy mô cụ thể mà Postgres không đáp ứng được), thay vì một cảm giác mơ hồ rằng “NoSQL scale tốt hơn”.

ACID, xem trước

Mọi transaction quan hệ mà PostgreSQL commit đều được kỳ vọng thỏa mãn ACID: Atomicity (Tính nguyên tử — mọi ghi trong một transaction xảy ra hết hoặc không xảy ra gì cả), Consistency (Tính nhất quán — một transaction đưa database từ trạng thái hợp lệ này sang trạng thái hợp lệ khác, tôn trọng các ràng buộc), Isolation (Tính cô lập — các transaction đồng thời không thấy trạng thái trung gian chưa commit của nhau), và Durability (Tính bền vững — một khi đã commit, dữ liệu sống sót qua sự cố crash). Cơ chế đầy đủ — isolation level, các loại anomaly, locking — được trình bày trong Backend — Relational Databases và sẽ được đào sâu ở Transactions & Concurrency Control; bài viết này chỉ xem trước cách PostgreSQL cụ thể hiện thực hai trong bốn chữ cái đó, vì nó giải thích rất nhiều hành vi đặc trưng của PostgreSQL sẽ gặp lại sau này trong roadmap:

• Durability đến từ Write-Ahead Log (WAL). Trước khi PostgreSQL sửa đổi một trang dữ liệu, nó ghi lại thay đổi đó vào WAL và flush xuống đĩa trước tiên. Nếu server crash, việc replay WAL khi khởi động lại sẽ tái tạo mọi thay đổi đã commit nhưng chưa kịp ghi vào file bảng thực tế. Đây cũng chính là cơ chế cung cấp năng lượng cho physical replication và point-in-time recovery, được trình bày trong Replication & High Availability.
• Isolation đến từ MVCC (Multi-Version Concurrency Control). Thay vì để reader lấy lock chặn writer, PostgreSQL giữ nhiều phiên bản của một hàng (được tạo ra bởi UPDATE/DELETE) và cấp cho mỗi transaction một “snapshot” nhất quán của dữ liệu tại một thời điểm. Một reader nhìn thấy phiên bản của hàng đã được commit trước khi snapshot của nó được chụp, bất kể writer đồng thời đang sửa đổi chính hàng đó. Đây là lý do trong PostgreSQL, SELECT không bao giờ bị chặn bởi UPDATE và ngược lại — một đặc tính mà nhiều DBA quen với các hệ thống nặng về lock ban đầu thấy bất ngờ.

OLTP so với OLAP so với HTAP

Không phải mọi workload database đều giống nhau, và hình dạng của workload nên quyết định schema, chiến lược indexing, thậm chí cả lựa chọn engine. Ba nhóm rộng sau mô tả phổ này:

Khía cạnh	OLTP	OLAP	HTAP
Tên đầy đủ	Online Transaction Processing	Online Analytical Processing	Hybrid Transactional/Analytical Processing
Truy vấn điển hình	Ngắn, đơn giản (tra cứu/cập nhật một hàng)	Dài, phức tạp (aggregation trên hàng triệu hàng)	Cả hai, trên cùng dữ liệu
Khối lượng truy vấn	Rất cao (hàng nghìn/giây)	Thấp đến trung bình	Cao cho phần OLTP, trung bình cho phần analytics
Phạm vi dữ liệu mỗi truy vấn	Vài hàng	Quét lớn, thường toàn bảng/partition	Hỗn hợp
Bố cục lưu trữ	Hướng hàng (row-oriented — nhanh khi đọc/ghi nguyên hàng)	Hướng cột (column-oriented — nhanh khi quét ít cột trên nhiều hàng)	Thường hỗn hợp hoặc bố cục kép
Hệ thống điển hình	PostgreSQL, MySQL, Oracle (như engine OLTP)	Snowflake, BigQuery, Redshift, ClickHouse	TiDB, SingleStore, PostgreSQL + extension columnar (ví dụ: Citus, hydra/columnar)
Điểm mạnh truyền thống của PostgreSQL	Xuất sắc — đây chính là thế mạnh cốt lõi của Postgres	Yếu theo mặc định (lưu trữ theo hàng gây bất lợi cho quét rộng)	Đang hình thành, thông qua extension

Storage engine của PostgreSQL về bản chất là hướng hàng (row-oriented), và chính điều đó khiến nó nhanh với OLTP: lấy hoặc cập nhật một hàng đầy đủ (một bản ghi khách hàng, một đơn hàng) chỉ chạm vào một khối liền kề trên đĩa. Nhưng cùng bố cục đó lại là bất lợi cho các truy vấn kiểu OLAP — SELECT AVG(amount) FROM orders chỉ cần một cột, nhưng row store vẫn phải đọc toàn bộ mỗi hàng vào bộ nhớ để lấy được cột đó. Đây là lý do các data warehouse cổ điển dùng lưu trữ hướng cột (column-oriented) thay vào đó: mỗi cột được lưu liền kề, nên quét một cột trên hàng tỷ hàng chỉ đọc dữ liệu của cột đó, và nén tốt hơn nhiều.

HTAP là nỗ lực mới nổi nhằm phục vụ cả hai pattern từ cùng một hệ thống mà không cần duy trì một pipeline ETL riêng biệt sang warehouse. PostgreSQL không hỗ trợ columnar storage nguyên bản, nhưng mô hình extension của nó khiến các thiết lập kiểu HTAP trở nên khả thi: các extension thêm bảng lưu trữ dạng columnar song song với các bảng row-based thông thường trong cùng database, để dữ liệu transactional “nóng” gần đây có thể vẫn ở dạng row-oriented trong khi dữ liệu lịch sử hoặc nặng về báo cáo sống ở định dạng columnar tối ưu cho aggregation — tất cả đều truy vấn được qua cùng giao diện SQL. Đây vẫn là một lĩnh vực còn non trẻ so với hàng chục năm trưởng thành về OLTP của Postgres, và hầu hết hệ thống production vẫn kết hợp PostgreSQL (OLTP) với một warehouse chuyên dụng (OLAP) được nạp dữ liệu qua change-data-capture hoặc batch ETL, nhưng đáng để biết HTAP tồn tại như một hướng đi mà hệ sinh thái đang tiến tới.

Best Practices

• Mô hình hóa các mối quan hệ tường minh bằng khóa và ràng buộc, đừng dựa vào quy ước. Khai báo PRIMARY KEY, FOREIGN KEY, UNIQUE, và NOT NULL ở bất cứ nơi nào đúng về mặt logic. Ràng buộc không phải là thủ tục giấy tờ — chúng là thứ giúp query planner của PostgreSQL và bản thân DBA khi lý luận về schema có thể tin tưởng rằng dữ liệu thực sự có hình dạng như nó trông có vẻ.
• Chọn PostgreSQL một cách có chủ đích, không phải theo mặc định. Đây là một lựa chọn đa dụng xuất sắc, nhưng hãy nói rõ điều bạn thực sự cần (transaction ACID, join phức tạp, truy vấn ad-hoc) để nếu sau này workload cần một thứ mà PostgreSQL thực sự không thể đáp ứng (ví dụ: horizontal write scaling tuyến tính ở quy mô khổng lồ), bạn nhận ra sớm thay vì cố gắng ép công cụ làm việc nó không phù hợp.
• Đừng dùng JSONB như một cách thay thế cho việc thiết kế schema. JSONB là lối thoát mạnh mẽ cho các thuộc tính thực sự biến đổi hoặc thưa, không phải giấy phép để bỏ qua việc mô hình hóa quan hệ cho các thực thể cốt lõi. Một bảng chỉ là một khối JSONB khổng lồ sẽ mất đi hầu hết lợi ích (ràng buộc, join, thống kê cho planner) vốn là lý do chọn PostgreSQL ngay từ đầu.
• Phân loại workload trước khi thiết kế schema. Biết một database (hay một bảng) cụ thể chủ yếu là OLTP hay OLAP trước khi chọn mức độ chuẩn hóa, chiến lược indexing, và bố cục lưu trữ — câu trả lời đúng cho một bảng orders đang nhận ghi trực tiếp rất khác với câu trả lời đúng cho một bảng báo cáo orders_history.
• Coi ACID là một dải cấu hình được, không phải một thứ nhị phân có sẵn miễn phí. Isolation level mặc định của PostgreSQL (READ COMMITTED) yếu hơn serializability đầy đủ; hãy biết nó cho phép những anomaly nào trước khi mặc định nghĩ “nó là ACID” nghĩa là “không có gì có thể sai” — điều này sẽ được trình bày đầy đủ ở Transactions & Concurrency Control.

Bản đồ roadmap

Chủ đề này là điểm khởi đầu về mặt khái niệm; phần còn lại của roadmap sẽ mở rộng dần theo thứ tự đại khái sau:

• 02 — Installation, Setup & Connecting: dựng một instance PostgreSQL và kết nối với nó bằng psql và driver.
• 03 — Đối tượng schema: database, schema, bảng, view, và cấu trúc phân cấp đối tượng.
• 04–05 — Truy vấn: SELECT, join, aggregation, subquery, và cách kết hợp truy vấn.
• 06 — Thao tác dữ liệu: INSERT/UPDATE/DELETE, upsert, và mệnh đề RETURNING.
• 07 — Procedure & trigger: stored procedure, function, và tự động hóa dựa trên trigger.
• 08 — Indexing: B-tree, GiST, GIN, BRIN, và cách chọn index phù hợp với access pattern.
• 09 — Transactions & Concurrency Control: isolation level, locking, deadlock, và MVCC chi tiết.
• 10–11 — Hiệu năng: lập kế hoạch truy vấn, EXPLAIN, tinh chỉnh cấu hình.
• 12–13 — Mở rộng & Replication and High Availability: read replica, failover, chiến lược sharding.
• 14 — Backup & recovery: pg_dump, backup vật lý, point-in-time recovery.
• 15 — Bảo mật: role, quyền hạn, row-level security, mã hóa.
• 16 — Giám sát: các view pg_stat, logging, công cụ observability bên ngoài.

Tài liệu tham khảo

• PostgreSQL Official Documentation
• PostgreSQL — Chapter 1: What is PostgreSQL?
• PostgreSQL — History
• Hironobu Suzuki, “The Internals of PostgreSQL” — đặc biệt Phần I (Overview) để nắm kiến trúc nền tảng
• Codd, E.F., “A Relational Model of Data for Large Shared Data Banks” (1970)
• roadmap.sh — PostgreSQL DBA
• Backend — Relational Databases
• Backend — NoSQL Databases