<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های عرفان علی اقدم</title><link>https://virgool.ir/feed/@aliaghdam.erfan</link><description>برنامه نویس و عاشق دنیای کامپیوتر و در نهایت توسعه دهنده حشرات 🪲.</description><language>fa</language><pubDate>2026-11-12 02:38:49</pubDate><image><url>https://files.virgool.ir/upload/users/3222721/avatar/avatar.png</url><title>عرفان علی اقدم</title><link>https://virgool.ir/@aliaghdam.erfan</link></image><item><title>ایزوله سازی پایگاه داده رو عمیق تر درک کنیم .</title><link>https://virgool.ir/@aliaghdam.erfan/ایزوله-سازی-پایگاه-داده-رو-عمیق-تر-درک-کنیم-sbozm0lcpy2h</link><description>همونطور که میدونید پایگاه داده ها برا حفظ استاندارد های مشخص از ACID (خودتون از اینجا بخونین) پیروی میکنن. در راستای همین موضوع برای حفظ یکپارچگی ، سطوح ایزوله سازی پایگاه داده مشخص میکنه میزان حفظ و تمامیت یک تراکنش در مقابل تراکنش های دیگه چقدر باشه . برای درک بهتر این موضوع بهتره که دیدگاه عمیق تری نسبت به  isolation و سطوح مختلفش داشته باشیم .بصورت کلی منشا اهمیت مبحث Database Isolation به چند وضعیت و سناریوی مشخص بر میگرده که بصورت زیر تعریف میشن ( به هر وضعیت یه صفت فاجعه میدم تا بترسین و با تمرکز بالاتری بخونینش ☢️ ): ☠️ فاجعه اول Dirty Read:این وضعیت زمانی رخ میده که یه transaction داده ای که هنوز commit  نشده رو میخونه . برای درک این حالت transaction 1 رو درنظر بگیریم که یک سطر رو update میکنه و transaction 2 اطلاعاتی از همین سطر اپدیت شده رو میخونه در ادامه transaction 1 به دلایلی rollback میشه ، خب فاجعه اینجاست ☢️ !. مشکل اینه که  transaction 2 داده ای رو خونده که اصلا توی database وجود نداره و یا بهتره بگیم قبلا وجود داشته !. ☠️ فاجعه دوم Non-repeatable Read :این حالت زمانی رخ میده که یه transaction داده ی خاصی رو ۲ بار از database بخونه و هر بار با یه مقدار متفاوت روبه رو شه !. برای مثال transaction 1 داده ای رو میخونه و در ادامه transaction 2 عملیات update رو داده ها انجام میده(بستر فاجعه ایجاد شد ☢️). حالا اگه transaction 1 به خوندن دوباره داده ها نیاز داشته باشه ، داده ها تغییر کردن. ☠️ فاجعه سوم Phantom Read :تو این وضعیت چند query یکسان اجرا میشن ولی پاسخ متفاوت دارن . برای مثال transaction 1  در راستای انجام عملیاتی ، کوئری ای رو اجرا میکنه و چند سطر رو برمیگردونه . transaction 2  در پایان عملیاتش چند سطر تولید میکنه که با transaction1  همپوشانی داره ( فاجعه اینجاس ☢️)  و حالا اگه transaction 1 دوباره query مرتبط رو اجرا کنه پاسخی متفاوت دریافت میکنه .براساس سه وضعیتی که معرفی کردیم  سطوح مختلفی از ایزوله سازی  و راه حل هایی برای ایجاد اونا تعریف شده که انواع مختلفی هم دارن . ما تو این مقاله به چند راهکار از دو نوع قفل و غیر قفل اشاره می کنیم تا بعد از این راهکار ها برا پیاده سازی سطوح ایزوله سازی استفاده کنیم  :راه حل اول S-lock (Shared lock)  :تو این نوع قفل اگه transaction 1 داده ای رو قفل کنه transaction 2  فقط میتونه عملیات read رو انجام بده.راه حل دوم X-lock(Exclusive lock)  :در این نوع قفل علاوه بر عملیات write عملیات read هم قفل میشن .راه حل سوم MVCC(Multi-Version Concurrency Control) :این روش قفل نداره و کلا از نوع راهکار های قفلی نیست ! . و شیوه کارش به این شکله که تمامی رکوردها یه  version number دارن، عملیات خوندن به صورت همزمان رو هر رکورد با بالاترین version انجام میشه و عملیات write رو یه کپی از record انجام میشه و تا زمانی که عملیات write تموم نشده کاربرا آخرین ورژن ثبت شده از record رو میبینن ولی به محض اینکه عملیات write انجام بشه version کپی رکورد مربوطه بالاتر میره و عملیات دیگه ای که به read  نیاز دارن آخرین ورژن رو میخونن . با همین روال با هر update ورژن جدیدی اضافه میشه و... .نکته 🗒️ : از معایب MVCC نسبت به قفل ها اینه که به دلیل ورژن های مختلف از رکوردها ، حجم دیتابیس به صورت خودکار افزایش پیدا میکنه( به اصطلاح پف میکنه! 💡) .نکته 🗒️ : در مقایسه با lock ها این روش  Optimization  هم حساب میشه چون تأخیر ناشی از lock  کردن رو حذف میکنه.خب تا اینجا مشکل رو درک کردیم و راهکار های موجود رو توضیح دادیم . پس وقتشه که بریم سراغ ۴ سطح از ایزوله سازی تو دیتابیس و استفاده از راهکار های موجود برا پیاده سازی این سطوح . جدول زیر به صورت خلاصه این ۴ سطح رو نشون میده . تو این جدول سطوح ایزوله سازی از بالا به پایین کاهش پیدا میکنن . برای درک بهتر سطوح رو بصورت خلاصه در ادامه توضیح خواهم داد . خلاصه ای از سطوح ایزوله سازی:Serializable 1️⃣ : این سطح بالاترین سطح از ایزوله سازیه که گارانتی میکنه تراکنش ها sequence وار انجام بشن.  درواقع اسم این روش هم از serial میاد که به معنی زنجیر واره .Repeatable Read 2️⃣ :  عملیات Read رو داده ها در طول هر تراکنش به صورتی هست که در ابتدا خونده میشه .Read Committed 3️⃣ : تغییرات روی داده ها فقط زمانی قابل خوندن میشن که تراکنش مربوطه commit بشه.Read Uncommitted 4️⃣ : قبل از commit شدن هر تغییراتی ، این تغییرات میتونن توسط تراکنش های دیگه خونده بشن.و در اخر باید به این نکته توجه کرد که انتخاب سطح ایزوله سازی به نیازمندی های پروژه بستگی داره و هر چقدر سطح ایزوله سازی بالاتر باشه ، یکپارچگی بیش تر میشه . ولی خب در مقابل باعث ایجاد locktime و بار بیشتر و در نهایت Performance کمتر تو دیتابیس میشه .نوشته ای از : عرفان علی اقدم ✌🏻.</description><category>عرفان علی اقدم</category><author>عرفان علی اقدم</author><pubDate>Sat, 27 Apr 2024 22:51:27 +0330</pubDate></item></channel></rss>