Hibernate Searchって何だ？

メリット2「LuceneのAPIの隠蔽」

Hibernate Searchの第2のメリットは、Lucene APIの隠蔽である。「JBoss EAP+Luceneによる全文検索システム」を読んだ方は、Luceneの検索インデックスへのアクセスが、RDBへのアクセ スと似ていることに気がつくだろう。たとえば、Luceneの「DocumentとField」は、それぞれRDBの「レコードとカラム」に相当している。

また、Luceneの検索結果であるHitsオブジェクトはRDBの結果セット（ResultSet）のオブジェクトに似ているといえる。このこと は、「JBoss HibernateのプログラマがLuceneのオブジェクトとビジネスオブジェクトを自分でマッピングしなければならない」という問題を抱え込むことになってしまう。

そのような場合にHibernate Searchを利用するとLuceneのAPIが隠蔽され、検索インデックスへの書き込みや検索結果の取り出しが、すべてビジネスオブジェクトへのアクセ スで置き換えられる。これがHibernate Searchのメリットの2番目となる。

図2：LuceneのAPIの隠蔽

次に、Hibernate Searchのその他の特徴的な機能を紹介する。

Hibernate Searchのその他の機能「更新トランザクション」

前述の通り、RDBを更新するとHibernate SearchによりLuceneインデックスの更新が自動的に行われる。このとき、更新をトランザクション内で実行すると、Luceneインデックスへの 更新の反映はコミット時にまとめて行われる。一方、トランザクションではなく自動コミット（auto-commit）を使用する場合は、Luceneインデックスへの更新の反映はRDBの操作直後に実行される。

一般的にパフォーマンスの観点から、特別な事情がない限りはトランザクションを使用して更新するのが推奨されている。

なお、Luceneインデックスへの更新を更新専用の別スレッドに委譲する「非同期」更新とコミットを実行するスレッド内で更新する「同期」更新を選択することができる。

「非同期」の場合は、RDB更新処理とLuceneインデックス更新処理が別々のスレッドになるため、トランザクションのスループットとレスポンス性能が向上する。しかし、RDBの更新内容がLuceneインデックスに反映されるのに遅れが生じる。

「同期」の場合は「非同期」のときのメリットとデメリットが逆になる。つまり、RDBとLuceneインデックスの更新はリアルタイムに行われるが、更新リクエストが多い場合にトランザクションのスループットとレスポンス性能が低下する。

Hibernate Searchでは、「同期」を試してみて性能上問題が見られる場合は「非同期」に移行するように推奨している。

次にHibernate Searchのクラスタのサポートを紹介する。