نگاهی به ۱۲ سال تکامل پایگاه داده‌های SQLite توزیع‌شده — Twelve Years of Distributed SQLite
خلاصه
این مقاله نگاهی دارد به تاریخچه دوازده‌ساله پروژه rqlite و ظهور دسته‌ای جدید از پایگاه داده‌های توزیع‌شده مبتنی بر SQLite. این نوشته سیر تکاملی از پروتکل‌های اجماع مثل Raft تا ابزارهای بک‌آپ‌گیری و پلتفرم‌های ابری را بررسی می‌کند و نشان می‌دهد که چگونه یک ایده متن‌باز ساده به یک ترند بزرگ در مهندسی نرم‌افزار تبدیل شد.
در سپتامبر ۲۰۱۴، «فیلیپ اوتول» (Philip O'Toole) با انتشار پروژه rqlite ایده ساده‌ای را عملی کرد: قرار دادن یک لایه لاگ Raft در جلوی SQLite و کپی کردن تمام عملیات نوشتن روی یک کلاستر تا از دست رفتن یک نود به قیمت از دست رفتن داده‌ها تمام نشود. این اولین سیستم متن‌بازی بود که Raft و SQLite را با هم ترکیب می‌کرد. حالا پس از گذشت دوازده سال، «SQLite توزیع‌شده» به یک دسته‌بندی بزرگ با پروژه‌های متعدد تبدیل شده است.
سال ۲۰۱۴: تولد rqlite
نیاز به این سیستم کاملاً ملموس بود. یک سیستم خوشه‌ای (Clustered) که نویسنده روی آن کار می‌کرد به مقدار کمی ذخیره‌سازی رابطه‌ای نیاز داشت و پروتکل‌های اجماع پاسخگوی این نیاز بودند. نسخه اول از کتابخانه goraft استفاده می‌کرد که در آن زمان ابزارهایی مثل InfluxDB و etcd نیز از آن بهره می‌بردند و در سال ۲۰۱۶ به پیاده‌سازی Raft توسط Hashicorp مهاجرت کرد که rqlite هنوز هم از آن استفاده می‌کند.
تصمیم معماری حیاتی rqlite این بود که به عنوان یک سیستم CP (سازگار و مقاوم در برابر پارتیشن‌بندی) طراحی شود:
- تمام عملیات نوشتن باید از طریق رهبر (Leader) انجام شود.
- اکثریت نودها باید عملیات را تایید کنند.
- اقلیت پارتیشن‌شده از پذیرش نوشتن سر باز می‌زند.
سال ۲۰۱۷ تا ۲۰۲۱: رقابت میان کتابخانه‌ها و رویکردهای جدید
در سال ۲۰۱۷، شرکت Canonical پروژه dqlite را توسعه داد تا برای ابزارهایی مثل LXD و MicroK8s یک ذخیره‌ساز داخلی و تکرارپذیر بدون نیاز به etcd فراهم کند. تفاوت اصلی dqlite و rqlite در نحوه بسته‌بندی آن‌هاست: dqlite یک کتابخانه قابل جاسازی (Embeddable) است، در حالی که rqlite یک سرور مستقل است.
در سال ۲۰۲۱، «بن جانسون» ابزار Litestream را معرفی کرد که بدون استفاده از پروتکل اجماع، فایل‌های WAL مربوط به SQLite را مانیتور کرده و آن‌ها را به S3 استریم می‌کند تا بازیابی فاجعه (Disaster Recovery) برای یک نود منفرد با کمترین هزینه ممکن شود. این ایده، جنبش «SQLite کافی است» را در جامعه برنامه‌نویسان سرعت بخشید.
سال ۲۰۲۲ و بعد از آن: ظهور کراس‌فرم‌ها و پلتفرم‌های ابری
در سال‌های اخیر، فضای طراحی SQLite توزیع‌شده به سه گوشه اصلی تقسیم شده است:
- اجماع (Consensus): مانند rqlite و dqlite که ثبات قوی و ساختار کلاستر دارند.
- استریمینگ (Streaming): مانند Litestream که روی بازیابی ارزان و تک‌نویسنده تمرکز دارد.
- ادغام (Merge): مانند cr-sqlite که با استفاده از CRDT امکان نویسندگان چندگانه و همگام‌سازی نهایی را بدون نیاز به رهبر فراهم می‌کند.
همچنین پروژه‌هایی مثل libSQL (پروژه منشعب‌شده توسط Turso) و محصولات ابری مانند Cloudflare D1 و Supabase نشان دادند که این ایده‌ها چگونه از نرم‌افزارهای متن‌باز به سرویس‌های ابری تجاری تبدیل شده‌اند.
چرا این موضوع برای مهندسان اهمیت دارد؟
مسیر دوازده‌ساله rqlite و اکوسیستم پیرامون آن نشان می‌دهد که ایده استفاده از SQLite به عنوان موتور ذخیره‌سازی و افزودن لایه تکثیر (Replication) از بیرون، یک الگوی پایدار و اثبات‌شده است. در حالی که ابزارهای تجاری و پلتفرم‌های ابری سرمایه‌های کلانی جذب کرده‌اند، rqlite همچنان به عنوان یک پایگاه داده رابطه ای مقاوم، قابل فهم و رایگان برای توسعه‌دهندگانی که می‌خواهند زیرساخت خود را شخصاً مدیریت کنند، یک انتخاب عالی باقی مانده است.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل