3. Solrの概要¶

用語比較

RDB		Solr	備考
スキーマ	→	コア	詳細については次項にて説明します。
テーブル	→	スキーマ	詳細については次項にて説明します。
レコード	→	ドキュメント	IM-ContentsSearch では コンテンツ という形でラップしています。
カラム	→	フィールド
プライマリキー	→	IDフィールド
ユーザ	→	なし
コミット	→	コミット	詳細については次項にて説明します。
ロールバック	→	ロールバック	詳細については次項にて説明します。
なし	→	最適化	詳細については次項にて説明します。

詳細説明

• コア

  RDBのスキーマに相当する機能で、1つの Solr 上に複数のコアを保持することが可能です。

  Solr に対して複数コアの設定を行った場合、コアごとにアクセスするURLが異なります。

  尚、 IM-ContentsSearch 用に配布している Solr では、標準で default という名前のコアを定義しています。

• スキーマ

  RDBのテーブルに相当する機能です。 Solr では1コアに1スキーマのみ定義可能です。

  スキーマ上のプライマリキーに相当するIDフィールドは、システムを通して一意となる値を設定する必要があります。

  また、 Solr のスキーマには以下の特徴があります。

  1. 配列型の値をサポートしている
  2. 動的フィールド（データ型のみ指定し後から自由に追加できるフィールド）がある

  以上の特徴により、RDBよりも柔軟なデータ構造を持たせることができます。

• 更新処理

  IM-ContentsSearch で利用している Apache Solr 3.6.x にはRDBのupdate文のようにレコード内の特定カラムを更新する機能がありません。

  そのため、いずれかの値に変更があった場合には該当のドキュメントを再度作成する必要があります。

• トランザクション

  Solr には分散トランザクションの概念がありません。

  そのため複数のプロセスから同時に登録処理が行われた場合、先行するプロセスのコミット処理によって、後続するプロセスが登録したデータが途中でコミットされる可能性があります。

  この問題を回避するために IM-ContentsSearch では、クローラジョブは１つのジョブネットにまとめ、更にそのジョブネットは並列実行を許可しない設定としています。

• コミット

  Solr におけるコミットは、登録済みデータを検索結果に反映させる処理です。

  RDBのようにトランザクション処理を確定するためのコミット処理ではありません。

• ロールバック

  Solr におけるロールバックは、登録済みでコミット前のデータを破棄する処理です。

  先述の通り Solr には分散トランザクションの概念がないため、複数のプロセスから同時に登録処理が行われていた場合、別プロセスが登録したデータも削除されます。

• 最適化

  Solr ではコミット処理を行うたびに索引情報を保持したバイナリファイルが作成されるため、コミットを繰り返すとファイル数が増え続けます。

  ファイル数が増大することで、以下の問題が発生します。

  1. 検索時にロードするバイナリファイルが増加しI/O負荷が高くなることで、検索速度が低下する。
  2. ファイルディスクリプタ、またはファイルハンドルの消費量が多くなり、場合によっては不足する可能性がある。

  この問題を回避するために、 Solr には最適化（optimize）処理が用意されています。

  最適化処理を実行することで、バイナリファイルを最小限にまとめ直し、上記の問題を回避することが可能です。

  IM-ContentsSearch では、以下の方法で Solr に対して最適化処理を実行することが可能です。

  1. クローラジョブネットの最後に最適化ジョブを実行する。 （推奨）
  2. APIから最適化処理を実行する。 （非推奨）
  3. ジョブの終了処理にて上記の最適化APIを実行する。 （非推奨）

  注意

  最適化処理はバイナリファイルのサイズ、すなわち登録されたデータの量によって処理時間が増加するため、実行を最小限にする必要があります。

  すべてのコミット処理が終了するタイミングで最適化処理を実行するために、ジョブネットの実行ジョブの最後に最適化ジョブを設定することを推奨します。