Bluesky、シングルテナントSQLiteへ移行

• Blueskyは、シングルテナントのSQLiteデータストアへ移行しました。
• これにより各ユーザーは、自身のリポジトリと個人アカウント状態を保存する専用のSQLiteファイルを持つようになりました。
• ユーザーデータベースは階層的に保存されます。
• 各リポジトリのリポジトリ署名キーは、SQLiteファイルとともに保存されます。
• ユーザーデータとやり取りする抽象化は、ActorStoreへ移行しました。
• ActorStoreは、読み取り用と書き込み用で別々のクラスを持っています。
• SQLiteは同時トランザクションをサポートしないため、ActorStoreでは書き込みのために明示的な"トランザクト"が必要です。
• 署名キーとデータベースのためのLRUCacheが維持され、3万件のオープンなファイルハンドルと、メモリ上に保持された3万件のキーを許可します。
• データベースがキャッシュから外れると、ファイルハンドルは閉じられます。
• サービス状態を管理するために、3つの独立したSQLiteデータベースが導入されました。すなわち、アカウント情報・招待コード・リフレッシュトークンなどのためのサービスDB、DID解決をキャッシュするためのdidキャッシュDB、そしてサービス内のすべてのリポジトリにおけるリポジトリ更新を順次処理するためのsequencer DBです。
• これらのSQLiteファイルは、同時読み取りとストリーミングレプリケーションを可能にするため、WALモードで動作します。
• PDSのデプロイは、Litestreamまたは同様のものとともに提供される見込みです。

[GN⁺]

Hacker News の意見

• BlueskyがシングルテナントのSQLite構成へ移行し、このアプローチの課題と利点について議論が起こりました。
• 一部のユーザーは、データ移行やスキーマバージョンに関する潜在的な問題、将来的なデータ集計の必要性について懸念を示しています。
• 別のユーザーたちは、SQLiteが同時トランザクションをサポートしないという主張に疑問を呈し、特定の条件下ではサポートされると指摘しています。
• ユーザーとデータベースを1:1で対応させる戦略は興味深く見え、ユーザー間で集計が必要なデータがどのように処理されるのかという疑問が提起されました。
• この構成で、他のユーザーが新しいコンテンツを投稿した際に、ユーザーのデータベースへの更新がどのように処理されるのかにも関心が集まっています。
• 一部のユーザーは、サーバー上でのSQLite/Litestreamの採用を称賛し、テナントデータベースに対する費用対効果の高い選択肢だと評価しています。
• SQLiteにどの種類のデータが保存され、どの種類のデータが保存されないのかという質問が提起され、一部のユーザーはユーザー間メッセージはSQLiteに保存されないのではないかと推測しています。
• MD5ハッシュを使って2文字の対象ディレクトリを得るほうが、SHA256ハッシュを使うより高速で、同じ問題を解決できるという提案があります。
• 一部のユーザーはこの移行を前向きな動きと見ており、SQLiteファイルをダウンロードしてローカル専用のHTMLフロントエンドを生成することで、簡単にサービスを離れられるだろうと提案しています。
• Blueskyが今も招待制なのかという質問があります。