どんだけ検索好きですか、おいら...さらにブログ内検索の続き
MySQLのFULLTEXT検索を行えるようにしてみた(素直にSenna入れたら? って言わないでね!)。まだ実験レベル。もう少しチューニングしたら使えそうだ。
現状、以下のフォームから検索する場合の仕様というか制限。
- タグ検索の場合はFULLTEXT検索にはならない(両方にチェック入れた時はタグ検索が優先される)
FULLTEXT検索の場合4文字未満はマッチしない→set-variable=ft_min_word_len=1を指定したので解決FULLTEXT検索の場合、検索語は分かち書きされない→クエリも分かち書きしてAND検索とした- FULLTEXT検索の場合、順位付の指定は無効で関連性順に表示
- FULLTEXT検索の場合、ストップワード(半分以上のレコードに含まれるワード)は検索対象にならない
- スペースで区切るとAND検索、但しタグ検索の場合はカンマで区切ることでOR検索となる
FULLTEXT検索の仕様についてはここらへんを参照ください。
ウェブ上のインターフェイス作ってダイナミックパブリッシング用のMTタグ作って試してみるとFULLTEXT検索もLIKE検索もこのブログ(400エントリー弱)だと殆ど変わんない(検索速度がカンマ1秒以下のレベルになるとむしろテンプレートからのページ構築とかプログラムの起動とかネットワークとかブラウザのレンダリングとかそっちの方の速度の影響が目立ってしまうね...追記: SQL見直したら倍程度の差は出た)。
このあたり、実際にはエントリー数をもっとべらぼうに増やしてテストしてみたりしてみたい。そのうちやってみる。
仕様、実装、考察とか課題なんか
拡張したエントリーのフィールド(entry_fulltext)に「タイトル(×3)」「概要(Excerpt)」「内容(Body)」の内容をつないだもの (タグを削除、但し画像のALT属性は含める) をMeCabで分かち書きして入れて (←ここはPerlで書いたプラグインで行う) FULLTEXTインデックスを作成。MySQLのFULLTEXT検索を行い、結果をMTのダイナミックパブリッシング用のプラグインを作成してMTのテンプレートで組み立てる。
「タイトル(×3)」としたのは検索結果におけるタイトルの重みづけをするため。つまりタイトルに検索語が含まれる方がスコア? を高くする。このブログでは「概要(Excerpt)」には殆ど何も入れていないので、「内容(Body)」の先頭100文字程度が重複して入る。エントリーの本文の先頭付近にも重み付けする。つまり、(初期の)SEOのように、出現頻度とか先頭付近のテキスト重視とかでスコアリングされるようにチューニングしてみる。
現状、「ウェブアクセシビリティ」と「アクセシビリティ」は別のものとして扱われる。IPA 辞書に「ウェブアクセシビリティ」が単語として登録されているみたいなので。
つまり、こういった類似語みたいなものをどう吸収するか、とか十分な件数が得られなかった時にあわせてLIKE検索の結果をマージするとか、そのあたりがキモになるんでしょうね。
今日はここまで。続きはまたいずれ。
追記: 何でこんなに検索こだわるかっていうと、色々ニーズがあるのですね。最近は「イントラブログで社内ポータル」っていうような依頼も多くて。なので、導入のしやすさと顧客のニーズにあわせた選択肢を広げておきたいなぁ、というあたりと、あとは単に面白いかな。カンマ何秒短縮出来るか、あるいは求めている結果がどうやればズバリ出てくるのか。
「面白い」といえば、ここ1週間程MTのダイナミックパブリッシングが面白くて、そっちの理由もありますけどね。
MySQL単体だと、日本語ではmatch...against...使えないのではないでしょうか。
是非MySQL+Sennaをお使いになられては如何でしょうか。
サポートも致します。（笑）
また、確かに個人のブログくらいの分量だと、全表走査でも、FULLTEXT Searchでも、ほとんど速度は変わらないかも知れないですねえ。
＞MySQL+Senna関係者
あら。関係者様こんにちは。
＞MySQL単体だと、日本語ではmatch...against...使えないのではないでしょうか。
対象のテキストをMeCabで分かち書きしているので、うまく検索出来てますよ。
＞是非MySQL+Sennaをお使いになられては如何でしょうか。
サポートも致します。（笑）
その際には宜しくお願いします。
＞確かに個人のブログくらいの分量だと、全表走査でも、FULLTEXT Searchでも、ほとんど速度は変わらないかも知れないですねえ。
SQL見直したら400弱エントリーでも倍くらいのスピード差は出ました。おそらく1000超えたあたりから目に見えて差が出てくるんではないでしょうかと踏んでいます。
>対象のテキストをMeCabで分かち書きしているので、うまく検索出来てますよ。
なるほど。
Sennaを使わずに、別の手段でFulltext Indexを作成している、ということでしょうか。
倍のスピード、というのは、利用を検討するのに十分な効果ですねえ。
＞Sennaを使わずに、別の手段でFulltext Indexを作成している、ということでしょうか。
実際にこのページのフォームに「アクセシビリティ」とか「再構築」とかの日本語入れてもらえれば分かると思いますが、ちゃんとマッチします。
Sennaが良いかどうか、という話ではなくて(もちろん導入を検討するケースも出てくると思います)、いかに簡単にMTと連携させるか、ってのと、出来るだけ導入しやすいサイト(blog)内検索を実現するかってところに主題はあります。
僕は「Web屋」なので、クライアントの事情にあわせて色んな選択肢を持っておける方が有利なのですね(だからSennaのこともちゃんと知ってますし視野に入れてますよ!)。
SQLでのLIKE検索、Hyper Estraierを使った検索、MySQLのmatch~against検索、MT Perl APIを使ったループ+正規表現での検索、というように色んな選択肢を持ちたいってのが建前ですが、単純に「検索」って面白いテーマなのでなんだか「マイブーム」です。