پیشگفتار
مدتی است که در حال مطالعه در زمینه رایانش ابری (Cloud Computing)، سیستمهای کامپیوتری توزیع شده (Distributed Computer System) و بیگ دیتا (BigData) هستم. از طرفی برای پروژههای کاری شروع به استفاده از آپاچی کاساندرا (Apache Cassandra) کردم. مانند قبل به منظور به اشتراک گذاشتن تجربه، قصد نگارش مطالبی در این زمینهها داشتم. متاسفانه محتوای فارسی در این زمینهها بسیار اندک است. مقالاتی که قصد نوشتن آنها را داشتم، به پیشنیازها زیادی داشت. از طرفی برخی مفاهیم به صورت مستقل معنی و مفهوم دارند. با توجه به این موضوعات، قبل از انتشار مقالات بیگدیتا و آپاچی کاساندرا، مفاهیم و پیشنیازهای مرتبط را ارائه میکنم. قضیه CAP یکی از آن پیشنیازهاست.
مقدمه
امروزه تولید اطلاعات با سرعت سرسام آوری در حال رشد است. افزایش دسترسی مردم به اینترنت و نیز رشد روز افزون شبکههای اجتماعی نمونهای از این تولید اطلاعات است. همه روزه تعداد زیادی متن، عکس، ویدئو و... بر روی اینترنت قرار میگیرند. از طرفی، برخلاف گذشته، شرکتهای بسیاری برای برنامهریزی نقشه راه (Roadmap) و تعیین استراتژی، محتوای بسیاری از مشتریان را برای مدت طولانی ذخیره میکنند. سیستمهای کامپیوتری توزیع شده از جمله مهمترین راهکارها برای مدیریت این اطلاعات هستند. با افزدون هر رایانه به عنوان گره (node) به این شبکهها میتوان بازدهی و توانایی آنها را افزایش داد. رشد این شبکهها به صورت افقی (Horizontal Scalability) یا همان Scale out است. در طی رشد این شبکهها، پیچیدگی آنها نیز افزایش مییابد. قضیه CAP برای توضیح مشکلات و محدودیت های این پیچیدگی ارائه شده است.
قضیه CAP
قضیه CAP |
عبارت CAP ترکیب سرنام مفاهیم زیر است:
- ثبات (Consistency): تمامی گرهها (nodes) اطلاعات یکسانی را در لحظه دارند.
- دسترسی (Availability): هر درخواستی (request) حتما یک پاسخ دریافت خواهد کرد.
- پارتیشن تولرنس (Partition tolerance): اگر بخشی از شبکه دچار مشکل شد، بقیه سیستم به کار خود ادامه خواهد داد. اشکال در بخشی از شبکه نباید منجر به توقف کار کل سیستم شود.
قضیه CAP بیانگر این موضوع است که در سیستمهای توزیع شده شما فقط امکان فراهم کردن دو گزینه از سه گزینه Consistency, Availability و Partition tolerance را خواهید داشت و گزینه باقیمانده قربانی فراهم کردن سایر گزینهها خواهد شد.
نکته: با توجه به مشکلات شبکهای که در هر سیستمای امکان بروز آن وجود دارد، توصیه متخصصین انتخاب قطعی Partition tolerant به عنوان یکی از فاکتورهای گزینش شده است. انتخاب گزینه بعدی از بین Consistency و Availability کاملا به ماهیت نرمافزار و اولویتها کارفرمای شبکه بستگی دارد. در ادامه توضیحات وضعیت گزینشی AP و CP را مشاهده میفرمایید:
گزینش AP
انتخاب Availability و Partition tolerance به معنی آن است که هر درخواستی، پاسخی دریافت خواهد کرد. این پاسخ تا جای ممکنه شامل جدیدترین اطلاعات خواهد بود ولی امکان قدیمی بودن آن نیز وجود دارد. از طرفی نوشتن اطلاعات جدید بر روی گرهها ممکن است در لحظه امکان پذیر نباشد (Partition tolerance). با این وجود سیستم به کار خود ادامه خواهد داد و در نهایت به ثبات اطلاعات خواهد رسید (Eventually Consistent). گزینش AP نشاندهنده این موضوع است که برای تجارت شما در دسترس بودن سیستم و سرعت بیشتر آن، اولویت بالاتری نسبت به ثبات و دوام اطلاعات در لحظه دارد.
گزینش CP
انتخاب Consistency و Partition tolerance به معنی آن است که هر درخواستی برای دریافت اطلاعات، دقیقا و حتما باید آخرین نسخه موجود را به عنوان پاسخ ارسال نماید. از طرفی، این آخرین نسخه موجود از هر اطلاعاتی بر روی سیستم کاملا مشخص و واضح است. یعنی اگر دو درخواست یکسان از دو مکان مختلف به سیستم ارسال شود، سیستم جواب یکسان و مشخصی را به هر دو خواهد داد. نکته دیگر اینکه با افزایش Consistency، شما مدت رکود (Latency Time) را نیز افزایش میدهید. هر میزان که Consistency مورد نیاز خود را افزایش دهید، سیستم دچار رکورد شده و سرعت پاسخدهی کاهش مییابد.
نکته: بار دیگر تاکید میکنم که انتخاب AP یا CP کاملا به ماهیت نرم افزار و اولویت های تجاری کارفرما بستگی دارد.
جایگاه پایگاههای داده در گزینش CAP
پایگاه های داده مختلف گزینش های متفاوتی از CAP انجام میدهند. پایگاههای داده RDBMS به خاطر نوع طراحی و ماهیتی که دارند (ACID)، لزوما گزینش CA را انجام میدهند. بعضی از پایگاه های داده مانند Apache Cassandra انتخاب بین Availability و Consistency را بر عهده مدیر سیستم قرار داده است ولی به صورت بیش فرض خود گزینش AP را انجام میدهد. تصویر زیر تعدادی از پایگاههای داده و نحوه گزینش آنها را به طور گویا بیان کرده است:
پایگاههای داده و قضیه CAP |
پی نوشت
- متاسفانه معادل های فارسی تعریف شده برای واژهها انگلیسی به قدر کافی گویا نیستند. از طرفی برخی عبارت چندین معادل فارسی دارند. مانند BigData که معادل های دادههای عظیم، دادههای انبوه، دادههای حجیم، داده بزرگ، وزرگ داده و کلان داده را دارد. به همین دلیل در متن بیشتر از خود عبارت انگلیسی استفاده شده است.
- در آینده در مورد پایگاههای داده NoSQL، آپاچی کاساندرا، BigData و سیستمهای توزیع شده مطالب بیشتری خواهم نوشت.
- لطفا دانش خود را با سایر به اشتراک بگزارید. متاسفانه مطالب تخصصی و فنی به زبان فارسی بسیار اندک است. همین موضوع باعث شده است که بسیاری از متخصصین و حتی افراد مبتدی به دنبال مطالب انگلیسی برای مطالعه باشند.