データベース・プルーニングによるアップグレードの高速化
データが多ければ多いほど、データのアップグレードには時間がかかります。 不要なサイトデータはよくあることだ。 データベースから不要なデータを削除することで、アップグレード処理のパフォーマンスが向上します。
例えば、サイトはウェブコンテンツの記事やドキュメント、メディアファイルの多くの未使用バージョンを保存することができる。 改訂が終わり、中間の改訂が必要なければ、安全に削除することができる。 これはスペースとアップグレード時間の節約になる。
データベースの剪定に関するトピックを紹介しよう:
- 重複するWeb コンテンツストラクチャーのフィールド名を削除する
- 未使用オブジェクトの検索と削除
- プルーニングされたデータベースのコピーを使用してテストする
廃止されたデータの削除
データベースに、廃止されたデータや廃止された機能から残ったデータが含まれている可能性があります。 どちらも簡単に削除できます。
データクリーンナップツール7.3以上使用可能。 データ削除ツールあり 7.4+
-
廃止されたモジュールのデータを削除するには、 データクリーンアップ ツールを使用します。
-
使用可能なモジュールから古いデータを削除するには、 データ削除 ツールを使用します。
重複するWeb コンテンツストラクチャーのフィールド名を削除する
ウェブ・コンテンツ・マネジメントを広く使っていれば、ユニークなフィールド名を持たない構造を持っているかもしれない。 アップグレードする前に、重複するフィールド名を見つけて削除する。 以前にLiferay Portal 6.2にアップグレードして、この作業をスキップした場合、このエラーが発生します:
19:29:35,298 ERROR [main][VerifyProcessTrackerOSGiCommands:221] com.liferay.portal.verify.VerifyException: com.liferay.dynamic.data.mapping.validator.DDMFormValidationException$MustNotDuplicateFieldName: The field name page cannot be defined more than once
com.liferay.portal.verify.VerifyException: com.liferay.dynamic.data.mapping.validator.DDMFormValidationException$MustNotDuplicateFieldName: The field name page cannot be defined more than once
このエラーが発生した場合は、Liferay Portal 6.2の以前のバックアップにロールバックし、重複するフィールド名を見つけて削除してください。
未使用のオブジェクトの削除
データベースには、使用されていないオブジェクトのデータが残っている場合があります。
- UI やデータベースで
SELECT
クエリを使用することで、未使用のオブジェクトを特定し、UI や スクリプトコンソール を通した API、または作成したポートレットからオブジェクトを削除します。
LiferayのUIまたはAPIはLiferay DXPのオブジェクト間の関係を考慮しているため、データの操作にはLiferayのUIまたはAPIのみを使用してください。 データベースでSQLを直接使用してレコードを削除しないでください。 SQLがオブジェクトの関係を見失い、オブジェクトが孤立し、パフォーマンスの問題が発生する可能性があります。
次に、未使用のオブジェクトをチェックするための一般的な場所を紹介する。
ラージテーブル/ポピュラーテーブルからのオブジェクト
テーブルの行はLiferay DXPのオブジェクトにマッピングされます。 多くのレコードを持つ大きなテーブルには、多くの未使用オブジェクトが含まれている可能性がある。 テーブルのサイズが大きく、テーブルあたりのレコード数が多ければ多いほど、アップグレードには時間がかかる。
このようなテーブルに関連付けられている未使用のオブジェクトを見つけて削除することで、アップグレードにかかる時間を短縮できる。 Liferayのバックアップからデータをインポートすることで、貴重なテーブル情報を得ることができます。 データベースエンジンは、この情報をさまざまな方法で表示する。 例えば、データベースのインポートログは次のようになる:
Processing object type SCHEMA\_EXPORT/TABLE/TABLE\_DATA
imported "LIFERAY"."JOURNALARTICLE" 13.33 GB 126687 rows
imported "LIFERAY"."RESOURCEPERMISSION" 160.9 MB 1907698 rows
imported "LIFERAY"."PORTLETPREFERENCES" 78.13 MB 432285 rows
imported "LIFERAY"."LAYOUT" 52.05 MB 124507 rows
imported "LIFERAY"."ASSETENTRY" 29.11 MB 198809 rows
imported "LIFERAY"."MBMESSAGE" 24.80 MB 126185 rows
imported "LIFERAY"."PORTALPREFERENCES" 4.091 MB 62202 rows
imported "LIFERAY"."USER\_" 17.32 MB 62214 rows
...
データベースのインポート例では、いくつかの項目が目立つ:
JOURNALARTICLE
テーブルはデータベースサイズの98%を占める。RESOURCEPERMISSION
の記録はたくさんある。- 多くの
PORTLETPREFERENCES
レコードがある。
目立つテーブルに関連付けられている未使用のオブジェクトを検索し、Liferay の API を使って(例えば、 スクリプトコンソール を使って)不要なオブジェクトを削除します。
チェックすべき一般的なオブジェクト・タイプ
いくつかの特定のオブジェクト・タイプは、未使用のオブジェクトがないかチェックする必要がある。 チェックする理由をいくつか挙げてみよう:
- これらのオブジェクトを削除すると、関連する未使用のオブジェクトが削除のために解放される。
- 持っておく価値のないバージョン物かもしれない
これらのオブジェクトタイプをチェックする:
-
**サイト不要なサイトを削除する。 サイトを削除すると、以下のような関連オブジェクトが削除されます:
- レイアウト
- ポートレットの環境設定
- ファイルエントリ(ドキュメントライブラリオブジェクト)
- アセットエントリー
- タグ
- 語彙とカテゴリー
- Expando フィールドとその値
ResourcePermission
オブジェクト- その他、その土地固有のものすべて
-
インスタンス :インスタンス**:未使用のインスタンスが存在することは稀であるが、インスタンスは 階層で最も高いオブジェクトであるため、そのオブジェクトを削除することで、 アップグレードを大幅に最適化することができる。 インスタンスを削除すると、それらに関連するこれらのオブジェクトが削除される:
- サイト(および関連するすべてのコンテンツ)
- ユーザー
- ロール
- 組織
- グローバル
ResourcePermission
オブジェクト
-
Web コンテンツの中間バージョン: Liferay DXP は、変更(翻訳を含む)後に新しい Web コンテンツのバージョンを生成します。 不要なバージョンは削除することを検討しよう。 特に、削除されたバージョンに固有の画像ファイルなどのオブジェクトがある場合は、かなりのスペースが空く可能性があります。 詳細は、 例:ジャーナル記事の中間バージョンの削除 を参照してください。
-
文書バージョン :ジャーナル記事と同様、中間文書バージョンが不要な場合は削除してください。 これにより、データベースとファイルシステムの両方のスペースを節約できる。
-
レイアウト: レイアウトはサイトページであり、ポートレット環境設定、権限、アセット、評価などの他のエンティティに関連するため、アップグレードのパフォーマンスに影響します。 不要なレイアウトを削除する。
-
ロール :不要なロールは削除してください。 これらを削除すると、 関連の
ResourceBlockPermission
とResourcePermission
オブジェクトも削除される。 -
ユーザー: アクティブでなく、不要になったユーザーを削除します。
-
語彙 :使用されていない語彙を削除します。 語彙を削除すると、そのカテゴリーも削除されることに注意。
-
孤児データ :何も接続されていない未使用のオブジェクトをチェックする。 次にいくつかの例を示します。
DLFileEntries
にファイルシステムのデータがない。- もはや存在しないロール、レイアウト、ユーザー、ポートレットインスタンスなどに関連付けられた
ResourcePermission
オブジェクト。 - もはや存在しないポートレットやレイアウトに関連付けられた
PortletPreference
オブジェクト。 これは、多くの組み込みポートレットがある環境では一般的です。 これらのポートレットインスタンスには異なるライフサイクルがあり、ポートレットがテンプレートから削除されても削除されません。
中間オブジェクトバージョンの削除例については、 例:ジャーナル記事の中間バージョンの削除 を参照してください。
ステージングされた変更を公開し、ステージングをオフにする
ローカル/リモートステージングが有効で、ステージングされたサイトにコンテンツやデータが保存されている場合、 をライブサイトに公開します。 このステップをスキップすると、アップグレード後に完全なパブリッシュを実行する(または手動で変更をパブリッシュする)必要があります。 最終的なパブリッシュを終えたら、アップグレードの前にステージングをオフにしてください。
次に、刈り込まれたデータベースでインスタンスをテストする。
プルーニングされたデータベースのコピーを使用してテストする
削除したオブジェクトに関連する問題を見つけ、解決する。 これは、オブジェクトが誤って削除された場合や、他のコンテンツに影響する場合に備えて、重要なステップです。 問題を解決できない場合は、いつでも本番データベースの新しいコピーのプルーニングを再開することができます。