2008年2月21日

[pgsql-jp: 39237] Re:日本語全文検索 textsearch-ja のご紹介

加納です。

> 現状では、インデックス・アクセスメソッドそのものを自作しない限り、
> 完全な組み込み型 N-gram 検索は難しいという印象です。
> 拡張 I/F は用意されていますが、実際に拡張を作るのはそれなりに高難度です。

Ludiaは、インデックスメソッドとして実装しています。そのため、DML文、
DDL文のIFとしては、ほぼ完全に統合されています。


●全文検索インデックス定義
・単語インデックスを作成する場合
CREATE INDEX index_name ON table USING fulltext(column);
・n-gramインデックスを作成する場合
CREATE INDEX index_name ON table USING fulltextb(column);
●検索
・単一検索語での検索
SELECT * FROM table WHERE column @@ 'keyword';
AND条件での検索
SELECT * FROM table WHERE column @@ 'keyword1 +keyword2';

また、内部で活用させてもらっているSennaは完全転置インデックス型ですの
で非常に高速に検索結果を返却します。結果として、PostgreSQLの返却性能が
最も大きな要素であるという状況です。

検索性能としては、1年半ほど前の検証ですが、840万件、17GB程度のテーブ
ルに対するレスポンスは以下の通りです。試験データは、某テキストデータを
100バイトずつぶつ切りにしてカラムに収容したものです。そのため、完全ラ
ンダムな試験データです。(N-gramでのテスト)
300件ヒットのクエリ 約1秒(Ludia) 約6分(LIKE文)
1000件ヒットのクエリ 約3秒(Ludia) 約6分(LIKE文)

> プロジェクトのページの末尾にリンクを用意しましたが、既にある拡張モジュール
> Ludia (Senna ベース), pgestraier (Hyper Estraier), pgRast (Rast) などでは
> N-gram 方式も選択できるようです。N-gram が必須という場合には、
> これらの中から選んで使っていくことになるかと思います。
>
> ただ、リカバリや DDL への対応不足などのトレードオフを持つものも
> あるようなので、事前に比較はされたほうが良いかもしれません。
> 性能や機能比較の情報も、ほとんど出回っていないようです。

上記の通りで、課題はリカバリです。インスタンス障害においても、イ
ンデックスは破損の可能性があり、基本的にはREINDEXでの対応をして
いただく必要があります。ただ、インデックスですから、再作成すれば
いいじゃないか、と割り切っていただけるならば、ご満足いただけるの
ではないかと思います。

Ludiaの紹介記事[ThinkIT]
http://www.thinkit.co.jp/free/article/0612/8/1/
Ludia開発日記
http://d.hatena.ne.jp/ludia/
採用事例
http://ludia.sourceforge.jp/moin.cgi/#id19
→採用事例を募集しています。すでにご利用の方で、公開させていただいて
よい事例がありましたら、ご一報ください。


投稿者 xml-rpc : 2008年2月21日 14:31
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/70114
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。