معماری D1 برای مدیریت میلیون‌ها پایگاه داده چگونه مقیاس می‌گیرد
به گزارش Cloudflare، معماری سرویس پایگاه داده بدون‌سرور D1 بازطراحی شده است تا میلیون‌ها پایگاه داده را مدیریت کند، بی‌آنکه عملیات مدیریتی به گلوگاه مسیر اجرای کوئری‌ها تبدیل شود. این رویکرد برای پلتفرم‌های چندمستاجری و سرویس‌هایی اهمیت دارد که برای هر کاربر، برنامه یا محیط آزمایشی یک پایگاه داده جداگانه می‌سازند.
جداسازی مسیر کوئری از عملیات مدیریتی
D1 بر پایه SQLite ساخته شده و هر پایگاه داده آن با یک SQLite Durable Object پشتیبانی می‌شود. در معماری جدید، درخواست‌های مرتبط با داده در لبه شبکه اجرا می‌شوند؛ اما کارهایی مانند ساخت، حذف، فهرست‌کردن، واردکردن یا خروجی‌گرفتن از پایگاه داده در صفحه کنترل قرار می‌گیرند و در صورت نیاز می‌توانند به اجزای مرکزی متکی باشند. پردازش‌های تحلیلی و صورتحساب نیز به یک مسیر پس‌زمینه و غیرهم‌زمان سپرده شده‌اند.
Workers KV اطلاعات حیاتی مسیریابی را در نقاط مختلف شبکه نگه می‌دارد تا اجرای کوئری برای یافتن مقصد به Postgres مرکزی وابسته نباشد. Hyperdrive نیز برای اتصال به Postgres، تجمیع اتصال‌ها، مسیریابی بهینه، کش و استفاده از replicaهای خواندنی به کار می‌رود. هنگام ساخت پایگاه داده، سرویس ابتدا Durable Object را نزدیک محل درخواست مقداردهی می‌کند، سپس نگاشت و فراداده را در Postgres ثبت می‌کند و در پایان اطلاعات مسیریابی را در Workers KV قرار می‌دهد.
رشد سریع و سازوکار خوداصلاحی
طبق آمار ثبت‌شده تا ۸ اکتبر ۲۰۲۶، شمار پایگاه‌های داده زنده و حذف‌نشده D1 طی یک سال ۱۵ برابر و طی دو سال ۶۵ برابر شده است. تعداد پایگاه‌های داده فعال روزانه نیز در یک سال ۱۸ برابر رشد کرده؛ پایگاه داده‌ای فعال محسوب می‌شود که در همان روز دست‌کم یک کوئری اجرا کرده باشد.
برای تاب‌آوری در برابر خطا، مراحل ساخت با شناسه‌های تازه قابل تکرار هستند و ثبت موفق در Postgres نقطه قطعی ایجاد پایگاه داده به شمار می‌آید. هر Durable Object نیز تقریباً هر ۳۰ ثانیه، همراه با کمی تغییر زمانی برای پخش بار، وضعیت خود را با صفحه کنترل بررسی می‌کند. این ضربان دوره‌ای می‌تواند اشیای رهاشده را کنار بگذارد و اختلاف احتمالی میان Workers KV و وضعیت مرجع Postgres را اصلاح کند.
برای تیم‌های زیرساخت و توسعه، پیام اصلی این معماری روشن است: عملیات پرتکرار کاربران باید از اجزای متمرکز دور بماند و کارهای قابل‌تأخیر با صف، کش، replica و سازگاری نهایی مدیریت شوند. نتیجه، الگویی برای حفظ سرعت سرویس هم‌زمان با رشد تعداد منابع است.
