分散SQLiteの12年間

分散SQLiteの12年間

2014年9月、私はrqliteを発表する短い投稿を公開しました。そのアイデアはシンプルでした。すなわち、SQLiteを取り上げ、その前にRaftログを置き、クラスタ全体にすべての書き込みをレプリケートすることで、ノードの損失がデータの損失を意味しないようにすることでした。ソースコードは、その週末にGitHubに公開されました。私の知る限り、それがRaftとSQLiteを組み合わせた最初のオープンソースシステムでした。他に誰もそれをやっておらず、数年間は誰も試みませんでした。

今日、「分散SQLite」は12のプロジェクトが存在するカテゴリとなり、そのうちいくつかはベンチャー資金を調達し、2つは買収されました。このカテゴリについて書く人々は、物語を2021年頃から始める傾向があるため、私は2014年から始まるバージョンを書き留めるべきだと思いました。私はそのすべてに立ち会いました。

2014年：rqlite

必要性は具体的でした。私が取り組んでいたクラスタシステムには、少量の関係型ストレージが必要でしたが、どのノードがそれを保持すべきかという問題には良い答えがありませんでした。RaftコンセンサスプロトコルでSQLiteをレプリケートすることがそれを解決しました。私たちは職場で別の方法を取りましたが、問題は一般的で解決策は小さかったため、rqliteの開発を続けました。最初のバージョンはgoraftを使用しました。これは当時InfluxDBとetcdが使用していたのと同じライブラリでした（私はほぼ同時期にInfluxDBにコア開発者として参加しました）。2016年初頭に、HashicorpのRaft実装に置き換えました。rqliteは現在もそれを使用しています。

最も重要だった設計上の決定は当時行われ、変更されていません。rqliteはCPシステムです。書き込みはリーダーを経由する必要があり、過半数が承認し、分割された少数派は書き込みを拒否します。HTTP API、読み取り整合性レベル、スナップショットなど、すべてがそこから派生しました。

2014年以前、および同時期

正直さのために、2つのことに言及する価値があります。Expensifyは、Paxosスタイルのプロトコルで、長年独自のインフラストラクチャ内でSQLiteをレプリケートしていました。彼らはそれを2016年にBedrockとしてリリースしました。また、各「アクター」にRaftでレプリケートされた独自のSQLiteデータベースを提供するErlangシステムであるActorDBが、rqliteとほぼ同時期に登場しました。どちらも、その起源を超えて広く採用されることはありませんでしたが、どちらもアイデアが空気中にあったことを示しています。rqliteが行ったことは、それをスタンドアロンの汎用オープンソースのものにし、誰でも実行できるようにしたことです。

2017年：dqlite

Canonicalは、LXDと後のMicroK8sのために、etcdを実行せずに埋め込み型のレプリケートされたストアを取得するためにdqliteを構築しました。Mark Shuttleworthは実際に一度私に電話してきて、rqliteが機能するようになることを期待して話しましたが、それは決して完全に適合しませんでした。dqliteはGoで始まり、独自のRaftライブラリを持つCで書き直されました。意図としてはrqliteに最も似たプロジェクトであり、主な違いはパッケージングにあります。dqliteは埋め込むライブラリであり、rqliteは実行するサーバーです。Canonicalのニーズは製品内のデータベースでしたが、私のニーズは誰の製品の隣にも置けるデータベースでした。

2021年：Litestream、そしてアプローチの変更

Ben Johnson（InfluxDBで一緒に働いた人物）は、2021年初頭にLitestreamをリリースしました。Litestreamはコンセンサスを全く使用しません。SQLiteのWALを監視し、それをS3にストリーミングすることで、ほぼゼロコストで単一ノードSQLiteデータベースの災害復旧を提供します。Benの主張は、ほとんどのアプリケーションはクラスタを必要とせず、1台のマシンを使用し、それが故障した場合に復旧する方法が必要だということでした。彼は多くのアプリケーションについて正しく、その後の数年間の「SQLiteで十分」という運動、ブログ記事やカンファレンストークは、その議論に大きく負うところが大きいです。

Litestreamとrqliteは異なる質問に答えます。Litestream：マシンが故障したらどうなるか？ rqlite：マシンが故障し、復旧を待てない場合はどうなるか？最初の質問はより一般的ですが、2番目の質問はrqliteにたどり着く人々が抱える質問です。

Fly.ioは2022年にBenを雇用し、LiteFSをリリースしました。これはConsulからのリースを使用してファイルシステムレベルでSQLiteをレプリケートします。これは、レプリケートされたSQLiteをデプロイするものではなく、プラットフォーム機能にする最初の試みでした。そして最終的なひねりとして、Litestreamはrqliteのv8.0のアプローチに影響を与え、SQLite WALの処理方法を改善しました。

2022年：フォークと拡張機能

2022年には、rqliteもLitestreamも持っていなかったアプローチを取った2つのプロジェクトがありました。cr-sqliteは、SQLiteにCRDTを拡張機能として追加し、複数のライターがリーダーなしで分岐してマージできるようにしました。これは設計空間のAPコーナーであり、rqliteのCP保証が障害となるローカルファーストアプリケーションに適しています。

libSQLはSQLite自体をフォークしました。ChiselStrike、後にTursoは、外部からの貢献を受け付けず、変更しないSQLiteプロジェクトのエンジン内部を変更したいと考えていました。フォークの上に、彼らはエッジにレプリカを持つホスト型サービスを構築しました。Tursoはそれによってベンチャー資金を調達し、2026年にSupabaseに買収されました。

ほぼ同時期に、SQLite Cloudが登場し、Raftでレプリケートされたホスト型SQLiteを提供しました。これは、クラウドサービスでラップされた、rqliteの元の設計に最も近いプロジェクトです。

2022年以降：プラットフォーム

Cloudflareは2022年にD1を発表しました。これは、エッジネットワーク内のサーバーレスデータベースとしてのSQLiteであり、後にDurable ObjectsにSQLiteストレージを組み込みました。これは、どのように機能するかを教えてくれる必要のない企業によるマネージド製品としてのレプリケートされたSQLiteです。Tursoのサービスも同様の形状です。このカテゴリは、「実行するもの」から「購入するもの」へと移行しました。

12年間が示すこと

3つのことだと思います。

コアは正しかった。SQLiteをストレージエンジンとして、外部にレプリケーションを追加するというアイデアは、少なくとも8つの異なるチームによって、異なるニーズと異なるプロトコルで再発明されてきました。誰もそれをやめる理由を見つけていません。

設計空間には3つのコーナーがあり、順序通りに現れました。まずコンセンサス（rqlite、dqlite）：単一リーダー、強い整合性、クラスタ。次にストリーミング（Litestream）：単一ライター、安価な復旧、クラスタなし。最後にマージ（cr-sqlite、およびローカルファースト運動の一部）：複数ライター、最終的な整合性。それぞれが異なる質問に対して正しいものであり、ほとんどの議論は、どの質問がされているかについてのユーザー間の議論です。

そして、お金はプラットフォームに向かいました。rqlite、dqlite、Litestreamはオープンソースで無料です。資本を調達したり買収されたりしたプロジェクトは、レプリケートされたSQLiteを請求書付きのサービスに変えたものです。それはインフラストラクチャのアイデアの通常の運命であり、私はそれを気にしません。しかし、誰かがそれを販売する前に、アイデアが8年間オープンソースであったことを記録しておく価値はあります。

rqliteはまだここにあります。2014年と同じことを、はるかにうまくやっています。そして、自分で実行でき、完全に理解でき、誰にも料金を支払う必要のない耐障害性の高いリレーショナルデータベースが必要な場合に、依然として頼りになるものです。12年経った今、私は物語におけるその立場に満足しています。