mysqlftppcのUNICODE正規化のこと。
mysqlftppcのUNICODE正規化のこと。
既存のMySQLを5.0から5.1にするにあたって困ってたのが、全文検索で使っているSenna+Tritonnが5.1に対応する気配がないこと。
（まあ、Sennaからgroonaに変わるとか、いろいろあるんだろうけど）
そういやMySQL5.1以降はプラグインで後付けできるようになってるから、誰かがお手軽に日本語の全文検索用のpluginを作ってそうだよなーとか思っていたら、ちゃんとmysql full-text parser plugin collectionってのがあった。makeやinstallも簡単で便利。
でまあ、mecabを入れるのも面倒なのでbigramを使うことにする*1。検索するときはIN BOOLEAN MODEを指定しないといけないのですが、既存のシステムはIN BOOLEAN MODEで検索してるから問題ない。
全角／半角の同一視などが必要なのだけど、元の文字コードがUTF-8でないのでMySQL本体のUNICODE正規化はちょっと使えない。なので、ICU有りでmakeする。
make/installは簡単で、プラグインの追加も
>INSTALL PLUGIN bigram SONAME 'libftbigram.so';
――とかするだけで問題なし。
ALTER TABLEでfull-textインデックスを張り直して検索してみる。文字コードがujisなのでちょっと気になってたけど特に問題なく動く――が、全角／半角の同一視がされない。
……ああ、「SET GLOBAL bigram_normalization='KC'」とかで指定する必要があるのを忘れてた。こちらを設定し直してfull-textインデックスを張り直すとmysqldが落ちる。
「KDならどうじゃろ？」と思ってやってみると、mysqldは落ちないけどエラーが返ってくる。
ネットで検索してみても類似の事例は全然ないのでいちおうバグレポ出しておくかと思ってかなりダメなレポートを送っておいたところ*2、いつの間にか新しいftnorm.cがアップされてました。
それを使ったらちゃんと動くように！ hiroaki-kawaiさん、ありがとう！
でまあ、NFKCとNFKDのどっちがいいかなーと思って両方でインデックスを作ってみたわけですが、なぜだかNFKCはNFKDの15倍ほど時間がかかってました*3。NFKCのほうが変換に時間がかかるんでしょうかね？
あるいはもしかすると濁点などが別で処理されるため、かもしれないけど。だとすれば基本的にはNFKDで使うようにしたほうがいいかもしれません。
あと、おそらくUNICODE正規化の種類が混在してると具合が悪そうな気がしてるのだけど――たとえば「SET GLOBAL bigram_normalization='KD'」としてデータを突っ込んだあとに「SET GLOBAL bigram_normalization='KC'」としてデータを追加するとあまりよろしくなさげだし、そもそも検索にひっからなくなるかもね――その辺の検証はしてません。
このあたりは設定ファイルにプラグインの追加指定とともに書いておいたほうがいい気がしています*4。
まあ、そんな感じで。
