«یک هسته برتر از یک خوشه»؛ رویکرد جدید Spacetime در مقیاس‌پذیری

تصور کنید برای نوشتن یک رمان، به‌جای یک نویسنده، ۱۰ نفر را استخدام کنید که هر کدام در شهری دیگر باشند و فقط از طریق پست با هم هماهنگ شوند؛ نتیجه قطعاً کندتر از یک نویسنده تنها خواهد بود. این دقیقاً همان اتفاقی است که در پایگاه‌های داده توزیع‌شده هنگام مدیریت تراکنش‌های پرتنش رخ می‌دهد. در حالی که خوشه‌های توزیع‌شده اغلب به عنوان استاندارد طلایی برای رشد شناخته می‌شوند، یک پایگاه داده تک‌رشته‌ای می‌تواند در مدیریت تراکنش‌های با رقابت بالا، تا ۳۰۰ برابر مقیاس‌پذیرتر باشد. این تضاد غیرمنتظره، هسته فلسفه معماری Spacetime است که در یک تحلیل فنی منتشر شده در ۴ سپتامبر ۲۰۲۶ به تفصیل شرح داده شده است.

بسیاری از مهندسان مدرن پایگاه داده، مقیاس‌پذیری افقی (Horizontal Scalability) — یعنی توانایی اضافه کردن کامپیوترهای بیشتر برای انجام کار بیشتر — را هدف نهایی می‌دانند. این طرز فکر منجر به ظهور سیستم‌های مدیریت پایگاه داده رابطه‌ای توزیع‌شده (Distributed RDBMS) مانند CockroachDB، Google Spanner و Aurora DSQL شده است. هدف این سیستم‌ها مدیریت حجم نامحدودی از داده‌ها و درخواست‌ها از طریق پخش کردن حجم کاری در یک خوشه (Cluster) است.

اما Spacetime استدلال می‌کند که این رویکرد باعث ایجاد یک «مالیات هماهنگی» (Coordination Tax) می‌شود که عملکرد سیستم را در زمان تداخل داده‌ها نابود می‌کند. وقتی چندین تراکنش برای دسترسی به یک ردیف واحد می‌جنگند، زمانی که صرف توافق بین گره‌های شبکه برای تعیین برنده می‌شود، چندین مرتبه بیشتر از زمانی است که صرف انجام خودِ عملیات واقعی می‌شود.

مالیات هماهنگی

طبق گزارش spacetimedb.com، صنعت اغلب توانایی ذخیره داده‌های بیشتر را با توانایی پردازش تراکنش‌های بیشتر اشتباه می‌گیرد. آن‌ها سه بعد متمایز از مقیاس را شناسایی می‌کنند:

• محاسبات (Compute): چه تعداد تراکنش می‌توانند پردازش شوند.
• ذخیره‌سازی (Storage): چه مقدار داده می‌تواند نگهداری شود.
• شبکه (Networking): چه تعداد اتصال و چه مقدار پهنای باند پشتیبانی می‌شود.

در حالی که مقیاس‌پذیری افقی برای ذخیره‌سازی نسبتاً آسان است، برای محاسبات این‌گونه نیست. برای روشن شدن موضوع، این گزارش معماری‌های مختلف سازگار با PostgreSQL را مقایسه می‌کند. Postgres استاندارد اساساً یک پایگاه داده تک‌گره است که این ابعاد را به‌صورت افقی برای کاربر مقیاس نمی‌کند. تنها استثنا، نسخه‌های Read Replica هستند که به مقیاس‌پذیری شبکه و محاسبات کمک می‌کنند، اما ملاحظاتی را در مورد عملکرد و سازگاری «خواندن پس از نوشتن» (read-after-write consistency) ایجاد می‌کنند.

سیستم Neon، که یک نسخه تغییریافته است، ذخیره‌سازی را به‌صورت افقی مقیاس می‌کند؛ این کار را با پشتیبانی از جداول توسط ذخیره‌سازی اشیاء (Object Storage) و کشینگ صفحات محلی انجام می‌دهد. اگرچه تأخیر دسترسی به صفحات در صورت نبود در کش (Cache Miss) می‌تواند بالاتر باشد، اما این معماری عملاً ذخیره‌سازی نامحدودی را فراهم می‌کند. با این حال، مانند Postgres، تمام تراکنش‌های نوشتن باید به یک گره اصلی (Primary) ارسال شوند.

در مقابل، CockroachDB و Spanner تلاش می‌کنند هر سه بعد را با پخش داده‌ها در «بازه ها» (Ranges) در سراسر خوشه مقیاس کنند. بخشی از هر جدول روی هر ماشین ذخیره شده و معمولاً در دو ماشین دیگر تکثیر می‌شود. این معماری متقارن اجازه می‌دهد هر گره هر درخواست SQL را پاسخ دهد. برای محاسباتی که به‌راحتی موازی می‌شوند — مانند تحلیل‌های داده یا نوشتن در کلیدهای غیرمرتبط — این سیستم به‌صورت افقی مقیاس می‌گیرد. با این حال، گره‌ای که به پرس‌وجو متصل است همچنان باید طرح (Plan) را محاسبه کرده و تراکنش‌های توزیع‌شده را بر اساس آن بازه‌ها در خوشه اجرا کند.

در یک سیستم توزیع‌شده مانند CockroachDB، تراکنشی که روی یک هسته تنها ۳ میکروثانیه زمان می‌برد، به‌دلیل رفت‌وبرگشت‌های شبکه و کنترل هم‌روندی توزیع‌شده، می‌تواند به ۱ میلی‌ثانیه افزایش یابد. این اتفاق به این دلیل می‌افتد که داده‌ها به‌ندرت روی یک ماشین واحد قرار دارند و هیچ تراکنشی دسترسی انحصاری به یک بازه ندارد. هر تراکنش هزینه سربار کنترل هم‌روندی توزیع‌شده را می‌پردازد و تراکنش‌های متضاد باید منتظر بمانند، لغو شوند یا مجدداً تلاش کنند.

این تغییر از میکروثانیه به میلی‌ثانیه یک گلوگاه عظیم ایجاد می‌کند. یک کلید «داغ» (Hot Key) با یک بخش بحرانی ۳ میکروثانیه‌ای می‌تواند ۳۰۰,۰۰۰ تراکنش در ثانیه (TPS) را مدیریت کند. در مقابل، در حالت ۱ میلی‌ثانیه‌ای، همان کلید تنها ۱,۰۰۰ TPS را می‌پذیرد. در این سناریو، اضافه کردن کامپیوترهای بیشتر در واقع سیستم را کندتر می‌کند.

ریاضیات تداخل (Contention)

این فروپاشی عملکرد، کاربردی از قانون آمدال (Amdahl's Law) است. تراکنش‌های متداخل باید به‌صورت متوالی (Serial) اجرا شوند. توان عملیاتی کل هرگز نمی‌تواند از نرخ متوالی تقسیم بر کسر تراکنش‌های متوالی فراتر رود. برای مثال، اگر تنها ۱٪ از تراکنش‌ها روی یک ردیف واحد با کامیت‌های توزیع‌شده ۱ میلی‌ثانیه‌ای تداخل داشته باشند، حداکثر توان عملیاتی (۱ / ۱ میلی‌ثانیه) / ۱٪ = ۱۰۰,۰۰۰ TPS خواهد بود، فارغ از اینکه چه تعداد هسته اضافه شود.

سربار هماهنگی حتی در یک ماشین واحد نیز وجود دارد. Postgres باید بین هسته‌های CPU هماهنگ شود، جایی که تأخیر کش L1 تقریباً ۲۰ برابر کمتر از L3 است. اگر موازی‌سازی باعث تبدیل دسترسی‌های کش محلی به ارتباطات بین-هسته‌ای شود، یک سیستم ممکن است به بیش از ۱۰ هسته نیاز داشته باشد تا فقط با یک هسته بهینه‌شده برای کش برابری کند. این موضوع حتی هزینه بالاتر دسترسی به حافظه اصلی را (زمانی که دفترداری MVCC داده‌های مفید را از کش بیرون می‌راند) در نظر نمی‌گیرد.

Spacetime استدلال می‌کند که برای محاسباتی که ذاتاً متوالی هستند، نمی‌توانید ۱۰ ماشین را مجبور کنید کار را سریع‌تر انجام دهند — درست مانند اینکه اضافه کردن برنامه‌نویسان بیشتر به یک پروژه، اغلب به‌دلیل افزایش جلسات هماهنگی، توسعه نرم‌افزار را کندتر می‌کند. همان‌طور که در گزارش ذکر شده، ۱۰ نویسنده نمی‌توانند یک رمان را سریع‌تر از یک نفر بنویسند، به‌خصوص اگر هماهنگی آن‌ها از طریق پست سنتی باشد.

معماری Spacetime

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

پس از صرف بیش از ۱ میلیون دلار برای آزمایش اجرای موازی با استفاده از کنترل هم‌روندی چندنسختی (MVCC)، تیم کشف کرد که یک مدل تک‌رشته‌ای با یک «قفل بزرگ» (Big ol' lock) به‌سادگی عملکرد بهتری دارد. آن‌ها دریافتند که اجرای تک‌رشته‌ای در اندازه‌گیری‌های آن‌ها به‌طور مطلق از اجرای موازی پیشی می‌گیرد. این رویکرد بهینه‌سازی برای سخت‌افزار محدود، مشابه استراتژی‌هایی است که در حوزه‌های دیگر برای بهره‌وری حداکثری از منابع به کار می‌رود؛ برای مثال، موتور FreeToken توانست مدل عظیم GLM-5.2 را تنها روی یک GPU اجرا کند تا نشان دهد بهینه‌سازی هوشمندانه می‌تواند جایگزین سخت‌افزارهای حجیم شود.

به‌طور طراحی‌شده، هر پایگاه داده Spacetime به عنوان یک «اکتور» تک‌رشته‌ای عمل می‌کند. این کار نیاز به مکانیسم‌های پیچیده قفل‌گذاری و همگام‌سازی کش بین هسته‌های CPU را از بین می‌برد و به موتور اجازه می‌دهد عملکرد عمودی (Vertical Performance) را به حداکثر برساند. این یک نیاز حیاتی بود که از ساخت بک‌اند یک بازی MMORPG (بازی‌های آنلاین چندنفره گسترده) نشأت گرفت، جایی که تأخیر بسیار کم در تراکنش‌ها و توان عملیاتی بالا، غیرقابل مذاکره بود.

نقشه راه به سوی «مقیاس‌پذیری قطری»

علیرغم هسته تک‌رشته‌ای، Spacetime رشد را نادیده نمی‌گیرد. آن‌ها در حال پیاده‌سازی یک استراتژی شش مرحله‌ای برای مقیاس‌پذیری بدون قربانی کردن عملکرد محلی هستند، که عرضه اصلی آن تحت عنوان «Spacetime Continuum» برای ۳۱ اکتبر ۲۰۲۶ برنامه‌ریزی شده است.

جزئیات استراتژی مقیاس‌پذیری

• ۱. پایگاه‌های داده تکثیرشده (Replicated Databases): در حال حاضر، SpacetimeDB Cloud از تکثیر ماشین وضعیت توزیع‌شده استفاده می‌کند. این کار با کپی کردن کار رشته واحد در چندین ماشین، پایداری را تضمین می‌کند تا در صورت خرابی ماشین‌ها، پایگاه داده در دسترس بماند. بنچمارک‌ها نشان می‌دهند که پایگاه‌های داده تکثیرشده به همان توان عملیاتی پایگاه‌های داده تکثیر‌نشده (حدود ۳۰۰ هزار TPS) می‌رسند، به شرطی که پهنای باند شبکه و حافظه کافی برای عمق خط لوله (Pipeline Depth) وجود داشته باشد. به‌طور پیش‌فرض، confirmedReads(true) تضمین می‌کند که کلاینت‌ها تنها پس از رسیدن تراکنش‌ها به وضعیت پایدار در خوشه، داده‌ها را بخوانند.

• ۲. ارتباطات نامتقارن بین-داده‌ای (Asynchronous IDC): این قابلیت که در ۳۱ اکتبر ۲۰۲۶ عرضه می‌شود، به پایگاه‌های داده اجازه می‌دهد به عنوان اکتورهای مستقل عمل کنند. در مدل اکتور، هر شارد یک اکتور است که به‌طور مستقل زمان‌بندی می‌شود. تراکنش‌های داخل یک شارد سریع و محلی باقی می‌مانند، در حالی که ارتباطات بین-شارد به‌صورت نامتقارن از طریق APIهای تایپ-سیف TypeScript انجام می‌شود. برای مثال، یک توسعه‌دهنده می‌تواند از ctx.db.receivePlayer.insert({ msgId: 0n, target: regionDb, player }) استفاده کند تا پیامی ارسال کند که منجر به دقیقاً یک فراخوانی Reducer در پایگاه داده هدف شود.

• ۳. ذخیره‌سازی لایه‌ای (Tiered Storage): این قابلیت نیز در ۳۱ اکتبر ۲۰۲۶ می‌رسد و با حافظه به عنوان کش L4، دیسک به عنوان L5 و ذخیره‌سازی اشیاء به عنوان L6 برخورد می‌کند. برای جلوگیری از متوقف شدن رشته واحد به‌دلیل عملیات I/O، Spacetime از تکنیک «ضد-کشینگ» (Anti-caching) استفاده می‌کند (تکنیکی که در H-Store نیز به کار رفته است). اگر تراکنشی به داده‌های غیرمقیم در حافظه دسترسی پیدا کند، موتور آن را لغو می‌کند، داده‌ها را به‌صورت نامتقارن واکشی کرده و سپس تراکنش را مجدداً اجرا می‌کند.

  • Reducerهای قطعی (Deterministic Reducers): Spacetime به‌طور منحصر‌به‌فردی برای این کار مناسب است زیرا Reducerها نمی‌توانند I/O انجام دهند، ساعت را بخوانند یا اعداد تصادفی تولید کنند.
  • لغوهای بدون اثر (Zero-Effect Aborts): چون هر دسترسی به داده از طریق کانتکست Reducer می‌گذرد، لغو تراکنش‌ها هیچ اثر قابل مشاهده‌ای ندارد و هزینه اجرای مجدد تنها چند میکروثانیه CPU در برابر میلی‌ثانیه‌های I/O است.
  • مقایسه: این روش مشابه «پرس‌وجوهای شناسایی» (Reconnaissance queries) در Calvin (اجراهای آزمایشی برای پیش‌واکشی داده‌ها) و مرحله پیش‌واکشی صریح در TigerBeetle است.

• ۴. شبکه‌سازی افقی (Horizontal Networking): این پلتفرم از یک معماری متقارن برای «تجمع» (Fan-in) اتصالات نویسنده استفاده می‌کند و آن‌ها را روی یک اتصال واحد به گره لیدر مالتی‌پلکس می‌کند. برای «توزیع» (Fan-out) درخواست‌های خواندن، از نسخه‌های Read Replica سازگار استفاده می‌کنند. این نسخه‌ها لاگ تراکنش‌های لیدر را با همان ترتیب کلی اعمال می‌کنند. برای پرس‌وجوهای نقطه-در-زمان (Point-in-time)، لیدر یک شماره توالی اختصاص می‌دهد و نسخه Read Replica زمانی پاسخ می‌دهد که به آن آفست برسد، که تضمین می‌کند خواندن‌ها نسبت به هر نوشتی خطی (Linearizable) باشند.

• ۵. ارتباطات هم‌گام (Synchronous IDC): به‌روزرسانی‌های آینده یک پروتکل دو-مرحله‌ای (Two-phase commit) خط‌لوله‌ای را برای تراکنش‌هایی که مطلقاً به اتمیک بودن بین چندین پایگاه داده نیاز دارند، معرفی خواهند کرد. API آن شبیه به یک فراخوانی Reducer معمولی روی یک پایگاه داده خارجی خواهد بود: ctx.at(regionDb).reducers.receivePlayer(player). برای جلوگیری از نگه داشتن قفل پایگاه داده در طول رفت‌وبرگشت‌های شبکه، Spacetime مجدداً MVCC را به‌طور خاص برای این تراکنش‌های توزیع‌شده معرفی خواهد کرد. این پروتکل برای ایمنی با استفاده از TLA+ مدل‌سازی و بررسی شده است.

• ۶. بخش‌بندی درون-داده‌ای (Intra-database Partitioning): مرحله نهایی شامل ایجاد واحدهای اجرایی در یک پایگاه داده منطقی واحد است. برخلاف «بازه‌های» CockroachDB (که تصمیمات مربوط به جای‌گذاری هستند)، یک پارتیشن Spacetime یک واحد اجرایی با لاگ تراکنش متوالی و کد Reducer مخصوص به خود است. این امر اجازه می‌دهد یک آرتیفکت استقرار واحد و تغییرات اتمیک در Schema وجود داشته باشد، در حالی که تراکنش‌های مربوط به پارتیشن‌های مختلف می‌توانند به‌طور هم‌زمان اجرا شوند. Spacetime می‌تواند کل پارتیشن‌ها را بین ماشین‌ها جابجا کند تا بار را متعادل کند، بدون اینکه تضمین کند تراکنش‌های محلی هیچ هزینه‌ای بابت وجود پارتیشن‌های دیگر نمی‌پردازند.

اصل هزینه صفر (Zero-Overhead Principle)

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

این رویکرد به‌ویژه برای اپلیکیشن‌های Real-time مانند MMORPGها حیاتی است، جایی که الزامات شدید تأخیر، هماهنگی توزیع‌شده را به‌شدت گران می‌کند. برای مثال، BitCraft از این مدل با داشتن یک پایگاه داده ریشه برای داده‌های جهانی و چندین پایگاه داده منطقه‌ای برای بخش‌های مختلف جهان استفاده می‌کند؛ این کار اجازه می‌دهد تراکنش‌های منطقه‌ای سریع و محلی بمانند در حالی که مناطق به‌طور موازی اجرا می‌شوند.

تحلیل: تغییر پارادایم مقیاس‌پذیری

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

در رابطه با قضیه CAP، این گزارش تصریح می‌کند که CAP (سازگاری، در دسترس بودن، تحمل تقسیم شبکه) محدودیتی برای مقیاس‌پذیری نیست، بلکه انتخابی بین صحت (CP) و در دسترس بودن (AP) در زمان شکست شبکه است. پایگاه‌های داده OLTP باید سیستم‌های CP باشند زیرا ناسازگاری (خواندن داده‌های قدیمی یا نوشتن‌های متضاد) می‌تواند فاجعه‌بار باشد. گزارش اشاره می‌کند که مقاله اصلی Spanner هیچ اشاره‌ای به قضیه CAP نمی‌کند و این قضیه هیچ سخنی درباره توان عملیاتی یا تأخیر نمی‌گوید.

برای توسعه‌دهندگان، این بدان معناست که بار عملکرد از هماهنگی داخلی پایگاه داده به استراتژی شاردینگ (Sharding) توسعه‌دهنده منتقل می‌شود. اگر بتوانید داده‌های خود را به‌گونه‌ای سازماندهی کنید که ۹۹٪ تراکنش‌ها در داخل یک اکتور باقی بمانند، عملکرد یک هسته واحد را با قابلیت اطمینان یک خوشه ابری به دست می‌آورید.

این یک شرط‌بندی روی «مقیاس‌پذیری قطری» است — استفاده از کشینگ هوشمند و I/O نامتقارن برای اینکه یک نویسنده واحد احساس کند منابع نامحدودی دارد. این رویکرد این فرض را به چالش می‌کشد که گره‌های بیشتر همیشه برابر با قدرت بیشتر است.

منتظر عرضه ۳۱ اکتبر ذخیره‌سازی لایه‌ای باشید تا ببینیم آیا مدل «ضد-کشینگ» واقعاً می‌تواند توان عملیاتی ۳۰۰ هزار TPS را در حالی که داده‌ها را از ذخیره‌سازی اشیاء می‌گیرد، حفظ کند یا خیر.