Mười hai năm của SQLite phân tán: từ rqlite đến kỷ nguyên dịch vụ đám mây

Tóm tắt: Philip O'Toole, tác giả dự án rqlite, nhìn lại chặng đường 12 năm phát triển SQLite phân tán — một hạng mục khởi đầu từ ý tưởng đơn giản năm 2014 nhưng nay đã có hàng chục dự án tham gia. Bài viết là lời kể của người trong cuộc về ba hướng tiếp cận thiết kế khác nhau, và về việc tiền đầu tư cuối cùng đã chảy về đâu.

Khởi đầu từ một nhu cầu rất cụ thể

Tháng 9 năm 2014, O'Toole công bố một bài viết ngắn giới thiệu rqlite. Ý tưởng rất đơn giản: lấy SQLite, đặt một nhật ký Raft lên phía trước, rồi sao chép mọi thao tác ghi ra toàn cụm — để việc mất một nút không đồng nghĩa với việc mất dữ liệu.

Mã nguồn được đưa lên GitHub ngay cuối tuần đó. Theo tác giả, đây là hệ thống mã nguồn mở đầu tiên kết hợp Raft và SQLite. Thời điểm ấy không ai làm điều tương tự, và trong nhiều năm sau cũng không ai thử lại.

Nhu cầu xuất phát từ thực tế: một hệ thống dạng cụm mà tác giả đang làm việc cần một lượng nhỏ lưu trữ quan hệ, nhưng không có câu trả lời thỏa đáng cho việc nút nào nên giữ dữ liệu đó.

Phiên bản đầu tiên dùng goraft — thư viện mà InfluxDB và etcd cũng sử dụng khi đó. Đầu năm 2016, nó được thay bằng bản triển khai Raft của Hashicorp, và rqlite vẫn dùng đến ngày nay.

Quyết định thiết kế quan trọng nhất được đưa ra từ thuở ban đầu và không bao giờ thay đổi: rqlite là một hệ thống CP. Thao tác ghi bắt buộc phải đi qua nút leader, phải được đa số nút xác nhận, và một thiểu số bị phân vùng sẽ từ chối ghi. Mọi thứ khác — API HTTP, các mức nhất quán khi đọc, cơ chế snapshot — đều suy ra từ nguyên tắc này.

Những dự án đi trước và song hành

Để công bằng, cần nhắc đến hai trường hợp. Expensify đã sao chép SQLite trong hạ tầng của mình nhiều năm bằng giao thức kiểu Paxos, và công bố dưới tên Bedrock vào năm 2016. ActorDB — hệ thống viết bằng Erlang, cấp cho mỗi "actor" một cơ sở dữ liệu SQLite riêng được Raft sao chép — xuất hiện gần như cùng lúc với rqlite.

Cả hai đều không được ứng dụng rộng rãi ngoài môi trường gốc, nhưng đều cho thấy ý tưởng đã "trong không khí". Điều rqlite làm được là biến nó thành một sản phẩm độc lập, đa dụng, mã nguồn mở mà bất kỳ ai cũng có thể chạy.

2017: dqlite và sự khác biệt về cách đóng gói

Canonical xây dựng dqlite để LXD và sau này là MicroK8s có được kho lưu trữ sao chép nhúng sẵn mà không cần chạy etcd. Mark Shuttleworth từng gọi điện trực tiếp cho O'Toole, hy vọng có thể tận dụng rqlite, nhưng mọi thứ không khớp.

dqlite khởi đầu bằng Go rồi được viết lại bằng C với thư viện Raft riêng. Đây là dự án gần nhất với rqlite về ý định; khác biệt chính nằm ở cách đóng gói: dqlite là thư viện để nhúng, rqlite là máy chủ để chạy. Canonical cần cơ sở dữ liệu nằm bên trong sản phẩm của họ; O'Toole muốn cơ sở dữ liệu nằm cạnh sản phẩm của bất kỳ ai.

2021: Litestream và sự thay đổi hướng tiếp cận

Ben Johnson công bố Litestream đầu năm 2021. Dự án này không dùng giao thức đồng thuận nào cả. Nó theo dõi WAL của SQLite và truyền lên S3, mang lại khả năng phục hồi sau thảm họa cho một cơ sở dữ liệu SQLite đơn nút với chi phí gần như bằng không.

Lập luận của Ben rất rõ ràng: phần lớn ứng dụng không cần cụm, chúng chạy trên một máy và chỉ cần cách phục hồi khi máy đó chết. Điều này đúng với rất nhiều ứng dụng, và phong trào "SQLite là đủ" những năm sau đó mang ơn không nhỏ từ lập luận này.

Litestream và rqlite trả lời hai câu hỏi khác nhau. Litestream: điều gì xảy ra nếu máy chết? rqlite: điều gì xảy ra nếu máy chết và tôi không thể chờ khôi phục?

Câu hỏi thứ nhất phổ biến hơn; câu hỏi thứ hai mới là lý do người ta tìm đến rqlite.

Năm 2022, Fly.io tuyển Ben và ra mắt LiteFS — sao chép SQLite ở tầng hệ thống tệp với cơ chế lease từ Consul. Đây là lần đầu tiên SQLite sao chép được đưa thành tính năng nền tảng thay vì thứ bạn phải tự triển khai. Và trong một bước ngoặt thú vị, chính Litestream đã truyền cảm hứng cho cách xử lý WAL của rqlite từ phiên bản 8.0.

2022: các nhánh rẽ và phần mở rộng

Hai dự án năm 2022 chọn hướng đi mà cả rqlite lẫn Litestream đều không theo.

• cr-sqlite bổ sung CRDT vào SQLite dưới dạng phần mở rộng, cho phép nhiều bên ghi phân kỳ rồi hợp nhất mà không cần leader. Đây là góc AP của không gian thiết kế, phù hợp với ứng dụng ưu tiên cục bộ — nơi các đảm bảo CP của rqlite sẽ thành rào cản.
• libSQL rẽ nhánh chính bản thân SQLite. ChiselStrike, sau này là Turso, muốn thay đổi những thứ bên trong engine mà dự án SQLite — vốn không nhận đóng góp từ bên ngoài — sẽ không chịu thay đổi. Trên nền bản rẽ nhánh đó, họ xây dịch vụ lưu trữ với các bản sao ở biên. Turso gọi được vốn đầu tư và đến năm 2026 thì được Supabase mua lại.

Cùng thời điểm, SQLite Cloud xuất hiện, cung cấp dịch vụ SQLite lưu trữ sao chép bằng Raft — dự án gần với thiết kế ban đầu của rqlite nhất, nhưng được gói trong một dịch vụ đám mây.

Từ "thứ bạn chạy" thành "thứ bạn mua"

Cloudflare công bố D1 năm 2022 — SQLite như một cơ sở dữ liệu serverless trong mạng lưới biên, sau đó đưa lưu trữ SQLite vào Durable Objects. Đây là SQLite sao chép dưới dạng sản phẩm quản lý của một công ty không cần giải thích cơ chế bên trong. Dịch vụ của Turso có hình dạng tương tự.

Hạng mục này đã chuyển từ "một thứ bạn tự chạy" sang "một thứ bạn mua".

Ba bài học sau mười hai năm

Thứ nhất, phần lõi đã đúng. SQLite làm engine lưu trữ, với sao chép được thêm vào bên ngoài, đã được ít nhất tám nhóm tái phát minh với những nhu cầu và giao thức khác nhau. Chưa ai tìm ra lý do để dừng lại.

Thứ hai, không gian thiết kế có ba góc và chúng xuất hiện theo thứ tự:

• Đồng thuận trước (rqlite, dqlite): một leader, nhất quán mạnh, có cụm.
• Truyền luồng tiếp theo (Litestream): một bên ghi, phục hồi rẻ, không cụm.
• Hợp nhất sau cùng (cr-sqlite, một phần phong trào local-first): nhiều bên ghi, nhất quán cuối cùng.

Mỗi hướng đều đúng cho một câu hỏi khác nhau, và phần lớn các cuộc tranh luận thực chất là tranh luận giữa người dùng của các hướng về việc đang hỏi câu gì.

Thứ ba, tiền đã chảy về các nền tảng. rqlite, dqlite và Litestream đều mã nguồn mở và miễn phí. Những dự án gọi được vốn hoặc bị thâu tóm là những dự án biến SQLite sao chép thành dịch vụ có hóa đơn. Đó là số phận thường thấy của các ý tưởng hạ tầng, nhưng đáng ghi lại rằng ý tưởng này đã mã nguồn mở suốt tám năm trước khi có người bán nó.

Vị thế của rqlite hôm nay

rqlite vẫn ở đó. Nó làm đúng việc nó làm năm 2014, chỉ tốt hơn nhiều, và vẫn là thứ bạn tìm đến khi cần một cơ sở dữ liệu quan hệ chịu lỗi, tự vận hành, hiểu tường tận và không phải trả tiền cho ai.

Mười hai năm nhìn lại, tác giả hài lòng với vị trí đó trong câu chuyện.

Với cộng đồng lập trình viên Việt Nam — đặc biệt những nhóm đang xây hệ thống nhỏ cần độ tin cậy mà không muốn vận hành một cụm cơ sở dữ liệu phức tạp như PostgreSQL hay MySQL — sự trưởng thành của hệ sinh thái SQLite phân tán là một lựa chọn đáng cân nhắc. Nếu ưu tiên đơn giản và khả năng tự chủ, rqlite vẫn là điểm khởi đầu hợp lý; nếu chỉ cần sao lưu liên tục, Litestream giải quyết gọn nhẹ; còn nếu muốn "mua cho xong", các dịch vụ đám mây như D1 hay Turso đã sẵn sàng.