django-queryset-batch-processing

Django QuerySet のバッチ処理

Django のコードで多数の行を処理する場合は、このスキルを使用します。不要なモデルインスタンスの読み込みや、QuerySet の結果キャッシュの肥大化を避け、動作上問題がなければ書き込みを集合ベースのデータベース操作に移行することを目指します。

ワークフロー

1. 行ごとの処理を特定します。

   • 読み取り専用のエクスポートやレポートですか？
   • モデルのメソッド、バリデーション、シグナルが必要ですか？
   • データベースで値を直接計算または更新できますか？

2. 読み取りパターンを選びます。

   • スカラー値のエクスポートやレポートには values() または values_list() を使用します。
   • モデルインスタンスが必要でも QuerySet のキャッシュが不要な場合は、iterator(chunk_size=...) を使用します。
   • 並び順は意図的に指定します。不要な並び替えは処理コストになります。

3. 書き込みパターンを選びます。

   • 一律の更新には、F() または式とともに QuerySet.update() を使用します。
   • オブジェクトごとに値が異なる場合は、bulk_update() を使用します。
   • 挿入には bulk_create() を使用します。競合オプションは、プロジェクトでその動作がサポートされている場合に限り指定します。
   • フック、バリデーション、副作用、シグナルが必要な場合にのみ、インスタンスごとの save() にフォールバックします。

4. バッチサイズを制御します。

   • トランザクションの規模を抑えます。
   • 巨大な IN リストや過度に大きな CASE 更新は避けます。
   • 本番ジョブでは、ロック、レプリケーションラグ、メモリを監視します。

例と注意事項については、batch-patterns.md を参照してください。

安全に関する注意事項

• 一括更新・削除操作では、各モデルインスタンスの save() メソッドや delete() メソッドは呼び出されません。
• 一括操作では、アプリケーションレベルの副作用やシグナルが省略されることがあります。
• 長時間のトランザクションはロックを保持し、バキュームやレプリケーションを遅延させる可能性があります。

検証

代表的なバッチで、1 秒あたりの処理行数、クエリ数、メモリ使用量、トランザクション時間、正確性を測定します。