クエリとインデックスに関するベストプラクティス best-practices-for-queries-and-indexing
AEM 6 での Oak への移行に伴い、クエリとインデックスの管理方法に関して大きな変更がいくつか導入されました。Jackrabbit 2 では、デフォルトですべてのコンテンツのインデックスが作成され、自由にクエリできました。Oak では、oak:index ノードの下にインデックスを手動で作成する必要があります。クエリはインデックスなしでも実行できますが、大規模なデータセットの場合は、実行が非常に遅くなるだけでなく、中止されることもあります。
この記事では、インデックスを作成するべき場合とインデックスが不要な場合、クエリが不要な場合にクエリの使用を回避するためのヒント、インデックスとクエリの機能をできる限り最適化するためのヒントを概説します。
さらに、クエリとインデックスの作成に関する Oak のドキュメントをお読みください。AEM 6 における新しい概念であるインデックスに加えて、Oak クエリの構文も大きく異なります。以前の AEM インストールからコードを移行する際にはこの違いを考慮する必要があります。
クエリを使用する場面 when-to-use-queries
リポジトリと分類のデザイン repository-and-taxonomy-design
リポジトリの分類を設計する際は、いくつかの要因を考慮する必要があります。 これには、アクセス制御、ローカライゼーション、コンポーネント、ページプロパティの継承などが含まれます。
こうした事柄に対応する分類を設計する一方で、インデックス設計の「トラバーサビリティ」についても検討することも重要です。このコンテキストでのトラバーサビリティとは、分類の機能で、パスに基づいてコンテンツに予測可能にアクセスできるようにします。 これにより、多数のクエリを実行する必要のあるシステムよりもメンテナンスが容易な、よりパフォーマンスの高いシステムが実現します。
さらに分類を設計する際は、順序が重要かどうか検討することが重要です。明確な順序が不要な場合および多数の兄弟ノードが予想される場合は、sling:Folder や oak:Unstructured などの順序がないノードタイプを使用することを推奨します。順序付けが必要な場合は、nt:unstructured および sling:OrderedFolder の方が適切です。
コンポーネント内のクエリ queries-in-components
AEMシステムで実行されるクエリは、より負担のかかる操作の 1 つになる可能性があるので、コンポーネント内でクエリを使用しないことをお勧めします。 ページがレンダリングされるたびに複数のクエリを実行すると、システムのパフォーマンスが低下する場合があります。 コンポーネントのレンダリング時にクエリを実行しないようにするには、次の 2 つの方法があります。 ノードの走査 および 結果を取得中.
ノードの走査 traversing-nodes
必要なデータの場所を事前に把握できるようにリポジトリを設計している場合は、必要なパスからこのデータを取得するコードをデプロイできます。クエリを実行しなくても、データを検索できます。
例えば、特定のカテゴリに適合するコンテンツのレンダリングがおこなわれます。 1 つの方法は、コンテンツをカテゴリプロパティで整理し、クエリを実行して、カテゴリ内の項目を表示するコンポーネントに入力できるようにすることです。
より優れたアプローチは、このコンテンツを手動で取得できるように、カテゴリ別の分類に構造化することです。
例えば、コンテンツが次のような分類に格納されている場合、
/content/myUnstructuredContent/parentCategory/childCategory/contentPiece
/content/myUnstructuredContent/parentCategory/childCategory ノードは簡単に取得でき、その子ノードを解析してコンポーネントのレンダリングに使用できます。
また、小さな結果セットや同種の結果セットを扱う場合は、同じ結果セットを返すクエリを作成するよりも、リポジトリを経由して必要なノードを収集する方が速くなります。 一般的な考慮事項として、クエリは可能な場所で避ける必要があります。
結果のプリフェッチ prefetching-results
コンポーネントのコンテンツや要件によっては、必要なデータを取得する方法としてノードトラバーサルを使用できない場合があります。 この場合、エンドユーザーに対して最適なパフォーマンスを確保するために、コンポーネントがレンダリングされる前に、必要なクエリを実行する必要があります。
コンポーネントに必要な結果が、作成時に計算でき、コンテンツが変更される予測がない場合は、作成者がダイアログで設定を適用する際にクエリを実行できます。
データやコンテンツが定期的に変更される場合は、クエリをスケジュールに従って実行するか、リスナーを使用して基になるデータの更新を実行できます。 その後、結果をリポジトリ内の共有場所に書き込むことができます。 このデータを必要とするコンポーネントは、実行時にクエリを実行しなくても、この 1 つのノードから値を取り出すことが可能です。
クエリの最適化 query-optimization
インデックスを使用していないクエリを実行すると、ノードトラバーサルに関する警告が記録されます。 このクエリが頻繁に実行されるクエリの場合は、インデックスを作成する必要があります。 特定のクエリが使用しているインデックスを確認するには、クエリの説明を実行ツールを推奨します。さらに情報を得るために、関連する検索 API の DEBUG ログを有効にすることもできます。
複雑なクエリを実行する場合、クエリを複数の小さなクエリに分類し、後でコードを介してデータを結合する方がパフォーマンスが向上する場合があります。 これらのケースでは、2 つの方法のパフォーマンスを比較し、問題の使用例に対してどのオプションが適しているかを判断することをお勧めします。
AEMでは、次の 3 つの方法のいずれかでクエリを記述できます。
- QueryBuilder API を使用（推奨）
- XPath の使用（推奨）
- SQL2 の使用
実行前にすべてのクエリが SQL2 に変換されますが、クエリ変換のオーバーヘッドは最小限なので、クエリ言語を選択する際の最も懸念されるのは、開発チームが読みやすさと快適さのレベルです。
クエリの説明を実行ツール the-explain-query-tool
どのクエリ言語でも、クエリ最適化の最初の手順は、クエリの実行方法を把握することです。これをおこなうには、操作ダッシュボードにあるクエリの説明を実行ツールを使用します。このツールを使用すると、クエリにプラグインして説明を取得できます。クエリが大きなリポジトリと実行時間、および使用されるインデックスで問題を引き起こす場合は、警告が表示されます。 また、処理に時間のかかる一般的なクエリのリストを読み込み、その後、説明や最適化をおこなうこともできます。
クエリの DEBUG ログ debug-logging-for-queries
Oak が使用するインデックスを選択する方法、およびクエリエンジンが実際にクエリを実行する方法に関する追加情報を取得するには、 デバッグ ログ設定は、次のパッケージに対して追加できます。
- org.apache.jackrabbit.oak.plugins.index
- org.apache.jackrabbit.oak.query
- com.day.cq.search
クエリのデバッグが完了したら、このロガーを必ず削除してください。大量のアクティビティが出力され、最終的にはログファイルでディスクがいっぱいになる可能性があります。
この方法について詳しくは、 ログドキュメント.
インデックスの統計 index-statistics
Lucene は、各インデックスに存在するドキュメントのサイズや数など、インデックスで指定されたコンテンツの詳細を提供する JMX Bean を登録します。
これを確認するには、JMX コンソール（https://server:port/system/console/jmx）にアクセスしてください。
JMX コンソールにログインしたら、 Lucene インデックス統計 それを見つけるために 他のインデックス統計は、 IndexStats MBean。
クエリ統計の場合は、 Oak クエリ統計.
Luke などのツールを使用してインデックスを詳しく調べる場合は、Oak コンソールを使用して NodeStore のインデックスをファイルシステムディレクトリにダンプする必要があります。この方法については、 Lucene ドキュメント.
また、システム内のインデックスを JSON 形式で抽出することもできます。 このためには、https://server:port/oak:index.tidy.-1.json にアクセスする必要があります。
クエリ制限 query-limits
開発中
の低しきい値を設定 oak.queryLimitInMemory ( 例： 10000）と Oak を設定します。queryLimitReads（例：5000) で、UnsupportedOperationException を押したときに、「The query read more than x nodes…」というメッセージが表示され、高価なクエリを最適化します。
これにより、リソースを大量に消費するクエリ ( インデックスをベースとしない、または、インデックスをカバーしないことによってバックアップされない )。 例えば、100 万個のノードを読み取るクエリは、I/O の増加につながり、アプリケーション全体のパフォーマンスに悪影響を与えます。 上記の制限により失敗したクエリは、分析し、最適化する必要があります。
デプロイメント後 post-deployment
-
ログを監視して、大規模なノードの走査やヒープメモリの大量使用を引き起こしているクエリがないかどうかを調べます。
*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を参照してください。
効率的なインデックス作成のヒント tips-for-creating-efficient-indexes
インデックスを作成する必要がありますか？ should-i-create-an-index
インデックスを作成または最適化する際に最初に尋ねる質問は、特定の状況に対して実際に必要かどうかです。 バッチ処理を通じて、問題のクエリを 1 回だけ、または時々のみ、システムのオフピーク時に実行する場合は、インデックスをまったく作成しない方が良い可能性があります。
インデックスを作成すると、そのインデックスが付けられたデータを更新するたびに、インデックスも更新する必要が生じます。この処理はシステムのパフォーマンスに影響するので、インデックスは実際に必要な場合にのみ作成する必要があります。
また、インデックスは、インデックス内に含まれるデータが十分に一意である場合にのみ役立ちます。 本のインデックスと、本が取り上げるトピックを考えてみましょう。 テキスト内の一連のトピックにインデックスを作成する場合、通常は数百から数千のエントリが存在します。これにより、ページのサブセットにすばやくジャンプして、探している情報をすばやく見つけることができます。 そのインデックスに 2、3 個のエントリしかなく、それぞれが数百ページを指す場合、インデックスは非常に役に立ちません。 この同じ概念は、データベースインデックスにも当てはまります。 一意の値がいくつかしか存在しない場合は、インデックスはあまり役立ちません。しかし、インデックスは大きすぎても不便です。インデックス統計を見るには、 インデックス統計 上
Lucene とプロパティインデックス lucene-or-property-indexes
Lucene インデックスは Oak 1.0.9 で導入され、AEM 6 の初回起動時に導入されたプロパティインデックスに対して、強力な最適化を提供します。 Lucene インデックスとプロパティインデックスのどちらを使用するかを決定する際は、次の点を考慮してください。
- Lucene インデックスは、プロパティインデックスよりも多くの機能を提供します。 例えば、プロパティインデックスは 1 つのプロパティにのみインデックスを作成でき、Lucene インデックスは多数を含めることができます。 Lucene インデックスで使用可能なすべての機能の詳細については、 ドキュメント.
- Lucene インデックスは非同期です。 これにより、パフォーマンスが大幅に向上しますが、リポジトリにデータが書き込まれるときとインデックスが更新されるときの間に遅延が生じる場合もあります。 クエリが 100%の正確な結果を返すことが重要な場合は、プロパティインデックスが必要です。
- Lucene インデックスは、非同期式という特性上、一意性制約を適用できません。この制約が必要な場合は、プロパティインデックスを使用する必要があります。
一般に、より高いパフォーマンスと柔軟性のメリットを得るためにプロパティインデックスを使用する必要性が強い場合を除き、Lucene インデックスを使用することをお勧めします。
Solr インデックス作成 solr-indexing
AEMでは、Solr のインデックス作成もデフォルトでサポートされています。 これは主に全文検索をサポートするために利用されますが、任意の種類の JCR クエリをサポートするためにも使用できます。 AEMインスタンスに、検索に負荷がかかるデプロイメント（多数の同時ユーザーを持つ検索主導型 Web サイトなど）で必要なクエリの数を処理する CPU 処理能力がない場合は、Solr を考慮する必要があります。 または、Solr をクローラーベースのアプローチで実装して、プラットフォームのより高度な機能の一部を活用することもできます。
Solr インデックスは、AEMサーバー上で開発環境用に埋め込んで実行するように設定することも、リモートインスタンスにオフロードして、実稼動環境とステージング環境での検索のスケーラビリティを向上させることもできます。 検索のオフロードによりスケーラビリティが向上しますが、遅延が生じるので、必要な場合を除きお勧めしません。 Solr 統合の設定方法と Solr インデックスの作成方法について詳しくは、 Oak クエリとインデックス作成に関するドキュメント.
このアプローチの欠点は、デフォルトではAEMクエリが ACL に従うので、ユーザーがアクセスできない結果は非表示になり、Solr サーバーに対する検索を外部化してもこの機能はサポートされないということです。 この方法で検索を外部化する場合は、ユーザーに表示されない結果が表示されないように、十分に注意する必要があります。
この方法が適切な場合があると考えられる使用例としては、複数のソースからの検索データを集計する必要が生じる場合があります。 例えば、AEM上でホストされているサイトと、サードパーティのプラットフォーム上でホストされている 2 つ目のサイトがあるとします。 Solr は、両方のサイトのコンテンツをクロールし、それらを集計インデックスに格納するように設定できます。 これにより、クロスサイト検索が可能になります。
デザインに関する考慮事項 design-considerations
Lucene インデックスの Oak ドキュメントには、インデックスを設計する際に考慮すべきいくつかの事項が記載されています。
-
クエリで異なるパス制限を使用する場合は、
evaluatePathRestrictionsを使用します。これにより、クエリは指定されたパスの下の結果のサブセットを返し、クエリに基づいてフィルタリングできます。 それ以外の場合は、クエリはリポジトリ内のクエリパラメーターに一致するすべての結果を検索し、パスに基づいてフィルタリングします。 -
クエリで並べ替えを使用する場合は、並べ替えるプロパティの明示的なプロパティ定義を用意し、そのプロパティの
orderedをtrueに設定します。これにより、結果をインデックス内と同じように並べ替え、クエリ実行時のコストの高い並べ替え操作を節約できます。 -
必要なものだけをインデックスに入れます。 不要な機能やプロパティを追加すると、インデックスが増え、パフォーマンスが低下します。
-
プロパティインデックスでは、一意のプロパティ名を使用すると、インデックスのサイズを削減できます。しかし Lucene インデックスでは、統一されたインデックスを実現するために、
nodeTypesとmixinsを使用する必要があります。特定のnodeTypeまたはmixinをクエリすると、nt:baseをクエリするよりもパフォーマンスが向上します。この方法を使用する場合は、当該のnodeTypesのindexRulesを定義します。 -
クエリが特定のパスでのみ実行されている場合は、それらのパスの下にインデックスを作成します。 インデックスをリポジトリのルートに配置する必要はありません。
-
インデックスを作成するすべてのプロパティが Lucene が可能な限り多くのプロパティ制限をネイティブに評価できるように関連している場合は、1 つのインデックスを使用することをお勧めします。 また、結合を実行する場合でも、クエリは 1 つのインデックスのみを使用します。
CopyOnRead copyonread
NodeStore がリモートに格納されている場合は、CopyOnRead というオプションを有効にできます。このオプションを指定すると、リモートインデックスが読み込まれる際にローカルファイルシステムに書き込まれます。 これは、これらのリモートインデックスに対して頻繁に実行されるクエリのパフォーマンスを向上させるのに役立ちます。
これは、OSGi コンソールの下の LuceneIndexProvider service およびは、Oak 1.0.13 以降でデフォルトで有効になっています。
インデックスの削除 removing-indexes
インデックスを削除するときは、必ず type プロパティを disabled に設定して一時的にインデックスを無効にしたうえで、実際に削除する前にテストを実施し、アプリケーションが正しく動作するか確認することを推奨します。インデックスは無効の間は更新されないので、再度有効にした場合は正しいコンテンツが含まれず、再インデックスが必要になる場合があります。
TarMK インスタンスでプロパティインデックスを削除した後、使用中のディスク領域を再利用するには、コンパクションを実行する必要があります。 Lucene インデックスの場合、実際のインデックスコンテンツは BlobStore に存在するので、データストアのガベージコレクションが必要になります。
MongoDB インスタンスでインデックスを削除する場合、削除のコストはインデックス内のノード数に比例します。 大きなインデックスを削除すると問題が発生する可能性があるので、インデックスを無効にし、メンテナンスウィンドウでのみ削除する方法を推奨します。例えば、次のようなツールを使用します。 oak-mongo.js. データの不整合が生じる可能性があるので、この方法は通常のノードコンテンツには使用しないでください。
再インデックス re-indexing
ここでは、Oak インデックスの再インデックスを実行する理由として許容できるもの のみ を概説します。
以下に説明する理由の外で、Oak インデックスの再インデックスを開始すると、 not 動作を変更したり、問題を解決したりして、AEMの負荷を不必要に増やします。
以下の各表に記載されている理由に該当しない限り、Oak インデックスの再インデックスを実行しないでください。
- クエリが正しいこと
- クエリは、期待されるインデックスに解決されます ( クエリの説明を実行)
- インデックス作成プロセスが完了しました
Oak インデックス設定の変更 oak-index-configuration-changes
Oak インデックスの再インデックスに対して許容されるエラーのない条件は、Oak インデックスの設定が変更された場合のみです。
再インデックスに着手する前には必ず、AEM の全体的なパフォーマンスに対する影響を適切に検討し、アクティビティが少ない期間やメンテナンスウィンドウ中に再インデックスを実行する必要があります。
以下の節では、発生する可能性がある問題と解決策について詳しく説明します。
プロパティインデックスの定義の変更 property-index-definition-change
-
適用対象：
- すべての Oak バージョン
- のみ プロパティインデックス
-
症状：
- プロパティインデックスの定義の更新前に存在するノードが結果にありません
-
確認方法：
- 更新されたインデックス定義をデプロイする前に、見つからないノードが作成または変更されたかどうかを判断します。
- 見つからないノードの
jcr:createdまたはjcr:lastModifiedプロパティをインデックスの変更時間と照合して検証します。
-
解決方法：
-
Lucene インデックスの再インデックスを実行します。
-
または、見つからないノードにタッチ（無害な書き込み操作を実行）します
- 手動のタッチまたはカスタムコードが必要
- 見つからないノードのセットが認識されている必要があります
- ノードのプロパティを変更する必要があります
-
Lucene インデックスの定義の変更 lucene-index-definition-change
-
適用対象：
- すべての Oak バージョン
- Lucene インデックスのみ
-
症状：
- Lucene インデックスに予期された結果が含まれていません
- クエリ結果に、インデックス定義の予期される動作が反映されていません
- クエリプランは、インデックス定義に基づいて期待される出力をレポートしません
-
確認方法：
- Lucene インデックス統計 JMX Mbean（LuceneIndex）の
diffStoredIndexDefinitionメソッドを使用して、インデックス定義が変更されているかどうかを検証します。
- Lucene インデックス統計 JMX Mbean（LuceneIndex）の
-
解決方法：
エラーと例外的な状況 erring-and-exceptional-situations
次の表に、Oak インデックスのインデックスを再作成すると問題が解決する、受け入れ可能なエラーと例外的な状況を示します。
以下に示す条件に一致しないAEMで問題が発生した場合は、 not 問題が解決されないので、インデックスを再インデックスします。
以下の節では、発生する可能性がある問題と解決策について詳しく説明します。
Lucene インデックスのバイナリが見つからない lucene-index-binary-is-missing
-
適用対象：
- すべての Oak バージョン
- Lucene インデックスのみ
-
症状：
- Lucene インデックスに予期された結果が含まれていません
-
確認方法：
- エラーログファイルには、Lucene インデックスのバイナリが見つからないという例外が含まれています
-
解決方法：
-
リポジトリ走査チェックを実行します。例：
http://localhost:4502/system/console/repositorycheck
リポジトリの走査により（lucene ファイル以外の）他のバイナリが欠落していないか判断
-
Lucene インデックス以外のバイナリが見つからない場合は、バックアップから復元します。
-
それ以外の場合は、すべての Lucene インデックスの再インデックスを実行します。
-
注意：
この状態は、データストアの設定が間違っていることを示し、すべてのバイナリ（例：アセットバイナリ）が欠落する可能性があります。
この場合は、正常であることがわかっている最新のリポジトリバージョンに復元し、見つからないすべてのバイナリを回復します。
-
Lucene インデックスのバイナリが破損している lucene-index-binary-is-corrupt
-
適用対象：
- すべての Oak バージョン
- Lucene インデックスのみ
-
症状：
- Lucene インデックスに予期された結果が含まれていません
-
確認方法：
-
AsyncIndexUpdate（5 秒ごと）が失敗し、次の例外がエラーログに記録されます。...a Lucene index file is corrupt...
-
-
解決方法：
再インデックスを実行する方法 how-to-re-index
プロパティインデックスの再インデックス re-indexing-property-indexes
-
用途 oak-run.jar プロパティインデックスを再インデックスするには
-
プロパティインデックスで async-reindex プロパティを true に設定します。
[oak:queryIndexDefinition]@reindex-async=true
-
PropertyIndexAsyncReindex MBean から web コンソールを使用してプロパティインデックスを非同期で再インデックス化します。
例：
Lucene プロパティインデックスの再インデックス re-indexing-lucene-property-indexes
-
用途 再インデックスする oak-run.jar Lucene プロパティインデックス
-
Lucene プロパティインデックスで async-reindex プロパティを true に Lucene プロパティインデックス
[oak:queryIndexDefinition]@reindex-async=true
バイナリのテキスト事前抽出 text-pre-extraction-of-binaries
テキストの事前抽出とは、分離されたプロセスを介してデータストアから直接バイナリからテキストを抽出および処理し、抽出したテキストを以降の Oak インデックスの再インデックスに直接公開するプロセスです。
- Oak のテキスト事前抽出は、
/oak:index/damAssetLuceneなど、デプロイされた Oak インデックスによるフルテキスト検索に適した抽出可能なテキストを含む大量のファイル（バイナリ）があるリポジトリで、Lucene インデックスの再インデックス／インデックス作成を実行する場合に推奨されます。このようなファイルの例としては、PDF、Word Doc、PPT、TXT などがあります。 - テキストの事前抽出は、Lucene インデックスの再/インデックスと Oak プロパティインデックス以外のインデックスのみを利用します。これは、プロパティインデックスがバイナリからテキストを抽出しないからです。
- テキストの事前抽出は、テキストの多いバイナリ (PDF、ドキュメント、TXT など ) の全文再インデックスを行う場合に、大きな悪影響を及ぼします。画像のリポジトリは抽出可能なテキストを含まないので、同じ効率を発揮しません。
- テキスト事前抽出では、全文検索関連テキストの抽出をより効率的に実行し、消費効率の高い方法で Oak の再インデックス/インデックス作成プロセスに公開します。
テキストの事前抽出をいつ使用できますか？ when-can-text-pre-extraction-be-used
のインデックス再作成 既存 バイナリ抽出が有効な lucene インデックス
- インデックス再作成処理 すべて リポジトリ内の候補コンテンツフルテキストを抽出するバイナリが多数あるいは複雑な場合は、フルテキスト抽出を実行する際の計算負荷が高くなります。 テキストの事前抽出では、テキスト抽出の「計算上コストのかかる作業」が、AEM Data Store に直接アクセスする独立したプロセスに移動し、AEMでのオーバーヘッドやリソースの競合を回避します。
のデプロイメントのサポート 新規 バイナリ抽出が有効なAEMへの lucene インデックス
- （バイナリ抽出が有効な）新しいインデックスがAEMにデプロイされると、Oak は次回の非同期フルテキストインデックス実行時に、すべての候補コンテンツのインデックスを自動的に作成します。 上記のインデックスの再作成で説明したのと同じ理由で、AEMに過度の読み込みが発生する場合があります。
テキストの事前抽出を使用できない状況 when-can-text-pre-extraction-not-be-used
テキストの事前抽出は、リポジトリに追加された新しいコンテンツには使用できません。また、使用する必要もありません。
新しいコンテンツがリポジトリに追加されると、非同期のフルテキストインデックス作成プロセス（デフォルトでは 5 秒ごと）に、インデックスが自然に増分的に作成されます。
AEMの通常の操作（Web UI を使用したアセットのアップロードや、プログラムによるアセットの取り込みなど）では、AEMは、新しいバイナリコンテンツのフルテキストインデックスを自動的かつ増分的に作成します。 データ量は増分的で比較的少ない（約 5 秒でリポジトリに保持できるデータ量）ので、AEMは、インデックス作成中に、システム全体のパフォーマンスに影響を与えることなく、バイナリから全文抽出を実行できます。
テキストの事前抽出を使用するための前提条件 prerequisites-to-using-text-pre-extraction
-
フルテキストバイナリ抽出を実行する Lucene インデックスのインデックスを再作成するか、既存のコンテンツのフルテキストインデックスバイナリを使用する新しいインデックスをデプロイします
-
テキストを事前に抽出するコンテンツ（バイナリ）は、リポジトリ内に存在する必要があります
-
CSV ファイルを生成し、最終的なインデックス再作成を実行するためのメンテナンスウィンドウ
-
Oak バージョン：1.0.18 以降、1.2.3 以降
-
oak-run.jar バージョン 1.7.4 以降
-
AEM のインデックス作成インスタンスからアクセス可能な、抽出されたテキストを格納するファイルシステムフォルダー／共有
- テキストの事前抽出 OSGi 設定には、抽出されたテキストファイルへのファイルシステムパスが必要なので、AEMインスタンス（ローカルドライブまたはファイル共有マウント）から直接アクセスできる必要があります
テキストの事前抽出の実行方法 how-to-perform-text-pre-extraction
事前抽出する内容のリストの生成
この操作ではノードストアが走査され、システムに大きな負荷がかかる可能性があるので、手順 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 が直接アクセスして処理することを回避します。