الگوهای جدید معماری بانک های اطلاعاتی NoSQL چه چیزی هستند و این نوع بانک های اطلاعاتی قرار است پاسخگوی چه نوع مسائلی باشند ؟ چگونه می توان با توجه به نوع نیاز و ماهیت مساله از یک الگوی مناسب NoSQL استفاده کرد ؟ سعی خواهیم کرد در این مطلب و سایر مطالبی که در آینده منتشر خواهد شد ، ضمن پاسخ گویی به این قبیل سوالات به صورت اصولی با الگوهای جدید معماری بانک های اطلاعاتی آشنا شویم .
بانک های اطلاعاتی از گذشته تا کنون
از گذشته تاکنون شاهد سه دوران مختلف در عرصه بانک های اطلاعاتی بوده ایم . شکل ۱ ، این دوره های مختلف را نشان می دهد.از سیستم های مدیریت بانک های اطلاعاتی رابطه ای (RDBMS ) برای تراکنش ها و از بانک های اطلاعاتی تحلیلی ( Analytics) برای انبار داده استفاده می گردد . NoSQL قرار است پاسخ گوی چه نیازهایی باشد و یا ما با چه کمبودی در عرصه ذخیره و بازیابی اطلاعات مواجه شده بودیم که ضرورت وجود یک الگوی معماری جدید بانک اطلاعاتی احساس گردید.
شکل ۱ : دوره های مختلف بانک های اطلاعاتی
شکل ۲ ، وضعیت قبل از NoSQL را نشان می دهد .
شکل ۲ : وضعیت بانک های اطلاعاتی قبل از NoSQL
به دنبال تحولات عظیم در عرصه فناوری اطلاعات از یک طرف و همچنین تغییرات عمده در نیازهای کسب و کار، معماری مبتنی بر تک گره RDBMS با چالش های متعددی روبرو گردید . در شکل ۳ به برخی از این چالش ها اشاره شده است .
با توجه به موارد اشاره شده ، از سال ۲۰۱۰ به بعد نیاز به یک الگوی جدید معماری در عرصه بانک های اطلاعاتی به شدت احساس گردید . ظهور NoSQL پاسخی به این نیاز بود . شکل ۴ ، وضعیت بعد از NoSQL را نشان می دهد.
درادامه با الگوهای مختلف معماری داده NoSQL آشنا خواهیم شد .
الگوهای معماری داده NoSQL
در این بخش کار خود را با بررسی ساده ترین نوع معماری داده NoSQL که به آن key-value می گویند شروع خواهیم کرد و در بخش های بعد به بررسی سایر الگوها خواهیم پرداخت . خواهیم دید که چگونه می توان از این الگوی مقرون به صرفه برای حل مسایل کسب و کار متعددی استفاده کرد. در ادامه به بررسی موارد زیر خواهیم پرداخت :
- Key-value store چیست ؟
- مزایای استفاده از key-value store
- نحوه استفاده ازkey-value store
- بررسی یک نمونه مثال کاربردی از نحوه استفاده key-value store
Key-value store چیست ؟
Key-value store یک بانک اطلاعاتی ساده است که با ارایه یک رشته ساده به عنوان کلید، می تواند حجم بالایی از داده ( value ) را برگرداند.ساختار ذخیره سازی فوق دارای یک زبان پرس و جو (query ) نمی باشد و از یک روش خاص جهت اضافه کردن و یا حدف زوج کلید- مقدار استفاده می نماید .یک key-value store را می توان مشابه یک واژه نامه در نظر گرفت که دارای لیستی از کلمات است و هر کلمه دارای یک و یا چندین تعریف است. یک واژه نامه ساده در شکل ۵ نشان داده شده است .
واژه نامه یک key-value store ساده است که کلمات key و تعاریف value می باشند . پس از ذخیره واژه ها در واژه نامه به صورت الفبایی ، امکان بازیابی سریع آنها فراهم می شود و لازم نیست برای واژه ای که به دنبال معنی آن هستیم ، تمامی واژه نامه را جستجو کرد .همانند واژه نامه ، یک key-value store توسط key ، ایندکس گذاری می شود . Key مستقمیا به value اشاره می کند. ماحصل این کار بازیابی سریع اطلاعات (values ) ، صرف نظر از تعداد واژه های ذخیره شده است . یکی از مزایای عدم مشخص کردن نوع داده در یک key-value store ، امکان ذخیره سازی هر نوع داده در value است . سیستم ، اطلاعات را به عنوان یک BLOB ذخیره می نماید و زمانی که از دستور GET جهت بازیابی استفاده می گردد ، BLOB مشابه برگردانده می شود . این به عهده برنامه است که مشخص سازد چه نوع داده یی استفاده شده است : یک رشته ، فایل xml و یا binary image .
BLOB از کلمات Binary Large Object اقتباس شده است و نشان دهنده مجموعه ای از داده باینری ذخیره شده به عنوان یک entry در یک سیستم مدیریت بانک اطلاعاتی است که معمولا شامل متن ، تصاویر ، صدا و سایر اشیاء چند رسانه ای است.
کلید( Key ) در یک key-value store ، انعطاف پذیر بوده و می تواند با قالب های مختلفی همچون اسامی مسیر منطقی به تصاویر و یا فایل ها ، رشته های تولید شده هوشمند از مقدار هش شده ، فراخوانی سرویس وبREST و یا SQL queries ارایه شود . مقادیر(Value) نیز نظیر کلیدها ، دارای انعطاف لازم بوده و می توانند شامل هر نوع BLOB داده نظیر تصاویر ، صفحات وب ، مستندات و ویدیوها باشد. شکل ۶ ، نمونه ای از یک key-value store متداول را نشان می دهد .
مزایای استفاده از یک Key-value store
سادگی ، بکارگیری آسان و متعاقب آن عمومیت key-value store باعث صرفه جویی در وقت و هزینه های جانبی می گردد و شاید همین دلایل باعث شده باشد که ضریب نفوذ استفاده از این نوع ساختار ذخیره سازی به شدت رشد پیدا نماید. بدیهی است در چنین مواردی ، در مقابل تمرکز بر روی طراحی معماری می توان بر روی مواردی جهت کاهش هزینه سرویس های داده نظیر ارتقاء سطح خدمات ، مانیتورینگ سرویس ها و اطلاع رسانی ، مقیاس پذیری و قابلیت اطمینان و قابلیت حمل و کاهش هزینه های عملیاتی متمرکز گردید.
نحوه استفاده از Key-value store
چگونه پیاده کنندگان یک برنامه می توانند از یک key-value store درون برنامه استفاده کنند ؟ بهترین روش برای تصور این که چگونه یک key-value store مقادیر را ذخیره می کند ، در نظر گرفتن آن به عنوان جدولی با دو ستون است . اولین ستون Key و دومین ستون value است . سه عملیات را می توان در ارتباط با key-value store تعریف کرد : put , get و delete . دستورات فوق ، اینترفیس مورد نیاز برنامه نویسان جهت کار با Key-value store را ارایه می نماید که به آن API ( برگرفته شده از Application Program Interface ) گفته می شود . در شکل ۷ اینترفیس فوق نشان داده شده است .
در مقابل استفاده از یک query language ، پیاده کنندگان برنامه با بکارگیری put , get و delete قادر به دستیابی و عملیات بر روی یک key-value store می باشند . علاوه بر دستورات فوق، یک key-value store دارای دو قانون کلی زیر است:
- Distinct keys: نمی توان دارای دو سطر با key-value مشابه بود. این بدان معنی است که تمامی کلیدها در key- value store منحصربفرد می باشند.در صورتی که به صورت منحصربفرد یک زوج key-value را مشخص و شناسائی نکنیم ، نمی توان یک مقدار را به عنوان نتیجه کار برگرداند .
- No queries on values: نمی توان بر روی مقادیر موجود در جدول query اجراء کرد. اگر صرفا متمرکز بر روی بانک های اطلاعاتی رابطه ای تمرکز نماییم ، لازم است توضیحات بیشتری در این خصوص داده شود.در یک بانک اطلاعاتی رابطه ای ، می توان با استفاده از where clause محدودیت هایی را در خصوص برگرداندن نتایج حاصل از اجرای یک query اعمال کرد . در صورتی که در یک key-value store ماحصل اجرای query ،برگرداندن یک آیتم خواهد بود .نمی توان یک زوج key-value را با استفاده از value انتخاب کرد . Key-value store این مساله را با ایندکسینگ در لایه برنامه برطرف می نماید. این کار اجازه می دهد ، key-value دارای یک ساختار ساده و انعطاف پذیر باشد .
پس از آشنایی با مزایا و نحوه استفاده از key-value store ، به بررسی یک نمونه مثال کاربردی خواهیم پرداخت . هدف این مثال ، ذخیره صفحات وب در یک key-value store است و نشان می دهد که چگونه یک موتور جستجو نظیر گوگل تمامی وب سایت ها را در یک key-value store ذخیره می کند.
مثال : ذخیره صفحات وب در یک Key-value store
گوگل از ابزاری به نام web crawler برای مشاهده اتوماتیک یک وب سایت ، استخراج و ذخیره سازی محتویات هر یک از صفحات وب استفاده می کند. در ادامه ، کلمات موجود در هر صفحه وب به منظور جستجوی سریع کلمات ، ایندکس گذاری می گردند . زمانی که از یک مرورگر وب استفاده می کنیم معمولا آدرس یک وب سایت را به صورت http:// www.example.com/hello.html وارد می نماییم . این URL ، کلید یک وب سایت و یا یک صفحه وب را مشخص می کند . می توان وب را به صورت یک جدول بزرگ با دو ستون(کلید ، مقدار) در نظر گرفت . شکل ۸ ، نحوه ذخیره محتویات صفحات یک وب سایت به کمک key-value store را نشان می دهد .
URL ، کلید است و value محتویات صفحه وب در آن آدرس را مشخص می کند. اگر تمامی صفحات وب را در یک سیستم key-value store ذخیره نماییم دارای میلیاردها و یا تریلیون ها زوج key-value خواهیم بود . هر کلید می بایست منحصربفرد باشد همانند یک URL به یک صفحه وب که منحصربفرد است . قابلیت استفاده از URL به عنوان یک کلید به شما اجازه ذخیره تمامی اجزاء استاتیک و غیرتغییر وب سایت را در یک key-value store می دهد . این عناصر شامل تصاویر ، صفحات HTML استاتیک ، فایل های CSS و کد جاوااسکریپت می باشند . تعداد زیادی از وب سایت ها از رویکرد فوق استفاده می کنند و تنها بخش های پویای یک وب سایت را که توسط اسکریپت ها تولید می شوند در key-value store ذخیره نمی کنند .
Berkley DB ، Memcache ، DynamoDB ، S3 ، Redis و Riak نمونه هایی از بکارگیری الگوی معماری Key-value می باشند.حال با Graph store یکی دیگر از الگوهای معماری فناوری NoSQL، آشنا خواهیم شد.
هدف اصلی این بخش ، آشنایی با ویژگی های یک Graph store ، نحوه استفاده از Graph store به منظور حل مسایل کسب و کار ، آشنایی با واژه ها و اصطلاحات گراف نظیر گره ها ، روابط ، خصلت و در نهایت کاربرد Graph store در عمل است .
رد پای گراف در علم کامپیوتر
علم کامپیوتر ارتباط بسیار نزدیکی با علم ریاضی دارد و بسیاری از مفاهیم آن ریشه در ریاضیات دارد . الگوریتم ها ، رمزنگاری ، محاسبات و حتی تئوری های پایه منطق ریاضی و جبر بولی از جمله مفاهیم ریاضی می باشند که دارای جایگاه برجسته ای در دنیای کامپیوتر می باشند . یکی دیگر از موضوعات مهم ریاضی که می توان حضور فعال و جدی آن را در بسیاری از کتاب ها و مقالات کامپیوتری مشاهده کرد ، تئوری گراف است . در علم کامپیوتر ، از گراف جهت ارایه ساختارهای داده خاص نظیر سلسله مراتب سازمانی ، شبکه های اجتماعی ، جریان های کاری و … استفاده می شود .
تاکنون از گراف در ابعاد گسترده ای در زمان ایجاد فرآیندهای نرم افزار استفاده شده است ولی این روند در حال تغییر است و بسیاری از پیاده کنندگان تمایل دارند ضمن فراموش کردن گذشته ، با نگاهی نو و این مرتبه در جهت نگهداری داده به آن توجه نمایند . ما تاکنون نهایت سعی خود را داشته ایم که داده را درون جداول و ستون های بانک های اطلاعاتی رابطه ای قرار دهیم و در ادامه ساختار آن را نرمالیزه و یا از حالت نرمالیزه خارج کنیم تا به چیزی که در عمل می خواهیم ، دست یابیم .
بانک های اطلاعاتی گراف از مدل گراف جهت ذخیره داده استفاده می نمایند . در این مدل ، ساختار گراف شامل رئوس و یال ها ( به عنوان دو موجودیت مهم مدل سازی هر نوع گراف ) مدل سازی می گردد .علاوه بر این ، می توان از تمامی الگوریتم های موجود تئوری گراف ( با توجه به قدمت طولانی آن ) برای حل مسائل گراف با کارآیی بیشتر و در زمان کمتر نسبت به بانک های اطلاعاتی رابطه ای استفاده کرد. Neo4j ، نمونه ای از یک بانک اطلاعاتی گراف است که به کمک آن می توان مسایل گراف را با کارآیی بهتر و ظرافت بیشتر حل کرد .Neo4j دارای جایگاهی برجسته در خانواده بزرگ NoSQL است .
شکل ۹ ، یک نمونه ساختار گراف جهت ذخیره سازی داده کاربران به همراه دوستان هر یک را نشان می دهد .
مروری بر Graph store
الگوی معماری داده Graph stores در برنامه هایی که نیازمند تحلیل روابط بین اشیاء و یا مشاهده تمامی گره ها در یک گراف می باشند، حائز اهمیت است. معماری فوق برای ذخیره موثر گره های گراف و ارتباطات بهینه بسیار کارساز است و می توان بر روی یک گراف query مورد نظر خود را اجراء کرد . این نوع بانک های اطلاعاتی برای هر نوع مساله کسب و کار که دارای ارتباطاتی پیچیده بین اشیاء می باشند ، مفید است . شبکه های اجتماعی ، موتورهای مبتنی بر قواعد ، ایجاد mashups و تحلیل ساختارهای پیچیده شبکه نمونه هایی از کاربرد الگوی معماری داده Graph store می باشند .
Graph store ، سیستمی است که شامل دنباله ای از گره ها و ارتباطات است که با ترکیب آنها با یکدیگر یک گراف ایجاد می گردد. همانگونه که در بالا اشاره گردید، معماری داده key-value store شامل دو فیلد key و value است . در مقابل ، در یک Graph store از سه فیلد اساسی داده با نام گره ، روابط و خصلت استفاده می شود. به برخی از گراف ها به دلیل ساختار node-relationship-node ، اصطلاحا triple stores گفته می شود شکل ۱۰ ، ماهیت یک بانک اطلاعاتی گراف را نشان می دهد .
زمانی که دارای آیتم های زیادی می باشیم که با یکدیگر روابط پیچیده ای دارند و هر یک نیز دارای خصلت های مختص به خود می باشند، استفاده از Graph stores بسیار مناسب است . در Graph store امکان اجرای query ساده وجود دارد و می توان به عنوان نمونه نزدیک ترین همسایه و یا الگوی خاصی را پیدا کرد . مثلا اگر از یک بانک اطلاعاتی رابطه ای برای ذخیره لیستی از دوستان خود استفاده کرده باشید ، می توان لیست مرتب شده ای بر اساس نام خانوادگی از دوستان خود را تولید و در خروجی نمایش داد . در صورت استفاده از graph store ، نه تنها می توان لیستی از دوستان خود را بر اساس نام خانوادگی پیدا کرد ، همچنین می توان لیستی از دوستان خود را که علاقه مند به مطالعه کتاب های علمی می باشند نیز پیدا کرد . Graph stores ، صرفا به این موضوع اکتفاء نمی کند که به شما بگوید بین دو گره یک رابطه وجود دارد بلکه قادر به ارایه گزارشات تکمیلی همراه با جزییات مورد نیاز در خصوص هر یک از روابط موجود است.
گره های گراف معمولا بیانگر اشیاء دنیای واقعی نظیر اسامی می باشند . گره ها می توانند افراد ، سازمان ها ، شماره تلفن ، صفحات وب ، کامپیوترهای موجود بر روی یک شبکه و یا حتی سلول های بیولوژیکی در یک ارگانیزم زنده باشند . ارتباطات را می توان به منزله اتصالات بین اشیاء درنظر گرفت که معمولا به صورت کمان در دیاگرام ها نشان داده می شوند . اجرای یک query بر روی یک گراف ، مشابه حرکت کردن بین گره ها در یک گراف است . به عنوان نمونه می توان با اجرای یک query به درخواست هایی مشابه زیر پاسخ داد:
- کوتاهترین مسیر بین دو گره موجود در گراف چیست ؟
- چه گره ای دارای همسایگانی با خصلت های خاصی است ؟
- با دادن دو گره در گراف ، تا چه میزان همسایگان آن به هم شبیه هستند ؟
- متوسط ارتباطات بین نقاط مختلف گراف با یکدیگر چه میزان است ؟
همانگونه که قبلا اشاره گردید ، در سیستم های مدیریت بانک اطلاعاتی رابطه ای (RDBMS ) از اعداد به عنوان کلید اصلی و خارجی برای ارتباط سطرها در جداولی که در بخش های مختلف یک هارد دیسک ذخیره شده اند ، استفاده می گردد . انجام عملیاتی نظیر Join در RDBMS دارای هزینه بالایی است و علاوه بر تاخیر در انجام عملیات ، I/O زیادی را نیز به دنبال خواهد داشت. Graph store ، گره ها را با یکدیگر مرتبط می نماید و متوجه این موضوع می شود که دو گره با شناسه یکسان ،گره های مشابه هستند . Graph stores به گره ها شناسه های داخلی را نسبت می دهد و از این شناسه ها برای Join شبکه ها به یکدیگر استفاده می کند. بر خلاف RBDMS ، در Graph stores عملیات Join سبک تر بوده و کار با سرعت به مراتب بیشتری انجام می شود . علت این کار به ماهیت کوچک هر گره و قابلیت نگهداری گراف در RAM برمی گردد . این بدان معنی است که گراف درون حافظه بارگذاری می شود و بازیابی داده نیازمند عملیات I/O نمی باشد .
برخلاف سایر الگوهای NoSQL ، مقیاس پذیری Graph stores بر روی چندین سرویس دهنده دارای چالش های مختص به خود است . در چنین مواردی . می توان داده را بر روی چندین سرویس دهنده تکرار کرد تا امکان خواندن و کارآیی اجرای query بهتر گردد . ولی نوشتن بر روی چندین سرویس دهنده و اجرای query بر روی گرافی که گره های آن بین چندین سرویس دهنده توزیع شده اند دارای پیچیدگی ها مختص به خود است .
با این که Graph stores بر اساس واقعیت ساختار داده node-relationship-node ایجاد می گردد ولی می تواند دارای پیچیدگی های مختص به خود باشد و حتی در برخی موارد ناسازگار به نظر آید . روش تعامل با Graph stores مشابه سایر بانک های اطلاعاتی است : داده بارگذاری می گردد ، query بر روی آن اجرا می شود و در صورت لزوم داده بهنگام و یا حذف می گردد. تفاوت به نوع query استفاده شده برمی گردد . یک query گراف ، مجموعه ای از گره های مورد نیاز برای ایجاد یک graph image و نمایش ارتباطات بین داده را برمی گرداند .
واژه ها و اصطلاحات Graph store
اجازه دهید ، نگاهی داشته باشیم به اصطلاحات مختلفی که از آنها جهت تشریح نوع های مختلف گراف استفاده می گردد. همانگونه که در صفحات وب مشاهده کرده اید ، لینک های موجود بر روی یک صفحه وب شما را به سمت صفحه دیگر هدایت می کنند. این لینک ها می توانند توسط یک گراف نمایش داده شوند . صفحه وب موجود اولین و یا گره مبداء است . لینک ، کمانی است که به صفحه دوم اشاره می کند و دومین صفحه مقصد ، گره دوم است. در این مثال ، اولین گره توسط URL صفحه مبداء نشان داده می شود و دومین گره و یا مقصد ، URL صفحه مقصد است . این فرآیند ارتباطی بین صفحات ، می تواند در مکان های مختلفی بر روی وب مشاهده شود. شکل ۱۱ ، یک نمونه Graph store شامل یک صفحه وب و ارتباط آن به دو صفحه وب را نشان می دهد.
شکل ۱۲ ، نحوه پیاده سازی گراف برای ارایه یک صفحه وب به همراه لینک به دو صفحه دیگر را نشان می دهد .
همانگونه که در شکل ۱۲ ملاحظه می شود، URL صفحه وب مبداء به عنوان یک Property URL ذخیره شده است و هر لینک ، بیانگر یک رابطه است که دارای خصلتی با نام : “points to ” است .هر لینک از طریق خصلت فوق به URL صفحه مقصد اشاره می کند . .مفهوم استفاده از URLs برای شناسایی گره ها جذاب است ، چراکه توسط انسان قابل خواندن است و ساختاری درون URL را ارایه می نماید. W3C این ساختار را به منظور ذخیره اطلاعات لینک های بین صفحات (همانند لینک بین اشیاء درون یک RDF برگرفته شده از Resource Description Format که در واقع یک مدل داده متادیتا می باشد) ، استاندارد کرده است.
مثال
در این بخش به کاربرد Graph store به منظور حل دو نمونه از مسایل کسب و کار اشاره ای مختصر خواهیم داشت .
- Link analysis: زمانی استفاده می شود که قصد جستجو و یافتن الگوها و ارتباطاتی را در مواردی نظیر شبکه های اجتماعی ، تلفن و یا رکوردهای ایمیل داشته باشیم.
- Integrating Linked data: به منظور کار با حجم بالایی از داده لینک شده باز (open Linked data) برای یکپارچه سازی بلادرنگ و ایجاد mashup بدون ذخیره داده استفاده می شود. Mashup ، یک صفحه وب و یا یک برنامه وب است که محتویات خود را از بیش از یک منبع دریافت و یک سرویس جدید را در قالب یک اینترفیس گرافیکی ارایه می نماید. مثلا می توان با ترکیب آدرس ها و تصاویر شعب یک شرکت بزرگ به همراه google map ، یک map mashup را ایجاد کرد.
Link analysis
در برخی موارد ، پیمایش داده گراف بهترین روش برای حل یک مساله کسب و کار است . به عنوان نمونه می توان به شبکه های اجتماعی اشاره کرد . شکل ۱۳ ، نمونه ای از یک شبکه اجتماعی را نشان می دهد . در این شکل هر فرد به صورت یک دایره مشخص شده است و بین دو فرد در صورت وجود ارتباط ، یک لینک برقرار شده است.هر یک از افراد با توجه به تعداد ارتباطات با سایر افراد بر روی گراف نشان داده شده اند . در شکل فوق، وضعیت ارتباطی یک کاربر نسبت به همکاران سابق خود در شرکت یاهو( رنگ سبز) و تحلیل گران گوگل ( رنگ صورتی ) مشخص شده است . همچنین ، وضعیت ارتباط وی با سایر همکاران و دوستان در شبکه اجتماعی LinkedIn ( رنگ آبی ) و هم کلاسی ها در دانشگاه کارنگی ملون( رنگ نارنجی) مشخص شده است .
به موازات این که به لیست دوستان خود افراد جدیدی را اضافه می کنید ، ممکن است به دنبال این موضوع باشید که آیا دوست مشترکی بین شما وجود دارد . در ابتدا لازم است ، لیستی از دوستان خود را داشته باشد و برای هر یک از آنها که در لیست شما می باشند ، لیست دوستان آنها را داشته باشید (friends-to-friends ) . فرض کنید بخواهیم چنین کاری را توسط یک بانک اطلاعاتی رابطه ای انجام دهیم ، پس از اولین مرحله ، کارآیی سیستم به شدت افت پیدا خواهد کرد . انجام این نوع تحلیل ها به کمک یک سیستم مدیریت بانک اطلاعاتی رابطه ای می تواند خیلی کند باشد. در شبکه های اجتماعی ، شما می توانید جدولی با نام friends برای هر شخص با سه ستون ID نفر اول و ID نفر دوم و نوع ارتباط بین آنها ( خانوادگی ، دبیرستانی و … ) بسازید . در ادامه می توان ، بر روی دو فیلد نفر اول و نفر دوم ایندکس ایجاد کرد تا یک RDBMS بتواند به سرعت لیست دوستان شما و لیست دوستان دوستان شما را در اختیار شما قرار دهد. ولی اگر بخواهیم به سراغ سطح بعدی برویم یک query دیگر لازم است . به موازات این که کار ساخت ارتباطات را ادامه می دهیم ، اندازه query نیز به سرعت رشد پیدا می کند. اگر ما دارای ۱۰۰ دوست باشیم و هر یک دارای ۱۰۰ دوست باشد ، query از نوع friends-of-friends و یا سطح دوم دوستان ، ۰۰۰ ، ۱۰ ( ۱۰۰ * ۱۰۰ ) سطر را برمی گرداند . همانگونه که حدس زده اید، انجام این نوع query در SQL پیچیده است . Graph stores این نوع عملیات را به مراتب سریعتر و با استفاده از روش هایی که عملیات ادغام و حذف گره های ناخواسته از حافظه را به دنبال دارد ، انجام می دهد. Graph stores دارای شفافیت و سرعت به مراتب بیشتری جهت انجام کارهایی نظیر تحلیل لینک ها است. آنها معمولا به حافظه RAM مناسبی نیاز دارند تا بتوانند تمامی لینک ها را در زمان تحلیل در حافظه نگهداری نمایند .
استفاده از گراف ها برای پردازش datasets عمومی
از Graph stores می توان جهت تحلیل داده یی که توسط سازمان شما تولید نشده است نیز استفاده کرد . فرض کنید بخواهیم بر روی سه dataset مختلف که توسط سه سازمان مختلف تولید شده اند ، کار کنیم . این سازمان ها حتی ممکن است از وجود هم باخبر نباشند. شما چطور می توان dataset آنها را بطور اتوماتیک Join کرد تا اطلاعات مورد نیاز خود را کسب کرد ؟ استفاده از ابزارهایی که به آنها Linked open data یا LOD می گویند یکی از روش های موثر در این رابطه است . می توان LOD را به منزله یک روش یکپارچه سازی برای Join بین datasets مختلف جهت ایجاد برنامه های جدید در نظر گرفت . استراتژی های LOD برای هر فردی که کار تحقیقات و یا تحلیل را با استفاده از datasets عمومی انجام می دهد بسیار حائز اهیمت است . این تحقیقات می تواند شامل مواردی نظیر هدف گذاری بر روی مشتریان خاصی ، تجزیه و تحلیل رویکرد بازار ، تجزیه و تحلیل احساسات ، تحلیل متون و یا ایجاد سرویس های جدید اطلاعات باشد. ترکیب مجدد داده به اشکال جدید ، فرصت هایی را برای کسب و کارهای جدید فراهم می کند.به موازات رشد LOD ، فرصت های جدیدی برای سرمایه گذاری کسب و کار جدید فراهم می گردد که با ترکیب و غنی سازی این نوع اطلاعات محقق می گردد . با ادغام LOD ، مجموعه داده های جدیدی از طریق ترکیب اطلاعات دو و یا چندین dataset عمومی در دسترس ایجاد می گردد که دارای ساختار LOD نظیر RDF و URI می باشند. در شکل ۱۴ ، نمونه هایی از سایت های LOD متداول که به آن دیاگرام LOD Cloud می گویند نشان داده شده است .
در مرکز دیاگرام ابری LOD ، سایت هایی وجود دارد که دارای تعداد زیادی dataset همه منظوره هستند .این سایت ها شامل هاب سایت های LOD نظیر DBPedia و یا Freebase می باشند . DBPedia ، وب سایتی است که تلاش می کند با برداشت حقایق از ویکی پدیا آنها را به RDF تبدیل کند. در واقع DBpedia ماحصل یک تلاش گروهی با هدف استخراج اطلاعات از ویکی پدیا و ارایه آنها در وب با یک ساختار مشخص جهت اجرای query مورد نظر است . پس از یافتن سایتی که حاوی اطلاعات RDF است ، می توان به دو صورت مختلف آن را پردازش کرد :
- دانلود تمامی فایل های داده RDF از سایت و بارگذاری آنها درون Graph store . برای مجموعه های بزرگ RDF نظیر DBPedia که شامل میلیاردها ارتباط است این روش در عمل غیر ممکن است .
- روش دوم که دارای کارآیی بیشتری است ، یافتن یک سرویس وب برای سایت RDF است که به آن SPARQL endpoint می گویند. این گونه سرویس های وب ، امکان اجرای SPARQL را فراهم می نمایند . SPARQL ، یک زبان Query مبتنی بر RDF است که از آن برای بازیابی و پردازش داده ذخیره شده با قالب RDF استفاده می گردد.
به طور کلی، در Graph stores به عنوان دومین الگوی معماری داده NoSQL ، داده در مجموعه ای از گره ها ، روابط و خصلت ها ذخیره می شود. اجرای یک query بر روی یک Graph strore و پیمایش آن از مهمترین عملیات بر روی یک گراف است . این الگوی معماری داده در مواردی که روابط بین داده بسیار حیاتی می باشند ، مناسب است . سرعت بالای جستجو ، کار با مجموعه داده لینک شده عمومی از مزایای مهم این مدل محسوب می گردد. از معایب این مدل می توان به قابلیت اندک مقیاس پذیری آن اشاره کرد . این وضعیت زمانی محقق می شود که نتوان گراف را در حافظه RAM مستقر کرد .
Neo4J , AllegroGraph , Bigdata triple store , InfinitGraph و StartDog نمونه هایی از بانک های اطلاعاتی مبتنی بر گراف می باشند که می توان از آنها جهت ایجاد الگوی معماری داده گراف NoSQL استفاده کرد .
مروری سریع بر الگوی معماری داده Column family
سیستم های Column family یکی از الگوهای مهم معماری داده NoSQL می باشند چراکه می توان از آنها برای مدیریت حجم بسیار بالایی از داده استفاده کرد .در سیستم های فوق از شناسه های سطر و ستون به عنوان کلیدهای همه منظوره جهت جستجوی داده استفاده می گردد . از واژه data store در مقابل database استفاده می شود چراکه این نوع منابع ذخیره سازی داده ، فاقد ویژگی هایی مشابه با بانک های اطلاعاتی سنتی می باشند . مثلا ، این نوع منابع ذخیره سازی داده دارای ستون هایی با نوع های مشخص شده ، ایندکس های ثانویه ، trigger و زبان query نمی باشند . تقریبا تمامی سیستم های مبتنی بر الگوی معماری داده فوق به نوعی در ارتباط با مقاله Bigtable گوگل می باشند . به عنوان نمونه ، گرچه نحوه پیاده سازی Hbase, Hypertable و Cassandra با یکدیگر متفاوت است ولی همگی آنها دارای اینترفیس هایی مشابه با Bigtable می باشند.
معماری فوق ارتباط نزدیکی با بسیاری از سیستم های MapReduce دارد . MapReduce ، چارچوبی است که از آن برای انجام پردازش موازی بر روی مجموعه های بزرگ داده و در بین چندین کامپیوتر (گره) استفاده می گردد. در فریمورک MapReduce ، عملیات map دارای یک گره master است که وظیفه آن شکست یک عملیات به چندین قسمت و توزیع هر عملیات به گره دیگر برای پردازش است . عملیات Reduce، فرآیندی است که در آن گره master اقدام به جمع آوری نتایج از سایر گره ها و ترکیب آنها با یکدیگر با هدف پاسخ به مساله تعریف شده است. به دلیل اهمیت MapReduce در اینگونه الگوهای معماری داده در ادامه بطور مختصر اشاره ای به آن خواهیم داشت .
MapReduce چیست ؟
MapReduce ، یک الگوی برنامه نویسی است که امکان مقیاس پذیری گسترده را در بین صدها یا هزاران سرویس دهنده در یک کلاستر ( به عنوان نمونه کلاستر هدوپ ) فراهم می نماید . واژه فوق به دو فعالیت مجزا و جداگانه اشاره دارد . اولین فعالیت map نامیده می شود و وظیفه آن دریافت مجموعه ای داده و تبدیل آن به مجموعه ای دیگر از داده است ( تبدیل عناصر منحصربفرد به زوج های کلید -مقدار ) . وظیفه reduce ، دریافت خروجی یک map به عنوان ورودی و ترکیب گروهی از زوج های کلید – مقدار به گروه های کوچک تر است . همانگونه که از نام MapReduce مشخص است ، همواره فرآیند reduce بعد از فرآیند map انجام می شود . در ادامه با بررسی یک مثال ساده ، سعی خواهیم کرد با مفاهیم کلیدی مدل برنامه نویسی MapReduce بیشتر آشنا شویم.
مثال : فرض کنید بخواهیم تعداد تکرار هر کلمه را در یک فایل ورودی محاسبه نماییم . برای انجام این کار مراحل زیر را می بایست دنبال کرد.
- داده ورودی به تعدادی رکورد تقسیم می شود .
- تابع map، بر روی رکوردهای ایجاد شده در مرجله قبل پردازش لازم را انجام داده و برای هر کلمه موجود در رکورد، زوج کلید – مقدار را تولید می نماید .
- تمامی زوج های کلید – مقدار که خروجی تابع map می باشند ، با یکدیگر ترکیب شده و بر اساس یک کلید گروه بندی و مرتب می گردند .
- نتایج میانی به تابع reduce ارسال می شوند تا خروجی نهایی را تولید نماید .
مراحل کلی برنامه MapReduce فوق در شکل ۱۶ نشان داده شده است .
اصول اولیه الگوی معماری داده Column family
به عنوان اولین نمونه از نحوه استفاده سطرها و ستون ها به عنوان یک کلید ، می توان به صفحات گسترده ( spreadsheet ) اشاره کرد.گرچه اکثر ما صفحات گسترده را به عنوان یک فناوری NoSQL در نظر نمی گیریم ، ولی یک روش ایده آل برای تصور این موضوع هستند که چگونه می توان کلیدها را با بیش از یک مقدار ایجاد کرد . شکل ۱۷ ، یک صفحه گسترده را با یک سلول در سطر ۳ و ستون ۲ ( ستون B ) که حاوی کلمه ‘فابک’ است ، نشان می دهد. سلول دارای آدرس ۳B است و می توان آن را به عنوان کلید جستجو در یک سیستم ماتریس Sparse در نظر گرفت .
در یک صفحه گسترده می توان از تلفیق شناسه های سطر و ستون جهت بازیابی مقدار ذخیره شده در یک سلول بخصوص استفاده کرد . مثلا ستون سوم در سطر دوم توسط کلید C2 شناسایی می شود. در مقایسه با key-value store که دارای یک کلید تک برای شناسایی مقدار است ، یک صفحه گسترده دارای شناسه های سطر و ستون است که با ترکیب آنها کلید دستیابی به یک سلول ایجاد می گردد . همانند key-value store می توان آیتم های مختلفی را در یک سلول قرار داد.یک سلول می تواند شامل داده ، فرمول و یا حتی یک تصویر باشد. وضعیت آدرس دهی در یک صفحه گسترده جهت دستیابی به یک سلول بخصوص در شکل ۱۸ نشان داده شده است.
این مفهوم دقیقا مشابه سیستم های column family است . هر آیتم داده را می توان با آگاهی از شناسه های سطر و ستون آن پیدا کرد و همانند یک صفحه گسترده می توان داده را در هر سلول درج کرد . برخلاف یک سیستم مدیریت بانک اطلاعاتی رابطه ای (RDBMS ) مجبور نیستیم که داده را برای تمامی ستون های یک سطر درج کنیم .
آشنایی با کلیدها
تا این جای کار ما با مفهوم کلیدهای ترکیبی جهت دستیابی به یک داده بخصوص آشنا شدیم . فرض کنید به صفحه گسترده دو فیلد column family و timestamp را اضافه کنیم . ساختارکلید در column family stores مشابه یک صفحه گسترده است با این تفاوت که دارای دو خصلت اضافه دیگر است .علاوه بر نام ستون ، از یک Column family جهت گروه بندی اسامی ستون مشابه استفاده شده است . اضافه کردن یک timestamp در کلید ، این امکان را فراهم می نماید تا بتوان چندین نسخه از یک مقدار را در طول زمان در هر یک از سلول ها ذخیره کرد. . کلید نشان داده شده در شکل ۱۹ ، نمونه ای از column stores است .
برخلاف ، صفحه گسترده معمولی که ممکن است دارای ۱۰۰ سطر و ستون باشد ، column family store برای حجم بسیار بالایی از داده طراحی شده است . سیستم هایی با میلیاردها سطر و صدها یا هزاران ستون!
به عنوان نمونه یک برنامه GIS ( برگرفته شده از Geographic Information System ) نظیر Google Earth ممکن است از یک شناسنه سطر ( Row ID ) به عنوان طول جغرافیایی یک نقشه و از نام ستون به عنوان عرض جغرافیایی استفاده نماید . مثلا در یک نقشه برای هر مایل مربع ، می توان از ۱۵۰۰۰ شناسه سطر و ۱۵۰۰۰ شناسه ستون استفاده کرد . در صورت پیاده سازی یک سیستم GIS به کمک یک صفحه گسترده ، مشاهده می شود که تعداد اندکی از سلول ها حاوی داده می باشند .چیزی که این پیاده سازی را غیرمعمول می سازد این است که صرفا درصد اندکی از سلول ها حاوی اطلاعات می باشند . این نوع پیاده سازی مشابه ماتریس های sparse است که صرفا تعداد محدودی از ستون های آن دارای مقدار می باشند. متاسفانه ، بانک های اطلاعاتی رابطه ای برای ذخیره داده sparse مناسب نمی باشند ولی column stores برای پاسخ به اینگونه اهداف طراحی شده اند. در یک بانک اطلاعاتی رابطه ای ، می توان از یک query ساده برای یافتن تمامی ستون ها در هر جدولی استفاده کرد . در صورت اجرای یک query بر روی sparse matrix ، برای یافتن هر عنصر در بانک اطلاعاتی ، می بایست تمامی اسامی ستون ها را جستجو کرد . جستجوی تمامی ستون ها برای یافتن یک داده بخصوص و یا لیست تمامی داده بر اساس یک شرط خاص می تواند نتایج اغواکننده ای را نیز به دنبال داشته باشد.برای حل این نوع مسایل می توان از مفهوم column family استفاده کرد . به عنوان نمونه می توان ستون ها را به منظور تشریح یک وب سایت ، یک شخص ، یک مکان جغرافیایی و یا محصولات فروش رفته گروه بندی کرد. برای مشاهده این ستون ها با یکدیگر ، آنها را در column family مشابه گروه بندی می کنیم تا امکان بازیابی سریع آنها فراهم شود .
تمامی column family stores از یک column family به عنوان بخشی از کلید خود استفاده نمی کنند. در صورت استفاده ، می بایست آن را در محاسبات خود در زمان ذخیره یک کیلد در نظر گرفت . چراکه column family بخشی از کلید است و بازیابی داده بدون آن میسر نمی باشد.
مزایا و محدودیت های سیستم های column family
رویکرد column family با استفاده از یک شناسه سطر و نام ستون به عنوان یک کلید جستجو ، روشی انعطاف پذیر برای ذخیره داده است که دارای مزایای متعددی نظیر مقیاس پذیری ، در دسترس بودن و عدم از دست دادن زمان در هنگام اضافه کردن داده به سیستم است .با توجه به این که سیستم های Column family متکی به Join نمی باشند ، می توان به خوبی از آنها در سیستم های توزیع شده استفاده کرد . با این که می توان کار پیاده سازی را بر روی یک لپ تاپ شروع کرد ولی در نهایت کار استقرار را می توان بگونه ای پیکربندی کرد که داده را در سه ناحیه جغرافیایی مختلف ذخیره کرد( افزایش قابلیت در دسترس پذیری سیستم ) . سیستم های column family دارای امکانات اتوماتیکی برای برخورد با مشکلات و تشخیص گره های دارای مشکل و الگوریتم هایی برای شناسایی خرابی داده می باشند. Column family بگونه ای پیاده سازی شده است تا بتواند با سیستم فایل های توزیع شده (نظیر Hadoop ) و MapReduce کار کند. لازم است قبل از پیاده سازی به موارد فوق و نکات زیر دقت شود .
- مقیاس پذیری بالا : سیستم های column family به منظور کار با بیش از یک پردازنده طراحی شده اند و همین موضوع قابلیت مقیاس پذیری بالای آنها را نشان می دهد. این بدان معنی است که شما می توانید به هر میزان داده که لازم دارید به سیستم خود اضافه نمایید. در چنین مواردی می توان گره های جدید را به کلاستر محاسباتی اضافه کرد. به موازات رشد داده ، می توان تعداد پردازنده ها را نیز اضافه کرد. دلیل اصلی مقیاس پذیری این روش ، مدل ساده یی است که در آن از شناسه های سطر و اسامی ستون ها به منظور شناسایی یک سلول استفاده می گردد . در واقع با ایجاد و نگهداری یک اینترفیس ساده ، سیستم back end می تواند درخواست ها را بین تعدادی از گره های پردازش بدون انجام عملیات join توزیع نماید و از ترافیک غیرضروری پیشگری و کارآیی سیستم را افزایش دهد.
- در دسترس پذیری بالا : با ایجاد سیستمی که قادر به رشد در طول شبکه های توزیع شده باشد، می توان داده را بر روی چندین گره یک شبکه تکرار کرد . با توجه به این که سیستم های column family از ارتباطات موثر استفاده می نمایند ، هزینه تکرار پائین خواهد بود . علاوه براین ، فقدان عملیات Join اجازه می دهد که بتوان هر بخشی از ماتریس column family را بر روی کامپیوترهای راه دور ذخیره کرد . این بدان معنی است که اگر سرویس دهنده ای که بخشی از ماتریس sparse را ذخیره کرده باشد دچار مشکل گردد ، سایر کامپیوترها آماده ارایه سرویس داده می باشند .
- تسهیل در اضافه کردن داده : یکی از ویژگی های کلیدی Column family همانند key-value stores و Graph stores عدم ضرورت طراحی کامل مدل داده ، قبل از درج داده است .قبل از هر چیز می بایست گروه بندی column family مشخص گردد ولی شناسه های سطرها و اسامی ستون ها را می توان در هر زمانی ایجاد کرد.
علی رغم تمامی مزایای اشاره شده در رابطه با سیستم های Column family، این گونه سیستم ها جهت استفاده بر روی کلاسترهای توزیع شده به کار گرفته می شوند و مناسب بانک های اطلاعاتی کوچک نیستند . معمولا به حداقل پنج پردازنده جهت ایجاد یک کلاستر column family نیاز خواهید داشت.همچنین، سیستم های Column family از SQL query برای دستیابی بلادرنگ به داده استفاده نمی کنند . این گونه سیستم ها دارای یک زبان query در یک سطح بالاتر می باشند . از سیستم های Column family اغلب جهت تولید کارهای دسته ای MapReduce استفاده می شود . جهت دستیابی سریع به داده ، می توان از یک رابط برنامه نویسی سفارشی شده نوشته شده با یک زبان رویه ای نظیرجاوا یا Python استفاده کرد .
مثال ۱ : ذخیره اطلاعات تحلیلی توسط گوگل در BigTable
در مقاله Bigtable شرکت گوگل ، به این موضوع اشاره شده است که چگونه می توان از BigTable برای ذخیره اطلاعات یک وب سایت در Google Analytics استفاده کرد . سرویس Google Analytics این امکان را فراهم می نماید که بتوان ملاقات کنندگان یک وب سایت را پیگیری کرد . هر زمان که کاربری بر روی یک صفحه وب کلیک می نماید ،اطلاعات آن در یک row-column ذخیره می گردد که دارای یک URL و یک timestamp به عنوان row ID است . همانگونه که حدس زده اید ، مشاهده جزئیات لاگ تمامی مشاهدات کاربر بر روی وب سایت می تواند یک فرآیند طولانی باشد. Google Analytics این کار را از طریق خلاصه کردن داده در فواصل زمانی خاص (نظیر یک مرتبه در روز) انجام می دهد. Google Analytics یک نمونه خوب از یک بانک اطلاعاتی بزرگ است که دارای یک رشد خطی است (همزمان با افزایش تعداد کاربران). به موازات این که یک رویداد جدید محقق می شود ، داده جدید بلافاصله به جدول اضافه می شود ، ولو این که یک گزارش در حال اجراء باشد .
داده در Google Analytics نظیر سایر برنامه هایی از نوع logging ، معمولا یک مرتبه نوشته می شوند و هرگز بهنگام نمی شوند . این بدان معنی است که پس از استخراج و خلاصه کردن ، داده اولیه فشرده شده و در یک مکان ذخیره سازی میانی قرار می گیرد تا بایگانی شود . در مواردی که از HBase به عنوان محل ذخیره سازی BigTable استفاده می شود ، لازم است نتایج در HDFS ( برگرفته شده از Hadoop distributed filesystem ) ذخیره گردند و از یک ابزار گزارش گیری نظیر Hadoop Hive برای تولید خلاصه گزارشات استفاده شود . Hadoop Hive دارای یک زبان query است که در بسیاری موارد شبیه SQL کار می کند .
مثال ۲ : ذخیره اطلاعات جعرافیایی گوگل مپ در BigTable
یک نمونه دیگر استفاده از BigTable برای ذخیره حجم بالایی از اطلاعات ، اطلاعات GIS است . سیستم های GIS نظیر Google map اطلاعات نقاط جغرافیایی زمین ، ماه و سایر سیارات را با شناسایی هر مکان با استفاده از مختصات طول و عرض جغرافیایی انجام می دهند . سیستم به کاربران اجازه می دهد بر روی زمین حرکت کرده و بر روی آن زوم نمایند . برای تسهیل کار با سیستم از اینترفیس های گرافیکی سه بعدی استفاده شده است . سیستم های GIS ، آیتم ها را یک مرتبه ذخیره می کنند و امکان دستیابی و مشاهده داده را به کمک مسیرهای مختلف فراهم می نمایند .
با الگوی معماری داده Column family store آشنا شدیم. در این عماری ، کلید دستیابی به اطلاعات از چندین آیتم تشکیل می گردد ( به عنوان نمونه شناسه یک سطر ، column family و نام ستون ) و می توان بر روی هر یک از آیتم های اشاره شده query زد. این نوع بانک های اطلاعاتی قابلیت رشد بسیار خوبی را دارند و قادر به نگهداری چندین نسخه از اطلاعات می باشند. شیوه طراحی سطرها و ستون ها در این مدل بسیار حائز اهمیت است .
Cassandra, HBase, Hypertable, Apache Accumulo و Bigtable نمونه هایی از بانک های NoSQL می باشند که از الگوی معماری داده Column family استفاده می کنند . در بخش بعد به بررسی الگوی معماری داده Document store می پردازیم.
بر اساس پیش بینی موسسه تحقیقاتی گارتنر تا سال ۲۰۱۷ ، تمامی پیشگامان ارایه دهنده سیستم های مدیریت بانک های اطلاعاتی ، اقدام به ارایه یک پلت فرم جامع جهت مدیریت بانک های اطلاعاتی می نمایند که مدل های داده مختلفی نظیر مدل های رابطه ای و NoSQL را شامل می شود .همچنین ، پیش بینی شده است که تا سال ۲۰۱۷ استفاده از واژه NoSQL به عنوان معیاری جهت تشخیص سیستم های مدیریت بانک اطلاعاتی بسیار کم رنگ خواهد شد . از منظر گارتنر ، یک سیستم نرم افزاری کامل که قادر به تعریف ، ایجاد ، مدیریت ، بهنگام سازی و اجرای query بر روی یک بانک اطلاعاتی باشد ، یک سیستم مدیریت بانک اطلاعاتی است . شکل ۲۰ ، جایگاه تولید کنندگان سیستم های مدیریت بانک اطلاعاتی عملیاتی را نشان می دهد که حضور شرکت های عرضه کننده محصولات 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 را بر روی ۵۰۰ سند مرتبط با ‘کشور ایران’ اجراء کینم و به دنبال مستنداتی باشیم که در آنها به ‘ استان خوزستان’ اشاره شده باشد ، ماحصل اجرای query ، برگرداندن لیستی از مستنداتی است که حاوی کلمه اشاره شده است .
Document stores ، از یک ساختار درختی که با یک گره ریشه شروع می شود و دارای شاخه هایی است که هر یک می توانند دارای شاخه های دیگری باشند، استفاده می نماید.مقادیر داده معمولا به عنوان برگ های یک درخت ذخیره می گردند.به موازات اضافه کردن یک سند جدید درون Document store ، برای هر آیتم ذخیره شده درون آن به صورت اتوماتیک ایندکس ایجاد می گردد. این بدان معنی است که با آگاهی از هر خصلت document ،می توان به سرعت تمامی سندهایی که دارای خصلت مشابه باشند را پیدا کرد. Document stores ، می تواند به شما نه تنها این موضوع را بگوید که آیا آیتم جستجو در document وجود دارد ، بلکه این توانمندی را نیز دارد که مکان واقعی آیتم را با استفاده از document path در اختیار شما قرار دهد .documet path در واقع یک نوع کلید است که به کمک آن امکان دستیابی به برگ های یک ساختار درختی فراهم می شود . شکل ۲۱ ، نحوه استفاده از یک ساختار درختی در Document stores را نشان می دهد.
حتی اگر ساختار یک سند پیچیده باشد، فرآیند جستجو در document store می تواند با بکارگیری رابط برنامه نویسی (API ) ساده باشد. ساختار فوق ، روشی ساده برای انتخاب یک سند و یا زیرمجموعه ای از آن را ارایه می نماید . یک Key-value store قادر به ذخیره تمامی سند در بخش مقدار است ولی یک document store قادر به استخراج بخش های جانبی تعداد زیادی از اسناد بدون بارگذاری هر سند درون حافظه است . در صورتی که قصد نمایش یک پاراگراف بخصوص از یک کتاب را داشته باشیم ، لازم نیست تمامی کتاب را درون حافظه مستقر کرد .
در ادامه ، کار خود را با تصور document store به صورت یک ساختار درختی همراه با ریشه ها ، شاخه ها و برگ ها دنبال خواهیم کرد و در مرحله بعد به سراغ این موضوع خواهیم رفت که چگونه برنامه ها می توانند از مفاهیم document store و document store API استفاده می کنند و در نهایت نمونه مثال هایی در خصوص استفاده از document store را بررسی خواهیم کرد .
اصول اولیه الگوی معماری داده document store
یک document store را می توان به عنوان یک ساختار شبه درخت همانگونه که در شکل ۲ نشان داده شده است ، تصور کرد . درخت ، شامل یک عنصر ریشه ( یا برخی اوقات چندین عنصر ریشه ) است . در بخش زیرین عنصر ریشه ، دنباله ای از شاخه ها ، زیرشاخه ها و مقادیر قرار دارند . هر شاخه دارای یک مسیر خاص است که نشان می دهد چگونه می توان از ریشه درخت به هر شاخه دلخواه ، زیر شاخه و یا مقدار حرکت کرد . هر شاخه ممکن است دارای یک مقدار مرتبط با آن شاخه باشد. برخی مواقع ، وجود یک شاخه در درخت دارای معنی خاصی است و در برخی موارد دیگر یک شاخه می بایست دارای مقداری باشد که به درستی تفسیر گردد .
Document collections
در مقابل ذخیره داده در سطرها و ستون ها در یک جدول ، داده در سندهایی ذخیره می گردد و این سندها در قالب کالکش هایی گروه بندی می شوند . هر سند می تواند دارای یک ساختار کاملا متفاوت باشد . اکثر document stores ، مستندات را در گروه هایی با نام کالکشن گروه بندی می کنند . شکل ۲۲ ، تفاوت مدل داده رابطه ای با مدل داده مبتنی بر Document را نشان می دهد .
این کالکشن ها شبیه یک ساختار دایرکتوری می باشند که نظیر آنها را می توان در سیستم فایل ویندوز و یا لینوکس پیدا کرد. از کالکشن ها می توان به روش های مختلفی برای مدیریت حجم بالایی از مستندات استفاده کرد . می توان از آنها به عنوان مکانیزمی برای حرکت در ساختار سلسله مراتبی مستندات ، گروه بندی منطقی مستندات مشابه و ذخیره قواعد کسب و کار نظیر مجوزها ، ایندکس ها و تریگرها استفاده کرد . کالکشن ها می توانند شامل سایر کالکشن ها و درخت ها نیز باشند. کالکش های مستندات را می توان به عنوان کالکشن های برنامه نیز استفاده کرد که چارچوبی برای ذخیره داده ، اسکریپت ها ، views و تبدیلات یک برنامه نرم افزاری را ارایه می نمایند .
Application collections
در برخی حالات ، از کالکشن در یک document store به عنوان یک چارچوب برای ارایه یک پکیج برنامه وب استفاده می شود . قالب پکیج ، یک فایل xar نامیده می شود و مشابه فایل JAR و یا WAR بر روی سرویس دهنده جاوا است . برنامه های پکیج می توانند علاوه بر داده ، شامل اسکریپت ها نیز باشند. استفاده از ساختارهای کالکشن برای ذخیره پکیچ های نرم افزاری این موضوع را نشان می دهد که یک document store می تواند به عنوان یک قالب برای ذخیره عناصر با قابلیت استفاده مجدد سطح بالا که قادر به اجرا بر روی چندین سیستم NoSQL باشند ، نیز مورد استفاده قرار گیرند.
Document store APIs
هر document store دارای یک API و یا query language است که مسیر هر گره و یا گروهی از گره ها را مشخص می کند . در حالت کلی ، لازم نیست گره ها دارای اسامی منحصربفرد باشند در مقابل ، می توان از یک عدد مکان یاب جهت مشخص کردن هر گره دلخواه در درخت استفاده کرد. مثلا ، برای انتخاب هفتمین فرد در لیست افراد ، می توان این query را اجراء کرد . [Person[7 . شکل ۲۳ ، نحوه استفاده از یک document path به عنوان کلیدی برای استخراج مقدار ذخیره شده در یک سلول بخصوص یک سند را نشان می دهد .
در شکل ۲۳ ، با انتخاب مجموعه ای از رکوردهای افراد که دارای شناسه ۲۰۰۲۰ می باشند، کار را شروع می کنیم . اغلب این شناسه به یک شخص اشاره خواهد داشت . در ادامه ، نگاهی خواهیم داشت به رکورد بخش آدرس و متن را از نام خیابان انتخاب می کنیم . مسیر کامل جهت دسترسی به نام خیابان در ذیل شکل ۴ نشان داده شده است .
پیاده سازی Document store
یک document store با گونه های مختلفی ارایه می شود . برخی بر اساس درخت های شی سریالی ساده و برخی پیچیده تر بوده و شامل محتویاتی می باشند که ممکن است از طریق متن های علامت گذاری شده در صفحات وب پیدا شوند. ساختارهای سند ساده تر اغلب با اشیاء سریالی مرتبط می باشند که ممکن است از فرمت JSON ( برگرفته شده از JavaScript Object Notation ) استفاده کنند. JSON این امکان را فراهم می آورد که بتوان در عمق درگیر ساختارهای درختی شد ولی از ذخیره و query خصلت های خاصی نظیر bold, italic و یا هایپرلینک حمایت نمی کند .
مثال : یک سرویس دهنده تبلیغاتی با MongoDB
اولین دلیل حضور MongoDB به عنوان یک محصول NoSQL ، ایجاد سرویسی بود تا بتوان به سرعت یک بنر تبلیغاتی را بر روی یک صفحه وب برای میلیون ها کاربر در یک لحظه ارسال کرد .هدف اولیه ، انتخاب سریع تبلیغات مناسب برای یک کاربر خاص و قراردادن آن بر روی صفحه در زمان بارگذاری توسط کاربر است . سرویس دهنده تبلیغاتی می بایست هر روز ۲۴ ساعت و هفت روز هفته بدون بروز مشکل بتواند سرویس خود را ارایه نماید. آنها از قواعد پیچیده کسب و کار به منظور یافتن مناسب ترین تبلیغ و ارسال آن برای یک صفحه وب استفاده می کنند . تبلیغات از یک بانک اطلاعاتی دریافت می شوند که متناسب با علایق هر شخص سازماندهی شده اند. میلیون ها تبلیغات این ظرفیت را دارند که بتوانند با علایق کاربر مطابقت نمایند . سرویس دهنده تبلیغاتی نمی تواند تبلیغ مشابهی را بطور تکراری برای افراد ارسال کند و می بایست قادر به ارسال تبلیغات در یک ناحیه خاص بر روی صفحه و با یک اولویت بخصوص باشد . در نهایت ، سیستم به گزارشات صحیح نیاز دارد تا نشان دهد که چه تبلیغاتی برای کدام کاربر ارسال شده است و کاربر بر روی کدام تبلیغ کلیک کرده است. این مساله کسب و کار نشان داد که نمی توان از RDBMS استفاده کرد چراکه هم پیچیده است و هم نیازمند ارسال داده به صورت real time است . MongoDB ثابت کرد که می تواند تمامی خواسته های موجود دراین زمینه را پاسخگو باشد . MongoDB دارای امکاناتی از قبیل پارتیش بندی اتوماتیک ، تکرار ، load balancing ، file storage و تجمیع داده است . به همین منظور از ساختار document store برای پیشگری از افت عملکرد استفاده گردید . از MongoDB در موارد متعددی می توان استفاده کرد:
- مدیریت محتوا : ذخیره محتویات وب ، تصاویر و استفاده از ابزارهای لازم جهت ایندکس و یافتن آیتم ها
- عملیات هوشمند real time : به عنوان نمونه مانیتورینگ رسانه های اجتماعی
- مدیریت داده محصول : ذخیره و اجرای query پیچیده بر روی داده محصولات
- مدیریت داده کاربر : ذخیره و اجرای query بر روی داده مرتبط با کاربر در برنامه های بزرگی نظیر بازهای ویدیویی ، برنامه های شبکه های اجتماعی
- تغذیه حجم بالای داده : ذخیره حجم بالایی از داده real time درون یک بانک اطلاعاتی مرکزی برای انجام تحلیل های متمرکز و …
شکل ۲۴ ، نحوه پیاده سازی جدول Users یک بانک اطلاعاتی رابطه ای را با MongoDB نشان می دهد . جدول به یک collection ، هر سطر در جدول SQL به یک document و هر ستون به یک فیلد در MongoDB تبدیل شده است .
