クエリとインデックスに関するベストプラクティス

AEM 6 での Oak への移行に伴い、クエリとインデックスの管理方法に関して大きな変更がいくつか導入されました。Jackrabbit 2 では、デフォルトですべてのコンテンツのインデックスが作成され、自由にクエリできました。Oak では、oak:index ノードの下にインデックスを手動で作成する必要があります。クエリはインデックスなしでも実行できますが、大規模なデータセットの場合は、実行が非常に遅くなるだけでなく、中止されることもあります。

この記事では、インデックスを作成するべき場合とインデックスが不要な場合、クエリが不要な場合にクエリの使用を回避するためのヒント、インデックスとクエリの機能をできる限り最適化するためのヒントを概説します。

さらに、クエリとインデックスの作成に関する Oak のドキュメントをお読みください。AEM 6 における新しい概念であるインデックスに加えて、Oak クエリの構文も大きく異なります。以前の AEM インストールからコードを移行する際にはこの違いを考慮する必要があります。

クエリを使用する場面

リポジトリと分類のデザイン

リポジトリの分類を設計する際は、いくつかの要因を考慮する必要があります。 これには、アクセス制御、ローカライゼーション、コンポーネント、ページプロパティの継承などが含まれます。

こうした事柄に対応する分類を設計する一方で、インデックス設計の「トラバーサビリティ」についても検討することも重要です。このコンテキストでのトラバーサビリティとは、分類の機能で、パスに基づいてコンテンツに予測可能にアクセスできるようにします。 これにより、多数のクエリを実行する必要のあるシステムよりもメンテナンスが容易な、よりパフォーマンスの高いシステムが実現します。

さらに分類を設計する際は、順序が重要かどうか検討することが重要です。明確な順序が不要な場合および多数の兄弟ノードが予想される場合は、sling:Folder や oak:Unstructured などの順序がないノードタイプを使用することを推奨します。順序付けが必要な場合は、nt:unstructured および sling:OrderedFolder の方が適切です。

コンポーネント内のクエリ

AEMシステムで実行されるクエリは、より負担のかかる操作の 1 つになる可能性があるので、コンポーネント内でクエリを使用しないことをお勧めします。 ページがレンダリングされるたびに複数のクエリを実行すると、システムのパフォーマンスが低下する場合があります。 コンポーネントのレンダリング時にクエリを実行しないようにするには、次の 2 つの方法があります。 ノードの走査 および 結果を取得中.

ノードの走査

必要なデータの場所を事前に把握できるようにリポジトリを設計している場合は、必要なパスからこのデータを取得するコードをデプロイできます。クエリを実行しなくても、データを検索できます。

例えば、特定のカテゴリに適合するコンテンツのレンダリングがおこなわれます。 1 つの方法は、コンテンツをカテゴリプロパティで整理し、クエリを実行して、カテゴリ内の項目を表示するコンポーネントに入力できるようにすることです。

より優れたアプローチは、このコンテンツを手動で取得できるように、カテゴリ別の分類に構造化することです。

例えば、コンテンツが次のような分類に格納されている場合、

/content/myUnstructuredContent/parentCategory/childCategory/contentPiece

/content/myUnstructuredContent/parentCategory/childCategory ノードは簡単に取得でき、その子ノードを解析してコンポーネントのレンダリングに使用できます。

また、小さな結果セットや同種の結果セットを扱う場合は、同じ結果セットを返すクエリを作成するよりも、リポジトリを経由して必要なノードを収集する方が速くなります。 一般的な考慮事項として、クエリは可能な場所で避ける必要があります。

結果のプリフェッチ

コンポーネントのコンテンツや要件によっては、必要なデータを取得する方法としてノードトラバーサルを使用できない場合があります。 この場合、エンドユーザーに対して最適なパフォーマンスを確保するために、コンポーネントがレンダリングされる前に、必要なクエリを実行する必要があります。

コンポーネントに必要な結果が、作成時に計算でき、コンテンツが変更される予測がない場合は、作成者がダイアログで設定を適用する際にクエリを実行できます。

データやコンテンツが定期的に変更される場合は、クエリをスケジュールに従って実行するか、リスナーを使用して基になるデータの更新を実行できます。 その後、結果をリポジトリ内の共有場所に書き込むことができます。 このデータを必要とするコンポーネントは、実行時にクエリを実行しなくても、この 1 つのノードから値を取り出すことが可能です。

クエリの最適化

インデックスを使用していないクエリを実行すると、ノードトラバーサルに関する警告が記録されます。 このクエリが頻繁に実行されるクエリの場合は、インデックスを作成する必要があります。 特定のクエリが使用しているインデックスを確認するには、クエリの説明を実行ツールを推奨します。さらに情報を得るために、関連する検索 API の DEBUG ログを有効にすることもできます。

メモ

インデックス定義を変更した後、インデックスを再構築（再インデックス）する必要があります。 インデックスのサイズによっては、完了に時間がかかる場合があります。

複雑なクエリを実行する場合、クエリを複数の小さなクエリに分類し、後でコードを介してデータを結合する方がパフォーマンスが向上する場合があります。 これらのケースでは、2 つの方法のパフォーマンスを比較し、問題の使用例に対してどのオプションが適しているかを判断することをお勧めします。

AEMでは、次の 3 つの方法のいずれかでクエリを記述できます。

  • QueryBuilder API を使用（推奨）
  • XPath の使用（推奨）
  • SQL2 の使用

実行前にすべてのクエリが SQL2 に変換されますが、クエリ変換のオーバーヘッドは最小限なので、クエリ言語を選択する際の最も懸念されるのは、開発チームが読みやすさと快適さのレベルです。

メモ

QueryBuilder を使用する場合、デフォルトで結果数が決定されます。Oak では、以前のバージョンの Jackrabbit に比べて遅くなります。 これを補うには、 guessTotal パラメーター.

クエリの説明を実行ツール

どのクエリ言語でも、クエリ最適化の最初の手順は、クエリの実行方法を把握することです。これをおこなうには、操作ダッシュボードにあるクエリの説明を実行ツールを使用します。このツールを使用すると、クエリにプラグインして説明を取得できます。クエリが大きなリポジトリと実行時間、および使用されるインデックスで問題を引き起こす場合は、警告が表示されます。 また、処理に時間のかかる一般的なクエリのリストを読み込み、その後、説明や最適化をおこなうこともできます。

クエリの DEBUG ログ

Oak が使用するインデックスを選択する方法、およびクエリエンジンが実際にクエリを実行する方法に関する追加情報を取得するには、 デバッグ ログ設定は、次のパッケージに対して追加できます。

  • org.apache.jackrabbit.oak.plugins.index
  • org.apache.jackrabbit.oak.query
  • com.day.cq.search

クエリのデバッグが完了したら、このロガーを必ず削除してください。大量のアクティビティが出力され、最終的にはログファイルでディスクがいっぱいになる可能性があります。

この方法について詳しくは、 ログドキュメント.

インデックス統計

Lucene は、各インデックスに存在するドキュメントのサイズや数など、インデックスで指定されたコンテンツの詳細を提供する JMX Bean を登録します。

これを確認するには、JMX コンソール（https://server:port/system/console/jmx）にアクセスしてください。

JMX コンソールにログインしたら、 Lucene インデックス統計 それを見つけるために 他のインデックス統計は、 IndexStats MBean。

クエリ統計の場合は、 Oak クエリ統計.

のようなツールを使用してインデックスを掘り下げたい場合は、 ルカを使用する場合、Oak コンソールを使用して、 NodeStore をファイルシステムディレクトリに追加します。 この方法については、 Lucene ドキュメント.

また、システム内のインデックスを JSON 形式で抽出することもできます。 このためには、https://server:port/oak:index.tidy.-1.json にアクセスする必要があります。

クエリ制限

開発中

oak.queryLimitInMemory の低しきい値（例：10000）と Oak を設定します。queryLimitReads（例：UnsupportedOperationException にヒットして「The query read more than x nodes…」と表示されたときに高負荷のクエリを最適化します。

これにより、リソースを大量に消費するクエリ ( インデックスをベースとしない、または、インデックスをカバーしないことによってバックアップされない )。 例えば、100 万個のノードを読み取るクエリは、I/O の増加につながり、アプリケーション全体のパフォーマンスに悪影響を与えます。 上記の制限により失敗したクエリは、分析し、最適化する必要があります。

デプロイメント後

  • ログを監視して、大規模なノードの走査やヒープメモリの大量使用を引き起こしているクエリがないかどうかを調べます。

    • *WARN* ... java.lang.UnsupportedOperationException: The query read or traversed more than 100000 nodes. To avoid affecting other tasks, processing was stopped.
    • クエリを最適化してトラバースされたノードの数を減らします

  • 大量のヒープメモリ消費をトリガーするクエリについて、ログを監視します。

    • *WARN* ... java.lang.UnsupportedOperationException: The query read more than 500000 nodes in memory. To avoid running out of memory, processing was stopped
    • クエリを最適化して、ヒープメモリの使用量を減らします。

AEM 6.0 ～ 6.2 では、AEM 起動スクリプトの JVM パラメーターを使用してノードのトラバーサルのしきい値を調整し、大きなクエリによる環境への過負荷を防ぐことができます。

推奨される値は次のとおりです。

  • -Doak.queryLimitInMemory=500000
  • -Doak.queryLimitReads=100000

AEM 6.3 では、この 2 つのパラメーターは標準で事前に設定されており、OSGi QueryEngineSettings で保持することができます。

詳しくは、https://jackrabbit.apache.org/oak/docs/query/query-engine.html#Slow_Queries_and_Read_Limitsを参照してください。

効率的なインデックス作成のヒント

インデックスを作成する必要がありますか？

インデックスを作成または最適化する際に最初に尋ねる質問は、特定の状況に対して実際に必要かどうかです。 バッチ処理を通じて、問題のクエリを 1 回だけ、または時々のみ、システムのオフピーク時に実行する場合は、インデックスをまったく作成しない方が良い可能性があります。

インデックスを作成すると、そのインデックスが付けられたデータを更新するたびに、インデックスも更新する必要が生じます。この処理はシステムのパフォーマンスに影響するので、インデックスは実際に必要な場合にのみ作成する必要があります。

また、インデックスは、インデックス内に含まれるデータが十分に一意である場合にのみ役立ちます。 本のインデックスと、本が取り上げるトピックを考えてみましょう。 テキスト内の一連のトピックにインデックスを作成する場合、通常は数百から数千のエントリが存在します。これにより、ページのサブセットにすばやくジャンプして、探している情報をすばやく見つけることができます。 そのインデックスに 2、3 個のエントリしかなく、それぞれが数百ページを指す場合、インデックスは非常に役に立ちません。 この同じ概念は、データベースインデックスにも当てはまります。 一意の値がいくつかしか存在しない場合は、インデックスはあまり役立ちません。しかし、インデックスは大きすぎても不便です。インデックス統計を見るには、 インデックス統計 上

Lucene とプロパティインデックス

Lucene インデックスは Oak 1.0.9 で導入され、AEM 6 の初回起動時に導入されたプロパティインデックスに対して、強力な最適化を提供します。 Lucene インデックスとプロパティインデックスのどちらを使用するかを決定する際は、次の点を考慮してください。

  • Lucene インデックスは、プロパティインデックスよりも多くの機能を提供します。 例えば、プロパティインデックスは 1 つのプロパティにのみインデックスを作成でき、Lucene インデックスは多数を含めることができます。 Lucene インデックスで使用可能なすべての機能の詳細については、 ドキュメント.
  • Lucene インデックスは非同期です。 これにより、パフォーマンスが大幅に向上しますが、リポジトリにデータが書き込まれるときとインデックスが更新されるときの間に遅延が生じる場合もあります。 クエリが 100%の正確な結果を返すことが重要な場合は、プロパティインデックスが必要です。
  • Lucene インデックスは、非同期式という特性上、一意性制約を適用できません。この制約が必要な場合は、プロパティインデックスを使用する必要があります。

一般に、より高いパフォーマンスと柔軟性のメリットを得るためにプロパティインデックスを使用する必要性が強い場合を除き、Lucene インデックスを使用することをお勧めします。

Solr インデックス作成

AEMでは、Solr のインデックス作成もデフォルトでサポートされています。 これは主に全文検索をサポートするために利用されますが、任意の種類の JCR クエリをサポートするためにも使用できます。 AEMインスタンスに、検索に負荷がかかるデプロイメント（多数の同時ユーザーを持つ検索主導型 Web サイトなど）で必要なクエリの数を処理する CPU 処理能力がない場合は、Solr を考慮する必要があります。 または、Solr をクローラーベースのアプローチで実装して、プラットフォームのより高度な機能の一部を活用することもできます。

Solr インデックスは、AEMサーバー上で開発環境用に埋め込んで実行するように設定することも、リモートインスタンスにオフロードして、実稼動環境とステージング環境での検索のスケーラビリティを向上させることもできます。 検索のオフロードによりスケーラビリティが向上しますが、遅延が生じるので、必要な場合を除きお勧めしません。 Solr 統合の設定方法と Solr インデックスの作成方法について詳しくは、 Oak クエリとインデックス作成に関するドキュメント.

メモ

統合型の Solr 検索アプローチを採用すると、インデックス作成を Solr サーバーにオフロードできます。クローラベースのアプローチで Solr サーバーの高度な機能を使用する場合は、追加の設定作業が必要です。

このアプローチの欠点は、デフォルトではAEMクエリが ACL に従うので、ユーザーがアクセスできない結果は非表示になり、Solr サーバーに対する検索を外部化してもこの機能はサポートされないということです。 この方法で検索を外部化する場合は、ユーザーに表示されない結果が表示されないように、十分に注意する必要があります。

この方法が適切な場合があると考えられる使用例としては、複数のソースからの検索データを集計する必要が生じる場合があります。 例えば、AEM上でホストされているサイトと、サードパーティのプラットフォーム上でホストされている 2 つ目のサイトがあるとします。 Solr は、両方のサイトのコンテンツをクロールし、それらを集計インデックスに格納するように設定できます。 これにより、クロスサイト検索が可能になります。

デザインに関する考慮事項

Lucene インデックスの Oak ドキュメントには、インデックスを設計する際に考慮すべきいくつかの事項が記載されています。

  • クエリで異なるパス制限を使用する場合は、evaluatePathRestrictions を使用します。これにより、クエリは指定されたパスの下の結果のサブセットを返し、クエリに基づいてフィルタリングできます。 それ以外の場合は、クエリはリポジトリ内のクエリパラメーターに一致するすべての結果を検索し、パスに基づいてフィルタリングします。

  • クエリで並べ替えを使用する場合は、並べ替えるプロパティの明示的なプロパティ定義を用意し、そのプロパティの ordered を true に設定します。これにより、結果をインデックス内と同じように並べ替え、クエリ実行時のコストの高い並べ替え操作を節約できます。

  • 必要なものだけをインデックスに入れます。 不要な機能やプロパティを追加すると、インデックスが増え、パフォーマンスが低下します。

  • プロパティインデックスでは、一意のプロパティ名を使用すると、インデックスのサイズを削減できます。しかし Lucene インデックスでは、統一されたインデックスを実現するために、nodeTypes と mixins を使用する必要があります。特定の nodeType または mixin をクエリすると、nt:base をクエリするよりもパフォーマンスが向上します。この方法を使用する場合は、当該の nodeTypes の indexRules を定義します。

  • クエリが特定のパスでのみ実行されている場合は、それらのパスの下にインデックスを作成します。 インデックスをリポジトリのルートに配置する必要はありません。

  • インデックスを作成するすべてのプロパティが Lucene が可能な限り多くのプロパティ制限をネイティブに評価できるように関連している場合は、1 つのインデックスを使用することをお勧めします。 また、結合を実行する場合でも、クエリは 1 つのインデックスのみを使用します。

CopyOnRead

NodeStore がリモートに格納されている場合は、CopyOnRead というオプションを有効にできます。このオプションを指定すると、リモートインデックスが読み込まれる際にローカルファイルシステムに書き込まれます。 これは、これらのリモートインデックスに対して頻繁に実行されるクエリのパフォーマンスを向上させるのに役立ちます。

これは、OSGi コンソールの下の LuceneIndexProvider service およびは、Oak 1.0.13 以降でデフォルトで有効になっています。

インデックスの削除

インデックスを削除するときは、必ず type プロパティを disabled に設定して一時的にインデックスを無効にしたうえで、実際に削除する前にテストを実施し、アプリケーションが正しく動作するか確認することを推奨します。インデックスは無効の間は更新されないので、再度有効にした場合は正しいコンテンツが含まれず、再インデックスが必要になる場合があります。

TarMK インスタンスでプロパティインデックスを削除した後、使用中のディスク領域を再利用するには、コンパクションを実行する必要があります。 Lucene インデックスの場合、実際のインデックスコンテンツは BlobStore に存在するので、データストアのガベージコレクションが必要になります。

MongoDB インスタンスでインデックスを削除する場合、削除のコストはインデックス内のノード数に比例します。 大きなインデックスを削除すると問題が発生する可能性があるので、インデックスを無効にし、メンテナンスウィンドウでのみ削除する方法を推奨します。例えば、次のようなツールを使用します。 oak-mongo.js. データの不整合が生じる可能性があるので、この方法は通常のノードコンテンツには使用しないでください。

メモ

oak-mongo.js について詳しくは、Oak のドキュメントの Command Line Tools のセクションを参照してください。

JCR クエリチートシート

効率的な JCR クエリとインデックス定義を作成できるようにするため、開発時に JCR クエリチートシートをダウンロードして参照用として使用できます。これには QueryBuilder、XPath、SQL-2 のクエリの例が収録されていて、クエリのパフォーマンスの点で異なる動作をする複数のシナリオに対応できます。また、Oak インデックスの作成またはカスタマイズ方法に関する推奨事項も収録されています。このチートシートの内容は、AEM 6.5 および AEM as a Cloud Service に適用されます。

再インデックス

ここでは、Oak インデックスの再インデックスを実行する理由として許容できるもの​のみ​を概説します。

ここに記載している理由以外の場合は、Oak インデックスの再インデックスを開始しても動作が変わったり問題が解決したりすることは​なく、AEM に不必要に高い負荷がかかります。

以下の各表に記載されている理由に該当しない限り、Oak インデックスの再インデックスを実行しないでください。

メモ

以下の各表を参照して再インデックスが有効であるかどうかを判断する前に、必ず​次のことを確認してください。

  • クエリが正しいこと
  • クエリは、期待されるインデックスに解決されます ( クエリの説明を実行)
  • インデックス作成プロセスが完了しました

Oak インデックス設定の変更

Oak インデックスの再インデックスに対して許容されるエラーのない条件は、Oak インデックスの設定が変更された場合のみです。

再インデックスに着手する前には必ず、AEM の全体的なパフォーマンスに対する影響を適切に検討し、アクティビティが少ない期間やメンテナンスウィンドウ中に再インデックスを実行する必要があります。

以下の節では、発生する可能性がある問題と解決策について詳しく説明します。

プロパティインデックスの定義の変更

  • 適用対象：

  • 症状：

    • プロパティインデックスの定義の更新前に存在するノードが結果にありません

  • 確認方法：

    • 更新されたインデックス定義をデプロイする前に、見つからないノードが作成または変更されたかどうかを判断します。
    • 見つからないノードのjcr:createdまたはjcr:lastModifiedプロパティをインデックスの変更時間と照合して検証します。

  • 解決方法：

    • Lucene インデックスの再インデックスを実行します。

    • または、見つからないノードにタッチ（無害な書き込み操作を実行）します

      • 手動のタッチまたはカスタムコードが必要
      • 見つからないノードのセットが認識されている必要があります
      • ノードのプロパティを変更する必要があります

Lucene インデックスの定義の変更

  • 適用対象：

  • 症状：

    • Lucene インデックスに予期された結果が含まれていません
    • クエリ結果に、インデックス定義の予期される動作が反映されていません
    • クエリプランは、インデックス定義に基づいて期待される出力をレポートしません

  • 確認方法：

    • Lucene インデックス統計 JMX Mbean（LuceneIndex）のdiffStoredIndexDefinitionメソッドを使用して、インデックス定義が変更されているかどうかを検証します。

  • 解決方法：

    • 1.6 以前の Oak バージョン：

    • Oak バージョン 1.6 以降

      • 既存のコンテンツが変更の影響を受けない場合は、更新のみが必要です

        • [oak:queryIndexDefinition]@refresh=true を設定して、Lucene インデックスを更新します。

      • それ以外の場合は 再インデックス lucene 指数

        • 注意：新しいインデックス再作成がトリガーされるまで、最後に正常に再インデックス作成（または最初のインデックス作成）されたインデックス状態が使用されます

エラーと例外的な状況

次の表に、Oak インデックスのインデックスを再作成すると問題が解決する、受け入れ可能なエラーと例外的な状況を示します。

以下に示す条件に一致しないAEMで問題が発生した場合は、 not 問題が解決されないので、インデックスを再インデックスします。

以下の節では、発生する可能性がある問題と解決策について詳しく説明します。

Lucene インデックスのバイナリが見つからない

  • 適用対象：

  • 症状：

    • Lucene インデックスに予期された結果が含まれていません

  • 確認方法：

    • エラーログファイルには、Lucene インデックスのバイナリが見つからないという例外が含まれています

  • 解決方法：

    • リポジトリ走査チェックを実行します。例：

      http://localhost:4502/system/console/repositorycheck

      リポジトリの走査により（lucene ファイル以外の）他のバイナリが欠落していないか判断

    • Lucene インデックス以外のバイナリが見つからない場合は、バックアップから復元します。

    • それ以外の場合は、すべての Lucene インデックスの再インデックスを実行します。

    • 注意：

      この状態は、データストアの設定が間違っていることを示し、すべてのバイナリ（例：アセットバイナリ）が欠落する可能性があります。

      この場合は、正常であることがわかっている最新のリポジトリバージョンに復元し、見つからないすべてのバイナリを回復します。

Lucene インデックスのバイナリが破損している

  • 適用対象：

  • 症状：

    • Lucene インデックスに予期された結果が含まれていません

  • 確認方法：

    • AsyncIndexUpdate（5 秒ごと）が失敗し、次の例外がエラーログに記録されます。

      ...a Lucene index file is corrupt...

  • 解決方法：

    • Lucene インデックスのローカルコピーを削除します。

      1. AEMを停止
      2. crx-quickstart/repository/indexにある Lucene インデックスのローカルコピーを削除
      3. AEM を再起動します。

    • この手順を実行しても問題が解決せず、AsyncIndexUpdate 例外が引き続き発生する場合は、次の手順に従います。

      1. エラーがあるインデックスの再インデックスを実行します。
      2. さらに、アドビサポートチケットを送ります。

再インデックスを実行する方法

メモ

AEM 6.5 では、MongoMK または RDBMK リポジトリでの再インデックスに使用できる方法は oak-run.jar のみです。

プロパティインデックスの再インデックス

Lucene プロパティインデックスの再インデックス

  • 用途 再インデックスする oak-run.jar Lucene プロパティインデックス

  • Lucene プロパティインデックスで async-reindex プロパティを true に Lucene プロパティインデックス

    • [oak:queryIndexDefinition]@reindex-async=true
メモ

前の節では、 Apache Oak ドキュメント AEMのコンテキストで使用されます。

バイナリのテキスト事前抽出

テキストの事前抽出とは、分離されたプロセスを介してデータストアから直接バイナリからテキストを抽出および処理し、抽出したテキストを以降の Oak インデックスの再インデックスに直接公開するプロセスです。

  • Oak のテキスト事前抽出は、/oak:index/damAssetLucene など、デプロイされた Oak インデックスによるフルテキスト検索に適した抽出可能なテキストを含む大量のファイル（バイナリ）があるリポジトリで、Lucene インデックスの再インデックス／インデックス作成を実行する場合に推奨されます。このようなファイルの例としては、PDF、Word Doc、PPT、TXT などがあります。
  • テキストの事前抽出は、Lucene インデックスの再/インデックスと Oak プロパティインデックス以外のインデックスのみを利用します。これは、プロパティインデックスがバイナリからテキストを抽出しないからです。
  • テキストの事前抽出は、テキストの多いバイナリ (PDF、ドキュメント、TXT など ) の全文再インデックスを行う場合に、大きな悪影響を及ぼします。画像のリポジトリは抽出可能なテキストを含まないので、同じ効率を発揮しません。
  • テキスト事前抽出では、全文検索関連テキストの抽出をより効率的に実行し、消費効率の高い方法で Oak の再インデックス/インデックス作成プロセスに公開します。

テキストの事前抽出をいつ使用できますか？

のインデックス再作成 既存 バイナリ抽出が有効な lucene インデックス

  • 再インデックスでは、リポジトリ内の​すべての​候補コンテンツが処理されます。フルテキストを抽出する元のバイナリが多数ある場合や複雑である場合、フルテキスト抽出を実行するための計算の負担が増し、AEM に高い負荷がかかります。テキストの事前抽出では、テキスト抽出の「計算上コストのかかる作業」が、AEM Data Store に直接アクセスする独立したプロセスに移動し、AEMでのオーバーヘッドやリソースの競合を回避します。

のデプロイメントのサポート 新規 バイナリ抽出が有効なAEMへの lucene インデックス

  • （バイナリ抽出が有効な）新しいインデックスがAEMにデプロイされると、Oak は次回の非同期フルテキストインデックス実行時に、すべての候補コンテンツのインデックスを自動的に作成します。 上記のインデックスの再作成で説明したのと同じ理由で、AEMに過度の読み込みが発生する場合があります。

テキストの事前抽出を使用できない状況

テキストの事前抽出は、リポジトリに追加された新しいコンテンツには使用できません。また、使用する必要もありません。

新しいコンテンツがリポジトリに追加されると、非同期のフルテキストインデックス作成プロセス（デフォルトでは 5 秒ごと）に、インデックスが自然に増分的に作成されます。

AEMの通常の操作（Web UI を使用したアセットのアップロードや、プログラムによるアセットの取り込みなど）では、AEMは、新しいバイナリコンテンツのフルテキストインデックスを自動的かつ増分的に作成します。 データ量は増分的で比較的少ない（約 5 秒でリポジトリに保持できるデータ量）ので、AEMは、インデックス作成中に、システム全体のパフォーマンスに影響を与えることなく、バイナリから全文抽出を実行できます。

テキストの事前抽出を使用するための前提条件

  • フルテキストバイナリ抽出を実行する Lucene インデックスのインデックスを再作成するか、既存のコンテンツのフルテキストインデックスバイナリを使用する新しいインデックスをデプロイします

  • テキストを事前に抽出するコンテンツ（バイナリ）は、リポジトリ内に存在する必要があります

  • CSV ファイルを生成し、最終的なインデックス再作成を実行するためのメンテナンスウィンドウ

  • Oak バージョン：1.0.18 以降、1.2.3 以降

  • oak-run.jar バージョン 1.7.4 以降

  • AEM のインデックス作成インスタンスからアクセス可能な、抽出されたテキストを格納するファイルシステムフォルダー／共有

    • テキストの事前抽出 OSGi 設定には、抽出されたテキストファイルへのファイルシステムパスが必要なので、AEMインスタンス（ローカルドライブまたはファイル共有マウント）から直接アクセスできる必要があります

テキストの事前抽出の実行方法

メモ

以下で概説する oak-run.jar コマンドを列挙した完全なリストは、https://jackrabbit.apache.org/oak/docs/query/pre-extract-text.html を参照してください。

上の図と後述の手順は、Apache Oak のドキュメントに記載されているテキスト事前抽出の技術的な手順を解説および補足しています。

テキスト事前抽出のプロセスフロー

事前抽出する内容のリストの生成

この操作ではノードストアが走査され、システムに大きな負荷がかかる可能性があるので、手順 1（a ～ b）はメンテナンスウィンドウ中やあまり使用されていない時間に実行してください。

1a. oak-run.jar --generate を実行して、テキストを事前抽出するノードのリストを作成します。

1b. ノード (1a) の一覧を CSV ファイルとしてファイルシステムに保存する

--generate を実行するたびに、ノードストア全体が走査され（oak-run コマンドでパスを指定された通りに）、新しい CSV ファイルが作成されます。CSV ファイルは、テキスト事前抽出プロセス（手順 1 ～ 2）の個々の実行の際に再利用され​ません。

ファイルシステムに対するテキストの事前抽出

手順 2（a ～ c）は、AEM の通常の操作中に実行できます。この手順では、データストアのみとやり取りがおこなわれます。

2a. oak-run.jar --tika を実行して、（1b）で生成した CSV ファイルに列挙されているバイナリノードのテキストを事前抽出します。

2b. （2a）で開始されたプロセスが、CSV で定義されているバイナリノードにデータストアで直接アクセスし、テキストを抽出します。

2c.抽出されたテキストが、Oak の再インデックスプロセス（3a）で取り込み可能な形式でファイルシステムに格納されます。

事前抽出されたテキストは、CSV 内でバイナリのフィンガープリントによって識別されます。バイナリファイルが同じである場合は、AEMインスタンス間で同じ事前抽出テキストを使用できます。 AEM Publish は通常 AEM Author のサブセットなので、AEM Author から事前に抽出したテキストも、AEM Publish のインデックスを再作成する場合に使用できます（AEM Publish が抽出したテキストファイルへのファイルシステムアクセス権を持っている場合）。

事前抽出されたテキストは、時間の経過と共にに増分的に追加できます。 テキストの事前抽出では、以前に抽出したバイナリの抽出がスキップされるので、将来再インデックスが必要になる場合（抽出したコンテンツが大きくないと仮定）は、事前抽出したテキストを保持することをお勧めします。 過度に大きい場合は、テキストが十分に圧縮される zip 形式で内容を暫定的に圧縮することを検討してください）。

Oak インデックスの再インデックス、抽出されたテキストファイルからフルテキストを取得

この操作ではノードストアが走査され、システムに大きな負荷がかかる可能性があるので、手順 1（3a ～ b）はメンテナンスウィンドウ中やあまり使用されていない時間に実行してください。

3a. 再インデックス AEMで呼び出される Lucene インデックスの

3b. Apache Jackrabbit Oak DataStore PreExtractedTextProvider の OSGi 設定（抽出されたテキストをファイルシステムパスで指定します）では、Oak は、抽出されたファイルからフルテキストを取得するよう指示されており、リポジトリに格納されているデータに Oak が直接アクセスして処理することを回避します。

このページ