django-db-performance

Django DB のパフォーマンス

Django のデータベースパフォーマンス作業では、オーケストレーションスキルとしてこれを使用します。測定に基づく証拠から始め、遅い処理経路を再現し、測定されたボトルネックを解消する最小限の最適化へ振り分けます。

基本的なワークフロー

1. 症状を記録します。

   • 対象となるエンドポイント、コマンド、タスク、レポート、またはクエリセットを特定します。
   • 現在の経過時間、クエリ数、遅い SQL、データベースバックエンド、データ量、Django のバージョンを記録します。
   • 問題を再現できる元のリクエストパラメーターまたはフィクスチャを保持します。

2. コードを変更する前にプロファイリングします。

   • APM トレース、データベースのスロークエリログ、Django Debug Toolbar、connection.queries、または対象を絞ったロギングを使用します。
   • コストの高いクエリが分かっている場合は、QuerySet.explain() またはデータベースの EXPLAIN を使用します。
   • API エンドポイントでは、クエリセットだけでなく、シリアライザーと権限チェックもプロファイリングします。

3. 主な問題を分類します。

   • 類似したクエリが何度も繰り返される場合：django-orm-query-optimization を使用します。
   • 1つか2つの SQL 文にコストがかかる場合：django-query-plan-reading と django-index-design を使用します。
   • メモリ使用量が多い場合、またはクエリセットを処理するループが長い場合：django-queryset-batch-processing を使用します。
   • 件数、合計、フラグ、または最新の関連行を計算する Python のループがある場合：django-db-side-computation を使用します。
   • 古いデータでも許容できる集計／レポートクエリが遅い場合：django-materialized-views を使用します。
   • 一覧ページの表示が遅い、または一貫しない場合：django-pagination-performance を使用します。
   • 根拠が不明確な場合：django-query-profiling を使用します。

4. 一度に1つの変更を適用します。

   • 期待される効果が明確な、最小限の変更を優先します。
   • 推測でインデックス、プリフェッチ、またはマテリアライズドビューを追加しないでください。
   • 小規模なフィクスチャだけでなく、本番環境に近いデータで最適化の効果を確認します。

5. 結果を検証し、記録します。

   • 同じパラメーターで同じリクエストまたはコマンドを再実行します。
   • クエリ数、DB 合計時間、経過時間、メモリ使用量、クエリプランを比較します。
   • 変更前後の根拠を PR または最終レポートに残します。

ルーティングのチェックリスト、よくある症状、変更前後の根拠を記録するテンプレートについては、diagnostic-flow.md を参照してください。

最新の Django に関する注意事項

• ORM のクエリプランを確認する際は、生の EXPLAIN に切り替える前に QuerySet.explain() を優先します。
• 適用できる場合は、手書きの並行インデックス作成 SQL より、AddIndexConcurrently などの Django／PostgreSQL ネイティブのマイグレーション操作を優先します。
• データベース処理を明示でき、十分に移植可能な場合は、ORM の式、Subquery、Exists、Window、GeneratedField、db_default を優先します。
• バックエンド固有の最適化は、すべてプロジェクトのデータベースに応じた条件付きのものとして扱います。PostgreSQL のパターンが MySQL、MariaDB、SQLite、Oracle にそのまま適用できるとは限りません。

検証

• 遅い処理経路が引き続き機能的に正しいことを示します。
• 測定されたボトルネックが改善したことを示します。
• 最適化によって、より悪いクエリ、古いデータに関するバグ、書き込み処理の性能低下、またはメモリの急増が発生していないことを示します。