معرفی کتاب Designing Data-Intensive Applications

اثر مارتین کلپمن (Martin Kleppmann)

نویسنده: مارتین کلپمن
سال انتشار: ۲۰۱۷
تعداد صفحات: 670 صفحه
ژانر: معماری سیستم‌های توزیع‌شده، پایگاه داده، مهندسی داده
سطح مطالعه: پیشرفته (حداقل ۳-۴ سال تجربه عملی در بک‌اند توصیه می‌شود)

چرا این کتاب؟ چرا حالا؟

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

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

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

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

تفاوت این کتاب با بقیه

چرا این کتاب اینقدر خاص است؟ به چند دلیل.

دلیل اول: علمی، اما کاربردی. کلپمن استاد دانشگاه کمبریج است، اما کتابش خشک و آکادمیک نیست. هر مفهوم با مثال‌های واقعی از ابزارهای موجود (PostgreSQL, MySQL, MongoDB, Kafka, Redis, و ده‌ها ابزار دیگر) توضیح داده می‌شود.

دلیل دوم: بی‌طرفی. نویسنده به جای اینکه بگوید «از ابزار X استفاده کنید»، به شما یاد می‌دهد خودتان بر اساس نیازتان تصمیم بگیرید. او Trade-offهای هر انتخاب را شفاف می‌کند.

دلیل سوم: جامعیت. کتاب از لایه فیزیکی ذخیره داده (دیسک و SSD) شروع می‌کند، تا لایه توزیع (Replication, Partitioning) و نهایتاً لایه پردازش جریان داده (Stream Processing, Batch Processing) را پوشش می‌دهد. این یعنی بعد از خواندن این کتاب، نقشه کامل زیرساخت داده‌های مدرن را در ذهنت خواهی داشت.

دلیل چهارم: مدرن بودن. بر خلاف بسیاری از کتاب‌های کلاسیک که در دهه ۹۰ یا ۲۰۰۰ نوشته شده‌اند، این کتاب در ۲۰۱۷ منتشر شده و کاملاً با چالش‌های امروز مثل میکروسرویس‌ها، کلاود، و سیستم‌های توزیع‌شده  هماهنگ است.

معمای اصلی کتاب؛ چرا داده مسئله اصلی است؟

در گذشته، اپلیکیشن‌ها عمدتاً محاسباتی (Compute-Intensive) بودند. یعنی محدودیت اصلی، قدرت CPU بود. امروزه اما اکثر اپلیکیشن‌ها داده‌محور (Data-Intensive) هستند. یعنی:

• حجم داده‌ها بسیار بزرگ است (ترابایت، پتابایت)

• سرعت ورود داده‌ها بالاست (هزاران رکورد در ثانیه)

• داده‌ها باید همیشه در دسترس باشند (۹۹.۹۹٪ آپ‌تایم)

• داده‌ها باید در چندین منطقه جغرافیایی تکثیر شوند

در چنین شرایطی، CPU دیگر گلوگاه اصلی نیست. گلوگاه اصلی، مدیریت داده است: چطور آن را ذخیره کنیم، چطور آن را پخش کنیم، چطور از آن بخوانیم، چطور آن را هماهنگ نگه داریم، و چطور وقتی خطایی رخ داد، آن را بازیابی کنیم.

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

کالبدشکافی کتاب؛ سه بخش اصلی

بخش اول: پایه‌ها؛ ذخیره‌سازی و بازیابی داده

کلپمن از پایه شروع می‌کند. واقعاً از پایه. او توضیح می‌دهد که یک دیتابیس چطور داده را روی دیسک می‌نویسد.

موتورهای ذخیره‌سازی (Storage Engines): هسته اصلی این بخش، مقایسه بین LSM-Trees (مثل LevelDB, RocksDB, Cassandra) و B-Trees (مثل PostgreSQL, MySQL, SQL Server) است. کلپمن با دقت توضیح می‌دهد:

• B-Trees برای خواندن‌های تصادفی و تراکنش‌های ACID بهینه‌اند

• LSM-Trees برای نوشتن‌های سنگین و فشرده‌سازی بهینه‌اند

• هر کدام هزینه‌های متفاوتی دارند: یکی نوشتن را سریع می‌کند اما خواندن را کند، دیگری برعکس

مدل‌های داده (Data Models): چرا SQL سال‌ها غالب بود؟ چه نواقصی دارد که NoSQL آمد آنها را حل کند؟ چه زمانی باید از داکیومنت‌گرا (مثل MongoDB) استفاده کرد، چه زمانی از گراف (مثل Neo4j) و چه زمانی از ستون‌گرا (مثل Cassandra)؟

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

توزیع؛ وقتی یک سرور کافی نیست

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

تکرارپذیری (Replication): چطور داده را بین چند سرور کپی می‌کنیم؟ کلپمن سه معماری اصلی را توضیح می‌دهد:

• Leader-based (مثل PostgreSQL و MySQL): یک سرور اصلی برای نوشتن، بقیه فقط می‌خوانند

• Multi-leader (مثل دیتابیس‌هایی که در چند منطقه جغرافیایی کپی می‌شوند): چند سرور می‌توانند بنویسند، اما هماهنگی سخت‌تر است

• Leaderless (مثل Cassandra و DynamoDB): همه سرورها می‌توانند بنویسند و بخوانند، با سازگاری نهایی (Eventually Consistent)

هر کدام از این روش‌ها هزینه‌ها و ریسک‌های خاص خودشان را دارند. کلپمن به تفصیل نشان می‌دهد که در کدام شرایط کدام روش مناسب است.

بخش‌بندی (Partitioning) و شاردینگ (Sharding): وقتی یک جدول در دیتابیس آنقدر بزرگ می‌شود که روی یک سرور جا نمی‌شود، باید آن را به چند قطعه (Partition) تقسیم کنیم. اما چطور تصمیم می‌گیریم که کدام داده به کدام پارتیشن برود؟ بر اساس کلید؟ بر اساس بازه؟ بر اساس هش؟ کلپمن Trade-offهای هر روش را توضیح می‌دهد.

تراکنش‌ها و سازگاری (Transactions & Consistency): این بخش از نظر فنی سخت‌ترین بخش کتاب است. کلپمن معرفی می‌کند:

• ACID و اینکه چرا در سیستم‌های توزیع‌شده نمی‌توان به طور کامل به آن دست یافت

• سازگاری خطی (Linearizability) : قوی‌ترین مدل سازگاری، که می‌گوید همه سرورها باید یکسان ببینند

• سازگاری نهایی (Eventual Consistency): مدلی که در آن داده ممکن است مدت کوتاهی بین سرورها ناهماهنگ باشد، اما نهایتاً هماهنگ می‌شود

• تناقض‌های CAP (Consistency, Availability, Partition Tolerance): و اینکه چرا نمی‌توان هر سه را همزمان داشت

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

داده در حرکت؛ ردازش دسته‌ای و جریانی (Batch & Stream Processing)

تا اینجا کتاب درباره داده در حال استراحت (Data at Rest) بود؛  یعنی داده‌های ذخیره شده روی دیسک. حالا نوبت داده در حال حرکت (Data in Motion) است یعنی داده‌هایی که مدام در حال تولید و پردازش هستند.

پردازش دسته‌ای (Batch Processing): روش سنتی پردازش حجم عظیم داده؛ مثلاً یک بار در روز، همه داده‌های دیروز را بگیریم، روی آنها عملیات MapReduce اجرا کنیم، و نتیجه را ذخیره کنیم. مثال: الگوریتم‌های قدیمی گوگل.

پردازش جریانی (Stream Processing): روش مدرن؛  داده به محض ورود پردازش می‌شود، بدون اینکه منتظر بمانیم تا یک دسته کامل جمع شود. ابزارهایی مثل Apache Kafka, Apache Flink, Spark Streaming. کلپمن توضیح می‌دهد چطور سیستم‌های امروزی مثل اوبر، نت‌فلیکس، و توییتر از این روش برای پردازش لحظه‌ای استفاده می‌کنند.

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

نظر شخصی من

نقطه قوت اصلی کتاب، شفافیت و بی‌طرفی آن است. کلپمن به جای اینکه بفروشد، آموزش می‌دهد. او صادقانه درباره محدودیت‌های هر ابزار، شکست‌های معروف (مثل مشکلات سازگاری دیتابیس‌های توزیع‌شده در آمازون و گوگل در دهه ۲۰۰۰)، و Trade-offهایی که باید بپذیری صحبت می‌کند.

نقطه ضعف اینه که سنگین است. واقعاً سنگین. اگر کمتر از ۳ سال تجربه عملی در بک‌اند داشته باشی، احتمالاً گم می‌شوی. بعضی فصل‌ها به قدری فشرده هستند که خواندن ۱۰ صفحه ممکن است یک هفته طول بکشد. این کتاب را نمی‌توان یک‌شبه خواند. باید با حوصله، و با زدن وقفه‌های طولانی جلو رفت.

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

این کتاب برای چه کسانی است؟

کتاب برای تازه‌کاران مطلق مناسب نیست. حداقل دو سال تجربه عملی با یک دیتابیس تولیدی (PostgreSQL, MySQL, MongoDB یا مشابه) و آشنایی با اصول پایه شیءگرایی و API design توصیه می‌شود.

 نقل قول‌های کلیدی از کتاب

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

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

بزرگترین خطر در طراحی سیستم‌های داده، این نیست که ابزار اشتباه انتخاب کنی. این است که ندانی چه Trade-offهایی داری، و بعداً وقتی سیستم زمین می‌خورد، غافلگیر شوی.

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

بعد از این کتاب، چه بخوانیم؟

سخن پایانی

کتاب Designing Data-Intensive Applications، فقط یک کتاب فنی نیست. یک نقشه راه برای تبدیل شدن از یک توسعه‌دهنده معمولی به یک مهندس سیستم‌های مقیاس‌پذیر است. به تو یاد می‌دهد که دیگر کاربر ابزارها نباشی، بلکه «طراح زیرساخت‌ها» شوی.

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

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