راه حل هایی برای تنظیم حد از دست دادن

قضیه CAP معتقد است که یک سیستم توزیع شده می تواند تنها دو سه ویژگی مورد نظر را ارائه دهد: ثبات ، در دسترس بودن و تحمل پارتیشن.

قضیه کلاه چیست؟

آیا تا به حال تبلیغاتی را برای یک منظره ، نقاش خانه یا برخی از تجار دیگر دیده اید که با تیتر "ارزان ، سریع و خوب: دو انتخاب کنید" شروع می شود؟

قضیه CAP نوع مشابهی از منطق را در سیستم های توزیع شده اعمال می کند - یعنی اینکه یک سیستم توزیع شده می تواند تنها دو سه ویژگی مورد نظر را ارائه دهد: ثبات ، در دسترس بودن و تحمل پارتیشن ("C ،" A "و" P "در CAP).

یک سیستم توزیع شده شبکه ای است که همزمان داده ها را در بیش از یک گره (ماشین های فیزیکی یا مجازی) ذخیره می کند. از آنجا که همه برنامه های کاربردی ابری سیستم های توزیع شده هستند ، درک قضیه CAP هنگام طراحی یک برنامه ابری ضروری است تا بتوانید یک سیستم مدیریت داده را انتخاب کنید که ویژگی های برنامه شما را به بیشترین نیاز داشته باشد.

قضیه کلاه نیز قضیه Brewer نامیده می شود ، زیرا برای اولین بار توسط استاد اریک A. Brewer در طی سخنرانی که در سال 2000 در محاسبات توزیع شده ارائه شد ، پیش بینی شد. دو سال بعد ، اساتید MIT ست گیلبرت و نانسی لینچ اثبات "حدس آبجو را منتشر کردند."

اطلاعات بیشتر در مورد "کلاه" در قضیه کلاه

بیایید نگاهی دقیق به سه ویژگی سیستم توزیع شده که قضیه CAP به آن اشاره می کند ، نگاهی بیندازیم.

ثبات

قوام بدان معنی است که همه مشتری ها داده های یکسان را همزمان می بینند ، مهم نیست که به کدام گره وصل شوند. برای این اتفاق ، هر زمان که داده ها به یک گره نوشته شود ، باید فوراً ارسال شود یا به تمام گره های دیگر سیستم قبل از نوشتن "موفقیت آمیز" تلقی شود.

دسترسی

در دسترس بودن به این معنی است که هر مشتری که درخواست داده را ایجاد کند ، حتی اگر یک یا چند گره پایین باشد ، پاسخ می دهد. راه دیگر برای بیان این موضوع - همه گره های کار در سیستم توزیع شده ، بدون استثنا ، پاسخ معتبری را برای هر درخواست باز می گردانند.

تحمل پارتیشن

یک پارتیشن یک شکست ارتباطی در یک سیستم توزیع شده است - یک ارتباط گمشده یا به طور موقت بین دو گره. تحمل پارتیشن به این معنی است که خوشه باید با وجود هر تعداد از ارتباطات ارتباطی بین گره های موجود در سیستم ، به کار خود ادامه دهد.

انواع پایگاه داده NOSQL CAP CAP

پایگاه داده های NOSQL برای برنامه های شبکه توزیع شده ایده آل هستند. بر خلاف همتایان SQL (رابطه ای) عمودی آنها ، پایگاه داده های NOSQL به صورت افقی مقیاس پذیر هستند و با طراحی توزیع می شوند - آنها می توانند به سرعت در یک شبکه در حال رشد متشکل از گره های بهم پیوسته مقیاس مقیاس بندی کنند.(برای اطلاعات بیشتر به "SQL در مقابل NOSQL پایگاه داده ها: تفاوت؟"

امروزه ، پایگاه داده های NOSQL بر اساس دو ویژگی درپوش که از آنها پشتیبانی می کنند طبقه بندی می شوند:

• بانک اطلاعاتی CP: یک پایگاه داده CP با هزینه در دسترس بودن ، ثبات و تحمل پارتیشن را ارائه می دهد. هنگامی که یک پارتیشن بین هر دو گره رخ می دهد ، سیستم باید تا زمان برطرف شدن پارتیشن ، گره غیر سازگار را خاموش کند (یعنی آن را در دسترس نیست).

   

ما به دلایلی نوع پایگاه داده CA را ذکر کردیم - به یک دلیل - در یک سیستم توزیع شده ، از پارتیشن ها نمی توان جلوگیری کرد. بنابراین ، در حالی که ما می توانیم از یک پایگاه داده توزیع شده CA در تئوری بحث کنیم ، برای همه اهداف عملی یک پایگاه داده توزیع شده CA نمی تواند وجود داشته باشد. این بدان معنا نیست که در صورت نیاز به یک پایگاه داده CA برای برنامه توزیع شده خود نمی توانید داشته باشید. بسیاری از بانکهای اطلاعاتی رابطه ای ، مانند PostgreSQL ، سازگاری و در دسترس بودن را ارائه می دهند و با استفاده از تکثیر می توانند به چندین گره مستقر شوند.

MongoDB و قضیه کلاه

MongoDB یک سیستم مدیریت محبوب پایگاه داده NOSQL است که داده ها را به عنوان اسناد BSON (باینری JSON) ذخیره می کند. این اغلب برای داده های بزرگ و برنامه های زمان واقعی در چندین مکان مختلف که در حال اجرا هستند استفاده می شود. نسبت به قضیه CAP ، MongoDB یک فروشگاه داده CP است - با حفظ قوام ، پارتیشن های شبکه را برطرف می کند ، در حالی که در دسترس بودن به خطر می افتد.

MongoDB یک سیستم تک رشته ای است-هر مجموعه ماکت (پیوند در خارج از IBM. com) می تواند فقط یک گره اصلی داشته باشد که تمام عملیات نوشتن را دریافت می کند. تمام گره های دیگر در همان مجموعه ماکت گره های ثانویه هستند که ورود به سیستم عملکرد گره اصلی را تکرار می کنند و آن را در مجموعه داده های خودشان اعمال می کنند. به طور پیش فرض ، مشتریان همچنین از گره اولیه می خوانند ، اما می توانند ترجیح خوانده شده را نیز مشخص کنند (پیوند در خارج از IBM. com) که به آنها اجازه می دهد از گره های ثانویه بخوانند.

هنگامی که گره اولیه در دسترس نیست ، گره ثانویه با جدیدترین ورود به سیستم به عنوان گره اولیه جدید انتخاب می شود. هنگامی که همه گره های ثانویه دیگر با استاد جدید روبرو شدند ، خوشه دوباره در دسترس قرار می گیرد. از آنجا که مشتری ها نمی توانند در این بازه ، درخواست های نوشتن را ارائه دهند ، داده ها در کل شبکه سازگار است.

کاساندرا و قضیه کلاه (AP)

Apache Cassandra یک پایگاه داده منبع باز NOSQL است که توسط بنیاد نرم افزار Apache نگهداری می شود. این یک پایگاه داده با ستون گسترده است که به شما امکان می دهد داده ها را در یک شبکه توزیع شده ذخیره کنید. با این حال ، بر خلاف MongoDB ، کاساندرا یک معماری بدون استاد دارد و در نتیجه ، دارای چندین نقطه شکست است نه یک واحد.

نسبت به قضیه CAP ، Cassandra یک پایگاه داده AP است - در دسترس بودن و تحمل پارتیشن است اما نمی تواند همواره قوام را ارائه دهد. از آنجا که کاساندرا گره اصلی ندارد ، تمام گره ها باید به طور مداوم در دسترس باشند. با این حال ، کاساندرا با اجازه دادن به مشتریان برای نوشتن هر گره در هر زمان و آشتی دادن ناسازگاری ها در اسرع وقت ، سازگاری نهایی را فراهم می کند.

از آنجا که داده ها فقط در مورد یک پارتیشن شبکه متناقض می شوند و ناسازگاری ها به سرعت برطرف می شوند ، کاساندرا عملکرد "تعمیر" را برای کمک به گره ها با همسالان خود ارائه می دهد. با این حال ، در دسترس بودن مداوم منجر به یک سیستم بسیار عملکردی می شود که ممکن است در بسیاری از موارد ارزش تجارت را داشته باشد.

میکروسرویس و قضیه کلاه

خدمات میکروسرویس به صورت مستقل و مستقل از مؤلفه های برنامه کاربردی مستقر هستند که شامل پشته خود هستند - از جمله پایگاه داده و مدل پایگاه داده خود - و با یکدیگر از طریق یک شبکه ارتباط برقرار می کنند. از آنجا که می توانید خدمات میکروسرویس را در هر دو سرور ابری و مراکز داده در محل اجرا کنید ، آنها برای برنامه های ترکیبی و چند منظوره بسیار محبوب شده اند.

درک قضیه CAP می تواند به شما در انتخاب بهترین پایگاه داده هنگام طراحی یک برنامه مبتنی بر میکروسرویس که از چندین مکان در حال اجرا است ، کمک کند. به عنوان مثال ، اگر توانایی تکرار سریع مدل داده ها و مقیاس به صورت افقی برای کاربرد شما ضروری است ، اما می توانید تحمل قوام نهایی (بر خلاف سختگیرانه) را تحمل کنید ، یک پایگاه داده AP مانند Cassandra یا Apache Couchdb می تواند نیازهای شما را برآورده کرده و استقرار شما را ساده کند. بشراز طرف دیگر ، اگر برنامه شما به شدت به سازگاری داده ها - مانند یک برنامه تجارت الکترونیکی یا یک سرویس پرداخت بستگی دارد - ممکن است یک پایگاه داده رابطه ای مانند PostgreSQL را انتخاب کنید.