اگر از SQLite استفاده میکنید، احتمالاً با این واقعیت تلخ روبرو شدهاید که در لحظه تنها یک کاربر میتواند در فایل بنویسد. تداخل در نوشتن موازی در پایگاهدادههای محلی معمولاً توسعهدهندگان را مجبور میکند بین سادگی SQLite و سربارهای سنگین یک سرور کامل (مانند PostgreSQL یا MySQL) یکی را انتخاب کنند. BriskDB این بنبست را با توزیع دادهها بین چندین فایل مستقل میشکند تا عملیات نوشتن بهصورت موازی و بدون تداخل انجام شود. این ابزار با مسیریابی دادهها به چندین فایل SQLite، اجازه میدهد تکههای مختلف (Shards) از طریق قفلهای WAL اختصاصی خود، عملیات نوشتن را بهطور همزمان پردازش کنند.
بسیاری از توسعهدهندگان بهدلیل عدم نیاز به پیکربندی (Zero-config)، به SQLite اعتماد میکنند؛ اما با رشد برنامه، قفل تکنویسنده (Single Writer Lock) به یک گلوگاه تبدیل میشود. در حالی که ابزارهایی مثل rqlite یا Turso بر روی دسترسی بالا (High Availability) یا همگامسازی در لبه (Edge Synchronization) تمرکز دارند، یک شکاف عملیاتی برای «تکهبندی در یک میزبان» (Same-host Sharding) وجود دارد که شفافیت سطح فایل را حفظ کند. BriskDB در نسخه آلفای خود دقیقاً برای پر کردن این فضای میانی وارد شده است. در این راستا، برای کسانی که به دنبال بهینهسازیهای مشابه در لایه خواندن هستند، مقایسه DuckDB و SQLite دیدگاههای جالبی درباره افزایش ظرفیت پردازش دادهها ارائه میدهد.
همانطور که در تحلیلهای پیشین ما درباره بهینهسازی لایههای ذخیرهسازی اشاره کردیم، حذف گلوگاههای I/O کلید مقیاسپذیری در سیستمهای محلی است. BriskDB دقیقاً همین نقطه را هدف قرار داده است.
معماری مسیریابی
بر اساس مستندات این پروژه، هسته مرکزی BriskDB یک موتور مسیریاب است که با زبان Rust نوشته شده و نسبت به پروتکلها خنثی است. این موتور یک مسیریاب (Router) را مدیریت میکند که دادهها را بین ۴۰۹۶ سطل مجازی (Virtual Buckets) توزیع کرده و سپس آنها را به N فایل فیزیکی SQLite متصل میکند. از آنجا که هر تکه (Shard) یک پایگاهداده استاندارد با قابلیت WAL (Write-Ahead Logging) است، هر کدام قفل نویسنده مستقل خود را دارند.
این طراحی تضمین میکند که نوشتن در تکههای مختلف بهصورت موازی پیش برود. سیستم BriskDB کد SQLite را تغییر نداده یا آن را فورک نکرده است؛ بلکه یک لایه مسیریابی و حفاظهای عملیاتی به آن افزوده است. به این معنا که هر تکه داده همچنان یک فایل استاندارد است و با هر ابزار SQLite موجود قابل بررسی و بازرسی است. لایههای پروتکل، معناشناسی پایگاهداده را مدیریت نمیکنند؛ بلکه وظایفی مثل مسیریابی، اعمال محدودیتها، لغو عملیات (Cancellation)، مدیریت مقادیر، نشستها (Sessions) و اجرا در موتور Rust متمرکز شدهاند. این جداسازی ساختاری، فضا را برای افزودن پروتکلها و آداپتورهای ذخیرهسازی بیشتر در آینده باز میگذارد.
سازگاری با پروتکلها و دسترسی
طبق اعلام توسعهدهندگان، BriskDB سه مسیر اصلی برای تعامل با دادههای تکهبندیشده فراهم میکند:
- پروتکل PostgreSQL: این لایه از احراز هویت TLS/SCRAM-SHA-256 و استریم ردیفها با قابلیت Backpressure پشتیبانی میکند. این یعنی ابزارهای استانداردی مثل
psql،tokio-postgres،psycopgیا SQLAlchemy میتوانند مستقیماً به آن متصل شوند. همچنین پشتیبانی از CRUD متنی/باینری، لغو عملیات از طریق SQLite-interrupt و تراکنشهای واقعی در سطح تک-تکه (Single-shard transactions) فراهم شده است. - رابط HTTP API: یک مسیر محدود برای پرسوجوها و نوشتن دادهها. همچنین یک مرورگر دادههای فقط-خواندنی و پاسخگو در مسیر
/adminوجود دارد که ردیفهای تکهبندیشده را در یک نمای منطقی واحد ترکیب کرده و مقادیر اعداد صحیح بزرگ (Large Integers) را حفظ میکند. برای تستهای آلفای محلی، این بخش در آدرسhttp://127.0.0.1:7654/adminبا نام کاربری و رمز عبورadminدر دسترس است. لازم به ذکر است که این اعتبارنامههای موقت صرفاً برای راحتی توسعه هستند و یک مرز امنیتی محسوب نمیشوند؛ به همین دلیل سرور در حال حاضر از پذیرش آدرسهای HTTP غیر از loopback امتناع میکند. - APIهای جاسازیشده (Embedded): کتابخانههای بومی Rust (Crates) و Python Wheels اجازه میدهند موتور مستقیماً درون فرآیند برنامه (In-process) اجرا شود. در Rust، نقطه ورود از طریق
BriskDb::open()یا یک Builder تایید شده است. در پایتون، موتور از طریق یک افزونه بومی با APIهای sync و asyncio اجرا میشود. کاربران میتوانند از متدDatabase.serve()برای متصل کردن شنوندههای HTTP یا PostgreSQL استفاده کنند.
برنامههای آینده شامل پشتیبانی از پروتکلهای بومی MongoDB (با هدف رسیدن به برابری با TinyMongo در زمینه BSON، پرسوجوها، بهروزرسانیها، ایندکسها، کرسرها و Aggregation) و همچنین MySQL است که همگی از همان منطق مسیریابی Rust استفاده خواهند کرد. در کنار این پیشرفتهای زیرساختی، ابزارهایی برای تسهیل تعامل با دادهها در حال ظهورند؛ برای مثال مدلهای SQRL با بازبینی پیشفرض دادهها، دقت تبدیل متن به SQL را بهطور چشمگیری افزایش دادهاند.
حل مشکل تداخل شناسهها (ID Collision)
تکهبندی معمولاً سادگی کلیدهای AUTOINCREMENT را از بین میبرد چون دیگر یک قفل مرکزی برای هر ردیف در کل سیستم وجود ندارد. BriskDB دو مکانیزم آزمایشی و اختیاری (Opt-in) برای تولید شناسههای بدون تداخل در تمام تکهها معرفی کرده است:
۱. native_range_v1: در این روش، هر تکه یک محدوده ۶۴ بیتی مثبت و غیرهمپوشان دریافت میکند. سپس خودِ SQLite از طریق INTEGER PRIMARY KEY AUTOINCREMENT تخصیص محلی را انجام میدهد و نیاز به یک نوشتن مرکزی برای هر ردیف حذف میشود.
۲. hilo_v1: این روش بلوکهای ۴۰۹۶ تایی از شناسهها را بهصورت پایدار از مانیفست اجاره میکند. سپس این شناسهها را در حافظه تخصیص داده و هر شناسه را از طریق هش مسیریابی میکند. اگرچه ممکن است در اثر کرش کردن سیستم، شکافهایی در توالی شناسهها ایجاد شود، اما هیچ شناسهای هرگز دوباره استفاده نمیشود.
هر دو سیاست در مانیفست نسخهبندی شدهاند تا یکپارچگی در محیط تکهبندیشده تضمین شود. اجرای کلیدهای تولیدشده همچنان در وضعیت آزمایشی است.
حفاظهای عملیاتی و محدودیتها
به نقل از مستندات گیتهاب، این پروژه در وضعیت آلفا است و برای محیطهای عملیاتی (Production) آماده نیست. مرزهای توانایی سیستم بهطور صریح مشخص شده و نتایج اندازهگیری شده حتی در صورتی که مطلوب نباشند، منتشر شدهاند. سیستم در حال حاضر فاقد تراکنشهای اتمیک (Atomic Transactions) سراسری بین چندین فایل تکه است و هنوز نقشها (Roles) یا مجوزهای دسترسی (Authorization) را در پیادهسازی PostgreSQL پشتیبانی نمیکند.
یکپارچگی و یکتایی جهانی از طریق ایندکسهای ناهمگام (Asynchronous Indexes) مدیریت میشود که از فیلترهای بلوم (Bloom Filters)، واترمارکها (Watermarks) و خلاصههای min/max استفاده میکنند. این سازوکار مانع از آن میشود که فرآیندهای بهینهسازی، ردیفها را هنگام پاکسازی تکهها (Shard Pruning) بهطور خاموش پنهان کنند. برای نظارت، نقاط انتهایی (Endpoints) مخصوصی مانند /health ،/metrics و /v1/admin/global-indexes برای ردیابی تأخیر، تعمیرات، بازسازیها، تداخلها و فشار Outbox در دسترس است. گزارشهای عملیاتی Rust نیز دید عمیقتری از وضعیت موتور فراهم میکنند.
استقرار و یکپارچهسازی
توسعهدهندگان میتوانند BriskDB را بهعنوان یک سرویس مستقل یا بهصورت جاسازیشده (Embedded) مستقر کنند. نسخه لینوکس شامل بستههای .deb و سرویسهای سختگیرانه systemd است. برای کاربران پایتون، یک Wheel بومی از طریق pip در دسترس است (python -m pip install --only-binary=:all: briskdb) که اجازه میدهد موتور بدون نیاز به کامپایلر Rust مستقیماً در فرآیند اجرا شود. نسخههای تگشده، Wheelهای cp39-abi3 را برای ماتریس پلتفرمهای پشتیبانیشده منتشر میکنند، در حالی که نسخههای استخراج شده از مخزن به Rust 1.85+ نیاز دارند.
دسترسی چند-فرآیندی برای سیستمفایلهای محلی در یک میزبان پشتیبانی میشود؛ یعنی فرآیندهای مجزای پایتون، Rust و سرور میتوانند یک دایرکتوری ریشه آماده را به اشتراک بگذارند. اما برای جلوگیری از فساد دادهها، عملیات مهاجرت طرح (Schema Migration)، بهروزرسانی کاتالوگ و بازیابی دادهها نیازمند مالکیت انحصاری (Sole-process ownership) دایرکتوری دادهها است.
جزئیات فنی ذخیرهسازی
ساختار دایرکتوری BriskDB بهگونهای طراحی شده تا دادهها همواره قابل بازرسی باشند:
- manifest.sqlite: نسخههای مسیریابی، کاتالوگها، مهاجرتها و مالکیت شناسههای تولیدشده را مدیریت میکند.
- global-indexes/global.sqlite: دادههای معتبر برای یکتایی جهانی را ذخیره میکند.
- shards/: شامل فایلهای داده واقعی (مانند
0000.sqliteو0001.sqlite) است که در واقع پایگاهدادههای استاندارد SQLite با حالت WAL هستند. - قفلها: از فایلهای
.briskdb-process.lockو.briskdb-startup.lockبرای مدیریت دسترسی استفاده میکند.
مقایسه با ابزارهای مشابه
BriskDB جایگاه منحصربهفردی نسبت به پروژههای مبتنی بر SQLite دارد:
- SQLite: برای استفادههای کوچک، تکفایلی و جاسازیشده با یک نویسنده در هر فایل WAL ساخته شده است.
- rqlite: از طریق یک لاگ Raft برای دسترسی بالا (HA) بهینه شده است، در حالی که BriskDB برای مقیاسدهی عملیات نوشتن (Write Scaling) بهینه شده است.
- Turso / libSQL: بر روی دسترسی ابری/لبه و همگامسازی Local-first با مدلهای Push/Pull متمرکز هستند.
- Citus: یک خوشه توزیعشده بالغ از PostgreSQL است که از گرههای Coordinator و Worker استفاده میکند.
اگر به سرویسی محلی یا موتوری جاسازیشده نیاز دارید که تداخل نوشتن را در فایلهای قابل بازرسی پخش کند و با پروتکلهای آشنایی مثل PostgreSQL صحبت کند، BriskDB انتخاب مناسبی است. در مقابل، زمانی که یک فایل واحد SQLite، دسترسی بالای تکثیرشده، همگامسازی مدیریتشده در لبه یا یک خوشه بالغ چند-گره PostgreSQL نیاز باشد، ابزارهای دیگر اولویت دارند.
نقشه راه آینده
این معماری این فرض را تغییر میدهد که مقیاسدهی SQLite لزوماً به مهاجرت به یک خوشه توزیعشده نیاز دارد. با تبدیل سیستمفایل محلی به یک محیط تکهبندیشده، BriskDB اجازه میدهد توان عملیاتی نوشتن افزایش یابد در حالی که دادهها همچنان در قالبی باقی میمانند که برای انسان خوانا و با ابزارها سازگار است.
برای کسانی که از یک فایل واحد SQLite مهاجرت میکنند، پروژه یک واردکننده آفلاین (Offline Importer) برای انتقال دادهها به فرمت تکهبندیشده فراهم کرده است. اهداف آینده عبارتند از:
- ذخیرهسازی بدون سرور (Serverless Storage): پیادهسازی اسنپشاتهای اتمیک، آداپتورهای Object-store و عملیات تک-نویسنده محصور (Fenced) فراتر از الگوی فعلی warm-handler.
- گسترش پروتکلها: پیادهسازی کامل شنونده MySQL و سازگاری گستردهتر با کلاینتهای PostgreSQL.
- آداپتورهای ذخیرهسازی: اگرچه SQLite اولین بکاند است، اما مرزهای موتور بهگونهای طراحی شدهاند که برای سایر بکاندهای پایدار (Durable Backends) قابل استفاده باشند.
گذر از وضعیت آلفا به نسخه ۱.۰، بهویژه پیادهسازی پروتکل MongoDB و معرفی اسنپشاتهای آنلاین، مورد انتظار است. در حال حاضر پشتیبانی از بکآپ محدود به کپی کردن کامل دایرکتوری دادهها پس از خروج تمام سرورها و جاسازها است. چکپوینتهای غیرفعال (Passive Checkpoints) در حال حاضر تکهها، مانیفست و ذخیرهساز ایندکس جهانی را گزارش میکنند، اما هنوز اسنپشات آنلاین نیستند.
جزئیات پیادهسازی
برای شروع سریع، کاربران میتوانند Wheel بومی را نصب کرده و یک اسکریپت دمو را اجرا کنند. این دمو ۳۲ عملیات نوشتن مسیریابشده را از چهار رشته (Thread) پایتون اجرا میکند تا ثابت کند چهار فایل SQLite مجزا ردیفها را دریافت کردهاند. سپس هر ردیف را بازخوانی کرده، سلامت HTTP را بررسی میکند و در نهایت شنونده PostgreSQL را فعال میسازد. این دمو از یک دایرکتوری موقت استفاده کرده و پس از اجرا آن را پاک میکند.
برای اجرای سرویس مستقل، باینری را میتوان با پرچمهای زیر اجرا کرد:
--data-dir: محل ذخیرهسازی را مشخص میکند.--shards: تعداد فایلهای فیزیکی SQLite را تعیین میکند.--postgres-listen: شنونده PostgreSQL را روی یک آدرس خاص (مثلاً127.0.0.1:5433) فعال میکند.
جداول ثبتشده را میتوان از طریق درخواستهای HTTP POST به مسیر /v1/query با استفاده از Payloadهای JSON حاوی SQL و پارامترها استعلام کرد. برای کسانی که در Rust جاسازی میکنند، میتوان از پرچم default-features = false همراه با ویژگی embedded استفاده کرد تا لایههای شبکه و CLI از بیلد حذف شوند.
وضعیت آلفا و اعتبارسنجی
وضعیت فعلی آلفای BriskDB با قابلیتهای فعال و آزمایشی مشخص میشود. مسیریابی سطلهای مجازی پایدار، مسیریابی کلید دقیق (Exact-key routing) و خواندنهای محدود Scatter/Gather بهطور کامل کار میکنند. APIهای پرسوجو/نوشتن HTTP و مرورگر ادمین برای آدرسهای loopback فعال هستند.
ویژگیهای آزمایشی که در حال حاضر اختیاری (Opt-in) هستند عبارتند از:
- شناسههای تولیدشده Native-range و Hi/Lo.
- ایندکسهای بین-تکهای و اجارههای مقدار جهانی (که تستهای صحت، بازیابی و پاکسازی تکهها را پاس کردهاند، هرچند تأخیر و سربار نوشتن آنها در گزارشهای انتشار مستند شده است).
اعتبارسنجی برای مصنوعات منتشر شده بسیار سختگیرانه است. اوبونتو ۲۴.۰۴ x86-64 یک مجموعه کامل CI Rust دریافت میکند. Wheelهای پایتون تحت تستهای ساخت بومی، حسابرسی (Audit)، نصب، ریاستارت، بررسی فساد دادهها و همروندی در لینوکس و مک (x86-64 و ARM64) قرار میگیرند. در حالی که متریکهای عملیاتی ایندکس جهانی در دسترس است، پروژه هنوز فاقد یک مجموعه کامل برای لاگهای پرسوجوی کند، اشباع منابع و اعتبارسنجی ظرفیت در بازههای زمانی طولانی است.
گام بعدی شما
- اگر با محدودیت Write-lock در SQLite مواجهید، نسخه آلفای BriskDB را در محیط توسعه تست کنید.
- برای اتصال ابزارهای تحلیل داده، از پروتکل PostgreSQL این ابزار استفاده کنید تا بدون تغییر کد، مقیاس نوشتن را افزایش دهید.
- ساختار دایرکتوری
shards/را بررسی کنید تا مطمئن شوید دادههای شما همچنان با ابزارهای استاندارد SQLite قابل بازرسی هستند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما درباره تراشههای Blackwell مراجعه کنید.
گفتگو