SQLiteを1経路で作る

更新: 2026-09-09

配信用の SQLite ファイル(dev.db)を、中継のクラウドDBを挟まずにデータレイク(Iceberg)から直接作る構成の記録。 stock-app で実際に切り替えたときに踏んだ挙動を書く。経緯は経路を1本に減らしたら、消えていた索引が出てきた。

経路の形

4段のうち、1 が抜けると遅くなるだけで気づけず、2 が無いと空のファイルが配信される。

消えるもの	理由
HTTPクライアント一式	リモートへ送らないので不要
`asyncio`	HTTP往復を並行化するためだけに使っていた。同期化できる
ローカル/リモートの分岐	送信先が1つになる
スキーマ整合の同期スクリプト	マイグレーションが直接当たるので不要
手書きの `MIGRATIONS` 配列	上と同じ。これが歯抜けの原因になる
疎通確認・スロットリング用スクリプト	送信先が無くなれば宛先も無い

生成経路を差し替えたとき、db/migrations/ を当てる段が経路から落ちた。

症状: ページは正常に表示される。エラーもログも出ない。特定のクエリだけ遅い
原因: 索引が1つ作られておらず、インデックスを使うはずのクエリが全走査(SCAN)へ退行していた
見つけ方: EXPLAIN QUERY PLAN で SCAN になっていないか見る。索引の有無は PRAGMA index_list(<テーブル>) で数える
対処: 生成経路の先頭でマイグレーションを全件適用する。「新しいファイルだから最新のはず」という前提を置かない

経路を差し替えるときは、経路上の段を1つずつ数える。 新しい経路が通ったことと、旧経路がやっていた仕事が全部移ったことは別。

対象テーブルが存在しない状態でエクスポートを走らせると、書き込む先が無いだけで例外にはならず、0件のまま正常終了する。そのまま配信すると、空のファイルが本番へ出る。

対処は、エクスポート開始時に対象テーブルの存在を検査して、無ければ異常終了させること。件数0を成功として扱わない。

起動 → 対象テーブルが全部あるか確認 → 無い → 非ゼロで終了

「何も起きなかった」と「うまくいった」を、終了コードで区別できるようにしておく。

適用すべきマイグレーションを配列に列挙する形にしていると、マイグレーションを足した人が配列に書き足すのを忘れた時点で黙って壊れる。 ディレクトリを読んで全部当てる形にすれば、書き忘れる場所自体が無くなる。

作り直せるかどうかは、テーブルごとに正本がどこにあるかで決まる。

全部戻せる。ただし実運用で壊れたときの最短復旧は、配信先に置いてあるスナップショットを戻すことで、再生成は最短ではない。設計ドキュメントには「戻せるか」と「戻すのが速いか」を分けて書く。