پایگاه های داده ACID – اتمی، سازگاری، جداسازی و دوام توضیح داده شده است
ACID مخفف اتمی، سازگاری، جداسازی و دوام است. اینها چهار ویژگی کلیدی هستند که اکثر سیستم های مدیریت پایگاه داده (DBMS) به عنوان تضمین هنگام مدیریت تراکنش ها ارائه می دهند.
اکثر DBMS های محبوب مانند MySQL ، PostgresSQL و Oracle دارای ضمانت ACID خارج از جعبه هستند. برخی دیگر مانند Redis ، DynamoDB و Cassandra دارای ضمانتهای ACID جزئی هستند. با این حال، به نظر می رسد روند این است که DBMS های بیشتری مطابق با ACID را ارائه می دهند.
توجه به این نکته مهم است که در حالی که بسیاری از DBMS ممکن است بگویند که با ACID سازگار هستند، اجرای این انطباق می تواند متفاوت باشد.
پس ، برای مثال، اگر جداسازی یک ویژگی کلیدی است که برای برنامهای که در حال ساخت آن هستید به آن نیاز دارید، باید بدانید که DBMS انتخابی شما دقیقا چگونه جداسازی را پیادهسازی میکند.
این مقاله با استفاده از قیاسها و مثالهای دنیای واقعی توضیح میدهد که چه معاملاتی هستند، و به تفصیل توضیح میدهند که اتمی، سازگاری، انزوا و دوام چیست.
فهرست مطالب:
تراکنش ها چیست؟
هنگام استفاده از پایگاه داده، بسیاری از چیزها ممکن است اشتباه پیش بروند:
سخت افزار یا نرم افزار پایگاه داده ممکن است از کار بیفتد
برنامه ای که پایگاه داده را فراخوانی می کند می تواند در اواسط عملیات شکست بخورد
شبکه می تواند با ترافیک بیشتری پر شود که می تواند آن را مدیریت کند (آن را غیرقابل اجرا می کند)
چندین مشتری می توانند به طور همزمان نوشته هایی ایجاد کنند که تغییرات دیگری را بازنویسی کند
مشتریان می توانند داده های فانتومی را که نباید در پایگاه داده باشند بخوانند
و به همین ترتیب - این به هیچ وجه فهرستی جامع از چیزهایی نیست که ممکن است اشتباه پیش بروند.
از آنجایی که همه چیز ممکن است به روشهایی بیشتر از آنچه که ما میتوانیم پیشبینی کنیم شکست بخورند، تلاش برای جلوگیری از هر شکست احتمالی میتواند به طور غیرضروری گران و پیچیده شود. در عوض، بهتر است سیستمی طراحی شود که بتواند علیرغم شکست به کار خود ادامه دهد. معاملات این امکان را به ما می دهد.
تراکنشها یک هدف واحد را دنبال میکنند: آنها اطمینان میدهند که یک سیستم تحمل خطا دارد. در صورت بروز نقص در یک سیستم، آیا سیستم می تواند بدون فاجعه کامل به کار خود ادامه دهد؟ با عبارت متفاوت، آیا سیستم می تواند خطاها را تحمل کند؟ پاسخ "بله" به این سوال به این معنی است که چنین سیستمی قابل تحمل خطا است.
پس ، معامله دقیقا چیست؟
معامله یک انتزاع است. این مجموعه ای از عملیات (خواندن و نوشتن) است که به عنوان یک عملیات منطقی واحد در نظر گرفته می شود.
تصور کنید می خواهید یک کتاب واحد را از یک فروشگاه آنلاین بخرید، مثلاً amazon.com. مراحل زیر یک نمای ساده از آنچه باید اتفاق بیفتد را نشان می دهد:
ابتدا کتابی را انتخاب می کنید که آیتم را به سبد شما اضافه می کند.
مقدار موجودی کتاب برای اطمینان از معتبر بودن آن تحلیل میشود (یعنی ارزش موجودی عنوانی که میخرید باید بیشتر از 0 باشد).
روی «خرید» کلیک میکنید، که موجودی آمازون را برای کتاب بهروزرسانی میکند و آن را 1 کاهش میدهد (از آنجایی که یک کتاب میخرید).
همچنین، موجودی حساب بانکی شما برای محاسبه هزینه کتاب به روز می شود.
یک تراکنش تضمین می کند که تمام عملیات مربوط به خرید به عنوان یک عملیات واحد در نظر گرفته می شود. اگر هر بخشی از تراکنش با شکست مواجه شود، کل تراکنش به عقب برگردانده می شود و پایگاه داده در حالتی قرار می گیرد که گویی مشتری هرگز اقدام به خرید نکرده است، پس یکپارچگی داده ها حفظ می شود.
تراکنش زمانی متعهد می شود که تمام عملیات درون تراکنش با موفقیت انجام شود و نتایج آنها به طور دائم ثبت شود. این ماندگاری معمولاً با نوشتن تغییرات در فضای ذخیرهسازی پایگاه داده به دست میآید که میتواند روی دیسک برای پایگاههای داده سنتی یا در حافظه برای پایگاههای داده درون حافظه مانند Redis باشد.
با در نظر گرفتن همه این عملیات های مختلف به عنوان یک عملیات منطقی واحد، پایگاه داده می تواند تضمین هایی را در مورد اینکه چگونه می تواند عیب را تحمل کند، ارائه دهد. این تضمین ها عبارتند از: اتمی بودن ، قوام ، انزوا و دوام .
اتمی به چه معناست؟
اتمی بودن به سادگی به این معنی است که تمام پرس و جوها در یک تراکنش باید موفق شوند تا تراکنش موفق شود. اگر یک کوئری با شکست مواجه شود، کل تراکنش با شکست مواجه می شود.
یک رستوران اتمی
تصور کنید از یک دستگاه سلف سرویس در یک رستوران فست فود استفاده می کنید. معامله در این مورد سفارش غذا است و شامل دو عملیات جداگانه است:
غذا را انتخاب کنید
پرداخت
هر دوی اینها باید موفقیت آمیز باشد تا معامله موفق شود. اگر هر کدام شکست بخورد، تراکنش با شکست مواجه می شود.
همبرگر، سیب زمینی سرخ کرده و نوشیدنی خود را از منوی صفحه لمسی انتخاب می کنید. دستگاه از شما درخواست پرداخت می کند و تنها پس از اینکه پرداخت شما با موفقیت انجام شد، سفارش شما را به آشپزخانه ارسال می کند. لحظاتی بعد، کل سفارش شما آماده است و آن را از پیشخوان تحویل می گیرید.
این یک عملیات اتمی است: تراکنش (سفارش غذا) یا به طور کامل انجام شده است (اگر غذای خود را انتخاب کرده و پرداخت کنید) یا اصلاً انجام نشده است.
شکست هر یک از بخشهای تراکنش به معنای شکست کل تراکنش است. اگر پرداخت شما ناموفق باشد، دستگاه هیچ بخشی از سفارش را پردازش نمی کند، پس تراکنش با شکست مواجه می شود. اگر بدون انتخاب ماده غذایی پرداختی انجام دهید، معامله نیز با شکست مواجه می شود، زیرا چیزی برای آشپزخانه وجود ندارد.
یک رستوران غیر اتمی
حالا گزینه جایگزین را در نظر بگیرید، یک رستوران سنتی نشسته که در آن چندین غذا سفارش می دهید. همانطور که هر غذا آماده می شود، آن را به میز شما می آورند.
باز هم، معامله سفارش غذا است و شامل دو عملیات جداگانه است:
غذا را انتخاب کنید
پرداخت
در این رستوران غیر اتمی، عدم پرداخت باعث نمیشود که تراکنش کامل نشود، زیرا شما پس از اتمام وعده غذایی خود پرداخت میکنید. شکست جزئی باعث شکست تراکنش نمی شود.
این برای رستوران خطر ایجاد می کند. مشتریانی که غذا خوردن و غذا خوردن را انتخاب میکنند، میتوانند غذا را به دلخوشی خود سفارش دهند و سپس بدون پرداخت هزینه آن را ترک کنند و باعث ضرر مالی برای رستوران شود.
معاملات اتمی
اگر چندین کوئری SQL در یک تراکنش با هم گروه بندی شوند، اتمی بودن تضمینی است که اگر هر یک از پرس و جوها به هر دلیلی (مشکلات سخت افزاری، برنامه کاربردی یا شبکه) با شکست مواجه شوند، تراکنش لغو می شود و پایگاه داده به حالت قبلی خود باز می گردد. هیچ اتفاقی نیفتاده بود
بدون اتمی، اگر هنگام اجرای برخی از پرسوجوها، شکستی رخ دهد، تشخیص اینکه کدام پرسوجوها متعهد شدهاند (یعنی تکمیل شده) دشوار است. اجرای مجدد پرس و جوها پس از شکست می تواند مشکل را تشدید کند، زیرا با اجرای مجدد پرس و جوهایی که قبلاً موفق بوده اند، خطر معرفی داده های نادرست به پایگاه داده را دارید.
تراکنشهای اتمی از چنین عدم قطعیتی جلوگیری میکنند، زیرا میدانید که اگر تراکنش قبلی ناموفق بود، در کل شکست خورده است، و میتوانید بدون نگرانی در مورد معرفی دادههای متناقض، دوباره امتحان کنید.
سازگاری به چه معناست؟
سازگاری می تواند در مهندسی ابر/نرم افزار، بسته به زمینه، معانی مختلفی داشته باشد. در مورد ACID، "C" به احتمال زیاد برای کارکرد مخفف اضافه شده است.
سازگاری در زمینه ACID به معنای سازگاری در داده ها است که توسط سازنده پایگاه داده تعریف می شود. اصطلاح فنی برای سازگاری در داده ها یکپارچگی ارجاعی نامیده می شود. یکپارچگی ارجاعی روشی برای اطمینان از ثابت ماندن روابط بین جداول است. معمولاً از طریق استفاده از کلیدهای خارجی اعمال می شود.
برای درک یکپارچگی ارجاعی، موارد زیر را در نظر بگیرید.
سیستم کتابخانه ای را با دو نوع کارت تصور کنید: کارت کتاب و کارت وام گیرنده.
کارت کتاب تمام کتابهای موجود در کتابخانه را فهرست میکند.
کارت وام گیرنده ردیابی می کند که کدام کتاب توسط کدام اعضا قرض گرفته شده است.
قانون کتابخانه این است که کتاب فقط در صورتی می تواند در کارت امانت گیرنده درج شود که در کارت کتاب وجود داشته باشد. این یکپارچگی ارجاعی است. اگر کسی سعی کند کتابی را در کارت وام گیرنده فهرست کند که در کارت کتاب نیست (این کتابی است که در کتابخانه وجود ندارد)، سیستم اجازه نمی دهد.
در حالی که اتمی، ایزوله و دوام خصوصیات ذاتی خود پایگاه داده هستند، سازگاری در داده ها، یا یکپارچگی ارجاعی، ویژگی ذاتی پایگاه داده نیست.
سازگاری توسط سازنده پایگاه داده تعریف می شود. برنامه ای که پایگاه داده را فراخوانی می کند، برای حفظ آن سازگاری، بر ویژگی های اتمی و جداسازی پایگاه داده تکیه دارد.
انزوا به چه معناست؟
جداسازی تضمینی است که تراکنشهای در حال اجرا همزمان نباید با یکدیگر تداخل داشته باشند. همزمانی در اینجا به دو یا چند تراکنش اطلاق میشود که سعی میکنند یک رکورد(های) پایگاه داده را به طور همزمان تغییر دهند یا بخوانند.
سه سطح جداسازی معاملات وجود دارد. من فقط دو مورد اصلی را در زیر توضیح میدهم که به ترتیب از سختگیرانهترین تا سختگیرترین مرتب شدهاند.
متعهد را بخوانید
این دو ضمانت می دهد. از خواندن کثیف و نوشتن کثیف جلوگیری می کند.
بدون کثیف خواندن : خواندن داده های تراکنش دیگری که هنوز انجام نشده است، خواندن کثیف نامیده می شود. با سطح جداسازی تعهد خوانده شده، شما فقط داده هایی را خواهید دید که توسط تراکنش دیگری متعهد شده اند.
بدون کثیف نوشتن : رونویسی دادههایی که قبلاً توسط تراکنش دیگری نوشته شدهاند اما هنوز انجام نشدهاند، نوشتن کثیف نامیده میشود.
برای درک نحوه عملکرد جداسازی متعهد خواندن، به مثال زیر توجه کنید.
یک رستوران فست فودی را تصور کنید که تنها آخرین برگر ویژه در آن موجود است و دو مشتری گرسنه، ماری و مارکو، سعی در خرید همزمان آن دارند.
ماری در دسترس بودن همبرگرها را تحلیل می کند و آخرین موجود را می بیند. سفارش مارکو ناشناخته در حال پردازش است اما به دلیل پرداخت نکردن او در سیستم نهایی نشده است. از آنجایی که دستور او هنوز نهایی نشده است، ماری نمی داند که دستور او با دستور او در تضاد است. این شبیه به تراکنشی است که آخرین دادههای تعهد شده را میخواند، جایی که تغییرات غیرمتعهد (مانند دستور معلق مارکو) را نمیبیند.
ماری بر اساس این اطلاعات ناقص سفارش می دهد و فکر می کند همبرگر در دسترس است.
هنگامی که مارکو پرداخت می کند، سیستم به روز می شود تا نشان دهد که برگری باقی نمانده است. این شبیه به معامله ای است که انجام می شود
دستور ماری باید لغو شود زیرا دیگر برگری باقی نمانده است.
نکته کلیدی در اینجا مرحله شماره 3 است. اگر پرداخت مارکو در این مرحله انجام نشد چه؟ سپس معامله انجام نخواهد شد و هنوز همبرگر برای ماری در دسترس خواهد بود.
در این مثال، خواندن انزوای متعهد تضمین میکند که ماری پیش از موعد از خرید همبرگر محروم نمیشود، فقط به این دلیل که شخص دیگری گفته است که آن را میخواهد. فقط تراکنش های تعهد شده قابل خواندن هستند. پس ، تا زمانی که کسی هزینه آن را پرداخت نکرده باشد، برگر قابل سفارش است.
خواندن تکراری
خواندن تکرارشونده یک سطح جداسازی دقیقتر است، از این نظر که تضمینهای مشابه با جداسازی متعهد خواندن دارد - به علاوه تضمین میکند که خواندنها تکرارپذیر هستند.
خواندن تکرارپذیر تضمین می کند که اگر یک تراکنش یک ردیف از داده ها را بخواند، هر خواندن بعدی از همان ردیف داده در همان تراکنش، بدون توجه به تغییرات ایجاد شده توسط سایر تراکنش ها، همان نتیجه را به همراه خواهد داشت. این ثبات در طول مدت معامله حفظ می شود.
هنگامی که یک تراکنش یک داده را دو بار می خواند، اما در هر خواندن مقدار متفاوتی می بیند، زیرا یک تراکنش متعهد، مقدار بین دو خوانده شده را به روز کرده است، به آن خواندن فازی می گویند. سطح جداسازی خواندن قابل تکرار از خواندن فازی جلوگیری می کند.
خواندن فازی نه ذاتا خوب است و نه بد. همه چیز بستگی به این دارد که شما در حال تلاش برای رسیدن به آن هستید.
خواندن فازی برای تراکنشهای طولانیمدت و فقط خواندنی بد است، زیرا احتمالاً نوشتنهای جدید در طول تراکنش رخ میدهد و این میتواند باعث ناهماهنگی در دادهها شود. نمونههایی از تراکنشهای طولانیمدت و فقط خواندنی، پشتیبانگیری از پایگاه داده و پرس و جوهای تحلیلی است که معمولاً در انبار داده استفاده میشود.
خواندن های تکرار شونده معمولاً توسط DBMS با خواندن یک عکس فوری از پایگاه داده که در طول مدت تراکنش بدون تغییر باقی می ماند، پیاده سازی می شود و در نتیجه هرگونه نوشته جدید متعهد در آن دوره نادیده گرفته می شود.
دوام به چه معناست؟
دوام تضمینی است که تغییرات ایجاد شده توسط یک تراکنش متعهد نباید از بین برود. همه تراکنشهای متعهد باید روی ذخیرهسازی بادوام و غیرفرار، یعنی روی دیسک، ادامه داشته باشند. این تضمین می کند که هرگونه تراکنش متعهد محافظت می شود حتی اگر پایگاه داده خراب شود.
به طور طبیعی، دوام نمی تواند در برابر تخریب دیسکی که داده ها را ذخیره می کند محافظت کند. افزونگی اضافی را می توان با ذخیره کردن نسخه پشتیبان از پایگاه داده شما جدا از نسخه اصلی اضافه کرد.
آوردن آن با هم
ACID (اتمیسیته، سازگاری، جداسازی و دوام) مجموعه ای از تضمین ها را هنگام کار با DBMS ارائه می دهد. در حالی که اکثر DBMS های رابطه ای با ACID سازگار هستند، اجرای این انطباق می تواند متفاوت باشد.
اتمیسیتی تضمین میکند که تمام بخشهای یک تراکنش کامل شده یا اصلاً هیچکدام از آنها انجام نشده است. شکست جزئی مجاز نیست.
سازگاری یا یکپارچگی ارجاعی تضمین می کند که داده ها دقیق و قابل اعتماد باقی می مانند و قوانین از پیش تعریف شده را رعایت می کنند. برخلاف سایر اولویتها، سازگاری ذاتی خود DBMS نیست. در عوض، برنامه ای که پایگاه داده را فراخوانی می کند، برای حفظ ثبات، بر ویژگی های اتمی و جداسازی پایگاه داده تکیه دارد.
جداسازی تضمینی است که تراکنشهای در حال اجرا همزمان نباید با یکدیگر تداخل داشته باشند. مسلماً این مهمترین ویژگی است زیرا یک DBMS اغلب میتواند سطوح جداسازی پیشفرض متفاوتی داشته باشد که ممکن است بر اساس آنچه برای برنامه شما نیاز است نیاز به تغییر داشته باشد.
در نهایت، دوام تضمینی است که تغییرات ایجاد شده توسط یک معامله متعهد نباید از بین برود.
ارسال نظر