فصل دوازدهم: آینده سامانه‌های داده‌ای

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

این مبحث از کتاب «طراحی برنامه‌های داده‌گرا» نوشتهٔ «مارتین کلپمن» به بررسی آیندهٔ سیستم‌های داده‌گرا و الگوهای نوآورانه در معماری داده می‌پردازد.

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

دومین ایدهٔ کلیدی مقایسهٔ رویکرد دادهٔ مشتق‌شده (Derived Data) با تراکنش‌های توزیع‌شده است. دادهٔ مشتق‌شده یعنی مجموعه‌ای که از داده‌های دیگر طی یک فرایند قابل تکرار به دست می‌آید تا خواندن را سریع‌تر کند. تراکنش‌های توزیع‌شده با استفاده از قفل‌ها تلاش می‌کنند سازگاری ایجاد کنند، اما ویژگی‌های ضعیفی در تحمل خطا دارند. در مقابل، سیستم‌های مبتنی بر لاگ با استفاده از تغییر دادهٔ ضبط‌شده (Change Data Capture) که تکنیک ثبت تغییرات پایگاه داده برای اعمال به سایر سیستم‌هاست، داده‌ها را به شکل غیرهم‌زمان به‌روزرسانی می‌کنند که این روش جداسازی مؤلفه‌ها را بهبود می‌بخشد.

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

چهارمین ایدهٔ کلیدی اتحاد پردازش دسته‌ای و جریانی است. پردازش دسته‌ای (Batch Processing) روی داده‌های محدود و پایان‌پذیر کار می‌کند و توابع خالص و قطعی تولید می‌کند، در حالی که پردازش جریانی (Stream Processing) روی داده‌های بی‌نهایت و پیوسته عمل می‌کند. در گذشته معماری لامبدا تلاش می‌کرد هر دو سیستم را موازی نگه دارد، اما رویکردهای مدرن به دنبال یکی کردن آن‌ها در یک موتور واحد هستند که بتواند رویدادهای تاریخی را هم بازپخش کند و اجرا را به صورت دقیقاً یک‌بار (Exactly-Once) تضمین نماید؛ یعنی طوری که اثر نهایی عملیات حتی با وجود خطا دقیقاً یک بار اعمال شود.

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

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

این فصل به ما نشان می‌دهد که آیندهٔ سیستم‌های داده‌گرا در گرو گذر از انباره‌های صلب و حرکت به سوی جریان‌های انعطاف‌پذیر داده است.