دوازده سال SQLite توزیع شده

در سپتامبر 2014 من یک پست کوتاه منتشر کردم که rqlite را اعلام کرد. ایده ساده بود: SQLite را بگیرید، یک گزارش Raft در جلوی آن قرار دهید و هر نوشته را در یک خوشه تکرار کنید تا از دست دادن یک گره به معنای از دست رفتن داده ها نباشد. منبع در همان آخر هفته در GitHub منتشر شد. تا آنجا که من می توانم بگویم، این اولین سیستم منبع باز بود که Raft و SQLite را ترکیب کرد. هیچ کس دیگری این کار را انجام نمی داد و برای چندین سال هیچ کس دیگری تلاش نکرد.

امروزه «SQLite توزیع‌شده» مقوله‌ای است که ده‌ها پروژه را در خود جای داده است که تعدادی از آن‌ها با سرمایه‌گذاری مخاطره‌آمیز، دو مورد از آنها خریداری شده‌اند. از آنجایی که افرادی که اکنون در مورد این دسته می نویسند تمایل دارند داستان را در حدود سال 2021 شروع کنند، فکر کردم باید نسخه ای را که در سال 2014 شروع می شود، یادداشت کنم. من برای همه آن ها آنجا بودم.

نیاز ملموس بود. سیستم خوشه‌ای که در jut.io روی آن کار می‌کردم به مقدار کمی فضای ذخیره‌سازی رابطه‌ای نیاز داشت و این سؤال که کدام گره باید آن را نگه دارد، پاسخ خوبی نداشت. تکرار SQLite با پروتکل اجماع آن را حل کرد. ما راه دیگری را در محل کار رفتیم، اما من به ساختن rqlite ادامه دادم زیرا مشکل کلی بود و راه حل کوچک بود. نسخه اول از goraft استفاده می کرد، همان کتابخانه InfluxDB و etcd که در آن زمان استفاده می شد (من متعاقبا در همان زمان به عنوان یک توسعه دهنده اصلی به InfluxDB پیوستم). در اوایل سال 2016 آن را با اجرای Raft Hashicorp جایگزین کردم که rqlite هنوز از آن استفاده می کند.

تصمیم طراحی که بیشترین اهمیت را داشت در آن زمان گرفته شد و هرگز تغییر نکرد. rqlite یک سیستم CP است. نوشته ها باید از طریق رهبر انجام شود، اکثریت باید تصدیق کنند، و اقلیت تقسیم شده از نوشتن امتناع می ورزند. همه چیزهای دیگر، HTTP API، سطوح سازگاری خواندن، عکس فوری، به دنبال آن هستند.

دو چیز به خاطر صداقت شایسته ذکر است. Expensify سال‌ها SQLite را در زیرساخت‌های خود با پروتکل Paxos-style تکرار می‌کرد. آنها آن را به عنوان بستر در سال 2016 منتشر کردند. و ActorDB، یک سیستم Erlang که به هر "بازیگر" پایگاه داده SQLite خود را می داد که توسط Raft تکرار شده بود، تقریبا همزمان با rqlite ظاهر شد. هیچ یک به طور گسترده ای خارج از مبدأ خود پذیرفته نشد، اما هر دو نشان می دهند که این ایده در هوا بوده است. کاری که rqlite انجام داد این بود که آن را به چیزی مستقل، همه منظوره و منبع باز تبدیل کرد که هر کسی می توانست اجرا کند.

dqlite متعارف ساخته شده است تا LXD و بعدا MicroK8s یک فروشگاه تکراری جاسازی شده بدون اجرای etcd دریافت کند. مارک شاتل ورث در واقع یک بار با من تماس گرفت، و ما با هم صحبت کردیم، به این امید که rqlite بتواند کار کند، اما هرگز کاملا مناسب نبود. dqlite در Go شروع شد و در C با کتابخانه Raft خودش بازنویسی شد. این پروژه از نظر قصد شبیه ترین پروژه به rqlite است، و تفاوت اصلی آن در بسته بندی است: dqlite کتابخانه ای است که شما جاسازی می کنید، rqlite سروری است که شما اجرا می کنید. نیاز Canonical یک پایگاه داده در محصولات آنها بود: من یک پایگاه داده در کنار محصول هر کسی بود.

بن جانسون (که من با او در InfluxDB کار کردم) Litestream را در اوایل سال 2021 منتشر کرد. Litestream به هیچ وجه از اجماع استفاده نمی کند. SQLite WAL را تماشا می‌کند و آن را به S3 می‌فرستد، و تقریبا بدون هیچ هزینه‌ای، بازیابی فاجعه را برای یک پایگاه‌داده SQLite تک گره ارائه می‌کند. استدلال بن این بود که اکثر برنامه ها نیازی به خوشه ندارند. آنها از یک دستگاه استفاده می کنند و در صورت مرگ به راهی برای بازیابی نیاز دارند. او در مورد بسیاری از برنامه‌های کاربردی درست می‌گفت، و جنبش «SQLite کافی است» در چند سال آینده، با پست‌های وبلاگ و گفتگوهای کنفرانس، مدیون این بحث است.

Litestream و rqlite به سوالات مختلفی پاسخ می دهند. Litestream: اگر دستگاه بمیرد چه؟ rqlite: اگر دستگاه بمیرد و من نتوانم برای بازیابی صبر کنم چه؟ سوال اول رایج تر است، سوال دوم این است که وقتی مردم به rqlite می آیند با آن مواجه می شوند.

Fly.io در سال 2022 بن را استخدام کرد و LiteFS را ارسال کرد که SQLite را در سطح سیستم فایل با اجاره نامه Consul کپی می کند. این اولین تلاش برای تبدیل SQLite تکراری به‌جای چیزی که شما به کار می‌گیرید، به یک ویژگی پلتفرم تبدیل شد. و در آخرین پیچ، Litestream از رویکرد rqlite v8.0 برای مدیریت SQLite WAL الهام گرفت.

دو پروژه در سال 2022 رویکردهایی داشتند که نه rqlite و نه Litestream نداشتند. cr-sqlite CRDT ها را به عنوان یک افزونه به SQLite اضافه کرد، به طوری که چندین نویسنده بتوانند بدون یک رهبر از هم جدا شوند و ادغام شوند. این گوشه AP فضای طراحی است، و مناسب برنامه‌های محلی اول است که ضمانت‌های CP rqlite مانعی برای آن است.

libSQL خود SQLite را فورک کرد. ChiselStrike، بعدا Turso، می خواست چیزهایی را در داخل موتور تغییر دهد که پروژه SQLite، که مشارکت های خارجی را نمی پذیرد، و تغییر نمی داد. آنها در بالای چنگال یک سرویس میزبان با نسخه های مشابه در لبه ایجاد کردند. Turso از این طریق پول سرمایه گذاری جمع آوری کرد و در سال 2026 Supabase آنها را خریداری کرد.

تقریبا در همان زمان، SQLite Cloud ظاهر شد و SQLite میزبانی شده را با Raft ارائه کرد. این پروژه نزدیکترین پروژه به طرح اصلی rqlite است که در یک سرویس ابری پیچیده شده است.

Cloudflare D1 را در سال 2022 معرفی کرد، SQLite را به عنوان یک پایگاه داده بدون سرور در داخل شبکه لبه خود معرفی کرد و بعدا SQLite را در داخل Durable Objects قرار داد. این SQLite به عنوان یک محصول مدیریت شده از یک شرکت تکرار می شود که نیازی به توضیح نحوه عملکرد آن ندارد. سرویس تورسو به همین شکل است. مقوله از «چیزی که می دوید» به «چیزی که می خرید» تبدیل شده بود.

هسته درست بود. SQLite به عنوان یک موتور ذخیره سازی، با تکرار اضافه شده در خارج، توسط حداقل هشت تیم با نیازهای مختلف و پروتکل های مختلف دوباره اختراع شده است. هیچ کس دلیلی برای متوقف کردن این کار پیدا نکرده است.

فضای طراحی دارای سه گوشه است و به ترتیب ظاهر شده اند. اجماع اول (rqlite، dqlite): یک رهبر، قوام قوی، یک خوشه. جریان دوم (Litestream): یک نویسنده، بازیابی ارزان، بدون خوشه. ادغام سوم (cr-sqlite، و بخش‌هایی از جنبش محلی-اول): بسیاری از نویسندگان، سازگاری نهایی. هر کدام برای یک سوال متفاوت صحیح است و بیشتر استدلال ها بحث هایی است که بین کاربران آنها در مورد سوال پرسیده می شود.

و پول به سکوها رفت. rqlite، dqlite و Litestream منبع باز و رایگان هستند. پروژه هایی که سرمایه را افزایش دادند یا به دست آوردند، پروژه هایی هستند که SQLite تکراری را به یک سرویس با صورتحساب تبدیل کردند. این سرنوشت معمول ایده‌های زیرساختی است و من از آن ناراحت نیستم. اما شایان ذکر است که این ایده به مدت هشت سال قبل از اینکه کسی آن را بفروشد منبع باز بود.

rqlite هنوز اینجاست. این همان کاری را که در سال 2014 انجام داد، بسیار بهتر انجام می‌دهد، و همچنان چیزی است که وقتی می‌خواهید یک پایگاه داده رابطه‌ای مقاوم به خطا داشته باشید، می‌توانید خودتان آن را اجرا کنید، کاملا درک کنید و به هیچ‌کس پولی نپردازید. دوازده سال بعد، من به این موقعیت در داستان راضی هستم.