Pega の性能とレポート設計

レポートの性能、公開列とインデックス、データの保持、ノードの構成を扱う記事です。

この領域で判断すること

Pega の性能問題の多くは、BLOB に格納されたデータへの検索と、増え続けるテーブルから生まれます。どの項目を公開列にするか、集計をいつ行うか、古いデータをどう退避するかといった判断を、本番で遅くなってからではなく設計の段階で決めるための記事です。

01
Pega Report Definition パフォーマンス設計｜Join・サブレポート・列最適化の判断
Report Definition は書けば動きますが、結合とフィルタの設計を誤ると本番データ量で一気に遅くなります。鍵は「公開列で結合・フィルタ・ソートしているか」——BLOB 内の未公開プロパティを条件にした瞬間、全行展開のスキャンに落ちます。本記事では Join とサブレポートの使い分け、集約とインデックス、列最適化の判断基準を実務目線でまとめます。
02
Pega 公開列とインデックス設計｜BLOB格納とレポート性能の最適化
レポートが遅い、フィルタが効かない——原因の多くは非公開プロパティへのアクセスで BLOB 展開が発生していることにある。公開列とインデックスは万能ではなく、増やすほど書き込みは重くなる。本記事は何を公開し何を BLOB に残すかの判断基準を扱う。
03
Pegaのテーブル肥大化対策｜アーカイブとパージの設計判断
作業テーブルや履歴テーブルは黙っていても増え続け、クエリ性能を蝕む。消してよいデータと退避すべきデータをどう切り分け、保持ポリシーと参照整合性をどう守るか。アーカイブ/パージ設計のよくある失敗と回避策を整理する。