واژه ی NoSQL ای که این روزها بیشتر در موردش می شنویم، در سال ۱۹۹۸ پدیدار شد، خیلی ها فکر می کنند این پدیده وجود SQL رو قراره زیر سوال ببره. اما اینطور نیست! NoSQL مخفف عبارت Not Only SQL یا نه تنها اسکیوئل هست، با دیدن این عبارت یه چیزهایی می شه ازش برداشت کرد، اما هدف اصلی این شعار این بوده که این دو تکنولوژی بگونه ای با یکدیگر همزیستی مسالمت آمیز داشته باشند و هرکدوم جایگاه خودشون را حفظ کند. جنبش NoSQL چند سال اخیر همواره در اخبار فن آوری حضور داشته، بطوریکه درمیان بسیاری از بزرگان web2.0  از جایگاه مناسب و محکمی با عنوان تکنولوژی NoSQL برخوردار شده. امروزه شرکت های بزرگی همچون فیس بوک، تویتر، دیگ، آمازون، گوگل و… هر یک به طریقی از این تکنولوژی استفاده می کنند.

ظهور 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 بنویسم که البته بحث هم فنی تر خواهد شد!

منبع: ۱