نگاهی متفاوت به ذخیره‌سازی داده‌ها

استقبال از دیتابیس‌های 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 گوگل، کاساندرا و مانگو پشتیبانی می‌کند.

توسعه‌دهندگان و مدیران می‌توانند با به‌کارگیری این رابط انتزاعی، قابلیت‌های دیتابیس‌های غیررابطه‌ای مختلف را بررسی و بهترین آنها را انتخاب کنند.

مترجم: محمدرضا قربانی

مراجع:

http:‌/‌‌/‌www.odbms.org‌/‌ download‌/‌Cattell.Dec10.pdf

http:‌/‌‌/‌www.eweek.com

newsQrCode
ارسال نظرات در انتظار بررسی: ۰ انتشار یافته: ۰

نیازمندی ها