"برآورد تقریبی: هنر محاسبات سریع و دقیق برای طراحی سیستم‌ها"

من امیر معصوم بیگی هستم ، علاقه مند به به طراحی ، توسعه و پیاده سازی سیستم های نرم افزاری

"برآورد تقریبی: هنر محاسبات سریع و دقیق برای طراحی سیستم‌ها"

مقدمه:

فرض کن تو یه جلسه کاری نشستی و یکی از مدیرها ازت می‌پرسه: "اگه بخوایم یه سیستمی راه بندازیم که روزی چند هزار پیام رو پردازش کنه، چند تا سرور لازم داریم؟" یا مثلاً تو یه مصاحبه شغلی ازت می‌خوان تخمین بزنی که توییتر چجوری اطلاعات میلیون‌ها کاربر رو ذخیره و مدیریت می‌کنه. خب، اینجا وقت نداری لپ‌تاپ رو باز کنی، ماشین‌حساب بیاری یا یه برنامه دقیق بنویسی، درسته؟ اینجاست که "برآورد تقریبی" یا

همون Back-of-the-Envelope Estimation مثل یه ناجی وارد بازی می‌شه.

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

تو دنیای تکنولوژی هم داستان همینه. مثلاً مهندس‌های گوگل وقتی می‌خوان یه سرویس بزرگ مثل جیمیل طراحی کنن، نمیان از همون اول همه‌چی رو دقیق حساب کنن. اول چند تا فرض ساده می‌کنن:

• مثلاً چند نفر از این سرویس استفاده می‌کنن؟
• هر نفر چقدر داده تولید می‌کنه؟
• این داده‌ها چقدر فضا لازم دارن؟

برآورد تقریبی دقیقاً همین جا به کار میاد. یه جور محاسبه سرانگشتیه که تو رو از گیر کردن توی جزئیات نجات می‌ده و کمک می‌کنه بفهمی طرح کلی چطوری باید باشه.

این روش تو زندگی عادی هم کلی کاربرد داره. مثلاً:

• می‌خوای برای مهمونی نوشیدنی بخری؟ تعداد مهمونا رو ضربدر دو کن، همینه!
• داری فکر می‌کنی برای تعطیلات چقدر پول کنار بذاری؟ مسیر رو ضربدر قیمت بنزین کن.

توی این مقاله قراره همین روش ساده و کاربردی رو با زبون خودمونی یاد بگیریم و با چند مثال واقعی، مثل توییتر و دیتاسنترها، حسابی دستمون راه بیفته. آماده‌ای؟! 😊

برآورد تقریبی: راهی برای حل مسائل پیچیده با روش‌های ساده

گاهی وقتا توی زندگی و کار، نیاز نیست همه‌چیز رو دقیق بدونی. مثلاً اگه یکی ازت بپرسه برای اینکه یه آپارتمان رو نقاشی کنی چند قوطی رنگ لازمه، نیازی نیست دقیق بشینی دیوارها رو متر کنی یا میزان جذب رنگ هر دیوار رو محاسبه کنی! کافیه به طور تقریبی طول و عرض خونه رو در نظر بگیری، یه عدد حدودی ضرب و تقسیم کنی، و به یه تخمین برسی. برآورد تقریبی دقیقاً همینه: رسیدن به یه جواب سریع که خیلی هم دور از واقعیت نباشه.

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

مثال واقعی:

فرض کن می‌خوای یه سرویس مثل اینستاگرام طراحی کنی. سؤال اینه که برای ذخیره‌سازی عکس‌های کاربران چقدر فضای دیسک لازمه؟ خب، می‌تونی اینجوری فکر کنی:

• مثلاً یه کاربر معمولی روزی ۵ تا عکس آپلود می‌کنه.
• هر عکس به طور متوسط ۵ مگابایته.
• سرویس ۱۰۰ میلیون کاربر فعال داره.

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

چرا این روش انقدر جذابه؟

1. سریع و ساده‌ست: برآورد تقریبی نیاز به ابزار خاصی نداره؛ فقط مغزت و شاید یه قلم و کاغذ.
2. تمرکز رو روی اصول نگه می‌داره: به جای غرق شدن توی جزئیات، بهت کمک می‌کنه روی ایده‌های کلی تمرکز کنی.
3. تصمیم‌گیری بهتر: وقتی یه دید کلی داری، می‌تونی تصمیم‌های بزرگ‌تری بگیری.

مثال روزمره:

تو زندگی عادی هم این روش کلی به کار میاد. مثلاً:

• می‌خوای برای عید آجیل بخری؟ اگه بدونی هر نفر حدود نیم کیلو آجیل می‌خوره، کافیه تعداد مهمون‌ها رو ضربدر نیم کنی. نیازی نیست دقیق میزان اشتهای هر نفر رو حساب کنی!
• داری برنامه‌ریزی می‌کنی که برای سفر چقدر هزینه کنی؟ می‌دونی هر کیلومتر تقریباً ۱۰ هزار تومن هزینه داره، مسافت رو در این عدد ضرب کن.

نکته طلایی:

هدف از برآورد تقریبی این نیست که جواب کاملاً دقیق بدی. این یه ابزار کمکیه برای اینکه سریع‌تر و مطمئن‌تر به یه دید کلی برسی. حالا این دید کلی تو رو توی مسیر درست قرار می‌ده تا بعداً وقت و انرژی بیشتری برای جزئیات بذاری.

این فقط شروع ماجراست! تو بخش‌های بعدی، به نکات تخصصی‌تر و جذاب‌تر، مثل "Power of Two" و تأخیر سیستم‌ها، می‌پردازیم. آماده‌ای؟ 😊

قدرت دو (Power of Two): چرا برای سیستم‌ها مهمه؟

وقتی درباره طراحی سیستم‌ها یا ذخیره‌سازی داده‌ها حرف می‌زنیم، یکی از اولین چیزایی که باید بدونی، مفهوم "Power of Two" یا همون "توان‌های دو" هست. این مفهوم شاید اولش یه چیز ریاضی خشک به نظر برسه، ولی وقتی کاربردش رو ببینی، احتمالاً نظرت عوض می‌شه.

داستان از کجا شروع می‌شه؟

دنیای کامپیوتر خیلی با دنیای ما که بر پایه ده‌گانست فرق داره. تو کامپیوتر همه‌چیز با اعداد باینری (صفر و یک) کار می‌کنه. برای همین، توان‌های دو نقش کلیدی دارن. مثلاً:

• 1 بایت = 8 بیت (معادل 2 به توان 3 بیت)
• 1 کیلوبایت = 1024 بایت (معادل 2 به توان 10 بایت)
• 1 مگابایت = 1024 کیلوبایت (معادل 2 به توان 10 کیلوبایت)
• همین‌جوری تا گیگابایت ، ترابایت و پتابایت پیش می‌ره!

پس اگه بدونی چطوری با این توان‌های دو کار کنی، خیلی راحت‌تر می‌تونی حجم داده‌ها رو تخمین بزنی.

چرا توان‌های دو مهم هستن؟

مثلاً فرض کن یه سیستم ذخیره‌سازی طراحی می‌کنی. تعداد کاراکترهایی که کاربرها تایپ می‌کنن چقدر فضا می‌بره؟ برای هر کاراکتر معمولی (مثل حروف انگلیسی) 1 بایت لازمه. ولی اگه داده‌ها رو به شکلی ذخیره کنی که همیشه با توان دو هماهنگ باشه، هم محاسبات ساده‌تر می‌شه و هم سیستم بهینه‌تر کار می‌کنه.

مثال ساده:

بیایم حجم یه چت ساده رو تخمین بزنیم:

• هر پیام شامل 100 کاراکتره.
• هر کاراکتر 1 بایت می‌بره.
• اگه 1 میلیون نفر روزی 10 پیام بفرستن، حجم داده‌ها این‌طوری حساب می‌شه:

خب، بیایم این محاسبات رو انجام بدیم:

هر پیام 100 کاراکتر × 1 بایت = 100 بایت

تعداد پیام‌ها در روز: 1,000,000 نفر × 10 پیام = 10,000,000 پیام

حجم کل داده‌ها در روز: 10,000,000 پیام × 100 بایت = 1,000,000,000 بایت

تبدیل به مگابایت: 1,000,000,000 بایت ÷ (1024 × 1024) ≈ 953.67 مگابایت

بنابراین، اگه 1 میلیون نفر هر روز 10 پیام بفرستن، حجم کل داده‌ها تقریبا 953.67 مگابایت می‌شه. ما برای راحتی کار ، عدد رو گرد میکنیم و 1024 در نظر میگیریم که معادل 1 گیگ میشه، حالا اگه این داده‌ها رو برای یک سال ذخیره کنیم، حجمش می‌شه

365*1 = 365 گیگابایت

نکته مهم:

وقتی این برآوردها رو انجام می‌دی، همیشه حواست باشه اعدادت گرد و راحت باشن. مثلاً اگه نتیجه‌ای که گرفتی 995 مگابایته، بهتره همون 1 گیگابایت در نظر بگیری. اینجوری هم محاسبات ساده‌تر می‌شه و هم احتمال خطا کمتره.

کاربرد تو دنیای واقعی:

توان‌های دو فقط برای محاسبات ذخیره‌سازی نیستن. این مفهوم تو شبکه‌ها، کش کردن داده‌ها، و حتی طراحی حافظه هم استفاده می‌شه. مثلاً اگه یه سرور داری که 32 گیگابایت رم داره، بهینه‌ترین حالت اینه که حافظه‌ها رو بر اساس بلوک‌های توان دو تقسیم کنی.

جمع‌بندی:
"Power of Two" یه ابزار ساده ولی قدرتمنده. وقتی یاد بگیری چطوری ازش استفاده کنی، هم محاسباتت سریع‌تر می‌شه و هم سیستمی که طراحی می‌کنی بهتر و بهینه‌تر کار می‌کنه. حالا که این مفهوم رو یاد گرفتی، تو بخش بعدی درباره یکی از مسائل حیاتی دیگه یعنی "Latency" یا همون تاخیر صحبت می‌کنیم؛ چیزی که می‌تونه سیستم‌هاتو سریع یا کند کنه! 😊

تأخیر (Latency): وقتی زمان اهمیت پیدا می‌کند

فرض کن می‌خوای یه فیلم آنلاین ببینی. دکمه پخش رو می‌زنی و فیلم فوراً شروع می‌شه. حالا تصور کن بعد از زدن دکمه، ۱۰ ثانیه طول بکشه تا پخش شروع بشه. چه احساسی داری؟ احتمالاً به اینترنت یا سرویس استریم غر می‌زنی! اینجا چیزی که اذیتت کرده، تأخیر (Latency) هست.

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

تأخیر تو سیستم‌های کامپیوتری یعنی چی؟

تو کامپیوتر، تأخیر می‌تونه مربوط به هر چیزی باشه:

• زمان پردازش توی CPU
• مدت زمان لازم برای خواندن داده‌ها از حافظه یا دیسک
• مدت زمانی که یه بسته داده از یه سرور به سرور دیگه منتقل می‌شه

به قول معروف، حافظه سریع است، ولی دیسک کند!

تأخیر معمول در عملیات کامپیوتری:

آقای Dr. Jeff Dean (یکی از مهندسان ارشد گوگل) یه جدول معروف از تأخیرهای معمول عملیات کامپیوتری درست کرده. این جدول نشون می‌ده چقدر بعضی کارها سریع‌تر از بقیه هستن:

• خواندن از حافظه کش (Cache) چند نانوثانیه (ns)
• دیسک SSD: چند میلی‌ثانیه (ms)
• ارسال داده به یه سرور دیگه: چند میلی‌ثانیه تا چند صد میلی‌ثانیه

برای اینکه بهتر بفهمی، بیا یه مثال ساده بزنیم:

• خواندن 1 بایت از حافظه رم: مثل اینه که از خونه‌ت یه فنجون قهوه برداری.
• خواندن 1 بایت از دیسک سخت (HDD): مثل اینه که بری سوپرمارکت محل و قهوه بخری.
• ارسال داده به یه سرور دیگه تو کشور دیگه: مثل اینه که سوار هواپیما بشی و بری قهوه رو از یه کافی‌شاپ تو شهر دیگه بگیری!

چطور تأخیر رو کم کنیم؟

خب، کسی از تأخیر خوشش نمیاد، پس چیکار می‌شه کرد؟ چند راه‌حل ساده:

1. داده‌ها رو فشرده کن: وقتی می‌خوای داده‌ها رو از یه نقطه به نقطه دیگه بفرستی، حجمش رو کم کن تا سریع‌تر ارسال بشه.
2. از کش (Cache) استفاده کن: اگه داده‌ها رو نزدیک‌تر به جایی که استفاده می‌شن نگه داری، نیاز به رفت‌وبرگشت‌های اضافه کم می‌شه.
3. تا جایی که می‌تونی دیسک رو دور بزن: اگه اطلاعات رو توی حافظه (RAM) ذخیره کنی، دسترسی خیلی سریع‌تره.

یه نکته جالب درباره مراکز داده (Data Centers) :

دیتاسنترها معمولاً توی مناطق مختلف دنیا پخش هستن. وقتی یه کاربر ایرانی بخواد به یه سرور آمریکایی متصل بشه، داده‌ها باید کلی راه طی کنن. برای همین شرکت‌های بزرگ مثل گوگل یا آمازون سرورهاشون رو نزدیک کاربرانشون قرار می‌دن تا تأخیر رو کم کنن.

جمع‌بندی:

تأخیر چیزی نیست که همیشه بتونی ازش فرار کنی، ولی با شناخت بهترش می‌تونی طراحیهات رو بهینه‌تر کنی. یه قانون طلایی اینه: "تا جایی که می‌تونی، داده‌ها رو نزدیک نگه دار و دیسک رو دور بزن!"

تو بخش بعدی، درباره یه مفهوم حیاتی دیگه حرف می‌زنیم: "Availability" یا همون در دسترس‌پذیری، که نشون می‌ده یه سیستم چقدر می‌تونه همیشه آماده به کار باشه! 😊

در دسترس‌پذیری (Availability): همیشه روشن و آماده به کار

فرض کن یه روز صبح می‌خوای وارد اینستاگرام بشی و با یه پیغام خطا روبه‌رو می‌شی: "سرویس در دسترس نیست". چه احساسی پیدا می‌کنی؟ احتمالاً اول اینترنتت رو چک می‌کنی، بعد از دوستات می‌پرسی که آیا برای اونا هم این مشکل پیش اومده. حالا تصور کن این قطعی یه ساعت، یه روز یا حتی بیشتر طول بکشه! واقعاً عصبانی‌کننده‌ست. اینجا دقیقاً چیزی که تحت تأثیر قرار گرفته، در دسترس‌پذیری(Availability) سیستمه.

در دسترس‌پذیری یعنی چی؟

در دسترس‌پذیری یعنی یه سیستم یا سرویس چه مقدار از زمان رو می‌تونه بدون هیچ وقفه‌ای کار کنه و خدمات ارائه بده. این مفهوم رو معمولاً با درصد بیان می‌کنن. مثلاً:

• 100% در دسترس‌پذیری یعنی هیچ‌وقت قطعی نداره (که در عمل غیرممکنه).
• 99.9% در دسترس‌پذیری یعنی در طول یه سال، فقط حدود ۸ ساعت قطعی خواهیم داشت.

سطح خدمات (SLA) و نقش "نه‌ها"

وقتی یه شرکت بزرگ مثل گوگل یا آمازون به شما یه سرویس می‌فروشه، یه قرارداد به اسم SLA (Service Level Agreement) ارائه می‌ده. این قرارداد مشخص می‌کنه که چقدر سرویسشون در دسترس خواهد بود. معمولاً این سطح خدمات رو با تعداد "نه‌ها" (nines) نشون می‌دن:

• (99% یا 2 تا نه): حدود ۸۷ ساعت قطعی در سال.
• (99.9% یا 3 تا نه): حدود ۸ ساعت قطعی در سال.
• (99.99% یا 4 تا نه): حدود ۵۲ دقیقه قطعی در سال.

نکته : 2 تا نه ، همون تعداد عدد 9 که در درصد هستش ، همینقد ساده 😊

هر چی تعداد "نه‌ها" بیشتر باشه، سرویس بهتره، اما هزینه ارائه این سطح هم بیشتر می‌شه.

چطور در دسترس‌پذیری رو بالا ببریم؟

هیچ سیستمی نمی‌تونه همیشه 100% در دسترس باشه، ولی می‌تونیم با طراحی‌های هوشمندانه این زمان رو به حداکثر برسونیم:

1. پشتیبان‌گیری از داده‌ها (Replication) :
   اطلاعات رو توی چند سرور مختلف ذخیره کن تا اگه یکی خراب شد، داده‌ها از جای دیگه بازیابی بشن.
2. تعادل بار (Load Balancing) :
   وقتی تعداد زیادی کاربر به سیستم وصل می‌شن، یه سرور ممکنه خیلی شلوغ بشه. با توزیع بار بین چند سرور، می‌تونی از این مشکل جلوگیری کنی.
3. نقاط شکست رو کم کن (Single Point of Failure) :
   اگه یه بخش از سیستمت خراب بشه و کل سرویس رو از کار بندازه، یعنی یه نقطه ضعف بزرگ داری. باید مطمئن بشی که سیستم بتونه با از کار افتادن یه بخش، به کارش ادامه بده.

مثال واقعی:

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

• مشتری‌ها اعتمادشون رو از دست می‌دن.
• کلی فروش رو از دست می‌دی.
• ممکنه رقبا مشتری‌هاتو جذب کنن.

برای همین شرکت‌های بزرگ کلی هزینه می‌کنن تا سرویس‌هاشون همیشه آماده به کار باشن.

جمع‌بندی:

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

تو بخش بعدی، می‌ریم سراغ یه مثال واقعی از برآورد سیستم‌های بزرگ: "توییتر چطور نیازهای ذخیره‌سازی و پردازش خودش رو تخمین می‌زنه؟" 😊

مثال واقعی: تخمین نیازهای توییتر

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

فرضیات اولیه:

برای این مثال فرض کنیم توییتر اطلاعات زیر رو به ما داده:

• توییتر حدود 300 میلیون کاربر فعال ماهانه داره.
• حدود 50 درصد این کاربرها روزانه وارد توییتر می‌شن.
• هر کاربر به‌طور متوسط روزانه 2 توییت ارسال می‌کنه.
• 10 درصد توییت‌ها شامل فایل‌های مدیا (عکس یا ویدیو) هستن.
• توییت‌ها باید برای مدت 5 سال ذخیره بشن.

برآورد نیازهای پردازش (QPS):

• مفهوم QPS (Queries Per Second) یعنی تعداد درخواست‌هایی که سیستم در هر ثانیه باید پاسخ بده.

مفهوم DAU (Daily Active Users) : مخفف عبارت Daily Active Users است که به معنی کاربران فعال روزانه است. این اصطلاح در تحلیل سیستم‌ها و اپلیکیشن‌ها استفاده می‌شود تا تعداد کاربرانی را نشان دهد که در یک روز مشخص از سرویس یا اپلیکیشن استفاده می‌کنند.

به‌عنوان مثال:
اگر توییتر 300 میلیون کاربر ماهانهداشته باشد و 50 درصد آن‌ها به‌صورت روزانه وارد حسابشان شوند، DAU توییتر برابر است با:
300 میلیون × 50٪ = 150میلیون کاربر فعال روزانه.

مفهوم DAU یکی از معیارهای مهم برای ارزیابی میزان تعامل کاربران با یک سرویس یا اپلیکیشن است و اغلب برای سنجش عملکرد و رشد پلتفرم‌ها استفاده می‌شود.

حالا بریم بهتر نیاز های توییتر رو ارزیابی کنیم :

1. تعداد کاربران روزانه (DAU) :
300 میلیون کاربر × 50٪ = 150میلیون کاربر فعال روزانه

2. تعداد توییت‌های روزانه:
150 میلیون کاربر × 2 توییت در روز = 300 میلیون توییت در روز

3. تعداد توییت در هر ثانیه (QPS) :
300 میلیون توییت ÷ (24 ساعت × 3600 ثانیه) 3500 ≈ توییت در ثانیه

4. حالت اوج (Peak QPS) :
معمولاً در زمان‌های اوج، تعداد درخواست‌ها ممکنه 2 برابر بشه:
3500 توییت در ثانیه × 2 = 7000 توییت در ثانیه

برآورد نیازهای ذخیره‌سازی:

برای ذخیره‌سازی، باید حجم هر توییت رو حساب کنیم:

1. حجم هر توییت:

• شناسه توییت (tweet_id): 64 بایت
• متن توییت 140 کاراکتر = 140 بایت
• مدیا (در صورت وجود) 1مگابایت (در نظر گرفتن حالت میانگین)

حجم هر توییت = 64 بایت + 140 بایت + حجم مدیا (در صورت وجود)

2. محاسبه حجم مدیا:
فقط 10 درصد توییت‌ها شامل مدیا هستن:
150 میلیون کاربر × 2 توییت × 10٪ × 1 مگابایت = 30 ترابایت در روز

3. حجم کل ذخیره‌سازی برای 5 سال:
30 ترابایت در روز × 365 روز × 5 سال 55 ≈ پتابایت

نتیجه‌گیری:

• توییتر باید سیستمی طراحی کنه که در اوج ترافیک، توان پردازش 7000 درخواست در ثانیه رو داشته باشه.
• فضای ذخیره‌سازی لازم برای مدیا در طول 5 سال، حدود 55 پتابایت خواهد بود.

نکته مهم:

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

تو بخش بعدی، چند نکته طلایی رو بررسی می‌کنیم که می‌تونه برآوردها رو دقیق‌تر و بهتر کنه. 😊

نکات طلایی برای برآورد دقیق‌تر و بهتر

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

. 1 گرد کردن و ساده کردن اعداد

محاسبه با اعداد پیچیده وقت‌گیر و گاهی گیج‌کننده‌ست. برای همین همیشه اعداد رو گرد کن.

• مثال:
  به‌جای اینکه بگی 99987 تقسیم بر 9.1، سریع می‌گی: 100000 تقسیم بر 10. نتیجه تقریباً همونه، ولی محاسبه‌ش خیلی راحت‌تره.
• به‌جای حساب کردن 1023بایت، همون 1 کیلوبایت رو در نظر بگیر.

. 2 نوشتن فرضیات

همیشه فرضیاتی که انجام می‌دی رو بنویس. این کار به دو دلیل مهمه:

• ممکنه بعداً لازم باشه دوباره فرضیاتت رو بررسی کنی.
• مصاحبه‌کننده یا همکارت می‌تونه دقیقاً بفهمه بر چه اساسی محاسبه کردی.
• مثال:
  اگه گفتی هر کاربر روزی 2 توییت ارسال می‌کنه، حتماً این فرض رو مشخص کن.

. 3 برچسب‌گذاری واحدها

وقتی اعدادی مثل 5 یا 1000 رو می‌نویسی، حتماً مشخص کن منظور چیه.

• مثال:
• 5 کیلوبایت؟ 5 مگابایت؟ یا 5 گیگابایت؟
• به‌جای نوشتن 10 بنویس 10 گیگابایت، اینجوری هیچ ابهامی باقی نمی‌مونه.

. 4 استفاده از تقریب‌های رایج

برای برآورد بهتر، بعضی اعداد رو همیشه تو ذهنت نگه دار. این کار باعث می‌شه سریع‌تر تصمیم بگیری.

• مثال:
• (تعداد ثانیه‌های یک روز: 86400 تقریباً 86000 )
• (تعداد روزهای یک سال: 365 تقریباً 360 )

. 5 تمرین کردن سوالات پرکاربرد

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

• مثال‌های پرکاربرد:
• برآورد تعداد درخواست در ثانیه (QPS).
• حجم داده موردنیاز برای ذخیره‌سازی.
• تعداد سرورهای لازم برای یک سرویس.

. 6 استفاده از ابزارها

گاهی وقتا یه ابزار ساده مثل قلم و کاغذ یا حتی یه ماشین‌حساب می‌تونه سرعتت رو چند برابر کنه. همچنین ابزارهای آنلاین برای برآورد ذخیره‌سازی یا پردازش داده‌ها وجود دارن که می‌تونی ازشون استفاده کنی.

. 7 آماده بودن برای سوالات تکمیلی

کارفرما یا مصاحبه کننده یا تیم ممکنه ازت سوالات بیشتری بپرسن، مثل اینکه:

• اگه تعداد کاربران 2 برابر بشه، چه تغییری توی سیستم لازمه؟
• اگه بخوای داده‌ها رو سریع‌تر پردازش کنی، چه راهکاری داری؟

نکته پایانی

هدف از برآورد تقریبی این نیست که جواب دقیق بدی. مهم اینه که نشون بدی می‌تونی یه مسئله پیچیده رو به بخش‌های کوچیک‌تر تقسیم کنی و یه تخمین منطقی بزنی. با این روش، همیشه یه قدم جلوتر از بقیه خواهی بود!

سعی من در این مقاله این بود که شما با کلیت تخمین در سیستم های نرم افزاری آشنا بشید و یک دید خوب برای این موضوع پیدا کنید ، منابع زیادی هستن که میتونید به عنوان رفرنس تکمیلی تر مطالعه کنید ، کتاب های آقای Alex Xu یکی از قویترین کتاب ها برای حوزه طراحی نرم افزار هست

System Design Interview An Insider’s Guide by Alex Xu

دوست دار شما امیر معصوم بیگی