【iDempiere Lab】JPiereのボリュームテストメモ-300万伝票レベル

JPiereを使用したボリュームテストのメモ。

JPiereでは、大量ボリュームを意識した各種設定を予め施しています。詳しくは"JPiereのパフォーマンス改善への取り組み"を参照して下さい。

 

テスト環境

Windows10 - 64bit ノートPC

  • Intel Core i7 - 4510U CPU @2.00GHz
  • メモリ16GB
  • SSD(※ただしボリュームテストのDBはUSB3接続の外付けSSD)
  • PostgreSQL9.4

DB概要

USB3接続の外付けSSD(2TB)にデータを格納。

DBサイズ:約203GB

ダンプファイルサイズ:約117GB -> 圧縮後 17GB

取得時間:約1時間20分 -> 圧縮時間 約40分

DBクラスタのコールドバックアップした場合のZIPファイルサイズ:約38GB

圧縮時間:約4時間40分

主なマスタ情報

取引先マスタ - 10万件

◆C_BPartnerテーブル情報

  • レコード件数(Count関数使用):100,125
  • テーブルサイズ(統計情報参照):46MB
  • インデックスサイズ(統計情報参照):36MB

品目マスタ - 10万件

◆M_Productテーブル情報

  • レコード件数(Count関数使用):100,080
  • テーブルサイズ(統計情報参照):31MB
  • インデックスサイズ(統計情報参照):23MB

販売管理と購買管理

受注伝票と発注伝票 - 合計313万伝票

1伝票10明細で伝票登録。

受注伝票(標準入力:登録専用)ウィンドウにおいて、通常通り伝票登録できる事を確認した。

◆C_Orderテーブル情報

  • レコード件数(Count関数使用):3,138,890
  • テーブルサイズ(統計情報参照):1556MB
  • インデックスサイズ(統計情報参照):1550MB

◆C_OrderLineテーブル情報

  • レコード件数(Count関数使用):31,447,725
  • テーブルサイズ(統計情報参照):10GB
  • インデックスサイズ(統計情報参照):10GB

出荷納品伝票と入荷伝票 - 合計313万伝票

1伝票10明細で伝票登録。

受注伝票をもとに出荷納品伝票を作成し、通常通り伝票登録ができる事を確認した。

◆M_InOutテーブル情報

  • レコード件数(Count関数使用):3,138,815
  • テーブルサイズ(統計情報参照):1,167MB
  • インデックスサイズ(統計情報参照):1,742MB

◆M_InOutLineテーブル情報

  • レコード件数(Count関数使用):31,447,576
  • テーブルサイズ(統計情報参照):7,313MB
  • インデックスサイズ(統計情報参照):6,590MB

 

売上請求伝票と仕入請求伝票 - 合計331万伝票

1伝票10明細で伝票登録。

売上請求伝票(標準入力:登録専用)ウィンドウで受注伝票をもとに売上請求伝票を作成し、通常通り伝票登録ができる事を確認した。

◆C_Invoiceテーブル情報

  • レコード件数(Count関数使用):3,311,465
  • テーブルサイズ(統計情報参照):1,223MB
  • インデックスサイズ(統計情報参照):2,329MB

◆C_InvoiceLineテーブル情報

  • レコード件数(Count関数使用):33,173,308
  • テーブルサイズ(統計情報参照):8,775MB
  • インデックスサイズ(統計情報参照):7,633MB

債権債務管理

入金伝票と支払伝票 - 合計320万伝票

ひと月ごとに売上/仕入請求伝票をまとめて支払う想定で入金/支払処理を実行。

入金伝票を、通常通り登録し、消込処理画面で消込処理が行えることを確認した。

◆C_Paymentテーブル情報

  • レコード件数(Count関数使用):3,201,803
  • テーブルサイズ(統計情報参照):1,006MB
  • インデックスサイズ(統計情報参照):1,533MB

 

消込伝票 - 合計318万伝票

ひと月ごとに売上/仕入請求伝票をまとめて支払う想定で入金/支払処理を実行。

◆C_AllocationHdrテーブル情報

  • レコード件数(Count関数使用):3,185,914
  • テーブルサイズ(統計情報参照):845MB
  • インデックスサイズ(統計情報参照):1054MB

◆C_AllocationLineテーブル情報

  • レコード件数(Count関数使用):3,310,823
  • テーブルサイズ(統計情報参照):574MB
  • インデックスサイズ(統計情報参照):551MB

 

出納帳

◆C_BankStatementテーブル情報

  • レコード件数(Count関数使用):6,030
  • テーブルサイズ(統計情報参照):19MB
  • インデックスサイズ(統計情報参照):6.7MB

◆C_BankStatementLineテーブル情報

  • レコード件数(Count関数使用):3,289,421
  • テーブルサイズ(統計情報参照):812MB
  • インデックスサイズ(統計情報参照):769MB

在庫管理

在庫管理台帳テーブル情報

◆M_Transactionテーブル情報

  • レコード件数(Count関数使用):33,410,415
  • テーブルサイズ(統計情報参照):5,554MB
  • インデックスサイズ(統計情報参照):4,292MB

◆M_StorageOnHandテーブル情報

  • レコード件数(Count関数使用):6,117,413
  • テーブルサイズ(統計情報参照):1,141MB
  • インデックスサイズ(統計情報参照):1,626MB

◆M_StorageReservationテーブル情報

  • レコード件数(Count関数使用):1,000,115
  • テーブルサイズ(統計情報参照):1,141MB
  • インデックスサイズ(統計情報参照):1,628MB

会計

FACT_ACCTテーブル情報 1億3000万レコード

  • レコード件数(Count関数使用):129,830,916
  • テーブルサイズ(統計情報参照):41GB
  • インデックスサイズ(統計情報参照):33GB

 

会計レポート関係

◆会計レポート表示

キューブ再計算の実行後で、勘定科目レベルの残高だけFACT_Acct_Summaryテーブルに保持ている状態であれば、レポート表示はまったく問題ない。BS残高であってもほんの数秒で表示される。再計算が必要な場合も勘定科目残残高レベルの1会計期間分であれば、それほど時間はかからないのではないかと思われる。

◆キューブ再計算 - 勘定科目残高

勘定科目残高のキューブ再計算プロセス。2011年~2020年の10年(120会計期間)×組織数7。基本的に自動仕訳のみのデータなので、勘定科目レベルの残高にするとレコード件数的には少なくなる。

  • レベル XXXXレコードインサート
  • フル再計算の処理時間XXXX秒(約XXX分

上記処理後に請求受注の伝票タイプで受注伝票を1枚完成にした後に、会計レポートを再表示するとXX秒程度で表示される。再計算がある場合でXX秒程度という事であり、再計算の必要がなければ、すぐに表示される。

関連するコンテンツ