コンテンツハッシュファイルキャッシュパターン
SHA-256コンテンツハッシュをキャッシュキーとして使用して、高コストなファイル処理結果(PDF解析、テキスト抽出、画像分析)をキャッシュします。パスベースのキャッシュとは異なり、このアプローチはファイルの移動/名前変更に対して生き残り、コンテンツが変更されたときに自動的に無効化されます。
起動条件
- ファイル処理パイプラインの構築(PDF、画像、テキスト抽出)
- 処理コストが高く、同じファイルが繰り返し処理される場合
--cache/--no-cacheCLIオプションが必要な場合- 既存の純粋な関数を変更せずにキャッシュを追加したい場合
コアパターン
1. コンテンツハッシュベースのキャッシュキー
パスではなくファイルコンテンツをキャッシュキーとして使用します:
なぜコンテンツハッシュ? ファイルの名前変更/移動 = キャッシュヒット。コンテンツ変更 = 自動無効化。インデックスファイル不要。
2. キャッシュエントリの凍結データクラス
3. ファイルベースのキャッシュストレージ
各キャッシュエントリは{hash}.jsonとして保存されます — ハッシュによるO(1)検索、インデックスファイル不要。
4. サービスレイヤーラッパー(SRP)
処理関数を純粋に保ちます。キャッシュを別のサービスレイヤーとして追加します。
主要な設計上の決定
ベストプラクティス
- パスではなくコンテンツをハッシュ — パスは変わるが、コンテンツのアイデンティティは変わらない
- 大きなファイルはチャンク処理でハッシュ — ファイル全体をメモリに読み込まないようにする
- 処理関数を純粋に保つ — キャッシュについて何も知らないようにする
- 切り捨てたハッシュでキャッシュヒット/ミスをログ記録 — デバッグのため
- 破損をグレースフルに処理 — 無効なキャッシュエントリはミスとして扱い、クラッシュしない
避けるべきアンチパターン
使用すべき場合
- ファイル処理パイプライン(PDF解析、OCR、テキスト抽出、画像分析)
--cache/--no-cacheオプションが有益なCLIツール- 同じファイルが複数回にわたって現れるバッチ処理
- 既存の純粋な関数を変更せずにキャッシュを追加する場合
使用すべきでない場合
- 常に最新でなければならないデータ(リアルタイムフィード)
- 非常に大きなキャッシュエントリ(代わりにストリーミングを検討)
- ファイルコンテンツ以外のパラメータに依存する結果(例:異なる抽出設定)


