- 多くの開発者は、サーバーでSQLiteを使うのは小規模アプリケーション向きだと考えている
- その理由は次のとおり:
- 低いインフラコスト: 別個のデータベースサーバーが不要（単一ファイルで運用）
- 開発とテストのしやすさ: 同じDBファイルをクライアントとサーバーの両方で活用できる
- 運用負担の最小化: 複雑な設定やデーモン管理が不要
- 高い信頼性: SQLiteは世界で最も広く配布されているDBであり、強力な耐久性を持つ
- LiteFS, Litestream, rqlite, Dqlite, Bedrock などのツールがSQLiteにレプリケーションと高可用性(HA)を追加し、小規模デプロイに適したものにしている
しかしこの記事では、小規模ではなくハイパースケールアプリケーションに適したSQLiteの可能性を探っている
従来の大規模データベース拡張の問題
- 大規模アプリケーションでは通常、PostgreSQLやMySQLを単一DBとして維持するのが難しく、シャーディングされたデータベースを使用する
- 例: Cassandra, ScyllaDB, DynamoDB, Vitess(シャーディングされたMySQL), Citus(シャーディングされたPostgres)
- シャーディングDBには次のような利点がある:
- データ分割を通じたバッチ読み取り(Batch Read)の最適化
- 水平スケーリング(Scalability) が可能
- 高速な書き込み性能を提供
しかし現在のパーティショニングソリューションには次のような欠点がある
- 固定的なスキーマ(Rigid Schemas): MySQLやPostgresのような柔軟なクエリをサポートしない
- スキーマ変更が難しい: インデックス追加やリレーション変更時の運用負担が大きい
- 複雑なクロスパーティション演算: ACIDトランザクションの維持が難しく、2フェーズコミット(2PC)のような複雑な手法が必要
- データ不整合の問題: パーティション間で強力なデータ制約を適用しにくく、データ整合性が崩れる可能性が高い
SQLiteベースのハイパースケールデータベースの可能性
- Cloudflare Durable Objects と Turso は、SQLiteを基盤にハイパースケールアプリケーションを設計する方法を示している
- これらのシステムは次のような強みを提供する:
- 動的スケーリング(Dynamic Scaling): エンティティ(Entity)ごとにデータベースを作成し、インフラの複雑さを低減
- 無制限の低コストデータベース: 従来のシャーディングのようにデータ分割を強制せず、必要なときに新しいSQLiteインスタンスを作成できる
- グローバル分散(Global Distribution): データベースをユーザーに近い場所へ配置して性能を向上
- 組み込みのレプリケーションと耐久性(Built-in Replication & Durability): 従来のSQLiteと異なり、多地域でデータを複製して高可用性を維持
- SQLiteを活用したシャーディング代替方式 (Cloudflare Durable Objects & Tursoの活用)
- 従来のシャーディング方式では、単一のデータベースパーティションに複数のチャットログを保存
- SQLiteを使えば、各チャンネルごとに独立したSQLiteデータベースを作成でき、より柔軟なスキーマを活用できる
- 例の構造
- 従来のシャーディング: チャットログテーブル + パーティションキー
- SQLiteベース: チャンネルごとの個別SQLite DB (チャットログ、参加者、リアクション情報を含む)
- SQLiteを使うこの方式の利点は次のとおり:
- ローカルACIDトランザクションを維持: クロスパーティション問題なしに、個別DB内でトランザクションを実行できる
- 高性能I/O: SQLiteは単一ファイルDBであるため、読み書き性能が非常に高い
- SQL拡張機能を活用可能:
- FTS5(Full-Text Search): 検索性能を向上
- JSON1: JSONデータの保存とクエリをサポート
- R*Tree, SpatiaLite: 空間データを活用可能
- SQLマイグレーションをサポート: Prisma, Drizzleのような既存のマイグレーションツールと互換性がある
- 遅延(Lazy)スキーママイグレーションをサポート:
- マイグレーションを即時実行する必要がなく、SQLiteインスタンスを開く際に軽量なマイグレーションを行う方式を使える
サーバーでSQLiteを使う際の限界
- オープンソースでセルフホスト可能なソリューションが不足
- クロスデータベースクエリをサポートしない → 分析には別途データレイクが必要
- 限られたデータベースツーリング (SQLブラウザ、ETLパイプライン、監視、バックアップ)
- StarbaseDB がCloudflare Durable Objects + SQLiteベースでこの問題を解決中
- 統一された標準プロトコルの不足
- PostgreSQL, MySQL, Cassandraは標準化されたプロトコルを使うが、SQLiteサーバーにはまだ標準化されたネットワークプロトコルが不足している
- ハイパースケールでSQLiteを使った大規模事例が不足
- Cassandra, DynamoDBのような事例研究は不足しているが、時間とともに変わる可能性がある
結論: SQLiteは単なるローカルDBではなく、ハイパースケールアプリケーションでも強力な選択肢
- SQLiteは単純な小規模プロジェクト向けDBではなく、ハイパースケールアプリケーションでも従来のシャーディング方式を置き換えられる強力なツール
- Cloudflare Durable Objects & Turso を活用すれば、データベースをエンティティ単位に分割し、SQLの強力な機能とACIDトランザクションを維持したままスケールできる
- 従来のシャーディングデータベースより柔軟で管理しやすい代替手段として定着する可能性が高い
2件のコメント
どれほど多くのリクエストをさばく超大規模環境であっても、進んでsqliteを使うような勇敢な人がいるだろうか……
Hacker Newsの意見
あるユーザーが、カスタムデータベースをSQLベースのものに置き換えることを検討している
あるユーザーはローカルファーストのWebアプリを開発しており、SQLiteが適していると考えている
SQLite-Per-Partitionの利点について議論している
マルチユーザー環境では、SQLiteはMVCCの不足によって困難に直面する
Ruby on Railsの8.0リリースでSQLiteサポートが拡張された
VitessやCitusに詳しくないユーザーは、記事の内容を理解しづらいと感じている
あるユーザーはVPSホスティングを望まず、SQLiteを使ったWebページを作成した
Ubiquitiコントローラーの設定に苦労したユーザーがSQLiteの利用を提案している
Appleは2022年時点で約300,000のCassandra/ScyllaDBインスタンスを運用している
TDLib（Telegramデータベースライブラリ）はSQLiteを使用している