دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که شرکت‌های بزرگ چطور حجم عظیمی از داده‌های انباشته‌شده را پردازش می‌کنند، وقتی هیچ کاربری پشت خط ننشسته و منتظر پاسخ آنی نیست؟ چطور می‌توان میلیاردها رکورد گزارش سرور را بدون اخلال در سرویس‌های آنلاین تحلیل کرد و از دل آن‌ها گزارش‌های دقیق بیرون کشید؟
این مبحث کلیدی از کتاب «طراحی برنامه‌های داده‌گرا» نوشتهٔ «مارتین کلپمن» است که به ما نشان می‌دهد چگونه پردازش داده‌ها فراتر از درخواست و پاسخ‌های آنلاین معنا پیدا می‌کند.
اولین ایدهٔ بنیادین، استفاده از رویکرد پردازش دسته‌ای (batch processing) پردازش آفلاین است. در این سیستم‌ها، ورودی حجم ثابتی از داده است که پردازش آن ممکن است دقایق یا روزها طول بکشد و هیچ کاربری منتظر نتیجهٔ فوری نیست. گزینهٔ جایگزین، سیستم‌های آنلاین هستند که برای پاسخ سریع به کاربر طراحی شده‌اند؛ اما تفاوت بزرگ پردازش دسته‌ای در این است که به جای بهینه‌سازی زمان پاسخ، روی توان عملیاتی متمرکز می‌شود تا بیشترین حجم داده را در کمترین زمان ممکن پردازش کند. برای نمونه، تحلیل لاگ‌های دسترسی وب‌سایت برای پیدا کردن پربازدیدترین صفحات در پایان روز، نمونه‌ای کلاسیک از این کار است.
ایدهٔ دوم، الهام گرفتن از فلسفهٔ ابزارهای یونیکس در مقیاس توزیع‌شده است. در سیستم‌های سنتی، برنامه‌ها ممکن است در حافظه کار کنند، اما ابزارهایی مانند دستورات مرتب‌سازی و خطوط لوله به کمک ما می‌آیند تا داده‌های بزرگ‌تر از حافظه اصلی را با کمک دیسک و الگوهای مرتب‌سازی و ادغام مدیریت کنند. مسئله این است که وقتی حجم داده‌ها از رم سیستم بیشتر می‌شود، روش‌های متکی بر جدول هش داخلی شکست می‌خورند. راه‌حل این است که داده‌ها را قطعه‌قطعه مرتب کرده و روی دیسک بنویسیم و سپس با ادغام‌سازی مرتب‌سازی‌شده آن‌ها را ترکیب کنیم، دقیقا مشابه همان کاری که ابزار مرتب‌سازی لینوکس برای مدیریت داده‌های عظیم انجام می‌دهد.
ایدهٔ سوم، معماری نگهداری داده‌ها روی یک سامانهٔ فایل توزیع‌شده است. برای پردازش در مقیاس هزاران ماشین، الگوریتم‌هایی مانند مپ‌ردیوز (MapReduce) معرفی شدند که داده‌ها را روی فایل‌سیستم توزیع‌شدهٔ هدوپ HDFS ذخیره می‌کنند. مسئله اصلی این است که چطور محاسبات را به جایی که داده قرار دارد ببریم تا از بار شبکه کاسته شود. گزینه‌ها شامل استفاده از ذخیره‌سازی متمرکز یا معماری بدون اشتراک است. معامله یا تریدآف در اینجا این است که ساختار بدون اشتراک نیازی به سخت‌سافزارهای گران‌قیمت شبکه ندارد و محاسبات مستقیماً روی گره‌های حاوی داده اجرا می‌شود. نمونهٔ عینی آن اجرای وظایف مپ و ردیوز روی همان ماشین‌هایی است که بلوک‌های فایل ورودی را ذخیره کرده‌اند.
ایدهٔ چهارم به چگونگی اجرای پیوستگی‌ها عمل جوین در پردازش‌های دسته‌ای مربوط می‌شود. وقتی بخواهیم لاگ فعالیت کاربران را با پایگاه دادهٔ پروفایل آن‌ها ترکیب کنیم، پرس‌وجوی تک‌تک رکوردها از پایگاه دادهٔ از راه دور عملکرد را به شدت پایین می‌آورد. گزینهٔ بهتر، کپی کردن پایگاه داده در همان فایل‌سیستم توزیع‌شده و استفاده از روش جوین کاهش‌یافته و مرتب‌سازی sort-merge join است. در این روش، کلیدها توسط مپ‌ردیوز مرتب و کنار هم قرار می‌گیرند تا ردیوز بتواند داده‌های مرتبط را بدون درخواست‌های شبکه و با کارایی بالا ترکیب کند.
پیشنهاد من این است که وقتی با حجم داده‌های تحلیلی کلان سر و کار دارید، به جای وابستگی به تراکنش‌های آنلاین و پرس‌وجوهای منفرد، از الگوهای پردازش دسته‌ای با داده‌های تغییرناپذیر استفاده کنید تا قابلیت اطمینان و خطایابی سیستم شما به‌شدت افزایش یابد.
در نهایت، این معماری‌های توزیع‌شده به ما یاد می‌دهند که جداسازی منطق برنامه‌نویسی از زیرساخت سیم‌کشی داده‌ها، کلید ساخت سیستم‌های داده‌گرا و مقیاس‌پذیر در دنیاست.