django-materialized-views

Django マテリアライズドビュー

高コストな読み取りクエリが頻繁に再利用され、制御された範囲でデータが古くなることを許容できる場合に、このスキルを使用します。まずクエリプラン、インデックス、ORM 式の改善を試してください。マテリアライズドビューを導入すると、運用上の状態管理が必要になります。

ワークフロー

1. 適合性を確認します。

   • 元のクエリのコストが高く、安定しています。
   • 利用側が古いデータを許容できます。
   • 更新頻度、管理責任者、障害時の動作が明確です。
   • 対象のデータベースは PostgreSQL です。

2. マテリアライズドビューを設計します。

   • SQL クエリと出力列を定義します。
   • 同時更新が必要な場合は、一意の列または一意の列の組み合わせを追加します。
   • ビューに対する利用側のクエリに合わせてインデックスを追加します。

3. Django に統合します。

   • RunSQL でビューを作成します。
   • managed = False を設定した非管理モデルとして表現します。
   • 非管理モデルのフィールドを SQL の出力列と一致させます。
   • アプリケーションの境界で書き込みを不可能にします。

4. 更新を実装します。

   • 単純な更新には REFRESH MATERIALIZED VIEW を使用します。
   • REFRESH MATERIALIZED VIEW CONCURRENTLY は、ビューにデータが格納済みで、条件を満たす一意インデックスがある場合に限って使用します。
   • 管理コマンド、タスクキュー、またはデータベースジョブを通じて更新をスケジュールします。

マイグレーション、モデル、更新のテンプレートについては、materialized-view-patterns.md を参照してください。

安全上の注意

• マテリアライズドビューは保存済みのデータを返すため、自動的に最新の状態になるわけではありません。
• 同時更新を使用すると読み取りをブロックせずに済みますが、前提条件があり、ビューごとに一度に実行できる更新は 1 つだけです。
• 大規模なビューの更新は、データベースに大きな負荷をかける可能性があります。読み取りとは分けて測定してください。

検証

SQL が元のテーブルに対して正しいことを検証し、非管理モデルによる読み取りをテストし、更新の動作を確認したうえで、更新前後の読み取りレイテンシを測定します。