ドキュメント数の非常に多いコレクションを扱う場合、複数のシャードを作ってデータを分けることができます。ドキュメントはそれぞれ複数のシャードのどれか1箇所にだけ属します。
シャードは1個以上のレプリカから構成されます。同じシャードに属するレプリカの内容はすべて同じです。シャードのうちどれか一つがリーダーとして選ばれます。

インデックス対象のドキュメントがSolrに送られてきたとき、まずそのドキュメントがどのシャードに属するべきかが決定され、そのシャードのリーダーにドキュメントが送られます。そして同じシャードに属する他のレプリカすべてにリーダーからドキュメントが転送されます。

レプリカにはいくつか種類があります。

NRT(= NearRealTime)

• デフォルトの設定。トランザクションログを保持しつつ自身のローカルのインデックスの更新も行う。
• リーダー選出の候補となる。

TLOG

• トランザクションログの維持はするが、自身ではローカルのインデックス更新は行わない。
• このタイプのレプリカはコミットを実行する必要が無いのでインデックスの速度向上が見込める。
• このタイプのレプリカでインデックスを更新するには、リーダーからインデックスをレプリケートする。
• リーダー選出の候補となる。
• もしもリーダーに選出された場合には、NRTレプリカと同様に動作する。

PULL

• トランザクションログの維持もローカルのインデックス更新もせず、リーダーのインデックスのレプリケーションのみを行う。
• リーダー選出の候補にはならない。

レプリカのうちどれかはリーダーにならなければならないので、シャードのレプリカをすべてPULLだけで構成することはできません。
Solrリファレンスでお薦めされているレプリカタイプの組み合わせは以下の通りです。

すべてNRT

更新のリアルタイム性が必要でありインデックス更新のスループットがそれほど大きくない場合、この組み合わせにする。
特にSoft Commitが必要な場合はNRTしか選択肢が無い。

すべてTLOG

インデックス更新のリアルタイム性が必要でなくシャード内のレプリカが非常に多い場合、すべてのレプリカで更新リクエストを扱えるようにしておきたいと考えるならば、この組み合わせにする。

TLOGとPULLの組み合わせ

インデックス更新のリアルタイム性が必要でなくシャード内のレプリカが非常に多い場合、多少古い検索結果を許容しつつ検索クエリへの応答能力拡大をするにはこの組み合わせにする。

はじめに

Solr 8.10 で管理画面に Schema Designer UI が追加されました。
https://solr.apache.org/guide/8_10/schema-designer.html

• ドキュメントのサンプルからスキーマを作ってくれる
• スキーマをGUIで編集できる
• 編集中のスキーマの設定でクエリがどんな動きになるか動作確認できる
• 作ったスキーマに基づいたコレクションを作成できる

と至れり尽くせりです。

使い方

名前を付けて新しいスキーマを作る

スキーマの名前と、元になる設定の名前を与えて新しいスキーマを作成します。

ドキュメントのサンプルを与えてスキーマの設定を生成する

インデックス対象のドキュメントをテキストエリアに貼り付けるか、ファイルを指定するかして与えます。ドキュメントは1個でも解析してスキーマを作ってくれますが、ドキュメントを複数与えておけば、後でクエリの動作を確認するときに色々なパターンを試せます。

今回サンプルとして与えたのは以下のようなドキュメントです。

[
{"id":"10","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62","address_p":"34.6164938333333,135.438210722222"},
{"id":"11","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14","address_p":"34.6190439722222,135.442191833333"},
{"id":"12","type":"官公庁","area":"住吉区","name":"住吉税務署","address":"住吉区住吉2丁目17番37号","address_p":"34.6109641111111,135.491388722222"}
]

生成されたスキーマの画面です。
JSONでフィールド名を与えているのでフィールド名が正しいのは当然として、サンプルの内容を解析してフィールドタイプもそれなりに妥当なものを選んでくれます。
たとえば上のように、緯度経度を値に持つ address_p フィールドに対して location タイプが選ばれています。

スキーマの設定を変更する

設定を変更することもできます。 住所を格納する address フィールドに対して string タイプが選ばれていましたが、ここでは形態素解析をする text_ja フィールドに変更しました。

Analyzer の動作を確認する

形態素解析をするフィールドでどのような解析が行われるか動作確認ができます。

クエリの動作を確認する

現在のスキーマの設定でクエリがどのように動くかを確認できます。

このときクエリの対象となるのが、最初に与えたサンプルドキュメントになります。今回はドキュメントを3件(id が 10, 11, 12)与えたので、全件検索で3件ヒットしています。

area フィールドを対象としたファセットで「住之江区」が2件、「住吉区」が1件となることも分かります。

変更前の設定との差分を確認する

元になった設定(_default)からの、現在の設定の変更点を表示します。

作成したスキーマを利用してコレクションを生成する

生成した設定は Zookeeper のツリー上に保存されますが、この設定を利用して一気にコレクションを生成することもできます。