یکی از مباحث مطرح در مخابرات و مهندسی نرم افزار Scability یا به بیان فارسی “مقیاس پذیری” می باشد. اگر بخواهیم توصیفی ساده و گذرا از مفهوم مقیاس پذیری یاscability داشته باشیم، می توانیم بگوییم:
مقیاس پذیری، خاصیتی مطلوب از یک سیستم، شبکه و یا روند پردازشی است که توانایی خود را در کنترل و پذیرش حجم مضاعفی از کار بتواند به گونه ای روان و مورد پذیرش نشان دهد.
به بیان ساده تر: Scability یعنی اینکه اگر سیستم در حال حاضر حجم A محاسبه رو به شکل مطلوب انجام میده یا اگر شبکه ای حجم A رو داره مورد تبادل قرار میده،(به طور مطلوب و کارا)، بشه حجم A+B رو با همون وضعیت مطلوب به انجام برسونه. اینکه B چقدر باشه موضوع مهمیه، و یکی از مباحث مطرح در Tuning و Optimization دیتابیس ها، دستورات اجرایی و سرورهای میزبان اونهاست. و فاکتور اصلی رقابت در این عرصه B بیشتره.
مقیاس پذیری از ابعاد زیر قابل بررسی است:
- Load scalability مقیاس پذیری بار:
توانایی حفظ عملکرد همراه با کاهش و یا افزایش حجم وضایف محوله (بار) اعم از پردازش و یا تبادل را مقیاس پذیری بار می نامند. - Geographic scalability مقیاس پذیری جغرافیایی:
حفظ کارایی، سودمندی و دسترسی سیستم، با حذف سیطره ی جغرافیایی (یعنی سیستم چه در سطح یک شهر یا یک منطقه از یک شهر و یا یک کشور عملکرد بهینه داراباشد)
- Administrative scalability مقیاس پذیری مدیریتی و کنترلی:
قابلیت سهولت مدیریت در سطح یک سازمان با چندین بخش و زیربخش همانند وقتی که در مقیاس یک سازمان تخت بدون بخش های زیرمجموعه و یا همجوار می باشد. - Functional scalability مقیاس پذیری کارکردی:
توانایی حفط عملکرد و کارایی در عین افزایش قابلیت های جدید.
*******************************************************************
-
مقایس پذیری افقی یا عمودی؟
افزودن منابع سیستمی جهت افزایش توانایی پذیرش به یک جزء (node) را در اصطلاح مقیاس پذیری عمودی، Scale vertically یا Scale Up گویند. افزودن منابع سیستمی همچون CPU یا حافظه از جمله این نوع مقیاس دهی است که به دنبال آن افزایش حجم پردازش های ممکن را خواهیم داشت.
افزودن node های جدید به سیستم جهت توانایی پردازش داد های بیشتر را مقیاس پذیری افقی، Scale horizontally و یا Scale Out گویند، به طور مثال افزایش وب سرورهای یک وب سایت با کاربران و بازدیکنندگان بسیار، از یک به سه وب سرور از نمونه های این مورد است.
اینکه کدام یک از دو روش Scale Up یا Scale Out را به عنوان روش Scability انتخاب کنیم، نکته مهمی است که باید با دقت مورد بررسی قرار گیرد، چرا که Scale Up همراه با مواردی چون مدیریت و برنامه نویسی آسانتر است، از طرفی محدودیت های سیستم در پذیریش میزان منابع بیشتر و همچنین فزونی حجم منابع اشتراکی ما را از به کارگیری محض این روش برحضر می دارد.
برای مثال: محدودیت یک سرور از نظر پذیرش تعداد هارد دیسک و در عین حال اشتراک پهنای باند کنترلر برای هارددیسک ها و یا محدودیت سیستم عامل و شاسی سرور از نظر پذیرش RAM،برای کاربرد روش Scale Up سقف معینی را در نظر می گیرد که محدودیت را در حوزه گسترش و افزایش منایع به دنبال خواهد داشت.
از طرفی پیچیدگی های برنامه نویسی، پیاده سازی و مدیریت Scale Out نیز را باید در نظر داشت. پس برقراری موازنه جهت انتخاب این دو روش و یا ترکیب آن ها از جمله نکاتی است که باید مورد توجه قرار گیرد و انتخاب نابجای آن ها می تواند موجبات هزینه های اضافی، افزایش زمان تولید و پیاده سازی و همچنین مشکلات متعدد از نظر حجم پردازش ها را دنبال خواهد داشت.
توجه به هزینه و کارایی نکته مهمی است، از آنجایی که پردازش موازی غالبا سریع تر از حالات دیگر است، برای مثال انجام پردازش موازی بر روی 4 پردازنده 70% سریعتر از یک پردازنده خواهد بود.
اگر آلفا رو کسری از محاسبات ترتیبی در نظر گیریم، و 1 − α (آلفا منهای یک !) کسر محاسبات موازی باشد، آنگاه حداکثر افزیش سرعتی که توسط P عدد پردازنده صورت خواهد گرفت طبق قانون Amdahl از رابطه زیر به دست می آید:
یک مثال:
دقت کنید که بر اساس رایطه فوق دوبراربر کردن توان یک پردازنده تنها 0.27 به تعداد دستورات آن می افزاید:
*******************************************************************
سوال: برتری 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 مطلب ارائه خواهد شد. در ضمن از بابت اشتباهات انشایی و تایپی عذرخواهی می کنم، علتش کمبود وقت و اینکه گاهی بین نگارش دو پاراگراف کار پیش میاد و رشته کلام از دست میره!
خیلی ممنون, استفاده کردم