اسید: این بار نه شیمی، بلکه دیتابیس!(قسمت پنجم از مفاهیم دیتابیس)
به قسمت پنجم از سری مجموعه مفاهیم دیتابیس خوش اومدی، توی این قسمت میخواییم شیمی ها رو بریزیم تو دیتابیسا تا اسیدی بشن. دقت کنید که توی این سری مجموعه ما با انواع مفاهیم دیتابیس آشنا میشیم و کاری با کد زدن و نوع خاصی از دیتابیسا ها نداریم
قبل اینکه بریم ببینیم اسید(ACID) چیه باید با مفهوم تراکنش یا همون Transaction آشنا بشیم
مجموعه‌ای از عملیات های پایگاه داده است که یا بایستی به طور کامل انجام بشه یا در صورت بروز مشکل وضعیت به حالت قبلی برگردونده بشه.
✅ اصل اول اتمیک بودن (Atomic)
این اصل میگه یک تراکنش باید به صورت کامل انجام بشه یا اصلا انجام نشه. یعنی یا همه یا هیچ و اگر بخشی از تراکنش با خطا مواجه شد، کل تراکنش لغو میشه و تغییرات Rollback میشن
فرض کنید 100 تومن پول از حساب A میخواییم کارت به کارت کنیم به حساب B خب اول باید 100 تومن از حساب A برداشت بشه و به حساب B واریز بشه یعنی این کارت به کارت طی دومرحله انجام میشه
حالا اگه از حساب A برداشت شد و یه مشکلی پیش اومد به حساب B نرفت چی؟یعنی پول ما رو هوا میمونه دیگه و این خیلی بده
اصل اتمیک میگه اگه این مشکل اتفاق افتاد باید پول برگردونده بشه به حساب A
✅ اصل دوم یکپارچگی (Consistency)
این اصل میگه تراکنش باید دیتابیس را از یک وضعیت معتبر به وضعیت معتبر دیگری منتقل کنه. یعنی هیچوقت دیتابیس نباید در وضعیت نامعتبر قرار بگیره.
بازم با مثال قبلی توضیحش میدم، ببینید جمع موجودی حساب A و B قبل و بعد از ترنزکشن(کارت به کارت کردنمون) باید برابر باشه. مثلا اگه 100 تومن از حساب A برداشت بشه و به حساب B واریز بشه، مجموع موجودی حساب‌ها نباید تغییری کنه. یعنی حساب ها باید وضعیت معتبر خودشون رو حفظ کنن
✅ اصل سوم ایزوله بودن (Isolation)
این اصل میگه تراکنش ها باید به گونه‌ای اجرا بشن که به نظر برسه هر تراکنش به صورت مستقل انجام میشه، حتی اگر همزمان با ترنزکشن‌های دیگه اجرا بشه. این ویژگی مانع از اثرگذاری منفی ترنزکشن‌ها روی همدیگه میشه.
ببینید مثلا اگه کاربر اول ۵۰ تومان برداشت کنه و کاربر دوم هم همزمان بخواهد برداشت کند(هردو از یک حساب)، نباید کاربر دوم قبل از به‌روزرسانی دیتابیس توسط کاربر اول، به موجودی قدیمی دسترسی داشته باشه. چون مثلا موجودی حساب کلا 50 تومنه هم کاربر اول 50 تومن رو برداشت کنه هم دوم !!!! نمیشه که
این ایزولیشن رو میتونید توی سفارشات هم ببینید اونجا که از یک محصول مثلا یه دونه موجوده بعد دونفر همزمان اون یه دونه رو بخرن که خب اگه ازولیشن رعایت نشه ممکنه مشکل به وجود بیاد
✅ اصل چهارم پایداری (Durability)
و در آخر هم این اصل میگه پس از تکمیل موفقیت‌آمیز یک تراکنش، تغییرات آن باید دائمی باشن و حتی در صورت خرابی سیستم هم از بین نرن. یعنی یهو برق رفت همه چی نره باد فنا
مثلا در یه سیستم بانکی، اگر بعد از واریز پول به حساب B سیستم خراب شد، باید مطمئن باشیم که مبلغ واریز‌شده همچنان در حساب B موجوده.
✅ حالا اگه ایزولیشن نباشه چی میشه ؟؟؟
ممکنه این سه مشکل به وجود بیان که خلاصه وار توضیحشون میدم:
مشکل Dirty Read 👈 وقتی یک تراکنش، داده‌ای رو که توسط تراکنش دیگری تغییر یافته اما هنوز نهایی نشده (Commit نشده) است، بخونه. اگر تراکنش اول تغییرات خود را Rollback کند، تراکنش دوم به داده‌های نامعتبر دسترسی پیدا کرده و حالا بیا و درستش کن.
مشکل non-Repeatable Read 👈 وقتی یک تراکنش در طول اجرای خود، دوبار یک مقدار رو بخونه و به دلیل تغییر داده توسط تراکنش دیگری، هر بار مقدار متفاوتی ببیند.
مشکل Phantom Read 👈 وقتی یک تراکنش چند بار یک کوئری رو اجرا کنه و هر بار تعداد نتایج متفاوتی دریافت کنه، به دلیل اینکه تراکنش دیگری در این بین داده‌ها رو اضافه یا حذف کرده.
✅ چهار سطح ایزوله سازی در دیتابیس
اینکه کدوم از این چهارتا رو کی و کجا باید استفاده کنیم وابسته به نوع دیزاین و پروژتون داره
سطح read uncommited 👈 در این سطح، یک تراکنش می‌تونه داده‌هایی رو بخونه که توسط تراکنش دیگری تغییر پیدا کرده اما هنوز Commit نشده(یعنی هنوز تو دیتابیس ننشسته).
سطح read commited 👈 یک تراکنش فقط می‌تونه داده‌هایی را بخونه که توسط تراکنش های دیگه Commit شده‌اند.
سطح repeatable read 👈 یک تراکنش تضمین می‌کنه که داده‌های خوانده‌شده در طول تراکنش تغییر نخواهند کرد.
سطح serializable 👈 بالاترین سطح ایزوله‌سازی که تضمین می‌کنه تراکنش ها به گونه‌ای اجرا بشن که انگار به صورت سریالی و پشت‌سرهم اجرا شده‌اند. توی این سطح هیچکدوم از اون سه مشکل بالا رو نداریم.
امیدوارم مورد استفاده اتون قرار گرفته باشه
اگه دوست داشتید توی کانال تلگرامیمون هم عضو بشید LearnByLearn@
