全文検索機能の設計
RDBMS にあるデータへの全文検索機能の設計で悩んでいます。アプリケーションは Java で記載すること、RDBMS は PostgreSQL を想定してます。色々なレイヤでのアプローチがあると思うのですが、イメージしている所をあげると
を考えています。
まず最初の Google 先生。
ここにもあるように、Customized Search と Search API の合わせ技が美味しそうです。メリットは全文検索については Google 先生に完全にお任せできる点とフロントエンドでのコントロールがしやすい点。デメリットとしては、先生用に RDMBS のデータをクローラがアクセス出来る所にさらす機能を作る必要がある点、クローラの検索タイミングをコントロールしづらい点、独自のランキング処理を追加するのが難しい点、ローカルの開発環境でテストしにくい点。
次に Lucene を使う方法。
Lucene+Solr を使うと、全文検索のエンジンに Lucene を使いつつ、アクセスを HTTP 経由で行う事が出来ます。Solr は Lucene のサブプロジェクトで詳細はこちら。Solr は無くてもよいのですが、HTTP でアクセス出来る所は魅力ですし、データの登録及びインデックス化の容易さを考えるとこの組み合わせは美味しそうです。メリットはローカルにテスト環境を構築出来る点、ミドルウェアにアプリケーション配備だけで検索エンジンを構築出来る点、フロントエンドでのコントロールがしやすい点、クラスタリングしやすい点。デメリットはとしては、RDMBS にデータを登録する際に、Solr 側にもデータをポストする必要がある事(データ登録時に RDBMS のトランザクションとは別に Solr へのトランザクション処理も考えないといけない)、別途 Solr のコンテキストを配備する必要がある点、検索結果と RDBMS の持つデータのマッピングを行わないといけない点といった所でしょうか。
三つ目、HyperEtraier を使う方法。
HyperEstraier+pgestraier を使う方法。pgestraier についてはここ。こちらも pgestraier 無しでも構築は可能ですが、trigger でデータの更新時に自動的に HyperEtraier のインデックス更新をしかける事が出来るので、この組み合わせが美味しそうです。メリットはローカルにテスト環境を構築出来る点、HyperEstraier のクラスタリング機能が使える点。デメリットとしては、HyperEstraier をローカルにインストールする必要がある点、検索結果と RDBMS の持つデータのマッピングを行わないといけない点。
最後 Ludia 。
Ludia を使うと、アプリケーション側の処理を全て RDBMS 内で留めておく事が出来ます。メリットは全て RDMBS での中に留められること、その為、検索結果でヒットしたデータのマッピングが不要な点、デメリットとしては (Windows 上での) ローカルの開発環境が整えにくい点、フロントエンドでのコントロールをしたければ別途開発が必要になる点。
Ludia に関しては、この性能比較も気になります。この資料自体にも幾つか気になる点(後述)はあるのですが、フィルタ検索をかけた場合の処理速度の差は大きいように思います。
メリット、デメリットを表にまとめようと思ったのですが、まだまとまりきっていない感もあるので、今日はここまで。
