خانه / NoSQL / مقایسه و انتخاب / تاملاتی در باب انتخاب درست بانک اطلاعاتی
wordle

تاملاتی در باب انتخاب درست بانک اطلاعاتی

مطلبی را سال گذشته در سایت شخصی خودم با عنوان “تاملاتی در باب انتخاب چهار دیتابیس کاساندرا، مانگو و الاستیک سرچ و ردیس “ در رابطه با تجربیاتم در انتخاب و استفاده از چهار بانک اطلاعاتی مهم در حوزه NoSQL منتشر کرده بودم که عیناً همان مطلب را برای استفاده علاقه مندان در این سایت که مناسبت بیشتری دارد، قرار می دهم.

مدتی بود در رابطه با اینکه در پروژه های جاری شرکت در مورد این تحقیق می کردم که چه دیتابیس هایی را در چه قسمتهایی باید استفاده کنیم بخصوص با تجربه یکساله ای که توی کارعملی بدست آورده بودیم و باعث شد که یک الگوی داخلی برای استفاده از این بانکهای اطلاعاتی آماده کنم . امیدوارم این تجربیات برای سایرین نیز مفید باشد :

  1. کاساندرا :

کاساندرا را می توانیم یک دیتابیس برای ساخت ایندکس های سفارشی بدانیم داده هایی که ما کلید آنرا تعیین می کنیم و اطلاعات بر اساس همان کلید و ترتیب مورد نظر ما ذخیره می شوند که این امر برای سریهای زمانی بسیار مناسب و ایده آل خواهد بود . مثلاً اگر نیاز به ذخیره اطلاعات راجع به صفحات بازدید شده توسط یک یوزر، اخبار پابلیش شده توسط یک خبرگزاری، آمار گرفته شده برای یک خبر، جستجوهایی انجام شده در یک روز، جستجوهای انجام شده توسط یک یوزر ، دوستان یک فرد، نظرات ذیل یک مطلب و … مانند آن که بر اساس یک کلید خاص (مثلا نام خبرگزاری ، کد خبر ، کد یوزر) قرار است داده هایی را ذخیره و بعدا به ترتیب زمانی (که روی سایر فیلدها هم قابل تنظیم است) آنها را بازیابی کنیم کاساندرا بدون شک بهترین گزینه است با سریعترین زمان ممکن و توزیع شوندگی بالا درون شبکه …

از طرفی ما برای بخش تحلیل و آمارگیری هم با حجم بالای داده، نیاز به شمارنده هایی داریم که در یک شبکه بزرگ از داده ها به خوبی کار کند و تداخلی هنگام آپدیت کردن جداول آماری ایجاد نشود . مثلاً با کلیک روی هر خبر، یا هر گروه باید چندین شمارنده به روز رسانی شود یعنی علاوه بر آمار بازدید آن خبر خاص، بازدید آن کتگوری ، خبرگزاری مربوطه ، کشور و …. نیز باید به روز شود. برای این منظور از کوئریهای دیتابیسی نمی توان استفاده کرد چون در یک دیتابیس توزیع شده و با تراکنش های لحظه ای فراوان، ارسال کوئری های آماری به دیتابیس باعث کندی کار خواهد شد. در اینجا شمارنده های توزیع شده کاساندرا بهترین کارآیی را خواهند داشت و این امر می تواند در کل شبکه توزیع شود و مدیریت آنرا با مدیریت تداخل ها خود کاساندرا انجام دهد (distributed counters) .

نکته بعدی معماری کاساندراست که به جای سیستم مستر / اسلیو یک سیستم کاملا شفاف و هم سطح است و هر نودی در شبکه که از کار بیفتد، بقیه سیستم بدون اشکال می تواند به کار خود ادامه دهد که مانگو بر خلاف این اصل عمل می کند .

بنابراین توصیه بنده برای ذخیره داده های زمانی و داده های آماری بخصوص شمارنده هایی که باید در نظر گرفته شوند ، استفاده از کاساندراست .

  1. الاستیک سرچ

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

بنابراین برای بخش جستجو ، اخبار مرتبط و نیز چنل ها ، انجمن های گفتگو، سوال و جواب ها، نظرات کاربران و مانند آن که نیاز به کوئری گرفتن روی متن داریم (با فیلترهای مختلف) یک انتخاب ایده ال خواهد بود با این شرط که اصل انتری ها و نیز چنل های کاربر در دیتابیسی جداگانه نیز ذخیره شود تا به هر دلیلی بعدها نیاز به ساخت مجدد ایندکس ها را داشته باشیم، بتوانیم این کار را انجام دهیم .

  1. مانگو

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

  1. ردیس

استفاده از این دیتابیس که یک دیتابیس کلید/مقدار مقیم در حافظه است برای ذخیره موقت داده ها و کش آنها در حافظه برای افزایش سرعت برنامه ها بسیار ضروری خواهد بود .

البته به عنوان یک دیتابیس فرعی و عملیاتی و نه به عنوان یک سیستم ذخیره پایدار .

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

Time limit is exhausted. Please reload CAPTCHA.