JPiereを使用したボリュームテストのメモ。
基本的な操作は問題なく行えている。このレベルになると、登録専用の画面を作成し、更新の際には検索ウィンドウよりズームするようにするなど、操作的に大量ボリューム対応できるように準備しておく必要があると感じる。
JPiereでは、大量ボリュームを意識した各種設定を予め施しています。詳しくは"JPiereのパフォーマンス改善への取り組み"を参照して下さい。
ボリュームテストの目標としていた1,000万伝票1億明細を達成したので、ボリュームテストはひとまずこれで終了します。
テスト環境
Windows10 - 64bit ノートPC
- Intel Core i7 - 4510U CPU @2.00GHz
- メモリ16GB
- SSD(※ただしボリュームテストのDBはUSB3接続の外付けSSD）
- PostgreSQL9.4
DB概要
USB3接続の外付けSSD(2TB)にデータを格納。
DBサイズ：約564GB
【補足説明】
データボリュームによるパフォーマンスの違いを検証するために、900万伝票に達する過程で次のテーブルのレコードをいったんすべて削除しました。
- M_CostDetail
- M_CostHistory
検証の結果としては、上記のテーブルのレコードを削除しても、出荷納品伝票や入荷伝票の登録パフォーマンスに好影響がある事は確認できませんでした。
【補足説明】インデックスの追加
900万伝票に達する過程でC_OrdetテーブルのBill_BPartner_IDにインデックスを追加しています。これにより、900万伝票から1000万伝票にかけての伝票登録処理を大幅に短縮化する事ができました。
[関連するコンテンツ]
主なマスタ情報
取引先マスタ - 10万件
◆C_BPartnerテーブル情報
- レコード件数(Count関数使用):100,125
- テーブルサイズ(統計情報参照)：47MB
- インデックスサイズ(統計情報参照):42MB
品目マスタ - 10万件
◆M_Productテーブル情報
- レコード件数(Count関数使用):100,080
- テーブルサイズ(統計情報参照)：31MB
- インデックスサイズ(統計情報参照):23MB
販売管理と購買管理
受注伝票と発注伝票 - 合計1,000万伝票 1億明細
1伝票10明細で伝票登録。
受注伝票(標準入力:登録専用)ウィンドウと発注伝票ウィンドウ(標準入力)において、通常通り伝票登録できる事を確認した。
◆C_Orderテーブル情報
- レコード件数(Count関数使用):10,025,955
- テーブルサイズ(統計情報参照)：4,277MB
- インデックスサイズ(統計情報参照):4,562MB
◆C_OrderLineテーブル情報
- レコード件数(Count関数使用):100,318,226
- テーブルサイズ(統計情報参照)：40GB
- インデックスサイズ(統計情報参照):24GB
出荷納品伝票と入荷伝票 - 合計1,002万伝票 9,031万明細
1伝票10明細で伝票登録。
受注伝票をもとに出荷納品伝票を作成し、通常通り伝票登録ができる事を確認した。同様に、発注伝票から入荷伝票を作成し、通常通り伝票登録ができる事を確認した。
◆M_InOutテーブル情報
- レコード件数(Count関数使用):10,025,884
- テーブルサイズ(統計情報参照)：3,656MB
- インデックスサイズ(統計情報参照):4,391MB
◆M_InOutLineテーブル情報
- レコード件数(Count関数使用):100,318,080
- テーブルサイズ(統計情報参照)：21GB
- インデックスサイズ(統計情報参照):18GB
発注照合伝票 - 合計391万伝票
◆M_MatchPOテーブル情報
- レコード件数(Conut関数使用):3,916,109
- テーブルサイズ(統計情報参照)：996MB
- インデックスサイズ(統計情報参照):1748MB
売上請求伝票と仕入請求伝票 - 合計1,019万伝票 9,204万明細
1伝票10明細で伝票登録。
売上請求伝票(標準入力:登録専用)ウィンドウで受注伝票をもとに売上請求伝票を作成し、通常通り伝票登録ができる事を確認した。同様に仕入請求伝票(標準入力)でも通常通り、伝票登録ができる事を確認した。
◆C_Invoiceテーブル情報
- レコード件数(Count関数使用):10,198,514
- テーブルサイズ(統計情報参照)：3,874MB
- インデックスサイズ(統計情報参照):8,049MB
◆C_InvoiceLineテーブル情報
- レコード件数(Count関数使用):102,043,765
- テーブルサイズ(統計情報参照)：25GB
- インデックスサイズ(統計情報参照):20GB
請求照合伝票 - 合計391万伝票
◆M_MatchInvテーブル情報
- レコード件数(Conut関数使用):3,911,707
- テーブルサイズ(統計情報参照)：938MB
- インデックスサイズ(統計情報参照):1459MB
債権債務管理
入金伝票と支払伝票 - 合計953万伝票
ひと月ごとに売上／仕入請求伝票をまとめて支払う想定で入金／支払処理を実行。
入金伝票を、通常通り登録し、消込処理画面で消込処理が行えることを確認した。
◆C_Paymentテーブル情報
- レコード件数(Count関数使用):9,538,003
- テーブルサイズ(統計情報参照)：3,091MB
- インデックスサイズ(統計情報参照):4,775MB
消込伝票 - 合計932万伝票
ひと月ごとに売上／仕入請求伝票をまとめて支払う想定で入金／支払処理を実行。
◆C_AllocationHdrテーブル情報
- レコード件数(Count関数使用):9,321,195
- テーブルサイズ(統計情報参照)：2,581MB
- インデックスサイズ(統計情報参照):3,474MB
◆C_AllocationLineテーブル情報
- レコード件数(Count関数使用):9,515,440
- テーブルサイズ(統計情報参照)：1,651MB
- インデックスサイズ(統計情報参照):1,535MB
出納帳
◆C_BankStatementテーブル情報
- レコード件数(Count関数使用):12,767
- テーブルサイズ(統計情報参照)：19MB
- インデックスサイズ(統計情報参照):42MB
◆C_BankStatementLineテーブル情報
- レコード件数(Count関数使用):9,413,045
- テーブルサイズ(統計情報参照)：2,300MB
- インデックスサイズ(統計情報参照):2,240MB
在庫管理
在庫管理台帳テーブル情報
◆M_Transactionテーブル情報
- レコード件数(Count関数使用):102,279,192
- テーブルサイズ(統計情報参照)：17GB
- インデックスサイズ(統計情報参照):12GB
◆M_StorageOnHandテーブル情報
- レコード件数(Count関数使用):1,214,484
- テーブルサイズ(統計情報参照)：2,096MB
- インデックスサイズ(統計情報参照):3,394MB
◆M_StorageReservationテーブル情報
- レコード件数(Count関数使用):1,000,115
- テーブルサイズ(統計情報参照)：172MB
- インデックスサイズ(統計情報参照):384MB
会計
FACT_ACCTテーブル情報 3億8千700万レコード
- レコード件数(Count関数使用):387,158,067
- テーブルサイズ(統計情報参照):124GB
- インデックスサイズ(統計情報参照):92GB
勘定科目レベル残高のキューブの全レコード再作成時間：約8時間
勘定科目レベル残高のキューブの全レコード再作成後に売上請求伝票を1伝票作成し転記した後で、その転記を反映した会計レポートが表示されるまでの時間:約25秒
関連するコンテンツ
- 【iDempiere Lab】JPiereのボリュームテストメモ-900万伝票9000万明細レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-700万伝票7000万明細レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-600万伝票6000万明細レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-500万伝票5000万明細レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-300万伝票レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-200万伝票レベル
- 【iDempiere Lab】JPiereのボリュームテストメモ-100万伝票レベル