قبل از شروع لازم می دونم تا تعریف کلاسیکی از این بانک اطلاعاتی در قالب دو جمله ارائه بدم؛

تعریف mongodb

بانک اطلاعاتی ای سندگرا که با اهدافی همچون مقیاس پذیری در قبال حجم عظیمی از داده ها و توسعه ی سریع ایجاد شد. طراحی و توسعه ی این پروژه ی متن باز،  توسط شرکت ۱۰gen انجام شده است.

پنج موضوع درباره ی این پروژه متن باز که هر توسعه دهنده ی پی اچ پی (وبی)  باید بداند:

۱) mongodb، یک سرور مستقل

همچون mysql یا هر PostgreSQL دیگری، مونگو دی بی روی پُرت ها جهت دریافت ارتباط های ورودی listen می کند. این بانک اطلاعاتی تمامی ابزار پرس و جو مثل ایجاد، درج، حذف و بروزرسانی را در اختیار شما قرار می دهد. به عبارت دیگر  هر عملی که از یک بانک اطلاعاتی انتظار می رود، mongodb قادر به انجام آن می باشد، منظور همون پروسه ایجاد ارتباط، انجام انواع عملیات و در نهایت قطع ارتباط هست.

۲) خداحافظی با سطر ها و جدول ها

از این پس بجای اینکه داده هاتون رو در جدولها و سطرها ذخیره کنید (همونطورکه اینکار رو در RDBMSها می کردید)، عمل ذخیره سازی شما در قالب اسناد انجام خواهد شد. به عنوان مثال رکوردی که اطلاعات مربوط به یک مقاله را در خود جای داده و دارای فیلدهایی همچون عنوان مقاله، نویسنده های مقاله، محتوا (body) و برچسب های مربوطه می باشد را در نظر بگیرید، شیوه ی دخیره سازی این داده در mongodb بهمراه درایور php به شکل زیر خواهد بود:

								
<?php

 array(

 'title' => 'Hello World',

 'authors' => array('John', 'Sally', 'Jim'),

 'body' => 'Hello world',

 'tags' => array('tag1', 'tag2', 'tag3')

 );

 ?>
									
							

نکته ی قابل توجهی که در مثال بالا دیده میشود این است که این رکورد که در قالب یک آرایه است بصورت یک سند ذخیره شده و مشاهده می کنید که هر فیلدی از آن قادر به پذیرفتن مقادیر چندتایی می باشد و موضوع مهم دیگر اینکه نیازی به نرمالسازی داده ها و نهایتا تجزیه یک جدول به چندین جدول مجزا نیست چراکه در mongodb اصلا جدولی در کار نیست تا با مشکلاتی نظیر افزونگی داده ها(redundancy)، مقادیر تهی(null values) و… مواجه شویم. حالا بجای اینکه ذخیره سازی همین اسناد ما به درون جداول صورت بگیرد، مجموعه یا collectionهایی مورد استفاده قرار می گیرد که ممکن است تصور و حدس همه ما از این کالکشن ها، لیستی از اسناد باشد. خوب اگر حدس شما هم اینچنین بوده، که ایول! درست حدس زدید!

۳) mongodb، با اسکیمایی (schema) کاملا متفاوت

طراحی اسکیما در مونگودی بی بسیار متفاوت از طراحی اسکیما در بانکهای اطلاعاتی رابطه ای است، طراحی اسکیما بعنوان مهمترین و اولین قدم در راستای ایجاد برنامه ی کاربردی مورد نظرمان یک مسئله اجتناب ناپذیر است. در این بانک اطلاعاتی هم طراحی اسکیما، نه تنها تابعی از داده هایی است که قرار است مدل شوند بلکه به use caseهای ما نیز وابسته است. عادت کردن به این مدل متفاوت برای کسانی که مدت طولانی با بانکهای اطلاعاتی رابطه ای و نظام مند سروکار داشته اند، شاید کمی دشوار باشد.

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

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

سوال دیگری که برایمان پیش می آید درمورد تعریف انواع داده ای در این بانک اطلاعاتی است، تعریف داده ها در mongodb بشکل نوع داده ای اجباری سیستم (type coercion system) می باشد. در این نوع تعریف داده ای، شما قرار نیست در کوئری مونگو نوع داده ای خودتان را مشخص کنید، این کار توسط driver یا همان زبانی که قرار است با بانک اطلاعاتی شما تعامل داشته باشد، انجام می شود.

نکته: نوع داده ای اجباری سیستم، تکنیکی است که در آن عمل تبدیل نوع توسط کامپیوتر و بدون دخالت کاربر انجام می شود. این کار بخاطر سازگار کردن داده ها با کد اجرایی موردنظر صورت می گیرد. بعنوان مثال زمانی که داده ی ورودی ما از نوع شناور(float) است و ما نیاز داریم تا خروجی موردنظرمان از نوع صحیح(integer) باشد، این تبدیل نوع انجام می پذیرد.

۴) عدم نیاز شما به یادگیری سایر زبان های پرس و جو

در mongodb نیازی به درگیری با عملیاتی همچون ایجاد لایه های انتزاعی و یا استفاده از لایه ی پیچیده ORM جهت نگاشت به زبانهای شی گرایی نیست و می تونید اونها رو کاملا کنار بگذارید. از طرفی نیاز شما به استفاده از زبان کوئری نویسی مونگو بویژه زمانی که از درایور php این بانک اطلاعاتی استفاده می کنید ، بطور قابل توجهی کاهش پیدا می کند، به این شکل که در بسیاری از موارد شما اطلاعات خود را در قالب آرایه ی php وارد بانک اطلاعاتی مونگو می کنید و آرایه ای از اسناد را تحت عنوان مقدار بازگشتی دریافت می کنید. اما در مورد کوئری های پیچیده هم باید بگم که اگر می خواهید کوئری های بسیار پیچیده ای همچون عملیات map-reduced را اجرا کنید، می توانید از توابع javascript درون مونگودی بی استفاده کنید، اسکریپت های نوشته ی شما توسط موتور داخلی جاوا اسکریپت در مونگو اجرا خواهند شد.

۵) php و mongodb

درحال حاضر php بطور کامل و قدرتمندانه ای از mongodb پشتیبانی می کند، درایور مونگو برای زبان پی اچ پی بصورت اکستنشن PECL موجود و نصب آن بسادگی انجام می شود. این extension پایدار این امکان رو به شما می دهد تا اکثر عملیات معمول کوئری نویسی را بواسطه ی دسترسی به بانک اطلاعاتی mongodb انجام بدید.

به نظرم قبل از شروع کار با مونگو دی بی بهتر بود که این مطالب گفته بشه تا دید بهتر و درک جامع تری از این پروژه متن باز و NoSQL پیدا کنیم، که البته امیدوارم مفید واقع شده باشه! سعی می کنم بزودی پست بعدی رو درباره نصب و راه اندازی mongodb بنویسم تا هرچه زودتر از این حالت تشریفاتی و کلاسیک خارج بشیم.

منابع ۱ ۲

ظهور NoSQL براساس نیاز

موارد زیر دغدغه هایی در عرصه ذخیره و بازیابی اطلاعات بود که موجب ظهور بانک های اطلاعاتی NoSQL شد.

ذخیره سازی داده ها

در حال حاضر  حجم داده های دیجیتالی ذخیره شده دنیا در مقیاس Exabyte است، یک اگزابایت معادل یک میلیارد گیگابایت از داده هاست. طبق آمار وبسایت internet.com، میزان کل داده های ذخیره شده در سال ۲۰۰۶، حدود ۱۶۱ اگزابایت بوده است و تنها بعد از ۴ سال یعنی ۲۰۱۰ میزان این داده های ذخیره شده تقریبا به ۱۰۰۰ اگزابایت رسید، یعنی افزایشی ۵۰۰% داشته اشت. به عبارت دیگر حجم گزافی از داده ها در دنیا همواره در حال ذخیره شدن هستند و همچنان بدون وقفه به رشد خود ادامه می دهد.

پیوستگی داده ها

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

ساختار پیچیده  داده ها

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

NoSQL چیست؟

برای تعریف NoSQL، من فکر می کنم بهتره از این حیث بررسی کنیم که NoSQL چه چیزی نیست؟ یعنی یه جورایی از فرض خلف به مفهومش برسیم. این تکنولوژی، SQL نیست و بصورت رابطه ای هم نیست. همانطور که از نامش پیداست جایگزینی برای مدیریت بانک های اطلاعاتی رابطه ای (RDBMS)  هم نیست، اما آنرا پیاده سازی می کند! NoSQL برای ذخیره سازی داده ها بصورت توزیع شده، جایی که حجم داده های ما در مقیاس بالا باشد، وارد میدان می شود. به عنوان مثال فیسبوک با ۷۰۰,۰۰۰,۰۰۰ کاربرش یا تویتر که متحمل حجم داده ای در مقیاس ترابایت در هر روز می باشد، را در نظر بگیرید.

دنیای کنونی NoSQL به چهار دسته منشعب می شود:

ذخیره به روش مقدار-کلید  اساس این روش در درجه ی اول به آمازون دینامو برمی گردد که در سال ۲۰۰۷ ایجاد شد. ایده ی اصلی این روش از وجود جداول هش نشأت می گیرد، همانطورکه می دانیم در این ساختار یک کلید یکتا و یک اشاره گر داریم که به یک داده ی خاصی اشاره می کند. لازم به ذکر است که در این روش نگاشت معمولا جهت بیشینه کردن کارایی از مکانیزم کش (cache) استفاده می شود.

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

بانک های اطلاعاتی سندگرا که از لوتوس نتز الهام گرفته و عملکرد آن شبیه به روش ذخیره ی مقدار-کلید است. این مدل اساسا مجموعه ای از اسناد اندیس گذاری شده است. این نوع بانک اطلاعاتی اسناد را در فرمت های Yaml، Xml، Json ذخیره می کند.

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

گردانندگان اصلی NOSQL

برخی از پروژه های معتبر بانک های اطلاعاتی NOSQL به شرح زیر می باشند:

Dynamo: دینامو توسط Amazon.com ایجاد شد و برجسته ترین بانک اطلاعاتی NoSQL به روش مقدار-کلید است. شرکت آمازون نیازمند به یک پلتفرم توزیعی مقیاس پذیر بود تا پاسخگوی فعالیت های تجاری آنها در ابعاد بزرگ باشد.

Cassandra: کاساندرا، پروژه ای که توسط شرکت بزرگ فیسبوک بصورت متن باز ارائه شد و در زمره ی بانک های اطلاعاتی NoSQL ستون گرا قرار دارد.

BigTable: بیگ تیبل یک بانک اطلاعاتی ستون گرای که مختص به شرکت گوگل می باشد و این شرکت استفاده از آن را تنها در صورت تعامل با Google App Engine مجاز می داند.

SimpleDB: سیمپل دی بی یکی دیگر از بانک های اطلاعاتی آمازون محسوب می شود.

CouchDB: کوچ دی بی به همراه mongodb پروژه های متن بازی می باشند که بصورت سندگرا عمل می کنند و به سرعت در حال رشد می باشند.

Neo4J:  یک پروژه متن باز که بانک اطلاعاتی گراف گونه محسوب می شود.

روش پرس و جوی NoSQL

چگونگی نوشتن کوئری ها در بانک اطلاعاتی NoSQL سوالی است که همواره برای توسعه دهندگان جالب بوده (البته قبل از رسیدن به پاسخشون!). خوب، بعد از همه ی این صحبت ها، اگر شما نتوانید داده های ذخیره شده ی خام در این بانک های عظیم اطلاعاتی را واکشی کنید و نهایتا آنها را به طریقی در اختیار کاربران نهایی یا سرویسهای وبی قرار بدید، طبیعتا این داده ها به هیچ درد شما نمی خورند. NoSQL همچون SQL، از یک زبان پرس و جوی اعلانی سطح بالا برخوردار نیست. در عوض دارای یک زبان پرس و جوی مدل-داده ای (Data-Model) مشخص می باشد.

نتیجه اینکه سازمان ها یا شرکت هایی که همواره در حال ذخیره سازی حجم عظیمی از داده ها هستند باید نگاهشون رو به NoSQL بطورجدی تری معطوف کنند، چراکه RDBMSها قادر به پردازش اطلاعات در  مقیاس بالا نیستند و البته موضوع فقط به بحث مقیاس پذیری ختم نمی شه، بد نیست این مقاله مفید و خوب رو که درباره ی دردسرهایی که هنگام کارکردن با بانکهای اطلاعاتی SQL (در این مقاله mysql مورد بحث قرار گرفته) ممنکه باهاش مواجه شیم رو مطالعه کنید تا چرایی ظهور NoSQL براتون ملموس تر شه. از طرفی باید این موضوع را در نظر داشته باشیم که  SQL جایگاه خودش را همچنان حفظ خواهد کرد و همواره پاسخگوی نیاز سازمان ها و شرکت های کوچک خواهد بود.

همونطور که بالا هم اشاره شد، در پست بعدی سعی می کنم تا درباره یکی از پروژه های متن باز NoSQL به نام mongodb بنویسم که البته بحث هم فنی تر خواهد شد!

منبع: ۱