خانه / بلاگ / پایگاه‌ داده‌های NoSQL

پایگاه‌ داده‌های NoSQL

امروزه به‌دلیل فراگیر شدن شبکه‌های گسترده رایانه‌ای به‌ویژه اینترنت و به وجود آمدن نرم افزارهای تحت وب با کاربران بسیار زیاد، دیگر پایگاه داده های [۱]RDBMS یا سنتی پاسخگوی نیاز این نرم‌افزارها، توسعه‌دهندگان و استفاده‌کنندگان آن نیستند؛ از دلایل این امر می‌توان به نگاه‌داری داده‌ها با حجم بسیار زیاد، سرعت بالا در خواندن و نوشتن نام برد. به همین دلایل پایگاه داده‌های نسل بعدی یعنی NoSQL ها در اواخر دهه اول هزاره سوم میلادی (قرن ۲۱) به وجود آمدند و بسیار سریع در حال پیشرفت هستند. در این پست کوتاه به صورت اجمالی به معرفی این پایگاه داده‌ها، انواع آنها و چندین اصطلاح پرکاربرد در ارتباط با این حوزه خواهیم پرداخت.

از ویژگی‌های NoSQL ها می توان به نحوه ذخیره سازی و نگه داری داده ها به صورت توزیع شده، نبودن رابطه به صورت جداولی، عموما متن باز بودن، بدون Schema بودن و قابلیت گسترش پذیری در سرور های مختلف با محل های جغرافیایی متفاوت اشاره کرد. در این پایگاه داده ها دیگر محدودیت های ساختار های خاص، نرمال سازی و غیر نرمال سازی و بسیاری موارد دیگر را نمی بینیم.

مقایسه NoSQLها و RDBMSها

برای درک بهتر مفهوم پایگاه داده های NoSQL و نحوه عملکر آن ها شاید بهتر باشد تا ویژگی های آن ها را درکنار ویژگی های پایگاه داده های رابطه قرار داد و مقایسه کرد. جدول ۱ مقایسه ای کوچک میان پایگاه داده های NoSQL یا غیر رابطه ای و RDBMS یا رابطه ای را نشان می دهد.

جدول۱  مقایسه پایگاه داده های NoSQL با پایگاه داده های رابطه ای

  RDBMS NoSQL
انواع یک نوع با امکانات مختلف Key-Value, Column Store, Document Store, Graph
تاریخچه توسعه در دهه ۱۹۷۰ برای مقابله با اولین موج از برنامه های ذخیره داده، توسعه داده شدند در دهه ابتدایی هزاره سوم برای مقابله با محدودیت های پایگاه های داده SQL خصوصاً نگرانی حول مقیاس، تکرار و ذخیره داده بدون ساختار، توسعه یافتند
نمونه Microsoft SQL Server, MySQL, Oracle Aerospike, Sophia, BigTable, MongoDB, Cassandra, HBase, Neo4j, OrientDB
 

 

مدل نگهداری داده

جدول (رابطه) شامل ستون ها و ردیف ها بر اساس نوع پایگاه داده متفاوت است. برای مثال، انبارهای key-value مشابه پایگاه های داده SQL عمل می کنند، اما تنها دو ستون دارد (key و Value) به همراه اطلاعات پیچیده تری که برخی مواقع درون ستون value ذخیره می شود. پایگاه های داده مبتنی بر سند، تمامی داده های مرتبط با یکدیگر را در یک “سند” در JSON، XML و یا سایر فرمت ها که مقدار ها را به صورت سلسله مراتبی در خود جای می دهند، ذخیره می کنند.
 

شِما (اسکیما)

با حرکت از رکورد یک به رکورد دو، ساختار داده‌ای یکسان می باشد. با حرکت از رکورد یک به رکورد دو،  ممکن است با دو ساختار داده‌ای متفاوت مواجه شوید (بدون شِما).
مقیاس پذیری عمودی؛ به این معنی که یک سِرور تنها به منظور غلبه بر تقاضای افزایش یافته، باید به میزان زیادی تقویت شود. امکان دارد که پایگاه های داده SQL در میان سِرور های متعددی توزیع شود، اما عموماً نیاز به مهندسی مازاد قابل توجهی است. افقی؛ به این معنی که برای افزایش ظرفیت، یک راهبر پایگاه داده به راحتی می تواند سِرور و یا مواردی همچون فضای ابری را اضافه نماید. پایگاه داده، در صورت لزوم به طور خودکار داده را در میان سرور توزیع می کند.
مدل توسعه ترکیبی از منبع باز (مانند MySQL و Postgres)

و منبع بسته (مانند پایگاه داده Oracle)

اکثراً منبع باز
پشتیبانی تراکنش ها اکثراً به صورت کامل پشتیبانی می کنند در شرایط خاص و در سطوح خاص

(سطح سند در مقابل سطح پایگاه داده)

زبان مدل زبان برنامه نویسی استاندارد شده SQL. در برخی انواع مختلف مانند PL/SQL و T-SQL. سمت برنامه نویسی – زبان های مختلف

مانند : xml – Json – Java Script , …

پایایی امکان پیکربندی برای پایایی زیاد و قوی وابسته به محصول، برخی پایایی زیاد را فراهم می آورند (برای مثال MongoDB) در حالیکه برخی پایایی مشروط و نسبی فراهم می آورند.

طبقه‌بندی ساختاری NoSQLها

در این بخش اشاره کوتاهی بر انواع پایگاه داده های NoSQL کرده و به صورت مختصر پیرامون هرکدام توضیح خواهیم داد. پایگاه داده های NoSQL بر اساس نوع ذخیره سازی و ارتباط داده ها به چهار دسته کلی تقسیم می شوند:

  • Key-Value Store (کلید – مقدار)،
  • Column Family Store (خانواده ستونی)،
  • Document Store (سندگرا)،
  • Graph Based (مبتنی بر گراف).

در ذیل شرح مختصری از هر کدام از این دسته ها، موارد کاربرد آن ها، مزایا و معایب هریک و بلاخره چندین نمونه توزیع موجود در بازار، آمده است.

  • کلید مقدار: ساده‌ترین حالت از دسته‌بندی‌های NoSQL دسته، کلید-مقدار می‌باشد و معمولا در سیستم هایی مورد استفاده قرار می گیرد که داده‌ها از یکدیگر متمایز هستند و اصولا در دسترس بودن داده‌ها نسبت به مواردی نظیر پایائی اهمیت بیشتری دارد. در این معماری فقط یک کلید داریم (که مانند کلید اصلی در پایگاه داده های رابطه ای عمل می کنند) و یک مقدار داریم که مقدار معادل آن کلید را باز می گرداند. از مزایای این دسته می توان به سرعت بالا در درج کردن و خواندن اطلاعات، پیاده سازی و قابلیت توسعه پذیری آسان اشاره کرد.
    • چند نمونه محصول: LevelDB، Redis و Aerospike.
  • خانواده ستونی: پایگاه های داده ستونی با توسعه کلید-مقدارها به وجود آمده اند. این پایگاه های داده در واقع به جای یک جفت کلید-مقدار، می توانند برای هر رکورد چندین جفت کلید-مقدار داشته باشند. در این نوع نیازی به ساختار نداریم و هر رکورد می تواند چندین ستون با تعداد صفات متفاوت داشته باشند. از مزایای این دسته می تواند ذخیره سازی میزان وسیع و متفاوتی از رکوردها با مقادیر بسیار باشد.
    • چند نمونه محصول: Amazon SimpleDB، Cassandra و HBase.
  • سند گرا: این دسته از پایگاه داده ها نیز مانند دسته اول یعنی کلید-مقدار و دسته دوم ستونی می باشند ولی با این تفاوت که در این سیستم دسته بندی داده های مرتبط با یکدیگر در قالب یک فایل سند می باشند. از متن ساده گرفته تا یک ایمیل یا عکس و … یک سند می باشند. اما با وجود قدرت بسیار بالایی که این نوع پایگاه های داده دارند، خواندن و نوشتن در آن ها بسیار وقت گیر است. از مزایای این دسته می توان به ذخیره سازی مقدار زیادی داده های بی ربط نام برد.
    • چند نمونه محصول: MongoDB، Elastic Search، CouchDB و RavenDB.
  • مبتنی بر گراف: این دسته از پایگاه های داده به داده ها، از دید کاملا متفاوتی نسبت به دسته های قبلی نگاه می کند. داده ها را مانند یک گراف به هم مرتبط می کند و ساختار یک درخت یا گراف را به داده ها می دهد. در این پایگاه داده، رکوردها هنگام درج شدن، توسط یک یا چند صفت به هم مرتبط می شوند؛ نتیجه این که انجام عملیات ریاضی و الگوریتمیک بسیار ساده تر از دسته های دیگر است. کاربرد این دسته زمانی است که ارتباطات معین و مشخصی میان رکوردها وجود دارد؛ مثل شبکه های اجتماعی. از مزایای این دسته می توان به مناسب بودن برای تحقیقات علمی و فنی اشاره کرد.
    • چند نمونه محصول: Neo4J، InfoGrid، AllegroGraph و.Sparksee

برخی از پایگاه های داده NoSQL همزمان از چندین مدل پشتیبانی می کنند. به عنوان مثال هم دارای امکاناتی برای ذخیره و بازیابی اسناد و هم دارای امکاناتی برای کار با گراف ها هستند. چنین پایگاه داده هایی را Multi-Model هم می نامند و برای کاربردهای ترکیبی ایده آل به نظر می رسند. از جمله ابزارهای مطرح در این زمینه پایگاه داده OrientDB است، که موضوع اصلی فصل سوم این نوشتار می باشد.

نظریه CAP

با توجه به گستردگی و تنوع زیاد موجود در محصولات NoSQL بر خلاف محصولات رابطه ای انتخاب یک محصول متناسب برای استفاده در پروژه های مرتبط، در نگاه اول ساده به نظر نمی رسد. نظریه CAP که در این جا تشریح می شود، راهنمای بسیار خوبی برای انتخاب پایگاده داده مناسب با نیازهای نرم افزار موردی می باشد. نظریه CAP از ۳ راس Availability، Consistency  و Partition-tolerance تشکیل شده است.

  • Availability یا دسترسی پذیری، به این معنا می باشد که کاربران همیشه بتوانند عملیات درج کردن و خواندن را داشته باشند. یعنی اگر Server اصلی و یا یک Server دیگر دچار مشکل شد ارتباط کاربران قطع نشود و همچنان دسترسی داشته باشند. یک بیان دیگر دسترسی پذیری اذعان می دارد که همه درخواست‌ها در مورد موفقیت آمیز یا ناموفق بودن عملیات جواب مناسبی را دریافت کنند.
  • Consistency یا سازگاری یعنی داده هایی که تمام کاربران مشاهده می کنند از هر جا برای تمام آن ها داده های یکسان نمایش داده شود و هیچ کاربری نسبت به دیگری داده های کمتر، بیش تر یا اشتباهی یا متفاوتی را نبیند که یعنی پایگاه داده تضمین می کند که یک فقره از اطلاعات همیشه و همه جا یکسان ذخیره سازی شده باشند.
  •  Partition-telorance به این معنا می باشد که سرور های مختلف در مکان های مختلف جغرافیایی به طوری توزیع شوند که سیستم به طور یکپارچه با همه گره ها در ارتباط می باشد و کار می کند. به عبارت دیگر سامانه به کار خودش ادامه دهد حتی در صورت پیش‌آمدن شکست شبکه‌ای در مقیاس گسترده. شکل ‏۱ یک شمای مفهومی از ارتباط این سه عامل را در قالب رئوس یک مثلث نشان می دهد.

شکل ‏۱ شمای مفهومی رئوس مثلث CAP

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

تفسیر جمله آخر پاراگراف فوق این است که مدل داده ای مورد نیاز ما یا باید CA باشد که در این حالت استفاده از پایگاه داده های رابطه ای مناسب می باشد. یا باید AP باشد که در این صورت پایگاه داده های غیر رابطه ای یا NoSQL پیشنهاد داده می شوند که معمولا از نوع کلید-مقدار و یا ستونی هستند و یا CP باشد که بیش تر پایگاه داده هایی که از نوع NoSQL و در دسته های ستونی، سندگرا و یا مبتنی بر گراف هستند پیشنهاد می شوند که البته در شکل ‏۱ چند نمونه از این پایگاه داده ها بر اساس اضلاع مثلث پیشنهاد شده اند.

مراجع

به زودی درج می‌گردد.

 

پانویس‌ها

[۱] Relational Database Managements System

درباره ی [مرتضی]

مرتضی ذاکری - عضو تیم کاری تارنمای میکروپدیا دانش آموخته مهندسی کامپیوتر - گرایش نرم افزار

همچنین ببینید

مهندس نرم افزار بشویم یا نشویم؟

میزان تقاضا برای ورود به رشته های تحصیلی مانند مهندسی نرم افزار، سخت افزار، آی …

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

پاسخ عبارت زیر را وارد کنید: *