რა არის MVCC PostgreSQL-ში?

Question

Accepted Answer

**MVCC** (Multi-Version Concurrency Control) არის ის, თუ როგორ ამკებს PostgreSQL კონკურენტულ წვდომას — მწკრივების ჩაკეტვის ნაცვლად წაკითხვებისთვის, იგი ინახავს **მწკრივების მრავალ ვერსიას**, ასე რომ თითოეული ტრანზაქცია ხედავს ონაერთი თანმიმდევრული **სნაპშოტი** მონაცემებიდან. მთავარი უპირატესობა: **მკითხველები არ აკეტავენ მწერლებს, და მწერლები არ აკეტავენ მკითხველებს**, რაც უზრუნველყოფს მაღალ კონკურენციას.

## ძირითადი იდეა: მწკრივების მრავალი ვერსია

```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.
```

## დიდი უპირატესობა: წაკითხვის ჩაკეტვის გარეშე

```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.
```

## როგორ მუშაობს (გამარტივებული)

```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 ტრეკავს ტრანზაქციის ID-ებს და მწკრივის ხილვადობას, ასე რომ თითოეული ტრანზაქცია ხედავს სწორ ვერსიას. ეს უზრუნველყოფს **იზოლაციას** წაკითხვის ჩაკეტვის გარეშე.

## ღირებულება: მკვდარი tuple-ები და 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.
```

## რატომ აქვს მნიშვნელობა

MVCC ფундამენტური ადგილი უკავია PostgreSQL-ის კონკურენტობის ქცევის და წარმადობის გაგებაში, ამიტომ ეს ღირებული ცოდნაა PostgreSQL-თან ეფექტურად მუშაობისთვის.

MVCC-ს ძირითადი მნიშვნელობა არის **მაღალი კონკურენცია**: მწკრივების მრავალი ვერსიის შენარჩუნებით და თითოეული ტრანზაქციის ერთიანი სნაპშოტის მოწოდებით, **მკითხველები არ აკეტავენ მწერლებს და მწერლები არ აკეტავენ მკითხველებს** — რაც დიდი უპირატესობაა რეალური აპლიკაციებისთვის (ხანმოკლე ანგარიშის აღება არ აკეტავს განახლებებს, და ჩანაწერი არ აკეტავს წაკითხვას), რაც უზრუნველყოფს ბევრად უკეთეს კონკურენციას საკითხის მძიმე და შერეული სამუშაოს დატვირთვებისთვის, ვიდრე ჩაკეტვაზე დაფუძნებული მიდგომები.

ეს არის მიზეზი, რატომ ამკებს PostgreSQL კონკურენტულ წვდომას ისე კარგად, და MVCC-ს გაგება აexplains მონაცემთა ბაზის კონკურენტობის მახასიათებლებს (თანმიმდევრული სნაპშოტები, იზოლაცია წაკითხვის ჩაკეტვის გარეშე, რეპლიკები არ წაკითხულა).

კრიტიკულია, რომ MVCC-ს გაგება ასევე აvyasvyteb **რატომ არის მნიშვნელოვანი `VACUUM` Postgres-ში**: MVCC ქმნის მოძველებულ მწკრივის ვერსიებს ("მკვდარი tuple-ები") რადგან მწკრივები განახლდება და წაიშლება, რომლებიც დაგროვდება როგორც bloat, და `VACUUM`/`AUTOVACUUM` არის გაწმენდის მექანიზმი, რომელიც აბრუნებს ამ ადგილს და ინახავს მონაცემთა ბაზას ჯანსაღ მდგომარეობაში — ასე რომ MVCC და VACUUM მჭიდროდ დაკავშირებულია, და ამ კავშირის ცოდნა მნიშვნელოვანია მონაცემთა ბაზის შენარჩუნებისა და წარმადობისთვის (vacuum-ის უგულებელყოფა იწვევს bloat-ს და გაუარესებულ წარმადობას, რეალური ოპერაციული წინააღმდეგობა).

ვინაიდან კონკურენტობის ქცევა ფუნდამენტურად გავლენას ახდენს იმაზე, თუ როგორ ფუნქციონირებს მონაცემთა ბაზა დატვირთვის ქვეშ, და MVCC (Postgres-ის კონკურენტობის მოდელი) აzsvyasvyteb ბოლოდ გამოკითხვის/ჩაწერის უკეთეს კონკურენციას და VACUUM შენარჩუნების საჭიროებას, MVCC-ს გაგება ღირებული ცოდნაა PostgreSQL-თან მუშაობისთვის — ის ხსნის მონაცემთა ბაზის კონკურენტობის უპირატესობებს და მის მიერ მოთხოვილ შენარჩუნებას, მნიშვნელოვანი როგორც წარმადობის მიზეზების უკან დაფიქრებისთვის, ასევე Postgres-ის სწორად ოპერირებისთვის, და ცნობილი თემა, რომელიც აჩვენებს გაგებას იმის შესახებ, თუ როგორ ამკებს Postgres კონკურენტულ წვდომას.