BriskDB: Biến các tệp SQLite thành một cơ sở dữ liệu phân mảnh với khả năng ghi song song

SQLite là một trong những công cụ lưu trữ dữ liệu phổ biến nhất nhờ tính đơn giản và độ tin cậy. Tuy nhiên, nó vốn nổi tiếng với hạn chế về khả năng ghi khi chỉ có một writer duy nhất cho mỗi tệp. BriskDB xuất hiện như một lớp trừu tượng hóa, biến nhiều tệp SQLite riêng lẻ thành một cơ sở dữ liệu phân mảnh (sharded database) thống nhất, cho phép ghi song song giữa các phân mảnh khác nhau.

Dự án ở giai đoạn alpha đang thu hút sự chú ý của cộng đồng nhờ cách tiếp cận độc đáo: không fork SQLite, không có khóa ghi tập trung, đồng thời cung cấp nhiều giao thức truy cập như PostgreSQL, HTTP, và các API nhúng cho Rust/Python. Điều này mở ra hướng đi mới cho các ứng dụng cần mở rộng quy mô ghi dữ liệu nhưng vẫn muốn giữ sự đơn giản và minh bạch của định dạng tệp SQLite.

Badge CI của BriskDB

Vấn đề mà BriskDB giải quyết

Một tệp SQLite thông thường chỉ cho phép một writer tại một thời điểm (write lock toàn cục). Khi ứng dụng cần ghi dữ liệu với tốc độ cao và số lượng lớn, đây trở thành một điểm nghẽn nghiêm trọng.

BriskDB giải quyết vấn đề này bằng cách chia dữ liệu thành nhiều "shard" – mỗi shard là một tệp SQLite WAL độc lập. Vì mỗi tệp có WAL writer lock riêng, các tiến trình ghi vào các shard khác nhau có thể diễn ra song song mà không cần chờ đợi lẫn nhau.

Kiến trúc một engine, nhiều giao thức

Điểm mấu chốt trong thiết kế của BriskDB là một engine Rust trung lập về giao thức (protocol-neutral Rust engine). Engine này chịu trách nhiệm về định tuyến, giới hạn tài nguyên, hủy lệnh, quản lý phiên và thực thi, trong khi các bộ chuyển đổi giao thức (PostgreSQL, HTTP) chỉ là lớp vỏ mỏng bên ngoài.

Kiến trúc phân lớp này mang lại lợi ích lớn:

• Nhất quán hành vi: Dù truy cập qua PostgreSQL, HTTP hay API nhúng, hành vi định tuyến và xử lý lỗi đều giống nhau.
• Dễ dàng mở rộng: Trong tương lai, dự án có kế hoạch hỗ trợ thêm giao thức MongoDB và MySQL trên cùng engine.
• Nhúng hoặc chạy dịch vụ: Cùng một engine có thể chạy như một binary độc lập, hoặc được nhúng trực tiếp vào ứng dụng Rust/Python.

Điểm độc đáo: ID sinh tự động an toàn cho phân mảnh

Việc tạo ID duy nhất toàn cục khi có nhiều shard là một bài toán kinh điển. BriskDB đưa ra hai chiến lược mới:

• native_range_v1: Mỗi shard được cấp một dải số nguyên dương 64-bit không chồng lấn. SQLite tự động cấp ID dựa trên INTEGER PRIMARY KEY AUTOINCREMENT trong phạm vi đó, không cần ghi tập trung cho mỗi hàng.
• hilo_v1: Thuê một khối 4.096 ID từ manifest, cấp phát trong bộ nhớ và định tuyến mỗi ID theo hàm băm. Nếu sự cố xảy ra có thể tạo ra khoảng trống, nhưng ID sẽ không bao giờ bị tái sử dụng.

Cả hai chiến lược đều được đánh phiên bản trong manifest và hiện đang trong giai đoạn thử nghiệm, yêu cầu người dùng chọn tham gia (opt-in).

Trải nghiệm 30 giây

Dự án cung cấp một bản demo đơn giản để người dùng có thể trải nghiệm ngay lập tức, không cần biên dịch:

python -m pip install --only-binary=:all: briskdb
curl -fsSLO https://raw.githubusercontent.com/schapman1974/briskdb/main/examples/launch_demo.py
python launch_demo.py

Script này sẽ thực hiện 32 lần ghi được định tuyến từ 4 luồng Python, chứng minh rằng tất cả 4 tệp SQLite phân mảnh đều nhận được dữ liệu, đọc lại toàn bộ dữ liệu, kiểm tra trạng thái HTTP và khởi động listener PostgreSQL. Demo tự dọn dẹp sau khi chạy.

Demo BriskDB

Vị trí của BriskDB trong hệ sinh thái cơ sở dữ liệu

BriskDB không nhắm đến việc thay thế các hệ thống như Citus hay Turso. Bảng so sánh sau đây giúp định vị dự án:

Dự án	Mục đích	Mô hình ghi	Truy cập	Hình thức lưu trữ
BriskDB	Phân mảnh cùng máy chủ, kết hợp dịch vụ và nhúng	Song song giữa các WAL shard độc lập	PostgreSQL, HTTP, Rust, Python	Manifest + các tệp SQLite thông thường
SQLite	Nhúng, tệp đơn, cơ sở dữ liệu nhỏ	Một writer mỗi file WAL	API SQLite và hệ sinh thái	Một tệp SQLite thông thường
rqlite	Khả năng sẵn sàng cao đa nút	Ghi thông qua log Raft, tối ưu cho HA	HTTP + thư viện client	SQLite được sao chép
Turso / libSQL	Truy cập cloud/edge và đồng bộ local-first	Phụ thuộc sản phẩm, push/pull	SDK + HTTP	Turso Database
Citus	PostgreSQL phân tán trưởng thành	Song song giữa các shard PostgreSQL	PostgreSQL	Cụm coordinator + worker

Hãy chọn BriskDB khi bạn cần một dịch vụ cục bộ duy nhất hoặc engine nhúng để dàn trải tranh chấp ghi trên các tệp SQLite có thể kiểm tra được, đồng thời nói chuyện với các giao thức cơ sở dữ liệu quen thuộc.

Ranh giới trung thực của giai đoạn alpha

Đội ngũ phát triển rất minh bạch về những giới hạn hiện tại:

• Không có giao dịch nguyên tử đa shard – một giao dịch chung cho nhiều tệp shard vẫn chưa được hỗ trợ.
• HTTP chỉ hoạt động trên loopback (127.0.0.1) ở giai đoạn hiện tại, như một bề mặt phát triển.
• Không có snapshot trực tuyến – sao lưu được hỗ trợ hiện tại là sao chép toàn bộ thư mục dữ liệu khi server đã dừng.
• Truy cập đa tiến trình chỉ giới hạn trong cùng máy chủ và hệ thống tệp cục bộ.
• Tương thích API và định dạng lưu trữ có thể thay đổi trước phiên bản 1.0.

Lộ trình phát triển

Hướng đi trong tương lai của BriskDB khá tham vọng:

1. MongoDB wire protocol: Listener Rust gốc với BSON, query, update, index, cursor và aggregation.
2. MySQL wire protocol: Mở rộng khả năng tương thích client.
3. Serverless storage: Snapshot nguyên tử, bộ chuyển đổi object-store và hoạt động ghi đơn writer được bảo vệ nghiêm ngặt.
4. Nhiều backend lưu trữ hơn: Engine được thiết kế để có thể gắn thêm các backend bền vững khác ngoài SQLite.

Badge License MIT

Kết luận

BriskDB là một dự án trẻ và đầy hứa hẹn, giải quyết một vấn đề thực tế của nhiều nhà phát triển: làm sao để mở rộng khả năng ghi của SQLite mà không phải từ bỏ những ưu điểm vốn có của nó. Việc sử dụng "những tệp tin vẫn có thể kiểm tra được" là một triết lý mạnh mẽ, giúp giảm thiểu rủi ro và tăng sự tin tưởng của người dùng.

Nếu bạn đang phát triển một ứng dụng cần xử lý khối lượng ghi lớn trên một máy chủ duy nhất và yêu thích sự minh bạch của SQLite, BriskDB xứng đáng để theo dõi và thử nghiệm. Dự án được phát hành dưới giấy phép MIT, mã nguồn mở trên GitHub.