Takayuki Honda
honda****@gmail*****
2012年 3月 7日 (水) 19:35:00 JST
本多と申します。
先日首題の件についてご対応頂きまして、誠にありがとうございます。
恥ずかしながらgithubから取ってきたソースでコンパイルする事が出来ず
正式リリースされたものでやっとコンパイル出来ました（それも人に頼んだ・・)
ので、簡単に速度を測ってみました。
まずご対応頂いたケース3「 全文検索以外の条件で絞り込む処理が遅い問題」
の方はlimit句を付ければ、早くなる事を確認出来ました。
select * from sample_beta where match(body) against
('12') and type = 1 order by match(body) against ('12') limit
0, 100;
groonga2.0.0+mroonga2.00(最適化on) = 0.15sec
groonga2.0.0+mroonga2.00(最適化off) = 0.51sec
tritonn1.0.12+Mysql5.0.87 = 0.47sec
ただ、ケース2「count(*)等で件数を取得するだけでも応答が遅い問題」
の方が、2.00から追加されたmroonga_enable_optimizationにて、
最適化をoff/onしても結果が変わりませんでした。
かつtritonnよりも遅い結果となりました。
select count(*) from sample_beta where match(body) against ('12') ;
groonga2.0.0+mroonga2.00(最適化on) = 0.54sec
groonga2.0.0+mroonga2.00(最適化off) = 0.54sec
tritonn1.0.12+Mysql5.0.87 = 0.11sec
テーブル定義
mroonga
CREATE TABLE `sample_beta` (
`search_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`body` varchar(2000) COLLATE cp932_bin DEFAULT NULL,
`type` tinyint(1) NOT NULL DEFAULT '1',
`regist_datetime` datetime NOT NULL,
`update_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`search_id`),
FULLTEXT KEY `fidx_sample_beta_01` (`body`)
) ENGINE=mroonga DEFAULT CHARSET=cp932 COLLATE=cp932_bin
tritonn
CREATE TABLE `search_real_1_beta` (
`search_id` bigint(20) unsigned NOT NULL auto_increment,
`body` varchar(2000) collate cp932_bin default NULL,
`type` tinyint(1) NOT NULL default '1',
`regist_datetime` datetime NOT NULL,
`update_timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY (`search_id`),
KEY `idx_search_real_01` (`type`,`search_id`),
FULLTEXT KEY `fidx_search_real_01` USING NGRAM, NO NORMALIZE, 512 (`body`)
) ENGINE=MyISAM DEFAULT CHARSET=cp932 COLLATE=cp932_bin
レコード数=約210万件 (上記SQLでhitする件数は約20万件)
データサイズ=約200M インデックスサイズ=約500M
何処か抜けてる箇所がありますでしょうか？ご教示頂ければ幸いです。
以上よろしくお願い致します。
> 須藤です。
>
> In <20120****@gmail*****>
> "[groonga-dev,00695] Re: 全文検索カラム以外を含んだ検索について" on Wed, 01 Feb 2012 21:14:51 +0900,
> Takayuki Honda <honda****@gmail*****> wrote:
>
> >> 今回のケースは3.にあたるかと思います。
> >> mroongaでは、このうち1.と2.のみを実装していますが、3.と4.は
> >> 未実装です。
> > 上記の件了解致しました。
> > 対応を期待しつつ、現状では実データで試してみて、
> > 応答速度が許容範囲かどうか判断していきたいと思います。
>
> 条件付きなのですが、gitリポジトリのmasterで対応してみました。
>
> >> > ---------------------------------------------------
> >> > select
> >> > *
> >> > from
> >> > table
> >> > where
> >> > match(body) against (“さんぷる”)
> >> > and
> >> > flag = 1
> >> > ---------------------------------------------------
>
> ↑だけではなく、↑に加えてORDER BY LIMITを指定すると↓と同じ
> 論理で高速化するようにしました。
> http://mroonga.github.com/ja/docs/userguide/storage.html#optimisation-for-order-by-limit-in-full-text-search
>
> たとえば↓のような感じです。
> ---------------------------------------------------
> select
> *
> from
> table
> where
> match(body) against (“さんぷる”)
> and
> flag = 1
> order by
> match(body) against (“さんぷる”)
> limit
> 0, 100
> ---------------------------------------------------
>
> これまでは、whereには全文検索条件1つのときしか「ORDER BY
> LIMIT 高速化」ができなかったのですが、全文検索条件と「簡単な
> 式」のwhereなら高速化するようにしました。
>
> 今のところ、「簡単な式」のところは「カラム名 = INTの値」のみ
> だけサポートしています。が、ここは難しいというよりも手を動か
> していけば対応種類を増やせるところなので、要望が大きいところ
> から対応していく進め方が現実的かと思っています。（たとえば、
> DOUBLEの値に対応することや「カラム名 < INTの値」などに対応す
> ることも難しくありません。）
>
> もし、1.20で期待した速度が出ない場合はこちらも試してみて結果
> を教えてもらえると嬉しいです。
--
Takayuki Honda <honda****@gmail*****>