آشنایی با مدل های مدیریت داده ها

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

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

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

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

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

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

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

• پیمایش بین داده ها از طریق روال های جداگانه:

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

• نقص encapsulation :

یکی از پایه های مفهوم شیی گرایی است. از آنجا که با اجرای query می توان به داده های درون یک شی درون پایگاه داده ها دست یافت، می توان این طور گفت که پایگاه داده ها شی گرا، مفهوم شی گرایی را به طور کامل پشتیبانی نمی کنند. گاهی اوقات نقض این encapsu ation ضروری است. به عنوان مثال نیازمند داده ای از یک شی داده هستیم که متد آن پیاده سازی نشده است و دستیابی به این مقدار، تنها یک بار صورت میگیرد. در واقع منطقی نیست که برای دستیابی به این مقدار بخواهیم یک متد جدا درون شی داده ای درون پایگاه داده ها بنویسیم. بنابراین همواره یک مصالحه بین نقض encapsulation و نوشتن متدهای بیشتر برای اشیاء داده وجود دارد.

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

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

شرکتهای توسعه دهنده و پشتیبان ایده پایگاه های داده شی گرا متوجه تکرار اشتباه خود شدند. اولین اشتباه آنها نزدیک کردن بیش از حد طراحی پایگاه داده ها به طراحی برنامه ها بود. آنها دوباره فهمیدند که این نزدیک شدن با معماری چند لایه توسعه نرم افزارها که باعث انعطاف در توسعه نرم افزارها می شود تناقض دارد. آنها همچنین دوباره فهمیدند که استفاده از زبانهای اخباری مانند SQL-۹۲چنان بهره وری را بالا میبرد که شرکتهای توسعه دهنده نرم افزار ترجیح میدهند که به جای درگیری با مفاهیم جدید، هزینه تامین منابع سخت افزاری را پرداخت کنند؛ به عبارتی شما همواره می توانید سخت افزار بخرید، اما زمان را هرگز! آنها همچنین دوباره فهمیدند که استاندارد نبودن یک مدل داده ای منجر به خطا در طراحی و بروز ناسازگاری در داده ها می شود. نگهداری از یک سیستم مدیریت پایگاه های داده شی گرا کاری بسیار سخت بود.

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

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

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

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

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

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

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

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

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

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

• ساختار و نوع داده نگهداری شـونده:

در سیستم رابطه ای، نیازمند یک ساختار از صفات برای نگهداری داده ها هستیم بر خلاف NoSQL که معمولا اجباری را تحمیل نمی کند.

• پرس و جو:

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

• بسط پذیری:

هر دو این راهکارها قابل رشد به صورت عمودی هستند. (مثلا افزایش منابع سیستم) هرچند با پیشرفت و ساده تر شدن برنامه ها، راهکارهای NoSQL ابزارهای راحت تری را در جهت رشد افقی ارائه می کنند (مثلا ساختن یک cluster از چندین ماشین)

قابلیت اتکا : هنگامی که مساله ی قابلیت اطمینان در داده ها و تضمین تراکنش های انجام شده مطرح باشد، همچنان بهتر است بر روی پایگاه های داده های رابطه ای شرط ببندید

• پشتیبانی:

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

• داده های پیچیده و نیاز به نگهداری و پرس وجو:

به طور ذاتی، پایگاه داده های رابطه ای از منطق goto جهت پرس وجوهای پیچیده و برآورده نمودن نیاز نگهداری از داده ها استفاده می کنند که در این حوزه پیشرو بودہ و بسیار موثرترند

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

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

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

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

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

مبتنی بر کلید – مقدار:

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

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

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

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

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

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

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

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

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

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

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

مبتنی برسند:

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

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

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

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

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

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

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

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

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

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