هریپر با انتشار نسخه 5.2 نشان میدهد که نگهداشتن کدِ برنامه و داده در یک runtime میتواند در بارهای دارای دادهٔ زنده و شخصیشده، تاخیر را بهطور قابل ملاحظهای کاهش دهد و کارایی بالاتری نسبت به استکهای چندسیستمی ارائه کند.
معیارسنجیِ مقایسهای: تکرانتایم در برابر استکِ Vercel
تیم هریپر یک اپلیکیشن کاتالوگ ایموجی را دوبار پیادهسازی کرد: یکبار داخل هریپر که داده، محاسبه و پیامرسانی هممکان هستند و بار دیگر روی استکی مبتنی بر Vercel که Vercel Functions، Neon Postgres، Upstash Redis و Ably را ترکیب میکند. همان UI و قرارداد داده حفظ شد؛ تنها معماری متفاوت بود.
در خوانشهای درونپردازشی، هریپر میانگینِ حدود 0.4ms ثبت کرد، در حالی که عبور از شبکه در استک Vercel تقریباً 3ms تاخیر اضافه میکرد؛ شکافِ عملکردی با افزایش میزان شخصیسازی داده در صفحه بزرگتر میشود. آزمایشها در دو منطقهٔ ایالات متحده و در مجموع 474 تست بار طی سه دوره انجام شد.
چه زمانی هر کدام برتری دارند
- هریپر در مسیرهای دادهٔ زنده و شخصیشده — خوانشهای تک، مقادیر تزریقشده زنده، استریم سمت سرور و تازگی نوشتن تا خواندن — تا چندین برابر (تا حدود ~14×) بهتر عمل میکند.
- استک سرورلس مبتنی بر Vercel در محتوای قابل کش، تحویل از CDN و سناریوهای realtime محدود به broadcast عملکرد بهتری دارد.
- در بارهای fan-out بسیار بالا که نیاز به مقیاس افقی سریع دارد، autoscaling سرورلس ممکن است نسبت به یک نود ثابت برتری پیدا کند؛ بنابراین نتیجه به الگوی بار کاری وابسته است.
چرایی تأکید بر تکرانتایم
هریپر اینگونه استدلال میکند که هر پرش شبکه به معنی تاخیر بیشتر است؛ بنابراین خوانشهای شخصیشده نباید تبدیل به یک درخواست شبکه شوند، بلکه باید به فراخوانی تابعی روی یک جدول درونحافظهای تبدیل شوند. پیادهسازی این رویکرد متکی بر همگامسازی نسخهها میان نودها و پاسخدهی درونپردازشی از نزدیکترین نود به کاربر است.
برای مطالعهٔ بیشتر دربارهٔ مفاهیم جداسازی ذخیره و محاسبه میتوانید مطلب معرفی Lakebase و Databricks را بخوانید و برای مرجع فنی درباره PostgreSQL به ویکیپدیا مراجعه کنید.
ویژگیهای کلیدی نسخه 5.2
نسخهٔ 5.2 دو تغییر عملیاتی مهم دارد:
- کش رکوردی: خوانشهای تکراری را بهصورت قابل توجهی سریعتر سرو میکند؛ هریپر ادعا میکند سرعت خوانشها 5 تا 8 برابر افزایش یافته است.
- مسیر commit مجزا برای هر دیتابیس: نوشتنهای سنگین دیگر فرآیندهای نامرتبط را متوقف نمیکنند؛ با جداسازی commitها، p99 فراخوان فایلسیستم نامرتبط از 223.7ms به 2.6ms کاهش یافته است.
هریپر اشاره کرده که معیارسنجیها روی مجموعهدادهای گرم و در حافظه اجرا شدهاند؛ وقتی working set از حافظهٔ در دسترس فراتر رود، مزیتها ممکن است کاهش یابد. به عبارت دیگر، همواره تریدآف بین حافظه، مقیاس و هزینه وجود دارد.
چشمانداز طراحی سیستم
انتشار 5.2 این پرسش را مطرح میکند که برای اپلیکیشنهایی با نیاز به تازگی شدید داده و خوانشهای شخصیشده، جمعکردن کد و داده در یک runtime عملیاتی و اقتصادیتر است یا تفکیک لایهها با اتکا به CDN و سرورلس. پاسخ به الگوی ترافیک، حجم دادهای که میتوان در حافظه نگه داشت و نیاز به همگامسازی جهانی وابسته است. معماریهای تکرانتایم گزینهٔ جدیدی برای متعادلسازی تأخیر، هزینه و پیچیدگی عملیاتی ارائه میدهند و باید بهعنوان یکی از گزینههای طراحی سیستمهای مدرن در نظر گرفته شوند.
