リクエストハンドラと検索コンポーネント
solrconfig.xml の <query> セクションの後、リクエストハンドラと検索コンポーネントが構成されます。
リクエストハンドラは、Solr に送信されるリクエストを処理します。これには、クエリリクエスト、インデックス更新リクエスト、Ping などの特殊なインタラクションが含まれます。
すべてのハンドラが solrconfig.xml で明示的に定義されているわけではなく、多くのハンドラは暗黙的に定義されています。詳細は 暗黙的なリクエストハンドラ を参照してください。
さらに、ハンドラは Config API を使用して configoverlay.json で定義または上書きできます。最後に、独立したパラメータセットも リクエストパラメータ API で定義できます。これらは params.json ファイルに格納され、useParams で参照されます。
これらの多層構成はすべて、Config API を介して検証できます。
独自の config ハンドラを定義することは、ビジネスケースをサポートし、クライアント API を簡素化するためにデフォルトと高度な構成を提供するのに役立つ方法です。同時に、このガイドで説明されているすべてのオプションを使用すると、実際にはどのパラメータが使用されているのかについて混乱が生じる可能性があります。
リクエストハンドラの定義と呼び出し
各リクエストハンドラは、名前とクラスで定義されます。リクエストハンドラの名前は、通常はパスとして、Solr へのリクエストで参照されます。たとえば、Solr が https://127.0.0.1:8983/solr/ にインストールされていて、「gettingstarted」というコレクションがある場合、次のようなリクエストを行うことができます。
https://127.0.0.1:8983/solr/gettingstarted/select?q=solrこのクエリは、/select という名前のリクエストハンドラによって処理されます。ここでは "q" パラメータのみを使用しており、クエリ用語である "solr" という単純なキーワードを含んでいます。リクエストハンドラにさらにデフォルトパラメータが定義されている場合、クライアント（またはユーザー）がクエリ自体で上書きしない限り、そのリクエストハンドラに送信するすべてのクエリでそれらが使用されます。
別のリクエストハンドラが定義されている場合は、その名前でリクエストを送信できます。たとえば、/update はインデックスの更新（つまり、新しいドキュメントをインデックスに送信する）を処理する暗黙的なリクエストハンドラです。デフォルトでは、/select はクエリリクエストを処理するリクエストハンドラであり、ほとんどの例とツールで想定されています。
リクエストハンドラは、名前の中にネストされたパスに対するリクエストも処理できます。例えば、/myhandler/extrapathを使うリクエストは、/myhandlerという名前で登録されたリクエストハンドラによって処理される可能性があります。/myhandler/extrapathという名前でリクエストハンドラが明示的に定義されている場合、ネストされたパスよりも優先されます。これは、Solrに含まれるリクエストハンドラクラスを使用していることを前提としています。独自のハンドラを作成する場合は、カスタムリクエストハンドラでネストされたパスを使用したい場合は、ネストされたパスを処理する機能を含める必要があります。
リクエストハンドラがあまり頻繁に使用されない場合は、必要になるまでロードされないようにstartup="lazy"でマークできます。
<requestHandler name="/spell" class="solr.SearchHandler" startup="lazy">
...
</requestHandler>リクエストハンドラの設定
リクエストハンドラを定義内で設定する方法は3つ、他の場所で設定する方法はさらに3つあります。
リクエストパラメータ（GETとPOST）
最も簡単で柔軟な方法は、標準的なGETまたはPOSTリクエストでパラメータを提供することです。
/select検索ハンドラにid、fl、wtパラメータを送信する例を示します。flパラメータの値のURLエンコードされたスペース（+）に注意してください。
https://127.0.0.1:8983/solr/techproducts/select?q=id:SP2514N&fl=id+name&wt=xml以下は、JSONリクエストAPIを使用して/query検索ハンドラにPOSTフォームを介してパラメータを送信する例です。
curl https://127.0.0.1:8983/solr/techproducts/query -d '
{
"query" : "memory",
"filter" : "inStock:true"
}'どちらの方法でも、パラメータは抽出され、以下で説明する他のオプションと組み合わせられます。
デフォルト、追加、および不変パラメータ
デフォルト
リクエストハンドラを設定する最も一般的な方法は、defaultsセクションを提供することです。そこに指定されたパラメータは、他の方法で上書きされない限り使用されます。
<requestHandler name="/select" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<int name="rows">10</int>
</lst>
</requestHandler>この例では、便利なトラブルシューティングパラメータechoParamsを定義し、リクエスト自体で定義されたパラメータのみを返す値（デフォルトなし）に設定し、詳細情報のためにallに設定しています。また、返す結果数（ページあたり）を指定するrowsパラメータも定義しています（10は実際上のデフォルトなので、変更しない場合は冗長な定義になります）。
パラメータが文字列、整数、または他の型の場合、デフォルトの定義方法は異なります。
他のプリミティブ型は以下のように表現されます。
<lst name="defaults">
<float name="hl.regex.slop">0.5</float>
<bool name="default">true</bool>
</lst>その他の特殊な型が存在する場合があります。それらは関連コンポーネントのセクションで説明されます。
追加
appendsセクションでは、既に他の場所で定義されているパラメータを追加するパラメータを定義できます。これらは、同じパラメータが複数回意味のある定義される場合（フィルタクエリなど）に役立ちます。クライアントがこれらの追加を上書きできるメカニズムはSolrにはないため、これらのパラメータが常にクエリに適用されることを確認する必要があります。
<lst name="appends">
<str name="fq">inStock:true</str>
</lst>この例では、フィルタクエリinStock:trueがすべてのクエリに追加され、利用可能な「製品」のみが返されるようになります。
不変パラメータ
invariantsセクションでは、クライアントによって上書きできないパラメータを定義できます。invariantsセクションで定義された値は、ユーザー、クライアント、defaults、またはappendsで指定された値に関係なく、常に使用されます。
<lst name="invariants">
<str name="facet.field">cat</str>
<str name="facet.field">manu_exact</str>
<str name="facet.query">price:[* TO 500]</str>
<str name="facet.query">price:[500 TO *]</str>
</lst>この例では、facet.fieldとfacet.queryパラメータが固定され、クライアントが使用できるファセットが制限されます。ファセットはデフォルトでは有効になっていませんが、クライアントがリクエストでfacet=trueを指定した場合、カウントを表示できるのはこれらのファセットのみになります。他のfacet.fieldまたはfacet.queryパラメータを指定しても無視されます。
InitParams
initParamsと呼ばれるセクションを使用して、リクエストハンドラのデフォルトを設定することもできます。これらのデフォルトは、各ハンドラで共通のプロパティを使用したい場合に使用できます。例えば、レスポンスで同じフィールドリストを要求する複数のリクエストハンドラを作成する場合は、フィールドリストを使用してinitParamsセクションを設定できます。initParamsの詳細については、InitParamsセクションを参照してください。
ParamsetsとUseParams
パラメータを頻繁に変更する必要がある場合、またはオンザフライで適用できるパラメータセットを定義したい場合は、リクエストパラメータAPIを使用して定義し、ハンドラの定義自体またはクエリパラメータとしてuseParams設定に1つ以上を提供して呼び出すことができます。
<requestHandler name="/terms" class="solr.SearchHandler" useParams="myQueries">
...
</requestHandler>https://127.0.0.1/solr/techproducts/select?useParams=myFacets,myQueriesparamsetが呼び出されても定義されていない場合は無視されます。これにより、ほとんどの暗黙的なリクエストハンドラは、必要に応じて後で定義できる特定のparamsetを呼び出すことができます。
検索ハンドラ
検索ハンドラはSolrにとって非常に重要です。データは（概ね）一度インデックス付けされますが、何度も検索されるためです。Solr（およびLucene）全体の設計は、検索のためのデータの最適化を目的としており、検索ハンドラはそのための柔軟なゲートウェイです。
検索ハンドラ内では、以下のセクションが許可されます。
<requestHandler name="/select" class="solr.SearchHandler">
... defaults/appends/invariants
... first-components/last-components or components
... shardHandlerFactory
</requestHandler>すべてブロックはオプションです。特に、パラメータはinitParamsとuseParamsでも提供できるためです。
defaults/appends/invariantsブロックについては、デフォルト、追加、および不変パラメータで既に説明しました。すべてのクエリパラメータは、任意の検索ハンドラののとして定義できます。
検索コンポーネントブロックについては次に説明し、shardHandlerFactoryはSolrCloud分散リクエストの微調整用です。
検索コンポーネントの定義
検索コンポーネント自体は、リクエストハンドラの外部で定義され、それらを使用したいさまざまな検索ハンドラから参照されます。ほとんどの検索ハンドラは、デフォルトの（暗黙的な）検索コンポーネントスタックを使用し、追加のコンポーネントを先頭または末尾に追加する場合のみ拡張する必要があります。コンポーネントスタックを完全に上書きすることは非常にまれであり、やや脆いですが、特定の検索コンポーネントの効果を明確に示す例で使用されています。
デフォルトコンポーネント
以下に示すように、検索エクスペリエンスは、主に以下に定義されているコンポーネントのシーケンスです。これらのコンポーネントはリストされている順序で呼び出されます。
| コンポーネント名 | クラス名 | 詳細情報 |
|---|---|---|
query |
|
クエリ構文とパーサーセクションで説明されています。 |
facet |
|
元のパラメータベースのファセットコンポーネントで、ファセッティングセクションで説明されています。 |
facet_module |
|
JSONファセッティングと分析モジュールで、JSONファセットAPIセクションで説明されています。 |
mlt |
|
MoreLikeThisセクションで説明されています。 |
highlight |
|
ハイライトセクションで説明されています。 |
stats |
|
統計コンポーネントセクションで説明されています。 |
expand |
|
結果の折りたたみと展開セクションで説明されています。 |
terms |
|
Termsコンポーネントセクションで説明されています。 |
debug |
|
debugパラメータに関するセクションで説明されています。 |
同梱のカスタムコンポーネント
デフォルトのコンポーネントとは別に、Solrには多くの追加の（非常に便利な）コンポーネントが同梱されています。実際に使用するには、solrconfig.xmlで定義して参照する必要があります。
-
AnalyticsComponentは、分析コンポーネント（非推奨）セクションで説明されています。 -
ClusteringComponentは、結果クラスタリングセクションで説明されています。 -
PhrasesIdentificationComponentは、インデックス付きフィールドのシングルトンに基づいて、入力文字列で見つかった「フレーズ」を識別してスコア付けするために使用されます。PhrasesIdentificationComponentのJavadocを参照してください。 -
QueryElevationComponentは、クエリ昇格コンポーネントセクションで説明されています。 -
RealTimeGetComponentは、リアルタイム取得セクションで説明されています。 -
ResponseLogComponentは、Solrログを介してユーザーに返されたドキュメントを記録するために使用されます。ResponseLogComponentのJavadocを参照してください。 -
SpellCheckComponentは、スペルチェックセクションで説明されています。 -
SuggestComponentは、サジェスタセクションで説明されています。 -
TermVectorComponentは、Termベクトルコンポーネントセクションで説明されています。
https://solr.cool/ウェブサイトからも、サードパーティのコンポーネントがいくつかリンクされています。
カスタム検索コンポーネントの定義
カスタムコンポーネントを定義する構文は次のとおりです。
<searchComponent name="spellcheck" class="solr.SpellCheckComponent">
<lst name="spellchecker">
<str name="classname">solr.IndexBasedSpellChecker</str>
...
</lst>
</searchComponent>カスタムコンポーネントには、ここで説明されていない構成要素が含まれていることがよくあります。詳細については、特定のコンポーネントのドキュメント/例を確認してください。
注意：デフォルトの名前のいずれかで新しい検索コンポーネントを登録すると、新しく定義されたコンポーネントがデフォルトのコンポーネントの代わりに使用されます。これにより、Solrのアップグレードをそれほど心配することなく、特定のコンポーネントを上書きできます。
検索コンポーネントの参照
一部のコンポーネントは、上記でリストされているデフォルトのコンポーネントの前（first-componentsを使用）または後（last-componentsを使用）で使用されるように定義できます。
<searchComponent name="..." class="...">
<arr name="first-components">
<str>mycomponent</str>
</arr>
<arr name="last-components">
<str>spellcheck</str>
</arr>
</searchComponent>| "debug"という名前で登録されたコンポーネントは、常に"last-components"の後で実行されます。 |
代わりにcomponentsを定義した場合、デフォルトコンポーネントは実行されず、first-componentsとlast-componentsは許可されません。これは、デフォルトリストは後のSolrバージョンで変更される可能性があるため、最後の手段として検討する必要があります。
<searchComponent name="..." class="...">
<arr name="components">
<str>mycomponent</str>
<str>query</str>
<str>debug</str>
</arr>
</searchComponent>更新リクエストハンドラ
更新リクエストハンドラは、インデックスへの更新を処理するリクエストハンドラです。利用可能な更新リクエストハンドラのほとんどは暗黙的であり、適切に名前付けされたParamsetを定義することでカスタマイズできます。
追加の更新リクエストハンドラを定義する必要がある場合、構文は次のとおりです。
<requestHandler name="/update/json" class="solr.UpdateRequestHandler">
... defaults/appends/invariants
</requestHandler>詳細は、更新ハンドラを使用したインデックス作成セクションで説明しています。
検索ハンドラの検索コンポーネントと同様に、Solrには更新リクエストハンドラ用のドキュメント前処理プラグインがあり、更新リクエストプロセッサと呼ばれ、デフォルトとカスタムの構成チェーンも許可しています。
注：更新リクエストハンドラと、solrconfig.xmlにも定義されているupdateHandlerセクションを混同しないでください。