از گذشته تاکنون شاهد سه دوران مختلف در عرصه بانک های اطلاعاتی بوده ایم. از سیستم های مدیریت بانک های اطلاعاتی رابطه ای (RDBMS ) برای تراکنش ها و از بانک های اطلاعاتی تحلیلی ( Analytics) برای انبار داده استفاده می شود .
این وضعیت تا سال ۲۰۱۰ ادامه بافت . از آن سال به بعد با توجه به تغییرات گسترده در حوزه فناوری اطلاعات از یک طرف و از سویی دیگر تغییرات عمده در نیازهای کسب و کار، فقدان وجود یک ساختار ذخیره و بازیابی دیگر بیش از همیشه احساس گردید. NoSQL ، پاسخی به این کمبود بود . NoSQL قرار است پاسخ گوی چه نیازهایی باشد و یا ما با چه کمبودی در عرصه ذخیره و بازیابی اطلاعات مواجه شده بودیم که ضرورت وجود یک الگوی معماری جدید بانک اطلاعاتی احساس گردید؟ آشنایی با الگوهای معماری داده NoSQL می تواند به بسیاری از سوالات این چنین پاسخ دهد.
الگوهای جدید معماری بانک های اطلاعاتی NoSQL چه چیزی هستند و این نوع بانک های اطلاعاتی قرار است پاسخگوی چه نوع مسائلی باشند ؟ چگونه می توان با توجه به نوع نیاز و ماهیت مساله از یک الگوی مناسب NoSQL استفاده کرد ؟ سعی خواهیم کرد در این مطلب و سایر مطالبی که در آینده منتشر خواهد شد ، ضمن پاسخ گویی به این قبیل سوالات به صورت اصولی با الگوهای جدید معماری بانک های اطلاعاتی آشنا شویم .
1- بانک های اطلاعاتی از گذشته تا کنون
از گذشته تاکنون شاهد سه دوران مختلف در عرصه بانک های اطلاعاتی بوده ایم . شکل ۱ ، این دوره های مختلف را نشان می دهد.از سیستم های مدیریت بانک های اطلاعاتی رابطه ای (RDBMS ) برای تراکنش ها و از بانک های اطلاعاتی تحلیلی ( Analytics) برای انبار داده استفاده می گردد . 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 در عمل است .
مروری بر 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 که در واقع یک مدل داده متادیتا می باشد) ، استاندارد کرده است.
منبع : سایت فابک