DXP 7.2 FP8/SP3 および DXP 7.3+ でのマルチテナント Elasticsearch インデックス名のサポート: 検索チューニングとワークフローメトリックに関する重要な変更

環境

Liferay DXP 7.3および7.4
Liferay DXP 7.2 Service Pack 3+/Fix Pack 8+ (SP3+/FP8+)
エラスティックサーチ 6.x/7.x
Liferay Connector to Elasticsearch 7 v3.1.0 (DXP 7.2用)

この記事を読むべき人

既存の DXP 7.2 展開を管理する管理者、特に次の機能のいずれかが使用されている場合: 検索チューニング (結果ランキング、シノニムセット)、ワークフローメトリックおよび SP3+/FP8+ パッチレベルへの移行またはアップグレードを計画しているDXP7.3/7.4
SP3+/FP8+ または DXP 7.3/7.4 で新しい DXP 7.2 展開を設計するソリューションアーキテクト

紹介
マルチテナント DXP-Elasticsearch スタックとは何ですか?
DXP 7.0 および DXP 7.1 のマルチテナンシー
SP3/FP8 より前の DXP 7.2 のマルチテナンシー
DXP 7.2 SP3+/FP8+ および DXP 7.3 のマルチテナンシー
DXP 7.2 SP3/FP8 のアプリ駆動型インデックスの変更点
DXP 7.2 SP3+/FP8+ パッチレベルに移行する前に
質問 & トラブルシューティング
関連記事
関連チケット

紹介

DXP 検索フレームワークは、その 会社インデックス ( 仮想インスタンス用に作成されたインデックス) をプレフィックス付きで作成します。デフォルトのプレフィックスは liferay-であるため、通常、Elasticsearch で次のような名前のインデックスを見つけることができます。

liferay-0
liferay-20101

ここで 20101 データベース内の特定の Company の companyId です。 UI では「インスタンス ID」として表示され、仮想インスタンスを表します。

DXP 7.0 以降、システム設定の Elasticsearch 6/7 コネクタ構成の「インデックス名プレフィックス」(または .config ファイルを介して行う場合は indexNamePrefix ) プロパティを使用して、インデックス名プレフィックスをカスタマイズできます。

マルチテナントElasticsearchクラスターを構築してLiferay DXP展開を提供する予定がある場合、インデックス名プレフィックス構成は重要です。

マルチテナント DXP-Elasticsearch スタックとは何ですか?

単一の Elasticsearch クラスターが複数の DXP 展開のインデックスをホストする場合、DXP-Elasticsearch スタックは マルチテナント です。これらのデプロイメントは、異なる本番デプロイメントまたは同じデプロイメントの異なる環境である可能性があります。

次のシナリオを検討してください:
A.) 複数の仮想インスタンスを使用した 1 つの Liferay DXP 展開 (単一ノードまたはクラスター化)
B.) 複数の DXP 展開 (単一またはクラスター化)、それぞれに 1 つ以上の仮想インスタンスがある

どのアーキテクチャを使用していても、スタンドアロンの Elasticsearch が必要です。

B.) の場合、DXP 展開ごとに個別の Elasticsearch クラスターをセットアップできますが、単一の Elasticsearch クラスターを維持することを好む場合があります。複数のインスタンスの companyId が同じである場合、インデックスを区別し、異なる展開からのデータが混在しないようにする方法が必要です。

2 つの DXP 展開がある場合は、"インデックス名プレフィックス" Elasticsearch 6/7 コネクタ構成に一意の値を指定します。

パブリック DXP インスタンス: indexNamePrefix=liferay-dxp-public
プライベート DXP インスタンス: indexNamePrefix=liferay-dxp-private

ケース A) を考えてみましょう: Liferay DXP は、 companyId 展開内の各仮想インスタンスに対して一意であることを保証します。 B) の場合と同様に、TEST、UAT、または DEV 環境を、本番環境のデプロイを提供する同じ Elasticsearch クラスターに接続することをお勧めします (Liferay はこれを推奨しません)。本番データベースが複製され、これらの内部環境で使用される場合、 companyId は同じになります。インデックス名が一致するためにデータが混在するリスクがあり、これを回避したい。

解決策は、「インデックス名プレフィックス」構成を使用することです。

indexNamePrefix=prod-
indexNamePrefix=uat、
indexNamePrefix=test-、
indexNamePrefix=dev- など

DXP 7.0 および DXP 7.1 のマルチテナンシー

前述のように、これらのバージョンで行う必要があるのは、 indexNamePrefix プロパティを使用して、Elasticsearch 6/7 コネクタ構成で目的のプレフィックスを構成することだけです。

新しい展開の場合、インデックスは最初の起動時に指定されたプレフィックスで作成されます。既存の展開では、完全な再インデックスを実行して、インデックスを削除し、新しい名前で再作成する必要があります。

SP3/FP8 より前の DXP 7.2 のマルチテナンシー

DXP 7.2 では、開発者が Liferay DXP の検索 API を介して Elasticsearch でインデックスを作成できるように、新しい API を導入しました。

これを活用した最初の内部機能は、 Workflow Metrics (DXP 7.2 GA1 以降で利用可能) でした。その後、 Result Rankings および Synonym Sets もこれらの API に基づいて構築されました (DXP 7.2 SP1/FP2 以降で利用可能)。これは、デフォルトの仮想インスタンス (別名、会社) インデックスとは別に、複数のアプリケーション固有のインデックスが存在することを意味します。 (DXP 7.2 SP2/FP5 の既成のインデックスのリストについては、 DXP 7.2 SP2 およびそれ以前のパッチレベルの Elasticsearch で作成された既成のインデックスとは? を参照してください。)

これらのインデックスを アプリケーション主導またはアプリケーション提供のインデックスと呼びます。これらのインデックスは、会社のインデックスとは異なる方法で管理されます。完全な再インデックス時に削除および再作成されることはなく、異なる設定とマッピングのセットで動作します*。さらに、結果ランキングなどの機能は、検索インデックスをプライマリデータストレージとして利用します。ランキングエントリ用のデータベーステーブルはありません。

SP3/FP8 パッチレベルより前では、前述の "インデックス名プレフィックス" は、すぐに使用できるアプリ駆動型インデックスには適用されません。さらに、これらのインデックスの一部は「マルチカンパニー」です。つまり、複数の仮想インスタンスからのデータを保存し、ドキュメントは companyId または index フィールドを使用してデータを分離します。

*: アプリ駆動型インデックスの構成を許可する機能要求があります。

DXP 7.2 SP3+/FP8+ および DXP 7.3+ のマルチテナンシー

マルチテナント展開をサポートすることの重要性を理解しているため、検索およびワークフロー製品チームが協力して、DXP 7.2 SP3/FP8、7.3、および 7.4 に必要な変更を導入し、プレフィックスを適用し、会社ごとのアプリ駆動型インデックスを作成しました。 .

DXP 7.2 SP3/FP8 のアプリ駆動型インデックスの変更点

以下の表は、デフォルトの「インデックス名プレフィックス」構成が使用されているすべての展開に影響する変更の概要を示しています。

古いインデックス名 (SP2)	インデックス名 (SP3+/FP8+)	再インデックスが必要	メモ
`liferay-search-tuning-rankings`	`liferay-<companyId>-search-tuning-rankings`	いいえ	仮想インスタンスごとに個別の結果ランキングインデックスが作成されます。次回の起動時に、データが新しい企業ごとのインデックスに移行された後、古いインデックスは自動的に削除されます。
`liferay-search-tuning-synonyms-liferay-<companyId>` (SP2/FP5 時点)	`liferay-<companyId>-search-tuning-synonyms`	いいえ	古いインデックスと同様に、新しいインデックスは「ヘルパー」インデックスとして機能し、完全な再インデックス操作でシノニムセットを保持します。シノニムは主に、Elasticsearch の特定の仮想インスタンスインデックスのインデックス設定内に格納されます。シノニムセットが Search Tuning admin に表示されることを確認したら、古いインデックスを削除できます。
`workflow-metrics-*`	`liferay-<companyId>-workflow-metrics-*`	いいえ	各仮想インスタンスのワークフローメトリックインデックスタイプごとに個別のインデックスが作成されます。データを検証した後、古いインデックスを削除できます。

既存のデータを新しいインデックスに移行する方法に興味がある場合は、こちらをお読みください。 DXP 7.2 SP3+/FP8+ の Elasticsearch で作成されるすぐに使用できる検索インデックスは何ですか? を参照してください。 DXP 7.2 SP3/FP8 のアプリ駆動型インデックスの完全なリストについては、以下の質問 & トラブルシューティングを参照してください。

DXP 7.2 SP3+/FP8+ パッチレベルに移行する前に

前提条件 : DXP 7.2 SP3/FP8 では、Elasticsearch へのコネクタの新しいバージョンをインストールする必要があります 7 (v3.1.0).

SP3 / FP8より前のパッチレベルでLiferayDXP 7.2の上記の機能のいずれかを使用していた場合は、必要に応じて後で復元できるように、古いインデックスのスナップショットを作成することをお勧めします。 SP3 + / FP8 +パッチレベルに移行する前。 Kibana 7.x では、スナップショットと復元機能を使用できます。 Elastic Stack 6.x を使用している場合は、Elasticsearch 6.x の関連ドキュメントに従ってください。

質問 & トラブルシューティング

以下に、このトピックに関する詳細情報を提供するために、いくつかの質問と回答を集めました。

目次:

DXP 7.2 SP2 以前のパッチレベルの Elasticsearch で作成された、すぐに使用できるインデックスは何ですか?
影響を受けるインデックスと、DXP 7.2 SP3/FP8 に移行する前、または DXP 7.3 にアップグレードした後にそれらをバックアップするにはどうすればよいですか? それらを削除しても安全ですか?
DXP 7.2 SP3+/FP8+ および DXP 7.3 の Elasticsearch で作成された、すぐに使用できる検索インデックスは何ですか?
データは古いインデックスから新しいインデックスにどのように移行されますか?
古いパッチレベル (SP3/FP8 より前) に戻すことはできますか?
SP3/FP8 パッチレベルに移行した後、完全な再インデックスを実行する必要がありますか?
すべてのドキュメントが新しいインデックスに移行されたことを Elasticsearch で確認する方法は?
既存の展開でインデックス名のプレフィックス構成を変更する方法は?
カスタムコードとプロジェクトにどのような影響がありますか?
DXP 7.3 にはどのような影響がありますか?
DXP 7.1 および 7.0 に影響しますか?
これらの変更はホットフィックスで配信できますか?
それは Solr に影響しますか?

DXP 7.2 SP2 以前のパッチレベルの Elasticsearch で作成された、すぐに使用できるインデックスは何ですか?

仮想インスタンス (別名会社) が 1 つしかなく、デフォルトの indexNamePrefix Elasticsearch コネクタ構成を使用していると仮定すると、インデックス名は次のようになります。

liferay-0 // system index
liferay-<companyId> // company index
workflow-metrics-instances //app-driven index, multi-company
workflow-metrics-nodes //app-driven index, multi-company
workflow-metrics-processes //app-driven index, multi-company
workflow-metrics-sla-process-results //app-driven index, multi-company
workflow-metrics-sla-task-results //app-driven index, multi-company
workflow-metrics-tokens //app-driven index, multi-company
liferay-search-tuning-rankings //app-driven index, multi-company
liferay-search-tuning-synonyms-liferay-<companyId> // app-driven index, as of DXP 7.2 SP2/FP5 (LPS-100272)

影響を受けるインデックスと、DXP 7.2 SP3/FP8 に移行する前、または DXP 7.3 にアップグレードした後にそれらをバックアップするにはどうすればよいですか? それらを削除しても安全ですか?

DXP 7.2 SP3+/FP8+ パッチレベルを使用しているか、最近 DXP 7.3 にアップグレードし、以前のパッチレベルで Liferay DXP 7.2 を使用していた場合、次の古いインデックスが Elasticsearch に残ります。

liferay-search-tuning-synonyms-liferay-<companyId>
workflow-metrics-instances
workflow-metrics-nodes
workflow-metrics-processes
workflow-metrics-sla-process-results
workflow-metrics-sla-task-results
workflow-metrics-tokens

liferay-search-tuning-rankingsはどうですか? このインデックスは、データが新しい会社ごとのインデックスに移行された後、起動時に自動的に削除されます。

これらのインデックスのスナップショットを作成することをお勧めします 必要に応じて後で復元できるようにします。 Kibana 7.x では、スナップショットと復元機能を使用できます。 Elastic Stack 6.x を使用している場合は、Elasticsearch 6.x の関連ドキュメントに従ってください。

影響を受ける機能が適切に動作することを確認した後、Elasticsearch の _close および _delete REST API または Kibana の Index Management ツールを使用して、これらのインデックスを削除できます。

DXP 7.2 SP3+/FP8+ および DXP 7.3+ の Elasticsearch で作成された、すぐに使用できる検索インデックスは何ですか?

仮想インスタンス (別名会社) が 1 つしかなく、デフォルトの indexNamePrefix Elasticsearch コネクタ構成を使用している場合、インデックス名は次のようになります。

DXP 7.2 SP3+/FP8+

liferay-0
liferay-<companyId>
liferay-<companyId>-search-tuning-rankings
liferay-<companyId>-search-tuning-synonyms
liferay-<companyId>-workflow-metrics-instances
liferay-<companyId>-workflow-metrics-nodes
liferay-<companyId>-workflow-metrics-processes
liferay-<companyId>-workflow-metrics-sla-process-results
liferay-<companyId>-workflow-metrics-sla-task-results
liferay-<companyId>-workflow-metrics-tokens

DXP 7.3

liferay-0
liferay-<companyId>
liferay-<companyId>-search-tuning-rankings
liferay-<companyId>-search-tuning-synonyms
liferay-<companyId>-workflow-metrics-instances
liferay-<companyId>-workflow-metrics-nodes
liferay-<companyId>-workflow-metrics-processes
liferay-<companyId>-workflow-metrics-sla-instance-results
liferay-<companyId>-workflow-metrics-sla-task-results
liferay-<companyId>-workflow-metrics-tasks
liferay-<companyId>-workflow-metrics-transitions

データは古いインデックスから新しいインデックスにどのように移行されますか?

結果ランキング

起動時に登録される RankingIndexCreationBackgroundTaskExecutor という BackgroundTask (BT) コンポーネントがあります。 BT フレームワークは、使用可能なエグゼキュータスレッドが存在する場合にタスクを実行します。検索エンジンが Elasticsearch の場合、インポートは SingleIndexToMultipleIndexImporterImplによってトリガーおよび処理されます。インポートは 2 段階で行われます。最初に、仮想インスタンスごとに 1 つずつ、Elasticsearch に新しいインデックスを作成します (まだ存在しない場合)。次に、指定された仮想インスタンスのドキュメントを古いインデックス (liferay-search-tuning-rankings) からロードし、一括リクエストによってそれらを新しいインデックスにインデックス付けします。インポートプロセスの最後に、エラーがなければ古いインデックスを削除します。

同義語セット

SynonymSetIndexCreationPortalInstanceLifecycleListenerと呼ばれるPortalInstanceLifecycleListenerコンポーネントがあり、起動時に各仮想インスタンス（会社）に対して発生するportalInstanceRegisteredイベントをリッスンしています。まだ存在しない場合は、指定された仮想インスタンスの Elasticsearch に新しいインデックスを作成し、指定された仮想インスタンスインデックスのインデックス設定からシノニムセットを読み込みます。各セットはドキュメントとして新しいインデックスに追加されます。

Workflow Metrics
PortalInstanceLifecycleListener WorkflowMetricsPortalInstanceLifecycleListener というコンポーネントがあり、起動時に各仮想インスタンス (会社) に対して発生する portalInstanceRegistered イベントをリッスンします。まだ存在しない場合は、 BaseWorkflowMetricsIndexer および各ワークフローメトリックインデックスタイプの実際のインデクサーを介して、指定された仮想インスタンスの Elasticsearch に新しいインデックスを作成します。次に、これらのインデックスに対して再インデックスを実行し、データベースの対応するレコードに基づいてドキュメントを再作成します。

古いパッチレベル (SP3/FP8 より前) に戻すことはできますか?

一部: 「新しい」企業ごとのインデックスから結果ランキングの古い複数企業のインデックスにデータを移動するメカニズムはありません。シノニムとワークフローメトリックについては、完全な再インデックスが必要です。

古い結果ランキングインデックスのスナップショットを作成した場合は、それを復元して古いパッチレベルで Liferay DXP 7.2 を使用できますが、SP3+/FP8+ パッチレベルで作成した新しいランキングエントリはすべて失われることに注意してください。あなたのスナップショット。 UI を使用してそれらを再追加するか、Elasticsearch の Reindex API を使用して手動でインデックスドキュメントを作成する必要があります。

SP3/FP8 パッチレベルに移行した後、完全な再インデックスを実行する必要がありますか?

前述のように、これらの変更には完全な再インデックスは必要ありません。ただし、SP3/FP8 では、すべての検索インデックスの再作成を必要とする他の大きな変更が導入される可能性があります。詳細は SP3 のハイライトと FP8 の重要な変更を参照してください。

すべてのドキュメントが新しいインデックスに移行されたことを Elasticsearch で確認する方法は?

Elasticsearch の _search REST API を使用します。Kibana の curl または Dev Tools Console から呼び出して、古い「複数会社」インデックス (会社) から特定の仮想インスタンス (会社) に属するドキュメントの数を照会します (結果ランキングとワークフローメトリクスインデックスの場合)。

例を次に示します。

コントロールパネル - 構成 - 仮想インスタンスに移動します。
各インスタンスの companyId (UI では「インスタンス ID」と呼ばれます) を取得します。たとえば、ID 20101を持つものがあります。
Elasticsearch で次のクエリを実行します。

GET workflow-metrics-instances/_search
{
  "query": {
    "term": {
      "companyId": {
        "value": "20101"
      }
    }
  },
  "size": 0
}

(または curl リクエストとして:

curl -XGET "http://localhost:9200/workflow-metrics-instances/_search" -H 'Content-Type: application/json' -d'{  "query": {    "term": {      "companyId": {        "value": "20101"      }    }  },  "size": 0}'

結果は次のようになります。

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}

応答は、 workflow-metrics-instances インデックス内にこの会社のドキュメントが 2 あることを示しています。他の ワークフロー -* インデックスでも同じことができます。

Result Rankingsの場合、検索するフィールドの名前は index で、値は liferay-<companyId>です。たとえば、この例では liferay-20101 です。

GET liferay-search-tuning-rankings/_search
{
  "query": {
    "term": {
      "index": {
        "value": "liferay-20101"
      }
    }
  },
  "size": 0
}

古いドキュメントカウントが得られたので、結果ランキング (liferay-20101-search-tuning-rankings) とワークフローメトリック (liferay-20101-workflow-metrics-*) の新しい会社ごとのインデックスを照会できます。）同じ方法。ドキュメント数が一致する必要があります。

注: すでに SP2/FP5 パッチレベルを使用していた場合、シノニムセットは会社ごとのインデックスに既に格納されています。そのパッチレベルより前は、同義語のインデックスはありません。

既存の展開でインデックス名のプレフィックス構成を変更する方法は?

DXP をシャットダウンし、 .config ファイルを介してインデックス名のプレフィックスを編集します。
次回のポータルの起動後に完全な再インデックスを実行します。これにより、新しいプレフィックスでインデックスが作成され、システムインデックス、仮想インスタンスインデックス、およびワークフローメトリックインデックスが再インデックス化されます。 古いインデックスは削除されません。
既存のデータ (ドキュメント) を 結果ランキング および シノニム インデックスから新しいインデックスに手動で移行し、既存の各結果ランキングドキュメントの インデックス フィールドを更新して、対応するインデックス (新しい名前) を指すようにします。指定された仮想インスタンス ( "index": "liferay-20101"-> "index": "dxp-20101"など)。これらの追加の手順を行わないと、既存の類義語セットとランキングエントリが新しいインデックスから失われるため、検索クエリに適用されません。

データを移行し、結果ランキングの インデックス フィールドを更新するには、Elasticsearch の Reindex API を使用できます。 indexNamePrefix プロパティを liferay- から dxp- に変更すると、API 呼び出しは次のようになります。

POST _reindex/
{
  "dest": {
    "index": "dxp-20101-search-tuning-rankings"
  },
  "source": {
    "index": "liferay-20101-search-tuning-rankings"
  },
  "script": {
    "lang": "painless",
    "source": """
            ctx._source.index = 'dxp-20101';
          """
  }
}

以下の Elasticsearch からの応答の例は、新しいインデックスに 1 つのドキュメントが作成されたことを示しています。

{
  "took" : 13,
  "timed_out" : false,
  "total" : 1,
  "updated" : 0,
  "created" : 1,
  "deleted" : 0,
  "batches" : 1,
  "version_conflicts" : 0,
  "noops" : 0,
  "retries" : {
    "bulk" : 0,
    "search" : 0
  },
  "throttled_millis" : 0,
  "requests_per_second" : -1.0,
  "throttled_until_millis" : 0,
  "failures" : [ ]
}

シノニムについても同じことを行うには、 ソース および デスト インデックス名で ランキング シノニム に置き換え、 スクリプト ブロックを削除して、API 呼び出しを再度実行します。

LPS-117702: マルチテナント Elasticsearch インデックス名
LPS-117703: シノニムインデックス: 標準の命名パターンに従う
LPS-117704: 結果ランキングのインデックス: 標準の命名パターンに従います
LPS-117706: ポータル管理者として、Workflow Metrics で会社ごとにインデックスを作成したい 7.2
LPS-118286: ポータル管理者として、ワークフローメトリックスがマルチテナントインデックスの命名規則に従うようにしたい
LPS-101291: 結果ランキングのインデックスは、共有ではなく、仮想インスタンスごとにする必要があります
LPS-100272: 検索インデックスを再インデックスすると、すべてのシノニムセットが削除されます

ヘルプセンター

製品

リソース

セキュリティ

サポート

Tibor Lipusz

環境

この記事を読むべき人

紹介

マルチテナント DXP-Elasticsearch スタックとは何ですか?

DXP 7.0 および DXP 7.1 のマルチテナンシー

SP3/FP8 より前の DXP 7.2 のマルチテナンシー

DXP 7.2 SP3+/FP8+ および DXP 7.3+ のマルチテナンシー

DXP 7.2 SP3/FP8 のアプリ駆動型インデックスの変更点

DXP 7.2 SP3+/FP8+ パッチレベルに移行する前に

質問 & トラブルシューティング

DXP 7.2 SP2 以前のパッチレベルの Elasticsearch で作成された、すぐに使用できるインデックスは何ですか?

影響を受けるインデックスと、DXP 7.2 SP3/FP8 に移行する前、または DXP 7.3 にアップグレードした後にそれらをバックアップするにはどうすればよいですか? それらを削除しても安全ですか?

DXP 7.2 SP3+/FP8+ および DXP 7.3+ の Elasticsearch で作成された、すぐに使用できる検索インデックスは何ですか?

データは古いインデックスから新しいインデックスにどのように移行されますか?

古いパッチレベル (SP3/FP8 より前) に戻すことはできますか?

SP3/FP8 パッチレベルに移行した後、完全な再インデックスを実行する必要がありますか?

すべてのドキュメントが新しいインデックスに移行されたことを Elasticsearch で確認する方法は?

既存の展開でインデックス名のプレフィックス構成を変更する方法は?

カスタムコードとプロジェクトにどのような影響がありますか?

DXP 7.3+ にはどのような影響がありますか?

DXP 7.1 および 7.0 に影響しますか?

これらの変更はホットフィックスで配信できますか?

それは Solr に影響しますか?

DXP 7.2 FP8/SP3 および DXP 7.3+ でのマルチテナント Elasticsearch インデックス名のサポート: 検索チューニングとワークフロー メトリックに関する重要な変更

Tibor Lipusz

DXP 7.2 FP8/SP3 および DXP 7.3+ でのマルチテナント Elasticsearch インデックス名のサポート: 検索チューニングとワークフローメトリックに関する重要な変更