SQLiteをエッジで使うと何を確認し直す？

SQLiteエンジンはSQLをバイトコードに変換し、仮想マシンで実行します。B-tree、ページキャッシュ、ファイルシステムインターフェースも使います。マネージドなエッジDBはこのエンジンをリモート保存、複製、実行環境のAPIと組み合わせるため、ローカルのDBファイルと遅延・整合性が同じとは限りません。SQLiteアーキテクチャ

まずワークロードを三つに分ける

  • 1. データは1台の端末内で必要か、複数地域の利用者に近い場所で共有するか。ローカルアプリならSQLiteファイルだけで足りる場合があります。マネージドエッジでは、事業者固有のバインディング、通信、複製、アクセス制御も評価します。
  • 2. 読み書きの比率と最新性の要件は何か。複数地域から小規模データを読む処理が多い場合、読み取り複製が有用なことがあります。ただし書き込みはprimaryへ送られ、非同期レプリカには一時的な遅れが生じる場合があります。
  • 3. 同時書き込みとデータ増加はどの程度か。上限はエンジンとマネージドサービスごとに異なります。書き込みの集中、大規模分析、一括取込では、実測・料金・クォータ・別の保存方式を比較します。「SQLite」という名称だけで、どのサービスにも単一書き込みのボトルネックがある、または無制限に拡張できるとは判断できません。

例：価格変更直後の商品ページ

読み取り複製を使うD1の店舗が商品価格を更新し、同じ利用者がすぐ商品ページを再読み込みするとします。Cloudflareの説明ではレプリカは非同期で更新され、最新データから遅れることがあります。Sessions APIとbookmarkはセッション内の順序的一貫性を保ちます。次の読み込みで最新値が必要なら、first-primaryでセッションを始めるか、前のセッションのbookmarkを引き継ぎます。必要な処理経路でセッションを使い、DBで複製が有効か先に確認してください。D1読み取り複製ドキュメント

エンジン構造と製品動作を分けて考える

SQLiteのB-tree、pager、VFSの説明はエンジン内部の構造です。Cloudflare D1のprimary、読み取りレプリカ、bookmark、Worker bindingはそのサービス固有の配置・API仕様です。マネージドサービスがローカルのSQLiteファイルやすべてのVFS動作を公開すると推測しないでください。ローカルファイルのWAL運用を分散型の管理サービスへそのまま当てはめないことも重要です。

実測する項目

複数地域から読み書き混合の負荷を再現し、書き込み直後の読み取り、連続読み取り、同時書き込み、複製遅延時の挙動を確認します。D1では結果メタデータのserved_by_primaryとserved_by_regionを観察できます。実際の遅延、整合性、復旧動作がアプリの目標を満たすか測定してください。機能説明が存在するだけで個々のDBの複製が有効とは限りません。

参考資料