JPiereを使用したボリュームテストのメモ。
受発注伝票のヘッダー合計で200万伝票、明細で2,000万明細を超えているが、基本的な操作は問題なく行えている。
JPiereでは、大量ボリュームを意識した各種設定を予め施しています。詳しくは"JPiereのパフォーマンス改善への取り組み"を参照して下さい。
テスト環境
Windows10 - 64bit ノートPC
- Intel Core i7 - 4510U CPU @2.00GHz
- メモリ16GB
- SSD(※ただしボリュームテストのDBはUSB3接続の外付けSSD）
- PostgreSQL9.4
【補足説明】前回の100万伝票レベルの検証環境からの変更点
データストレージとして使用しているUSB3接続の外付けのHDDをSSDに変更した。外付けなのは変わらないが、HDDをSSDに変えた事で、伝票の登録が体感で3倍くらい処理できるようになった。HDDでは、どうしてもI/Oがボトルネックとなり、CPUの使用率が上がらずCPUは常に余裕がある状態だったが、SSDに変更してからは反対にCPUの使用率が100%に近い状態で、I/Oは10%前後とかなり余裕がある状態である。
DB概要
USB3接続の外付けSSD(2TB)にデータを格納。
DBサイズ：約130GB
ダンプファイルサイズ：約80GB
取得時間：約1時間
DBクラスタのコールドバックアップした場合のZIPファイルサイズ：約25.5GB
圧縮時間：約3時間
主なマスタ情報
取引先マスタ - 10万件
◆C_BPartnerテーブル情報
- レコード件数(Count関数使用):100,125
- テーブルサイズ(統計情報参照)：44MB
- インデックスサイズ(統計情報参照):32MB
品目マスタ - 10万件
◆M_Productテーブル情報
- レコード件数(Count関数使用):100,080
- テーブルサイズ(統計情報参照)：31MB
- インデックスサイズ(統計情報参照):29MB
販売管理と購買管理
受注伝票と発注伝票 - 合計206万伝票
1伝票10明細で伝票登録。
受注伝票(標準入力:登録専用)ウィンドウにおいて、通常通り伝票登録できる事を確認した。
◆C_Orderテーブル情報
- レコード件数(Count関数使用):2,065,241
- テーブルサイズ(統計情報参照)：907MB
- インデックスサイズ(統計情報参照):922MB
◆C_OrderLineテーブル情報
- レコード件数(Count関数使用):20,649,887
- テーブルサイズ(統計情報参照)：6760MB
- インデックスサイズ(統計情報参照):5356MB
【メモ】
- 発注-入荷-請求照合フォームの画面を開くのが前回調査時よりさらに少し遅くなった気がする…。10~15秒くらいで開くので我慢できないほどではないが…。おそらくフォームを開く際に、カウント系のSQLが実行されているのではないかと思われるので要確認。
出荷納品伝票と入荷伝票 - 合計206万伝票
1伝票10明細で伝票登録。
受注伝票をもとに出荷納品伝票を作成し、通常通り伝票登録ができる事を確認した。
◆M_InOutテーブル情報
- レコード件数(Count関数使用):2,065,169
- テーブルサイズ(統計情報参照)：765MB
- インデックスサイズ(統計情報参照):1015MB
◆M_InOutLineテーブル情報
- レコード件数(Count関数使用):20,649,752
- テーブルサイズ(統計情報参照)：5338MB
- インデックスサイズ(統計情報参照):3626MB
売上請求伝票と仕入請求伝票 - 合計222万伝票
1伝票10明細で伝票登録。
売上請求伝票(標準入力:登録専用)ウィンドウで受注伝票をもとに売上請求伝票を作成し、通常通り伝票登録ができる事を確認した。
◆C_Invoiceテーブル情報
- レコード件数(Count関数使用):2,227,817
- テーブルサイズ(統計情報参照)：816MB
- インデックスサイズ(統計情報参照):1473MB
◆C_InvoiceLineテーブル情報
- レコード件数(Count関数使用):22,275,842
- テーブルサイズ(統計情報参照)：6,241MB
- インデックスサイズ(統計情報参照):4,582MB
債権債務管理
入金伝票と支払伝票 - 合計207万伝票
ひと月ごとに売上／仕入請求伝票をまとめて支払う想定で入金／支払処理を実行。
入金伝票を、通常通り登録し、消込処理画面で消込処理が行えることを確認した。
◆C_Paymentテーブル情報
- レコード件数(Count関数使用):2,072,430
- テーブルサイズ(統計情報参照)：576MB
- インデックスサイズ(統計情報参照):552MB
消込伝票 - 合計205万伝票
ひと月ごとに売上／仕入請求伝票をまとめて支払う想定で入金／支払処理を実行。
◆C_AllocationHdrテーブル情報
- レコード件数(Count関数使用):2,056,564
- テーブルサイズ(統計情報参照)：532MB
- インデックスサイズ(統計情報参照):543MB
◆C_AllocationLineテーブル情報
- レコード件数(Count関数使用):2,175,822
- テーブルサイズ(統計情報参照)：377MB
- インデックスサイズ(統計情報参照):359MB
出納帳
◆C_BankStatementテーブル情報
- レコード件数(Count関数使用):3,302
- テーブルサイズ(統計情報参照)：19MB
- インデックスサイズ(統計情報参照):3.4MB
◆C_BankStatementLineテーブル情報
- レコード件数(Count関数使用):1,949,112
- テーブルサイズ(統計情報参照)：504MB
- インデックスサイズ(統計情報参照):402MB
在庫管理
在庫管理台帳テーブル情報
◆M_Transactionテーブル情報
- レコード件数(Count関数使用):22,460,478
- テーブルサイズ(統計情報参照)：3,734MB
- インデックスサイズ(統計情報参照):2,601MB
◆M_StorageOnHandテーブル情報
- レコード件数(Count関数使用):5,908,427
- テーブルサイズ(統計情報参照)：1,080MB
- インデックスサイズ(統計情報参照):1,520MB
◆M_StorageReservationテーブル情報
- レコード件数(Count関数使用):1,000,115
- テーブルサイズ(統計情報参照)：166MB
- インデックスサイズ(統計情報参照):340MB
会計
FACT_ACCTテーブル情報 8700万レコード
- レコード件数(Count関数使用):87,058,500
- テーブルサイズ(統計情報参照):28GB
- インデックスサイズ(統計情報参照):21GB
会計レポート関係
◆会計レポート表示
キューブ再計算の実行後で、勘定科目レベルの残高だけFACT_Acct_Summaryテーブルに保持ている状態であれば、レポート表示はまったく問題ない。BS残高であってもほんの数秒で表示される。再計算が必要な場合も勘定科目残残高レベルの1会計期間分であれば、それほど時間はかからないのではないかと思われる。
◆キューブ再計算 - 勘定科目残高
勘定科目残高のキューブ再計算プロセス。2011年～2020年の10年(120会計期間)×組織数7。基本的に自動仕訳のみのデータなので、勘定科目レベルの残高にするとレコード件数的には少なくなる。
- レベル 7246レコードインサート
- フル再計算の処理時間3313秒(約55分）
上記処理後に請求受注の伝票タイプで受注伝票を1枚完成にした後に、会計レポートを再表示すると13秒程度で表示される。再計算がある場合で13秒程度という事であり、再計算の必要がなければ、すぐに表示される。