‍ آشنایی با مکانیزم همروندی در پستگرس و ضرورت اجرای منظم Vacuum

یکی از پرسش‌های کلیدی در طراحی پایگاه داده این است که:

🔍 وقتی چندین تراکنش به‌صورت همزمان قصد تغییر رکوردهای مشابه را دارند، سیستم چگونه تصمیم می‌گیرد کدام تغییر اعمال شود؟

پستگرس برای پاسخ به این چالش از مکانیزم MVCC (Multi-Version Concurrency Control) استفاده می‌کند - روشی که اجازه می‌دهد تراکنش‌ها بدون قفل‌های سنگین، همزمان روی داده‌ها کار کنند.


مکانیزم MVCC در پستگرس

در این مدل، هنگام تغییر یک رکورد، نسخه‌ی جدیدی از همان ردیف (tuple) در جدول درج می‌شود یعنی به ازای تراکنش‌های مختلفی که قصد تغییر یک رکورد را دارند، تعداد نسخه های زیادی از آن رکورد به صورت همزمان ایجاد می‌شود؛ اگر در همان صفحه (page) فضای کافی وجود داشته باشد، نسخه‌(ها)ی جدید در همان‌جا ذخیره می‌شود، وگرنه در صفحه‌ی دیگری قرار می‌گیرد.

برخلاف تصور رایج، کل صفحه کپی نمی‌شود - بلکه فقط ردیف(های) جدید افزوده می‌شود و نسخه‌ی قبلی به‌عنوان «مرده» (dead tuple) علامت‌گذاری می‌شود.
اگر تراکنش commit شود، نسخه‌ی جدید قابل مشاهده می‌شود؛ در غیر این صورت، ردیف‌های جدید هرگز برای سایر تراکنش‌ها دیده نمی‌شوند.

✨ مفهوم Page در پستگرس چیست؟

در PostgreSQL، داده‌ها مستقیماً به‌صورت خطی روی دیسک ذخیره نمی‌شوند، بلکه در قالب واحدهایی به نام Page (صفحه) سازمان‌دهی می‌شوند.

هر Page معمولاً حجمی برابر با ۸ کیلوبایت دارد و شامل چندین tuple (یا همان ردیف داده) است.

وقتی داده‌ای جدید درج می‌شود، PostgreSQL ابتدا بررسی می‌کند که آیا در یکی از صفحات موجود فضای کافی برای آن وجود دارد یا نه:

✅ اگر فضا کافی باشد، ردیف جدید در همان صفحه قرار می‌گیرد.

📦 اگر صفحه پر باشد، ردیف جدید در صفحه‌ای دیگر ذخیره می‌شود و ممکن است اندازهٔ فایل جدول افزایش پیدا کند.

در واقع، Page واحد پایهٔ ذخیره‌سازی و بازیابی داده‌ها در پستگرس است؛ همهٔ عملیات خواندن و نوشتن در نهایت در سطح صفحات انجام می‌شود.

🔹 نکته جالب اینجاست که ساختار داخلی جداول در پستگرس به‌صورت #Heap (پشته‌ای/درهم/بدون هیچ ترتیب‌ خاصی) پیاده‌سازی شده است؛
یعنی برخلاف ساختارهای مرتب‌شده مثل B-Tree، ردیف‌ها به‌ترتیب خاصی ذخیره نمی‌شوند : هر رکورد «هرجا که یک پیج، فضای خالی داشته باشد» درج می‌شود.

🎯 ضرورت فرآیند VACUUM

با گذر زمان، رکوردهای قدیمی (dead tuples) باید پاک‌سازی شوند تا فضای جدول بی‌دلیل افزایش نیابد. این وظیفه بر عهده‌ی فرآیند #VACUUM است.

فرآیند VACUUM فضای اشغال‌شده توسط تاپل‌های مرده (رکوردهایی که بازنویسی شده‌اند و نسخه قدیمی آن‌ها باید پاک شود) را برای استفاده‌ی مجدد در همان فایل آزاد می‌کند اما اگر بخواهیم این فضای آزاد شده از حذف رکوردهای مرده از سایز فایل کم شوند و به سیستم عامل برگردند، نیاز به VACUUM FULL داریم که می‌تواند آن فضا را واقعاً به سیستم‌عامل بازگرداند.

در کارگاه عملی این جلسه، با استفاده از PostgreSQL 18 در محیط Docker و ابزار DBeaver، گام‌به‌گام بررسی کردیم که:

🔰مکانیزم MVCC چگونه نسخه‌های مختلف رکوردها را مدیریت می‌کند،

🔰و VACUUM چگونه فضا را بازیابی و از wraparound جلوگیری می‌کند.


🎥 مشاهده ویدئوی کامل در یوتیوب:

👉 https://youtu.be/TtHSDJgFI6g

📌 نکته: در محیط‌های تولیدی، هرگز autovacuum را غیرفعال نکنید - این گزینه فقط برای اهداف آموزشی در این کارگاه موقتاً خاموش شده بود.

Sepahram Data Eng. School

دوره کاربردی پستگرس : https://sepahram.ir/courses/postgresql