content-hash-cache-pattern

Topics in the source

• コンテンツハッシュファイルキャッシュパターン
• 起動条件
• コアパターン
• 1. コンテンツハッシュベースのキャッシュキー
• 2. キャッシュエントリの凍結データクラス
• 3. ファイルベースのキャッシュストレージ
• 4. サービスレイヤーラッパー（SRP）
• 主要な設計上の決定

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