 |
|
|
|
|
|
| 1 2 3 4 次のページ
|
|
| バッチ・レポーティング機能
|
レポーティング・ツールで開発されるレポートは、リレーショナル・データベースに対してSQLクエリーを実行することで、初めて結果を表示することができます。このため定時に多くのユーザが同じレポートを参照しようとすると、データベース・サーバの負荷は一時的に大きくなってしまいます。
一方、レポーティング・ツールのユーザ層は他のユーザ層に比べて人数が多く、ピーク時の同時アクセス数を予想することは難しい場合が大半です。しかしレポーティング・ツール導入の際に、データベース・サーバのCPUの個数やメモリ容量を余裕を持てるだけの大きさにしようとすると、多大なコストが発生しかねません。
これを解決する方法のひとつが、あらかじめSQLクエリーを実行しておいて、その結果をキャッシュに保存しておくバッチ・レポーティング機能です。バッチ・レポーティング機能のメカニズムを図1に示します。
図1：バッチ・レポーティング機能のメカニズム
まず、スケジューラによりバッチ・モードで起動されたレポーティング・ツールがアプリケーション・サーバ上にあるレポートのクエリー定義からリレーショナル・データベースに対してクエリーを実行し、結果をアプリケーション・サーバ上のキャッシュに格納します（図1の1）。次に、ユーザからレポートが要求されると、レポーティング・ツールはキャッシュ上にあるクエリー結果をレイアウト定義に従ってレイアウトし、ユーザのブラウザ上に表示します（図1の2）。
この時のユーザのレポート要求は、リレーショナル・データベースに対してのアクセスは発生しません。また、クエリーの実行回数や同時実行数（基本的に1）もあらかじめ想定することができますので、データベース・サーバのCPUの個数やメモリ容量を比較的簡単に割り出すことができます。
一方、バッチ・レポーティング機能を使用する際の問題点は、運用スケジュール上の制限に合わせて、ユーザからのアクセスが集中する時間帯の前に必要なレポートをあらかじめ実行できるような計画を立てる必要があるという点です。しかし、あらかじめ実行しておくレポートの数をあまりに増やしすぎると、バッチ処理時間が長くなりすぎて運用上許される時間をオーバーしてしまう可能性もあります。したがって、あらかじめ実行するレポートは、同時アクセス数が多いと想定されるものだけにする必要があります。
|
| レポート・キャッシュ・サーバ機能
|
バッチ・レポーティング機能とは別にデータベース・サーバの負荷を軽減してくれるレポーティング・ツールの機能に、レポート・キャッシュ・サーバ機能があります。これは、あらかじめクエリー結果をキャッシュに格納しておくのではなく、レポート要求があった時に初めてクエリー結果をキャッシュに格納するという機能です。
同じレポートに対する2回目の要求からは、キャッシュに格納されたクエリー結果が使用されるため、データベース・サーバへのアクセスが少なくなります。しかしユーザから見ると、自分の行った要求が1回目なのか2回目以降なのかはわかりませんので、レポート表示までに要する時間が場合によっては大きく異なることに対して、クレームが発生する可能性があります。
このように、バッチ・レポーティング機能とレポート・キャッシュ・サーバ機能は一長一短がありますので、同時実行数やクエリーの複雑度などを考慮して、レポートによりこの2つの機能を使い分けることが必要です。
したがって、レポーティング・ツールの機能をチェックする際は、これら2つの機能を両方持っていることが理想的だといえます。
|
1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社アイエイエフコンサルティング 平井 明夫
日本DEC（現HP）、コグノス、日本オラクルを経て現職。一貫してソフトウェア製品の開発、マーケティング、導入コンサルティングを歴任。 特に、データウェアハウス、BI、OLAPを得意分野とする。現在、企業業績管理、管理会計などデータ分析ソリューションの短期導入を可能にするテンプレートやパッケージの開発を行っている。
|
|
この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！ インプレスIT INSIDE
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
