 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| バッチ・レポーティング機能 | ||||||||||||
|
レポーティング・ツールで開発されるレポートは、リレーショナル・データベースに対してSQLクエリーを実行することで、初めて結果を表示することができます。このため定時に多くのユーザが同じレポートを参照しようとすると、データベース・サーバの負荷は一時的に大きくなってしまいます。 一方、レポーティング・ツールのユーザ層は他のユーザ層に比べて人数が多く、ピーク時の同時アクセス数を予想することは難しい場合が大半です。しかしレポーティング・ツール導入の際に、データベース・サーバのCPUの個数やメモリ容量を余裕を持てるだけの大きさにしようとすると、多大なコストが発生しかねません。 これを解決する方法のひとつが、あらかじめSQLクエリーを実行しておいて、その結果をキャッシュに保存しておくバッチ・レポーティング機能です。バッチ・レポーティング機能のメカニズムを図1に示します。  図1：バッチ・レポーティング機能のメカニズム この時のユーザのレポート要求は、リレーショナル・データベースに対してのアクセスは発生しません。また、クエリーの実行回数や同時実行数（基本的に1）もあらかじめ想定することができますので、データベース・サーバのCPUの個数やメモリ容量を比較的簡単に割り出すことができます。 一方、バッチ・レポーティング機能を使用する際の問題点は、運用スケジュール上の制限に合わせて、ユーザからのアクセスが集中する時間帯の前に必要なレポートをあらかじめ実行できるような計画を立てる必要があるという点です。しかし、あらかじめ実行しておくレポートの数をあまりに増やしすぎると、バッチ処理時間が長くなりすぎて運用上許される時間をオーバーしてしまう可能性もあります。したがって、あらかじめ実行するレポートは、同時アクセス数が多いと想定されるものだけにする必要があります。 |
||||||||||||
| レポート・キャッシュ・サーバ機能 | ||||||||||||
|
バッチ・レポーティング機能とは別にデータベース・サーバの負荷を軽減してくれるレポーティング・ツールの機能に、レポート・キャッシュ・サーバ機能があります。これは、あらかじめクエリー結果をキャッシュに格納しておくのではなく、レポート要求があった時に初めてクエリー結果をキャッシュに格納するという機能です。 同じレポートに対する2回目の要求からは、キャッシュに格納されたクエリー結果が使用されるため、データベース・サーバへのアクセスが少なくなります。しかしユーザから見ると、自分の行った要求が1回目なのか2回目以降なのかはわかりませんので、レポート表示までに要する時間が場合によっては大きく異なることに対して、クレームが発生する可能性があります。 このように、バッチ・レポーティング機能とレポート・キャッシュ・サーバ機能は一長一短がありますので、同時実行数やクエリーの複雑度などを考慮して、レポートによりこの2つの機能を使い分けることが必要です。 したがって、レポーティング・ツールの機能をチェックする際は、これら2つの機能を両方持っていることが理想的だといえます。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
