rqliteが始めた「分散SQLite」、その12年を作者自身が振り返る
Twelve Years of Distributed SQLite
Philip O'Tooleが2014年に公開したrqliteは、SQLiteの前にRaftログを置くという単純な発想で、分散SQLiteというカテゴリの先駆けとなった。その後dqlite、Litestream、cr-sqlite、libSQL、Cloudflare D1などが続き、設計空間はコンセンサス、ストリーミング、マージの三方向に分かれていった。作者は、資金を集めたのはサービス化したプロジェクトだったと率直に記している。
インフラのアイデアとはたいていそういう運命をたどるもので、私も気にはしていない。ただ、誰かがそれを売り出すまで8年間オープンソースだったという事実は記録しておく価値がある。
HNでの議論
62- piterrro
D1を本番環境で使ったことがある身から言うと、あれはあまり信頼できない。HNにはD1の開発者の一人が[1]、D1はSQLiteの分散的な性質を模倣した、Durable Objects上のSQLラッパーにすぎないとコメントしていた。
> ちょっとした汚い秘密を教えてあげよう：
ほとんどの場合、D1よりもDurable Objectsのストレージを使う方が良い。たとえグローバルな単一データベースが欲しいだけでも、それをD1で実装するよりシングルトンのDurable Objectとして実装する方が良い。なぜならD1そのものの実体はまさにそれ、つまり自身のSQLiteデータベースへのAPIを公開するシングルトンのDurable Objectにすぎないからだ。ただのラッパーなんだよ。
- AgentME
rqliteとLitestreamの比較は興味深かった。（rqliteはノード間の合意アルゴリズムを使って同期を保ち、プライマリノードの変更を可能にするのに対し、Litestreamは自分自身をS3に同期するだけで、別のノードがそこからデータを引き継げるようにする。）
記事がまもなくD1の話に入り、それがCloudflare Durable Objects（D1の基盤）と、S3に書き込むCloudflare Durable Objectsのオープンソース再実装であるcelldとの関係とほぼ同じだと言及するものだと完全に予想していた。ところが記事はD1を突然、皮肉めいた興味のなさで扱い、最後のセクションはrqliteを気まずいほど擁護しているように感じられた。
- mmnfrdmcx
sqliteとそのシンプルさを愛してきた者として言うと、正直なところ、エージェントを使うようになってからはpostgresの管理が極めて簡単だと感じているし、postgresのSQL機能を全部使えるのは本当に快適だ——sqliteは多くのSQLにおいてかなり制限が多い。だからリモートsqliteやそういったものを検討しているなら、今ほどデータベースサーバーをそのまま使うべき時はないように感じる。
もちろん、sqliteはローカルツールなどには素晴らしい。
- vikrantrathore
面白いことに、Paxosの論文（part time parliament）を読んでいて、ZigとOdin言語を学ぶ中で純粋なPaxosライブラリを作り、そのライブラリの最初の応用としてマルチマスターのsqliteを構築した。私が取った2つのアプローチは大きく異なっていて、Zigではzaxonlite（https://github.com/insanai/zaxonlite）を作り、rqliteも含めたベンチマークを用意している。これはWALレプリケーションを戦略として使っている。Odinで試した2つ目の試みはsqlodin（https://github.com/insanai/sqlodin）で、こちらはシステムがWALを使わず各ノードでSQLクエリを実行するため、その結果sqliteのSQLクエリの一部はサポートされていない。
- Kinrany
これらすべてを一緒に実現するプロジェクトはあるだろうか？
- sqliteのように組み込み可能
- dqliteのようにクラスタ化
- rqliteのようにスタンドアロンノードを持つ
- litestreamのようにS3へバックアップ可能
- さらにCPと並んでcr-sqliteのようにオプションでAPも