چگونه Write-Ahead Logging و Two-Phase Locking اتمیسیته و ایزولاسیون را در پایگاه‌های داده رابطه‌ای تضمین می‌کنند

محدودیت الزام‌آور برای هر پایگاه داده رابطه‌ای این است که رسانه ذخیره‌سازی زیرین باید پیش از تایید نوشتن‌های ترتیبی، آن‌ها را واقعاً ذخیره کند و عملیات همزمان نیز باید از نظر ریاضی قابل سریال‌سازی باشند. اگر دیسک درباره تکمیل دستور fsync دروغ بگوید، یا اگر ۲ پردازش به‌طور همزمان روی یک حافظه بنویسند، کل توهم یک پایگاه داده قابل‌اعتماد فرو می‌ریزد.

در حالی که فروشندگان مدرن پایگاه‌های داده اغلب روی تراکنش‌های با «مقیاس‌پذیری بی‌نهایت» و «تاخیر صفر» مانور تبلیغاتی می‌دهند، قابلیت واقعی آن‌ها به ۲ الگوریتم بنیادین متکی است که دهه‌ها پیش عرضه شده‌اند: ثبت پیش‌از‌نوشتن (WAL) و قفل‌گذاری دوفازی (2PL). این دو در کنار هم، ۴ ویژگی اصلی مدل ACID (اتمیسیته، سازگاری، ایزولاسیون، ماندگاری) را اعمال می‌کنند.[3][5]

اتمیسیته (Atomicity) نرخ موفقیت یا شکست ۱۰۰ درصدی را برای یک تراکنش دیکته می‌کند؛ هیچ‌گونه تکمیل نسبی وجود ندارد. اگر برق سرور در میانه انتقال وجه قطع شود، پایگاه داده باید دقیقاً به حالت پیش از آغاز تراکنش بازگردد و تضمین کند که ۰ داده از دست رفته است.

مکانیزمی که این امر را تضمین می‌کند، ثبت پیش‌از‌نوشتن (WAL) است. همان‌طور که Bytebase اشاره می‌کند، WAL بر اساس یک قانون سخت‌گیرانه «اول لاگ، دوم داده» عمل می‌کند. پیش از آنکه هرگونه تغییری در فایل‌های اصلی پایگاه داده اعمال شود، این تغییرات به یک لاگ ماندگار افزوده می‌شوند.[4]

این طراحی یک گلوگاه حیاتی سخت‌افزاری را حل می‌کند. نوشتن مستقیم در جداول پایگاه داده نیازمند عملیات ورودی/خروجی تصادفی (Random I/O) دیسک است که از نظر فیزیکی کند است. WAL با افزودن تغییرات به یک لاگ ترتیبی، نوشتن‌های تصادفی را به نوشتن‌های سریع و ترتیبی تبدیل می‌کند و ضمن تضمین وجود رکوردی از تراکنش روی دیسک، توان عملیاتی را به‌شدت بهبود می‌بخشد.

در سرفصل دوره ۴۱۱۳ دانشگاه کلمبیا درباره سیستم‌های توزیع‌شده آمده است: «عملیات‌های گنجانده‌شده در یک تراکنش، علی‌رغم خرابی‌های موقت پردازش یا ماشینی که پایگاه داده را اجرا می‌کند، یا همگی موفق می‌شوند یا هیچ‌کدام.» اگر خرابی رخ دهد، پایگاه داده هنگام راه‌اندازی مجدد به‌سادگی لاگ ترتیبی را بازپخش می‌کند تا دقیقاً به همان وضعیت قبلی بازگردد.[1]

در حالی که WAL با واقعیت فیزیکی خرابی‌ها مقابله می‌کند، قفل‌گذاری دوفازی (2PL) هرج‌ومرج منطقی همزمانی را مدیریت می‌کند. در سیستمی که ۲۴ ساعت شبانه‌روز و ۷ روز هفته کار می‌کند، هزاران کاربر ممکن است تلاش کنند تا دقیقاً همان ردیف‌ها را به‌طور همزمان بخوانند و بنویسند.[2]

بروشورهای بازاریابی مرتباً وعده «ایزولاسیون بی‌نقص» را می‌دهند، اما واقعیت مهندسی نیازمند سریال‌پذیری دقیق ریاضی است؛ یعنی این تضمین که وضعیت نهایی پایگاه داده دقیقاً به گونه‌ای باشد که گویی تراکنش‌ها ۱ به ۱ و در یک ترتیب متوالی اجرا شده‌اند.

مایکل فرانکلین در مقاله‌ای در سال ۱۹۹۷ برای دانشگاه کارنگی ملون توضیح می‌دهد که مسئولیت حفظ این ایزولاسیون بر عهده نرم‌افزار کنترل همزمانی است. فرانکلین با تفکیک نقش‌های WAL و 2PL می‌نویسد: «بازیابی تضمین می‌کند که پایگاه داده در برابر خطا مقاوم است؛ به این معنا که وضعیت پایگاه داده در نتیجه خرابی نرم‌افزار، سیستم یا رسانه مخدوش نمی‌شود.»[2]

2PL با تقسیم یک تراکنش به دقیقاً ۲ فاز مجزا به سریال‌پذیری دست می‌یابد: فاز رشد و فاز کاهش. در طول فاز اول، تراکنش قفل‌های مورد نیاز خود (برای خواندن یا نوشتن) را روی داده‌ها دریافت می‌کند، اما نمی‌تواند هیچ‌کدام را آزاد کند.[2]

زمانی که تراکنش به نقطه اوج خود می‌رسد و فاز دوم (فاز کاهش) را آغاز می‌کند، می‌تواند قفل‌ها را آزاد کند اما اکیداً از دریافت قفل‌های جدید منع می‌شود. این سخت‌گیری ریاضی از سناریوهای کلاسیک «بن‌بست» (Deadlock) که در آن تراکنش‌ها تا بی‌نهایت منتظر یکدیگر می‌مانند، جلوگیری می‌کند.

با این حال، این رویکرد بدبینانه با یک بده‌بستان شدید در عملکرد همراه است. از آنجا که 2PL فرض می‌کند تداخل رخ خواهد داد، تراکنش‌ها را مجبور می‌کند در صف منتظر بمانند. در شرایط ترافیک بالا، این سربار قفل‌گذاری می‌تواند توان عملیاتی پایگاه داده را خفه کند و در حالی که پردازش‌ها منتظر آزادسازی قفل هستند، چرخه‌های پردازنده (CPU) را بیکار بگذارد.

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

انتخاب میان 2PL و OCC کاملاً به نرخ تداخل حجم کاری بستگی دارد. در محیط‌هایی با ترافیک بالای نوشتن، هزینه لغو و تلاش مجدد مداوم تراکنش‌های OCC به‌سرعت از سربار قفل‌گذاری پیشاپیش 2PL فراتر می‌رود. در مقابل، حجم‌های کاری که بیشتر شامل خواندن هستند، اغلب از ماهیت بدون قفل OCC بهره می‌برند.