تشریح Scale UP و Scale OUT، و مصداق در Databaseها

Database_sharding

یکی از مباحث مطرح در مخابرات و مهندسی نرم افزار Scability یا به بیان فارسی “مقیاس پذیری” می باشد. اگر بخواهیم توصیفی ساده و گذرا از مفهوم مقیاس پذیری یاscability داشته باشیم، می توانیم بگوییم:

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

به بیان ساده تر: Scability یعنی اینکه اگر سیستم در حال حاضر حجم A محاسبه رو به شکل مطلوب انجام میده یا اگر شبکه ای حجم A  رو داره مورد تبادل قرار میده،(به طور مطلوب و کارا)، بشه حجم A+B رو با همون وضعیت مطلوب به انجام برسونه. اینکه B چقدر باشه موضوع مهمیه، و یکی از مباحث مطرح در Tuning و  Optimization دیتابیس ها، دستورات اجرایی و سرورهای میزبان اونهاست. و فاکتور اصلی رقابت در این عرصه B بیشتره.

مقیاس پذیری از ابعاد زیر قابل بررسی است:

  •  Load scalability مقیاس پذیری بار:
    checkmark_small 
    توانایی حفظ عملکرد همراه با کاهش و یا افزایش حجم وضایف محوله (بار) اعم از پردازش و یا تبادل را مقیاس پذیری بار می نامند.
  • Geographic scalability مقیاس پذیری جغرافیایی:checkmark_small 

    حفظ کارایی، سودمندی و دسترسی سیستم، با حذف سیطره ی جغرافیایی (یعنی سیستم چه در سطح یک شهر یا یک منطقه از یک شهر و یا یک کشور عملکرد بهینه داراباشد)

  • Administrative scalability مقیاس پذیری مدیریتی و کنترلی:
    checkmark_small
    قابلیت سهولت مدیریت در سطح یک سازمان با چندین بخش و زیربخش همانند وقتی که در مقیاس یک سازمان تخت بدون بخش های زیرمجموعه و یا همجوار می باشد.
  • Functional scalability مقیاس پذیری کارکردی:
    checkmark_small
    توانایی حفط عملکرد و کارایی در عین افزایش قابلیت های جدید.

 

 *******************************************************************

  •  مقایس پذیری افقی یا عمودی؟

light_bulb

افزودن منابع سیستمی جهت افزایش توانایی پذیرش به یک جزء (node) را در اصطلاح مقیاس پذیری عمودی، Scale vertically یا  Scale Up گویند. افزودن منابع سیستمی همچون CPU یا حافظه از جمله این نوع مقیاس دهی است که به دنبال آن افزایش حجم پردازش های ممکن را خواهیم داشت.

light_bulb

افزودن node های جدید به سیستم جهت توانایی پردازش داد های بیشتر را مقیاس پذیری افقی، Scale horizontally و یا Scale Out گویند، به طور مثال افزایش وب سرورهای یک وب سایت با کاربران و بازدیکنندگان بسیار، از یک به سه وب سرور از نمونه های این مورد است.

balance2

اینکه کدام یک از دو روش Scale Up یا Scale Out  را به عنوان روش Scability انتخاب کنیم، نکته مهمی است که باید با دقت مورد بررسی قرار گیرد، چرا که Scale Up همراه با مواردی چون مدیریت و برنامه نویسی آسانتر است، از طرفی محدودیت های سیستم در پذیریش میزان منابع بیشتر و همچنین فزونی حجم منابع اشتراکی ما را از به کارگیری محض این روش برحضر می دارد.

برای مثال: محدودیت یک سرور از نظر پذیرش تعداد هارد دیسک و در عین حال اشتراک پهنای باند کنترلر برای هارددیسک ها و یا محدودیت سیستم عامل و شاسی سرور  از نظر پذیرش RAM،برای کاربرد روش Scale Up سقف معینی را در نظر می گیرد که محدودیت را در حوزه گسترش و افزایش منایع به دنبال خواهد داشت.

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

توجه به هزینه و کارایی نکته مهمی است، از آنجایی که پردازش موازی غالبا سریع تر از حالات دیگر است، برای مثال انجام پردازش موازی بر روی 4 پردازنده 70% سریعتر از یک پردازنده خواهد بود.

اگر آلفا رو کسری از محاسبات ترتیبی در نظر گیریم، و 1 − α (آلفا منهای یک !) کسر محاسبات موازی باشد، آنگاه حداکثر افزیش سرعتی که توسط P عدد پردازنده صورت خواهد گرفت طبق قانون Amdahl از رابطه زیر به دست می آید:

Amdahl

یک مثال:

دقت کنید که بر اساس رایطه فوق دوبراربر کردن توان یک پردازنده تنها 0.27 به تعداد دستورات آن می افزاید:

Amdahl_smple  *******************************************************************

oracle sqlserver
  سوال: برتری Oracle 11g نسبت به SQL Server 2008 R2 ؟

شاید تو این بلاگ بیشتر راجع به SQL Server بنویسم یا اینکه من رو در زمینه تدریس و مشاوره اش بشناسند ولی اراکل واقعا دوست داشتنیه و وجود RAC یا همون Real Application Cluster برتری مهمی نسبت به SQL Server هست. از طرفی SQL Server دارای برتری های زیادیه که نمیشه از اون ها گذشت.

در زمینه Scale UP هر دو قوی هستند، پشتیبانی از 256 پردازنده منطقی در SQL Server و محدودیت  RAM به میزان RAM قابل پشتیبانی توسط سیستم عامل و … مواردی هست که لزومی بر بحث و مقایسه Scale Up بین این دو محصول ایجاد نمی نماید ولی Scale Out موضوع بحث مهمی ست.

RAC در اراکل یک راهکار واقعی، پایدار و مطمئن است ولی عمدتا در SQL Server راهکارهای نظیر توزیع داده ها در سطح سرورها پیشنهاد می شود. برای مثال:

شما دارای 15 میلیارد رکورد هستید تنها راهکار مستقل این است که از رکورد 1 تا 5 میلیارد را در سرور 1، 5 میلیارد تا 10 میلیارد در سرور 2 و 10 میلیارد تا 15 میلیارد در سرور 3 ذخیره و پردازش هابر حسب توزیع، بر روی سرور میزبان صورت خواهد پذیرفت.

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

گزینه پیشنهادی؟

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

امیدوارم آنچه که از نظر گذروندید کمکی در جهت درک بهتر مفاهیم Scale Up, Scale Out, Load Balancing در دیتابیس ها بوده باشه. در صورت استقبال از مطلب فوق درباره چگونگی گیاده سازی و عملکرد GridScale مطلب ارائه خواهد شد. در ضمن از بابت اشتباهات انشایی و تایپی عذرخواهی می کنم، علتش کمبود وقت و اینکه گاهی بین نگارش دو پاراگراف کار پیش میاد و رشته کلام از دست میره!

۱ دیدگاه دربارهٔ «تشریح Scale UP و Scale OUT، و مصداق در Databaseها;

دیدگاهتان را بنویسید