استقبال از ديتابيس‌هاي NoSQL مديون توييتر و نت‌فليكس است. از آنجا كه ديتابيس‌هاي رابطه‌اي شناخته‌شده‌تر هستند و راه‌حل‌هاي زيادي براي آنها وجود دارد، هنوز قدرت خود را حفظ كرده‌اند.
طي چند سال اخير، پايگاه‌هاي داده NoSQL توجه زيادي را به‌سوي خود جلب كرده‌اند، كه يكي از دلايل آن، قابليت بي‌نظير اين پايگاه‌هاي داده براي شكوفايي مشاغل تحت وبي است كه نياز به پاسخگويي داده‌هاي در حال رشد كاربران دارند و مي‌تواند از داده‌هاي حجيم بخوبي استفاده كند.
صرف‌نظر از قابليت‌هاي بي‌شمار NoSQL در مشاغلي در حد و اندازه اينترنت، خدمات و محصولاتي كه زيرچتر NoSQL قرار دارند بخوبي مي‌توانند در تمامي سازمان‌ها مورد بررسي قرار بگيرند. البته نه به عنوان جايگزيني براي پايگاه‌هاي داده سنتي، بلكه در پوشش ابزاري اضافه براي رسيدن به اهداف تجاري.
NoSQL به بخش بزرگي از نرم‌افزارهاي ديتابيسي اشاره دارد كه در اصل از رابط SQL استفاده نمي‌كند. چيزي كه اين ديتابيس‌ها را از انواع سنتي جدا مي‌كند، ارتباط اندكي است كه با زبان SQL دارد و بيشتر تفاوت آنها در مدل رابطه‌اي است. به‌طور خاص، اين پايگاه‌هاي داده، شكل ثابتي ندارند و مي‌توانند در نرم‌افزارهايي به‌كار بروند كه نيازمندي‌ها در آنها مدام در حال تغيير است. به‌همين دليل، استفاده از ديتابيس‌هاي غيررابطه‌اي بهتر است.
يكي از بهترين تحليل‌هاي موجود بر فوايد مفاهيم پياده‌سازي ديتابيس‌هاي غيررابطه‌اي، مقاله سال 2007 وب‌سايت آمازون است كه درباره پايگاه داده Dynamo منتشر شد. اين شركت اين پايگاه داده را توسعه داده است تا نيازهاي داخلي خود را رفع كند.
در اين مقاله آمده است كه پايگاه‌هاي داده رابطه‌اي سنتي كه تمركزشان روي اولويت‌گذاري بر داده‌هاست، به نيازهاي زيرساختي آمازون ارتباطي ندارند؛ چرا كه اين شركت از سرورهاي مختلف با حجم‌هاي متفاوت استفاده مي‌كند. براي آمازون، اين كه كاربران براي اين كه محصولي را به سبد خريد خود اضافه كنند بايد مدت زيادي براي همخوان شدن سرورها صبر كنند، بسيار گران تمام مي‌شد ؛ بنابراين داينامو طراحي شد تا پاسخگويي براي نيازهاي اين شركت باشد.
هر چند اندازه زيرساخت آمازون و حجم كاربراني كه از اين وب‌سايت استفاده مي‌كنند، نسبتا منحصر به‌فرد است
(چرا كه آمازون اين قابليت را دارد كه براي خود يك راه‌حل جديد طراحي كند)، اما نياز به اولويت‌بندي بخش‌هايي خاص از نرم‌افزار نسبت به ديگر بخش‌هاي آن در ميان همه سازمان‌ها مشترك است. وجود ديتابيس‌هاي غيررابطه‌اي امروز باعث مي‌شود مشاغل، گزينه‌هاي بيشتري پيش روي خود ببينند و مجبور نباشند از اول همه چيز را بسازند.
چند مدل پايگاه داده غيررابطه‌اي وجود دارد كه همه زير چتر NoSQL جمع مي‌شوند؛ ديتابيس‌هاي كليد مقدار، سند محور، ستوني و گرافي كه هر كدام مدل‌هاي داده، مدل‌هاي بزرگ شدن و موارد استفاده خاص خود را دارند.
قراردادن ديتابيس‌هاي NoSQL در يك شاخه خاص مي‌تواند گيج‌كننده باشد ؛ چرا كه برخي از شاخه‌ها با يكديگر نقاط مشترك بسياري دارند. براي درك كاربردهاي وسيع NoSQL، مي‌توانيد به بخش مراجع مراجعه كرده و ببينيد كه چطور يك نياز در سازمان Sun Microsystems به روش‌هاي كليد مقدار، سند محور و ركوردهاي گسترش‌پذير قابل حل است.
در روش كليدمقدار، ركوردها با مقدار دلخواهي از اطلاعات پر و به وسيله يك كليد انديس‌گذاري مي‌شوند. اين سيستم‌ها عموما خود، داده‌ها را تفسير نمي‌كنند و اين كار را به لايه كاربردي برنامه واگذار مي‌كنند. Riak و Oracle Berkeley DB 2 ديتابيس غيررابطه‌اي هستند كه به اين روش كار مي‌كنند.
در روش سند محور، ركوردها به‌صورت سندهايي ذخيره مي‌شوند كه شامل تعداد متعددي متغير از انواع مختلف هستند (عدد صحيح، رشته و اشيا). ديتابيس‌هاي سندمحور ساختار داده‌اي را كه ذخيره‌كرده‌اند مي‌شناسند و قابليت‌هاي Query بيشتري نسبت به روش كليدمقدار دارند. MongoDB و CouchDB از مثال‌هاي اين شاخه به شمار مي‌روند.
در روش ركوردهاي گسترش‌پذير كه به آن روش ستون‌هاي پهن هم گفته مي‌شود، مدلي شبيه ديتابيس‌هاي رابطه‌اي طراحي شده است، اما داده‌ها در آن به صورت ستون (به‌جاي رديف) و خانواده‌اي از ستون‌ها (به‌جاي جداول) ذخيره مي‌شوند. Cassandra و HBase از مثال‌هاي اين شاخه هستند. در اين پايگاه‌هاي داده به‌جاي آن كه بيشتر نگران اين بود كه چه ديتابيسي چه قابليت‌هايي دارد، چقدر ثبات دارد و در مقابل خطا مقاوم است، بايد به ميزان گسترش‌پذيري آن و اينترفيسي كه در اختيار مي‌گذارد توجه كرد.
بهعنوان مثال، كاساندرا به مديران ديتابيس اجازه مي‌دهد بر مبناي هر كوئري ارسال شده به سيستم، سرعت يا دقت را در نظر بگيرند. براي بالابردن ثبات بتوانند خوشه كاساندرا را طوري طراحي كنند كه دستور تاييد خواندن يا نوشتن تنها زماني ارسال شود كه همه گره‌ها در خوشه پاسخ مثبت داده باشند. براي بالابردن سرعت، سيستم مي‌تواند درست زماني كه اولين گره پاسخ مثبت به نوشتن يا خواندن را ارسال كرد، عمليات را ادامه دهد. مديران همچنين مي‌توانند روش‌هايي را پياده كنند كه در صورت وقوع خطا بتوانند خطا را بسادگي تشخيص دهند و از بين ببرند.
مانگو با به‌كارگيري تكنيك پارتيشن‌بندي خودكار، مي‌تواند خودش را پخش كرده و در بقيه سيستم‌ها بزرگ كند. بهعنوان مثال اگر يك مجموعه داده براي يك سيستم بسيار بزرگ شد، اين ديتابيس مي‌تواند آن را به چند تكه مجزا و در ميان چند گره ديگر تقسيم كند.
مشكل اصلي مديران در به‌كارگيري پايگاه‌هاي داده NoSQL در دسترسي داده‌هاست. به‌دليل تفاوت بسيار ميان اين محصولات، همانند SQL نمي‌توان با كمك يك زبان به جنگ پايگاه‌هاي داده رابطه‌اي رفت. بيشتر ديتابيس‌هاي غيررابطه‌اي از وصله‌هايي استفاده مي‌كنند كه ذخيره داده‌ها را از طريق زبان‌هاي برنامه‌نويسي به انجام برسانند.
البته زبان‌هايي مشابه با SQL براي اين پايگاه‌هاي داده عرضه شده است تا دسترسي با سطح بالاتري به داده‌ها را به‌ارمغان بياورد. از ميان اين زبان‌ها مي‌توان به GQL (گوگل) براي دسترسي به سرويس نرم‌افزاري‌اش، Mongo Query Language و Cassandra Query Language و UnQL اشاره كرد. آپاچي نيز براي سيستم‌هاي Hadoop خود، Apache Pig و Apache Hive را منتشر كرده است كه 2 مسير كاملا متفاوت براي كار با داده در سطح بالا را مهيا مي‌كنند.
شايد يكي از عمومي‌ترين روش‌هاي دسترسي به داده، استفاده از پروژه غيررابطه‌اي جانگو باشد. جانگو فريم‌وركي است كه با زبان پايتون نوشته شده و هدف اصلي آن توليد نرم‌افزارهاي تحت وب با ساختار شي‌ء گراست. اين فريم‌ورك يك لايه انتزاعي ايجاد مي‌كند كه پوشاننده تفاوت‌هاي دسترسي به ديتابيس‌هاي غيررابطه‌اي مختلف است و از AppEngine گوگل، كاساندرا و مانگو پشتيباني مي‌كند.
توسعه‌دهندگان و مديران مي‌توانند با به‌كارگيري اين رابط انتزاعي، قابليت‌هاي ديتابيس‌هاي غيررابطه‌اي مختلف را بررسي و بهترين آنها را انتخاب كنند.
