سطوح ایزوله دیتابیس و موارد استفاده چیست؟

همانطور که می دانیم، برای حفظ ثبات در یک پایگاه داده، از ویژگی های ACID پیروی می کند. در بین این چهار ویژگی (Atomicity, Consistency, Isolation, and Durability) ایزوله به این معنی است که یک تراکنش باید در یک سیستم به گونه ای انجام شود که تنها تراکنشی باشد که به منابع یک سیستم پایگاه داده دسترسی دارد.

چرا به ایزوله نیاز داریم؟

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

• آیا هنگام خواندن داده‌ها قفل‌می‌شوند و چه نوع قفل‌هایی درخواست می‌شوند.
• قفل های خواندن چه مدت نگه داشته می شوند؟
• این که آیا یک عملیات خواندن که به ردیف‌هایی ارجاع می‌دهد توسط تراکنش دیگری اصلاح شده است، بنابراین تا زمانی که قفل انحصاری روی ردیف آزاد نشود مسدود می‌شود یا نسخه متعهد ردیف را که در زمان شروع بیانیه یا تراکنش وجود داشت، بازیابی می‌کند، به سطوح جداسازی بستگی دارد.

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

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

database isolation chart

Serializalable: این بالاترین سطح ایزوله است. تراکنش های همزمان تضمین شده است که به ترتیب انجام می شوند.
Repeatable Read: داده های خوانده شده در طول تراکنش با شروع تراکنش ثابت می ماند.
Read Committed: اصلاح داده ها فقط پس از انجام تراکنش قابل خواندن است.

Read Uncommitted: اصلاح داده ها را می توان قبل از انجام تراکنش توسط سایر تراکنش ها خواند

دو ستون مخفی برای هر ردیف وجود دارد:transaction_id و roll_pointer.

هنگامی که تراکنش Aشروع می شود، یک Read View جدید باtransaction_id=201 ایجاد می شود. اندکی پس از آن، تراکنش Bشروع می شود، و یک Read View جدید باtransaction_id=202 ایجاد می شود.

اکنون تراکنش Aموجودی را به 200 تغییر می دهد، یک ردیف جدید از گزارش ایجاد می شود و roll_pointer به ردیف قدیمی اشاره می کند. قبل از انجام تراکنش AA، تراکنش Bداده های موجودی را می خواند. تراکنش Bمتوجه می شود کهtransaction_id 201 تعهد نشده است، رکورد متعهد بعدی را می خواند (transaction_id=200).

حتی زمانی که تراکنش Aانجام می شود، تراکنش Bهمچنان داده ها را بر اساس نمای Read ایجاد شده هنگام شروع تراکنش Bمی خواند. بنابراین تراکنش Bهمیشه داده ها را با تعادل=100 می خواند.

به شما: آیا سطوح ایزوله را به اشتباه استفاده کرده اید؟
آیا باعث قطعی جدی شد؟
–