Kazuho Oku
kazuh****@gmail*****
2008年 2月 1日 (金) 22:14:58 JST
奥です。
MySQL のオプティマイザで他にもいろいろ気になることがあったので、勉強がてらパッチを書いてみました。
やっていることは単純で、
・senna の key にプライマリキーを含める (8バイト以内の数字だった場合のみ)
・オプティマイザの側で、取得カラムがプライマリキーのみか判定してフラグをたてる
・取得カラムがプライマリキーのみの場合は senna のキーから値を返し、行データを読まない
（boolean mode のみ)
ということです。手元の環境では、
select id from content_emkey where match(title,body) against
('+the' in boolean mode);
のようなクエリの所要時間が平均0.130秒から0.016秒に変化しました (メモリに載った状態で５回平均) 。実際には join
して使うことが多いでしょうから、そこまでの効果は望めないかもしれませんが、参照するワークセットが小さくなる
(同一メモリ量でより多くのデータを扱えるようになる) メリットも大きいと思います。
このパッチのメリットを整理すると、検索結果のプライマリキーにしか必要としない場合に無駄な行データ参照が発生しないため、
・join した上で他のテーブルのカラムを利用して order by ... limit する際に場合の高速化／省メモリ化
・self join して order by ... limit することで、2nd index patch と同等の効果が期待できる
(ただし 2nd index patch より遅いと思います。ベンチとっていませんが)
という感じになるかと思います。一方でデメリットは、
・プライマリキーが8バイト以内の数字以外の場合に効果がない
・１行あたり８バイト余計に空間を消費する
というあたりになるかと思います。
奥としては、
・Item_func_match あたりのフラグの立て方をもう少し調整する必要がありそう
・match の引数で subselect でインデックスを使うようなクエリを書くとやばいかも
・boolean mode の relevance の計算を TF 風にしたい
（出現回数を fulltext の長さで割りたい)
といった点があるので、まだもう少しいじるつもりですが、とりあえず、こちらにポストさせていただきたいと思います。
よろしくお願いいたします。
08/02/01 に Tetsuro IKEDA<te.ik****@jpta*****> さんは書きました:
> 奥さん、こちらでははじめまして：） 池田です。
>
> ご報告ありがとうございます！！
>
> まだしっかり調べていないので正確なことは言えないですが、こうしたヘビーな
> 環境で使った場合の欠点はぜひぜひ改善していきたいと考えています。
>
> 実際にご利用されている環境にて現れてきた性能問題としては他にも、、
> ・大きなテーブルへの更新クエリにより参照クエリが長時間ブロックされる問題
> （MyISAMを使用していることからくる欠点）
> ・更新クエリに対するCPUスケーラビリティが乏しい問題（これもMyISAM...）
>
> といったようなものを認識しています。
>
> Tritonnの普及を促進したい自分としては、機能的な不具合だけでなく、
> こうした問題にも積極的に取り組んでいきたいと考えております。
>
> # もちろんpatchの寄贈とかも大歓迎です :)
>
> この件につきましては、こちらでも擬似環境を作って調べてみたいと思います。
> その際にはいろいろ伺うこともあるかと思いますが、よろしくおねがいします。
>
>
> > はじめまして、奥一穂と申します。
> >
> > 仕事で 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
> >
> > _______________________________________________
> > Tritonn-dev mailing list
> > Trito****@lists*****
> > http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev
>
> ------------------------------
> Tetsuro IKEDA
> Sumisho Computer Systems, Corp.
> http://www.scs.co.jp/mysql/
> ------------------------------
>
> _______________________________________________
> Tritonn-dev mailing list
> Trito****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev
>
--
Kazuho Oku
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: tritonn-preserve-primary-key.patch
型: application/octet-stream
サイズ: 11774 バイト
説明: 無し
Download