Sự tiến hóa của SQLite phân tán từ rqlite đến các dịch vụ đám mây được quản lý

Vào tháng 9 năm 2014, Philip O'Toole phát hành rqlite, một hệ thống mã nguồn mở kết hợp SQLite với giao thức đồng thuận Raft để tạo ra một cơ sở dữ liệu cụm có khả năng chịu lỗi. Mười hai năm sau, O'Toole suy ngẫm về cách thử nghiệm ban đầu này đã khơi mào cho một phạm vi rộng lớn hơn các giải pháp SQLite phân tán, từ các CRDT ưu tiên cục bộ (local-first) cho đến các dịch vụ được quản lý nhận vốn đầu tư mạo hiểm.

Điều gì đã xảy ra

O'Toole ban đầu xây dựng rqlite để giải quyết một vấn đề hạ tầng cụ thể tại jut.io: cung cấp lưu trữ quan hệ cho một hệ thống cụm mà không chỉ định một nút nào là nơi giữ dữ liệu vĩnh viễn. Bằng cách đặt một log Raft phía trước SQLite, ông đảm bảo rằng mọi thao tác ghi đều được nhân bản trên toàn bộ cụm, ngăn ngừa mất dữ liệu nếu một nút gặp sự cố. Mã nguồn được công bố trên GitHub ngay cuối tuần đó, đánh dấu điều mà O'Toole tin là sự kết hợp mã nguồn mở đầu tiên giữa Raft và SQLite. Trong vài năm, rqlite đứng độc lập trong ngách này, không có dự án lớn nào khác thử nghiệm kiến trúc tương tự.

Bối cảnh bắt đầu thay đổi vào năm 2016 khi Expensify phát hành Bedrock, một hệ thống nhân bản SQLite dựa trên Paxos mà họ đã sử dụng nội bộ trong nhiều năm. Cùng thời điểm đó, ActorDB xuất hiện, cung cấp các cơ sở dữ liệu SQLite được nhân bản bằng Raft cho từng actor riêng lẻ trong môi trường Erlang. Mặc dù cả hai không đạt được sự chấp nhận rộng rãi bên ngoài các công ty khởi nguồn, chúng chứng minh rằng khái niệm nhân bản SQLite đang dần thu hút sự chú ý. Tuy nhiên, rqlite vẫn khác biệt như một công cụ độc lập, đa mục đích mà bất kỳ nhà phát triển nào cũng có thể triển khai độc lập với một khung ứng dụng cụ thể.

Đến năm 2017, Canonical phát triển dqlite để cung cấp một kho lưu trữ được nhúng và nhân bản cho LXD và MicroK8s, tránh gánh nặng vận hành khi chạy etcd. Mặc dù O'Toole và Mark Shuttleworth đã thảo luận về khả năng hợp tác, các dự án đã tách biệt về mô hình đóng gói. Dqlite trở thành một thư viện C được nhúng trực tiếp vào ứng dụng, trong khi rqlite vẫn là một quy trình máy chủ riêng biệt. Sự khác biệt này xác định các trường hợp sử dụng tương ứng của họ: dqlite cho chức năng cơ sở dữ liệu bên trong sản phẩm, và rqlite cho hạ tầng cơ sở dữ liệu nằm cạnh chúng.

Cách hoạt động

Cơ chế cốt lõi của rqlite dựa vào thuật toán đồng thuận Raft để quản lý trạng thái trên nhiều nút. Trong hệ thống CP (Consistency and Partition tolerance - Tính nhất quán và Khả năng chống phân vùng) này, tất cả các thao tác ghi phải được gửi tới nút leader (nút dẫn đầu). Nút leader sau đó thêm thay đổi vào log của nó và nhân bản tới các nút follower (nút theo dõi). Một thao tác ghi chỉ được coi là thành công khi đa số cụm xác nhận nó. Nếu một phân vùng mạng cô lập một thiểu số các nút, những nút đó sẽ từ chối ghi để ngăn chặn sự phân kỳ dữ liệu, đảm bảo tính nhất quán mạnh mẽ nhưng đánh đổi bằng tính sẵn sàng trong quá trình phân vùng.

Thiết kế này trái ngược rõ rệt với các phương pháp tiếp cận sau này như Litestream, được Ben Johnson phát hành vào năm 2021. Litestream không sử dụng các giao thức đồng thuận. Thay vào đó, nó giám sát Write-Ahead Log (WAL) của SQLite và truyền các thay đổi tới lưu trữ đối tượng như S3. Điều này cung cấp khả năng khôi phục thảm họa cho các triển khai một nút với chi phí tối thiểu, đáp ứng nhu cầu sao lưu phổ biến hơn là cụm thời gian thực. Rqlite trả lời câu hỏi về tính sẵn sàng cao khi thời gian ngừng hoạt động là không thể chấp nhận được, trong khi Litestream giải quyết độ bền dữ liệu cho các kiến trúc đơn giản hơn.

Các đổi mới gần đây hơn đã khám phá những điểm khác nhau trong không gian thiết kế. Cr-sqlite giới thiệu các Kiểu dữ liệu Nhân bản Không xung đột (CRDTs) dưới dạng phần mở rộng của SQLite, cho phép nhiều người ghi phân kỳ và hợp nhất các thay đổi mà không cần một leader trung tâm. Phương pháp tiếp cận AP (Availability and Partition tolerance - Tính sẵn sàng và Khả năng chống phân vùng) này phù hợp với các ứng dụng ưu tiên cục bộ, nơi tính nhất quán tức thì ít quan trọng hơn khả năng hoạt động ngoại tuyến. Trong khi đó, các dự án như libSQL đã fork (phân nhánh) chính engine SQLite để cho phép tích hợp sâu hơn, hỗ trợ các dịch vụ như Turso cung cấp cơ sở dữ liệu nhân bản edge dưới dạng sản phẩm được quản lý.

Chi tiết chính

• Rqlite được phát hành vào tháng 9 năm 2014, ban đầu sử dụng thư viện goraft trước khi chuyển sang cài đặt Raft của Hashicorp vào đầu năm 2016.
• Dqlite của Canonical, được tạo ra vào năm 2017, là một thư viện C được nhúng trong ứng dụng, trong khi rqlite hoạt động như một máy chủ độc lập.
• Litestream, ra mắt năm 2021, truyền các tệp WAL của SQLite tới S3 để khôi phục thảm họa mà không sử dụng các giao thức đồng thuận.
• Cr-sqlite cho phép hỗ trợ nhiều người ghi thông qua CRDTs, phục vụ các ứng dụng ưu tiên cục bộ yêu cầu tính nhất quán cuối cùng (eventual consistency).
• Turso, được xây dựng trên fork libSQL, đã được Supabase mua lại vào năm 2026, nhấn mạnh khả năng thương mại hóa của SQLite phân tán được quản lý.
• Cloudflare’s D1 và Durable Objects đại diện cho sự chuyển dịch hướng tới nhân bản SQLite được quản lý, serverless ở edge.

Tại sao điều này quan trọng

Đối với các kỹ sư phần mềm và trưởng nhóm hạ tầng, việc hiểu lịch sử của SQLite phân tán làm sáng tỏ các sự đánh đổi giữa các mẫu kiến trúc khác nhau. Sự xuất hiện của ba góc độ riêng biệt trong không gian thiết kế—cụm dựa trên đồng thuận, truyền stream WAL và hợp nhất CRDT—có nghĩa là việc lựa chọn một giải pháp đòi hỏi định nghĩa chính xác các yêu cầu. Các nhà phát triển phải quyết định xem họ cần tính nhất quán mạnh mẽ với tính sẵn sàng cao, khôi phục thảm họa hiệu quả về chi phí, hay khả năng cộng tác ưu tiên ngoại tuyến. Việc áp dụng sai một hệ thống CP như rqlite cho một trường hợp sử dụng chỉ cần sao lưu, hoặc ngược lại, có thể dẫn đến sự phức tạp không cần thiết hoặc rủi ro dữ liệu.

Quỹ đạo từ các công cụ mã nguồn mở đến các nền tảng được quản lý cũng phản ánh một xu hướng rộng lớn hơn trong phần mềm hạ tầng. Trong khi rqlite, dqlite và Litestream vẫn miễn phí và mã nguồn mở, lượng lớn vốn đầu tư mạo hiểm và các thương vụ mua lại đã đổ dồn vào các dịch vụ trừu tượng hóa sự phức tạp trong vận hành. Các công ty như Turso và Cloudflare bán SQLite nhân bản như một tiện ích, cho phép các đội ngũ bỏ qua gánh nặng bảo trì khi quản lý các cụm. Sự chuyển dịch này xác nhận giá trị của công nghệ nền tảng nhưng thay đổi mô hình kinh tế cho các nhà phát triển trước đây phụ thuộc vào các giải pháp tự host (self-hosted).

Bạn có thể làm gì

• Đánh giá các yêu cầu về tính nhất quán của bạn: chọn các hệ thống dựa trên Raft như rqlite cho tính nhất quán mạnh mẽ, hoặc CRDTs như cr-sqlite cho các ứng dụng ưu tiên ngoại tuyến.
• Cân nhắc Litestream nếu nhu cầu chính của bạn là khôi phục thảm họa cho một cơ sở dữ liệu SQLite một nút chứ không phải cụm thời gian thực.
• Sử dụng dqlite nếu bạn đang xây dựng một ứng dụng yêu cầu một cơ sở dữ liệu được nhúng và nhân bản mà không phụ thuộc vào dịch vụ bên ngoài.
• Khám phá các dịch vụ được quản lý như Turso hoặc Cloudflare D1 nếu bạn muốn giảm bớt gánh nặng vận hành khi quản lý các cụm cơ sở dữ liệu phân tán.
• Xem xét các khả năng truyền stream WAL trong rqlite v8.0, được lấy cảm hứng từ Litestream, để tối ưu hóa các quy trình sao lưu và khôi phục.
• Đánh giá xem đội ngũ của bạn có đủ chuyên môn để duy trì một cụm Raft tự host hay không, hoặc nếu một nền tảng được quản lý mang lại sự phân bổ tài nguyên tốt hơn.