مطابقت با قاعده ACID در پایگاه‌های داده

در دنیای امروزی داده و اطلاعات اهمیت بسیار زیادی دارند تا جایی که در سال ۲۰۱۷ مجله اکونومیست عنوان کرد که داده از نفت ارزشمندتر بوده و به ارزشمند ترین منبع دنیای امروزی تبدیل شده است. در عین حال حجم داده ها در دنیای مدرن آنچنان زیاد است که مهندسان همیشه به دنبال راه های جدیدی برای مدیریت داده ها و ذخیره سازی مطمئن آن ها هستند. اگر به صورت حرفه ای با پایگاه های داده سر و کار داشته باشید احتمالا نام قاعده ACID را شنیده اید. آقای Jim Gray‎ قاعده ACID را به عنوان ویژگی‌ های یک سیستم تراکنش مطمئن در اواخر دهه ۱۹۷۰ معرفی کرد. کلمه ACID مخفف atomic و consistency و isolation و durability است بنابراین قاعده ACID در اصل خودش از چهار قاعده کوچک تشکیل شده است. هر پایگاه داده ای که از این چهار قانون تبعیت کند ACID Compliant است که یعنی با قاعده ACID انطباق دارد اما قاعده ACID چیست و چرا چنین موضوعی برای ما اهمیت دارد؟

قاعده ACID چیست؟

ACID مجموعه ای از قوانین است که باعث می شود تراکنش های پایگاه داده به طور مطمئن پردازش شوند. زمانی که صحبت از تراکنش های پایگاه داده می کنیم منظورمان مجموعه عملیات هایی است که در سمت پایگاه داده انجام می شود بنابراین آن را با تراکنش های مالی (نوع خاصی از تراکنش) اشتباه نگیرید. کلمه تراکنش در دنیای پایگاه های داده معانی بسیار مختلفی دارد. مثلا وب سایت MongoDB از کلمه تراکنش برای اشاره به مجموعه عملیات هایی استفاده می کند که باید همگی با هم اجرا شوند و نقص در یکی از آن ها به معنی نقص در تمام آن ها است. بنابراین تفاوت های جزئی در معنی طبیعی است. اگر تراکنش های پایگاه داده مطمئن و قابل اعتماد نباشند ممکن است بخشی از داده ها را از دست بدهیم یا آن ها را به طور غلط ذخیره کنیم. از آنجایی که داده بسیار اهمیت بالایی دارد، نمی توانیم ریسک چنین مواردی را قبول کنیم.

قاعده اول: Atomicity یا تجزیه ناپذیری

Atomicity در لغت به معنی «اتمی بودن» است اما در عمل به معنی تجزیه ناپذیری می باشد. تراکنش های پایگاه داده مانند اتم ها بخش های مختلفی دارند اما همانطور که یک اتم آهن فقط زمانی اتم آهن است که کامل باشد، تراکنش ها نیز فقط زمانی تراکنش محسوب می شود که کامل باشند. به همین دلیل است که به atomicity در فارسی تجزیه ناپذیری می گوییم.

قاعده Atomicity بیان می کند که تراکنش ها فقط زمانی مقبول هستند که کامل شده باشند و اگر فقط بخشی از آن ها انجام شده باشند نامعتبر هستند. به زبان ساده تر یا تمام تراکنش انجام می شود یا اینکه از نظر ما اصلا تراکنشی وجود ندارد.

بیایید یک مثال را در نظر بگیریم. در صورتی که شما در یک فروشگاه اینترنتی هستید، باید محصولات را  در سبد خرید خود قرار بدهید و در نهایت هزینه آن ها را از درگاه های بانکی پرداخت کنید. آیا می توانید پولی را برای محصولی پرداخت کنید که در سبد خریدتان وجود ندارد؟ قطعا خیر. آیا می توانید محصولی را بدون پرداخت پول بخرید؟ قطعا خیر. اگر هزینه خرید ۲۰۰ هزار تومان باشد آیا می توانید نصف این پول را بپردازید؟ قطعا خیر. بنابراین متوجه می شوید که یا یک تراکنش به صورت ۱۰۰% کامل می شود یا اینکه از نظر ما هیچ تراکنشی وجود نداشته است.

این مسئله زمانی اهمیت دو چندان پیدا می کند که قطعی و crash شدن سیستم های کامپیوتری را در نظر بگیریم. به طور مثال اگر در هنگام پرداخت هزینه یک محصول باشیم و در همان لحظه برق خانه ما قطع شود یا سرور های بانک دچار مشکل شوند چه اتفاقی می افتد؟ بعد از چند روز پول شما برگشت داده می شود. چرا؟ به دلیل اینکه تراکنش های بانکی مانند تراکنش های پایگاه داده باید اتمی یا تجزیه ناپذیر باشند. یا تمام فرآیند خرید انجام می شود یا اینکه هیچ خریدی انجام نشده است.

قاعده دوم: Consistency یا ثبات

اگر بخواهیم پایگاه داده ای طبق انتظار ما عمل کند، باید قوانین اعتبارسنجی دقیقی را برای داده های خود داشته باشد. با این حساب تنها داده هایی که بر اساس این قوانین اعتبارسنجی صحت داشته باشند، اجازه ثبت شدن در پایگاه داده را دارند. قاعده Consistency در زبان فارسی با نام همخوانی نیز شناخته می شود.

اگر در لحظه ای تراکنشی اتفاق بیفتد و بر اساس آن تراکنش داده هایی ایجاد شوند که از قوانین اعتبارسنجی پیروی نمی کنند، roll back اتفاق می افتد یا به عبارتی پایگاه داده به آخرین وضعیت (state) معتبر خود برمی گردد. از طرف دیگر اگر داده های تراکنش با قوانین اعتبارسنجی مطابقت داشته باشند، داده های جدید در پایگاه داده ثبت شده و وضعیت (state) جدیدی را می سازند. به زبان فنی تر، زمانی که تراکنش پایان می یابد، تمام داده‌ها باید در وضعیت پایدار قرار بگیرند و هر تراکنش پایگاه داده را از یک حالت معتبر به حالت معتبر دیگری می برد.

باز هم از یک مثال بانکی برای روشن شدن این موضوع استفاده می کنم. هر حساب بانکی باید موجود مثبت داشته باشد و امکان ندارد که موجود حساب یک نفر منفی باشد. چرا؟ به دلیل اینکه بانک به کسی پول قرض نمی دهد! از طرفی هر بار که کاربر خریدی انجام می دهد از موجودی حساب او کم می شود. اگر به جایی برسیم که یک تراکنش باعث منفی شدن موجود حساب کاربر شود چطور؟ مثلا کاربر در حساب خود ۱۰۰ هزار تومان دارد اما سبد خرید او ۲۰۰ هزار تومان است. در این حالت نباید موجود او منفی ۱۰۰ هزار تومان شود بلکه باید خطایی دریافت کند که موجود حساب او کافی نیست. زمانی که چنین تراکنشی اجرا شود، پایگاه داده متوجه می شود که موجودی منفی شده است بنابراین roll back می کند و اجازه ثبت این داده ها را نمی دهد.

قاعده سوم: Isolation یا انزوا

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

انزوای تراکنش ها در چنین پایگاه های داده ای به معنی قابلیت پردازش همزمان تراکنش ها به شکلی است که روی یکدیگر تاثیر نگذارند. یعنی چه؟ فرض کنید شما و همسایه شما می خواهید به صورت همزمان از یک فروشگاه اینترنتی ماست بخرید. این فروشگاه ۴ عدد ماست دارد. همسایه شما ۳ ماست و شما ۲ ماست می خواهید. اگر تراکنش ها از هم مستقل نباشند، فروشگاه به هر دوی شما ماست می فروشد و از حسابتان پول کم می شود اما در مغازه به اندازه کافی ماست وجود ندارد! آیا متوجه مشکل شدید؟

در پایگاه های داده واقعی مبحث انزوا بدین شکل اجرا می شود که هر کسی زودتر کلیک کند، ابتدا درخواست او پردازش می شود. یادتان باشد که کامپیوتر ها بسیار دقیق هستند و زمان را در سطح میکروثانیه و دقیق تر درک می کنند بنابراین در مثال بالا ابتدا همسایه شما ۳ ماست می خرد و سپس به شما پیام خطا داده می شود که موجود باقی مانده فقط یک عدد می باشد و نمی توانید ۲ ماست بخرید.

این مسئله در اصطلاح فنی به serializable بودن تراکنش ها معروف است. یعنی تراکنش ها به صورت «سریالی» و با ترتیب خاص اجرا می شوند. با ارسال درخواست های مختلف به پایگاه داده یک صف سراسری در پایگاه داده برای این درخواست ها ایجاد شده و سپس آن ها به ترتیب اجرا می شوند. احتمالا همانطور که حدس می زنید این مسئله سرعت پایگاه داده را کمی پایین می آورد اما در برنامه هایی که به انزوای تراکنش ها نیاز داریم (وب سایت های فروشگاهی، بانک ها و ...) این مسئله ضروری است و پایین تر آمدن جزئی سرعت اهمیتی ندارد. به طور مثال موتور MyISAM در پایگاه داده MySQL سریع تر از InnoDB است اما نمی تواند از تراکنش های بانکی پشتیبانی کند بنابراین عملا برای برنامه هایی که تراکنش بانکی دارند بدون استفاده است.

قاعده چهارم: Durability یا پایایی

از هر زبان و هر تکنولوژی که استفاده کنید همیشه احتمال وجود خطا در سیستم وجود دارد بنابراین هدف اصلی ما حذف خطا ها نیست بلکه کاهش خطا ها تا حد ممکن و همچنین مخفی کردن خطا ها از دید کاربران است. در پایگاه های داده ای که از قاعده پایایی داده پیروی می کنند، پس از اتمام کامل یک تراکنش داده ها در پایگاه داده ذخیره می شوند حتی اگر برق سرور به طور کامل قطع شود.

تصور کنید که به صورت آنلاین بلیط سینما خریداری کرده اید. حالا فرض کنید پس از اینکه خرید شما تایید شد، برق دیتاسنتر قطع شده و به پایگاه داده ضربه ای وارد شود. اگر پایگاه داده از قاعده پایایی داده پشتیبانی نکند، ممکن است بلیط های خریداری شده توسط شما از سیستم حذف شوند. طبیعتا چنین موضوعی به شدت به سرویس های آنلاین ضرر می رساند و باید به هر شکلی از آن ها دوری شود.

به زبان فنی تر، تراکنش‌هایی که به مرحله انجام (Commit) برسند اثرشان ماندنی است و هرگز به طور تصادفی از بین نمی رود. پایایی داده ها به روش های مختلفی انجام می شود که از محدوده این مقاله خارج است.

چه پایگاه های داده ای با قاعده ACID مطابقت دارند؟

بسیاری از پایگاه های داده امروزی با قاعده ACID انطباق دارند اما می توانند متفاوت نیز باشند. به طور مثال موتور MyISAM در پایگاه داده MySQL سریع تر از InnoDB است اما نمی تواند از تراکنش های بانکی پشتیبانی کند یا نمی تواند constraint های خاصی را روی جدول های شما بگذارید. با این حساب زمانی که در حال انتخاب راه اندازی MySQL هستید باید حواستان به موتور انتخاب شده باشد.

مثال دیگر می تواند MongoDB باشد. این پایگاه داده از نسخه ۴ به بعد از تراکنش های multi-document ACID transactions پشتیبانی می کند اما نسخه های قبلی آن اینطور نیستند. همچنین این تراکنش های ACID در MongoDB محدودیت های خاصی دارند. مثلا نمی توانید با آن ها کالکشن خاصی را بسازید بلکه تمام کالکشن ها باید از قبل ساخته شده باشند.

پایگاه داده ای مانند Postgresql نیز یکی از پایگاه های داده مشهور است و ساختار آن تا حد ممکن با ACID مطابقت دارد. یکی از دلایل شهرت Postgresql انطباق بالای آن با ACID به صورت پیش فرض و قابلیت های بسیار زیاد آن است.

با این حساب نه تنها پایگاه داده بلکه روش استفاده و پیکربندی آن است که مطابقت با قاعده ACID را تعیین می کند.

منبع: وب سایت mariadb