کتاب Designing Data-Intensive Applications - فصل اول

تصمیم دارم تو چند تا پست خلاصه های از کتاب Designing Data-Intensive Applications نوشته‌ی Martin Kleppmann رو براتون بنویسم تا اگه زمان کافی برای خوندن این کتاب ندارید بتونید از مطالبش بهره ببرید.

تو اولین پست میریم سراغ فصل اول کتاب : Reliable, Scalable, and Maintainable Applications

وقتی سیستم‌ها بزرگ می‌شن، مشکلات هم بالغ می‌شن

فصل اول کتاب Designing Data-Intensive Applications در واقع مقدمه‌ی فنی نیست؛ مقدمه‌ی فکریه.
نویسنده هنوز وارد دیتابیس، ایندکس، replication یا distributed system نمی‌شه.
اول می‌گه: قبل از اینکه درباره‌ی راه‌حل حرف بزنیم، باید بفهمیم مسئله چیه.

و مسئله‌ی اصلی اینه:

سیستم‌های نرم‌افزاری دیر یا زود خراب می‌شن.

نه به این دلیل که مهندس‌ها بد کدنویسی می‌کنن،
بلکه چون دنیای واقعی پر از failure هستش:

• دیسک‌ها می‌سوزن

• شبکه‌ها ناپایدارن

• سرورها از دسترس خارج می‌شن

• و انسان‌ها (که خطرناک‌ترین component سیستم هستن) اشتباه می‌کنن

پس سؤال مهم این نیست که «خرابی پیش میاد یا نه»، سؤال اینه که وقتی پیش اومد، سیستم چه واکنشی نشون می‌ده؟

Data-Intensive Application یعنی چی؟

Kleppmann از همون اول یه تمایز مهم قائل می‌شه.

بعضی سیستم‌ها compute-intensive هستن:

• مثل بازی‌ها

• یا شبیه‌ سازی‌ های علمی

ولی سیستم‌هایی که این کتاب قراره در موردشون صحبت کنه، data-intensive هستن:

• داده‌ی زیاد

• سرعت بالای read و write

• تعداد کاربر بالا

• و مهم‌تر از همه: پیچیدگی مدیریت داده

مثل:

• شبکه‌های اجتماعی

• سیستم‌های پرداخت

• فروشگاه‌های آنلاین

• سیستم‌های لاگ و آنالیتیکس

اینجا مسئله فقط performance نیست، مسئله اینه که داده‌ها:

• درست ذخیره بشن

• درست بازیابی بشن

• و در شرایط خرابی هم درست باقی بمونن

سه معیار اصلی یک سیستم خوب

Kleppmann می‌گه برای قضاوت درباره‌ی طراحی یک سیستم data-intensive، باید به سه معیار نگاه کنیم که ابزار های فکری هستن:

• Reliability

• Scalability

• Maintainability

Reliability — سیستم باید قابل اعتماد باشه

Reliability یعنی:

سیستم حتی وقتی بخشی ازش خراب می‌شه، هنوز رفتار قابل پیش‌بینی داشته باشه.

اینجا Kleppmann یه تفکیک خیلی مهم انجام می‌ده:

• Fault یعنی یک جزء خراب شده

• Failure یعنی کاربر نتیجه‌ی اشتباه می‌بینه

Fault اجتناب‌ناپذیره. Failure چیزیه که باید جلوش رو گرفت.

سیستم reliable سیستمیه که:

• fault رو تحمل کنه

• بدون اینکه failure بده بیرون

برای همین مفاهیمی مثل اینها از همین‌جا معنی پیدا می‌کنن :

• replication

• redundancy

• isolation

• graceful degradation

Scalability — وقتی سیستم بزرگ می‌شه، له نشه

Scalability یعنی:

سیستم بتونه رشد کنه بدون اینکه مجبور بشیم از نو بسازیمش.

نکته‌ی مهمی که Kleppmann تأکید می‌کنه اینه که: Scalability یعنی تعریف دقیق مسئله.

باید بدونیم:

• چی داره زیاد می‌شه؟ کاربران؟ داده؟ درخواست؟

• bottleneck کجاست؟

• با چه متریکی اندازه می‌گیریم؟
  (throughput، latency، resource usage)

و اینجا یکی از مفاهیم کلیدی فصل اول مطرح می‌شه: Tail Latency

میانگین مهم نیست. اون ۱٪ درخواست خیلی کند مهمه.

مثال آمازون:
وقتی یه درخواست کاربر وابسته به چند سرویس مختلفه، کندی هر کدوم می‌تونه کل تجربه رو خراب کنه. اگر ۹۹٪ درخواست‌ها سریع باشن ولی ۱٪ خیلی کند، کاربر همون ۱٪ رو یادش می‌مونه.

اینجاست که جمله‌ی معروف میاد:

Your bottleneck is dominated by a small number of extreme cases.

یعنی گلوگاه سیستم رو همون درخواست‌های نادر ولی خیلی کند تعیین می‌کنن.

Maintainability — سیستم باید قابل زندگی کردن باشه

شاید انسانی‌ترین بخش فصل اول همین‌جاست.

Kleppmann می‌گه سیستم قراره:

• سال‌ها زنده بمونه

• آدم‌های مختلف روش کار کنن

• تغییر کنه، گسترش پیدا کنه، refactor بشه

پس Maintainability فقط درباره‌ی «کد تمیز» نیست.
برای همین اون رو به سه معیار مشخص می‌شکنه:

Operability — سیستم باید قابل اداره باشه

Operability یعنی:

تیم عملیاتی بتونه سیستم رو بفهمه، مانیتور کنه و در شرایط بحرانی نجاتش بده.

سیستم operateable سیستمیه که:

• deploy کردنش ساده‌ست

• لاگ و متریک معنادار داره

• failureها قابل تشخیص و recovery هستن

• کارها وابسته به یک آدم خاص نیست

سیستمی که فقط «نابغه‌ی تیم» بلده درستش کنه، یه سیستم خطرناکه.

Simplicity — جنگ با پیچیدگی، نه با امکانات

Simplicity به‌معنای ساده‌لوحی نیست. به‌معنای حذف پیچیدگی غیرضروریه.

Kleppmann دشمن‌ها رو اسم می‌بره:

• tight coupling of models

• tangled dependencies

• special case های زیاد

• explosion of the state space

این‌ها سیستم رو شکننده می‌کنن، جوری که یه تغییر کوچیک، ده تا جای دیگه رو می‌ترکونه.

Simplicity یعنی:

• اجزا مستقل‌تر باشن

• رفتار سیستم قابل پیش‌بینی باشه

• مدل ذهنی سیستم ساده باشه، نه الزاماً implementation نرم افزار

Evolvability — سیستم باید بتونه تغییر کنه

Evolvability یعنی:

تغییر دادن سیستم هزینه‌ی غیرمنطقی نداشته باشه.

چون واقعیت اینه:

• نیازها عوض می‌شن

• بیزنس رشد می‌کنه

• مقیاس تغییر می‌کنه

• و هیچ طراحی‌ای ابدی نیست

سیستمی که هر تغییر کوچیکش نیاز به بازنویسی کامل داره، در بلندمدت شکست می‌خوره.

جمله محبوب من و یکی از جملات کلیدی این فصل :

There is no such thing as a generic solution.

هیچ دیتابیس، معماری یا ابزار «همه‌چیزتمامی» وجود نداره.
هر تصمیم مهندسی یه trade-off محسوب میشه:

• consistency در برابر availability

• latency در برابر throughput

• simplicity در برابر flexibility

این کتاب نمی‌گه «این بهترین راهه»، می‌گه: بفهم داری چی رو قربانی می‌کنی.

جمع‌بندی فصل اول

فصل اول بیشتر از اینکه فنی باشه، ذهنیت می‌سازه.

می‌گه:

• خرابی طبیعیه

• پیچیدگی خطرناکه

• و طراحی خوب یعنی آمادگی برای تغییر

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

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

ممنونم از زمانی که گذاشتید و امیدوارم این مطلب براتون مفید بوده باشه.

خوشحال میشم نظراتتون رو بخونم تا هم ازتون یاد بگیرم و هم بتونم محتوای بهتری بنویسم.