Getting Started - Japanese

日本JasperReportsコミュニティページ日本Jaspersoftコミュニティページへようこそ！

作成：小沢仁

新年おめでとうございます。今年ももっとJasperReportsを使いやすいように改善して行く予定です！

先ずは当たり前のことを当たり前のようにできるようにします。

 

レスポンスタイムを100ms以内でビッグデータを扱うレポーティング／BIシステムの構築について検討します。

機能が豊富なシステムでも、１操作に20秒以上も掛かっていたら、ユーザは実際にはこの機能を使いません。レポートを出力する時間が私の睡眠時間よりも長いのも問題だと思っています。

幸いにもJasperReportsでビッグデータを高速に扱えることができます。そのためにはソフトウエアデザインとシステム構成が重要になります。

 

本サイトは「ただ動くものの作りかた」ではなく、ユーザが実際に使えるシステムを構築するノウハウを蓄積していきたいと思います。

ビッグデータを扱いレポート／BI分析をレスポンスタイム1秒以内で行うためには今までとは異なった技術が必要です。システムの構成から初めて、レポートの作り方、データソースなどなどすべての面で従来のレポート／BIツールとはことなった考え方が必要です。

本サイトはこのように一歩進んだ本格的なレポート／BIについての情報を纏めていきます。主にApacheプロジェクトのビッグデータ関係のプロジェクトを中心にします。

 

キャッシュに依存している設計だと、

if (data > memory) then {you = history}

 

「データ容量が実メモリの容量よりも多いと、システム設計者は不要の人になってしまう」

 

  • 基本的な考え方
    JasperReportsを使ってビッグデータを処理することはできる。問題となるのはJasperReportsの使われ方である。
     
  • システム構成
    (1)RDBは使わない。データベースが性能のネックになっていることが多いです。データが少ない場合であればRDBの方が性能は良いですが、RDBはビッグデータを処理するのには不十分です。
    (2)ビッグデータはAPサーバ間で共有しない。ビッグデータを扱う場合は、APサーバをクラスタリングして共有メモリを有効にすると、ビッグデータ用のメモリを共有するためのオーバーヘッドが高くなってしまう。
    (3)レポーティング, BIのシステムは別々に考える。
    (4)OSSを利用する。ビッグデータを扱う場合はスケールアウトすることがあります。商用製品を使っている場合だと新規にライセンスを購入する必要になります。
     
  • レポートの作り方
    データベースからレポート用に取得するSQL文にCASE, JOIN, UNIONは使わない。CASE, JOIN, UNION処理は単純なSELECT文より遅いです。マスタテーブルの列をすべての行に追加するとデータ量が多くなり、データベースとネットワークに負荷を掛けることになります。列が多くなるとAPサーバのメモリも多く使われるようになるため、同時ユーザ数が増えるとメモリ不足になり、性能が悪化します。

 

 

 

旧ページ＞＞

Feedback
randomness