BIエンジニアをやっていたら必ず発生する問題といえば・・・
「BIが遅い！！！」
そうパフォーマンス問題です。
エンジニアでもパフォーマンス改善というのはかなり難しいですが、自分の経験を活かせそうなので記事にまとめてみます。
おことわり
- 筆者の専門がMotionBoard・Dr.Sumのため、一部 MotionBoard・Dr.Sumに限定した記述 が含まれます。
- わかりやすいようイメージで記述する部分がありますが、すべてに対して正確な裏付けを取っているわけではありません。
正確な仕様を把握したい場合は、お使いのサービスの公式サポートにお問い合わせください。
１．パフォーマンス低下の主な原因
パフォーマンス問題が発生しました。あなたはどれくらい原因箇所が浮かびますか？
思いついた原因の数とBIシステムの理解度はわりと比例すると思います。
考え方は色々あると思いますが、僕なりに分類分けしてみたのが以下です。
「遅いからBIツールを変えてみた」とか「サーバースペックを上げてみた」という対応をよく聞きますが、あくまでこれらは解決策の１つであるということがわかると思います。
２．パフォーマンス改善効果の確認
この記事では「どうパフォーマンスを改善するか」ということを書いていくのですが、その前に重要なことがあります。
それが
「パフォーマンス改善することでどの程度効果を得られるか？」
ということです。
厳密に効果測定する方法は、実際に改善するまでわからないのですが、１つの判断基準をご紹介しようと思います。
それが
BIツールからデータベースのテーブルを参照する
という方法です。
テーブル参照により速度の限界値を知る
パフォーマンス改善ではサーバースペックを上げるのは最後の手段であることがほとんどなので、「BIツールとデータベースの修正でどこまで速度を上げられるのか？」ということを早めに把握する必要があります。
そして、BIツールとデータベース修正で実現できる最速値が
「BIツールからデータベースのテーブルを参照する」
という方法になります。
Dr.Sumであればビューからテーブルへのデータエクスポート機能があります。
他のデータベースであればBIが参照しているビューのデータを全てSELECT INTOでテーブルに投入すればよいでしょう。
データ投入の時間はかかりますが、難しい作業ではありません。
テーブル参照した結果からわかること
テーブル参照した場合とビューを参照した場合の違いは何でしょうか。
それは「結合」と「データベース関数」の処理がテーブルを参照した場合には無くなるということです。
つまりテーブルを参照した場合にデータを表示するまでの時間は
BIでデータ表示するまでの時間 = データベースの集計処理時間 ＋ BIツールの処理時間
となります。
もしこの速度でも満足できないのであればデータベース側でチューニングできる要素がほぼありません。
そのような場合には
- サーバースペックを上げる
- BIの画面要件を落とす
- BIの長所である集計の柔軟性を失ってでもあらかじめ集計後テーブルを作成する
という解決策を検討する必要が出てきます。
チューニングし終わった後に結局上のような結末になるのは残念すぎるので、チューニング作業前には確認しておくと良いでしょう。
３．次回予告
ここまではパフォーマンスに関する基本と、実際に改善する前にやることについての話でした。
次回以降で具体的な原因箇所の調査方法や改善方法を書いていこうと思います。