SpacetimeDB ۲.۰: ایدهی خوب، بنچمارک بد
هوش مصنوعیخلاصهٔ کاملتر
SpacetimeDB این هفته نسخه ۲ رو با یه ویدیوی نسبتاً عجیب و میمگونه معرفی کرد که توش رقباشون رو مسخره میکنه (اصطلاح خودشون «اشک رقبا رو نوشیدن» بود) و یهسری بنچمارک نشون میده که به گفتهی نویسنده اصلاً واقعی نیستن. نویسنده میگه از این نوع تبلیغ خوشش نمیاد، ولی میخواد با انصاف کامل یه نقد فنی روی خود محصول بنویسه، چون به نظرش ایدههای جالبی توش هست.
مشکل اصلی بنچمارکها اینه که SpacetimeDB رو با دیتابیسهای توزیعشده و چندریجن مقایسه میکنن، درحالیکه SpacetimeDB یه چیز خیلی متفاوته: هم دیتابیسه هم سرور اپلیکیشن، یعنی کد خود اپ داخل دیتابیس اجرا میشه. نویسنده از تجربه خودش تو PlanetScale مثال میزنه: وقتی یه اکستنشن جستجوی برداری برای MySQL ساختن که داده رو روی دیسک نگه میداشت، میتونستن با مقایسه با pgvector (که باید همهچیز تو رم جا بشه) عددهای دههاهزار برابر سریعتر نشون بدن، ولی این مقایسه رو منتشر نکردن چون منصفانه نبود.
از نظر فنی، SpacetimeDB یه جدول هش درونحافظهست که کل دیتابیس پشت یه Read-Write Mutex سراسری (از کتابخونهی Rust به اسم parking_lot، که خودش پورتی از قفل WebKit هست) قفل میشه. همین باعث میشه اثبات linearizable بودن نوشتنها بدیهی باشه، چون همهچیز بهترتیب اجرا میشه؛ اما یعنی یه خوندن و یه نوشتن هم نمیتونن همزمان اتفاق بیفتن، و خوانندهها گاهی تا نیم میلیثانیه معطل میمونن.
کد اپلیکیشن بهصورت «reducer» به WebAssembly کامپایل میشه و با Wasmtime همون داخل بخش قفلشده اجرا میشه؛ یعنی موقع اجرای یه reducer نه فقط نوشتن، حتی خوندن دیگهای هم امکانپذیر نیست، و اصلاً اجازهی درخواست HTTP هم نداره. یه قابلیت جدید به اسم «Procedure» (هنوز Beta) اجازهی کارهای سنگینتر مثل HTTP رو میده، ولی چون تراکنشش هم قفل سراسری میگیره باید خیلی سریع تموم بشه؛ خوندنهای معمولی هم از طریق «View» انجام میشن که همزمان چندتاشون میتونن اجرا بشن ولی جلوی نوشتن رو میگیرن.
چون همهچیز درونحافظهست، برای دووم داده از یه Write-Ahead Log استفاده میکنن که همزمان با تراکنش نوشته نمیشه، بلکه هر ۵۰ میلیثانیه یهبار روی دیسک flush میشه؛ یه فلگ به اسم withConfirmedReads هست که میتونی باهاش تا وقتی داده واقعاً روی دیسک نشسته صبر کنی، اونم با تاخیر تا ۵۰ میلیثانیه. نویسنده این طراحی رو شبیه مونگوDB سال ۲۰۱۱ میدونه: بنچمارک چشمگیر با یه موتور ذخیرهسازی ضعیف که بعدها (با خرید WiredTiger) درست شد، ولی برند ضربهخورده رو سالها با خودش حمل کرد.
از نظر مقیاسپذیری، SpacetimeDB فقط عمودی رشد میکنه: چون دیتابیس و اپلیکیشن روی یه ماشین جا میگیرن، محدودیتش همون رم و CPU یه سرور تنهاست، نه یه سیستم توزیعشدهی واقعی. نویسنده میگه این طراحی برای بکاند بازی آنلاین (مثل BitCraft روی Steam) منطقیه، ولی برای بازار جدیدشون یعنی اپهای LLM دقیقاً بدترین انتخابه: یه خطای کوچیک تو کد تولیدشدهی LLM میتونه بخش قفلشده رو گیر بندازه و کل اپ رو از کار بندازه.
نکات کلیدی:
- SpacetimeDB نسخه ۲ با ویدیوی مسخرهکردن رقبا و بنچمارکهای ناعادلانه معرفی شد.
- کل دیتابیس پشت یه Read-Write Mutex سراسری (parking_lot) قفل میشه؛ خوانندهها تا ۰.۵ میلیثانیه معطل میمونن.
- کد اپلیکیشن («reducer») با WebAssembly داخل خود دیتابیس اجرا میشه و اجازهی HTTP نداره؛ «Procedure» (Beta) این محدودیت رو کمی باز میکنه.
- WAL هر ۵۰ میلیثانیه flush میشه؛ فلگ withConfirmedReads برای خوندنهای consistent موجوده.
- مقیاسپذیری فقط عمودیه؛ نویسنده میگه محصول واقعاً شبیه «Redis قویتر»ه نه دیتابیس رابطهای رقابتی.
- طراحی برای بکاند بازی آنلاین مناسبه ولی به نظر نویسنده برای اپهای LLM (بازار جدید تبلیغاتیشون) بدترین گزینهست.
