Kazuho Oku
kazuh****@gmail*****
2008年 2月 1日 (金) 12:27:20 JST
はじめまして、奥一穂と申します。 仕事で Pathtraq というウェブサービスを開発していて、そのキーワード検索機能に Tritonn を使わせていただいています。また、MySQL のストレージエンジンを開発していたりします (http://q4m.31tools.com/) 。よろしくお願いいたします。 ところで、Tritonn の動作についてちょっと質問があるのですが、現状の Tritonn では、たとえば、 select id from content where match(body) against ('+test' in boolean mode); のようなクエリを投げた場合に、条件にマッチした全ての行データを MYD から読み込むと理解しています。 Pathtraq では、全文検索で得られた文書IDの一覧 (と tritonn の返す relevance と length(body)) と、別テーブルに記録されているスコアの一覧を inner join ... order by して結果を返しているのですが、大量に MYD へのアクセスが発生するため、実質的に MYD をメモリに載せておかないとサービスが提供できない感じになっています。 ＃あるいは、約２倍程度のメモリが必要となっているということです 奥の理解では、この原因は２つあって、 ・sql/sql_select.cc の make_join_readinfo 関数で、他の型の場合に行われる最適化処理が JT_FT の場合に実行されない ・そもそも MySQL の全文索引が、テーブルのプライマリキーではなく MYD ファイルのオフセットを記憶するようになっている というものです。 order by を予定するカラムと全文索引を同一テーブルに載せることができれば 2ind パッチが有効になるパターンだと思うのですが、Pathtraq の場合は、日ごとに異なるスコアテーブルがあるので、そのような対応は不可能です。また、他のユースケースにおいても、結合後に order by をしたい、というのはあり得る話だと思います。 現象の説明が長くなってしまいましたが、この問題について、あるいは関連するようなバージョンアップは今後予定されていますでしょうか？ 自分のケースに限って言えば、 ・プライマリキー等、必要なカラムを senna のキーのお尻にくっつけるようにする ・senna のキーのお尻から読むような read_record を作る ・read_record をセッション変数を用いて切り替えられるようにする といった感じでごまかしてしまえばオプティマイザに手を入れなくていいので楽なのですが、もっとちゃんとした解決策が検討されているのであれば、自分も何か協力できるかもしれませんし、メールする次第です。 よろしくお願いいたします。 -- Kazuho Oku
