تاریخچه و تعریف :
اصطلاح NoSQL اولین بار در سال 1998 توسط Carlo Strozzi برای پایگاه‌داده‌های رابطه‌ای‌ای که از زبان SQL استفاده نمی‌کردند به کار رفت . بعدها مجدداً در سال 2009 در اجلاس در San Francisco که مدافعین پایگاه‌داده‌های غیر رابطه‌ای گرد هم آورده بود مورداستفاده قرار گرفت. ازجمله این مدافعین می‌توان به Jon Oskarsson و Eric Evans اشاره نمود. اخیراً NoSQL به معنای "نه‌فقط SQL"(Not Only SQL) به دسته بزرگی از پایگاه‌داده‌ها اطلاق می‌شود که خصوصیات پایگاه‌داده‌های رابطه‌ای را ندارند و برای جستار زدن(query) از زبان توصیفی(declarative language) SQL استفاده نمی‌کنند. ازجمله بارزترین ویژگی‌های این دسته از پایگاه‌داده‌ها می‌توان به موارد زیر اشاره نمود:
• مدل داده غیر رابطه‌ای (Non-relational data model): محدودیت مدل رابطه‌ای در پشتیبانی از ابر داده‌ها(big data) و داده‌هایی با ساختارهای ترکیب‌شده(mixed-structured data) یعنی داده‌های ساخت‌یافته(structured)، نیمه ساخت‌یافته(semi- structured) و غیر ساخت‌یافته(unstructured) یکی از دلایل اصلی معرفی NoSQL بود.
• طراحی‌شده برای محیط‌های توزیع‌شده: جهش‌های صورت گرفته در توسعه معماری کامپیوتر، پردازش‌های توزیع‌شده و موازی(distributed and parallel processing)، محاسبات ابری(cloud computing) و همچنین نیاز به تکرار(replicate) و توزیع(distribute) داده‌ها میان سرویس‌دهنده‌های متعدد؛ نیاز به یک پایگاه‌داده باقابلیت وسعت پذیری افقی( scale horizontally : scale out) را بیش‌ازپیش روشن می‌ساخت. یعنی پایگاهی که به تواند به‌سادگی و ارزانی با افزودن گره‌های جدید به شبکه‌اش توسعه یابد برخلاف پایگاه‌داده‌های رابطه‌ای که تنها به وسعت پذیری عمودی(scale vertically : scale up) یعنی ارتقا کارایی یک تک گره با افزودن به منابع آن یا با فناوری‌های مجازی‌سازی (virtualization technology)اهتمام می‌ورزند.
• واسط سطح فراخوانی ساده‌تر : واسط سطح فراخوانی(CLI : call level interface) یک استاندارد نرم‌افزاری است که می‌گوید چه طور جستارها از سمت برنامه به سمت DBMS ارسال و چه طور مجموعه‌رکورد(record set) به برنامه مجدداً به‌طور سازگاری برگرد. در برنامه‌های شی‌ءگرا و پایگاه‌داده‌های رابطه‌ای لازم بود تا نگاشت شی رابطه (Object/Relational Mapping) صورت پذیرد.
• اهمیت کم‌تر به سازگاری داده‌ها: پایگاه‌داده‌های NoSQL ای از مدل هم‌روندی و تراکنشی ضعیف‌تری نسبت به ACID بهره می‌برند. خصوصیت ACID به معنای اتمیک بودن(atomic)، سازگاری(consistency)، انزوا(isolation) و پایداری(durability) برای تراکنش‌های پایگاه‌داده، همخوانی داده‌ها در بالاترین اولویت خود می‌دانست. پیاده‌سازی این خصوصیت برای پردازش‌های موازی و پاسخگویی سریع به جستارها کار دشواری بود. پس برای پردازش حجم بالایی از داده در یک محیط توزیع‌شده ناچار به تعدیل خصوصیت ACID بودیم که در پایگاه‌داده‌های NoSQL این امر صورت پذیرفته است.
• استفاده کاراتر از شاخص‌ها و حافظه اصلی توزیع‌شده: با استفاده از ساختارهای درون‌حافظه ای(in-memory) می‌توان حجم بالایی از داده‌ها را در حافظه اصلی نهان (cache) نمود و با سرعت بالاتری نسبت به دیسک آنها را واکشی(fetch) کرد.
• شمای منعطف‌تر : بی شمایی(schema-less) یا شمای ضعیف(weak schema) در انبار داده‌ها(data warehouse) یک پیشرفت در جستارهای تحلیلی حرفه‌های فاقد عمومیت(ad-hoc business analytics query) به‌حساب می‌آمد که پایگاه‌داده‌های NoSQL ای نیز بدان توجه وافری داشته‌اند.
تقسیم بندی :
پایگاه های داده NoSQL را می توان بر اساس مدل داده (data model) به چهار دسته تقسیم می شوند:
• پایگاه‌داده جفت کلید مقدار (Key Value Pair) : ایده اصلی این مدل دهه‌ها است که در محاسبات وجود دارد، این یک ساختمان داده معمول است یا مفهومی است در توسعه file system ها به کار گرفته‌شده است [1]. ساختار این مدل از مدل رابطه ای ساده تر و سرعت به جواب رسیدن جستارها نیز بسیار بالاتر است. این مدل برای تغییر(modify)دادن و جستار زدن بر روی کلیداصلی(primary key) حجم سنگینی از داده ها(mass storage) در همزمانی بالا(high concurrency) عملکرد عالی ای از خود نشان می دهد [33]. در این نوع از پایگاه‌داده‌ها، داده به‌صورت جفتی از کلیدها و مقدارها ذخیره می‌گردد. هر یک از کلیدها در گردایه (collection) خود منحصربه‌فرد است. دسترسی به مقادیر به‌وسیله تجمیع (association)کلید-مقدار به دست می‌آید. کلیدها نیازمند آن هستند که در مخزن داده‌ای که قابل‌دسترسی سریع باشند نگهداری گردند شبیه جدول درهم (hash table). نمونه ای از پیاده سازی ها :
Redis
Voldemort(LinkedIn)
Membase
Coherence(Oracle)
Velocity
BigTable(Google)
TokyoCabinet
• پایگاه‌داده‌های گراف(graph database) : پایگاه‌داده‌های گراف بر اساس نظریه گراف‌ها ایجادشده‌اند که شامل گره (node)، یال(edge) و خصوصیات (properties)هستند.بخشی از شهرت شبکه‌های اجتماعی به دلیل احیای تحقیقات پایگاه‌داده‌های گرافی در دهه‌های 80 و 90 بوده است چراکه روابط دوستی و علاقه‌مندی‌های افراد را می‌توان به‌صورت یک گراف متصور شد. نمونه ای از پیاده سازی ها :
Neo4j
InfoGrid
Sesame
BigData
FlockDB
GraphDB
AllegroGraph
DEX
• پایگاه‌داده‌های ستون-فامیل (Column-Family) : پایگاه‌داده‌های ستون-فامیل نوعی از پایگاه‌داده‌های جفت کلید-مقدار هستند. و شامل column،column family و super column هستند. ابرستون ها (super-columns) و ستون فامیل (column family) شمای پایگاه‌داده را تعیین می‌کنند. می‌توان ستون و ابرستون‌های جدیدی نیز به پایگاه‌داده‌ای قبلاً تولید است اضافه نمود. یکی از تفاوت‌های پایگاه‌داده رابطه‌ای با پایگاه‌داده ستون-فامیل این است که سطرهای(row) در پایگاه‌داده ستون فامیلی لزوماً نباید هم‌درجه باشند.یعنی می‌توانند شمار متغیر و متفاوتی از ستون‌ها و ابرستون ها را داشته باشند. ازاین‌رو پایگاه‌داده‌های ستون فامیل در برنامه‌هایی که با گردایه ای از داده‌های پر تهی (spars) کار می‌کنند بسیار کارا هستند. نمونه ای از پیاده سازی ها :
Cassandra(Apache)
Hypertable
HBase
Dynamo
Riak
• پایگاه‌داده سندمحور : از مفهوم جفت کلید-مقدار استفاده می‌کند ولی ساختار خاصی را در ذخیره‌سازی داده شبیه سند مانند XML و JSON اعمال می‌کنند که موجب ذخیره اطلاعات بیش‌تری درباره ساختار خود داده می‌شود که آن را نسبت به ستون-فامیل ها جستار پذیر تر می‌کند چراکه آنجا تنها جستار با یک کلید(key) یا بازه کلید (key range) امکان‌پذیر است[1] . پایگاه‌داده‌های سندمحور با وجود شباهت ساختاری زیاد به پایگاه داده های جفت کلید/مقدار با آن ها دو تفاوت دارند: اول این‌که مقادیر پایگاه‌داده‌های سندمحور معنایی(semantic)هستند و دوم این‌که می توانند از شاخص‌ثانویه نیز استفاده کنند . MangoDB نمونه‌ای از این مدل است که توسط شرکت 10gen توسعه‌یافته است. وقتی از پیاده‌سازی MangoDB پایگاه‌داده‌های NoSQL ای استفاده می‌کنیم خبری از جداول و شماها در پایگاه‌داده نیست. MangoDB در عوض از "گردایه ها" (collection) ها که شبیه جداول هستند و نیز از "اسناد" (documents) که شبیه سطرها هستند برای ذخیره‌سازی داده‌ها و اطلاعات شما (schema information) استفاده می‌کند. MangoDB به‌صورت خودکار برای هر "سند" یک شناسه‌ی کلید اصلی تولید(primary key id) می‌کند تا به‌طور منحصربه‌فرد قابل‌شناسایی باشد. ازلحاظ مفهومی شناسه (id) و سند (document) شبیه جفت کلید‌مقدار (key-value pair)است. MangoDB سعی می‌کند تا داده را بر حافظه نگاه دارد بنابراین دیگر نیاز به بازیابی (retrieve) داده‌های از روی دیسک سخت (hard disk) نیست و زمان کمتری برای جستارها لازم نیاز است. یکی از مشکلات (caveat) زمانی است مجموعه داده بزرگ‌تر از حافظه موجود (available memory) می‌گردد که در این صورت MangoDB مجبور به شروع کردن جستار از روی دیسک سخت خواهد شد. نمونه ای از پیاده سازی ها :
MangoDB(10gen)
CouchDB(Apache)
Riak
eXist
SimpleDB(Amazon)
Terrastore
Lotus Notes
خلاصه شده و برگرفته از مقاله آقای امیرحسین فرمد، چاپ شده در چهارمین کنفرانس بین المللی مدیریت فناوری اطلاعات، ارتباطات و کامپیوتر، http://www.mitc2014.com/fa ، 1393
