آشنایی با مدل‌های مدیریت داده‌ها و سیستم های مدیریت بانک های اطلاعاتی

مطلب زیر تماما به نقل از سلام دنیا بازنشر میشود.

در دهه‌های گذشته، ذخیره‌سازی موثر داده‌ها و بدون تناقض آن‌ها جنبه مهم مدیریت داده‌ها بوده است. امروزه مساله ذخیره‌سازی داده‌ها سهم کمتری در میان مساله مدیریت داده‌ها دارد. مدیریت داده‌ها و استفاده از آن‌ها حتی نسبت به ده سال قبل، شکل دیگری به خود گرفته است. شبکه‌های اجتماعی، سیستم‌های امنیتی و هوشمند، میزبان‌های رسانه (Media Servers)، دوربین‌های مدار بسته، سیستم‌های مدیریت نقشه‌ها، شبکه‌های سنسوری و… هر یک به نوعی خاص نیازمند استفاده و مدیریت داده‌ها هستند. به عبارتی هر جنبه کیفی استفاده از داده‌ها مانند امنیت و سرعت دسترسی، امکان تغییر و توسعه داده‌ها به شکل‌های گوناگون و… باعث شدند مدل‌های ذخیره‌سازی متفاوتی برای داده‌ها به وجود آید. علاوه بر این موارد، حجم عظیم داده‌های مبادله شده باعث ایجاد مساله‌ای تازه به نام داده‌های بزرگ (BigData) شده است. بنابراین حوزه‌ی مطالعاتی در زمینه‌ی داده‌ها بسیار وسیع است. در این بخش سعی شده که به معرفی اجمالی از چند مدل ذخیره‌سازی داده‌ها و سیستم‌های مدیریت مربوط به آن مدل‌ها پرداخته شود. از آنجا که مدل داده‌ای یک پایگاه‌داده‌ها، رابطه مستقیمی با سیستم مدیریت آن پایگاه داده دارد (البته به جز نوع بدون قالب آن)، در این نوشته گاهی اوقات از واژه «مدل» و «پایگاه‌داده‌ها» به جای «سیستم مدیریت پایگاه‌داده‌ها» استفاده شده است. هرچند که هر کدام مفاهیمی جدا هستند.

سیستم‌های مدیریت پایگاه‌های داده رابطه‌ای (RDBMS):

این مدل را می‌توان جزو پرکاربردترین و شناخته شده‌ترین مدل مدیریت داده‌ها و نیز بالغ‌ترین مدل بین سایر مدل‌ها دانست. شالوده مدل رابطه‌ای، منطق رابطه‌ای است. این منطق توسط ادگار کاد (Edgar Codd)، دانشمند علوم رایانه در سال ۱۹۷۰ معرفی شده و در واقع تفسیر دیگری از نظریه مجموعه‌ها و جبر رابطه‌ای است. هر قلم داده (Data Entity) در مدل رابطه‌ای، معادل یک سطر از جدول است که با یک کلید از سایر سطرهای آن جدول متمایز می‌شود. منطق رابطه‌ای در واقع یک جبر بسته است. به این ترتیب که همه چیز، اعم از جداول و سطرهای جدول، یک رابطه است و حاصل عملگرهای جبری بر روی رابطه‌ها، باز هم یک رابطه است. به خاطر این شالوده‌ قدرتمند، مدل رابطه‌ای توانست جایگزین مدل‌های ناکارآمدی چون مدل سلسله مراتبی و مدل شبکه‌ای شود که پیمایش بین داده‌ها از طریق اشاره‌گرها و زیرروال‌های پیمایشگر صورت می‌گرفت؛ بر خلاف مدل رابطه‌ای که هر سطر به طور منظم و مستقل در جایگاه خود قرار دارد و یافتن آن‌ها نیازمند اشاره‌گرهای نسبی و فراخوانی زیرروال‌های پیمایشگر نیست. بسته بودن منطق رابطه‌ای، باعث به کارگیری پرس‌وجوها (query) به طور تو در تو و به طور موثر می‌شود. در این مدل، عملگرهای رابطه‌ای مانند join، باعث اتصال جدول‌ها با یکدیگر و استفاده‌ی موثر از داده‌ها می‌شود. زبان دستکاری و به کار گیری داده‌ها (DML) در این مدل، معمولا زبان SQL است که یک زبان سطح بالا و اخباری (declarative) است. از آنجا که روند تدریجی توسعه سیستم‌های نرم‌افزاری می‌تواند باعث تغییرات آتی در ساختار پایگاه‌داده‌ها شود، طراحی درست یک پایگاه‌داده‌ها، مساله‌ای ضروری و مهم است. این موضوع در مدل ذخیره‌سازی رابطه‌ای، تا حدودی مساله‌ای چالشی است. گرچه معرفی سطوح نرمال‌سازی و روش‌های نرمال‌سازی پایگاه‌های داده، گام‌های مورد نیاز را برای این امر فراهم می‌آورند، اما طراحی درست و نرمال یک پایگاه‌داده‌های رابطه‌ای خبرگی و مهارت خاص خود را می‌طلبد.

?

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

مدل رابطه‌ای دارای محدودیت‌های خاص خود است. کاربر نمی‌تواند به طور معمول و موثر، هر نوع ساختار داده دل‌خواه خود را در یک جدول پایگاه‌داده‌های رابطه‌ای ذخیره کند. به علاوه این که هر RDBMS برای خود مجموعه نوع داده (Data Type)های خود را ارائه کرده است که جدای از ناهمخوانی با یکدیگر، محدود هستند.

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

سیستم‌های مدیریت پایگاه‌های داده شیئ گرا (OODBMS):

اواخر دهه ۸۰ میلادی را می‌توان زمان ظهور پایگاه‌های داده‌ی شئ‌گرا دانست که در واقع پاسخی به نیازمندی‌های برنامه‌های CAD بود که با اشیاء داده‌ی پیچیده و تودرتو سروکار دارند. مساله اینجاست که برنامه‌ی CAD یک برنامه‌ی روالی (procedural) است که در هر لحظه یک ورودی می‌گیرد و یک خروجی پیچیده تولید می‌کند، اما این با ساختار رابطه‌ای در تضاد است و پیاده‌سازی آن در منطق رابطه‌ای مستلزم اجرای دستورات join متعدد و پرس و جو (query)های طولانی، آن هم برای گرفتن تنها یک سطر خروجی است.

سیستم‌های مدیریت پایگاه‌داده‌های شئ‌گرا (OODBMS) برای حل این مشکلات به وجود آمد. خصوصیات این سیستم را می‌توان بطور خلاصه این طور بیان کرد:

• پشتیبانی از نوع داده کاربر (User Data Type)
• امکان ذخیره‌سازی اشیاء تودرتو
• پشتیبانی از لیست اشیاء (مانند مجموعه‌ها، آرایه‌ها، دسته‌ها) و bag (لیستی از لیست‌ها) ، هر کدام به عنوان یک شیئ مستقل
• پشتیبانی از متد‌های اشیاء (معادل روال‌های ذخیره شده (Stored Procedure) در پایگاه‌داده‌های رابطه‌ای): متدها جزئی از منطق شئ‌گرا هستند. به جای آن که برنامه درگیر اجرای query جهت دریافت اطلاعات اطلاعات از پایگاه‌داده‌های و محاسبات آن و ارسال نتیجه به پایگاه داده شود، یک متد شئ می‌تواند به طور موثر در سمت سرور پایگاه‌داده‌های اجرا شود و تغییرات را در همان جا، روی شئ اعمال کرده و نتیجه را به برنامه برگرداند.
• و یکی از مهم‌ترین خصوصیات این سیستم، اشتراک در نوع داده در برنامه و پایگاه‌داده‌ها است که باعث اعمال قوانین بررسی قوی نوع (Strong Type Checking) در زمان انتقال داده‌ها بین برنامه و پایگاه‌داده‌ها، به طور موثر می‌شود.
• ادغام با زبان‌های برنامه‌نویسی: از آنجا که ساختار داده‌ها در پایگاه‌داده‌ها، مانند همان ساختار برنامه کاربر است، ذخیره و بازیابی اطلاعات می‌تواند از طریق دستورات DML درون خود برنامه یا زبان برنامه نویسی صورت بگیرد، به جای آنکه دستورات DML از طریق یک واسطه محدود مانند Connection Stringها یا دستورات خاص، به پایگاه‌داده‌ها، به عنوان یک سیستم جدا ارسال شود.

مشکلات سیستم‌های مدیریت پایگاه‌های داده شئ گرا:

• پیمایش بین داده‌ها از طریق روال‌های جداگانه: در منطق پایگاه داده شیئ‌گرا، اشیاء داده به وسیله‌ی اشاره‌گرها به یکدیگر متصل هستند. این منطق وجود یک زیرروال پیمایشگر را موجب می‌شود که می‌توان آن را یک گام به عقب توصیف کرد.
• نقض encapsulation: خاصیت encapsulation یکی از پایه‌های مفهوم شیئ‌گرایی است. از آنجا که با اجرای query می‌توان به داده‌های درون یک شئ درون پایگاه‌داده‌ها دست یافت، می‌توان این طور گفت که پایگاه‌داده‌‌ها شئ‌گرا، مفهوم شئ‌گرایی را به طور کامل پشتیبانی نمی‌کنند. گاهی اوقات نقض این encapsulation ضروری است. به عنوان مثال نیازمند داده‌ای از یک شئ داده هستیم که متد آن پیاده‌سازی نشده است و دستیابی به این مقدار، تنها یک بار صورت می‌گیرد. در واقع منطقی نیست که برای دستیابی به این مقدار بخواهیم یک متد جدا درون شئ داده‌ی درون پایگاه‌داده‌ها بنویسیم. بنابراین همواره یک مصالحه بین نقض encapsulation و نوشتن متدهای بیشتر برای اشیاء داده وجود دارد.
• بسته بودن جبر رابطه‌ای موجود در منطق رابطه‌ای در اینجا وجود ندارد و به کارگیری پرس‌وجو های تودرتو که حاصل این بسته بودن بود، در اینجا از دست می‌رود. به خصوص که در این مدل، اخباری بودن و سطح بالا بودن زبان دسترسی به داده‌ها (DML) تضعیف می‌شود.
• در نهایت آن استخوان‌بندی و شالوده قدرتمند ریاضی که منطق رابطه‌ای بر آن استوار بود، در منطق پایگاه‌داده‌های شئ‌گرا وجود ندارد و این به معنی از دست رفتن مجموعه‌ای از ابزارهای تحلیل و استنتاج مبتنی بر این منطق است.

ایده‌ای که در پشت پیاده‌سازی پایگاه‌داده‌های شئ گرا نهفته بود این بود که برای توسعه‌دهندگان بسیار مفید خواهد بود که نه تنها ذهنشان درگیر پیاده‌سازی پشت رابط اشیاء داده نشود، بلکه حتی درگیر این مساله نباشند که آن شئ چطور در پایگاه‌داده‌ها ذخیره می‌شود.

سه اشتباه که تکرار شد:

شرکت‌های توسعه‌دهنده و پشتیبان ایده پایگاه‌های داده شئ‌گرا متوجه تکرار اشتباه خود شدند.

اولین اشتباه آن‌ها نزدیک کردن بیش از حد طراحی پایگاه‌داده‌ها به طراحی برنامه‌ها بود. آن‌ها دوباره فهمیدند که این نزدیک شدن با معماری چند لایه توسعه نرم‌افزارها که باعث انعطاف در توسعه نرم‌افزارها می‌شود تناقض دارد.

آن‌ها همچنین دوباره فهمیدند که استفاده از زبان‌های اخباری مانند SQL-92 چنان بهره‌وری را بالا می‌برد که شرکت‌های توسعه‌دهنده نرم‌افزار ترجیح می‌دهند که به جای درگیری با مفاهیم جدید، هزینه تامین منابع سخت‌افزاری را پرداخت کنند؛ به عبارتی شما همواره می‌توانید سخت‌افزار بخرید، اما زمان را هرگز!

آن‌ها همچنین دوباره فهمیدند که استاندارد نبودن یک مدل داده‌ای منجر به خطا در طراحی و بروز ناسازگاری در داده‌ها می‌شود. نگهداری از یک سیستم مدیریت پایگاه‌های داده شئ‌گرا کاری بسیار سخت بود.

سیستم مدیریت پایگاه‌های داده شئ-رابطه‌ای (ORDBMS):

گرچه تا سال ۹۵ میلادی، بحث شئ‌گرایی در پایگاه‌های داده مساله داغی بود، اما هنوز یک توافق عام بر سر اینکه یک پایگاه‌داده‌های شئ‌گرا باید شامل چه خصوصیاتی باشد، شکل نگرفت! در نهایت همگان بر این موضوع توافق کردند که پشتیبانی کمی شئ‌گرایی در پایگاه‌های داده بسیار مفید است! به عبارتی گرچه پایگاه‌های داده شئ‌گرا نتوانستند موقیت قابل انتظاری را کسب کنند، اما پیشرو در ارائه چند ایده موفق و کاربردی بودند که بعدها در پایگاه‌داده‌های شئ-رابطه‌ای نیز توانستند پیاده‌سازی شوند. همچنین توسعه‌دهندگان سیستم‌های مدیریت پایگاه‌داده‌های رابطه‌ای نیز متوجه وجود کمبود در این سیستم‌ها شدند، سعی کردند به هر طریقی پشتیبانی از اشیاء داده را در سیستم‌های خود و با رعایت انطباق با نسخه‌های قبلی وارد کنند. که در منبع چهارم این نوشته با دشواری‌های زیاد این رویکرد آشنا خواهید شد. نهایتا گرایش به فواید موجود در مدل‌های ORDBMS و OODBMS باعث به وجود آمدن مفهومی با عنوان پایگاه‌های داده شئ-رابطه‌ای (Object-Relational) شد.

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

• پشتیبانی از داده‌های پیچیده
• پشتیبانی از ارث‌بری نوع داده
• پشتیبانی از رفتار اشیاء

منظور از رفتار اشیاء همان متدهای تعریف شده درون اشیاء داده است و این رفتار را می‌توان به عنوان حتی یک برنامه‌ی مستقل گسترش داد. نکته جذاب این است که با این دیدگاه می‌توان بخش زیادی از لایه منطق (Business Logic) برنامه را در سمت سرور اجرا کرد، بدون آنکه مانند گذشته، محاسبات در سمت کلاینت صورت بگیرد و تاخیر در انتقال داده‌ها باعث تاخیر در محاسبات گردد. یک سیستم مدیریت پایگاه‌داده‌های شئ-رابطه‌ای مانند یک سکو یا با یک مثال بد، مانند یک سیستم‌عامل عمل می‌کند، به این ترتیب که می‌تواند منابع سیستم را برای این برنامه‌ها و نیز ارتباطات بین برنامه‌ای را کنترل و مدیریت کند. این قدرت و انعطاف‌پذیری، باعث شده است که بسته‌های مختلفی برای این نوع سیستم نوشته شود که نوع داده‌ها و متدهای خود را وارد ORDBMS می‌کنند و کاربر می‌تواند در کنار استفاده‌ای که قبلا از یک DBMS به عنوان یک سیستم رابطه‌ای استاندارد می‌کرد، از این متدها و نوع داده‌های جدید در برنامه خود استفاده نماید.

?

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

معرفی سیستم‌های مدیریت پایگاه‌داده‌های NoSQL و مخازن داده:

گرچه مدل رابطه‌ای بسیار قدرتمند و انعطاف‌پذیر است، اما همان‌طور که اشاره شد، کارکردن با این مدل داده مهارت خاص خود را می‌طلبد. جدای از این، خیلی از کاربران، مشکلات و نیازمندی‌هایی دارند که راهکار پایگاه‌داده‌های رابطه‌ای و حتی شئ-رابطه‌ای برایشان مناسب نیست. در دهه اخیر سیستم‌هایی موسوم به NoSQL و برنامه‌های مربوط به آن‌ها بسیار پرطرفدار و فراگیر شده‌اند، با این شعار که در کنار معرفی کارکردهای جدید، بسیاری از دشواری‌های کار کردن با مدل رابطه‌ای را نیز برطرف کنند. در واقع هدف این است که با ریشه‌کن کردن محدودیت‌های سخت‌گیرانه‌ای که قبلا در سیستم رابطه‌ای معرفی شده بود، بتوان به راحتی و انعطاف بالا در نگهداری، پرس‌وجو و استفاده از داده‌ها رسید. پایگاه‌داده‌های NoSQL با استفاده از شیوه‌های ساخت‌نایافته (یا ساخت‌یافته در زمان عمل) به حذف محدودیت‌های رابطه‌ها کمک می‌کند و راه‌های متعدد و مختلفی را جهت موارد استفاده‌ی خاصی هم چون ذخیره «تمام متن» اسناد (full-text document storage) ارائه می‌کند. بر خلاف آنچه که در مقدمه آورده شده، در سیستم‌های پایگاه‌داده‌های NoSQL هیچ مدل داده‌ای همانند سیستم‌های پایگاه‌داده‌های رابطه‌ای، مورد استفاده یا نیاز نیست. هر سیستم مدیریت پایگاه‌داده‌های NoSQL، به منظورهای خاص و هر یک به شیوه خاص، این منطق را پیاده سازی کرده‌اند. این پیاده‌سازی‌ها و راهکارهای بدون قالب (schema less) هم اجازه‌ی پشتیبانی از انواع نامتناهی از فرم‌های داده‌ای را فراهم می‌آورد و هم اینکه به طور ساده و بسیار موثری، از قالب «کلید-مقدار»ی که در مدل رابطه‌ای بود، پشتیبانی می‌کنند. پشتیبانی از قالب کلید-مقدار، بیشتر برای تعداد داده‌های کوچک و معمولا به منظور cache کردن داده‌ها به کار می‌رود که در بخش مقایسه سیستم‌های NoSQL به آن پرداخته می‌شود.
?
بر خلاف پایگاه‌داده‌های رابطه‌ای، قادر خواهیم بود تا کلکسیونی (collection) از داده‌ها را درون یک سیستم پایگاه‌داده‌های NoSQL همانند MongoDB داشته باشیم. این پایگاه‌داده‌های یا به عبارت دیگر این «مخازن اسناد» (document stores) هر داده را در کنار سایر داده‌ها، تحت عنوان یک کلکسیون (یا همان سند) در پایگاه‌داده‌های نگهداری می‌کند. این اسناد می‌توانند تحت عنوان اشیاء داده مستقل مانند قالب JSON به نمایش درآیند و همچنین بر اساس صفت‌هایش پرس‌وجو شوند.

سیستم‌های پایگاه‌داده‌های NoSQL بر خلاف سیستم رابطه‌ای که از زبان SQL استفاده می‌کرد، روش‌های مشترکی را برای پرس‌وجو از داده‌ها ارائه نمی‌کنند و هر سیستم NoSQL راهکار پرس‌وجو یا دسترسی خاص خود به داده‌ها را دارا است.

مقایسه سیستم‌های مدیریت پایگاه‌های داده مبتنی بر SQL (رابطه‌ای) و NoSQL

جهت ساده‌سازی در ارائه‌ی مفهوم، سعی می‌گردد تا تفاوت‌های این دو سیستم بررسی گردد

• ساختار و نوع داده نگهداری شونده: در سیستم رابطه‌ای، نیازمند یک ساختار از صفات برای نگهداری از داده‌ها هستیم، بر خلاف NoSQL که معمولا اجباری را تحمیل نمی‌کند.
• پرس‌وجو: همه‌ پایگاه‌داده‌های رابطه‌ای استاندارد SQL را تا حدودی پیاده‌سازی کرده‌اند و می‌توانند از طریق SQL مورد پرسوجو قرار گیرند. در NoSQL شرایط عکس است. همان طور که گفته شد، هر پیاده‌سازی، روش خودش را برای کار با داده‌ها دارد.
• بسط‌پذیری: هر دو این راهکارها قابل رشد به صورت عمودی هستند. (مثلا افزایش منابع سیستم). هرچند با پیشرفت و ساده‌تر شدن برنامه‌ها، راهکارهای NoSQL ابزارهای راحت‌تری را در جهت رشد افقی ارائه می‌کنند (مثلا ساختن یک cluster از چندین ماشین)
• قابلیت اتکا: هنگامی که مساله قابلیت اطمینان در داده‌ها و تضمین تراکنش‌های انجام شده مطرح باشد، همچنان بهتر است بر روی پایگاه‌های داده رابطه‌ای شرط ببندید!
• پشتیبانی: پایگاه‌داده‌های رابطه‌ای، قدمتی طولانی دارند. همان طور که گفته شد، بسیار پرطرفدار هستند و پیدا کردن پشتیبانی برای آن‌ها چه به صورت رایگان و هزینه‌ای به راحتی امکان‌پذیر است. طبیعی است که حل مشکلات نیز در سیستم سنتی بسیار سریع‌تر از سیستم‌های تازه به ظهور رسیده مانند MongoDB که گفته می‌شود ذاتا پیچیده است، خواهد بود.
• داده‌های پیچیده و نیاز به نگهداری و پرس‌وجو: به طور ذاتی، پایگاه‌داده‌های رابطه‌ای از منطق go to جهت پرس‌وجو های پیچیده و برآورده نمودن نیاز نگهداری از داده‌ها استفاده می‌کنند که در این حوزه پیشرو بوده و بسیار موثرترند.

?گرچه در ادامه به جزئیات بیشتری از سیستم‌های NoSQL پرداخته می‌شود، لیکن موارد استفاده یا عدم استفاده از این سیستم‌ها را می‌توان به طور کلی به این شکل عنوان کرد:

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

مقایسه سیستم‌های مدیریت پایگاه‌داده‌های NoSQL و مدل‌های آن‌ها

در این بخش سعی بر آن است که سیستم‌های مدیریت پایگاه‌داده‌های NoSQL معرفی گشته و کارکرد و اهداف آن‌ها تشریح شود تا بتوان در صورت نیاز، انتخابی درست و موثر انجام داد.

به طور کلی، می‌توان سیستم‌های مدیریت پایگاه‌های داده NoSQL را به چهار دسته زیر تقسیم نمود:

• مبتنی بر مقدار-کلید
• مبتنی بر ستون
• مبتنی بر سند
• مبتنی بر گراف

?

۱) مبتنی بر کلید-مقدار:

این مدل می‌تواند به عنوان ساده ترین مدل در بین سایر مدل‌های این دسته و نیز زیرساخت مفهوم NoSQL شناخته شود. این نوع از پایگاه‌داده‌های با تطابق کلیدها و مقادیر کار می‌کنند، چیزی شبیه dictionary. هیچ چیزی به عنوان ساختار یا رابطه وجود ندارد. پس از اتصال به پایگاه داده (مانند Redis)، یک برنامه می‌تواند یک کلید را عنوان کند (مانند the_answer_to_life) و یک مقدار متناسب (مثلا ۴۲) را دریافت کند. سیستم‌های مدیریت پایگاه‌داده‌های مبتنی بر مقدار-کلید بطور معمول برای ذخیره‌ی سریع داده‌های اولیه به کار می‌روند. آن‌ها بسیار کارا، موثر و معمولا بسط پذیرند.

نکته: وقتی صحبت از دیکشنری در دنیای کامپیوتر می‌شود، منظور دسته‌ای خاص از اشیاء داده است که از آرایه‌ای از کلکسیون‌ها با کلیدهای مجزا تشکیل شده اند و هر کلید، با یک مقدار تطابق دارد.

برای سیستم‌های مدیریت پایگاه‌داده‌های NoSQL مبتنی بر کلید-مقدار می‌توان موارد زیر را معرفی نمود:

• Redis: درون حافظه اصلی قرار می‌گیرد و امکان ماندگار بودن در حافظه را نیز دارد.
• Riak: قابلیت بسط‌پذیری بالا، و قابلیت چند نسخه‌سازی
• Memcached / MemcacheDB: قابلیت بسط‌پذیری

موارد مناسب جهت استفاده:

• caching: سرعت ذخیره بالا، و گاهی تکراری داده‌ها و با هدف استفاده در آینده نزدیک
• در صف قرار دادن: برخی از سیستم‌ها مانند Redis از لیست‌ها، دسته‌ها و صف‌ها و… پشتیبانی می‌کنند.
• توزیع عملیات و اطلاعات: می‌توانند جهت پیاده‌سازی الگوی معماری Publish-Subscribe موثر باشند.
• نگهداری از اطلاعات زنده: برنامه‌هایی که نیازمند نگهداری از «حالت» (state) هستند، می‌توانند از این سیستم‌ها استفاده کنند.

۲) مبتنی بر ستون:

سیستم‌های مدیریت پایگاه‌های داده مبتنی بر ستون، بر اساس قدرتمندسازی همان طبیعت کلید-مقدار شکل گرفته‌اند. بر خلاف آن تصور عامه در اینترنت که گفته می‌شود یادگیری این پایگاه‌داده‌ها مشکل است، این نوع پایگاه‌داده‌ها به طور خیلی ساده و بر اساس ساخت کلکسون‌هایی از یک یا چند جفت کلید-مقدار کار می‌کنند که با یک رکورد مطابقت دارد. بر خلاف تعاریف قدیمی از قالب (schema) در سیستم‌های رابطه‌ای، یک سیستم مبتنی بر ستون نیازمند جدولی از پیش تعیین شده جهت کار کردن با داده‌ها در آن نیست. هر رکورد با یک یا چند ستون که دربردارنده‌ اطلاعات هستند، ارائه می‌شود و هر ستون از هر رکورد می‌تواند متفاوت باشد.

?

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

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

برای سیستم‌های مدیریت پایگاه‌داده‌های مبتنی بر ستون می‌توان موارد زیر را معرفی نمود:

• Cassandra: مخزن داده مبتنی بر BigTable و DynamoDB
• HBase: مخزن داده سکوی Apache Hadoop، مبتنی بر ایده‌ی BigTable

موارد مناسب جهت استفاده:

• نگهداری از داده‌های ساخت‌نایافته و اطلاعات غیرفرار: اگر دسته‌ای عظیم از مقادیر و صفات نیازمند به نگهداری برای مدت طولانی باشند، این سیستم بسیار کاربردی است.
• بسط‌دهی: این سیستم‌ها به طور ذاتی قابلیت بسط پذیری بسیار بالایی دارند و می‌توانند با مقادیر بسیار بسیار زیادی از اطلاعات سروکار داشته باشند.

۳) مبتنی بر سند:

سیستم مدیریت پایگاه‌داده‌های مبتنی بر سند را می‌توان آخرین دیوانه بازی دانست که توانسته سیل عظیمی از مردم را به استفاده از خود جوگیر کند! این سیستم همانند سیستم مبتنی بر ستون عمل می‌کند، گرچه امکان رسیدن به تودرتوسازی بیشتری را می‌دهد: وجود یک سند در یک سند دیگر، در سند دیگر،…

سندها بر محدودیت یک یا دو سطح از تودرتو سازی سیستم‌های مبتنی بر ستون فائق آمده‌اند. به طور ساده، هر ساختار پیچیده و دلخواه می‌تواند تشکیل یک سند را بدهد و این سند قابلیت ذخیره‌سازی در این سیستم را دارد.

علیرغم ذات قدرتمند قابلیت پرس‌وجو از رکوردها با کلیدهای مختلف، این سیستم مشکلات و افت‌هایی را در مقایسه با بقیه همتایان خود دارد. به عنوان مثال، دریافت یک مقدار از یک رکورد به معنی دریافت مقدار زیاد آن رکورد است. مشابه این سناریو در زمان به‌روزرسانی داده‌ها نیز صادق است. این موارد باعث افت کارایی می‌شوند.

برای سیستم‌های مدیریت پایگاه‌های داده مبتنی بر سند می‌توان موارد زیر را معرفی نمود:

• MongoDB: پایگاه‌داده‌های بسیار پرطرفدار و بسیار کارا
• CouchDB: یک مخزن داده‌ی پیشرو و سنت شکن
• Couchbase: مبتنی بر JSON، قابلیت ذخیره در حافظه اصلی

موارد مناسب جهت استفاده:

• اطلاعات تودرتو: این سیستم‌ها اجازه کار با داده‌های بسیار پیچیده و تودرتو را می‌دهد.
• کار با جاوا اسکریپت: یکی از حیاتی‌ترین کارکردهای این نوع سیستم‌ها، روشی است که در آن با برنامه‌های جاوا اسکریپتی روبرو می‌شوند، مثلا استفاده از قالب JSON مناسب برای جاوا اسکریپت!

۴) مبتنی بر گراف:

در نهایت، می‌توان به سیستم جذاب مدیریت پایگاه‌داده‌های مبتنی بر گراف اشاره کرد. این سیستم‌ها داده‌ها را به شکلی کاملا متفاوت از سه مدل قبلی که به آن اشاره شد، ارائه می‌کنند. آن‌ها ساختار درختی را همانند آنچه که در گراف‌ها هست ارائه می‌کنند، با راس‌ها و یال‌هایی که به وسیله‌ی رابطه‌ها به یکدیگر متصل هستند.

مشابه تصویری ریاضی گراف‌ها و به لطف طبیعت گراف‌ها (مانند اتصال و دسته‌بندی اطلاعات مرتبط با هم)، برخی از عملیات خاص در این سیستم‌ها، بسیار ساده‌تر صورت می‌پذیرند. (مانند ارتباط آدم‌ها)

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

برای سیستم‌های مدیریت پایگاه‌داده‌های مبتنی بر گراف می‌توان موارد زیر را معرفی نمود:

• OrientDB: یک پایگاه‌داده‌های ترکیبی NoSQL از گراف و سند و بسیار سریع که با جاوا نوشته شده و قابلیت کار در مدل‌های کاری مختلف را دارد.
• Neo4J: پایگاه‌داده‌های بسیار پر طرفدار و قدرتمند مبتنی بر جاوا

موارد مناسب جهت استفاده:

• سروکار داشتن با داده‌های رابطه‌ای پیچیده: همان طور که گفته شد، این سیستم برای کار با ساختارهای پیچیده و رابطه‌ای بسیار موثر و راحت است. مانند ارتباط بین دو موجودیت و هر درجه از ارتباط بین موجودیت‌هایی که به طور غیر مستقیم با یک موجودیت رابطه دارند.
• مدل سازی و سروکار داشتن با موجودیت‌های دسته‌بندی شده: این سیستم‌ها در هر زمینه‌ای که مفهوم روابط انسانی مطرح است، برتری دارند. دسته‌بندی اطلاعات بر طبق روابط انسانی می‌توانند به طور خیلی خوبی توسط این سیستم‌های انبار داده صورت گیرند.

منابع:

https://slmd.ir/lr

https://slmd.ir/ls

https://slmd.ir/lt

https://slmd.ir/lu

https://slmd.ir/lv