基本概念¶
この章では、 IM-ContentsSearch における全文検索の実現方法について説明します。
Apache Solr について¶
IM-ContentsSearch で利用している全文検索エンジンの Apache Solr の機能、ならびに注意点について説明します。主に、機能面についてRDBと比較しつつ解説します。
リレーショナルデータベースと Apache Solr の機能比較¶
リレーショナルデータベース(以下、RDB) と Apache Solr における用語の対比表を以下に示します。
RDB Apache Solr 備考 スキーマ → コア 詳細については次項にて説明します。 テーブル → スキーマ レコード → ドキュメント IM-ContentsSearch では コンテンツ という形でラップしています。 カラム → フィールド プライマリキー → IDフィールド ユーザ → なし コミット → コミット 詳細については次項にて説明します。 ロールバック → なし なし → 最適化 詳細については次項にて説明します。 詳細説明
コア
RDBのスキーマにあたる機能で、1つの Apache Solr 上に複数のコアを保持することが可能です。Apache Solr に対して複数コアの設定を行った場合、コア毎にアクセスするURLが異なります。尚、 IM-ContentsSearch 用に配布している Apache Solr では、標準で default という名前のコアを定義しています。スキーマ
RDBのテーブルにあたる機能です。 Apache Solr では1コアに1スキーマのみ定義可能です。スキーマ上のプライマリキーにあたるIDフィールドは、システムを通して一意となる値を設定する必要があります。また、 Apache Solr のスキーマには以下の特徴があります。
- 配列型の値をサポートしている
- 動的フィールド (データ型のみ指定し後から自由に追加できるフィールド) がある
以上の特徴により、RDBよりも柔軟なデータ構造を持たせることができます。更新処理
IM-ContentsSearch for Accel Platform で利用している Apache Solr 3.6.1 にはRDBのupdate文のようにレコード内の特定カラムを更新する機能がありません。そのため、何れかの値に変更があった場合には該当のドキュメントを再度作成する必要があります。トランザクション
Apache Solr には分散トランザクションの概念がありません。そのため複数のプロセスから同時に登録処理が行われた場合、先行するプロセスのコミット処理によって、後続するプロセスが登録したデータが途中でコミットされる可能性があります。この問題を回避するために IM-ContentsSearch では、クローラジョブは１つのジョブネットにまとめ、更にそのジョブネットは並列実行を許可しない設定とします。コミット
Apache Solr のおけるコミットは、登録済みデータを検索結果に反映させる処理を指します。RDBのようにトランザクション処理を確定するためのコミット処理ではありません。最適化
Apache Solr ではコミット処理を行うたびに索引情報を保持したバイナリファイルが作成されるため、コミットを繰り返すとファイル数が増え続けます。ファイル数が増大することで、以下の問題が発生します。
- ファイルディスクリプタもしくはファイルハンドルを消費し続け、場合によっては不足する可能性がある。
- 検索処理の実行時に複数バイナリファイルをロードすることになり、I/O負荷が高くなるとともに検索速度が低下する。
この問題を回避するために、 Apache Solr には最適化 (optimize) 処理が用意されています。最適化処理を実行することで、バイナリファイルを最小限にまとめ直し、上記の問題を回避することが可能です。IM-ContentsSearch では、以下の方法で Apache Solr に対して最適化処理を実行する事が可能です。
- クローラジョブネットの最後に最適化ジョブを実行する。 (推奨)
- APIから最適化処理を実行する。 (非推奨)
- ジョブの終了処理にて上記の最適化APIを実行する。 (非推奨)
注意
最適化処理はバイナリファイルのサイズ、すなわち登録されたデータの量によって処理時間が増加するため、実行を最小限にする必要があります。そのため、すべてのコミット処理が終了するタイミングである、クローラジョブネットの最後に最適化ジョブを実行するよう設定することを推奨します。