‏FokosDB: دیتابیسی روی Durable Objects کلادفلر

لامبروس پترو تو یک پست فنی مفصل توضیح می‌ده چطور FokosDB رو روی Durable Objects (DO) و بقیهٔ پلتفرم توسعهٔ کلادفلر ساخته. خودش شفاف می‌گه: هنوز production-ready نیست ولی به‌زودی می‌شه، محصول رسمی کلادفلر هم نیست، و بخش زیادی از کد با کمک AI نوشته شده ولی خط‌به‌خطش رو خونده و تقریباً همه‌جاش رو دست برده. شغل روزانه‌اش هم توی همون تیم پلتفرم توسعهٔ کلادفلره.

اصولی که معماری رو جلو بردن: ذخیره‌سازی بی‌انتها (بدون سقف عملی، در حد ترابایت)، consistency قوی (بنویسی و بلافاصله همون نسخه رو بخونی)، مقیاس‌پذیری throughput با زیادشدن آیتم‌ها، تأخیر «به‌اندازهٔ کافی خوب» (خوندن یک آیتم زیر ۵۰ میلی‌ثانیه تو یک کشور و زیر ۲۰۰ میلی‌ثانیه تو یک منطقه) و مقیاس‌پذیری خودکار بدون دخالت دستی.

مدل داده آشناست: هر آیتم با یک hash key و یک sort key شناخته می‌شه و آیتم‌های هم‌کلید بر اساس sort key مرتب می‌شن تا range query ممکن باشه. نویسنده پنهون نمی‌کنه که دیتابیس محبوبش DynamoDB‌ـه. عملیات اصلی putItem، getItem، deleteItem و به‌زودی queryItemsـه، همهٔ نوشتن‌ها conditional check دارن و تراکنش توزیع‌شده هم با transactWriteItems و transactReadItems پشتیبانی می‌شه. سقف هر آیتم به‌صورت پیش‌فرض ۵۰۰ کیلوبایته.

محدودیت‌های پلتفرم شکل معماری رو تعیین کردن: هر Worker و DO فقط ۱۲۸ مگابایت حافظه داره، هر DO تک‌نخی‌ـه و تقریباً هزار خوندن یا ۳۰۰ تا ۵۰۰ نوشتن در ثانیه جواب می‌ده، و هر DO مبتنی بر SQLite تا ۱۰ گیگابایت جا داره. نویسنده عمداً هر پارتیشن رو زیر ۱ گیگابایت (آستانهٔ پیش‌فرض ۵۰۰ مگابایت) نگه می‌داره، چون split و مهاجرت داده روی DOهای کوچیک‌تر خیلی سریع‌تره.

قلب معماری یک درخت B+ از Durable Objectهاست: گره‌های میانی فقط درخواست رو فوروارد می‌کنن و برگ‌ها داده رو نگه می‌دارن. پارتیشن‌های hash با hash key مسیریابی می‌کنن و پارتیشن‌های range با sort key. Worker اول hash key رو بین پارتیشن‌های ریشه هش می‌کنه و درخواست می‌ره پایین درخت؛ اگه توپولوژی تو کش (Workers KV) باشه، مستقیم می‌ره سراغ مالک آیتم. نکتهٔ ظریفش اینه که کش کهنه هم مشکلی نمی‌سازه: درخواست به هر حال از مسیر درخت به مقصد می‌رسه، پس کش فقط بهینه‌سازی کاراییه نه مکانیزم درستی.

وقتی حجم یک پارتیشن از آستانه رد بشه، split زمان‌بندی می‌شه: تعداد ثابتی فرزند ساخته می‌شن، داده ناهمگام مهاجرت می‌کنه و والد از اون به بعد فقط فورواردکننده‌ست. اگه یک hash key تنها ۳۰ تا ۵۰ درصد فضای پارتیشن رو بگیره، به پارتیشن range اختصاصی خودش ترفیع می‌گیره تا بعداً بر اساس sort key بشکنه. دو ماشین حالت split_status و migration_status کل جریان رو هدایت می‌کنن. نویسنده می‌گه همین مهاجرت داده بزرگ‌ترین پیچیدگی پروژه‌ست؛ تو بازهٔ مهاجرت هم نوشتن رد می‌شه و خوندن به والد برمی‌گرده.

تراکنش‌های توزیع‌شده هم بر پایهٔ طراحی timestamp ordering و پروتکل دومرحله‌ای DynamoDB (مقالهٔ USENIX ATC 2023) پیاده شدن، ولی نویسنده انحرافات رو هم می‌گه: فعلاً tie-breaking روی timestamp نداره، پس هر آیتم تو هر میلی‌ثانیه فقط یک نوشتن می‌پذیره و skew ساعت تو شبکهٔ کلادفلر این عدد رو بدتر هم می‌کنه.

نکات کلیدی:

• هر پارتیشن FokosDB یک Durable Object جداست و پارتیشن‌ها یک درخت B+ می‌سازن
• مدل داده hash key + sort key، الهام‌گرفته از DynamoDB، با consistency قوی و conditional writes
• کش توپولوژی تو Workers KV فقط بهینه‌سازیه؛ کش کهنه باعث خطا نمی‌شه چون درخت خودش مسیر رو اصلاح می‌کنه
• پر شدن پارتیشن → split؛ داغ شدن یک hash key → ترفیع به پارتیشن range اختصاصی
• بزرگ‌ترین پیچیدگی پروژه مهاجرت دادهٔ حین split‌ـه و تو اون بازه نوشتن روی پارتیشن رد می‌شه