فناوری NoSQL اولین مرتبه توسط شرکت های پیشگام اینترنتی نظیر گوگل ، فیسبوک ، آمازون و LinkedIn و به منظور غلبه بر محدودیت های بانک های اطلاعاتی رابطه ای با قدمتی بیش از 40 سال  ، مطرح گردید. بانک های اطلاعاتی NoSQL برای ذخیره و بازیابی داده تابع یک مدل متفاوت نسبت به بانک های اطلاعاتی رابطه ای می باشند که همه چیز را در جداول و ارتباط بین آنها تعریف می نمایند ( روابط جدولی ). در اغلب موارد تفسیر واژه NoSQL معادل Not-only-SQL در نظر گرفته می شود تا تاکیدی باشد بر این موضوع که اینگونه بانک های اطلاعاتی ممکن است از زبان های شبه SQL برای query حمایت نمایند . اکثر بانک های اطلاعاتی NoSQL با هدف ذخیره سازی حجم بسیار بالایی از داده و همچنین مقاوم در برابر خطاء ، طراحی شده اند .
بر اساس پیش بینی موسسه تحقیقاتی گارتنر تا سال 2017 ، تمامی پیشگامان ارایه دهنده سیستم های مدیریت بانک های اطلاعاتی ، اقدام به ارایه  یک پلت فرم جامع جهت مدیریت بانک های اطلاعاتی می نمایند که مدل های داده مختلفی نظیر مدل های رابطه ای و NoSQL را شامل می شود .همچنین ، پیش بینی شده است که تا سال 2017 استفاده از واژه NoSQL به عنوان معیاری جهت تشخیص سیستم های مدیریت بانک اطلاعاتی بسیار کم رنگ خواهد شد .  از منظر گارتنر ، یک سیستم نرم افزاری کامل که قادر به تعریف ، ایجاد ، مدیریت ، بهنگام سازی و اجرای query بر روی یک بانک اطلاعاتی باشد ، یک سیستم مدیریت بانک اطلاعاتی است . شکل 1 ، جایگاه تولید کنندگان سیستم های مدیریت بانک اطلاعاتی عملیاتی را نشان می دهد که حضور شرکت های عرضه کننده محصولات NoSQL (  نظیر Couchbase  ، MongoDB ) در آن قابل توجه است .


با این که فناوری ها ، نوع های داده و کاربرد هر یک از اعضاء خانواده بزرگ NoSQL متفاوت است ولی می توان با صرفنظر کردن از برخی موارد خاص اینگونه بانک های اطلاعاتی را به چهار نوع مختلف Key-value stores ، Graph stores ، Column stores و Document stores تقسیم کرد . در بخش های گذشته با سه الگوی  معماری داده  Key-value  ، Graph  و Column family آشنا شدیم . در این بخش با Document stores آشنا خواهیم شد .
بانک های اطلاعاتی Document stores ،رکوردها را در قالب document ذخیره می کنند . یک document را می توان به عنوان گروهی از زوج های key-value تصور کرد . کلیدها همواره رشته می باشند و مقادیر می توانند رشته ، عدد ، مقادیر منطقی ، آرایه ها و یا سایر زوج های تودرتو key-value باشند. مقادیر می توانند تا هر عمق دلخواهی به صورت تودرتو تعریف گردند . در یک بانک اطلاعاتی document ، هر document  مدل توصیفی مختص به خود را دارد .درست بر خلاف یک بانک اطلاعاتی رابطه ای که هر سطری در یک جدول بخصوص ، می بایست دارای ستون های مشابه باشد .CouchDB ، Couchbase و MongoDB سه محصول شناخته شده از بانک های اطلاعاتی Document stores می باشند .
 
 مروری سریع بر الگوی معماری داده Document store
بحث ما بر روی الگوهای معماری داده NoSQL بدون پرداختن به یکی از عمومی ترین ، انعطاف پذیرترین و قدرتمندترین الگوها یعنی Document store تکمیل نمی گردد . پس از مطالعه این بخش ، یک دید شفاف نسبت به این الگوی معماری داده پیدا خواهیم کرد تا بتوان به کمک آن بسیاری از مسایل کسب و کار را حل کرد. همانگونه که در بخش های قبل اشاره گردید ، Key-value و Column stores پس از ارایه کلید به عنوان ورودی ، حجم بالایی از داده مرتبط با کلید را برمی گردانند .
 Key-value store و Bigtable values دارای فقدان یک ساختار رسمی می باشند و در عمل از ایندکسینگ و یا قابلیت های جستجو استفاده نمی کنند. Document stores چنین وضعیتی را ندارند و دقیقا در نقطه مقابل دو مدل فوق کار می کند : کلید ممکن است یک شناسه  ساده باشد که هرگز استفاده و یا دیده نمی شود. ولی امکان بازیابی تقریبا هر آیتمی از درون یک document store از طریق یک query بر روی مقدار و یا محتویات وجود دارد. مثلا اگر یک query را بر روی 500 سند مرتبط با 'کشور ایران' اجراء کینم و به دنبال مستنداتی باشیم  که در آنها به  ' استان خوزستان'  اشاره شده باشد ، ماحصل اجرای query ، برگرداندن لیستی از مستنداتی است که حاوی کلمه اشاره شده است .
Document stores ،  از یک ساختار درختی که با یک گره ریشه شروع می شود و دارای شاخه هایی است که هر یک می توانند دارای شاخه های دیگری باشند، استفاده می نماید.مقادیر داده  معمولا به عنوان برگ های یک درخت ذخیره می گردند.به موازات اضافه کردن یک سند جدید درون Document store ، برای هر آیتم ذخیره شده درون آن به صورت  اتوماتیک ایندکس ایجاد می گردد. این بدان معنی است که با آگاهی از هر خصلت document ،می توان به سرعت تمامی سندهایی که دارای خصلت مشابه باشند را پیدا کرد. Document stores ، می تواند به شما نه تنها این موضوع را بگوید که آیا آیتم جستجو در document وجود دارد ، بلکه این توانمندی را نیز دارد که مکان واقعی آیتم را با استفاده از document path در اختیار شما قرار دهد .documet path در واقع یک نوع کلید است که به کمک آن امکان دستیابی به برگ های یک ساختار درختی فراهم می شود . شکل 2 ، نحوه استفاده از یک ساختار درختی در Document stores را نشان می دهد


حتی اگر ساختار یک سند پیچیده باشد، فرآیند جستجو در document store می تواند با بکارگیری رابط برنامه نویسی (API ) ساده باشد. ساختار فوق ، روشی ساده برای انتخاب یک سند و یا زیرمجموعه ای از آن را ارایه می نماید . یک Key-value store قادر به ذخیره تمامی سند در بخش مقدار است ولی یک document store قادر به استخراج بخش های جانبی تعداد زیادی از اسناد بدون بارگذاری هر سند درون حافظه است . در صورتی که قصد نمایش یک پاراگراف بخصوص از یک کتاب را داشته باشیم ، لازم نیست تمامی کتاب را درون حافظه مستقر کرد .
در ادامه ، کار خود را با تصور document store به صورت یک ساختار درختی همراه با ریشه ها ، شاخه ها و برگ ها دنبال خواهیم کرد و در مرحله بعد به سراغ این موضوع خواهیم رفت که چگونه برنامه ها می توانند از مفاهیم document store و document store API استفاده می کنند و در نهایت نمونه مثال هایی در خصوص استفاده از document store را بررسی خواهیم کرد .

 اصول اولیه الگوی معماری داده document store  
 یک document store را می توان به عنوان یک ساختار شبه درخت همانگونه که در شکل 2 نشان داده شده است ، تصور کرد . درخت ، شامل یک عنصر ریشه ( یا برخی اوقات چندین عنصر ریشه ) است . در بخش زیرین عنصر ریشه ، دنباله ای از شاخه ها ، زیرشاخه ها و مقادیر قرار دارند . هر شاخه دارای یک مسیر خاص است که نشان می دهد چگونه می توان از ریشه درخت به هر شاخه دلخواه ، زیر شاخه و یا مقدار حرکت کرد . هر شاخه ممکن است دارای یک مقدار مرتبط با آن شاخه باشد. برخی مواقع ، وجود یک شاخه در درخت دارای معنی خاصی است و در برخی موارد دیگر یک شاخه می بایست دارای مقداری باشد که به درستی تفسیر گردد .

Document collections
در مقابل ذخیره داده در سطرها و ستون ها در یک جدول ، داده در سندهایی ذخیره می گردد و این سندها در قالب کالکش هایی گروه بندی می شوند . هر سند می تواند دارای یک ساختار کاملا متفاوت باشد . اکثر document stores ، مستندات را در گروه هایی با نام کالکشن گروه بندی می کنند . شکل 3 ، تفاوت مدل داده رابطه ای با مدل داده مبتنی بر Document را نشان می دهد .


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

Application collections
در برخی حالات ، از کالکشن در یک document store به عنوان یک چارچوب برای ارایه یک پکیج برنامه وب استفاده می شود . قالب پکیج ، یک فایل xar نامیده می شود و مشابه فایل JAR و یا WAR بر روی سرویس دهنده جاوا است . برنامه های پکیج می توانند علاوه بر داده ، شامل اسکریپت ها نیز باشند. استفاده از ساختارهای کالکشن برای ذخیره پکیچ های نرم افزاری این موضوع را نشان می دهد که یک document store می تواند به عنوان یک قالب برای ذخیره عناصر با قابلیت استفاده مجدد سطح بالا که قادر به اجرا بر روی چندین سیستم NoSQL باشند ، نیز مورد استفاده قرار گیرند.

 Document store APIs
هر document store دارای یک API و یا query language است که مسیر هر گره و یا گروهی از گره ها را مشخص می کند . در حالت کلی ، لازم نیست گره ها دارای اسامی منحصربفرد باشند در مقابل ، می توان از یک عدد مکان یاب جهت مشخص کردن هر گره دلخواه در درخت استفاده کرد. مثلا ، برای انتخاب هفتمین فرد در لیست افراد ، می توان این query را اجراء کرد . [Person[7 . شکل 4 ، نحوه استفاده از یک document path به عنوان کلیدی برای استخراج مقدار ذخیره شده در یک سلول بخصوص یک سند را نشان می دهد .


در شکل 4 ، با انتخاب مجموعه ای از رکوردهای افراد که دارای شناسه 20020 می باشند، کار را شروع می کنیم . اغلب این شناسه به یک شخص اشاره خواهد داشت . در ادامه ، نگاهی خواهیم داشت به رکورد بخش آدرس و متن را از نام خیابان انتخاب می کنیم . مسیر کامل جهت دسترسی به نام خیابان در ذیل شکل 4 نشان داده شده است .

 پیاده سازی Document store
 یک document store با گونه های مختلفی ارایه می شود . برخی بر اساس درخت های شی سریالی ساده و برخی پیچیده تر بوده و شامل محتویاتی می باشند که ممکن است از طریق متن های علامت گذاری شده در صفحات وب پیدا شوند. ساختارهای سند ساده تر اغلب با اشیاء سریالی مرتبط می باشند که ممکن است از فرمت JSON ( برگرفته شده از JavaScript Object Notation ) استفاده کنند. JSON این امکان را فراهم می آورد که بتوان در عمق درگیر ساختارهای درختی شد ولی از ذخیره و query خصلت های خاصی نظیر bold, italic و یا هایپرلینک حمایت نمی کند .

مثال : یک سرویس دهنده تبلیغاتی با MongoDB 
اولین دلیل حضور MongoDB به عنوان یک محصول NoSQL ، ایجاد سرویسی بود تا بتوان به سرعت یک بنر تبلیغاتی را بر روی یک صفحه وب برای میلیون ها کاربر در یک لحظه ارسال کرد .هدف اولیه ، انتخاب سریع تبلیغات مناسب برای یک کاربر خاص و قراردادن آن بر روی صفحه در زمان بارگذاری توسط کاربر است . سرویس دهنده تبلیغاتی می بایست هر روز 24 ساعت و هفت روز هفته بدون بروز مشکل بتواند سرویس خود را ارایه نماید. آنها از قواعد پیچیده کسب و کار به منظور یافتن مناسب ترین تبلیغ و ارسال آن برای یک صفحه وب استفاده می کنند . تبلیغات از یک بانک اطلاعاتی دریافت می شوند که متناسب با علایق هر شخص سازماندهی شده اند. میلیون ها تبلیغات این ظرفیت را دارند که بتوانند با علایق کاربر مطابقت نمایند . سرویس دهنده تبلیغاتی نمی تواند تبلیغ مشابهی را بطور تکراری برای افراد ارسال کند و می بایست قادر به ارسال تبلیغات در یک ناحیه خاص بر روی صفحه و با یک اولویت بخصوص باشد . در نهایت ، سیستم به گزارشات صحیح نیاز دارد تا نشان دهد که چه تبلیغاتی برای کدام کاربر ارسال شده است و کاربر بر روی کدام تبلیغ کلیک کرده است. این مساله کسب و کار نشان داد که نمی توان از RDBMS استفاده کرد چراکه هم پیچیده است و هم نیازمند ارسال داده به صورت real time است . MongoDB ثابت کرد که می تواند تمامی خواسته های موجود دراین زمینه را پاسخگو باشد . MongoDB دارای امکاناتی از قبیل پارتیش بندی اتوماتیک ، تکرار ، load balancing ، file storage و تجمیع داده است . به همین منظور از ساختار document store برای پیشگری از افت عملکرد استفاده گردید . از MongoDB در موارد متعددی می توان استفاده کرد:

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

شکل 5 ، نحوه پیاده سازی جدول Users یک بانک اطلاعاتی رابطه ای را با MongoDB نشان می دهد . جدول به یک collection ،  هر سطر در جدول SQL به یک document و هر ستون به یک فیلد در MongoDB تبدیل شده است .


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