OSC2007 Tokyo/Fall 出展まとめと今後の方向性(NGRAMデフォルト)

ありがとうございました

先週末はOSC2007 Tokyo/Fallの"Tritonnプロジェクト"ブースにご訪問いただいた方々、ありがとうございました。この場を借りてお礼申し上げます。

初めてのブース出展ということで準備段階から既にバタバタしていたのですが、ブースの位置が会場入り口入ってすぐの正面という好条件もあり（主催者のびぎねっとさんに感謝）、当初想定していたよりも2倍くらいの方々とお話＆CDRお渡しができたと感じています。

今回のブース出展はOSSプロジェクトとしてのPR活動を行いたいという目的の他に、配布用バイナリパッケージを作りたいという目的がありました。先にやる内容と変更できない締め切りを作ると、やるしかないので必然的にがんばるというやつですｗ

今後はNGRAMをデフォルトに

で、この単一バイナリの作成を通じて思ったのですが、今後のTritonnでのデフォルトのインデックスタイプはNGRAMで行きたいなと考えております。

というのもMeCabの場合はどうしてもlibmecabだけでなく辞書の扱いをどうするかという問題がでてきまして、この辺も含めて全て解決!!という感じでバイナリを作成するのがちょっと難しいと感じたのが一つの理由です。任意のディレクトリ内にプログラムが完結して、1台のマシンに複数インストール、複数同時起動OKなMySQLの特性を維持することは、優先事項だと思っています。

またNGRAMをデフォルトにしてMECABは明示的に使うというスタイルのほうが利用時のトラブルが少ないだろうという理由もあります。

例えば先日、MeCabに独自パッチをあてて辞書の位置をmysqldから認識できるようにする方法などを考案しましたが、これはmysqld.exeをWindowsのサービスから起動した場合には有効に機能しないことがわかりました。あとdatadirをbasedir配下から移動した場合も。

また通常、MySQLはテーブル単位で文字コードが選べますが、MeCab(+Senna)はサーバ単位でしか文字コードが選べませんし、利用する文字コードを変える場合には辞書の再構築が必要になります。ちょっとややこしい。一方、NGRAMを使用するとテーブル単位での文字コード混在環境がOKで、辞書が無いのであれこれ気にする必要がありません。

そんなわけで今後のバイナリ配布を考慮すると、NGRAMデフォルトかなぁと。あれこれ悩まなくてもちゃんと動くメリットはでかいなぁと。

ただもちろん、MeCabを使用する速度的・機能的なメリットは依然としてありますので、MeCabの利用を制限するつもりはまったくありません。NGRAMだけだと満足しない上級者むけのオプションになるという感じでしょうか。

変更仕様案

NGRAMをデフォルトに変更した場合、以下のような使い勝手を考えています。

ソースからビルドする場合、configure時に"--with-senna-index-type=mecab"を指定できるようにする。省略された場合にはngramが指定されたものとみなす。
バイナリ配布版は"--with-senna-index-type=ngram"(つまりデフォルト)で作成する。
mysqldの起動パラメータおよびmy.cnfに"--senna-index-type=mecab"を指定できるようにする。省略された場合はconfigure時の値が指定されたものとみなす。つまりバイナリ配布版でもこのパラメータを指定すればmecabをデフォルトとして使える。
インデックス作成時にUSING句でMECABを明示的に指定できるようにする。USING MECABという感じで。（現在のUSING NGRAMと同様の仕様に。）

あとMeCabを含むバイナリパッケージの作成のために、以下の変更を行う予定です。

mysqld起動時に$MECABRCが指定されていなければbasedir/etc/mecabrcを$MECABRCに設定

この方法でmysqldは問題なくmecab-ipadic等の辞書を見つけることができると思います。

"../etc/mecabrc"を読む独自パッチは前述の問題点が見つかったため使用しないことにしました。あとwrapperスクリプトですが、signal関連(終了処理と障害解析)、サードパーティ製ツール、運用監視で新たなトラブルが生じることの可能性を考慮し、利用を断念しました。

ということでbin/mecabを実行する際はrcfileあるいはdicdirを明示する必要がでてきますが、ここは致し方なしとします。

とりあえずまだこれは案なので、変更を実装してsvnにcommitしてみます。