DBMSデフォルト組み込みの全文検索
PostgreSQL 8.2からGINというインデックス形式が追加され、
それを用いれば全文検索インデックスが実現できます。
分かち書きを別途行う必要はありますが。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060912/247864/?ST=lin-server&P=3
MySQLのデフォルトの全文検索インデックスも、
分かち書きを別途行えば日本語の全文検索が実現できます。
http://pc8.2ch.net/test/read.cgi/php/1157467026/382
382 ：nobodyさん ：2006/10/05(木) 14:59:05 ID:???
MySQLならMeCabとかで分かち書きして、UTF-8でFULLTEXTに放り込む手もある。
んじゃ、分かち書きさえやってしまえば
SennaのxxxxバインディングとかLudiaなんてイラネー、
って話になるのかというと、そういうわけでもないんでゲス。
Sennaは転置インデックスという形式でインデックスを作っているわけです。
転置インデックスというのは、書籍の巻末によくある索引のようなもので、
ある単語がどの文書に登場するかを、単語ごとに記憶するインデックスです。
(例)Senna p15, p313 : Ludia p3, p93, p135
完全転置インデックスというものがありまして、
これは、ある単語がどの文書の「どの部分に」登場するかを記憶するインデックスです。
Sennaは完全転置インデックスを採用しています。
MySQLやPostgreSQLのGINは完全転置インデックスを採用していません。
たとえば、「検索できない」という文字列で検索が行われるとしましょう。
一般的に、「検索できない」は「検索/でき/ない」と分かち書きされます。
完全転置インデックスであれば、単語の出現位置を記憶しているため、
インデックスのみで「検索できない」という文字列を検索できます。
ところが、出現位置情報を持たない転置インデックスでは、
インデックスのみで「検索できない」という文字列を検索できません。
もっと正確に言うと、「検索できない」という文字列以外のレコードがひっかかってしまうのです。
たとえば、「信頼できた検索エンジンなんてない。」という文書が引っかかってしまいます。
なぜなら、上記の文書は「信頼/でき/た/検索/エンジン/なんて/ない」と分かち書きされてしまうため、
「検索」「でき」「ない」という３つの単語を含んだ文書として判定されてしまうからです。
こういう場合には、いったん全文検索が返してきたレコードを全件をシーケンシャルにチェックして、
「検索できない」という文字列が出現していることを確認しなければなりません。
つまり、インデックスのみで検索が完結せず、grepと同様の処理が余計に必要となっているのです。
全件チェックしないという選択肢もありますが、
その場合は検索結果の精度が落ちてしまいます。
このように、複数の単語がその順番どおりに出現しているものを検索することを
「フレーズ検索」といい、
それを高速に行うためには完全転置インデックスが適しています。
日本語の文書の場合には、
検索クエリで一見フレーズ検索を使っていないように見えても、
分かち書きを行った結果としてフレーズ検索が必要となる場合があります。
たとえDBMSデフォルト組み込みの全件検索がutf-8に対応しても、
仮に分かち書きに対応したとしても、
それだけで高速かつ高精度な日本語検索が行うことはできないのです。
というわけで、黙ってSennaとかLudiaとか使っとけ!!! 悪いようにはせんから。。。
というお話を講演したりする模様。
http://www.dbsj.org/Japanese/Archives/dbjapan/auto/2006/msg00211.html
[追記2]
たたみラボさんからトラックバックをもらったので追記。
MySQLの場合、組み込みのFULLTEXTを使っていて困る点は、
インデックス付与後の逐次更新の遅さとフレーズ検索の遅さ、
そして、他のインデックスを併用することができないという点です。
他のインデックスを併用できないとはどういうことかというと、
検索した結果をorder by last_update descみたいなクエリが遅くなります。
というお話が、明日講演される予定らしい。
http://www.ospn.jp/osc2007-spring/modules/eguide/event.php?eid=25
満席だけど、当日会場に空きがあれば入れるらしいので、
興味のある方は参加されてみてはいかかでしょうか。
