Apakah MVCC dalam PostgreSQL?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) ialah cara PostgreSQL mengendalikan akses serentak — daripada mengunci baris untuk bacaan, ia menyimpan **berbilang versi** baris, supaya setiap transaksi melihat **snapshot** data yang konsisten. Faedah utamanya: **pembaca tidak menyekat penulis, dan penulis tidak menyekat pembaca**, membolehkan keserentakan tinggi.

## Idea teras: berbilang versi baris

```text
When a row is UPDATED, Postgres doesn't overwrite it — it creates a NEW version and
marks the old one obsolete. Different transactions can see different versions.
→ Each transaction sees a consistent SNAPSHOT of the database as of its start
  (depending on isolation level), unaffected by others' uncommitted changes.
```

## Faedah besar: tiada kunci bacaan

```text
Without MVCC (lock-based): readers and writers BLOCK each other
  → a long-running report could block writes; a write could block reads.
With MVCC:
  ✓ READERS DON'T BLOCK WRITERS — a SELECT sees an old version while an UPDATE proceeds
  ✓ WRITERS DON'T BLOCK READERS
  ✓ Each transaction sees a stable, consistent view (no dirty reads)
→ Much higher concurrency for read-heavy and mixed workloads.
```

## Bagaimana ia berfungsi (dipermudahkan)

```sql
-- Transaction A starts a long SELECT (sees a snapshot)
BEGIN; SELECT count(*) FROM orders;   -- sees data as of its snapshot

-- meanwhile Transaction B updates rows — creates new versions, doesn't block A
-- A still sees its consistent snapshot; B's changes are a new version
```

Postgres menjejaki ID transaksi dan keterlihatan baris supaya setiap transaksi melihat versi yang betul. Ini menyediakan **pengasingan (isolation)** tanpa kunci bacaan.

## Kos: dead tuple dan VACUUM

```text
MVCC creates obsolete row versions ("dead tuples") that accumulate → bloat.
VACUUM (and AUTOVACUUM) reclaims this dead space and keeps the database healthy.
→ This is why VACUUM is important in Postgres — it's the cleanup for MVCC's versions.
```

## Mengapa ia penting

MVCC adalah asas untuk memahami tingkah laku keserentakan dan prestasi PostgreSQL, jadi ia pengetahuan bernilai untuk bekerja dengan Postgres dengan berkesan.

Nilai teras yang disediakan MVCC ialah **keserentakan tinggi**: dengan menyimpan berbilang versi baris dan memberikan setiap transaksi snapshot yang konsisten, **pembaca tidak menyekat penulis dan penulis tidak menyekat pembaca** — yang merupakan kelebihan utama untuk aplikasi sebenar (laporan yang berjalan lama tidak menyekat kemas kini, dan tulisan tidak menyekat bacaan), membolehkan keserentakan yang jauh lebih baik untuk beban kerja berat-bacaan dan campuran berbanding pendekatan berasaskan kunci.

Inilah sebabnya PostgreSQL mengendalikan akses serentak dengan sangat baik, dan memahami MVCC menjelaskan ciri keserentakan pangkalan data (snapshot konsisten, pengasingan tanpa kunci bacaan, tiada dirty read).

Yang penting, memahami MVCC juga menjelaskan **mengapa `VACUUM` penting dalam Postgres**: MVCC mencipta versi baris usang ("dead tuples") apabila baris dikemas kini dan dipadam, yang terkumpul sebagai bloat, dan `VACUUM`/`AUTOVACUUM` ialah mekanisme pembersihan yang menuntut semula ruang ini dan memastikan pangkalan data sihat — jadi MVCC dan VACUUM berkait rapat, dan mengetahui kaitan ini penting untuk penyelenggaraan dan prestasi pangkalan data (mengabaikan vacuum membawa kepada bloat dan prestasi merosot, kebimbangan operasi sebenar).

Memandangkan tingkah laku keserentakan secara asasnya mempengaruhi cara pangkalan data berprestasi di bawah beban, dan memandangkan MVCC (model keserentakan Postgres) menjelaskan kedua-dua keserentakan baca/tulis yang cemerlang dan keperluan penyelenggaraan VACUUM, memahami MVCC ialah pengetahuan bernilai untuk bekerja dengan PostgreSQL — ia menjelaskan kelebihan keserentakan pangkalan data dan penyelenggaraan yang diperlukannya, penting untuk kedua-dua menaakul tentang prestasi dan mengendalikan Postgres dengan betul, dan topik biasa yang menunjukkan pemahaman tentang cara Postgres mengendalikan akses serentak.