توسعه پذیری برای پروژه ها و محصولات خیلی مهمه! و تقریبا توی مصاحبه با هر شرکتی بزرگ و کوچیکی که شرکت کنی یه جمله ثابت میگن : "پروژه ما توسعه پذیره" یا "میخوایم پروژه ای داشته باشیم که توسعه پذیر باشه"
خیلی ابعاد شرکت مهم نیست، هر کارفرمایی دوست داره اسم توسعه پذیر بودن یا به صورت اداعیی scalable رو پشت محصول شون بیاره
پس ما برنامه نویس های زحمت کش هم مجوریم که بلد باشین یا حداقل با مفاهیمش اشنا باشیم!
اگه شروع به خوندن در مورد توسعه پذیری کنی دوتا کلمه میبینی : توسعه افقی (Horizontal Scaling) یا توسعه عمودی (Vertical Scaling)
میدونم که ما همیشه افقی و عمودی رو قاطی کردیم اما بیاین یه بار برا همیشه ببینیم چی به چیه؟
اول ببنیم توسعه پذیری چیه تا باهم on the same page باشیم.
توسعه پذیری معنای زیادی داره توی بخش های مختلف پروژه ولی ما میخوایم درمورد توسعه پذیری زمانی که افزایش ترافیک داریم صحبت کنیم. توسعه پذیری توی این زمینه یعنی سیستم بتونه نسبت به افزایش ترافیک ورودی منابع خودشو بیشتر کنه تا بتونه در زمان افزایش ترافیک بدون مشکل و تاخیر به کاربران پاسخ بده. نکته مهم اینجاست که همه سیستم ها قابلیت توسعه دارن ولی وقتی میگیم یه سیستمی توسعه پذیره منظورمون اینجاست که این توسعه پیدا کردن بدون تغیرات اساسی قابل انجامه و نمیخواد چند ساعت منابع فنی براش خرج بشه یا حتی توی سیستم های مثل kubernetes این فرایند به صورت اتومات و بدون دخالت ما انجام بشه.این دقیقا فرق بین سیستم توسعه پذیر با سیستم های معمولی تره.
خب حالا که فهمیدیم توسعه پذیری چیه میتونیم درمورد توسعه افقی و عمودی صحبت کنیم.
زمانی که درمورد توسعه افقی صحبت می کنیم منظورمون اضافه کردن منابع بیشتر به صورت موازی با سرور خودمونه. به زبون ساده تر یعنی یه سرور دیگه مثل سرور اصلی توی مدار بیاد تا ترافیک بینشون تقسیم بشه. به صورت تخصصی تر یعنی اضافه کردن instance های بیشتر از پروژه تا ترافیک رو بین خودشون تقسیم کنن. load balancing یکی از روش های معروف توی توسعه افقیه.
در نقطه مقابل، توسعه عمودی منابع سرور اصلی رو بیشتر میکنه. مثلا تعداد هسته های پردازنده رو بیشتر میکنه یا میزان حافظه رم رو افزایش میده
حالا که فهمیدیم فرق شون چیه میتونیم درمورد این صحبت کنیم که کدومشون برای ما بهتره:
توسعه افقی نا محدوده چون هیچ کس نمیتونه جلوی مارو توی ساخت instance از پروژه بگیره و چون node هایی اضافه میکنیم که به صورت مستقل کار میکنن، اگه یک node به مشکل بخوره پروژه هنوز به کار خودش ادامه میده و مشکلی پیش نمیاد اگه هم از سخت افزار های سبک استفاده کنیم هزینه مون هم پایین تره ولی اینا فقط یک طرف ترازو هستن و ترازو همیشه دوتا کفه داره.
اگه دستمون توی ساخت instance بازه ولی به ازای هر instance که میسازیم داریم پشتیبانی از سیستم رو سخت تر میکنیم و نیاز به الگوریتم بهتری برای load balancing داریم و شاید هم لازم باشه توی پروژه تغیراتی بدین که بتونیم توسعه افقی داشته باشیم. مثلا مدیریت دیتابیس
توسعه عمودی پیاده سازیش به شدت راحته چون معمولا با یه تیکت به شرکت توزیع کننده میتونیم منابع مون رو افزایش بدین یا خودمون این کارو بکنیم و چون یک سرور کل پروژه رو مدیریت میکنه پشتیبانی ازش راحتره و خیلی تغیر خاصی هم توی پروژه نمیخواد تا بتونه از توسعه عمودی بهره مند بشه.
ولی توی توسعه محدودیت داره چون معمولا محدودیت سخت افزار داریم و هزینه این ارتقای سخت افزار به شدت زیاده و ما یه down time چند ساعته برای ارتقا نیاز داریم . اینم اضافه کنم که اگه پروژه به مشکل بخوره کل پروژه از دسترس خارج میشه.
حالا اصلا برا چی این همه درمورد توسعه پذیری افقی و عمودی و خود توسعه پذیری صحبت کردیم؟
برای رسیدن به بحث جذابه Sharding!
Sharding توی توسعه افقی نسبتا زیاد استفاده میشه ولی تو ایران به دلیل اینکه به پروژه پیچیدگی اضافه میکنه خیلی محبوب نیست.
sharding به طور کلی استراتژی برای تقسیم دیتاها بین دیتابیس هاست. به جای اینکه یک دیتابیس برای همه دیتاها داشته باشیم و همه خواندن ها و نوشتن ها روی یک دیتابیس انجام بشه، این فشار روی چنتا دیتابیس تقسیم میشه. حالا اصلا چرا باید از Sharding استفاده کنیم؟
دیتابیس ها توانایی ذخیره کردن حجم زیادی از دیتا رو دارن ولی فقط نیاز ما ذخیره کردن نیست، ما نیاز داریم تا بتونیم دیتایی که کاربران میخوان رو توی سریع ترین زمان ممکن بهشون برسونیم. وقتی تعداد کاربرهایی که از دیتابیس دیتا میخوان زیاد میشه به همون اندازه زمان اجرای کوئری بیشتر میشه.
برای همین میتونیم دیتا رو بین چنتا دیتابیس پخش کنیم تا کاربرهامون بین دیتابیس ها تقسیم بشن و زمان اجرای کوئری زیاد نشه.
حالا برای Sharding به چی نیاز داریم؟
برای Sharding ما نیاز به Sharding key داریم
به فیلدی که بر اساس اون دیتا هارو بین دیتابیس ها تقسیم میکنیم میگن Sharding key. برای مثال فیلد سن میتونه Sharding key باشه و کاربران روی توی بازه های 20 تا 30، 30 تا 50 و 50 به بالا بین دیتابیس های تقسیم کنیم ولی این سن کلید خوبی برای اینکار نیست؛ چرا ؟
چون اغلب کاربران ما بین 20 تا 30 هستن و دیتابیس مربوط به این افراد رکورد های بیشتری ذخیره میکنه. به دیتابیسی که بیشترین میزان دیتا رو توی خودش داره میگن hotspot.
کلید Sharding باید طوری انتخاب بشه که توی ساختار ما Hotspot شکل نگیره
حالا که ما کلید مناسب رو پیدا کردیم نیاز به الگوریتمی داریم تا فرایند انتخاب shard مناسب رو انجام بده. چنتا الگوریتم معروف هست برای این کار که میتونیم باهم بررسیشون کنیم:
MOD: این الگوریتم دیتاهارو براساس ترتیبشون تقسیم میکنه، مثلا الگوریتم mod3 رکورد های اول و چهارم و هفتم رو در شارد 1، رکوردهای دوم و پنجم و هشتم رو در شارد 2 و رکورد های سوم و ششم و نهم رو روی شارد 3 ذخیره میکنه و این فرایند تا اخر ادامه پیدا میکنه. اینجا sharding key ما ترتیب شون یا فیلد id اتخاب شده.
Hash : الگوریتم Hash دیتا هارو به صورت رندوم بین شارد ها تقسیم میکنه ولی دیگه خیلی هم تصادفی نیست که Hotspot شکل بگیره. این تقسیم بندی به صورت مدیریت شده انجام میشه.
RANGE: این الگوریتم دیتاهارو به بر اساس تنوع مقدارهای Sharding key ذخیره میکنه مثل فیلد سن
TAG: این الگوریتم بر اساس مقدار خاص فیلد Sharding key فرایند رو انجام میده. مثلا فیلد جنسیت
این نکته رو اضافه کنم که فرایند Sharding توی دیتابیس ها مدیریت نشده و شما باید به صورت دستی این کارو انجام بدین. کلید خودتونو انتخاب کنید، یک کلاس برای مشخص کردن Shard مورد نظر بسازید و دیتا رو روش ذخیره کنید و فرایند خوندن دیتا هم به همین شکل عمل میکنه.
در نظر داشته باشید مسائله ای مثل Sharding واقعا کمک میکنن به پروژه به شرطی که برای پروژه مناسبی انتخاب بشه و به صورت اصولی اجرا بشه.
اگه دوست داری بیشتر در مورد Sharding بدونی میتونی ویدیو زیر رو ببین تا مسائل رو با مثال های بهتری برات توضیح بده
ممنونم از اینکه وقت گذاشتین و مقاله منو خوندین امیدوارم تونسته باشم بهتون کمک کنم تا دیگه توسعه افقی و عمودی رو باهم قاطی نکنید.
