Deep Dive: PostgreSQL Storage Internals — Từ Heap File Trên Disk Đến Shared Buffer

Khi bạn chạy EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM users WHERE id = 42;, PostgreSQL trả về một dòng kiểu như Buffers: shared hit=3 read=1. Con số đó nghĩa là gì? Tại sao cùng một câu UPDATE, lần này chạy 2 ms, lần khác lại 80 ms — dù bảng không hề bị lock? Tại sao sau một câu DELETE thì dung lượng file của bảng vẫn không hề giảm? Và cụ thể thì “shared buffer” mà mọi tài liệu hướng dẫn tune luôn nhắc đến — bên trong nó thực sự chứa gì?

Trả lời được những câu hỏi đó đòi hỏi bạn phải đi xuống một tầng dưới SQL: storage engine layer. Đây là bài deep dive về cách PostgreSQL tổ chức dữ liệu trên đĩa (heap files, pages, tuples) và cách dữ liệu được kéo lên RAM thông qua Shared Buffer Manager. Bài này bổ sung cho Deep Dive về Table Bloat (tập trung vào hậu quả là dead tuples và vacuum) và Deep Dive về PostgreSQL Partitioning (tập trung vào chia bảng lớn) — cả hai bài đó đứng trên những concepts mà bài này mổ xẻ.

1. Tổ chức file của một bảng trên disk

Mọi bảng trong PostgreSQL cuối cùng đều quy về một tập file trên hệ thống tệp. Khi bạn cài đặt PostgreSQL, biến môi trường PGDATA trỏ tới thư mục dữ liệu (ví dụ /var/lib/postgresql/16/main). Bên trong đó, đường dẫn của heap file một bảng có dạng:

$PGDATA/base/<database_oid>/<relfilenode>

Bạn có thể tự kiểm chứng bằng query này:

SELECT pg_relation_filepath('users');

16384 là OID của database, 24576 là relfilenode của bảng users — relfilenode là tên file vật lý của 1 relation trong postgresql.

OID và relfilenode là khác nhau. Khi bạn chạy VACUUM FULL, CLUSTER, REINDEX hay TRUNCATE, PostgreSQL viết lại data sang một file mới và đổi relfilenode — nhưng oid (cách bảng được tham chiếu trong system catalog) giữ nguyên. Điều này quan trọng khi monitoring: nếu bạn cache đường dẫn file rồi 30 phút sau dùng lại, có thể nó đã trỏ tới một file đã bị xóa.

Ba forks của một relation

Một bảng không phải chỉ một fork mà tận 3 forks — Fork là một khái niệm mượn từ “file fork” trong filesystem cũ, bạn có thể hiểu đơn giản nó là file.

• Main fork (<relfilenode>): heap data thực sự — các tuple bạn đã INSERT.
• FSM fork (<relfilenode>_fsm): Free Space Map — một cấu trúc dữ liệu tree-like nhỏ ghi nhận từng page còn bao nhiêu byte trống. Khi INSERT, PostgreSQL tra cứu FSM trước để tìm page có đủ chỗ thay vì phải scan tuần tự.
• VM fork (<relfilenode>_vm): Visibility Map — 2 bit cho mỗi page, đánh dấu (a) page có toàn live tuples không, và (b) page đã được frozen chưa. Index-only scan dựa vào bit (a) để bỏ qua bước check heap; VACUUM dựa vào để bỏ qua những page không có dead tuple.

Khi bảng vượt quá 1 GB, main fork được chia thành nhiều segment files liên tiếp: <relfilenode>, <relfilenode>.1, <relfilenode>.2, …

Lý do lịch sử: nhiều filesystem cũ (HFS, FAT32, ext2 với block size nhỏ) có giới hạn 2 GB hoặc 4 GB cho một file. PostgreSQL giữ giới hạn segment 1 GB cho đến nay vì nó hoạt động tốt và không có lý do để thay đổi.

2. Page anatomy — đơn vị I/O 8 KB

PostgreSQL không đọc/ghi từng byte, từng tuple, hay từng row. Đơn vị I/O cơ bản là page (còn gọi là block), mặc định 8 KB. Mọi thao tác đọc từ disk hay ghi xuống disk đều xảy ra ở granularity này. Đây là lý do bài table-bloat nhấn mạnh chuyện “muốn lấy 1 tuple, phải kéo cả container 8 KB lên RAM”.

Layout của một page, từ offset 0 đến 8191:

1. PageHeaderData (24 byte) — header chứa metadata của page:

   • pd_lsn (8 B): Log Sequence Number của WAL record gần nhất chạm vào page này. Dùng cho recovery và checkpoint coordination.
   • pd_checksum (2 B): checksum data integrity (nếu bật data_checksums).
   • pd_flags (2 B): flags như PD_HAS_FREE_LINES, PD_PAGE_FULL, PD_ALL_VISIBLE.
   • pd_lower (2 B), pd_upper (2 B): hai con trỏ định nghĩa vùng free space — pd_lower là cuối line pointer array, pd_upper là đỉnh của vùng tuple.
   • pd_special (2 B): offset đến đầu special area (chỉ index dùng).
   • pd_pagesize_version (2 B), pd_prune_xid (4 B).

2. ItemIdData array — mảng các line pointer 4 byte. Mỗi line pointer = (offset, length, flags) trỏ tới một tuple trong cùng page. Index entries trỏ tới tuple không phải bằng offset trực tiếp mà thông qua line pointer, gọi là CTID = [block_num, line_pointer_index]. Lý do: khi VACUUM xoá dead tuples và defragmentation, các tuple sẽ bị thay đổi vị trí trong page, line pointer giúp tránh việc phải update index trỏ về các vị trí mới.

3. Free space — khoảng giữa pd_lower và pd_upper. Đây là vùng chưa dùng. INSERT mới sẽ ăn vào vùng này từ cả hai đầu.

4. Tuples — dữ liệu thật, xếp từ cuối page hướng lên. Mỗi tuple = HeapTupleHeader + (optional) null bitmap + user data.

5. Special space — dành cho indexes (B-tree, GIN, GiST,…). Heap pages không dùng vùng này.

Tại sao two-direction layout?

Thiết kế “line pointers grow down, tuples grow up” có một mục tiêu cụ thể: cho phép thêm tuple mới mà không phải shift toàn bộ dữ liệu.

Khi INSERT:

• Line pointer được append vào cuối array (tăng pd_lower)
• Tuple được prepend vào đỉnh tuple area (giảm pd_upper)
• Page chỉ “đầy” khi pd_lower chạm pd_upper.

3. Tuple anatomy — HeapTupleHeader

Mỗi tuple vật lý là một block byte gồm ba phần: header (23 byte + padding), null bitmap (tùy chọn), và user data (aligned).

Header chứa toàn bộ metadata mà MVCC cần để biết tuple này có visible với một transaction nào đó hay không. Đây là các field quan trọng:

• t_xmin (4 B) — Transaction ID đã INSERT tuple này. Một row mới có t_xmin = current_xid.
• t_xmax (4 B) — XID đã DELETE hoặc UPDATE tuple này. Nếu = 0 nghĩa là tuple đang live, chưa bị ai xóa. Khi bạn DELETE một row, PostgreSQL chỉ set t_xmax = current_xid và để nguyên tuple ở đó — đây là bản chất của MVCC (Multi-Version Concurrency Control — cơ chế cho phép reader và writer hoạt động song song mà không block nhau bằng cách giữ nhiều phiên bản dữ liệu).
• t_cid / t_xvac (4 B) — Command ID trong cùng transaction; phân biệt các statement khác nhau trong cùng một BEGIN/COMMIT.
• t_ctid (6 B = 4 B block_num + 2 B offset) — con trỏ tới chính tuple này (sau INSERT) hoặc tới phiên bản mới nhất sau UPDATE. Đây là cơ chế xây dựng HOT chain mà chúng ta sẽ gặp ở section 7.
• t_infomask2 (2 B) — số lượng attribute và một số flag (như HEAP_KEYS_UPDATED).
• t_infomask (2 B) — flags vital. Bao gồm:
  • HEAP_HASNULL: tuple có cột NULL → có null bitmap.
  • HEAP_HOT_UPDATED, HEAP_ONLY_TUPLE: đánh dấu HOT chain (section 7).
  • Hint bits — HEAP_XMIN_COMMITTED, HEAP_XMIN_INVALID, HEAP_XMAX_COMMITTED, HEAP_XMAX_INVALID: cache trạng thái commit/abort của xmin/xmax để visibility check không phải đi tra pg_xact mỗi lần.
• t_hoff (1 B) — offset từ đầu tuple đến đầu user data (qua header + null bitmap).

Null bitmap chỉ tồn tại khi HEAP_HASNULL = 1. Mỗi cột chiếm 1 bit; bit = 0 nghĩa cột đó NULL. Cách này tiết kiệm hơn nhiều so với việc lưu riêng một byte/flag cho mỗi cột.

User data — giá trị các cột, được căn chỉnh (aligned) theo typalign của type. int8 align 8 byte, int4 align 4 byte, bool align 1 byte. Hệ quả: thứ tự cột trong CREATE TABLE ảnh hưởng đến storage. Bảng có columns (a bool, b int8, c bool) lớn hơn bảng (b int8, a bool, c bool) vì padding chèn vào để align b. Chi tiết về tối ưu này được nói kỹ ở table-bloat.

Giới hạn kích thước tuple — con số 2 KB đến từ đâu?

Mỗi tuple có giới hạn kích thước là 2KB.

Một câu hỏi thường gặp: “Vì sao lại là 2 KB, có phải hằng số cố định không?”

Câu trả lời là không. Con số đó được PostgreSQL tính ra theo công thức TOAST_TUPLE_THRESHOLD ≈ BLCKSZ / 4, tức cố nhét ít nhất 4 tuple vào mỗi page. Với BLCKSZ = 8 KB mặc định, ngưỡng rơi vào khoảng 2 KB.

Khi tuple vượt ngưỡng này, TOAST (The Oversized-Attribute Storage Technique — cơ chế nén và/hoặc đẩy các cột lớn ra một bảng phụ riêng) kích hoạt: PostgreSQL nén các cột variable-length hoặc tách chúng ra 1 bảng phụ, chỉ để lại một con trỏ inline.

Ngưỡng này có thể chỉnh ở mức bảng bằng storage parameter toast_tuple_target (từ PG 11):

ALTER TABLE my_table SET (toast_tuple_target = 4080);

4. Shared Buffer Manager — cầu nối giữa RAM và disk

Mỗi lần PostgreSQL cần một tuple, đơn vị tối thiểu mà nó đọc từ disk là một page 8 KB. Disk chậm hơn RAM khoảng năm bậc, nên việc truy disk cho mọi câu truy vấn là điều không thể chấp nhận. Lời giải là một buffer pool nằm trong shared memory, được chia thành các slot 8 KB; mỗi slot giữ đúng một page. Tham số shared_buffers (mặc định 128 MB, production thường đặt ~25% RAM) quy định tổng số slot.

Cái khó nằm ở tình huống thực tế: hàng trăm backend cùng đọc–ghi vào pool, có những page nóng được chạm hàng nghìn lần mỗi giây, có những page lạnh nằm im. Buffer manager phải trả lời ba câu hỏi đan vào nhau — tra cứu nhanh “page này đã trong pool chưa?”, chọn ai bị thay khi pool đầy, và ghi dirty page xuống disk mà không chặn transaction. Ba phần dưới đây bóc lần lượt từng câu.

Kiến trúc ba tầng

Để hỗ trợ ba câu hỏi trên, buffer manager được tổ chức thành ba thành phần song hành:

• Buffer table — một hash table map BufferTag → buffer_id. Đây là chỉ mục giúp tra cứu nhanh xem một page nhất định có nằm trong pool hay không.
• Buffer descriptor array — mảng metadata song song với buffer pool, mỗi phần tử mô tả một slot: tag, buf_id, refcount (pin count), usage_count, và state chứa các cờ như BM_DIRTY, BM_VALID, BM_IO_IN_PROGRESS.
• Buffer pool — mảng các slot 8 KB chứa page thật. buffer_id chính là chỉ số trong mảng này. Quan trọng: descriptor [i] và pool slot [i] luôn nói về cùng một page — chúng song hành theo cùng index.

BufferTag là khóa định danh duy nhất một page trên toàn cluster, gồm năm field:

BufferTag = { spcOid, dbOid, relNumber, forkNum, blockNum }

Ví dụ {16821, 16384, 37721, 0, 7} chỉ block 7, fork main (0), của relation 37721 thuộc database 16384 trong tablespace 16821. Vì sao cần đủ năm field? Một PostgreSQL cluster có nhiều database, mỗi database có nhiều tablespace, mỗi relation có vài fork (main, FSM, VM); tag phải gói trọn ngữ cảnh đó mới đảm bảo không trùng.

Vòng đời của một page access

Bây giờ ta đi qua đúng chuỗi thao tác khi backend cần đọc một page, theo ba kịch bản tăng dần độ phức tạp. Cùng một bộ thuật ngữ — buffer_table, descriptor, slot — được dùng xuyên suốt.

Cache hit (page đã trong pool):

1. Backend process xác định page cần đọc và tính BufferTag.
2. Buffer manager tra buffer_id trong Buffer table với BufferTag.
3. Buffer manager cập nhật metadata trong Buffer descriptor để đánh dấu slot này có truy cập: refcount += 1, usage_count += 1.
4. Backend process truy cập slot thứ buffer_id trong Buffer pool thông qua Buffer manager, đọc hoặc ghi tuple.
5. Sau khi xong, Buffer manager cập nhật lại metadata trong Buffer descriptor: refcount -= 1. Nếu vừa ghi, set BM_DIRTY = 1.

Đây là đường nhanh — mọi thao tác đều vận hành trên RAM.

Cache miss, còn slot trống:

1. Backend process xác định page cần đọc và tính BufferTag.
2. Buffer manager không tìm thấy buffer_id trong Buffer table.
3. Buffer manager xác định slot còn trống trong freelist.
4. Buffer manager insert entry (buffer_tag, buffer_id) vào buffer table.
5. Set BM_IO_IN_PROGRESS = 1, đọc 8 KB từ disk vào slot.
6. Set BM_IO_IN_PROGRESS = 0, BM_VALID = 1.

Sau khi tìm và nạp thành công page từ disk lên Buffer pool. Process tiếp tục được xử lý như tình huống Cache hit.

Cache miss, pool đã đầy (page replacement):

Khi tất cả các slot trong Buffer pool đã bị chiếm giữ, và page cần tìm chưa được nạp vào pool. Buffer manager cần phải quyết định page nào sẽ bị thay thế. Khi này, một thuật toán thay thế sẽ được thực thi, và page được chọn gọi là victim page.

1. Buffer manager xác định page cần tìm chưa được nap vào Buffer pool, và không còn slot trống.
2. Buffer manager tìm victim page thông qua thuật toán clock-sweep (mục kế tiếp).
3. Nếu victim page đang dirty: phải flush page xuống storage trước khi tái sử dụng slot, nếu không nội dung đã modify sẽ mất.
4. Hoán đổi entry trong buffer table: gỡ entry cũ (trỏ tới tag victim), insert entry mới (trỏ tới tag được yêu cầu) — cả hai trỏ tới cùng buffer_id.
5. Load page mới từ disk vào slot, reset BM_DIRTY = 0, BM_VALID = 1.

Clock-sweep — chọn victim không cần global LRU lock

LRU thuần đòi hỏi mỗi truy cập phải promote slot lên đầu danh sách, mà danh sách thì chỉ có một — với hàng trăm backend cùng truy cập, lock toàn cục trên LRU list trở thành điểm nghẽn. PostgreSQL chấp nhận một xấp xỉ LRU rẻ hơn nhiều: clock-sweep.

Một con trỏ nextVictimBuffer chạy vòng tròn qua descriptor array. Mỗi vòng, nó kiểm tra descriptor hiện tại theo logic này:

loop:
  d = descriptors[nextVictimBuffer]
  if d.refcount == 0:
    if d.usage_count == 0:
      return d
    else:
      d.usage_count -= 1
  nextVictimBuffer = (nextVictimBuffer + 1) mod N

Phối hợp với việc backend tăng usage_count mỗi lần chạm vào buffer, thuật toán này tạo ra hành vi mong muốn:

• Page nóng được chạm liên tục → usage_count luôn ở mức cao → vượt qua rất nhiều vòng sweep mới về 0.
• Page lạnh không được chạm → mỗi vòng sweep giảm usage_count thêm một → rơi về 0 nhanh và bị chọn làm victim.
• Buffer đang được pin (refcount > 0) luôn được bỏ qua → không bao giờ evict page đang được dùng.

Chi phí trên hot path là O(1) thao tác trên một descriptor đơn lẻ, không cần global lock.

Flushing dirty pages — bgwriter, checkpointer, và backend

Khi backend ghi vào buffer, nó chỉ set BM_DIRTY rồi đi tiếp — việc đưa nội dung xuống disk là chuyện của ai khác. Có ba “ai khác”, phân vai rõ ràng:

• bgwriter — process chạy liên tục, mỗi bgwriter_delay (mặc định 200 ms) flush tối đa bgwriter_lru_maxpages page (mặc định 100). Điểm cốt lõi: bgwriter ưu tiên flush các page có usage_count = 0 — chính là những candidate sắp bị clock-sweep chọn làm victim. Dọn trước thì khi backend cần evict, victim đã sạch, không phải block chờ I/O.
• checkpointer — định kỳ flush toàn bộ dirty page tại thời điểm checkpoint, và ghi checkpoint record vào WAL. Trigger: checkpoint_timeout (mặc định 5 phút) hoặc khi WAL chạm max_wal_size. Mục tiêu là giới hạn lượng WAL phải replay sau crash; checkpoint càng thưa thì recovery càng lâu.
• Backend tự flush — fallback khi clock-sweep chọn trúng một dirty victim mà bgwriter chưa kịp dọn. Backend bắt buộc phải tự ghi xuống disk trước khi tái sử dụng slot, gây latency spike trực tiếp cho query. Lượng “backend writes” cao là tín hiệu rõ rệt bgwriter đang tune sai — thường là delay quá lớn hoặc max pages quá nhỏ.

Tóm lại, bgwriter “dọn vệ sinh” theo cấp số nhỏ và đoán trước eviction; checkpointer định kỳ “tổng vệ sinh”; backend là phương án cuối khi cả hai không kịp.

5. Kết luận

PostgreSQL storage engine có thể được học từ trên xuống (SQL → query plan → I/O) hoặc từ dưới lên (byte trong file → page → buffer → tuple → MVCC → SQL). Cách thứ hai khó hơn nhưng cho hiểu biết bền vững hơn — bạn không còn lệ thuộc vào “best practice từng nghe nói” mà có thể đọc bất cứ tài liệu nào và suy ra trade-off bằng những nguyên lý đã nắm vững.