تصور کنید برای دادههای تولیدی (Production) خود یک دکمهٔ «Undo» داشته باشید و هر تغییری را بتوانید به حالت قبل برگردانید. این رویای توسعهدهندگان با عرضه نسخه بتای DoltLite در ۱ سپتامبر ۲۰۲۶ به واقعیت تبدیل شد. قابلیتهایی مانند شاخهبندی (Branching)، ادغام (Merging) و تفاوتیابی (Diffing) که پیش از این فقط در سیستمهای کنترل نسخه مانند Git دیده میشد، اکنون برای یک بسته سازگار با SQLite در دسترس است. در واقع، پایگاهدادههای جاسازیشده (Embedded Databases) به طور موثری یک دکمه بازگشت برای دادههای عملیاتی خود به دست آوردند.
سالهاست که برنامهنویسان با SQLite مانند یک فایل ایستا یا ذخیرهساز ساده کلید-مقدار برخورد کردهاند. این ابزار با وجود قدرت زیاد، راهی بومی برای ردیابی تغییرات یا همکاری تیمی از طریق درخواستهای Pull و Push نداشت. DoltLite این مشکل را با جایگزینی لایه B-tree استاندارد با یک Prolly Tree حل کرده است؛ یک ساختار دادهای با آدرسدهی محتوایی (Content-addressed) که اجازه میدهد بدون بازنویسی کل موتور SQL، نسخهبندی کامل دادهها انجام شود. این تلاش برای ارتقای قابلیتهای SQLite، مشابه رویکرد پروژههای دیگری است که سعی دارند محدودیتهای این موتور را برطرف کنند؛ برای مثال پروژه BriskDB نیز با ترکیب SQLite و Rust تلاش کرد تا با استفاده از شاردینگ، مشکل نوشتنهای موازی را حل کند.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای دادهمحور اشاره کردیم، نیاز به همگامسازی دقیق در محیطهای توزیعشده همواره یک چالش بوده است.
به نقل از وبسایت dolthub.com، این پروژه در ابتدا به عنوان آزمونی برای Gas Town (یک ارکستراتور عاملهای هوش مصنوعی ساخته شده توسط استیو یگی) توسعه یافت. سازنده این ابزار میخواست به جای یک پروژه نمایشی و ساده، یک مسئله واقعی و مهندسی را حل کند. اگرچه تیم توسعه سالهاست که خواهان یک نسخه جاسازیشده از Dolt بودهاند، اما بازنویسی موتور ذخیرهسازی به زبان C یا Rust از نظر آنها «فراتر از توان» (a bridge too far) بود.
در نهایت، SQLite به عنوان میزبان منطقی برای این موتور انتخاب شد. جالب اینجاست که تیمی از عاملهای هوش مصنوعی (AI Agents) — شبیه به دستیاران دیجیتالی که میتوانند کارهای پیچیده مهندسی را به صورت مستقل انجام دهند — با ارسال حدود ۲,۰۰۰ درخواست Pull، این پروژه را به نسخه فعلی یعنی ۰.۵۰.۰ رساندند. این دستاورد ثابت میکند که تیمی از عاملهای هوش مصنوعی میتوانند یک وظیفه مهندسی پیچیده در این مقیاس را با موفقیت اجرا کنند.
DoltLite در واقع یک فورک (Fork) از SQLite است. این ابزار با حفظ لایههای تجزیه و تحلیل SQL (Parser)، تحلیلگر (Analyzer) و لایههای تعامل با سیستم فایل، سازگاری بالایی با نسخه اصلی دارد. این استراتژی به تیم اجازه داد تا از دشواریهای ساخت یک موتور SQL از صفر اجتناب کنند.
تفاوتهای کلیدی و مشخصات فنی این سیستم عبارتند از:
- موتور ذخیرهسازی: لایه B-tree با Prolly Tree جایگزین شده است که بر پایه یک ذخیرهساز تکفایلی (Chunk Store) کار میکند. Prolly Treeها در واقع B-treeهای با آدرسدهی محتوایی هستند که قدرت کنترل نسخه را به تمام محصولات Dolt میبخشند.
- سازگاری SQL: این مدل ۱۰۰٪ از ۵.۸ میلیون پرسوجوی پیچیده در مجموعه sqllogictest عبور کرده است.
- تفاوت در API: حدود ۹۹.۴۶٪ از ۸۹۲,۲۷۷ تست پذیرش مبتنی بر TCL در SQLite را پاس میکند. ۴,۸۰۹ مورد واگرایی (Divergence) شناخته شده وجود دارد که عمدتاً به این دلیل است که جداول به جای rowid بر اساس کلید اصلی (Primary Key) کلیدگذاری شدهاند و سیستم به جای صفحات (Pages) از تکهها (Chunks) استفاده میکند.
- قابلیت همگامسازی: از دستورات Git-style شامل Push، Pull، Clone و Fetch پشتیبانی میکند و DoltHub به عنوان بکاند همگامسازی عمل میکند. این سیستم یک موتور همگامسازی SQLite فراهم میکند که نسبت به تداخلات (Conflict-aware) حساس است.
- محدودیتها: به دلیل معماری خاص، هیچ فایل جانبی برای WAL یا Journal وجود ندارد؛ در نتیجه، تستهای مربوط به WAL و Journal نادیده گرفته شدهاند.
رسیدن به مرحله بتا به این معناست که فرمت ذخیرهسازی اکنون پایدار است. بر اساس مستندات پروژه، مراحل اولیه توسعه با «تغییرات مکرر فرمت ذخیرهسازی» (Storage format bumps) همراه بود که سازگاری عقبرو (Backward-compatible) نداشتند و کاربران را مجبور میکرد دادهها را به صورت دستی Dump کرده و دوباره Import کنند. ۱۲ بار تغییر فرمت لازم بود تا به این مرحله برسند. فرمت فعلی برای ۵۷ انتشار متوالی، یا بیش از سه ماه تقویمی، بدون تغییر مانده است. هرگونه تغییر سازنده در آینده، اکنون شامل یک مسیر مهاجرت (Migration path) پشتیبانیشده خواهد بود.
البته این قابلیتها هزینهای در عملکرد دارند. در حالی که سرعت خواندن دادهها تقریباً مشابه SQLite است، سرعت نوشتن کاهش یافته است. گزارشهای عملکرد روزانه که DoltLite را با SQLite در بنچمارکهای استاندارد sysbench مقایسه میکند، در گیتهاب منتشر میشود:
- در حافظه (In-Memory): خواندن ۱۰٪ کندتر و نوشتن ۶۰٪ کندتر است.
- پایگاهداده فایلی: سرعت خواندن برابر است و نوشتنهای دستهای (Batched) تنها ۱۰٪ کندتر هستند.
- نوشتنهای Autocommit: کندترین بخش است و ۳.۱ برابر کندتر از SQLite عمل میکند.
به طور مشخص، یک Runner کوچک در گیتهاب ثبت کرد که زمان نوشتن در SQLite حدود ۱۲۵ میکروثانیه بود، در حالی که در DoltLite این عدد به ۴۰۰ میکروثانیه رسید. توسعهدهندگان توصیه میکنند برای کاهش این تأخیر از نوشتنهای دستهای استفاده کنید، هرچند عملکرد همچنان در محدوده میکروثانیه (زیر یک میلیثانیه) باقی میماند.
این تغییر، فرض قدیمی را که پایگاهدادههای جاسازیشده باید «تخریبی» باشند یا برای نسخهبندی به Snapshotهای خارجی تکیه کنند، میشکند. با ادغام کنترل نسخه در لایه ذخیرهسازی، توسعهدهندگان اکنون میتوانند عاملهای هوش مصنوعی را روی دادههای محلی خود رها کنند و اگر عاملی باعث خرابی وضعیت دادهها شد، با یک دستور ساده dolt_reset('--hard') همه چیز را به حالت اول برگردانند.
برای کسانی که وضعیتهای پیچیده محلی را مدیریت میکنند یا روی مجموعهدادههای مشترک همکاری میکنند، این ابزار اصطکاک مربوط به خروجیها و ورودیهای دستی (Manual exports/imports) را از بین میبرد. شما اکنون میتوانید با پایگاهداده خود مانند یک کد منبع (Codebase) برخورد کنید.
کاربران در حال حاضر میتوانند نسخه بتا را تست کرده و به رابط گرافیکی Dolt Workbench دسترسی پیدا کنند که شامل یک حالت اختصاصی برای عاملها (Agent Mode) جهت دستکاری پایگاهداده است. پشتیبانی کاربران از طریق کانال doltlite🪶 در دیسکورد در دسترس است.
گام بعدی شما
- اگر از SQLite برای مدیریت وضعیتهای پیچیده محلی استفاده میکنید، نسخه بتای DoltLite را برای مدیریت نسخهها امتحان کنید.
- برای کاهش تأخیر در نوشتن، استراتژی Batched Writes را در اپلیکیشن خود پیاده کنید.
- رابط گرافیکی Dolt Workbench را برای مدیریت بصری دادهها و استفاده از حالت عامل (Agent Mode) بررسی کنید.
اما تأثیر این رویکرد بر مدیریت دادههای حجیم در لبه (Edge) حتی جذابتر است — به بررسی ما درباره رایانش لبه مراجعه کنید.
گفتگو