در دیتابیس مفهومه ACID چیه؟

شماره یک ( 🅰️ - Atomicity):

به این معناست که یک transaction (عملیات در دیتابیس) یا کامل انجام میشه یا اصلاً انجام نمیشه.
اگه در طول اجرای transaction خطایی رخ بده، تمام تغییرات انجام‌شده در دیتابیس باید لغو بشه (rollback) تا دیتابیس در وضعیت اولیه باقی بمونه.

📌 مثلا؟؟
فرض کنین شما در حال انتقال پول از حساب بانکیتون به حساب شخص دیگه ای هستین. اگه فرایند انتقال بطور کامل انجام بشه (یعنی پول از حساب شما کم شده و به حساب اون شخص اضافه بشه)، تراکنش موفقیت‌آمیزه.✅️

اما اگه وسطه عملیات مشکلی پیش بیاد (مثلاً اتصال اینترنت قطع بشه)، هیچ‌کدوم از این تغییرات نباید در دیتابیس باقی بمونه. یعنی یا همه عملیات‌ها باید انجام بشن، یا هیچکدوم نباید انجام بشن.
#Database
#ACID
#Atomicity

@GoldenCodeir

خب حالا بریم سراغ C یا همون Consistency(سازگاری) در ACID:

ویژگی Consistency در دیتابیس یعنی بعد از انجام هر transaction، دیتاهامون باید همیشه صحیح و درست باقی بمونن. یعنی دیتابیس نباید هیچ وقت به وضعیتی نادرست یا اشتباه برسه.

📌 اگه transaction ها قوانین دیتابیس رو رعایت نکنن (مثلاً مقدار موجودی کافی نباشه)، سیستم اونا رو رد میکنه و هیچ تغییری روی داده‌ها اعمال نمیشه.
پس یعنی بعد از هر تغییر در دیتابیس، سیستم باید مطمئن بشه که همه‌چیز درست و منطبق با قوانین دیتابیس هستش.

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

این نشون دهنده Consistency است که سیستم همیشه دیتاهای صحیح و قابل اعتماد رو حفظ میکنه.👌🏾
#ACID
#SQL
#Database

@GoldenCodeir

خب بریم سراغ مفهوم Isolation (جداسازی) در ACID ✅️

وقتی یک برنامه با دیتابیس کار میکنه ممکنه چندین Transaction بطور همزمان اجرا بشن. هر transaction مجموعه‌ای از عملیات روی داده‌هاس که باید بصورت یک واحد کامل انجام بشه.

مفهومه Isolation اینه که transaction ها باید بصورت جدا و مستقل از هم اجرا بشن، یعنی طوری که عملیات یک transaction تا قبل از پایان کاملش برای transaction های دیگه قابل مشاهده نباشه.

📌 اصلا چرا Isolation مهمه؟

فرض کنین دو transaction همزمان در حال تغییر اطلاعات یک حساب بانکی هستن:

بر فرض transaction اول: ۱۰۰ هزار تومان از حساب کم کنه.

و transaction دوم: ۵۰ هزار تومان به حساب اضافه کنه.


📌 اگه این transaction ها بدرستی جداسازی نشن چی میشه؟؟

ممکنه مقدار نهایی اشتباه محاسبه بشه، مثلاً چون هر transaction دیتاهای transaction دیگه رو نمیبینه یا به صورت ناقص میبینه.



در نتیجه، Isolation تضمین میکنه که transaction ها به گونه‌ای اجرا بشن که انگار پشت سر هم انجام شدن ودر نتیجه، دیتاهامون بدرستی و بصورت سازگار باقی میمونه .

در عمل، سطح‌های مختلفی از Isolation وجود داره (مثل Read Uncommitted، Read Committed، Repeatable Read، Serializable) که کنترل میکنن چقد transaction میتونن تغییرات یکدیگر رو ببینن و تداخل داشته باشن.

⚠️ سطح بالا مثل Serializableحداکثر جداسازی رو تضمین میکنه ولی ممکنه باعث کاهش کارایی بشه!

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

#ACID

@GoldenCodeir

مفهوم D (Durability) در ACID

وقتی یک transaction در دیتابیس COMMIT میشه، باید مطمئن باشیم تغییراتش برای همیشه ذخیره شدن و حتی در صورت قطع برق یا crash سیستم از بین نمیرن. این همون Durability (ماندگاری) هستش.

💡یه مثال :
وقتی پول از حساب بانکیت به حسابه دوستت منتقل میشه و پیام "انتقال موفق بود" میگیری، حتی اگه برق دیتاسنتر قطع بشه، دیتابیس تضمین میکنه که تراکنش انجام شده . این همون Durability هستش.


📌 روش‌های اصلی برای تضمین Durability:

شماره ۱. Write-Ahead Logging (WAL)

تغییرات ابتدا در WAL ثبت میشن و بعدش روی داده‌های اصلی اعمال میشن.
تا زمانیکه تغییرات در WAL ثبت نشده باشن، هیچ تضمینی برای ماندگاری داده‌ها وجود نداره.
✅ در صورت crash، تراکنش های commit شده با WAL قابل بازیابی هستنن.


شماره ۲. Redo / Undo Logs

بخش Redo: مکانیزمی برای بازگرداندن تغییرات تراکنش‌های commit شده پس از crash

بخش Undo: مکانیزمی برای rollback تراکنش‌های ناقص یا aborted

📌 رایج در Oracle و SQL Server و بخش مهمی از Crash Recovery هستش.


شماره ۳. fsync / Force-write

بعده هر COMMIT، داده‌ها از حافظه کش و OS به دیسک واقعی منتقل میشن.
این کار امنیت داده‌ها رو بالا میبره، اما سرعت transaction هارو کمی کاهش میده.


شماره ۴. Replication & Backup

تغییرات میتونن روی سرورهای دیگه کپی بشن یا snapshot گرفته بشن.

📌 این روش‌ها به تنهایی Durability رو تضمین نمیکنن و بیشتر برای Disaster Recovery کاربرد دارن.

Trade-off بین سرعت و ماندگاری (Performance vs Durability)

حالت strict: بعده هر transaction، همه تغییرات حتما روی دیسک نوشته میشن. درین حالت Durability بالاست، اما سرعت transaction ها کمتر خواهد بود.

حالت lazy: تغییرات ممکنه کمی دیرتر روی دیسک نوشته بشن. درین حالت سرعت transaction هابالاتره، اما Durability کمی پایینتر خواهد بود.

📌 مثال در دیتابیس‌ها

PostgreSQL – synchronous_commit:

وقتی این تنظیم فعال باشه، بعده هر transaction، تغییرات حتما روی دیسک نوشته میشن تا Durability تضمین بشه. اگه غیرفعال باشه، transaction سریعتر انجام میشه ولی ممکنه تغییرات کمی دیرتر روی دیسک ذخیره بشن.

MySQL – innodb_flush_log_at_trx_commit:

اگه مقدار این پارامتر روی 1 باشه، بعده هر transaction، تغییرات فورا روی دیسک نوشته میشن (Durability بالا، سرعت کمتر). اگه مقدار روی 2 یا 0 باشه، سرعت بالاتره ولی ممکنه در صورت crash، آخرین transaction ها از دست برن.

#ACID #دیتابیس

@GoldenCodeir 🔥