CodeCrafters

در ادامه کتاب «طراحی برنامه‌های داده محور» در بخش race conditions کتاب یک الگوی دیگری برای رفع شرایط مسابقه رو هم بررسی میکنه (two-phace locking) یا به اختصار 2PL که البته این رویکرد منسوخ شده اما منتها جهت درک بهتره دو سطح serializable در snapshot کمک کننده هستش

2PL
رویکرد با قفل کردن در دیتابیس عمل میکنه، این الگو بشدت بدبین هستش و هر وقت صورت بگیره دوتا قفل انجام میده بک قفل اشتراکی برای خوندن و بک قفل انحصاری برای نوشتن و تراکنش‌ها رو در صف انتظار قرار میده تا زمانیکه قفل باز بشه (در صورت نیاز کل دیتابیس رو یکجا و به یک صورت قفل میکنه)، موجب کندی و تاخیر شدید در پاسخ به کوئری‌ها میشه و دیتابیس رو از هرگونه عملی محروم میکنه تا کوئری فعال کننده قفل تموم بشه و دیتابیس رو آزاد کنه، تصور کنید که select for update رو روی کل موجودیت دیتابیس اجرا کردید، اما تمام شرایط مسابقه رو هندل میکنه کامل (phamtom read, lost update, write skew, dirty data)، این رویکرد هم کوئری‌ها رو بصورت سریالی انجام میده (انگار که چند کوئری بزرگ و طولانی پشت سرهم اجرا شدن)


snapshot isolation
در رویکرد سطح ایزوله با repeatable read و فعال کردن اون (در اجرای هر کوئری یه تصویر ثابت در ابتدا به کوئری میدیم) ما مشکل phamtom read رو بر طرف میکنیم منتها با مشکل write skew روبرو بودیم، اگه در بدنه atomic بیایم از select for update استفاده کنیم مشکل write skew برطرف میشه منتها مشکل اساسی تر این هستش که تعارض رو فقط برای ردیف اعلام شده بر روی اون انجام میده نه کل دیتابیس و تداخل داده در ردیف‌هایی که قفل روی اون‌ها صورت نگرفته شکل میگیره و write skew همچنان پابرجا هستش

serializable snapshot isolation
یا به اختصار SSI بهش میگیم، رویکرد خوشبینانه در برخورد با اتفاقات داره، دیتابیس رو قفل نمیکنه بلکه یک تصویر ثابت به کوئری میده و مابقی کوئری‌های دیگه اگه خوندن باشن رو باز میزاره جهت اجرا و کوئری‌های نوشتن رو چک میکنه با روش (conflict detection) اگه تداخل باشه لغو و roll back میزنه و در غیر این صورت اجرا میشه، کوئری‌ها رو به شکل سریالی اجرا میکنه و هیچ قفلی روی دیتابیس نمیزاره تو حالت partitioning به خوبی کار میکنه و مناسب کوئری‌های سبک و پرفورمنس عالی برای اونها داره (پرفورمنس بشدت وابسته به رفتار مهندسی نرم افزار در پروژه می باشد) جالبه که در برخورد با conflict detection سخت برخورد نمیکنه (با استفاده از MVCC در پستگرس) تراکنش‌هارو در حد نیاز و کم بررسی میکنه و این عامل پرفورمنس داخلش هستش


یه نکته جالب هم بگم سریالی برخورد کردن با داده خودش یه مفهوم بزرگی هستش که کمک میکنه تا داده رو در یک ترد و یک پردازنده عملیات روش انجا بدیم ایده اصلی redis از این مفهوم و برپایه اون استوار هستش

@code_crafters

❤7

www.tgoop.com/Code_Crafters/899

585 viewsBehzad Azadi, edited  Jun 27 at 08:31

در ادامه کتاب «طراحی برنامه‌های داده محور» در بخش race conditions کتاب یک الگوی دیگری برای رفع شرایط مسابقه رو هم بررسی میکنه (two-phace locking) یا به اختصار 2PL که البته این رویکرد منسوخ شده اما منتها جهت درک بهتره دو سطح serializable در snapshot کمک کننده هستش

2PL
رویکرد با قفل کردن در دیتابیس عمل میکنه، این الگو بشدت بدبین هستش و هر وقت صورت بگیره دوتا قفل انجام میده بک قفل اشتراکی برای خوندن و بک قفل انحصاری برای نوشتن و تراکنش‌ها رو در صف انتظار قرار میده تا زمانیکه قفل باز بشه (در صورت نیاز کل دیتابیس رو یکجا و به یک صورت قفل میکنه)، موجب کندی و تاخیر شدید در پاسخ به کوئری‌ها میشه و دیتابیس رو از هرگونه عملی محروم میکنه تا کوئری فعال کننده قفل تموم بشه و دیتابیس رو آزاد کنه، تصور کنید که select for update رو روی کل موجودیت دیتابیس اجرا کردید، اما تمام شرایط مسابقه رو هندل میکنه کامل (phamtom read, lost update, write skew, dirty data)، این رویکرد هم کوئری‌ها رو بصورت سریالی انجام میده (انگار که چند کوئری بزرگ و طولانی پشت سرهم اجرا شدن)


snapshot isolation
در رویکرد سطح ایزوله با repeatable read و فعال کردن اون (در اجرای هر کوئری یه تصویر ثابت در ابتدا به کوئری میدیم) ما مشکل phamtom read رو بر طرف میکنیم منتها با مشکل write skew روبرو بودیم، اگه در بدنه atomic بیایم از select for update استفاده کنیم مشکل write skew برطرف میشه منتها مشکل اساسی تر این هستش که تعارض رو فقط برای ردیف اعلام شده بر روی اون انجام میده نه کل دیتابیس و تداخل داده در ردیف‌هایی که قفل روی اون‌ها صورت نگرفته شکل میگیره و write skew همچنان پابرجا هستش

serializable snapshot isolation
یا به اختصار SSI بهش میگیم، رویکرد خوشبینانه در برخورد با اتفاقات داره، دیتابیس رو قفل نمیکنه بلکه یک تصویر ثابت به کوئری میده و مابقی کوئری‌های دیگه اگه خوندن باشن رو باز میزاره جهت اجرا و کوئری‌های نوشتن رو چک میکنه با روش (conflict detection) اگه تداخل باشه لغو و roll back میزنه و در غیر این صورت اجرا میشه، کوئری‌ها رو به شکل سریالی اجرا میکنه و هیچ قفلی روی دیتابیس نمیزاره تو حالت partitioning به خوبی کار میکنه و مناسب کوئری‌های سبک و پرفورمنس عالی برای اونها داره (پرفورمنس بشدت وابسته به رفتار مهندسی نرم افزار در پروژه می باشد) جالبه که در برخورد با conflict detection سخت برخورد نمیکنه (با استفاده از MVCC در پستگرس) تراکنش‌هارو در حد نیاز و کم بررسی میکنه و این عامل پرفورمنس داخلش هستش


یه نکته جالب هم بگم سریالی برخورد کردن با داده خودش یه مفهوم بزرگی هستش که کمک میکنه تا داده رو در یک ترد و یک پردازنده عملیات روش انجا بدیم ایده اصلی redis از این مفهوم و برپایه اون استوار هستش

@code_crafters

BY CodeCrafters