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

kanout @ nttdata.co.jp kanout @ nttdata.co.jp
2008年 2月 21日 (木) 14:31:31 JST


加納です。

> 現状では、インデックス・アクセスメソッドそのものを自作しない限り、
> 完全な組み込み型 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
→採用事例を募集しています。すでにご利用の方で、公開させていただいて
よい事例がありましたら、ご一報ください。





pgsql-jp メーリングリストの案内