سلام به همه. ولادیسلاو رودن در تماس است. من در حال حاضر مدیر دوره برای دوره High Workload Architect در OTUS هستم و همچنین دوره های معماری نرم افزار را تدریس می کنم.
علاوه بر تدریس، همانطور که متوجه شده اید، من در حال نوشتن مطالب اصلی برای وبلاگ OTUS در Habré هستم و می خواهم با مقاله امروز همزمان با شروع دوره باشد.
معرفی
В
عایق
جداسازی مشکل دسترسی به داده ها را در یک محیط رقابتی حل می کند و اساساً محافظت در برابر شرایط مسابقه را فراهم می کند. در حالت ایدهآل، ایزوله به معنای سریالسازی است، که ویژگیای است که تضمین میکند که نتیجه اجرای تراکنشها به صورت موازی همان است که به صورت متوالی انجام شدهاند. مشکل اصلی این ویژگی این است که ارائه آن از نظر فنی بسیار دشوار است و در نتیجه تأثیر قابل توجهی بر عملکرد سیستم دارد. به همین دلیل است که انزوا اغلب تضعیف می شود و خطرات ناهنجاری های خاص را می پذیرد که در زیر مورد بحث قرار خواهد گرفت. امکان وقوع ناهنجاری های خاص دقیقاً سطح جداسازی تراکنش را مشخص می کند.
شناخته شده ترین ناهنجاری ها عبارتند از: خواندن کثیف، خواندن غیرقابل تکرار، خواندن فانتوم، اما در واقع 5 مورد دیگر وجود دارد: نوشتن کثیف، به روز رسانی مکان نما، به روز رسانی از دست رفته، خواندن چولگی، نوشتن کج.
کثیف بنویس
ماهیت ناهنجاری این است که تراکنش ها می توانند داده های غیرمتعهد را بازنویسی کنند.
این ناهنجاری نه تنها به این دلیل خطرناک است که دادهها پس از انجام هر دو تراکنش (مانند تصویر) میتوانند با هم تضاد داشته باشند، بلکه به این دلیل که اتمی نقض شده است: از آنجایی که ما اجازه میدهیم دادههای غیرمتعهد بازنویسی شوند، روشن نیست که چگونه یک تراکنش را بدون تأثیرگذاری بر دیگری برگردانیم. .
این ناهنجاری را می توان به سادگی درمان کرد: قبل از شروع ضبط، یک قفل را به رکورد متصل می کنیم و تا زمانی که قفل حذف نشود، دیگر تراکنش ها را از تغییر رکورد منع می کنیم.
کثیف خوانده شود
کثیف خواندن به معنای خواندن داده های غیرمتعهد است.
مشکلات زمانی به وجود می آیند که باید اقدامات یا تصمیماتی بر اساس نمونه گرفته شود.
برای اصلاح ناهنجاری، میتوانید قفل خواندن را وصل کنید، اما این کار تأثیر زیادی بر عملکرد خواهد داشت. بسیار ساده تر است که بگوییم برای تراکنش برگشتی، وضعیت اولیه داده ها (قبل از شروع ضبط) باید در سیستم ذخیره شود. چرا از اونجا نمیخونی؟ به اندازه کافی ارزان است که اکثر پایگاه های داده به طور پیش فرض خواندن کثیف را حذف می کنند.
به روز رسانی گم شده است
به روز رسانی گم شده به معنای به روز رسانی های از دست رفته است، و ترجمه کاملاً دقیقاً ماهیت مشکل را منعکس می کند:
در واقع، نتیجه تراکنش T2 معکوس شد. این وضعیت را می توان با قفل نوشتن صریح یا ضمنی اصلاح کرد. یعنی یا به سادگی رکورد را به روز می کنیم و سپس یک قفل ضمنی رخ می دهد یا انجام می دهیم را برای به روز رسانی انتخاب کنید، باعث ایجاد قفل خواندن و نوشتن می شود. لطفاً توجه داشته باشید که چنین عملیاتی کاملاً خطرناک است: با خواندن "معصوم" خود ، ما قرائت های دیگر را مسدود می کنیم. برخی از پایگاه های داده ایمن تر ارائه می دهند برای اشتراک گذاری انتخاب کنید، اجازه خواندن داده ها را می دهد اما تغییر نمی دهند.
مکان نما به روز رسانی را از دست داد
برای کنترل دقیق تر، پایه ها ممکن است ابزارهای دیگری مانند مکان نما را ارائه دهند. مکان نما ساختاری است که شامل مجموعه ای از ردیف ها است و به شما امکان می دهد روی آنها تکرار کنید. cursor_name را برای select_statement اعلام کنید. محتویات مکان نما با انتخاب توضیح داده می شود.
چرا به مکان نما نیاز دارید؟ واقعیت این است که برخی از پایگاه های داده یک قفل را در تمام رکوردهای انتخاب شده با انتخاب (پایداری خواندن) یا فقط روی رکوردی که مکان نما در حال حاضر روی آن قرار دارد (پایداری مکان نما) ارائه می دهند. با ثبات مکان نما، قفل کوتاه اجرا می شود، که به ما امکان می دهد در صورت تکرار روی نمونه بزرگی از داده، تعداد قفل ها را کاهش دهیم. بنابراین، ناهنجاری به روز رسانی گم شده به طور جداگانه برای مکان نما جدا می شود.
خواندن غیر قابل تکرار
خواندن غیرقابل تکرار این است که در طول اجرای تراکنش ما، 2 خواندن متوالی یک رکورد منجر به نتایج متفاوتی می شود، زیرا تراکنش دیگری بین این دو خواندن دخالت کرده، داده های ما را تغییر داده و متعهد شده است.
چرا این حتی یک مشکل است؟ تصور کنید که هدف از تراکنش T2 در تصویر انتخاب همه کالاهایی است که قیمت آنها کمتر از 150 تومان است. شخص دیگری قیمت را به 200 دلار به روز کرد. بنابراین، فیلتر نصب شده کار نمی کند.
این ناهنجاریها با اضافه شدن اینترلاکهای دوفاز یا زمانی که مکانیسم MVCC استفاده میشود، رخ نمیدهند، که میخواهم به طور جداگانه در مورد آن صحبت کنم.
فانتوم خواند
فانتوم خواندن داده هایی است که توسط تراکنش دیگری اضافه شده است.
به عنوان مثال می توان انتخاب نادرست ارزان ترین محصول را در هنگام بروز این ناهنجاری مشاهده کرد.
خلاص شدن از خواندن فانتوم در حال حاضر بسیار دشوار است. مسدود کردن منظم کافی نیست، زیرا ما نمی توانیم چیزی را که هنوز وجود ندارد مسدود کنیم. سیستمهای 2PL از قفل پیشبینی استفاده میکنند، در حالی که سیستمهای MVCC دارای یک زمانبندی تراکنش هستند که تراکنشهایی را که ممکن است توسط یک درج مختل شوند، برمیگرداند. هر دو مکانیسم اول و دوم بسیار سنگین هستند.
کج را بخوانید
چولگی خواندن زمانی اتفاق میافتد که با چندین جدول کار میکنیم که محتوای آنها باید به طور مداوم تغییر کند.
فرض کنید جداولی داریم که پست ها و اطلاعات متا آنها را نشان می دهد:
یک تراکنش از جداول خوانده می شود، دیگری آنها را اصلاح می کند:
در نتیجه تراکنش T1، پست دارای عنوان = خوب و updated_by = T2 است که نوعی ناسازگاری است.
در واقع، این یک خواندن غیرقابل تکرار است، اما به عنوان بخشی از چندین جدول است.
برای رفع این مشکل، T1 میتواند روی تمام ردیفهایی که میخواند قفل بگذارد که از تغییر اطلاعات تراکنش T2 جلوگیری میکند. در صورت MVCC، تراکنش T2 لغو خواهد شد. اگر از مکان نما استفاده کنیم، محافظت در برابر این ناهنجاری می تواند مهم شود.
کج بنویس
توضیح این ناهنجاری با یک مثال ساده تر است: فرض کنید در سیستم ما حداقل یک پزشک باید در حال انجام وظیفه باشد، اما هر دو پزشک تصمیم به لغو وظیفه خود گرفتند:
این ناهنجاری به این معنی بود که هیچ یک از پزشکان در حال انجام وظیفه نیستند. چرا این اتفاق افتاد؟ زیرا تراکنش در حال بررسی شرایطی بود که امکان نقض آن توسط تراکنش دیگری وجود داشت و به دلیل ایزوله بودن، این تغییر را مشاهده نکردیم.
این همان خواندن غیرقابل تکرار است. از طرف دیگر، انتخابها میتوانند قفلهایی را روی این رکوردها قرار دهند.
چولگی بنویسید و کج خواندن ترکیبی از ناهنجاری های قبلی است. شما می توانید نوشتن کج را در نظر بگیرید، که در اصل یک خواندن فانتوم است. جدولی را در نظر بگیرید که شامل نام کارمندان، حقوق آنها و پروژه ای است که روی آن کار می کنند:
در نتیجه، تصویر زیر را به دست میآوریم: هر مدیر فکر میکرد که تغییر آنها منجر به افزایش بودجه نمیشود، بنابراین آنها تغییرات پرسنلی را انجام دادند که در مجموع منجر به افزایش هزینهها شد.
علت مشکل دقیقاً مانند فانتوم خوانی است.
یافته ها
آرام کردن سطح جداسازی تراکنش در پایگاه داده یک مبادله بین امنیت و عملکرد است؛ انتخاب این سطح باید بر اساس خطرات احتمالی برای کسب و کار در صورت بروز ناهنجاریهای خاص مورد بررسی قرار گیرد.
منبع: www.habr.com