ارزیابی ACID در برابر BASE: چگونه پایگاه‌های داده توزیع‌شده، قابلیت سریال‌سازی سختگیرانه را فدای در دسترس بودن بالا می‌کنند

فروشندگان نرم‌افزارهای سازمانی اغلب پایگاه‌های داده توزیع‌شده را به گونه‌ای تبلیغ می‌کنند که گویی می‌توانند هم دقت بی‌نقص داده‌ها و هم زمان کارکرد بدون وقفه را در مقیاس جهانی ارائه دهند. اما واقعیت ریاضی، که توسط قضیه CAP اریک بروئر در سال ۲۰۰۰ تعریف شد، ثابت می‌کند که این ترکیب در طول تقسیم‌بندی‌های شبکه (network partitions) غیرممکن است. هنگامی که یک لینک شبکه قطع می‌شود، معماری پایگاه داده یا باید عملیات را برای محافظت از یکپارچگی داده متوقف کند – رویکرد ACID – یا به ارائه اطلاعات بالقوه قدیمی ادامه دهد تا در دسترس بودن را حفظ کند، که فرض اصلی BASE است. همانطور که جان دی. کوک اشاره می‌کند: «شما نمی‌توانید هم سازگاری (Consistency) و هم در دسترس بودن (Availability) را در یک شبکه تقسیم‌شده داشته باشید.»[3][6]

مدل ACID – اتمی بودن (Atomicity)، سازگاری (Consistency)، ایزوله‌سازی (Isolation)، و پایداری (Durability) – از اواخر دهه ۱۹۷۰ بر سیستم‌های مدیریت پایگاه داده رابطه‌ای حاکم بوده است. این مدل، قابلیت سریال‌سازی (serializability) را تضمین می‌کند، به این معنی که تراکنش‌های همزمان دقیقاً همان وضعیت پایگاه داده را ایجاد می‌کنند که گویی به صورت متوالی اجرا شده‌اند. مستندات MongoDB توضیح می‌دهد که یک تراکنش ACID تضمین می‌کند که «همه عملیات درون تراکنش با هم موفق یا ناموفق شوند»، و از به‌روزرسانی‌های جزئی جلوگیری می‌کند. این مکانیزم قفل‌گذاری سختگیرانه از ناهنجاری‌هایی مانند خواندن کثیف (dirty reads) یا خواندن شبح (phantom reads) جلوگیری می‌کند و آن را به استاندارد غیرقابل مذاکره برای دفاتر مالی و سیستم‌های موجودی تبدیل کرده است که در آن‌ها نرخ خطای ۰٫۰۱٪ فاجعه‌بار است.[2]

با این حال، این تضمین در محیط‌های توزیع‌شده، هزینه‌ی عملکردی سنگینی را تحمیل می‌کند. برای حفظ سازگاری سختگیرانه در چندین گره جغرافیایی، سیستم‌های ACID معمولاً از پروتکل‌های تعهد دو مرحله‌ای (two-phase commit) استفاده می‌کنند. اگر یک گره در لندن نتواند با گره‌ای در توکیو ارتباط برقرار کند، کل تراکنش مسدود می‌شود تا زمانی که اتصال بازیابی شود. این سربار تأخیر (latency overhead) مقیاس‌پذیری ضعیفی دارد؛ یک تحلیل در Dataversity در سال ۲۰۱۲ تأکید کرد که با انفجار حجم داده‌ها، «سازگاری سختگیرانه ACID به یک گلوگاه تبدیل می‌شود.» سیستم ترجیح می‌دهد غیرقابل دسترس باشد تا اینکه ریسک یک وضعیت ناسازگار را بپذیرد.[4]

در پاسخ به محدودیت‌های مقیاس‌پذیری ACID، معماری BASE در اواخر دهه ۲۰۰۰ در کنار جنبش NoSQL ظهور کرد. BASE که مخفف در دسترس بودن اساسی (Basically Available)، حالت نرم (Soft state) و سازگاری نهایی (Eventual consistency) است، صراحتاً قابلیت سریال‌سازی فوری را فدا می‌کند تا تضمین کند که سیستم به پذیرش عملیات خواندن و نوشتن ادامه می‌دهد. همانطور که در تحلیل معماری ByteByteGo در سال ۲۰۲۴ آمده است، سیستم‌های BASE با اجازه دادن به کپی‌های داده برای واگرایی موقت، «در دسترس بودن بالا و عملکرد» را در اولویت قرار می‌دهند. اگر تقسیم‌بندی شبکه رخ دهد، سیستم به‌روزرسانی را به صورت محلی می‌پذیرد و تضاد را بعداً حل می‌کند.[5]

«حالت نرم» (Soft state) در BASE به این معنی است که واقعیت داخلی پایگاه داده بدون ورودی صریح برنامه، دائماً در حال تغییر است و تنها پس از تأخیر به سمت دقت همگرا می‌شود. این پنجره سازگاری نهایی اغلب بر حسب میلی‌ثانیه اندازه‌گیری می‌شود، اما در طول افت شدید شبکه، می‌تواند تا ثانیه یا دقیقه طول بکشد. یک بازنگری در مورد قضیه CAP که در سال ۲۰۱۲ در ResearchGate منتشر شد، مشاهده کرد که سیستم‌های مدرن به طور فزاینده‌ای از «مدل‌های سازگاری انعطاف‌پذیر» استفاده می‌کنند که به توسعه‌دهندگان اجازه می‌دهد این پنجره را بر اساس عملیات خاص تنظیم کنند.[1]

هنگامی که یک سیستم BASE به کپی‌ها اجازه واگرایی می‌دهد، باید در نهایت داده‌های متضاد را آشتی دهد. سیستم‌هایی مانند DynamoDB آمازون از ساعت‌های برداری (vector clocks) یا الگوریتم‌های «آخرین نوشتن برنده است» (last-write-wins) مبتنی بر مُهر زمانی استفاده می‌کنند تا تعیین کنند کدام به‌روزرسانی باقی بماند. یک تحلیل اخیر ResearchGate در مورد مدل‌های ساختاربندی NoSQL اشاره کرد که این حل تضاد اغلب نیازمند «آگاهی در سطح برنامه» است و توسعه‌دهندگان را مجبور می‌کند منطق سفارشی بنویسند تا موارد خاصی را که آشتی خودکار شکست می‌خورد، مدیریت کنند. این امر بار یکپارچگی داده را از موتور پایگاه داده به تیم مهندسی نرم‌افزار منتقل می‌کند.[7]

انتخاب دوتایی بین ACID و BASE در طول یک تقسیم‌بندی، تنها نیمی از ماجرا را بیان می‌کند. قضیه PACELC که در سال ۲۰۱۰ توسط دانیل عبادی فرمول‌بندی شد، CAP را با پرداختن به عملیات عادی گسترش می‌دهد: حتی زمانی که شبکه به طور عادی کار می‌کند، یک سیستم باید بین تأخیر (Latency) و سازگاری موازنه ایجاد کند. یک پایگاه داده که برای انطباق سختگیرانه ACID پیکربندی شده است، همیشه تأخیر بیشتری را متحمل می‌شود زیرا باید قفل‌ها را در سراسر گره‌ها قبل از تأیید یک عملیات نوشتن، تأیید کند. در مقابل، یک سیستم BASE بلافاصله پیام موفقیت را برمی‌گرداند و تأخیر تکثیر (replication latency) را از کاربر پنهان می‌کند.[5]

این موازنه تأخیر، پیامدهای مالی مستقیمی دارد. غول‌های تجارت الکترونیک مدت‌هاست مستند کرده‌اند که تأخیر ۱۰۰ میلی‌ثانیه‌ای در زمان بارگذاری صفحه می‌تواند فروش را تا ۱٪ کاهش دهد. برای این حجم‌های کاری سنگین خواندن، قفل‌گذاری خوش‌بینانه (optimistic locking) در معماری‌های BASE یک مزیت درآمدی قابل اندازه‌گیری فراهم می‌کند. با این حال، همانطور که جان دی. کوک اشاره می‌کند، این خوش‌بینی فرض می‌کند که تضادها نادر هستند؛ در محیط‌های با رقابت بالا که چندین کاربر همزمان تلاش می‌کنند یک رکورد مشابه را تغییر دهند، هزینه محاسباتی حل تضادها می‌تواند از صرفه‌جویی اولیه در تأخیر بیشتر شود.[3]

مرز سخت بین این دو پارادایم در حال محو شدن است. پایگاه‌های داده رابطه‌ای سنتی در حال پذیرش ویژگی‌های توزیع‌شده هستند، در حالی که پیشگامان NoSQL در حال افزودن تضمین‌های ACID به زیربنای BASE خود هستند. در سال ۲۰۱۸، MongoDB تراکنش‌های ACID چند سندی را معرفی کرد و تلاش کرد تا شکاف را برای مشتریان سازمانی پر کند. با این حال، این رویکردهای ترکیبی همچنان با محدودیت‌های فیزیکی اساسی روبرو هستند؛ افزودن قفل‌های ACID به یک سیستم BASE ذاتاً در دسترس بودن آن را کاهش داده و تأخیر آن را در طول رویدادهای تقسیم‌بندی افزایش می‌دهد.[2]

تصمیم معماری بر اساس هزینه خاص یک ناهنجاری داده در مقابل هزینه از کار افتادگی (downtime) استوار است. یک درگاه پرداخت که انتقال‌های ۱۰٬۰۰۰ دلاری را پردازش می‌کند، نمی‌تواند سازگاری نهایی را تحمل کند، در حالی که یک فید رسانه اجتماعی که به ۵۰ میلیون کاربر فعال روزانه خدمات می‌دهد، نمی‌تواند هر بار که کاربری پستی را لایک می‌کند، پایگاه داده خود را قفل کند. چالش مهندسی دیگر انتخاب یک پارادایم واحد برای کل برنامه نیست، بلکه جدا کردن ۵٪ از عملیاتی است که به سریال‌سازی سختگیرانه نیاز دارند، از ۹۵٪ که در دسترس بودن بالا را طلب می‌کنند.[8]