عنوان سخنرانی: Inverting the Backend: Why We Built our MMORPG Inside a Database
کنفرانس: Carnegie Mellon University Database Group - PostgreSQL vs. The World
سخنران:
Tyler Cloutier (CEO و هم‌بنیان‌گذار Clockwork Labs)
تاریخ ارائه: ۶ آوریل ۲۰۲۶
لینک ویدیو: https://youtu.be/-GhNDYCchqc?si=0j3y0gmqAEyl-Q_U
Tyler Cloutier، مدیرعامل و یکی از بنیانگذاران Clockwork Labs، در این سخنرانی در دانشگاه کارنگی ملون، داستان ساخت یک بازی MMORPG به نام Bitcraft را روایت می‌کند که در دل یک پایگاه داده رابطه‌ای به نام SpacetimeDB قرار گرفته است.
معماری سنتی بازی‌های آنلاین از سه لایه : کلاینت، سرور بازی، و پایگاه داده تشکیل شده است
سرور بازی منطق را اجرا می‌کند، وضعیت موقت را مدیریت می‌کند و با پایگاه داده برای ماندگاری ارتباط برقرار می‌کند. این جدایی باعث ایجاد مشکلاتی مانند عدم تطابق وضعیت، پیچیدگی هماهنگی و سربار شبکه می‌شود.
SpacetimeDB این معماری را وارونه می‌کند. در این رویکرد، کلاینت مستقیماً به پایگاه داده متصل می‌شود و سرور بازی به عنوان کد رویه‌ای درون پایگاه داده اجرا می‌شود. منطق بازی به صورت ماژول‌های WebAssembly یا JavaScript در پایگاه داده بارگذاری می‌شود و تمام تراکنش‌ها به صورت اتمیک و با قوام ACID اجرا می‌شوند.
ویژگی‌های کلیدی SpacetimeDB عبارتند از:
کاهنده‌ها-Reducers: رویه‌های ذخیره‌شده با قابلیت اجرای اتمیک و قطعی که منطق بازی را پیاده‌سازی می‌کنند.
اشتراک‌های پرس‌وجو: امکان دریافت به‌روزرسانی‌های بلادرنگ نتایج کوئری‌ها به صورت خودکار را می‌دهد.
مدیریت طرحواره یکپارچه: کد و طرحواره هم‌زمان نسخه‌بندی می‌شوند و از ناهماهنگی جلوگیری می‌شود.
احراز هویت OpenID Connect: امنیت اتصال مستقیم کلاینت به پایگاه داده را تضمین می‌کند.
قابلیت به‌روزرسانی داغ: امکان تغییر کد سرور بدون قطع ارتباط کلاینت‌ها را می‌دهد.
معماری داخلی SpacetimeDB:
پایگاه داده درون‌حافظه با گزارش کامیت و عکس‌های دوره‌ای
تکثیر داده‌ها از طریق OmniPaxos
مسیریابی درخواست‌ها توسط یک پایگاه داده کنترل مرکزی که جدول مسیریابی را نگهداری می‌کند
مدل هم‌روندی تک‌رشته‌ای با یک قفل بزرگ (که برای بسیاری از بازی‌ها عملکرد کافی دارد)
مقیاس‌پذیری از طریق چندین مکانیسم:
خواندن از کپی‌ها
جداول توزیع‌شده برای داده‌های با تأخیر بالا
پارتیشن‌بندی داده‌ها بر اساس کلید
ارتباط بین پایگاه‌داده‌ای با قابلیت تضمین پردازش دقیقاً یک‌بار
قابلیت اجرای کد روی کلاینت برای پیش‌بینی و کاهش تأخیر شبکه
این سخنرانی برای من بسیار جذاب بود و چندین نکته جدید و شگفت‌انگیز داشت.
اولین و مهم‌ترین نکته، مفهوم وارونگی باطن بود. این ایده که سرور بازی به طور کامل در پایگاه داده جاسازی شود و کلاینت مستقیماً با پایگاه داده ارتباط برقرار کند، کاملاً با معماری‌های سنتی که من با آنها آشنا بودم تفاوت دارد. این رویکرد بسیاری از مشکلات رایج در سیستم‌های توزیع‌شده مانند عدم تطابق وضعیت و سربار سریال‌سازی را حل می‌کند.
دومین نکته جالب، استفاده از WebAssembly برای اجرای منطق سرور در پایگاه داده بود. این رویکرد به توسعه‌دهندگان اجازه می‌دهد از زبان‌های برنامه‌نویسی معمولی مانند Rust، C# و TypeScript استفاده کنند و از محدودیت‌های زبان‌های خاص رویه‌های ذخیره‌شده مانند PL/pgSQL فرار کنند. این یک پیشرفت بزرگ در تجربه توسعه‌دهندگی است.
سومین نکته، اشتراک‌های پرس‌وجو بود. این قابلیت که کلاینت‌ها می‌توانند روی نتایج یک کوئری SQL مشترک شوند و به‌روزرسانی‌های بلادرنگ دریافت کنند، بسیار قدرتمند است. محاسبه افزایشی دلتاهای پرس‌وجو با استفاده از داده‌های تغییر یافته و موتور پرس‌وجوی تفاضلی، یک راه‌حل کارآمد برای پخش بلادرنگ وضعیت در بازی‌های آنلاین است.
چهارمین نکته، به‌روزرسانی داغ ماژول بود. توانایی تغییر کد سرور در حال اجرا بدون قطع ارتباط کلاینت‌ها، یک ویژگی شگفت‌انگیز است که در معماری‌های سنتی بسیار دشوار است. تظاهر فیزیک برخورد دایره‌ها که در دمو نشان داده شد، این قابلیت را به خوبی به تصویر کشید.
و در نهایت، اعتراف Tyler Cloutier در پایان سخنرانی که SpacetimeDB در واقع بیشتر یک سیستم‌عامل توزیع‌شده است تا یک پایگاه داده، بسیار جالب بود. این دیدگاه که نسل بعدی سیستم‌عامل‌ها باید پایگاه‌داده‌های توزیع‌شده را در دل خود داشته باشند، یک ایده بلندپروازانه و تحریک‌کننده است.
این سخنرانی ارتباط عمیقی با مباحث درسی معماری نرم‌افزار و پایگاه‌داده دارد.
ارتباط اول: معماری سنتی سه‌لایه یک الگوی رایج است که در بسیاری از سیستم‌ها استفاده می‌شود.
SpacetimeDB این الگو را با ادغام لایه‌های سرور و پایگاه داده به چالش می‌کشد و مزایا و معایب این رویکرد را نشان می‌دهد.
ارتباط دوم: استفاده از یک قفل بزرگ و مدل تک‌رشته‌ای در SpacetimeDB، یادآور بحث‌های کلاسیک در مورد هم‌روندی در پایگاه‌داده‌ها است. این رویکرد سادگی و عملکرد بالا را در ازای از دست دادن مقیاس‌پذیری افقی ارائه می‌دهد، که نشان‌دهنده مصالحه‌های اساسی در طراحی سیستم‌های توزیع‌شده است.
ارتباط سوم: رویکرد SpacetimeDB در تعریف طرحواره به عنوان بخشی از کد، مشابه ORMها است، اما با این تفاوت که هم‌زمانی و یکپارچگی بیشتری را فراهم می‌کند. این موضوع به مبحث مدیریت نسخه و مهاجرت‌های پایگاه‌داده در درس معماری نرم‌افزار مربوط می‌شود.
ارتباط چهارم: مدل بازیگر است. قابلیت ارسال پیام بین پایگاه‌داده‌ها در SpacetimeDB شباهت زیادی به مدل بازیگر در سیستم‌هایی مانند Akka و Erlang دارد و نشان‌دهنده تأثیر این الگو بر طراحی سیستم‌های مدرن است.
ارتباط پنجم: بهینه‌سازی عملکرد است. استفاده از پایگاه‌داده درون‌حافظه، گزارش کامیت، عکس‌های دوره‌ای، و محاسبه افزایشی دلتاها، همگی تکنیک‌هایی هستند که در درس‌های پایگاه‌داده و سیستم‌های توزیع‌شده بررسی می‌شوند.
با وجود نوآوری‌های چشمگیر، چند سوال و نکته انتقادی برای من ایجاد شد:
سوال اول: مدل تک‌رشته‌ای با قفل بزرگ، چقدر مقیاس‌پذیر است؟ سخنران اشاره کرد که برای بازی‌های MMO با چند گیگابایت داده، این مدل عملکرد خوبی دارد و تأخیر تراکنش‌ها زیر میلی‌ثانیه است. اما برای برنامه‌هایی با حجم داده بسیار بالا یا نرخ تراکنش خیلی زیاد، آیا این مدل به گلوگاه تبدیل نمی‌شود؟ راه‌کارهای پارتیشن‌بندی و جداول توزیع‌شده که مطرح شد، چقدر عملی هستند؟
سوال دوم: اتصال مستقیم کلاینت به پایگاه‌داده چه پیامدهای امنیتی دارد؟ اگرچه SpacetimeDB از احراز هویت OpenID Connect و مجوزهای مبتنی بر نما استفاده می‌کند، اما آیا این رویکرد به اندازه معماری سنتی با لایه سرور میانی امن است؟ آیا حملاتی مانند تزریق کوئری یا دسترسی غیرمجاز به داده‌ها در این مدل ساده‌تر نیستند؟
سوال سوم: قابلیت به‌روزرسانی داغ ماژول در حین اجرا، چه محدودیت‌هایی دارد؟ آیا هر تغییری در کد را می‌توان بدون قطع ارتباط اعمال کرد؟ اگر تغییری نیاز به تغییر ساختار داده داشته باشد، چه اتفاقی می‌افتد؟ مهاجرت‌های دستی که در حال توسعه هستند، چقدر پیچیده خواهند بود؟
نکته انتقادی: سخنرانی به شدت بر روی بازی‌های MMO متمرکز است و ادعا می‌کند که این رویکرد برای هر برنامه‌ای که نیاز به وضعیت تغییرپذیر بلادرنگ دارد، مفید است. اما من کنجکاوم که آیا SpacetimeDB برای برنامه‌های با تراکنش‌های تحلیلی پیچیده یا برنامه‌های با نیازهای گزارش‌گیری سنگین نیز مناسب است؟
این سخنرانی یکی از جذاب‌ترین ارائه‌هایی بود که در زمینه معماری نرم‌افزار دیده‌ام. SpacetimeDB با وارونه کردن معماری سنتی، نشان می‌دهد که چگونه بازنگری در مفروضات اساسی می‌تواند به راه‌حل‌های نوآورانه منجر شود. این پروژه جسورانه، اگرچه ممکن است برای همه موارد مناسب نباشد، اما پتانسیل بالایی برای ساده‌سازی توسعه برنامه‌های بلادرنگ و کاهش پیچیدگی سیستم‌های توزیع‌شده دارد.
مهم‌ترین درسی که از این سخنرانی گرفتم، این است که گاهی بهترین راه‌حل برای یک مشکل، ادغام اجزا به جای جداسازی آنهاست. جداسازی نگرانی‌ها یک اصل مهم در معماری نرم‌افزار است، اما این سخنرانی نشان می‌دهد که گاهی ادغام هوشمندانه می‌تواند مزایای قابل‌توجهی از نظر عملکرد، سادگی و کارایی ارائه دهد. تعادل بین این دو رویکرد، هنر معماری نرم‌افزار است.
همچنین، این سخنرانی اهمیت درک عمیق از نیازمندی‌های برنامه و طراحی راه‌حل‌های متناسب با آن را نشان می‌دهد. Clockwork Labs به جای استفاده از ابزارهای موجود و پذیرش محدودیت‌های آنها، تصمیم به ساخت ابزار مورد نیاز خود گرفت. این رویکرد، اگرچه پرریسک است، اما می‌تواند به مزیت رقابتی قابل‌توجهی منجر شود.
«اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»
Cloutier, T. (2026). SpacetimeDB → Inverting the Backend: Why We Built our MMORPG Inside a Database. Carnegie Mellon University Database Group. Retrieved from https://youtu.be/-GhNDYCchqc?si=0j3y0gmqAEyl-Q_U
SpacetimeDB Documentation. (n.d.). SpacetimeDB - The Database for Real-Time Applications. Retrieved from https://spacetimedb.com/
