۱۳۹۳/۱۱/۲۸

پایگاه داده NoSQL

مقدمه 

در ادامه صبحت‌های که در پیشگفتار مطلب قضیه CAP در سیستم‌های توزیع شده، در این مطلب به معرفی پایگاه‌های داده NoSQL (نواس‌کیوال) می‌پردازم. این مطلب شامل معرفی نوع پایگاه داده NoSQL و ویژگی‌های آن است. در نهایت در مورد توضیحاتی در زمینه Polyglot Persistence ارائه خواهم کرد.

محدودیت های RDBMS و پیدایش جنبش NoSQL

همزمان با فراگیری دسترسی به وب در سطح جهان و با افزایش سرعت و حجم تولید اطلاعات، پایگاه‌های RDBMS مانند MySQL با محدودیت‌هایی مواجه شدند. این محدودیت ها عبارتند از:
  1. گسترش دادن  آن‌ها (Scalability) دشوار است.
  2. معماری آن‌ها به گونه‌ای است که در دسترس بودن تمام سیستم (Availability) دشوار نموده است.
  3. در ساختار و نوع ذخیره سازی اطلاعات محدودیت دارند.
  4. نحوه رشد آن‌ها به صورت Scale up است. به معنی اینکه برای افزایش کارایی باید سخت افزار هر سیستم را تقویت نمایید. در نتیجه هزینه تهیه و نگهداری سیستم‌ها به شدت افزایش می‌یابد.

پایگاه داده NoSQL چیست؟

عبارت NoSQL مخفف Not Only SQL بوده و به جنبش پدید آمدن مجموعه پایگاه‌های داده‌ای اطلاق می‌شود که مفاهیم متقاوتی با پایگاه های داده RDBMS مانند MySQL دارند. از جمله این مفاهیم می‌توان به موارد زیر اشاره کرد:
  • رابطه‌ای (Relational) نیستند. Join و مواردی از این قبیل که شامل رابطه‌ای بین چند جدول است، در NoSQL وجود ندارد.
  • به صورت افقی رشد می‌کنند. اصطلاحا Scale out یا Horizontally Scalable هستند. البته تمامی پایگاه‌های NoSQL امکان Scale out شدن را ندارد و برخی نیز به سختی Scale out می‌شوند.
  • امکان کنترل و مدیریت Availability (در دسترس بودن سرویس) ساده‌تر است.
  • گستره بیشتری از انواع داده و ساختارها را پشتیبانی می‌نمایند.

انواع پایگاه‌های داده NoSQL

انواع پایگاه های داده NoSQL
انواع پایگاه های داده NoSQL
یکی از مهمترین ویژگی‌های جنبش پایگاه‌های داده NoSQL پشتیبانی نمودن گستره عظیمی از انواع ساختار داده‌ها است. این ویژگی باعث انعطاف پذیری در مدل سازی و ذخیره اطلاعات شده است. از این رو پایگاه‌های داده NoSQL بر اساس مدل‌سازی اطلاعات به دسته‌بندی‌های زیر تقسیم می‌شوند:
  • Column: Cassandra, HBase
  • Document: CouchDB, Couchbase, MongoDB
  • Key-value: Dynamo, Redis, Riak
  • Graph: Neo4J, InfiniteGraph
  • Multi-model: OrientDB, FoundationDB
در نظر داشته باشید که انواع پایگاه‌های داده NoSQL برای منظورهای مختلفی طراحی شده است. به معنی آنکه هر کدام مزیت‌های خاص خود را دارند. به همین جهت در هنگام انتخاب پایگاه داده، عامل‌های زیر را در نظر گرفته و بررسی نمایید:
  1. نوع اطلاعاتی که قصد ذخیره سازی آن‌ها را دارید. 
  2. مدل سازی اطلاعات برای ذخیره و خواندن آن‌ها.
  3. میزان اطلاعات ورودی و خروجی سیستم.
  4. اهمیت Consistency و Availability در مدل تجاری‌تان. مطلب قضیه CAP در سیستم‌های توزیع شده را مطالعه نمایید.
  5. در دسترس بودن نیروی متخصص و مستندات کافی برای نگهداری سیستم (Maintenance)
نکته: با توجه به موارد قید شده در بالا، لزوما نمیتوان نوع خاصی از پایگاه‌های داده RDBMS یا NoSQL را به عنوان بهترین راه حل برای تمام بخش‌های یک سیستم در نظر گرفت. مارتین فاولر مفهوم Polyglot Persistence را برای توضیح بیشتر در این زمینه ارائه کرده است.

منظور از Polyglot Persistence چیست؟

هدف از Polyglot Persistence انتخاب و استفاده مناسب از پایگاه‌های داده متفاوت برای بخش‌های مختلف یک سیستم است. به بیان دیگر ممکن است در یک سیستم شما از چندین پایگاه داده استفاده نمایید. عبارت Polyglot به معنای دانستن زبان‌های مختلف بوده و Persistence نیز به معنای ادامه حیات است. با این اوصاف، مفهوم Polyglot Persistence یعنی ادامه حیات با استفاده از شناختن زبان‌های مختلف (در اصل و در اینجا، پایگاه‌های داده مختلف) است. به بیانی ساده‌تر، مفهوم Polyglot Persistence، همانند Polyglot Programming، انتخاب بهترین گزینه برای ادامه حیات موضوعی است که روی آن کار می‌کنیم. تصویر زیر Polyglot Persistence را به صورت گویاتر توضیح داده است:
Polyglot Persistence
Polyglot Persistence

بزودی مطالب بیشتری در زمینه Big Data منتشر خواهم کرد.

۱۳۹۳/۱۱/۱۶

قضیه CAP در سیستم‌های توزیع شده

پیشگفتار

مدتی است که در حال مطالعه در زمینه رایانش ابری (Cloud Computing)،  سیستم‌های کامپیوتری توزیع شده (Distributed Computer System) و بیگ دیتا (‌BigData) هستم. از طرفی برای پروژه‌های کاری شروع به استفاده از آپاچی کاساندرا (Apache Cassandra) کردم. مانند قبل به منظور به اشتراک گذاشتن تجربه، قصد نگارش مطالبی در این زمینه‌ها داشتم. متاسفانه محتوای فارسی در این زمینه‌ها بسیار اندک است. مقالاتی که قصد نوشتن آن‌ها را داشتم، به پیش‌نیازها زیادی داشت. از طرفی برخی مفاهیم به صورت مستقل معنی و مفهوم دارند. با توجه به این موضوعات، قبل از انتشار مقالات بیگ‌دیتا و آپاچی کاساندرا، مفاهیم و پیش‌نیازهای مرتبط را ارائه می‌کنم. قضیه CAP یکی از آن پیش‌نیازهاست.

مقدمه

امروزه تولید اطلاعات با سرعت سرسام آوری در حال رشد است. افزایش دسترسی مردم به اینترنت و نیز رشد روز افزون  شبکه‌های اجتماعی نمونه‌ای از این تولید اطلاعات است. همه روزه تعداد زیادی متن، عکس، ویدئو و... بر روی اینترنت قرار می‌گیرند. از طرفی، برخلاف گذشته، شرکت‌های بسیاری برای برنامه‌ریزی نقشه راه (Roadmap) و تعیین استراتژی، محتوای بسیاری از مشتریان را برای مدت طولانی ذخیره می‌کنند. سیستم‌های کامپیوتری توزیع شده از جمله مهم‌ترین راهکارها برای مدیریت این اطلاعات هستند. با افزدون هر رایانه به عنوان گره (node)  به این شبکه‌ها می‌توان بازدهی و توانایی آن‌ها را افزایش داد. رشد این شبکه‌ها به صورت افقی (Horizontal Scalability) یا همان Scale out است. در طی رشد این شبکه‌ها، پیچیدگی آن‌ها نیز افزایش می‌یابد. قضیه CAP برای توضیح مشکلات و محدودیت های این پیچیدگی ارائه شده است.

قضیه 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
پایگاه‌های داده و قضیه CAP

پی نوشت

  • متاسفانه معادل های فارسی تعریف شده برای واژه‌ها انگلیسی به قدر کافی گویا نیستند. از طرفی برخی عبارت چندین معادل فارسی دارند. مانند BigData که معادل های داده‌های عظیم، داده‌های انبوه، داده‌های حجیم، داده بزرگ، وزرگ داده و کلان داده را دارد. به همین دلیل در متن بیشتر از خود عبارت انگلیسی استفاده شده است.
  • در آینده در مورد پایگاه‌های داده NoSQL، آپاچی کاساندرا، BigData و سیستم‌های توزیع شده مطالب بیشتری خواهم نوشت.
  • لطفا دانش خود را با سایر به اشتراک بگزارید. متاسفانه مطالب تخصصی و فنی به زبان فارسی بسیار اندک است. همین موضوع باعث شده است که بسیاری از متخصصین و حتی افراد مبتدی به دنبال مطالب انگلیسی برای مطالعه باشند.