تئوری های CAP و DCS
دسته : تکنولوژی
نویسنده : علی منصورآبادی
تاریخ : 1401/8/18
سطح : پیشرفته
پست های مرتبط
تئوری های CAP و DCS
تئوری های CAP و DCS را در دیتابیس و بلاک چین بررسی کنیم و به صورت جزئی این دو مورد رو بیان کنیم. قبل از ادامه، بهتون پیشنهاد میدم که حتما "پست های بلاک چین" سایت تیما را مطالعه کنید.
سلام، وقتتون بخیر. علی هستم برنامه نویس تیما. امروز می خواهیم با هم تئوری های CAP و DCS را در دیتابیس و بلاک چین بررسی کنیم و به صورت جزئی این دو مورد رو بیان کنیم. قبل از ادامه، بهتون پیشنهاد میدم که حتما "پست های بلاک چین" سایت تیما را مطالعه کنید.
تئوری CAP، 20 سال پیش توسط Brewer به عنوان یک فرضیه معرفی شد و دو سال بعد، توسط Gilbert و Lynch به عنوان یک مدل شبکه نامتقارن یا asynchronous پذیرفته شد. با تضعیف کردن شرط های ثبات یا Consistency، ثابت شد که می شود هر سه ضلع CAP را بدست آورد که به این مدل، مدل t-Connected Consistency گفته می شد. تئوری CAP سه مشخصه مهم هر سیستم غیرمتمرکز یا توزیع شده را بیان می کند که شامل Consistency یا ثبات، Availability یا در دسترسی بودن و Partition Tolerance یا آستانه قطعی می شود که در ادامه هرکدام را جزئی تر بررسی می کنیم.
· Consistency یا ثبات: هر خواندن یا واکشی یا بازیابی اطلاعات از دیتابیس، آخرین داده های نوشته شده یا در اصل یعنی جدیدترین داده ها را به ما می دهد.
· Availability یا در دسترس بودن: مشتری یا Client در هر نقطه از زمان، پاسخ و نتیجه مورد نظر خودش را دریافت کند.
· Partition Tolerance یا آستانه قطعی: در مواردی که یک قطعی بین نود ها در سیستم های توزیع شده پیش می آید، سیستم همچنان باید به فعالیت خودش ادامه دهد.
در اصل طبق این تئوری، می توانیم دو مورد از این سه ویژگی را همزمان داشته باشیم ولی این عمل که هر سه را همزمان داشته باشیم، امری غیر ممکن است. در عمل، یک سیستم توزیع شده همیشه باید Partition Tolerance داشته باشد، پس فقط می ماند یک انتخاب دیگر بین Consistency و Availability. تئوری CAP تاثیر خودش را در بلاک چین هم دارد. اگر ما Availability را انتخاب کنیم به جای Consistency، داده های بازیابی شده ممکن است به روز نباشند و به این سیستم AP گفته می شود که A از Availability گرفته شده و P از Partition Tolerance. اگر Consistency را انتخاب کنیم، سیستم CP نامیده می شود که C از Consistency و P از Partition Tolerance گرفته شده است و در این صورت، سیستم ممکن است در مواقع قطعی، از دسترس خارج شود و به اجماع یا Consensus لطمه وارد کند. لازم به ذکر است که در سیستم های بلاک چین، هر دو ویژگی لازم هستند. پس بلاک چین همیشه به Consistency یا ثبات قوی احتیاج ندارد. به عنوان مثال در مورد Bitcoin، بزرگترین ذنجیره، ثبات نهایی را برای ما ایفا می کند ولی هنوز هیچ راه حل قطعی برای حل کلی وجود ندارد. شکل پایین نشانگر دیتابیس های مختلف بر اساس تئوری CAP است.
در این شکل نمونه دیتابیس هایی که از جفت ضلع های مشخص شده استفاده می کنند، نشان داده شده است. یک نمونه از تئوری CAP برای بلاک چین ارائه شد که به آن، DCS گفته می شود. DCS برگرفته شده از Decentralization یا غیر متمرکز، Consistency یا ثبات و Scalability یا مقیاس پذیری است. این تئوری می گوید که سیستم بلاک چین، در یک لحظه حداکثر دو مشخصه را می تواند داشته باشد. در ادامه معنای کلی هر مولفه این تئوری را با هم بررسی می کنیم.
· Decentralization یا غیر متمرکز بودن: هیچ موجودیت قابل اعتمادی شبکه را کنترل نمی کند پس هیچ نقطه ای هم برای شکسته شده شبکه نیست. بلاک چین به صورت پیش فرض غیر متمرکز است ولی در مثلث DCS، ما فرض بر غیر متمرکز بودن کامل را داریم یعنی هر نود در شبکه می تواند عضو شود و به عنوان Validator یا نود که اعتبار سنجی می کند، فعالیت کند.
· Consistency یا ثبات: نود های بلاک چین داده ها را در یک زمان باهم می خوانند. کوئری بلاک چین در همه نود های شبکه باید یک جواب مشترک را برگردادند. در بلاک چین، ثبات از الگوریتم های اجماع می آید.
· Scalability یا مقیاس پذیری: عملکرد بلاک چین باید منابع محاسباتی را افزایش دهد. تاخیر باید کم شود و ظرفیت و throughput افزایش پیدا کند.
دقیقا مثل CAP، می توانیم سیستم های DCS را به سه دسته DS، DC و CS تقسیم کنیم. اکثر سیستم های کریپتو مانند بیت کوین از دسته DC هستند. لازم به ذکر است که همه سیستم های بلاک چین Permissioned به صورت تمام غیرمتمرکز نیستند پس از نوع CS هستند. IPFS یا همان Interplanetary File System که برای انتقال و به اشتراک گذاری فایل ها در محیط های توزیع شده به کار می رود، ثباتی را نیاز ندارند چون بخش های مختلف داده ها به صورت توزیع شده در نود های مختلف قرار دارد، پس این سیستم ها از نوع DS هستند. شکل پایین نشانگر سیستم های مختلفی هست که از ضلع های مختلف مثلث DCS استفاده می کنند.
اگر طبق تئوری CAP پیش برویم، حالت های ما به این صورت می شود که در سیستم های DC ما مشکل مقیاس پذیری داریم. برای حل مشکل مقیاس پذیری یا Scalability، تکنیک های زیادی ارائه شده است مثل Sharding. به بیان ساده، شاردینگ یعنی تقسیم یک پردازش بزرگ به پردازشهای کوچک تر، Lightning Networks برای این که معاملات و تراکنش های کوچک، سریعتر و موثرتر انجام شوند و در آخر الگوریتم های اجماع یا Consensus. به همین ترتیب در سیستم های DS، ما ثبات یا Consistency را نداریم که می توانیم توسط استفاده از قرارداد های هوشمند یا Smart Contract های قابل اعتماد، این عمل را تضمین کنیم که در اصل، این امر توسط مدیریت کردن Fork ها و خفه کردن حملات به بلاک چین انجام می شود.
امیدوارم که از این آموزش لذت برده باشید و براتون مفید واقع شده باشه. با ما همراه باشید تا با هم یک درصد بیشتر بدونیم.
پست های مرتبط