🚀 MotionBoard が重い…そんな悩みから始まった
MotionBoard で大量データを扱うと、 「画面が重い」「表示に時間がかかる」 といった問題に直面することがあります。
私の環境でもまさに同じ状況でした。
- データ件数：約 1,000万件
- 項目数：約 70項目
- 期間：2010〜2025年（15年分）
- データソース：Dr.Sum
この規模になると、データの持ち方次第でパフォーマンスが大きく変わります。
❌ UNION の限界：大量データでは致命的に遅い
当初は、年別に分割された複数テーブルを UNION でまとめて MotionBoard に渡していました。
しかし、この UNION が本当に遅い。
- 全テーブルを読み込む
- 結合
- ソート（重複排除）
- MotionBoard が毎回クエリを投げる
データ量が増えるほど処理が重くなり、 画面表示に数分かかるようになりました。
結論：UNION は大量データでは致命的に遅い。
✔ 単一テーブル化の効果：爆速になった
そこで私は思い切って、
👉 夜間バッチで全データを1つのテーブルに統合し、MotionBoard は単一テーブルを直接参照する方式に変更
これが大正解でした。
Dr.Sum は 単一テーブルの高速検索に最適化されたエンジンなので、
- インデックスが効く
- WHERE 条件が素直に効く
- キャッシュも効きやすい
- MotionBoard のフィルタがそのまま最適化される
結果として、画面表示が 体感で“爆速” になりました。
UNION 時代：数分 → 単一テーブル化後：3秒未満
本当に世界が変わりました。
🧮 集計処理は極力バッチで行い、View ではなくテーブルを直接参照させる
✔ 集計や加工は極力バッチで前処理
MotionBoard や View に負荷をかけず、 必要な形に整えたデータをテーブルとして用意することで、 Dr.Sum の検索性能を最大限に活かせます。
✔ View 経由ではなく、テーブルを直接参照
View は便利ですが、
- 複雑な計算
- JOIN
- UNION などが含まれると、MotionBoard のレスポンスが一気に悪化します。
Dr.Sum は“テーブル直参照”が最速。
そのため、 「View で頑張る」のではなく 「バッチで作ったテーブルを直接参照させる」 という設計が圧倒的に有利です。
🧭 ただし、単一テーブル化できない環境もある
私の環境では夜間バッチが組めましたが、 すべての現場で同じ方法が取れるわけではありません。
例えば、
- バッチ処理の時間が確保できない
- 運用ルール上、統合テーブルを作れない
- データ更新がリアルタイムで頻繁
- 年別テーブルの構造が変わる可能性がある
こういったケースでは、 単一テーブル化という最適解が選べないことがあります。
📌 そんなときの“次善策”として使えるのがマルチビュー
単一テーブル化ができるなら、それが最速です。でも、どうしても難しい環境もあります。
そんなときにマルチビューを使うことも可能です。
🧩 マルチビューとは？
🎯 複数テーブルを“1つのテーブルのように扱える”Dr.Sum の仕組み
例えば、こんな年別テーブルがあるとします。
- 売上_2010
- 売上_2011
- 売上_2012
- …
- 売上_2025
これらをマルチビューで束ねると、MotionBoard からは 「売上」という1つのテーブルとして扱えるようになります。
⚡ マルチビューのメリット（次善策としては優秀）
- UNION より圧倒的に速い
- 必要なテーブルだけ参照する（パーティション的動作）
- MotionBoard からは1テーブルとして扱える
ただし、単一テーブル化には及びません。
🆚 単一テーブル参照 vs マルチビュー
どちらが速いのか？
結論は明確です。
🥇 最速：単一テーブル参照
- Dr.Sum の性能を最大限引き出せる
- 今回の私の環境はこれで爆速化
- UNION のボトルネックを完全に排除できる
- View を使わずテーブル直参照が最強
🥈 次善策：マルチビュー
- 単一テーブル化できない場合の選択肢
- UNION よりは圧倒的にマシ
- 年別テーブル運用をそのまま活かせる
🔧 さらに高速化するために行ったこと
- 日付列にインデックスを付与
- ID系（顧客ID・商品ID）にもインデックス
- MotionBoard の初期表示を「直近1年」に設定
- データソースで不要な列を除外
- キャッシュを有効化
これらを組み合わせることで、さらに高速化できます。
🎯 まとめ：一番伝えたいこと
🔥 1. UNION は大量データでは本当に遅い（致命的）
🔥 2. 単一テーブルに統合したら爆速になった（世界が変わる）
🔥 3. 集計は極力バッチで行い、View ではなくテーブル直参照が最速
🔥 4. 単一テーブル化できない場合は、マルチビューを“次善策”として検討
MotionBoard × Dr.Sum のパフォーマンスは、 データ構造と設計次第で劇的に変わります。
同じように悩んでいる人の参考になれば幸いです。
コメント