更新リクエストプロセッサ

Solr が受信したすべての更新リクエストは、更新リクエストプロセッサまたはURPと呼ばれるプラグインのチェーンを介して実行されます。

これは、たとえば、インデックス作成されるドキュメントにフィールドを追加したり、特定のフィールドの値を変更したり、受信ドキュメントが特定の基準を満たさない場合に更新を削除したりするのに役立ちます。実際、Solr の非常に多くの機能は更新プロセッサとして実装されているため、このようなプラグインがどのように機能し、どこで構成されているかを理解する必要があります。

URP の構造とライフサイクル

更新リクエストプロセッサは、1つ以上の更新プロセッサのチェーンの一部として作成されます。Solr は、不可欠な Solr 機能を有効にするいくつかの更新リクエストプロセッサで構成されるデフォルトの更新リクエストプロセッサチェーンを作成します。このデフォルトチェーンは、ユーザーが異なるカスタム更新リクエストプロセッサチェーンを構成して指定しない限り、すべての更新リクエストを処理するために使用されます。

更新リクエストプロセッサを説明する最も簡単な方法は、抽象クラスUpdateRequestProcessorの Javadocs を参照することです。すべての UpdateRequestProcessor には、UpdateRequestProcessorFactoryを拡張する対応するファクトリクラスが必要です。このファクトリクラスは、Solr がこのプラグインの新しいインスタンスを作成するために使用されます。このような設計には、2つの利点があります。

  1. 更新リクエストプロセッサは、1つのリクエストスレッドのみで使用され、リクエストが完了すると破棄されるため、スレッドセーフである必要はありません。

  2. ファクトリクラスは、構成パラメータを受け入れ、リクエスト間で必要な状態を維持できます。ファクトリクラスはスレッドセーフである必要があります。

すべての更新リクエストプロセッサチェーンは、Solr コアのロード中に構築され、コアがアンロードされるまでキャッシュされます。チェーンで指定された各 UpdateRequestProcessorFactory もインスタンス化され、solrconfig.xmlで指定された構成で初期化されます。

Solr が更新リクエストを受信すると、このリクエストに使用する更新チェーンが検索されます。チェーンで指定された各 UpdateRequestProcessor の新しいインスタンスが、対応するファクトリを使用して作成されます。更新リクエストは、対応するUpdateCommandオブジェクトに解析され、チェーンを介して実行されます。各 UpdateRequestProcessor インスタンスは、チェーン内の次のプラグインを呼び出す役割を担います。次のプロセッサを呼び出さずにチェーンをショートカットすることや、例外をスローしてそれ以上の処理を中止することさえできます。

単一の更新リクエストには、複数の新しいドキュメントや削除のバッチが含まれる可能性があり、そのため、UpdateRequestProcessor の対応する processXXX メソッドは、個々の更新ごとに複数回呼び出されます。ただし、単一のスレッドがこれらのメソッドをシリアルに呼び出すことが保証されています。

更新リクエストプロセッサーの設定

更新リクエストプロセッサーチェーンは、solrconfig.xml でチェーン全体を直接作成するか、solrconfig.xml で個々の更新プロセッサーを作成し、リクエストパラメータで全てのプロセッサーを指定することで実行時にチェーンを動的に作成することができます。

ただし、更新プロセッサーチェーンの設定方法を理解する前に、デフォルトの更新プロセッサーチェーンについて学ぶ必要があります。なぜなら、ほとんどのカスタムリクエストプロセッサーチェーンで必要となる重要な機能を提供しているからです。

デフォルトの更新リクエストプロセッサーチェーン

solrconfig.xml で更新プロセッサーチェーンが設定されていない場合、Solr は自動的にデフォルトの更新プロセッサーチェーンを作成し、全ての更新リクエストに使用します。このデフォルトの更新プロセッサーチェーンは、以下のプロセッサー（順番通り）で構成されています。

  1. LogUpdateProcessorFactory - このリクエスト中に処理されたコマンドを追跡し、ログに記録します。

  2. DistributedUpdateProcessorFactory - 更新リクエストを適切なノードに分散する役割を担います。例えば、リクエストを正しいシャードのリーダーにルーティングしたり、リーダーから各レプリカに更新を分散したりします。このプロセッサーは、SolrCloud モードでのみ有効になります。

  3. RunUpdateProcessorFactory - 内部 Solr API を使用して更新を実行します。

これらの各プロセッサーは必須の機能を実行するため、通常、カスタムチェーンにはこれらのプロセッサーが全て含まれます。RunUpdateProcessorFactory は通常、カスタムチェーンの最後の更新プロセッサーです。

カスタム更新リクエストプロセッサーチェーン

次の例は、solrconfig.xml 内でカスタムチェーンを設定する方法を示しています。

Example dedupe updateRequestProcessorChain
<updateRequestProcessorChain name="dedupe">
  <processor class="solr.processor.SignatureUpdateProcessorFactory">
    <bool name="enabled">true</bool>
    <str name="signatureField">id</str>
    <bool name="overwriteDupes">false</bool>
    <str name="fields">name,features,cat</str>
    <str name="signatureClass">solr.processor.Lookup3Signature</str>
  </processor>
  <processor class="solr.LogUpdateProcessorFactory" />
  <processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>

上記の例では、"dedupe" という名前の新しい更新プロセッサーチェーンが、チェーン内に SignatureUpdateProcessorFactory、LogUpdateProcessorFactory、および RunUpdateProcessorFactory を含めて作成されています。SignatureUpdateProcessorFactory は、"signatureField"、"overwriteDupes" など、異なるパラメータでさらに設定されています。このチェーンは、Solr が名前、機能、cat フィールドの値を使用して署名を計算し、それを "id" フィールドとして使用することにより、ドキュメントの重複排除を実行するように設定できる方法の例です。お気づきのように、このチェーンは DistributedUpdateProcessorFactory を指定していません。このプロセッサーは Solr が正しく動作するために不可欠であるため、Solr は RunUpdateProcessorFactory の直前に DistributedUpdateProcessorFactory を含まないチェーンに自動的に挿入します。

RunUpdateProcessorFactory

solrconfig.xml で定義する全てのチェーンの最後に RunUpdateProcessorFactory を追加することを忘れないでください。そうしないと、そのチェーンで処理された更新リクエストは、実際にインデックスされたデータに影響を与えません。

個々のプロセッサーをトップレベルプラグインとして設定する

更新リクエストプロセッサーは、solrconfig.xml のチェーンとは独立して設定することもできます。

updateProcessor Configuration
<updateProcessor class="solr.processor.SignatureUpdateProcessorFactory" name="signature">
  <bool name="enabled">true</bool>
  <str name="signatureField">id</str>
  <bool name="overwriteDupes">false</bool>
  <str name="fields">name,features,cat</str>
  <str name="signatureClass">solr.processor.Lookup3Signature</str>
</updateProcessor>
<updateProcessor class="solr.RemoveBlankFieldUpdateProcessorFactory" name="remove_blanks"/>

この場合、SignatureUpdateProcessorFactory のインスタンスが "signature" という名前で設定され、RemoveBlankFieldUpdateProcessorFactory が "remove_blanks" という名前で定義されます。上記が solrconfig.xml で指定されたら、次のように solrconfig.xml の更新リクエストプロセッサーチェーンでそれらを参照できます。

updateRequestProcessorChain Configuration
<updateProcessorChain name="custom" processor="remove_blanks,signature">
  <processor class="solr.RunUpdateProcessorFactory" />
</updateProcessorChain>

SolrCloud における更新プロセッサー

ユーザー管理のクラスターまたは単一ノードインストールでは、各更新はチェーン内の全ての更新プロセッサーを一度だけ通過します。ただし、SolrCloud では、更新リクエストプロセッサーの動作は特別な考慮が必要です。

SolrCloud の重要な機能は、リクエストのルーティングと分散です。更新リクエストの場合、このルーティングは DistributedUpdateRequestProcessor によって実装され、このプロセッサーはその重要な機能のために Solr によって特別なステータスを与えられています。

SolrCloud クラスターでは、DistributedUpdateProcessor より前 のチェーン内の全てのプロセッサーは、クライアントから更新を受信する最初のノードで実行されます。このノードがリーダーまたはレプリカとしてのステータスに関係なくです。次に、DistributedUpdateProcessor は、更新を更新のための適切なシャードリーダー（または、クエリによる削除やコミットなど、複数のドキュメントに影響を与える更新の場合は複数のリーダー）に転送します。シャードリーダーは、トランザクションログを使用して 部分ドキュメント更新 を適用し、更新を全てのシャードレプリカに転送します。リーダーと各レプリカは、DistributedUpdateProcessor 後 にリストされているチェーン内の全てのプロセッサーを実行します。

たとえば、上記のセクションで見た "dedupe" チェーンを考えてみましょう。ノードAがshard1のリーダーをホストし、ノードBがshard2のリーダーをホストし、ノードCがshard2のNRTタイプのレプリカをホストする3ノードのSolrCloudクラスターが存在すると仮定します。更新リクエストがノードAに送信され、ノードB（更新がshard2に属しているため）に転送され、ノードCのレプリカに更新を分散すると仮定します。各ノードで何が起こるかを見てみましょう。

  • ノードA: SignatureUpdateProcessor (署名を計算し、それを "id" フィールドに配置します) 、次に LogUpdateProcessor 、最後に DistributedUpdateProcessor を介して更新を実行します。このプロセッサーは、更新が実際にノードBに属していると判断し、ノードBに転送されます。更新はそれ以上処理されません。これは、次のプロセッサーである RunUpdateProcessor がローカルの shard1 インデックスに対して更新を実行し、shard1 と shard2 でデータが重複するのを防ぐために必要です。

  • ノードB: 更新を受信し、別のノードから転送されたことを認識します。更新は、ノードAで既に SignatureUpdateProcessor を通過しており、同じ署名計算を再度行うことは冗長になるため、直接 DistributedUpdateProcessor に送信されます。DistributedUpdateProcessor は、更新が確かにこのノードに属していると判断し、ノードC上のレプリカに分散してから、チェーン内の RunUpdateProcessor にさらに更新を転送します。

  • ノードC: 更新を受信し、リーダーによって分散されたことを認識します。更新は直接 DistributedUpdateProcessor に送信されます。DistributedUpdateProcessor は、いくつかの整合性チェックを実行し、チェーン内の RunUpdateProcessor に更新をさらに転送します。

要約

  1. DistributedUpdateProcessor より前の全てのプロセッサーは、更新リクエストを受信する最初のノードでのみ実行されます。転送ノード（上記の例のノードAなど）であるか、リーダー（上記の例のノードBなど）であるかに関係なくです。これらを「プリプロセッサー」または単に「プロセッサー」と呼びます。

  2. DistributedUpdateProcessor より後の全てのプロセッサーは、リーダーノードとレプリカノードでのみ実行されます。転送ノードでは実行されません。このようなプロセッサーは「ポストプロセッサー」と呼ばれます。

前のセクションでは、updateRequestProcessorChain が processor="remove_blanks, signature" で設定されていることを確認しました。これは、このようなプロセッサーが #1 の種類であり、転送ノードでのみ実行されることを意味します。同様に、属性 "post-processor" を指定することで、#2 の種類として構成することもできます。

post-processor Configuration
<updateProcessorChain name="custom" processor="signature" post-processor="remove_blanks">
  <processor class="solr.RunUpdateProcessorFactory" />
</updateProcessorChain>

ただし、転送ノードでのみプロセッサーを実行することは、ロードバランサーを介してランダムにリクエストを送信することにより、SolrCloud クラスター全体で重複排除などのコストのかかる計算を分散する優れた方法です。そうしないと、コストのかかる計算がリーダーノードとレプリカノードの両方で繰り返されます。

カスタム更新チェーンのポストプロセッサーは、回復中のレプリカでは決して呼び出されない可能性があります

レプリカが 回復 中の場合、受信更新リクエストはトランザクションログにバッファリングされます。回復が正常に完了した後、バッファリングされた更新リクエストが再生されます。ただし、この記事の執筆時点では、カスタム更新チェーンのポストプロセッサーは、バッファリングされた更新リクエストに対しては決して呼び出されません。 SOLR-8030 を参照してください。SOLR-8030 が修正されるまでこの問題を回避するには、カスタム更新チェーンでポストプロセッサーを指定しないでください。

Atomic Update Processor Factory

AtomicUpdateProcessorFactory が DistributedUpdateProcessor より前の更新チェーンにある場合、チェーンへの入力ドキュメントは部分ドキュメントになります。

DistributedUpdateProcessor は、アトミック更新 をリーダーノード上の完全なドキュメントに処理する役割を担っているため、転送ノードでのみ実行されるプリプロセッサーは部分ドキュメントでのみ操作できることを意味します。完全なドキュメントを処理する必要があるプロセッサーがある場合は、ポストプロセッサーとして指定するしかありません。

カスタムチェーンの使用

update.chain リクエストパラメータ

update.chain パラメータは、solrconfig.xml で設定されたカスタムチェーンを選択するために、任意の更新リクエストで使用できます。たとえば、前のセクションで説明した "dedupe" チェーンを選択するには、次のリクエストを発行できます。

Using update.chain
curl "https://127.0.0.1:8983/solr/gettingstarted/update/json?update.chain=dedupe&commit=true" -H 'Content-type: application/json' -d '
[
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]
  },
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]
  }
]'

上記は、2つの同一のドキュメントを重複排除し、そのうちの1つのみをインデックス化する必要があります。

Processor & Post-Processor リクエストパラメータ

processor および post-processor リクエストパラメータを使用して、カスタム更新リクエストプロセッサーチェーンを動的に作成できます。複数のプロセッサーを、これら2つのパラメータのカンマ区切り値として指定できます。例えば

Executing processors configured in solrconfig.xml as (pre)-processors
curl "https://127.0.0.1:8983/solr/gettingstarted/update/json?processor=remove_blanks,signature&commit=true" -H 'Content-type: application/json' -d '
[
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]
  },
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]

  }
]'
Executing processors configured in solrconfig.xml as pre- and post-processors
curl "https://127.0.0.1:8983/solr/gettingstarted/update/json?processor=remove_blanks&post-processor=signature&commit=true" -H 'Content-type: application/json' -d '
[
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]
  },
  {
    "name" : "The Lightning Thief",
    "features" : "This is just a test",
    "cat" : ["book","hardcover"]
  }
]'

最初の例では、Solr は "signature" と "remove_blanks" を転送ノードでのみ実行されるプリプロセッサーとして持つチェーンを動的に作成します。一方、2番目の例では、"remove_blanks" がプリプロセッサーとして実行され、"signature" がポストプロセッサーとしてリーダーとレプリカで実行されます。

カスタムチェーンをデフォルトとして設定する

また、各リクエストのリクエストパラメータで名前を指定する代わりに、特定の更新ハンドラーに送信された全てのリクエストでデフォルトで使用されるカスタムチェーンを指定することもできます。

これは、InitParams を介して、または全てのリクエストハンドラーでサポートされている "defaults" セクション に追加することで、特定のパスのデフォルトパラメータとして "update.chain" または "processor" と "post-processor" のいずれかを追加することで実行できます。

以下は、スキーマレスモード で定義された initParam で、"/update/" で始まる全てのリクエストハンドラーにカスタム更新チェーンを適用します。

Example initParams
<initParams path="/update/**">
  <lst name="defaults">
    <str name="update.chain">add-unknown-fields-to-the-schema</str>
  </lst>
</initParams>

または、以下の例に示すように、"defaults" を使用して同様の効果を実現できます。

Example defaults
<requestHandler name="/update/extract" startup="lazy" class="solr.extraction.ExtractingRequestHandler" >
  <lst name="defaults">
    <str name="update.chain">add-unknown-fields-to-the-schema</str>
  </lst>
</requestHandler>

更新リクエストプロセッサーファクトリー

以下は、現在利用可能な更新リクエストプロセッサーの簡単な説明です。UpdateRequestProcessorFactory は、必要に応じて solrconfig.xml の更新チェーンに統合できます。これらのクラスの Javadoc を確認することを強くお勧めします。これらの説明は、大部分が Javadoc から抜粋した要約されたスニペットです。

一般的な使用方法の UpdateProcessorFactories

AddSchemaFieldsUpdateProcessorFactory

このプロセッサーは、入力ドキュメントにスキーマ内のフィールドまたは動的フィールドと一致しないフィールドが1つ以上含まれている場合、スキーマにフィールドを動的に追加します。

AtomicUpdateProcessorFactory

このプロセッサーは、従来のフィールド-値ドキュメントをアトミック更新ドキュメントに変換します。このプロセッサーは、(solrconfig.xml で定義することなく) ランタイムで使用できます。以下のセクション AtomicUpdateProcessorFactory を参照してください。

ClassificationUpdateProcessorFactory

このプロセッサーは、Luceneの分類モジュールを使用して、単純なドキュメント分類を提供します。このプロセッサーの使用方法の詳細については、https://cwiki.apache.org/confluence/display/solr/SolrClassificationを参照してください。

CloneFieldUpdateProcessorFactory

一致するsourceフィールドに見つかった値を、構成されたdestフィールドに複製します。

DefaultValueUpdateProcessorFactory

fieldNameに値がまだないドキュメントにデフォルト値を追加する単純なプロセッサーです。

DocBasedVersionConstraintsProcessorFactory

このファクトリは、構成されたversionFieldの名前を使用して、ドキュメントごとのバージョン番号に基づいてドキュメントのバージョン制約を強制するのに役立つUpdateProcessorを生成します。

DocExpirationUpdateProcessorFactory

ドキュメントの自動「有効期限」を管理するための更新プロセッサーファクトリ。

FieldNameMutatingUpdateProcessorFactory

構成されたpatternに一致するすべてのフィールド名を、構成されたreplacementで置き換えることによって変更します。

IgnoreCommitOptimizeUpdateProcessorFactory

SolrCloudモードで実行している場合に、クライアントアプリケーションからのコミットおよび/または最適化リクエストを無視できます。詳細については、「SolrCloudでのシャードとインデックスデータの作成」を参照してください。

IgnoreLargeDocumentProcessorFactory

limit（KB単位）を超えるサイズの大きなドキュメントがインデックスに登録されるのを防ぐことができます。これは、非常に大きなドキュメントが原因で、インデックス作成時だけでなくリカバリ時にも予期しない問題を回避するのに役立ちます。

デフォルトでは、このプロセッサーは、構成された制限を超えるドキュメントを検出した場合、更新リクエストを中止し、エラーをユーザーに返送します。違反するドキュメントより前に処理されたドキュメントはSolrによってインデックスが作成され、違反するドキュメントより後のドキュメントは処理されません。

または、プロセッサーは「許可」モード（permissiveMode=true）を提供します。これにより、違反するドキュメントをスキップし、警告をログに記録しますが、バッチの残りを中止したり、エラーをユーザーに返したりしません。

RegexpBoostProcessorFactory

「inputField」のコンテンツを「boostFilename」にある正規表現と照合し、一致した場合はファイルから対応するブースト値を返し、これを「boostField」にdouble値として出力するプロセッサーです。

SignatureUpdateProcessorFactory

ドキュメントのハッシュ「署名」を生成するために、定義されたフィールドのセットを使用します。「類似」ドキュメントのコピーを1つだけインデックス作成する場合に役立ちます。

ScriptUpdateProcessorFactory

スクリプトとして実装された更新プロセッサーの使用を可能にするプロセッサー。「スクリプト更新プロセッサー」セクションで詳細を確認してください。

TemplateUpdateProcessorFactory

テンプレートパターンに基づいて、ドキュメントに新しいフィールドを追加できます。この更新プロセッサーは、ランタイム（solrconfig.xmlで定義せずに）でも使用できます。以下の「TemplateUpdateProcessorFactory」セクションを参照してください。

TimestampUpdateProcessorFactory

指定されたフィールドに値がまだない場合、追加されるドキュメントに新しく生成された「NOW」の日付値を追加する更新プロセッサーです。

URLClassifyProcessorFactory

URLを調べて、長さ、パスレベルの数、トップレベルのURL（levels==0）、ランディング/インデックスページのように見えるかどうか、URLの正規表現（例：index.htmlの削除）、URLのドメインとパスの部分など、そのURLの特性を持つさまざまなフィールドに出力する更新プロセッサーです。

UUIDUpdateProcessorFactory

指定されたフィールドに値がまだない場合、追加されるドキュメントに新しく生成されたUUID値を追加する更新プロセッサーです。このプロセッサーは、ランタイム（solrconfig.xmlで定義せずに）でも使用できます。以下の「UUIDUpdateProcessorFactory」セクションを参照してください。

FieldMutatingUpdateProcessorFactory派生ファクトリ

これらのファクトリはすべて、インデックスが作成されるときにドキュメント内のフィールドを変更する機能を提供します。これらのファクトリを使用する場合は、変更されるフィールドの構成でサポートされている共通オプションの詳細について、FieldMutatingUpdateProcessorFactory javadocsを参照してください。

ConcatFieldUpdateProcessorFactory

構成可能な区切り文字を使用して、指定された条件に一致するフィールドの複数の値を連結します。

CountFieldValuesUpdateProcessorFactory

指定された条件に一致するフィールドの値のリストを、そのフィールドの値の数に置き換えます。

FieldLengthUpdateProcessorFactory

指定された条件に一致するフィールドに見つかったCharSequence値を、それらのCharSequenceの長さ（Integerとして）に置き換えます。

FirstFieldValueUpdateProcessorFactory

指定された条件に一致するフィールドの最初の値のみを保持します。

HTMLStripFieldUpdateProcessorFactory

指定された条件に一致するフィールドに見つかったCharSequence値内のすべてのHTMLマークアップを削除します。

IgnoreFieldUpdateProcessorFactory

インデックスに追加されるドキュメントから、指定された条件に一致するフィールドを無視して削除します。

LastFieldValueUpdateProcessorFactory

指定された条件に一致するフィールドの最後の値のみを保持します。

MaxFieldValueUpdateProcessorFactory

複数の値が見つかった場合に、選択したフィールドから最大値のみを保持する更新プロセッサーです。

MinFieldValueUpdateProcessorFactory

複数の値が見つかった場合に、選択したフィールドから最小値のみを保持する更新プロセッサーです。

ParseBooleanFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをBoolean値に変更しようとします。

ParseDateFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをDate値に変更しようとします。

ParseNumericFieldUpdateProcessorFactory派生クラス
ParseDoubleFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをDouble値に変更しようとします。

ParseFloatFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをFloat値に変更しようとします。

ParseIntFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをInteger値に変更しようとします。

ParseLongFieldUpdateProcessorFactory

CharSequence型の値のみを持つ選択したフィールドをLong値に変更しようとします。

PreAnalyzedUpdateProcessorFactory

構成されたフォーマットパーサーを使用して、追加されるドキュメントの構成済みフィールドをPreAnalyzedFieldを使用して解析する更新プロセッサーです。

RegexReplaceProcessorFactory

選択したフィールドに見つかったCharSequence値に構成された正規表現を適用し、一致するものを構成された置換文字列で置き換える更新されたプロセッサーです。

RemoveBlankFieldUpdateProcessorFactory

長さが0（つまり、空の文字列）のCharSequenceである値を検出した場合、削除します。

TrimFieldUpdateProcessorFactory

指定された条件に一致するフィールドに見つかったCharSequence値から、先頭と末尾の空白を削除します。

TruncateFieldUpdateProcessorFactory

指定された条件に一致するフィールドに見つかったCharSequence値を、最大文字長に切り捨てます。

UniqFieldsUpdateProcessorFactory

指定された条件に一致するフィールドに見つかった重複した値を削除します。

プラグインとしてロードできる更新プロセッサーファクトリ

これらのプロセッサーは、Solrリリースに「モジュール」として含まれており、ランタイムでロードされる追加のjarが必要です。詳細については、各モジュールに関連付けられたREADMEファイルを参照してください。

langidモジュールが提供します
LangDetectLanguageIdentifierUpdateProcessorFactory

http://code.google.com/p/language-detectionを使用して、入力フィールドのセットの言語を識別します。

TikaLanguageIdentifierUpdateProcessorFactory

TikaのLanguageIdentifierを使用して、入力フィールドのセットの言語を識別します。

analysis-extrasモジュールが提供します
OpenNLPExtractNamedEntitiesUpdateProcessorFactory

OpenNLP NERモデルを使用して抽出された名前付きエンティティを使用して、インデックスを作成するドキュメントを更新します。SolrCloudで1MBを超えるモデルファイルを使用するには、ZooKeeperサーバーとクライアントの両方を構成するか、コレクションレプリカをホストしている各ノードのファイルシステムにモデルファイルを格納する必要があることに注意してください。

変更または削除するべきではない更新プロセッサーファクトリ

これらは完全性のためにリストされていますが、Solrインフラストラクチャ、特にSolrCloudの一部です。更新リクエストハンドラー（または作成したコピー）を変更するときに、これらを削除しないようにする以外は、これらを変更する必要はほとんどありません。

DistributedUpdateProcessorFactory

必要なすべてのノードに更新を分散するために使用されます。

NoOpDistributingUpdateProcessorFactory

常にnullを返すDistributingUpdateProcessorFactoryの代替No-Op実装。分散更新をバイパスして独自のカスタム更新ロジックを使用したいエキスパート向けに設計されています。

LogUpdateProcessorFactory

ロギングプロセッサー。これは、チェーンを通過したすべてのコマンドを追跡し、finish（）でそれらを出力します。

RunUpdateProcessorFactory

基盤となるUpdateHandlerを使用して更新コマンドを実行します。ユーザーが代替のカスタムUpdateRequestProcessorFactoryで更新コマンドを明示的に実行している場合を除き、ほぼすべてのプロセッサーチェーンはRunUpdateProcessorFactoryのインスタンスで終わる必要があります。

ランタイムで使用できる更新プロセッサー

これらの更新プロセッサーは、solrconfig.xmlで構成する必要はありません。これらの名前が更新リクエストとともに送信されたprocessorパラメーターに追加されると、自動的に初期化されます。複数のプロセッサーは、コンマで区切られた複数のプロセッサー名を追加することで使用できます。

AtomicUpdateProcessorFactory

AtomicUpdateProcessorFactoryは、ドキュメントをアトミックに更新するために使用されます。

processor=atomicパラメーターを使用して呼び出します。通常のupdate操作をアトミック更新操作に変換するために使用します。これは、アトミック操作の構文がない/update/csvや/update/json/docsなどのエンドポイントを使用する場合に特に役立ちます。

例：

processor=atomic&atomic.field1=add&atomic.field2=set&atomic.field3=inc&atomic.field4=remove&atomic.field4=remove

上記のパラメーターは、通常のupdate操作を次の方法で変換します。

  • field1をアトミックなadd操作に

  • field2をアトミックなset操作に

  • field3をアトミックなinc操作に

  • field4をアトミックなremove操作に

TemplateUpdateProcessorFactory

TemplateUpdateProcessorFactoryは、テンプレートパターンに基づいてドキュメントに新しいフィールドを追加するために使用できます。

このプロセッサを使用するには、パラメータ processor=template を使用してください。テンプレートパラメータ template.field (複数値可) は、追加するフィールドとパターンを定義します。テンプレートには、ドキュメント内の他のフィールドを参照するプレースホルダーを含めることができます。単一のリクエストで複数の Template.field パラメータを設定できます。

例：

processor=template&template.field=fullName:Mr. {firstName} {lastName}

上記の例では、fullName という名前の新しいフィールドがドキュメントに追加されます。フィールド firstName と lastName は、ドキュメントのフィールドから取得されます。どちらかが欠落している場合、その部分は空文字列で置き換えられます。これらのフィールドが複数値である場合は、最初の値のみが使用されます。

UUIDUpdateProcessorFactory

UUIDUpdateProcessorFactory は、生成された UUID をドキュメントに追加するために使用されます。

このプロセッサを呼び出すには、パラメータ processor=uuid を使用してください。また、uuid.fieldName パラメータを使用して、UUID が追加されるフィールドを指定する必要があります。

例：

processor=uuid&uuid.fieldName=somefield_name