サマリデータテーブル
1. 目的
- 複雑なクエリを要するDBのリードパフォーマンスを向上させたい
2. 課題
- クエリの発行回数が多すぎる
- 1回のクエリが10msecでも10回クエリが発行されると100msecかかることになる
- クエリのサイズが大きすぎる/複雑すぎる
- 多数のJOINや複雑な検索条件を要する複雑なクエリの為にクエリのパフォーマンスが悪い
- 一通りチューニングは済んでいるが、根本的にクエリのサイズが大きすぎる
3. 解決策
- サマリテーブルを作成し、事前にクエリ結果をキャッシュしておく
- データの追加・更新が発生したらバックグラウンドでサマリデータを作成する
4. メリット
- サマリデータへ対するクエリはシンプルになる（既に必要な情報は揃っているから）
5. デメリット
- サマリデータを作成する分だけシステムの構成要素が増えるので複雑化する
- サマリデータ作成失敗時のリカバリ処理が甘いといつまでたっても古いデータが表示されたままになってしまう
6. 注意事項
- メッセージキューで非同期処理にする場合は監視が特に重要になる
- エラー時のリランやリカバリの運用方針を決めておく必要がある
参考資料
Appendix-1 オンラインバッチを用いたサマリデータ生成フロー
