oo
Analytics Cloud
Commerce
DXP / Portal
Liferay Cloud
Reference
安定性とパフォーマンスのアップグレード

データベース・プルーニングによるアップグレードの高速化

データが多ければ多いほど、データのアップグレードには時間がかかります。 不要なサイトデータはよくあることだ。 データベースから不要なデータを削除することで、アップグレード処理のパフォーマンスが向上します。

例えば、サイトはウェブコンテンツの記事やドキュメント、メディアファイルの多くの未使用バージョンを保存することができる。 改訂が終わり、中間の改訂が必要なければ、安全に削除することができる。 これはスペースとアップグレード時間の節約になる。

データベースの剪定に関するトピックを紹介しよう：

  • 重複するWeb コンテンツストラクチャーのフィールド名を削除する
  • 未使用オブジェクトの検索と削除
  • プルーニングされたデータベースのコピーを使用してテストする

廃止されたデータの削除

データベースに、廃止されたデータや廃止された機能から残ったデータが含まれている可能性があります。 どちらも簡単に削除できます。

データクリーンナップツール7.3以上使用可能。 データ削除ツールあり 7.4+

  1. 廃止されたモジュールのデータを削除するには、 データクリーンアップ ツールを使用します。

  2. 使用可能なモジュールから古いデータを削除するには、 データ削除 ツールを使用します。

重複する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の以前のバックアップにロールバックし、重複するフィールド名を見つけて削除してください。

未使用のオブジェクトの削除

データベースには、使用されていないオブジェクトのデータが残っている場合があります。

  1. UI やデータベースで SELECT クエリを使用することで、未使用のオブジェクトを特定し、UI や スクリプトコンソール を通した API、または作成したポートレットからオブジェクトを削除します。
warning

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 オブジェクトも削除される。

  • ユーザー： アクティブでなく、不要になったユーザーを削除します。

warning

ユーザー管理ツール は、ユーザー生成コンテンツの匿名化や削除を支援します。 しかし、あなたのサイトに影響を与える可能性のあるいくつかの依存関係は、削除後も存続する可能性があります。 例えば、サイトページを作成したユーザーを削除すると、サイトエラーが発生する可能性があります。 これらのエラーを修正するためには、既存のユーザーによってサイト・コンテンツを再作成する必要があるかもしれません。 ユーザーの匿名化 は、ユーザー削除の代替オプションである。

  • 語彙 ：使用されていない語彙を削除します。 語彙を削除すると、そのカテゴリーも削除されることに注意。

  • 孤児データ ：何も接続されていない未使用のオブジェクトをチェックする。 次にいくつかの例を示します。

    • DLFileEntriesにファイルシステムのデータがない。
    • もはや存在しないロール、レイアウト、ユーザー、ポートレットインスタンスなどに関連付けられた ResourcePermission オブジェクト。
    • もはや存在しないポートレットやレイアウトに関連付けられた PortletPreference オブジェクト。 これは、多くの組み込みポートレットがある環境では一般的です。 これらのポートレットインスタンスには異なるライフサイクルがあり、ポートレットがテンプレートから削除されても削除されません。

中間オブジェクトバージョンの削除例については、 例：ジャーナル記事の中間バージョンの削除 を参照してください。

ステージングされた変更を公開し、ステージングをオフにする

ローカル/リモートステージングが有効で、ステージングされたサイトにコンテンツやデータが保存されている場合、 をライブサイトに公開します。 このステップをスキップすると、アップグレード後に完全なパブリッシュを実行する（または手動で変更をパブリッシュする）必要があります。 最終的なパブリッシュを終えたら、アップグレードの前にステージングをオフにしてください。

次に、刈り込まれたデータベースでインスタンスをテストする。

プルーニングされたデータベースのコピーを使用してテストする

削除したオブジェクトに関連する問題を見つけ、解決する。 これは、オブジェクトが誤って削除された場合や、他のコンテンツに影響する場合に備えて、重要なステップです。 問題を解決できない場合は、いつでも本番データベースの新しいコピーのプルーニングを再開することができます。

関連トピック