2018/03/04

【iDempiere Lab】1000万伝票1億明細を登録した感想と大量データへの対策

約1年ほどかけて、オープンソースのERP iDempiere/JPiereのボリュームテストを実施してきました。受注伝票、出荷納品伝票、売上請求伝票については、それぞれ1000万伝票ヘッダ、1億明細を超えていますが、データの登録だけを考えれば、まだまだ行けそうだなという感じを得ています。

しかしシステム運用は、データの登録だけではありません。データを更新するのはもちろん、データを一覧表示するレポートも必要です。それらの事が快適に行える必要があります。

そこで1000万伝票ヘッダ、1億明細を登録した経験を踏まえて、大量データ環境でもiDempiere/JPiereを快適に使うための方法を調査及び研究し、その成果をまとめてみました。

JPiereではここで紹介している内容を意識してカスタマイズを施しています。詳しくはJPiere lab -> カスタマイズ -> JPiereのパフォーマンス改善への取り組み を参照して下さい。

目次

 

ボリュームテストの経過

はじめにボリュームテストの経過を掲載しておきます。

トップのタブに表示負荷が高いガジェットを使用しない

データが大量になってくると、ログイン直後に表示されるタブに配置されているガジェットによってもログイン処理が長くなってきます。ここでログイン処理が長くなる恐れがあるガジェットを紹介しておきます。

業務状況確認ガジェット

業務状況確認のガジェットはとても便利なガジェットですが、データ件数を数えていますので、数える対象となるテーブルに大量にデータがある場合、ログイン処理が長くなる可能性があります。

業務状況確認ガジェット
業務状況確認ガジェット

大量データを想定した場合、業務状況確認に表示させる項目は厳選すべきですし、業務状況確認は使用せずに同様のデータを表示する"一覧レポート"を活用するのをオススメします。

 

パフォーマンスメーター

パフォーマンスメーターは、目を引くガジェットではありますが、表示するためにSQLを発行しています。大量データを処理するSQLを発行すると、それだけログイン処理が長くなりいます。

パフォーマンスメーターガジェット
パフォーマンスメーターガジェット

ログイン直後に確認できるのは、BI(Business Intelligence)として魅力的ですが、表示する必要がない場合でも、ログイン時に必ず計算して表示しますので、システムの負荷的には好ましくありません。

Jasper Reportsを活用してレポートで対応するのが良いのではないかと思います。

データの表示件数の制御

iDempiereを快適に使うために確実に実施すべきなのは、データの表示件数の制御です。どんなシステムでも一度に表示するデータ件数が多くなればなるほど、色々な所に負荷がかかります。ユーザーが意図せず、大量のデータを表示させる事が無いように、データの表示件数の制御は実施すべきです。

データ入力画面(ウィンドウ)のデータ表示件数の制御

データ入力画面(ウィンドウ)のデータ表示件数の制御は"職責"の"最大クエリレコード"フィールド(MaxQueryRecords)で設定する事ができます。このフィールドに設定した値は、すべてのウィンドウに適用されますので、設定する値をいくつにするかは難しいのですが、システム的には小さい値が好ましいですし、運用的には大きな値を設定したいと思います。

ウィンドウのデータ表示件数は100～1000程度がオススメ!!

そこで、個人的な設定値としては100～大きくても1000くらいに設定しておくのが良いのではないかと思います。ウィンドウの一覧表示において人間が目で見て探せるデータの件数は100件～1000件くらいが限界だと思います。この数より超える場合は、検索条件を追加して一覧表示するデータ件数を絞り込むべきです。

ウィンドウのデータ表示制限
ウィンドウのデータ表示制限

設定値を超えた場合、設定値までのデータを表示してくれます。

あまりにも表示するデータが多いとタイムアウトして処理が中断されます。タイムアウトさせる時間は、システムコンフィグ設定(GRIDTABLE_LOAD_TIMEOUT_IN_SECONDS)で指定する事ができ、iDempiereの初期設定では30秒になっています。

データ検索時(検索ウィンドウ)のデータ表示件数の制御

データ検索に使用する検索ウィンドウは、検索結果として表示するデータの件数をあらかじめ設定しておく事ができ、その設定を超える場合には、警告を表示して、設定値以内になるように検索条件を追加するように促します。

検索ウィンドウ
検索ウィンドウ

検索ウィンドウも、ウィンドウと同様の考え方で、人間が目で確認できるデータ件数を考慮して100件～200件程度を目安に検索の上限を設定しておくのが良いのではないかと思います。

帳票(レポート)のデータ表示件数の制御

一覧レポートを表示する際に、iDempiereの標準機能では、データの表示件数の制御が行われず、一覧レポートの抽出条件に該当するデータを全部表示しようとします。これはユーザーが間違えて、多くのデータを出力する抽出条件を指定してしまった場合、システム的に大きな負荷になってしまう場合があります。

そこでJPiereでは、レポートに表示するデータの件数を設定できるようにカスタマイズしていますので、活用して下さい。

関連するコンテンツ

システム負荷が軽い操作導線を用意しておく

ウィンドウを開く際にデータ件数を数える処理が実行されますので、大量データがあるウィドウに対しては、思わぬ負荷がかかる場合があります。それらを回避できる操作導線を用意しておくことも快適にシステムを運用するためには大切です。

データ登録処理

データ登録に際して、ウィンドウを開いて既存データを表示させてから新規作成ボタンを押す行為は、既存データを表示させる行為自体が無駄であり、無駄にシステムにリソースを消費しています。

◆ウィンドウを開く前にデータ登録アイコンを活用する

iDempiereではデータを登録する際に、既存データを表示しないで済むようにしていますので、それらの機能を活用する事で、既存データを表示させるという無駄な行為でシステムリソースを消費するのを防ぐ事ができます。

iDempiereのメニューツリーでは、メニューの横に新規作成のアイコンが表示されています。このアイコンをクリックする事で、データを新規に登録する状態でウィンドウを開く事ができます。

メニューを検索した際にも、同様に新規作成アイコンが表示されます。

ウィンドウを開くさいに表示されるFind Windowでも新規作成アイコンが表示されています。

上記に紹介した方法により、新規データを登録する際に、既存データを数えて表示するという無駄なシステムリソースの消費を防ぐ事ができますが、次に紹介するあらかじめデータ登録専用のウィンドウを表示する事もオススメです。

 

◆データ登録専用のウィンドウを用意する

JPiereではサンプルとして、受注伝票で登録専用のウィンドウを用意しています。

メニューから登録と更新を分ける事で、誤操作により思わぬシステムリソースの消費を防ぐ事ができます。

 

データ更新処理

データ更新処理に際して、更新対象ではないデータを表示するのは無駄にシステムリソースを消費としていと考える事ができます。そのような事を防ぐために、次の方法をオススメします。

◆大量データフラグをONにする

アプリケーション辞書のテーブルの設定にある大量データフラグをONにする事で、ウィンドウを開く前に、Find Window(検索条件入力画面)を表示させ、ウィンドウに表示させるデータを予め絞り込ませる事ができます。

Find Window
Find Window

◆検索ウィンドウで検索 ->【ズーム】-> ウィンドウで更新処理

大量データフラグをONにしても無視されて条件指定なしでウィンドウが開かれては意味がありません。またユーザーが条件を指定してくれてもシーケンシャルスキャンされてしまうと大量データにはパフォーマンスは期待できません。そこで、検索ウィンドウで先に検索させてから、更新したいデータを選択しウィンドウへズームして更新処理する操作導線をオススメします。

JPiereのメニューは受注伝票の検索ウィンドウをメニューに組み込んでいます。

例えばこれを受注伝票(更新)と名称を変更して、受注伝票の登録専用の画面と２つをメニューに表示しておけば、ユーザーは意識する事無くシステムに余計な負荷をかける事をかなり防げるはずです。

検索ウィンドウを使用すると、インデクスがはられている項目を検索の必須条件に加える事ができるのも大きなメリットです。そして、検索した結果を表示する件数も制限できるので不用意に多くのデータを表示する事を防ぐ事ができます。

検索ウィンドウで検索した結果表示されるデータを選択して、ズームアイコンをクリックするとウィンドウでデータを更新する事ができます。そのウィンドウはメニューにぶら下げないでおけば、ユーザーが直接そのウィンドを開くのを防ぐ事ができます。

 

◆一覧レポートで検索 ->【ズーム】-> ウィンドウで更新処理

一覧レポートもウィンドウへズームする事ができますので、上記で紹介した方法と同じ事ができます。

帳票(レポート)

大量データ環境でレポートのパフォーマンスを維持するために、DBにインデックススキャンさせる事と、大量のデータを表示させないようにする事を開発者の方は意識する必要があります。

関連するコンテンツ

適切なインデックスの追加

大量のデータが格納されているテーブルにシーケンシャルスキャンをするようなSQLを発行してしまうと、どんなシステムを使用していても良好なパフォーマンスは期待できません。適切なインデックスを追加して、インデックススキャンが行われるようにしないといけません。

関連するコンテンツ

 

インデックスをレポートの必須抽出条件にする

適切なインデックスを追加して、インデックススキャンされても、レポートに表示するデータが大量にあると、やはり良好なパフォーマンスは期待できません。サーバーに負荷がかかるだけでなく、ネットワークやデータを受け取り表示するクライアントのブラウザにとっても大きな負荷になります。

そのためレポートの抽出条件で、大量にデータが表示されないように予め制限をかけておくべきです。

インデックスがはられている項目を抽出条件で必須にし、伝票であれば日付をFrom～toで必須入力にさせる事で、レポート表示の良好なパフォーマンスが期待できます。

キャッシュマネジメント

大量データを登録して気が付いたのがキャッシュマネジメントの重要性です。キャッシュマネジメントはシステムの安定稼働にも欠かせません。キャッシュマネジメントについては下記リンク先にまとめていますので参照して下さい。

関連するコンテンツ

関連するコンテンツ

カテゴリ： 2018年研究日誌idempiere-lab