با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

خلاصهٔ صوتی کتاب ۱۴۰۵/۰۷/۳۰

فصل اول: برنامه‌های قابل‌اعتماد، مقیاس‌پذیر و قابل‌نگهداری

از کتاب طراحی برنامه‌های داده‌گرا · مارتین کلپمن

جلد طراحی برنامه‌های داده‌گرا
SHABGOFTAR PORTABLE AUDIOهمراهِ شنیدن
صدایی برای همراه بردنPODCAST · PERSONAL STEREO
شب‌گفتار / دفترچهٔ همراهSHABGOFTAR · LINER NOTES

دربارهٔ این فصل

یادداشتِ همراه نوار
جلد طراحی برنامه‌های داده‌گراطراحی برنامه‌های داده‌گرامارتین کلپمندیدن همهٔ قسمت‌های این کتاب ←

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

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

اولین اصل بنیادین در طراحی چنین سیستم‌هایی، قابلیت اعتماد (Reliability) است؛ یعنی توانایی سیستم در ادامهٔ کار درست حتی وقتی خطا رخ می‌دهد. در دنیای واقعی، سخت‌افزارها خراب می‌شوند، نرم‌افزارها باگ دارند و انسان‌ها اشتباه می‌کنند. برای نمونه، در یک کلاستر بزرگ با هزاران هارد دیسک، خرابی روزانهٔ چند قطعه کاملاً عادی است. نویسنده توضیح می‌دهد که به‌ جای تلاش برای حذف کامل خطاها، باید با افزودن قابلیت تحمل خطا و استفاده از تکنیک‌هایی مانند تست‌های مخرب خودکار، مطمئن شویم سیستم با خرابی‌ها از پا نمی‌افتد.

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

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

سومین ستون اصلی، قابلیت نگهداری (Maintainability) است که تلاش می‌کند سهولت تغییر، تعمیر و ادارهٔ سیستم در طول زمان را فراهم کند. بخش بزرگی از هزینهٔ نرم‌افزار مربوط به روزهای پس از توسعه است و پیچیدگی‌های تصادفی که در کد یا معماری انباشته می‌شوند، کار تیم‌های مهندسی و عملیات را دشوار می‌کنند. استفاده از انتزاع‌های مناسب، مانند زبان‌های سطح بالا یا پایگاه‌های داده‌ای که جزئیات پیچیدهٔ ذخیره‌سازی روی دیسک را پنهان می‌کنند، ابزارهایی هستند که به ما کمک می‌کنند پیچیدگی‌ها را مهار کنیم.

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

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